Blog

TOGAF voor IT-architectuur of Dragon1 voor Enterprise Architectuur?

Architectuur leer je niet uit een boekje, maar van een meester en na jarenlange uitoefening. Daarom: Niet TOGAF is verplichte kost voor de architect, maar de oratie van Daan Rijsenbrij.

In dit blog item geef ik een vergelijking van TOGAF met Dragon1. Ik heb de proef op de som genomen: een groep van zes beleidsmedewerkers van onder andere een gemeente kon ik in een Dragon1-Clinic van 3 uur hun eerste architectuurberoepsproduct laten maken (een ontwerpschets van een multiwetsysteem op conceptueel niveau), dat lang nadat ze een TOGAF training hadden gehad. Ik heb ook express een groep genomen die een TOGAF cursus had gevolgd maar niet aan het architectureren was geslagen. Dus wat is de waarde van een certificaat of boekenstudie? Het gaat om praktijkvaardigheid.

Ik denk dat een dag masterclass van Daan Rijsenbrij, een ervaren architect, mensen veel meer kennis en kunde bijbrengt dan een TOGAF-studie van enkele weken door jonge management-consultants gegeven. Met drie treffende vragen kan hij je laten voelen hoe ridicuul sommige informatiesystemen worden ontworpen bij de overheid en hoe architectuur daar positief aan had kunnen bijdragen. Het gaat om meesterschap, dat je kunst van de goeroe afkijkt en overneemt. Dat wat hij niet onder woorden kan brengen maar wat door voordoen zichtbaar wordt een beetje kan worden overgenomen. De oratie van Daan Rijsenbrij is bijvoorbeeld een veel onvoorwaardelijker document om te lezen dan TOGAF, maar je snapt dat document pas als je met een dag met hem bezig bent.

Daarnaast leer je architectuur door het te doen, fouten te maken en te leren van je fouten. Je moet fouten durven maken. Dat staat ook niet in het TOGAF-boekje.

Er zijn ook mensen die, net zoals ik, zeggen dat goede architecten veel voorbeelden hebben die ze mogen gebruiken van hun opdrachtgevers om anderen te tonen hoe je architectuur en ontwerpen maakt. Hieronder staan twee voorbeelden van architectuurvisualisaties die ikzelf heb gemaakt op basis van Dragon1.

Deze visualisatie laat de specifieke kenmerken zien van een multiwet-oplossing: Bijvoorbeeld het mogelijk maken van het uitvoeren van meerdere wetten en versies van wetten tegelijk om een nieuw gezicht en rol te creëeren.

Deze visualisatie laat zien welke '-gerichtheid' een bedrijfsonderdeel van een bepaalde ZBO in het bijzonder heeft. Bij een klantcontact centrum heb je namelijk andere mensen nodig, dan bij een gegevensdienst

Op basis van deze visualisaties heeft de klant keuzes kunnen maken en daadwerkelijk gemaakt in de architectuur en het ontwerp. De klant zag hoe zijn uitgangspunten werden geklankbord of vertaald in oplossingsrichtingen. Wat ik hiermee wil zeggen is dat ik over TOGAF veel theorie lees en maar weinig voorbeelden zie.

Er zijn nu meer dan tweehonderd practitioners van Dragon1 die zich steeds vaker afvragen wat TOGAF met architectuur te maken heeft en waarom het zo IT-minded is. Bijvoorbeeld vragen als: "Waarom is men in TOGAF zoveel bezig met het logische niveau in plaats van het conceptuele niveau? Waarom zijn architectuurprincipes in TOGAF een subset van IT-principes? Waarom lijken de architectuurprincipes zo op ontwerpregels? Klopt dat wel? Waarom kan een enterprise van alles zijn? Waarom is er geen eenduidige definitie voor architectuur en waarom wijkt deze af van de bouwkundige definitie van architectuur? Waarom zijn de definities in TOGAF inconsistent?". Deze mensen hebben mij gevraagd om nu te reageren.

Ik heb verschillende opmerkingen van toepassers van Dragon1 in de praktijk verzameld en in een kort artikel gezet. Het artikel is hier te downloaden:

TOGAF 9 versus Dragon1

Mijn conclusie:

Architectuur leer je niet uit een boekje, maar van een meester en na jarenlange uitoefening. Daarom: Niet TOGAF is verplichte kost voor de architect, maar de oratie van Daan Rijsenbrij.

TOGAF is een goed (reactief) analyse/managementinstrument, voor IT-architectuur, of beter gezegd: IT-structuur en IT-constructie. Dragon1 is volgens de Dragon1-gebruikers meer een (proactief) ontwerp/strategisch instrument voor bedrijfstransformaties en IT-innovatie onder enterprise architectuur.

Deze blog is geschreven door Mark Paauwe. Heeft u ook iets wat u bezig houdt? Meldt u dan aan als auteur en plaats uw eigen blog
Categorie:   
Auteur
afbeelding van markpaauwe
Mark Paauwe
Dragon1 Inc. - CTO

Mark is zeer actief in het enterprise architectuur vakgebied. De kans is groot dat je hem op een evenement tegenkomt en dat het gesprek al gauw over architectuurvisualisaties en architectuurprincipes gaat.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.