TOGAF™

TOGAF staat voor The Open Group Architecture Framework. Het is een snel groeiende standaard die wereldwijd wordt toegepast. TOGAF is ontstaan uit een jarenlange samenwerking van ervaren praktijkmensen in het architectuurforum van het internationale consortium The Open Group. Achterliggende gedachte bij dit werk  is de visie van The Open Group om te komen tot wat zij noemt een ‘boundaryless information flow’ waarbij integratie, standaardisatie en hergebruik de voornaamste thema’s zijn.

TOGAF is gestart in 1995 en gebaseerd op een architectuuraanpak met de naam ‘Technical Architecture Framework for Information Management (TAFIM)’ – een initiatief van het Amerikaans ministerie van Defensie [US Department of Defense, 1996]. De deelnemers aan het architectuurforum hebben sinds die tijd de methode doorontwikkeld in opeenvolgende versies en er wordt nog steeds aan gewerkt. Iedere nieuwe versie wordt, na goedkeuring door het forum, in zijn geheel gepubliceerd op de website van The Open Group. De grootste recente wijzing in TOGAF is het uitbrengen van versie 9.0 in februari 2009. Die versie was de eerste grote vernieuwing sinds versie 8.1 eind 2003 het licht zag. De actuele versie is 9.1. Deze versie bevat, ten opzichte van versie 9.0, cosmetische aanpassingen die vooral tot doel hebben de interne consistentie te vergroten en om onduidelijkheden weg te nemen.

Het doel van de methode is om organisaties het denkmateriaal ter beschikking te stellen om zelf een enterprise-architectuur te ontwikkelen door de aangeboden ontwikkelmethode te gebruiken waarin de verschillende deelarchitecturen worden samengebracht. De bedrijfsdoelstellingen en de strategie van de organisatie moeten hierin centraal staan. TOGAF kan gebruikt worden in conjunctie met andere raamwerken. Daarmee wordt het mogelijk om binnen de TOGAF-methode gebruik te maken van bijvoorbeeld een raamwerk dat zich richt op specifieke producten in een sector. De methode is open in haar verdere ontwikkeling en gebruik. De vormgeving is in het forum ondergebracht en deelnemers kunnen allen meedenken, meeschrijven en meebeslissen. Het gebruik van de methode door organisaties is vrij van licentieverplichtingen en in die zin ook open. Iedere gebruikersorganisatie mag het materiaal zonder kosten voor haar eigen architectuurontwikkeling inzetten. Zo ondersteunt TOGAF organisaties die hun eigen enterprise-architectuur op een gestandaardiseerde manier willen ontwikkelen of uitbouwen. TOGAF richt zich niet alleen op de inhoud van de verschillende architecturen, maar ook op het gebruik ervan door de organisatie. Commercieel gebruik van de methode is wel aan licentieovereenkomsten gebonden.

In korte tijd is TOGAF heel populair geworden in Europa en Nederland. In Angel- saksische landen wordt de methode al langere tijd gebruikt. Het aantal implementaties wereldwijd en in Nederland is inmiddels ontelbaar.

Definitie van architectuur

De definitie van architectuur die wordt gehanteerd in TOGAF is consistent met de standaard zoals die was gesteld door ISO/IEC [ISO2007]. De originele, in de Engelse taal opgestelde definitie luidt: ‘1. A formal description of a system, or a detailed plan  of the system at component level, to guide its implementation; 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time’.

TOGAF onderkent, zoals de definitie kenbaar maakt, twee visies op architectuur:

• De eerste visie betreft de formele beschrijving van een systeem, of een gedetailleerd plan van het systeem op componentniveau om de implementatie ervan te begeleiden.
• De tweede visie betreft de structuur van de componenten, hun interne verhouding en de principes en richtlijnen die hun ontwerp en ontwikkeling in de loop van de tijd Kortweg, een implementatie- en een ontwerpfocus.

Bij TOGAF wordt een flinke hoeveelheid documentatiemateriaal meegeleverd, waaronder het bijna zevenhonderd pagina’s tellende TOGAF-document [The Open Group, 2011], dat een vrijwel volledige beschrijving van de methode geeft. In dat materiaal wordt consequent gesproken over enterprise-architectuur. TOGAF onderkent daarin drie lagen of domeinen die elk apart beschreven kunnen worden: de business-, de informatiesysteem- en de technische architectuur. Merk op dat de informatiesysteemarchitectuur zelf weer uit twee aspecten bestaat, de applicatie- en de data-architectuur.

De opzet van TOGAF

TOGAF bestaat in essentie uit een zestal onderdelen.

1. Het eerste onderdeel, de ‘architecture development method’ of kortweg ADM, is een procesmethode voor het ontwikkelen van een enterprise-architectuur. Deze procesmethode vormt de kern van TOGAF en richt zich op ontwikkeling, implementatie en beheer van een enterprise-architectuur.
2. Het tweede onderdeel, ‘ADM guidelines and techniques’, voorziet de methode van een verzameling richtlijnen en technieken ter ondersteuning van de architect. Hierbij hebben de richtlijnen voornamelijk betrekking op het gebruik van de methode voor specifieke doeleinden of deelarchitecturen, zoals een beveiligingsarchitectuur, en hebben de technieken betrekking op het uitvoeren van bepaalde processtappen, zoals het opstellen van
3. Het derde onderdeel, het ‘architecture content framework’, biedt een uitgebreid model van architectuurproducten en de relatie daarvan met zogenoemde artefacten en architectuurbouwstenen. Dit derde onderdeel van TOGAF beschrijft feitelijk waaruit volgens TOGAF een architectuur bestaat en vormt daarmee een belangrijk onderdeel van het TOGAF-raamwerk.
4. Het vierde onderdeel, het ‘enterprise continuum & tools’, beschrijft methoden voor het classificeren van architectuur- en solutionartefacten, teneinde deze in een repository te kunnen organiseren en toegankelijk te Ook biedt het richtlijnen voor het selecteren van een toolset voor het maken en beheren van artefacten.
5. Het vijfde onderdeel, ‘TOGAF-referentiemodellen’, biedt twee referentiemodellen die architecten kunnen toepassen bij het uitvoeren van de architectuurwerkzaamheden uit de
6. Het zesde onderdeel, het ‘architecture capability framework’, biedt allerlei hulpmiddelen om in een organisatie de architectuurcompetenties te meten en in te richten.

Figuur 1 toont een overzicht van TOGAF waarin de bovengenoemde onderdelen herkenbaar zijn.

Figuur 1: Overzicht van de onderdelen van TOGAF 9.

De architecture development method

Het eerste onderdeel, de architectuurontwikkelmethode ADM, wordt beschouwd als het hart van TOGAF. We beschrijven hier deze procesmethode en de fasen waaruit die bestaat.

In feite wordt het architectuurproces gedreven vanuit de procesmethode ADM. Die bestaat uit een aantal iteratieve fasen, elk opgebouwd uit verschillende stappen, waarin bij iedere iteratieslag wordt doorgebouwd aan de totstandkoming van de enterprise-architectuur. Deze aanpak stelt organisaties in staat om op maat en in eigen tempo een architectuur te ontwikkelen. ADM is voorschrijvend als methode, maar stimuleert op duidelijke wijze de aanpassingen aan specifieke situaties en omstandigheden. De methode geeft volledige vrijheid in het toepassen van de fasen en de volgorde waarin die worden uitgevoerd. Ook kunnen naar believen onderdelen van andere methoden ingevoegd worden binnen het TOGAF-raamwerk. Dat betekent dat organisaties een eigen aanpak kunnen hanteren, passend bij de eigen cultuur en bij de branche waarin men actief is. Zo zal de ene organisatie een meer technologiegedreven architectuur kunnen ontwikkelen, terwijl de andere organisatie juist sterk vanuit een business- of integratieperspectief kan werken.

Figuur 2 toont hoe de diverse fasen in de ADM met elkaar samenhangen. Deze tien fasen worden kort toegelicht.

Figuur 2 De TOGAF Architecture Development Method.

Voorbereidende Fase

De besluitvorming over de manier waarop de organisatie ‘architectuur gaat bedrijven’, wordt op hoog niveau vastgelegd in de voorbereidende fase. Als er op hoog niveau geen besluitvorming heeft plaatsgevonden over het architectuurwerk, dan kan in de visie van TOGAF geen start plaatsvinden. In deze voorbereidende fase worden

de fundamentele principes opgesteld, wordt het raamwerk gekozen en wordt een aantal besluiten genomen, zoals de manier waarop de werkzaamheden naar een volgende fase worden overgedragen. Bedenk hierbij dat grote organisaties werken met overdrachtsdocumenten die een formele status hebben. Vaak wordt werk overgedragen aan een ander team of een andere afdeling en overdrachtsdocumentatie dient dan als de input op basis waarvan de vervolgwerkzaamheden uitgevoerd worden. De fase kan daarom worden afgesloten met een officieel verzoek om een architectuurproces op te starten: ‘request for architecture work’.

Requirementsmanagement

Centraal in de ADM staat requirementsmanagement. Dit is niet zozeer een fase als wel het verbindende mechanisme tussen de andere fasen. Alle fasen worden gedreven door de behoeftebepaling van de business en requirementsmanagement analyseert, bewaart en voedt die behoeften in en uit alle relevante fasen. TOGAF schrijft overigens geen methode of techniek voor requirementsmanagement voor.

Fase A: Architectuurvisie

Deze fase levert op basis van de kaders die zijn vastgesteld in de voorbereidende fase een langetermijnvisie voor de te ontwikkelen architectuur en hoe die visie een oplossing zal vormen voor de gestelde doelen. Naast dit richting geven aan het verdere architectuurwerk, zijn belangrijke doelen van deze fase het helder maken van voordelen en doelen die met de architectuurwerkzaamheden worden nagestreefd en het creëren van draagvlak binnen de organisatie. In deze fase wordt de strategie van de organisatie gevalideerd en worden de belanghebbenden met al hun eigen bedoelingen en belangen in kaart gebracht, zodanig dat de centrale requirements (eisen) en de constraints (beperkingen) duidelijk worden weergegeven. De huidige en de toekomstige architectuur worden hierop in grove lijnen ontworpen. Op deze wijze wil de visiefase draagvlak en erkenning voor de ontwikkelcyclus veiligstellen en de relatie met andere architectuurcycli verhelderen en in lijn brengen. Deze belangrijke fase wordt afgesloten met een contract, de ‘approved statement of architecture work’, dat de basis vormt voor het ontwikkelwerk van de diverse domeinarchitecturen.

Fasen B, C en D: Bedrijfs-, informatiesysteem- en technische architectuur

Dit zijn de fasen waarin de architectuur in de drie lagen (TOGAF spreekt van domeinen) opgesteld wordt. Alle drie kennen eenzelfde stapsgewijze opbouw. De eerste stap is een beschrijving van de huidige situatie, de tweede stap is een beschrijving van de gewenste situatie en de derde stap is een analyse van de veranderingen die nodig zijn om van de huidige situatie naar de gewenste situatie toe te groeien. Deze derde stap, de gap-analyse, is heel belangrijk omdat juist die analyse bepalend is voor het verdere werk.

Het begrip ‘building block’ (een herbruikbare component uit eerder werk en/of uit eerdere architectuurcycli) speelt een grote rol. Iedere fase gebruikt zaken die in een vorige fase zijn geproduceerd of bewerkt en iedere fase geeft zijn producten over aan de deelnemers van de volgende fase.

Deze drie ontwerpfasen worden herhaald, net zolang totdat een stabiele en voldoende gedetailleerde versie is bereikt waarmee de opdrachtgever en de andere belanghebbenden akkoord gaan. Dat akkoord vormt dan de formele toestemming voor de vervolgfasen van implementatie en beheer.

Fase B, Bedrijfsarchitectuur, is de fase waarin de bedrijfsarchitectuur wordt gespecificeerd en views op de business worden beschreven vanuit de perspectieven van de belanghebbenden. De business kan volgens TOGAF door middel van verschillende modellen en methodieken worden beschreven. Ze noemen activity models, use cases, class-, nodeconnectivity- en information exchange-modellen. Hierbij wordt ervoor gewaarschuwd om niet onnodig in details te treden en een juist beschrijvingsniveau vast te houden. Volwassen organisaties kennen veel verschillende architectuurproducten en hergebruik hiervan wordt gestimuleerd. De doelarchitectuur kan met behulp van deze herbruikbare componenten zo nodig geactualiseerd en onder aanvulling van nieuwe componenten volledig gedocumenteerd worden. De zo opgebouwde doelarchitectuur beschrijft de producten/dienstenstrategie, de organieke en functionele processen, de informatie en de geografische aspecten van de context van de gekozen scope. Dit alles in relatie gebracht met de businessprincipes, de doelen en de geïdentificeerde drijfveren. Deze fase wordt afgesloten met een verschilanalyse en een formeel rapport.

Fase C, Informatiesysteemarchitectuur, houdt zich bezig met enerzijds de data- en anderzijds de applicatiearchitectuur. TOGAF laat de volgordelijkheid van beide architecturen geheel open. De organisatie kan vrij kiezen welke architectuur eerst wordt ontwikkeld en daardoor als leidend kan worden opgevat. Deze keuze is afhankelijk van de bedrijfscultuur, de situatie en andere organisatiespecifieke aspecten. Voor beide delen (data en applicatie) worden modellen gemaakt, waarbij de relatie met de bedrijfsfuncties wordt gelegd. Men gaat via formele ‘checkpoint reviews’ van de modellen en bouwstenen samen met de belanghebbenden na of alle belangen gedekt zijn. Vervolgens wordt een impactanalyse ondernomen die voorwaarden oplegt aan het vervolgtraject van de technische architectuur. Ook deze fase wordt weer met een delta-analyse afgesloten.

Fase D, Technische architectuur, legt de fundering voor een toekomstige technische infrastructuur. In deze fase komt de vertaling in technische termen van de drie vorige architecturen (bedrijfs-, data- en applicatiearchitectuur) tot stand. De indeling van deze fase is gelijk aan die in de voorafgaande twee fasen: huidige situatie, gewenste situatie, delta-analyse. Voor het opstellen van de gewenste situatie worden verschillende modellen geanalyseerd, worden de requirements geverifieerd, de bouwstenen geselecteerd en de interfaces gespecificeerd. Bij de delta-analyse wordt ontbrekende functionaliteit onderzocht. Een en ander wordt ook hier weer opgenomen in het afsluitende faserapport.

Fase E: Kansen en oplossingen

Deze fase dient om een afweging te maken tussen de diverse scenario’s voor verandering die zijn ontstaan uit het werk in de voorgaande fasen. Deze fase is dus als

eerste sterk gericht op de implementatie. Om een goede afweging te kunnen maken, is het belangrijk om de voor- en nadelen, kosten en afhankelijkheden van de diverse scenario’s te onderzoeken. Daaruit volgt dan een globale visie op welke projecten gestart moeten worden om de gewenste veranderingen tot stand te brengen. Deze visie vormt de basis voor een migratiestrategie. Ook wordt in deze fase onderzocht of het zinvol is een volgende iteratieslag te maken in een of meer van de voorafgaande fasen.

Fase F: Migratieplanning

In de migratieplanning worden de implementatietrajecten geprioriteerd, waarbij gekeken wordt naar de implicaties, de afhankelijkheden, de producten, de kosten en de verwachte opbrengsten. De risicoanalyse van het implementatietraject wordt in beeld gebracht en de uitkomst van deze fase is een globale planning met een tijdslijn waarop de verschillende verandertrajecten worden uitgevoerd. Bovendien wordt een concept van een architectuurimplementatieplan opgeleverd.

Fase G: Implementatie governance

In deze fase wordt de feitelijke implementatie gecoördineerd. Ieder traject krijgt een leidend document mee, waarin voorwaarden en aanbevelingen staan opgenomen. Dit heet het architectuurimplementatiecontract. De coördinatie wordt vormgegeven in besturingsfuncties waarmee men wil afdwingen dat individuele projecten zich conformeren aan de architectuur.

Fase H: Beheer van de  architectuur

Deze fase richt zich op het beheren van de architectuur. Concreet betekent dit het bewaken van de actualiteit van de architectuurproducten en het begeleiden van wijzigingen daarin. Veranderingen in de bedrijfsomgeving of voortschrijdende technologie kunnen ertoe leiden dat architectuurproducten die in de andere fasen tot stand gekomen zijn, aangepast moeten worden. Ook zullen uit de implementatiefasen lessen geleerd zijn die een plaats moeten krijgen in de architectuur. In veel gevallen kan volstaan worden met kleine wijzigingen, maar in deze fase wordt ook bepaald of er noodzaak is voor een nieuwe volledige architectuurcyclus. Hierdoor ontstaat een dynamische enterprise-architectuur.

De hierboven beschreven tien fasen (de voorbereidende fase, requirementsmanagement en de fasen A tot en met H) vormen gezamenlijk een complete methode om een enterprise-architectuur te ontwikkelen, te implementeren en te beheren. Deze architecture development method is de kern van TOGAF.

Het architecture content framework

Zoals bij de beschrijving van de onderdelen van TOGAF al werd aangegeven, vormt het architecture content framework de inhoudelijke onderbouwing van de methode. Het beschrijft de relatie tussen architectuur(eind)producten, artefacten en bouwstenen. Waar de procesmethode ADM definieert welke activiteiten uitgevoerd moeten worden om een enterprise-architectuur te ontwikkelen, definieert het architecture content framework hoe die enterprise-architectuur eruit moet zien.

We beschrijven kort de belangrijkste onderdelen van het architecture content frame work:

• Architectuurproducten zijn de tastbare resultaten van een architectuurproject. Het zijn documenten of eventueel de inhoud van een repository die formeel worden afgestemd, gereviewd en
• Artefacten zijn werkproducten die veelal onderdeel uitmaken van een architectuurproduct. Het betreft doorgaans lijsten, tabellen en diagrammen. Artefacten worden vaak opgesteld vanuit een bepaald Voorbeelden zijn de specificatie van een component of een interactiediagram.
• Bouwstenen representeren herbruikbare componenten. Door bouwstenen te combineren kunnen concrete architecturen worden samengesteld. Kenmerkend is dat naar gelang de architectuur zich ontwikkelt, bouwstenen steeds verder uitgewerkt worden. Een bouwsteen kan ook opgebouwd zijn uit meerdere ‘sub-bouwstenen’.

TOGAF biedt een zogenoemd contentmetamodel, waarin de mogelijke typen bouwstenen zijn opgenomen en waarmee relaties tussen bouwstenen duidelijk worden. Het contentmetamodel is weergegeven in figuur 3.

Figuur 3: TOGAF contentmetamodel.

Enterprise Continuum en referentiemodellen

Het TOGAF Enterprise Continuum biedt de architect ondersteuning bij het onderhouden van de architectuurrepository. Het is een visie op de architectuurrepository die architecten helpt om architecturen en onderdelen daarvan te classificeren en de evolutie van de architectuur (bijvoorbeeld van abstract naar concreet of van logisch naar fysiek) zichtbaar te maken. Daardoor ontstaat een goed beeld van de context waarin architectuuronderdelen tot stand komen. Het Enterprise Continuum is vooral bedoeld als middel om effectieve communicatie van en over architectuur te bevorderen.

Het Enterprise Continuum hoofdstuk biedt ondersteuning bij het partitioneren van architecturen, dat wil zeggen op te delen in deelarchitecturen. Dat is zinvol, omdat enterprise-architecturen veelal een grote omvang en complexiteit hebben. Door te werken met deelarchitecturen wordt die complexiteit beheersbaar. Partitioneren kan bijvoorbeeld op basis van expertise of domein, abstractieniveau of gezichtspunt.

Verder bevat dit deel van TOGAF een metamodel voor het opzetten van architectuurrepository’s. Ook scharen we de referentiemodellen die TOGAF meelevert onder het Enterprise Continuum.

Het architecture capability framework

Het architecture capability framework biedt hulp bij het inrichten van de architectuurfunctie binnen een organisatie. Het beschrijft organisatiestructuren, taken en verantwoordelijkheden, vaardigheden en processen gerelateerd aan het ontwikkelen, beheren en toepassen van architectuur. Zo wordt bijvoorbeeld beschreven welke verantwoordelijkheden binnen een ‘Architecture Board’ belegd moeten worden. Nuttig is ook het architecture skills framework (architectuurcompetentieraamwerk), waarin voor diverse rollen een lijst van vaardigheden wordt gegeven met bij elke vaardigheid het niveau waarop een architect die vaardigheid moet beheersen. Dit zou bijvoorbeeld als basis kunnen dienen voor een functiewaardering van architecten binnen een organisatie. Een ander belangrijk aspect is architectuurvolwassenheid. TOGAF onderkent het belang van volwassenheidsmodellen op architectuurgebied, maar heeft daar nog geen uitontwikkelde visie op.

Figuur 4 toont in een radardiagram de score van TOGAF in het vergelijkingsmodel.

Denkwijze

TOGAF onderkent in de procesmethode drie architectuurlagen (bedrijfs-, informatiesysteem- en technische architectuur), maar werkt feitelijk met vier lagen doordat de informatiesysteemarchitectuur uiteenvalt in een applicatie- en een data-architectuur. De lagenstructuur biedt goede mogelijkheden om verantwoordelijkheden en taken te verdelen tussen afdelingen die bij het ontwikkelen van de architectuur betrokken zijn. Ook onderkent TOGAF dat er binnen de lagen diverse belanghebbenden zijn

Figuur 4: TOGAF gepositioneerd op het vergelijkingsmodel.

die elk een eigen rol spelen en vanuit hun eigen gezichtspunt in het architectuurproces betrokken worden.

TOGAF is vooral geschikt voor organisaties die een holistische aanpak van hun architectuur nastreven. Met de methode kunnen alle aspecten van enterprise-architectuur in samenhang worden opgepakt. Door de scheiding tussen architectuurlagen wordt het mogelijk om binnen een laag een andere architectuuraanpak te volgen, zolang die aanpak zich conformeert aan de scheiding tussen architectuurlagen. Dit kan met name interessant zijn voor organisaties die bijvoorbeeld een eigen methode voor infrastructuurontwerp hanteren.

Zoals eerder al is aangegeven, biedt TOGAF door middel van het architecture capability framework ondersteuning voor het inrichten van een architectuur governancefunctie. Zo’n functie is in de visie van TOGAF noodzakelijk, want architectuur is volgens TOGAF geen eenmalige exercitie maar een continu en iteratief proces dat actief gemanaged moet worden.

Beheer- en exploitatiewijze eigenaar

TOGAF wordt beheerd door The Open Group, een onafhankelijk consortium dat streeft naar open standaardisatie op diverse terreinen. De methode wordt daarom gepositioneerd als een open methode. De documentatie is via internet vrij toegankelijk. Ook zijn er diverse boeken geschreven die zowel via de website als via boekhandels verkrijgbaar zijn [The Open Group, 2011]. Extra faciliteiten zijn er voor leden van de gebruikergroep, het Architecture Forum. Lidmaatschap van dit forum is tevens de weg voor het aandragen van wijzigingen of uitbreidingen op de methode.

The Open Group streeft naar standaardisering van de kennis en vaardigheden van architecten. Daartoe bestaat de mogelijkheid voor architecten om zich te certificeren via het volgen van trainingen en het afleggen van examens. Was een TOGAF

8-certificering nog te halen door alleen het volgen van een uitgebreide training, vanaf TOGAF 9 is het afleggen van een examen verplicht gesteld. Trainingen zijn te volgen bij diverse trainingsinstanties wereldwijd. Vaardigheden kunnen via een ander programma worden gecertificeerd.

Er verschijnen regelmatig nieuwe versies van de methode. De actuele versie is versie 9.1, deze is eind 2011 uitgekomen. Daarnaast wordt aanvullend materiaal, zoals whitepapers en casusbeschrijvingen, op de website gepubliceerd.

Beheer- en exploitatiewijze gebruiker

In de eerste, voorbereidende fase van de Architecture Development Method besteedt TOGAF aandacht aan het toespitsen van de methode op de organisatie. Het is dus mogelijk om de methode naar eigen behoefte aan te passen, dit is zelfs onderdeel van de methode. In fase H, beheer van de architectuur, komt het beheren van de (naar eigen wensen aangepaste) methode aan bod.

Hoewel de methode op deze punten goede ondersteuning biedt, blijft er voor de gebruiker nog veel over om zelf te bepalen. Denk daarbij aan het kiezen van ondersteunende tooling, modelleertechnieken en presentatiewijzen. Voor het implementeren van TOGAF biedt de methode wel diverse richtlijnen en dergelijke, gebaseerd op best practices.

Werkwijze

TOGAF is een zeer gestructureerde, haast mechanistisch beschreven methode om vanuit een holistische aanpak en op iteratieve wijze een architectuur op te stellen, te beheren en te implementeren. In tegenstelling tot de precisie waarmee de methode beschreven is, biedt deze verrassend veel flexibiliteit en openheid ten aanzien van de invulling van de diverse stappen in de methode. De methode is daardoor voor iedereen bruikbaar, maar niet voordat de methode organisatiespecifiek is gemaakt. Dat organisatiespecifiek maken betreft dan ondermeer het kiezen van tooling, modelleerwijzen en presentatievormen.

Representatie- en modelleerwijze

Ook op dit vlak schrijft TOGAF niets voor, maar biedt de gebruiker juist de mogelijkheid te kiezen voor eigen middelen. In veel gevallen grijpt men naar standaarden zoals ArchiMate, UML of BPMN. Dergelijke standaarden worden doorgaans ook gebruikt in de voorbeelden, best practices en casusbeschrijvingen die TOGAF als ondersteunend materiaal biedt.

Ondersteuningswijze

TOGAF schrijft geen vaste technieken, modelleerwijzen of tools voor, maar laat die keuzes juist aan de gebruiker. Voor het maken van dergelijke keuzes is de voorbereidende fase in de ADM bedoeld. Er zijn diverse architectuurtools verkrijgbaar die TOGAF in meerdere of mindere mate ondersteunen, veelal zonder dat expliciet aan te geven.

Bruikbaarheid

TOGAF wordt inmiddels door vele duizenden organisaties in meer of mindere mate gebruikt. Er zijn zo’n tweehonderd organisaties lid van het Architecture Forum.

De procesmethode ADM is veelomvattend. Daardoor ontstaat het risico dat architectuurtrajecten veel tijd kosten en dikke rapporten opleveren die door hun omvang niet meer bruikbaar zijn. Het is dus zaak de methode toe te passen in overeenstemming met de grootte en (architectuur)volwassenheid van de organisatie. TOGAF biedt die mogelijkheid doordat het doel van de verschillende onderdelen en hun onderlinge afhankelijkheden duidelijk worden gemaakt, zodat een organisatie goed kan inschatten welke onderdelen in hun situatie essentieel zijn of wat de consequenties zijn van het niet doen van bepaalde activiteiten. Daardoor is TOGAF bruikbaar voor een grote diversiteit aan organisaties.

Bijzonder praktisch is de systematische beschrijving van de activiteiten en producten van de ADM. Bij de activiteiten wordt telkens aangegeven wat het doel ervan is, welke producten als input benodigd zijn en welke als output geproduceerd worden. Dat ondersteunt architecten bij het plannen van hun werk en maakt het bovendien heel eenvoudig om specifieke activiteiten volgens een andere methode uit te voeren. Daardoor kunnen methoden en technieken die in de organisatie al bekend of om andere redenen gewenst zijn, gemakkelijk in TOGAF geïntegreerd worden. Ook het architecture content framework met zijn producten, artefacten en bouwstenen biedt houvast voor architecten.

Omdat TOGAF wijd verspreid is en veel gebruikt wordt, is de methode bij veel architecten bekend. Dat is een voordeel, want het vergemakkelijkt de communicatie over architectuur tussen afdelingen en/of organisaties. Ook wordt bijvoorbeeld het inhuren van externe architecten of consultants eenvoudiger, omdat de betreffende expertise ruim voorhanden is. Deze voordelen versterken weer de positie van TOGAF, waardoor dit raamwerk vaker gekozen zal worden door organisaties. De systematische en procesmatige opzet van TOGAF maakt de methode geschikt om te gebruiken in een omgeving waar meerdere mensen of afdelingen samenwerken, maar niet altijd op dezelfde tijd of plaats. Het werk is goed te verdelen in concrete ‘werkpakketten’, waarbij het voor een ieder duidelijk is wat van hem of haar verwacht wordt en waar de aansluiting zit met het werk van collega’s. Daardoor kunnen ook minder ervaren architecten volop meewerken aan het opstellen en beheren van de architectuur. Naast een methode voor het opstellen van de architectuur biedt TOGAF ook handvatten voor het implementeren en beheren van de architectuur als die eenmaal is ontwikkeld. De procesmethode van TOGAF is vooral gericht op het ‘ontwerpen’ van een architectuur en het implementeren daarvan in de vorm van een of meer systemen. TOGAF is daarom vooral geschikt voor organisaties die deze methode willen gebruiken als een ontwerp- en realisatie-instrument. De methode is minder geschikt voor organisaties die een bestaande enterprise-architectuur willen gebruiken als een managementinstrument, werkend vanuit een portfoliomanagementbenadering, zonder directe link met systeemontwikkeling.

De score van TOGAF in het vergelijkingsmodel is hoog op de meeste aspecten. De bekendheid van de methode draagt daaraan bij. Sterk scoort met name de beheer- en exploitatiewijze door eigenaar The Open Group. De zwakste schakel in de TOGAF- score is de representatie- en modelleerwijze. Dat is de keerzijde van de flexibiliteit die TOGAF op dit vlak biedt. Omdat er niets voorgeschreven wordt, moet de gebruiker hier zelf zijn weg zoeken. Al met al scoort TOGAF desalniettemin als een goede en complete methode.