Een volgende stap in de ontwikkeling van architectuur

Danny Greefhorst, maandag 02 februari 2009

TOGAF in vogelvlucht

Er zijn de afgelopen tien jaar veel architectuurmethoden, technieken en raamwerken verschenen. Veel van deze methoden en technieken zijn afkomstig van adviesorganisaties en niet publiek beschikbaar. Er is echter een duidelijke trend naar open standaarden en TOGAF en ArchiMate zijn daarvan goede voorbeelden. In dit artikel wordt een overzicht gegeven van TOGAF, waarbij met name wordt ingegaan op TOGAF 9. Aanleiding is de publicatie ervan op 2 februari 2009 op de Open Group conferentie in San Diego.

Inleiding

Het enterprise architectuur vakgebied is nog relatief jong en de afgelopen 10 jaar is er veel gebeurd. Recentelijk nog is het tiende Landelijk Architectuur Congres gehouden. Het is een belangrijke constatering dat het vakgebied nog steeds in ontwikkeling is en dat we het nog lang niet met elkaar eens zijn. Met name adviesorganisaties zijn debet aan deze babylonische spraakverwarring, gemanifesteerd onder kreten als “Integrated Architecture Framework”, “Dynamische Architectuur”, “MArch”, “Generic Enterprise Model” en “Business Informatie Planning”. Waakzaamheid is geboden zodat deze onenigheid de geloofwaardigheid van architectuur niet aantast. Architectuur is immers een belangrijk hulpmiddel voor organisaties om structuur te geven aan veranderingen en architecten zijn er vooral om organisaties te helpen met hun kennis en ervaring. In de huidige praktijk wordt architectuur nog te veel tot doel op zich verheven, terwijl architectuur uiteindelijk alleen maar een middel is om de doelen van de organisatie te bereiken. Er zou meer gestreefd moeten worden naar een pragmatische en doelgerichte aanpak van architectuur.

Gegeven de bovenstaande ontwikkelingen is het belangrijk om te constateren dat er ook een aantal initiatieven op het vakgebied zijn die duidelijk bijdragen aan convergentie. Initiatieven die werken aan samenwerking, informatie-uitwisseling en professionalisering van architecten. Denk daarbij aan initiatieven zoals de Open Group, het Nederlands Architectuur Forum, Via Nova Architectura, het Genootschap voor Informatie Architecten en het Nederlands Genootschap voor Informatici. Niet onbelangrijker is dat er een aantal standaarden zijn ontstaan zoals IEEE/ANSI 1471 [IEEE, 2000], ArchiMate [Lankhorst, 2005] en TOGAF [Open Group, 2006] waardoor terminologie, notatie en methoden worden gestandaardiseerd. Dit artikel gaat met name in op TOGAF omdat dat een belangrijk convergentiepunt lijkt te worden voor architectuur. Aanleiding voor dit artikel is het verschijnen van versie 9 van TOGAF [Open Group, 2009] waarin een aantal belangrijke verbeteringen zijn doorgevoerd. Het artikel zal dan ook expliciet aandacht besteden aan de veranderingen in deze versie van TOGAF. Voor de mensen die nog niet bekend zijn met TOGAF geef ik eerst een kort overzicht van TOGAF 8.

TOGAF 8

TOGAF staat voor “The Open Group Architecture Framework” en is feitelijk een verzameling van methoden, technieken en best-practices op het gebied van enterprise architectuur. In tegenstelling tot wat de naam “framework” doet vermoeden ligt de nadruk daarbij niet zozeer op de architectuurinhoud zelf, maar vooral op het organiseren en procesmatig ondersteunen van architectuur. TOGAF versie 8 bouwt voort op eerdere versies van TOGAF die teruggaan tot 1994. Nieuw in versie 8 is de uitgebreidere aandacht voor bedrijfs- en informatiesysteem architectuur. In voorgaande versies lag de nadruk nogal op de technologie architectuur. Dit is voor een belangrijk deel te verklaren door de ontstaansgeschiedenis van de Open Group. Deze heeft zicht in het verleden vooral bezig gehouden met technische standaarden zoals bijvoorbeeld de DCE standaard voor gedistribueerde systemen. Enterprise architectuur in de brede zin kan echter niet beperkt zijn tot IT alleen.

TOGAF 8 bestaat uit vier delen:

  • Deel 1 (Introduction) is de inleiding en geeft een overzicht van TOGAF;
  • Deel 2 (Architecture Development Method) beschrijft de architectuurmethode;
  • Deel 3 (Enterprise Continuum) beschrijft een classificatie van architecturen en oplossingen;
  • Deel 4 (Resource Base) bevat een verzameling van architectuur best-practices.

Het belangrijkste van TOGAF is eigenlijk de architectuurmethode, temeer omdat andere methoden en raamwerken hier veel minder expliciet in zijn. Deze methode biedt een stappenplan waarin is aangegeven welke activiteiten moeten worden uitgevoerd en wat hun invoer en uitvoer is. De methode geeft niet in detail aan welke inhoudelijke architectuurmodellen moeten worden gemaakt. Er worden wel op allerlei plaatsen suggesties gedaan, waarbij frequent wordt gerefereerd aan het Zachman framework [Zachman, 1987]. Ik zie de methode vooral als een handige checklist; het tot op de letter volgen van de methode leidt niet tot een pragmatische aanpak. Zoek naar wat past bij de gestelde doelen.


Afbeelding 1 Architecture Development Method

In Afbeelding 1 is de architectuurmethode grafisch weergegeven. De methode start met het bepalen van de wijze waarop de methode wordt aangepast aan de organisatie en waarin de organisatie wordt ingericht. Ook worden in deze preliminary fase de architectuurprincipes opgesteld die richting geven aan alle vervolgfasen. In de architecture vision fase wordt de architectuur op hoofdlijnen bepaald, waarbij vooral gebruik gemaakt wordt van een scenario-gebaseerde werkwijze (business scenarios). Dit levert tevens de belangrijkste eisen die worden gesteld aan de architectuur. In de business architecture fase worden de bedrijfsaspecten beschreven, wat resulteert in een set van bouwblokken (building blocks) en views die de architectuur beschrijven. In de information systems architecture fase worden de data architecture en de application architecture beschreven. De volgorde is afhankelijk van de specifieke context, maar typisch worden in de data architecture op hoofdlijnen de applicaties geïdentificeerd, en worden deze in de application architecture verder uitgewerkt. Resultaat zijn wederom een verzameling bouwblokken en views. In de technology architecture fase wordt de vertaling gemaakt naar de technologie. Hier spelen standaarden een belangrijke rol; deze geven richting aan de uiteindelijke vertaling van architectuurbouwblokken naar oplossingsbouwblokken. In de opportunities and solutions fase wordt de architectuur vertaald naar een verzameling projecten en worden oplossingsbouwblokken gezocht bij de architectuurbouwblokken. In de migration planning fase worden de projecten geprioriteerd en gepland in tijd. In de implementation governance fase wordt de architectuur vertaald naar richtlijnen voor projecten, worden contracten afgesloten met de projecten en worden de projecten begeleid. In de architecture change management fase worden allerlei ontwikkelingen bewaakt en vertaald naar wijzigingen op de architectuur. Deze kunnen leiden tot kleine aanpassingen of tot een nieuwe cyclus van de methode. De requirements management fase staat centraal in alle processen en is de plaats waar alle eisen die aan de architectuur worden gesteld worden beheerd.

Het enterprise continuum beschrijft dat er architecturen en oplossingen op allerlei niveau’s bestaan. Dit continuum bestaat op zijn beurt weer uit een architecture continuum (Afbeelding 2) en een solution continuum. De belangrijkste boodschap daarbij is dat er niet alleen organisatie-specifieke architecturen zijn (organisation architecture), maar ook meer generieke en herbruikbare architecturen. Deze kunnen specifiek zijn voor een bepaalde sector (industry architecture), maar ook sector-onafhankelijk (common systems architecture). In het meest extreme geval is het een generieke classificatie van elementen en spreekt TOGAF over een foundation architecture. Voor elk van deze vormen van architectuur zijn er ook oplossingen die deze architecturen ondersteunen, bijvoorbeeld een standaard softwarepakket voor een specifieke sector. Andersom geredeneerd geven de architecturen richting aan de oplossingen. Het enterprise continuum biedt feitelijk een classificatie van architecturen en oplossingen die je zou kunnen gebruiken voor het organiseren van een architectuurrepository. TOGAF spreekt over een virtual repository.


Afbeelding 2 Architecture Continuum

De resource base beschrijft een aantal best-practices op het gebied van architectuur. Er zijn twee belangrijke groepen van hoofdstukken in deze resource base. De eerste groep heeft met name betrekking op de inrichting van architectuur in de organisatie. Hier lees je over wat architectuur governance is, hoe je een architectuur board inricht, welke competenties architecten zouden moeten hebben en hoe om te gaan met architectuur compliance en architectuurcontracten. De andere groep gaat meer in op architectuurmodellen zelf. Zo geeft het een goed beeld van wat architectuurprincipes zijn en geeft het hiervoor een goede startset. Daarnaast gaat het in op wat architectuurviews zijn en geeft het een beeld van de issues die in deze views geadresseerd zouden moeten worden. Zoals eerder aangegeven blijft het daarbij in het midden wat er dan precies in een view staat. Ook lijkt de tekst op een aantal plaatsen niet echt bijgewerkt op nieuwe inzichten.

TOGAF 9

Op 2 februari 2009 is TOGAF 9 aangekondigd op de Open Group conferentie in San Diego. Deze nieuwe versie van TOGAF blijkt een aantal belangrijke verbeteringen te zijn ondergaan ten opzichte van de vorige versie. We zullen in dit artikel ingaan op de veranderingen. Ervan uitgaande dat dit je nieuwsgierigheid heeft opgewekt verwijs ik graag naar de web-site van de Open Group voor de details (http://www.opengroup.org/). Dit is een belangrijk voordeel van TOGAF; het is gratis beschikbaar en als organisatie kun je ook meehelpen aan het verder verbeteren van TOGAF.

De eerste belangrijke verbetering is in de structuur van TOGAF (zie Afbeelding 3). Er zijn een aantal nieuwe delen gedefinieerd die een duidelijker herkenbare inhoud hebben en die ook los van de andere delen kunnen evolueren. Zo zijn de tips en technieken voor het inrichten van de methode in een separaat deel terecht gekomen, alsook best-practices rondom het inrichten van architectuur in een organisatie. Ook de referentie architecturen hebben een eigen deel gekregen. Een geheel nieuw deel is het content framework waar we in de volgende paragraaf dieper op in zullen gaan. Verder zijn ook de relaties tussen de verschillende delen inzichtelijker gemaakt wat bijdraagt aan een beter begrip van de architectuur van TOGAF.


Afbeelding 3 Inhoudsopgave van TOGAF 9

Verreweg de belangrijkste toevoeging is het content framework dat definieert waar een architectuur feitelijk uit bestaat. Zoals eerder in dit artikel aangegeven was dit een erg zwak punt in de vorige versie. Eigenlijk werd niet goed duidelijk welke specifieke modellen en views je moet maken op een specifiek moment en wat daarvan de precieze inhoud is. Ook was het onvoldoende helder wat de precieze invoer en uitvoer van fasen en stappen in de methode was. Oorzaak daarvan is ondermeer een inconsistent taalgebruik, onduidelijke definities en onvolledigheden.

Het content framework

Laten we eens kijken wat de belangrijkste onderdelen zijn van het content framework. Afbeelding 4 geeft een overzicht van deze onderdelen en hun relatie. De eenheden die formeel worden opgeleverd in een architectuurtraject zijn deliverables. Denk daarbij aan documenten waar de opdrachtgever ook zijn handtekening op zet. Deze deliverables bestaan op hun beurt weer uit artefacten. Dit zijn individuele modellen die zich kunnen manifesteren als een diagram, maar ook als een lijst (catalog) of matrix. In deze structuur zien we al snel de oorsprong van het content framework terugkomen; het Integrated Architecture Framework (IAF) van Capgemini. In deze aanpak wordt namelijk veel gewerkt met matrices die de relaties tussen allerlei architectuurelementen aangeven en daarmee een stuk traceerbaarheid bewerkstelligen. Artefacten beschrijven bouwblokken; de eenheden waarin architectuurelementen worden gedefinieerd. Dit was in de vorige versie een nogal abstract begrip. In versie 9 wordt het duidelijker; een bouwblok is een concept in het architectuur metamodel (zie volgende paragraaf) en kan daarmee feitelijk heel veel verschillende dingen zijn. Het zijn de eenheden die je registreert in je architectuurrepository; een begrip dat ook in deze versie is toegevoegd. Daarmee is het wel weer zo’n algemeen begrip dat je je afvraagt waarom er zoveel ophef over wordt gemaakt; er is immers wel weer een heel hoofdstuk over.


Afbeelding 4 Bouwblokken, artefacten en deliverables

De basis voor het content framework is het content metamodel waarin alle relevante concepten zijn gedefinieerd, inclusief hun relatie (zie Afbeelding 5). Voor alle architectuurdomeinen zijn deze concepten uitgewerkt en wordt zelfs een voorzet gegeven voor de relevante attributen die je in een architectuurrepository zou willen administreren. Ook in het metamodel herkennen we heel duidelijk het IAF raamwerk van Capgemini. Het is lovenswaardig dat Capgemini zoveel van zijn eigen intellectual capital in TOGAF heeft verwerkt. Ik vind het wel jammer dat hiermee tegelijk een concurrerend begrippenkader voor ArchiMate in TOGAF is opgenomen. Deze enterprise architectuurtaal was juist afgelopen jaar geadopteerd door de Open Group. De hoop is dat een volgende versie van TOGAF alle verschillen tussen ArchiMate en het TOGAF metamodel zijn gladgestreken. Gelukkig zit er in ieder geval geen notatie in TOGAF, zodat daar in ieder geval niet in gedivergeerd wordt.


Afbeelding 5 Content metamodel (bouwblokken)

Wat verder opvalt in het metamodel is dat er gekozen is voor een gelaagde structuur. Zo is er een basismetamodel waar alle kernbegrippen in voorkomen en zijn er specifieke uitbreidingen voor gebieden zoals motivatie, infrastructuur, governance, procesmodellering, data modellering en service oriëntatie. Alhoewel het doel van een aantal concepten daarmee wel helderder wordt vind ik het ook wat kunstmatig om deze opdeling aan te brengen. Uiteindelijk is het één geïntegreerd metamodel. Ook vind ik het bijvoorbeeld merkwaardig dat een begrip als business service feitelijk ook de semantiek van een application system service heeft als je de service oriëntatie extensie niet gebruikt. Alsof een concept van betekenis kan veranderen. Om nog maar niet te spreken over een vreemde inconsistentie van naamgeving; waarom levert een logical application component niet gewoon een application service?

Een ander belangrijk deel van het content framework is de definitie van artefacten. Daarbij wordt verwezen naar het IEEE model en worden artefacten gelijk gesteld aan views. Eerder gaven we al aan dat er drie soorten artefacten zijn: diagrammen, matrices en lijsten. Dit zien we ook terug in de lijst van voorgedefinieerde artefacten (zie Afbeelding 6). Deze lijst (of framework) is wederom een sterke verbetering van de lijst van views zoals gedefinieerd in TOGAF 8. Die waren niet helder gedefinieerd. Voor alle artefacten in TOGAF 9 is een alinea met tekst waarin helder wordt wat het doel is van het artefact en waar het uit bestaat. In de verschillende fasen en stappen van de architectuurmethode wordt ook expliciet gerefereerd aan deze artefacten, waardoor de methode een veel betere basis krijgt. Jammer is dat deze artefacten afwijken van de viewpoints in ArchiMate. Ook is het vreemd dat in de tekst nog steeds wordt ingegaan op een aantal viewpoints in TOGAF 8 die geen plaats hebben in Afbeelding 6 zoals bijvoorbeeld de system engineering view.


Afbeelding 6 Artefacten

De deliverables worden veel beter gedefinieerd in TOGAF 9. Een aantal begrippen die duidelijk ontbraken zijn daarin toegevoegd zoals bijvoorbeeld architecture definition document, architecture repository en architecture requirements specification. De deliverables zijn de invoer en uitvoer van de fasen en stappen in de methode. Door een betere definitie van de deliverables wordt de methode ook begrijpelijker. Zo waren bijvoorbeeld de requirements in TOGAF 8 nogal impliciet aanwezig en onduidelijk gepositioneerd.

Partitionering van architecturen

Een belangrijke toevoeging in TOGAF 9 is een verder onderscheid in soorten architecturen. Er is onderkend dat er in een typische organisatie allerlei architecturen bestaan en dat je vantevoren goed moet nadenken over welke architecturen je wilt onderscheiden en welke relaties deze met elkaar hebben. TOGAF noemt dat het partitioneren van architectuur en daar is een heel hoofdstuk aan gewijd. Daarin worden ondermeer de belangrijkste dimensies geïdentificeerd op basis waarvan je zou willen partitioneren: het onderwerp, het viewpoint, het detailniveau, het abstractieniveau en de accuraatheid. Ook wordt aangegeven hoe deze dimensies kunnen worden gehanteerd bij het onderverdelen van het architectuurlandschap (architecture landscape). Dit laatste is overigens ook een nieuw begrip in TOGAF 9 wat zoveel betekent als de architectuurniveau representatie van de organisatie. De typische vormen van architectuur die je kunt onderkennen zijn weergegeven in Afbeelding 7. Hierin wordt een onderscheid gemaakt tussen strategic architectures, segment architectures en capability architectures, die zich vooral onderscheiden qua detailniveau. Strategic architectures beschrijven op hoog niveau de gehele organisatie. Segment architectures gaan in op specifieke inhoudelijke deelgebieden. Capability architectures zijn architecturen voor een specifieke oplossing. Het is onduidelijk waarom niet meer gangbare termen als “enterprise architecture” , “domain architecture” en “solution architecture” worden gehanteerd.


Afbeelding 7 Partitionering van het architectuurlandschap

Partitionering heeft niet alleen betrekking op het architectuurlandschap, maar ook op referentie architecturen. Dit is feitelijk het architecture continuum zoals we het al kenden vanuit TOGAF 8, alleen wordt nu aangegeven dat dit reference models zijn (er wordt in de tekst ook wel over reference architectures gesproken). Interessant is dat gesteld wordt dat ook organisation-specific architectures in die categorie vallen. Daarmee is er in TOGAF een veel duidelijker onderscheid tussen architecturen met hele specifieke keuzen (strategic, segment en capability) en herbruikbare referentie architecturen (foundation, common systems, industry, organisation-specific) ontstaan. Dit onderscheid zie je ook terug in het hoofdstuk dat in gaat op wat een architectuurrepository is. Deze repository bevat beide categorieën van architecturen (zie Afbeelding 8).


Afbeelding 8 Architectuurrepository

Overigens zit er in deze repository eigenlijk alle voor architectuur relevante informatie zoals het metamodel, de standaarden (standards information base), governance gerelateerde informatie zoals besluiten, alsook informatie over de inrichting van architectuur in de organisatie. Er wordt in TOGAF 9 dus niet langer over het enterprise continuum gesproken als een virtual repository; in plaats daarvan hebben we een echte architectuurrepository. Deze repository staat centraal in alle fasen en activiteiten; resultaten worden er in opgeslagen en in vervolgfasen hergebruikt.

Vernieuwingen in de architectuurmethode

De architectuurmethode zelf is vrij stabiel gebleven. Op het hoogste niveau is deze feitelijk ongewijzigd. De aanpassingen zitten wat dieper onder deze structuur. De belangrijkste verbetering is de onderbouwing van de fasen en stappen met zaken uit het content framework. Een andere belangrijke verbetering is een gelijk stappenplan voor alle architectuur domeinfasen (business, data, application en technology). De stappen in al deze fasen zijn nu:

  1. Selecteren van referentiemodellen, viewpoints en tools
  2. Het ontwikkelen van de baseline architectuur
  3. Het ontwikkelen van de target architectuur
  4. Het uitvoeren van een gap analyse (verschil tussen baseline en target)
  5. Het definiëren van een roadmap van componenten
  6. De impact op andere delen van het architectuurlandschap bepalen
  7. Een review door relevante betrokkenen uitvoeren
  8. Het afronden van de architectuur
  9. Het opstellen van het architectuurdefinitie document

Daarnaast is de tekst zelf verder verrijkt en wordt je dus beter geholpen in het uitvoeren van de architectuurmethode. Uitbreidingen zitten met name in de preliminary fase en de opportunities & solutions fase.

Richtlijnen en technieken voor de architectuurmethode

Alhoewel de methode zelf dus niet echt is veranderd is er wel een heel nieuwe deel bijgekomen waarin richtlijnen en technieken worden gegeven die kunnen worden toegepast in de architectuurmethode. Hier staan een aantal bekende hoofdstukken in zoals die met architectuurprincipes en business scenarios, maar er zijn ook een aantal geheel nieuwe hoofdstukken.

Wat opvalt is dat het takenpakket van de architect breder lijkt te worden. We zien een aantal technieken die voor project managers al erg bekend zijn zoals stakeholder management en risico management. Het is ook als architect natuurlijk belangrijk om te weten wat hoe je met betrokkenen en met risico’s moet om gaan. Ook zien we technieken die in het verleden meer het werkgebied van business consultants was. Zo is er een soort van organisatie assessment aanpak opgenomen in TOGAF: de business transformation readiness assessment. Het idee ervan is dat je voordat je overgaat tot het implementeren van veranderingen een goed beeld hebt in hoeverre een organisatie klaar is voor de veranderingen. De aanpak gaat uit van factoren die de veranderbereidheid (readiness) van een organisatie bepalen. Deze factoren moeten worden bepaald en uitgewerkt, waarna de feitelijke scoring wordt uitgevoerd. Op basis van de scoring bepaal je de noodzakelijke acties en vertaal je deze naar een migratieplan. Ook de techniek van capability based planning is een uitgebreidere, meer strategische blik op de rol van de architect. Het is een andere manier om te kijken naar veranderingen die nodig zijn in een organisatie. Het idee is om zogenaamde capabilities te definiëren die door de hele organisatie heen snijden, maar fundamenteel zijn om de doelen van de organisatie te bereiken. Denk daarbij bijvoorbeeld aan Sarbanes-Oxley Compliance. De resulterende capabilities zijn een alternatieve bron van input voor de architectuurmethode. Het is een interessant idee om meer vanuit capabilities naar een organisatie te kijken. Het wordt het alleen niet echt duidelijk hoe je tot de juiste capabilities komt.

Er worden een aantal technieken besproken die erg dicht op de architectuurmethode zelf zitten. Zo wordt de architect allerlei technieken aangereikt die helpen bij het uitvoeren van migratie planning. In het bijzonder vind je allerlei soorten matrices die je kunt definiëren en die je inzicht geven in de stappen die moeten worden gezet, wanneer ze moeten worden gezet en hoe de architectuur evolueert in tijd. Projecten moet je afzetten tegen de waarde die ze leveren en de risico’s die ermee geassocieerd zijn. Op basis daarvan kan worden bepaald of projecten moeten worden doorgezet. De architect wordt ook geholpen bij het bepalen van de precieze iteraties in de architectuurmethode, wat één van de belangrijkste kenmerken ervan is. Globaal wordt een onderscheid gemaakt tussen baseline first en target first. Dit geeft aan of je met de huidige of gewenste situatie start en wat daarvan de impact is op de verschillende fasen in de architectuurmethode. Een iteratieve aanpak voor architectuur is mijn inziens essentieel om deze pragmatisch te houden; het zorgt ervoor dat je snel met resultaten kunt komen en snel inzicht krijgt in de gebieden die verdere verdieping vragen.

TOGAF 9 geeft nu inzicht in de soorten architectuurprojecten (architecture engagements) die je kunt uitvoeren. Daarbij worden drie fundamentele klassen onderkend: het identificeren van veranderingen, het definiëren van veranderingen en het implementeren van veranderingen. Hierin wordt duidelijk dat architectuur zich kan bewegen van strategisch tot operationeel niveau. Dit heeft een duidelijke relatie met de soort architecturen (strategic, segment, capability) en de iteratieaanpak die wordt gekozen.

Specifieke gebieden die voor architecten erg belangrijk zijn worden verder uitgewerkt. Een belangrijk gebied voor architecten is security. In een separaat hoofdstuk wordt ingegaan op security architectuur en de relatie die dat heeft met de verschillende fasen in de architectuurmethode. Zo worden per fase beschreven welke activiteiten relevant zijn en welke security gerelateerde invoer en uitvoer relevant is.

Een ander belangrijk gebied voor architecten is applicatie-integratie. De basis hiervoor zijn de eisen die eraan gesteld worden; interoperability requirements. We leren dat er verschillende soorten interoperability requirements bestaan; bijvoorbeeld op verschillende lagen van een applicatie. Daarnaast wordt een techniek aangereikt waarbij de uitwisseling tussen partijen wordt geclassificeerd op basis van de mate van integratie. De resulterende matrix lijkt wel wat kunstmatig.

De service-georiënteerde invalshoek is een separaat hoofdstuk beschreven. Dit gaat ondermeer in op het onderscheid tussen business-led SOA en developer-led SOA. Er wordt aangegeven wat er in de verschillende fasen aan SOA gerelateerde aandachtspunten zouden moeten worden opgepakt. Tenslotte wordt vrij uitgebreid stilgestaan bij het concept service-contract; een manier om afspraken tussen aanbieders en afnemers van services te formaliseren.

Overige veranderingen

Meer kleinschalige aanpassingen aan TOGAF zijn de toevoeging van een document categorization model waarin wordt aangegeven hoe de verschillende delen van TOGAF los van elkaar evolueren en wat de status ervan is. Ook is er nu een uitgebreidere lijst van definities van begrippen.

Er zijn ook zaken verwijderd uit TOGAF zoals de beschrijving hoe om te gaan met het ontwikkelen van views, de standards information base, de case studies en de relatie met andere raamwerken. Verder zijn er ook veel hoofdstukken (vrijwel) ongewijzigd zoals de hoofdstukken over requirements management, architectuurprincipes, architectuurpatronen, business scenarios, tools, het technical reference model, het Integrated Information Infrastructure Reference Model en veel van de hoofdstukken over de organisatie van architectuur, die nu in het architecture capability framework terecht is gekomen.

De certificatie van TOGAF 9 verdient ook aandacht. Architecten die TOGAF 8 gecertificeerd zijn, zijn niet automatisch ook TOGAF 9 gecertificeerd. Zij moeten opnieuw examen doen. Zij hebben wel het voordeel dat dit open boek mag. Voor de nieuwkomers is er nu een onderscheid tussen level 1 en level 2 certificering, waarbij voor de tweede ook een zwaarder examen geldt.

Conclusies

Ik heb in dit artikel een overzicht gegeven van TOGAF, waarbij ik met name ben ingegaan op de nieuwe inhoud van TOGAF 9. Het is duidelijk dat TOGAF 9 een meer volwassen aanpak biedt voor architectuur. Er zijn veel nieuwe zaken toegevoegd en de methode is een stuk beter onderbouwd, waardoor het een veel beter fundament heeft. Dit alles maakt TOGAF 9 tot een serieus raamwerk waarin iedere professionele architect eigenlijk zou moeten zijn gecertificeerd.

Natuurlijk zijn er ook nog zaken op te merken aan TOGAF 9; als architect ben je nu eenmaal kritisch. De belangrijkste omissie is dat het content framework nog niet in lijn is met ArchiMate. Ik kan dan ook niet wachten tot ArchiMate geïntegreerd is in TOGAF. Daarnaast vind ik dat er toch ook nog veel oude inhoud te vinden is die eigenlijk niet meer in lijn is met de nieuwe delen van TOGAF. Ik hoop dan ook dat deze delen er in een volgende versie gewoon uit zijn. Tenslotte zou ik graag meer ondersteuning zien in het maken van specifieke architectuurinhoud.

Danny Greefhorst ( dgreefhorst@archixl.nl) is algemeen directeur van ArchiXL en werkzaam als IT-architect voor klanten in de financiële en publieke sector.

Referenties

[IEEE, 2000] IEEE Std 1471-2000: “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”, 2000.
[Open Group, 2006] Open Group: “The Open Group Architecture Framework”, version 8.1.1., ISBN: 1-931624-62-3, 2006.
[Open Group, 2009] Open Group: “The Open Group Architecture Framework”, version 9, ISBN: 9789087532307, 2009.
[Lankhorst, 2005] M.M. Lankhorst et al.: “Enterprise Architecture at Work”, Springer, 2005. ISBN 3-540-24371-2.
[Zachman, 1987] J.A. Zachman: “A framework for information systems architecture”, IBM Systems Journal 1987.

[PDF]
 

Opmerking

Je moet lid zijn van Via Nova Architectura om reacties te kunnen toevoegen!

Wordt lid van Via Nova Architectura

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Daan Rijsenbrij op 03-02-2009 14:00

Danny,

Knap, dat jij zo snel na 2 februari 2009 zoveel pagina's hebt kunnen beoordelen.
Bij het lezen van jouw artikel krijg ik het gevoel dat ik te maken heb met een 'gelovige', zeg maar een aanbidder van TOGAF. Als ik de tijd heb gevonden om een wetenschappelijk verantwoorde analyse uit te voeren op die ruim 700 pagina’s, zal ik je een uitgebreide reactie geven.

In een van de laatste zinnen stel jij: ‘Dit alles maakt TOGAF 9 tot een serieus raamwerk waarin iedere professionele architect eigenlijk zou moeten zijn gecertificeerd’. Ik kies er doelbewust voor om in jouw ogen als zijnde ‘niet-professioneel’ door het leven te gaan. Ik geloof (nog) niet in de certificatie van architecten, laat staan in het certificeren op grond van het uit je hoofd leren van een boekwerk.

Groetjes,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Danny Greefhorst op 03-02-2009 21:22

Beste Daan,

Als lid van de Open Group had ik al eerder inzicht in de inhoud. Ik hoop dat ik in het artikel duidelijk heb kunnen maken dat ik ook wel wat kritische noten heb. Ik vind TOGAF echter een belangrijke beweging op architectuurgebied die je simpelweg niet kunt negeren. TOGAF certificatie is geen garantie dat je een goede architect bent. Het geeft echter wel een zeker basisniveau aan. Voor TOGAF 9 is er nu ook een onderscheid tussen en Foundation en Certified niveau van certificatie, waarbij de tweede ook nadrukkelijker kijkt naar toepassing van de methode. Uiteindelijk denk ik dat certificatie de enige route is om tot een volwassen vakgebied te komen waarin het transparant wordt wat je van iemand kunt verwachten. Ik ben met je eens dat de bestaande certificaties nog niet ideaal zijn.

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Peter Bakker op 04-02-2009 15:56

Orville Wright did not have a pilot's license.
(Gordon MacKenzie)

Certificering is een commerciele uitvinding en funest voor creativiteit en innovatie....

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Danny Greefhorst op 04-02-2009 19:41

Beste Peter,

Ik vind je nogal zwart/wit. Ik denk dat certificering transparant maakt wat iemand weet en kan. Neemt niet weg dat je niet dogmatisch een methode moet gaan hanteren. Daar ben ik een sterke tegenstander van; je moet vooral doelmatig en pragmatisch blijven!

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Peter Bakker op 04-02-2009 22:45

Beste Danny,

Ik ben niet zwart/wit, hooguit zwartgallig :-)

Ik denk niet dat een certificaat bepaald wat iemand kan. Het bepaald alleen dat hij/zij een bepaald leertraject op een juiste wijze heeft afgesloten. En dat leertraject heeft per definitie altijd te maken met bestaande kennis (best practices/consensus) over hoe je dingen zou moeten doen, over gebaande paden.
Echte vernieuwing en innovatie onstaat juist door buiten gebaande paden te treden, anders te denken, te leren met vallen en opstaan (of in het geval van de gebroeders Wright met opstijgen en neerstorten).

Het is frappant dat vaak van architecten in de echte wereld wordt verwacht dat zij op creatieve wijze komen tot verassende realiseerbare ontwerpen en modellen terwijl van de virtuele architecten wordt verwacht dat zij zich houden aan een strak keurslijf van methodieken. En dat ze uiteindelijk op de proppen komen met saaie diagrammen en langdradige opsommingen van principes en richtlijnen. Ik zou graag zien dat er ook binnen de virtuele architectuur meer ruimte komt voor creativiteit en het af en toe eens buiten de gebaande paden treden. Om zo hopelijk een steentje bij te dragen aan echte innovatie...

Peter

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Jaap van Rees op 04-02-2009 23:32

Beste Danny en anderen,

Dit kan een discussie worden die mij wel aanspreekt!
Mag ik een ieder die in dit onderwerp geïnteresseerd is het geweldige boek The Craftsman van Richard Sennett aanbevelen.
Vakmanschap is veel meer dan het leren van een methode. Sennett beschrijft dat zeer overtuigend. Niet alleen voor de IT, maar ook voor andere mensen die het slachtoffer worden van procedureschrijvers.
Er staat 10 000 uur voor het leren van een vak en 80% van het vakmanschap is waarnemen. Leer je dat ook door het bestuderen van TOGAF?
We weten toch al heel lang in theorie en uit de praktijk dat de methode het niet doet. Hoe komt het toch dat generatie op generatie IT-ers het programmeren van computers en 'programmeren' van ontwerpers als vergelijkbare problemen beschouwen?

Vriendelijke groeten,

Jaap van Rees
www.jaapvanrees.nl

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Danny Greefhorst op 05-02-2009 07:16

Heren,

Ik heb proberen aan te geven dat pragmatiek belangrijk is. Ik ben het dan ook geheel eens met de stelling dat de methode het niet doet. Ik denk echter dat je ook niet blind moet zijn voor zaken die al bedacht zijn. Zie het als gereedschapskist waar je uit kunt putten als het nodig is. Creativiteit is ook daarin een belangrijk element. Als we echter negeren wat anderen hebben bedacht dan maken we geen stappen in ons vakgebied. Dit is een symptoom waar we in IT in het algemeen last van hebben; we schijnen een zeer gebrekkig collectief geheugen te hebben en elke keer opnieuw weer dezelfde fouten te maken. Ik denk daarom dat het belangrijk is om best-practices te delen en je deze eigen te maken. TOGAF draagt daar aan bij en het is erg dom om dat gewoon maar te negeren. Een TOGAF certificaat laat zien dat iemand de moeite heeft genomen om zich echt te verdiepen in TOGAF en daaruit spullen in zijn persoonlijke gereedschapskist heeft kunnen stoppen. TOGAF laat overigens nog heel veel aan de architect, en het aanpassen van de methode aan de specifieke situatie is zelfs geformaliseerd in TOGAF; dat is stap 1.

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Daan Rijsenbrij op 05-02-2009 07:21

Danny,

In jouw stellingname dat professionele architecten dienen te zijn gecertificeerd in TOGAF, ga jij uit van het feit dat TOGAF een consistente, coherente, waardevolle methode (of raamwerk) is. Als ik diagonaal door die ruim 700 pagina’s blader, krijg ik nauwelijks het gevoel dat het consistent is, laat staan samenhangend.

Hoeveel waardevolle praktijkervaring is er al opgedaan met TOGAF? Kan jij mij een lijstje geven van ondernemingen die hun architectuur verifieerbaar hebben kunnen verbeteren door gebruik te maken van TOGAF?

Volgens mij zit er nog veel meer 'wishful thinking' achter TOGAF dan er zat achter SOA, de vorige besmetting die de IT-sector is aangepraat. Ik voorzie een goudmijn voor opleidingsinstituten en consultants, want iedere onderneming die zijn IT een beetje op orde wil hebben heeft volgens jou natuurlijk TOGAF nodig. Heb jij al een instrument waarmee TOGAF-compliancy of zelfs de TOGAF-maturity kan worden gemeten?

Groetjes,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.23

Geschreven door Mark Paauwe op 05-02-2009 09:32

Een vergelijking van TOGAF met Dragon1 is vanwege het statement van Danny wel op zijn plaats.

Hoe kun je nu beweren dat iedereen TOGAF als de ware moet zien, terwijl er zo ongelooflijk veel discussie is in het vakgebied? Hoe kun je nu beweren dat het zo belangrijk is om een TOGAF-certificaat te behalen als er nog weinig financiële meetbare bedrijfsvoordelen bekend zijn hiervan bij het bestuur van de klant-organisatie?

Ook al kan ik natuurlijk net zoveel kritiek krijgen op mijn voorliefde voor Dragon1 als Danny zijn voorliefde voor TOGAF, ik heb wel 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 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.

Ik heb het artikel geupload op http://research.paauwe.info/downloads/Dragon1_versus_TOGAF.pdf

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.

http://research.paauwe.info/downloads/Dragon1_versus_TOGAF.pdf

Mark Paauwe
mark@paauwe.info

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.22

Geschreven door Martin van den Berg op 05-02-2009 19:04

Beste mensen,

Ik vind het geweldig dat TOGAF-9 er is. Een mooie uitbreiding voor het vakgebied en een ontwikkeling die we niet kunnen negeren gezien de toenemende adoptie door met name grote organisaties ook in Nederland.
Ik vind het ook geweldig dat Jaap van Rees zegt dat de methode het niet doet en dat je als architect vooral moet waarnemen. Helemaal eens.
Ik vind het ook geweldig dat Mark Paauwe zich richt op goede en aansprekende visualisaties, ook dat is goed voor het vakgebied.
Ik vind het ook geweldig dat Daan Rijsenbrij scherp waarneemt.

Waar het uiteindelijk over gaat is dat architectuur een blijvende plaats krijgt in organisaties en daar waarde toevoegt. Daar hebben we goede architecten voor nodig die goed kunnen waarnemen etc. maar ook gereedschappen. Met name in grote organisaties met tientallen architecten is er behoefte aan gemeenschappelijke begrippenkaders, aanpakken, producten etc. Op dat laatste punt biedt TOGAF toegevoegde waarde als een internationale open standaard. In die zin ben ik het ook met Danny eens met zijn pleidooi voor TOGAF certificering. En natuurlijk is dat absoluut geen garantie dat je dan een goede architect bent.

Groeten vanuit San Diego (was bij de launch van TOGAF-9),
Martin van den Berg

NB: De relatie tussen DYA en TOGAF komt aan de orde op de DYA-dag op 10 februari. Aanmelden kan nog via www.sogeti.nl

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.22

Geschreven door Danny Greefhorst op 05-02-2009 20:14

Beste Mark,

Ik kan jouw hele betoog eigenlijk niet anders beoordelen dan een poging om de Dragon1 methode voor het voetlicht te brengen, wat ik vanuit jouw belang daarin geheel begrijp. Ik krijg daarbij echter sterk het gevoel dat je de objectiviteit wat uit het oog verliest.

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.22

Geschreven door Danny Greefhorst op 05-02-2009 20:27

Beste Daan,

Beoordelen of iets consistent is kun je niet met alleen maar diagonaal doorlezen. Zoals ik in mijn artikel aangeef is de consistentie van TOGAF 9 sterk toegenomen t.o.v. TOGAF 8. Perfect is TOGAF 9 zeker niet, maar dat hoeft ook niet. Zoals ik al eerder aangaf zie ik TOGAF vooral als een handige gereedschapskist en niet als iets dat je dogmatisch dient toe te passen. TOGAF compliancy is wat mij betreft dan ook niet zo nuttig. Het gaat erom dat je doelmatig blijft. Iets wegschuiven dat nog niet perfect is lijkt mij een verkeerde basishouding, het is hetzelfde "not invented here" syndroom waar ik eerder naar hintte toen ik het had over het gebrekkige collectieve geheugen op het gebied van IT.

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.22

Geschreven door Daan Rijsenbrij op 05-02-2009 21:13

Danny,

Constateren dat iets niet consistent is kan wel degelijk door slim diagonaal door te lezen. Je geeft zelfs zelf toe dat TOGAF niet consistent is, dus wat beoog je met deze opmerking richting mij. Het lijkt alsof je verliefd bent op TOGAF en geen enkele reële kritiek wilt horen.

Natuurlijk is TOGAF een (ongeordende) inspiratiebron en als zodanig voor sommigen een gereedschapskist. Maar moet die kist zo boordevol zitten, zelfs met zaken die helemaal niets te maken hebben met architectuur? Ik ken trouwens meer gereedschapkisten, b.v. Dragon1, DYA, GEA, IAF.

Ik schuif niets weg. Als TOGAF jou gelukkig maakt is dat fijn, maar verabsoluteer het niet door te stellen dat elke professionele architect hoort te zijn gecertificeerd in TOGAF. En de kreet ‘not invented here’ is een nietszeggende dooddoener die hier niet op zijn plaats is.
Voor het gebrekkige collectieve geheugen zou ik willen verwijzen naar mijn artikel ‘Toen was vakbekwaamheid nog heel gewoon (terug naar Hollandse nuchterheid)’ in het decembernummer van het maandblad Informatie.

Vriendelijke groet,
Daan.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.22

Geschreven door Danny Greefhorst op 05-02-2009 21:48

Beste Daan,

Het is denk ik de toonzetting van het commentaar die de discussie wat scherpe randjes geeft. Het is duidelijk dat jij niet gecharmeerd bent van TOGAF. Ik kan me voor een deel best vinden in je kritiek, maar desalniettemin zie ik in TOGAF toch een lichtpuntje in de babylonische spraakverwarring waar ons vakgebied zo'n last van heeft. Het geeft hoop dat we het ooit nog eens allemaal met elkaar eens worden.

Mvgr,

Danny

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.21

Geschreven door Ron Tolido op 06-02-2009 02:09

Ik gooi me even niet teveel in de inhoudelijke discussie (die is zonder mij al interessant genoeg) maar wil wel over certificatie opmerken dat The Open Group twee totaal verschillende standaards aanbiedt. Een is inderdaad TOGAF-certificatie, en dat gaat over het begrijpen en kunnen toepassen van TOGAF. Maar er is ook ITAC (IT Architect Certification) en dit is een veel zwaardere - op peer-review gebaseerde - standaard die vooral certificeert op bewezen competentie en ervaring.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.21

Geschreven door Erik Proper op 06-02-2009 02:45

Voordat we een vergelijk te maken tussen TOGAF x en architectuur aanpak/techniek/methode/school y, is het belangrijk stil te staan bij het feit dat TOGAF niet alleen maar een methode is maar ook een beweging.

Het is hard nodig dat we in ons vakgebied tot meer standaardisering komen. Neen! Ik bedoel niet dat er een "one-size-fits-all" methode moet komen. En ja! Jaap van Rees heeft gelijk dat de methode niet werkt. Ik zelf zeg altijd: "Een methode mag nooit een excuus worden om niet zelf na te denken". Er is meer standaardisering van terminologie, benoemde (tussen)resultaten, taken, processtappen, nodig. Daarnaast is het essentieel om tot uitwisseling van strategieen en aanpakken te komen in gemeenschappelijke. Zonder dit zal ons vakgebied voorlopig niet volwassen worden. Diegene onder ons die voor hun werkzaamheden op hun status als "held" of "guru" moeten vertrouwen hebben daar wellicht geen belang bij. Toch is het nodig als we als vakgebied serieus genomen willen worden. Een dergelijk proces vergt ook consensus. Dat kost tijd en energie. Vereist ook dat we soms water bij de wijn moeten doen. Het vergt van de deelnemers ook moed, openheid en vooral een constructieve houding.

Kritiek leveren op TOGAF is makkelijk. Maar laten we niet vergeten wat er al bereikt is. Er is zeker nog een boel te doen! Gebruik het vergelijken van TOGAF met een alternatieve methode daarom ook als kans om mogelijke verbeteringen en/of onderzoeksvragen naar voren te brengen.

Afbreken is makkelijker dan opbouwen ... dan weet iedere architect. Of zijn hier geen architecten!?

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.21

Geschreven door Peter Bakker op 06-02-2009 08:26

Ik denk dat we veel zouden kunnen leren van de "echte" architecten en de echte bouwwereld. Daar is, vooral door Frank Gehry, het Building Information Modeling, op gang gekomen.
Daardoor wordt het mogelijk om veel complexere gebouwen te bouwen met nieuwe technieken tegen "relatief" lage kosten (relatief want er zitten gebouwen tussen van meer dan 1 >miljard euro). Als we echt volwassen willen worden dan moeten we ons niet alleen richten op standaardisatie binnen ons vakgebied maar vooral op een heldere uitwisseling (dus ook accepteren/verwerken feedback) van informatie tussen alle partijen die bij de ICT omgeving betrokken zijn. Togaf is naar mijn mening teveel gericht op communicatie tussen architecten en 1-weg communicatie richting andere partijen en het standaardiseren lijkt een doel op zich te worden.

Ik raad iedereen aan om eens te googlen op Building Information Modeling of het artikel bij The Economist te lezen (http://www.economist.com/science/tq/displaystory.cfm?story_id=11482...) of een kijkje te nemen op de site van Gehry Technologies (http://www.gehrytechnologies.com/).

Met Building Information Modeling is al heel veel bereikt, van welke architectuurmethodiek kunnen we hetzelfde zeggen?

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.21

Geschreven door Mark Paauwe op 06-02-2009 13:15

Beste lezers van Via Nova,

Ik wil TOGAF absoluut niet afkraken, en dat doe ik ook niet!

PS: Deze blogentry/reactie is alleen geschikt voor mensen die conceptueel kunnen denken, creatief zijn en open staan voor kritiek aangevuld met nieuwe ideeen.

Ik WIL discussiëren over het feit dat volgens mij TOGAF over iets anders gaat dan wat je onder enterprise architectuur zou kunnen verstaan. Daar is Via Nova voor opgericht en bedoeld! Kritisch zijn en tot op het bot gaan.

Om als vakgebied serieus te worden genomen zijn aansprekende en bruikbare resultaten vele malen belangrijker dan methoden en definities. Bewegingen waar mensen zich bij aansluiten om dat ze dan beter in staat zijn ook goede aansprekende bruikbare resultaten te boeken is een geweldige ontwikkeling.

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.21

TOGAF is in mijn ogen een hele waardevolle en goede beweging. Maar gaat TOGAF wel over enterprise architectuur? Of gaat TOGAF over IT-governance, structuur en planning? Heeft men elkaar in TOGAF gevonden in een soort bedrijfs-informatieplannings paradigma?
Heel veel klantorganisaties hebben overzicht en inzicht nodig in hun IT-governance, planning en structuur. Het feit dat heel veel mensen dit waardevolle werk doen met een bepaald label erop, maakt nog niet dat ze dat label kunnen claimen.

In TOGAF had men ervoor kunnen kiezen om enterprise architectuur te definiëren als "de kunst en kunde van het ontwerpen en realiseren van duurzame, toekomstvaste en ondernemingen en integrale bedrijfs/IT-oplossingen". Dit zou zeer analoog zijn geweest aan de bouwkundige definitie voor architectuur. De enterprise architectuur van een onderneming zelf zou dan het geheel van toegepaste bedrijfskundige, veranderkundige en informatiekundige concepten en principes zijn.

Waarom heeft men in TOGAF de IEEE-definitie gebruikt voor architectuur en waarom heeft men niet gewoon de bouwkundige definitie van architectuur overgenomen?

Hoe groot de commerciele-machine achter TOGAF in mijn ogen ook is (Er valt denk ik heel veel geld te verdienen als je nu als TOGAF gecertificeerd bent of boeken drukt over TOGAF), ik wil discussies over TOGAF zien hier bij Via Nova. Discussies over de definities van TOGAF, over de principes van TOGAF. Over alles wat los en vast zit aan TOGAF.

Wat ik echter zie, is dat er niet inhoudelijk hier op Via Nova wordt gereageerd. En dan al helemaal niet door TOGAF-aanhangers.

Het begin van een discussie zo maar kunnen beginnen op basis van onderstaande definities van TOGAF9:

[TOGAF9] - Application Architecture - A description of the major logical grouping of capabilities that manage the data objects necessary to process the data and support the business.

[TOGAF9] - TOGAF defines "enterprise" as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership.

[TOGAF9] - Architecture principles are a subset of IT principles that relate to architecture work. Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way in which an organization sets about fulfilling its mission.

Drie definities van TOGAF9 die een hoop zinvolle inhoudelijke discussie waard zijn. Voor mijn gevoel slaan deze drie definities behoorlijk de plank mis en kunnen ze vele malen beter.

In de applicatie architectuur definitie ontbreekt bij TOGAF het contextuele en conceptuele abstractieniveau. Sowieso is architectuur toch geen beschrijving? Dus als we het niet beschrijven hebben we geen applicatie architectuur? Wat een rare definitie! De definitie van enterprise is zeer ruim, alles is een enterprise. Het woord enterprise is niet meer onderscheidend genoeg en hierdoor bijna niet meer bruikbaar. Ik denk dat enterprise zou is genoemd om ook business architectuur enterprise architectuur te mogen en vice versa. De definitie van architectuurprincipe is toch wel heel vreemd te noemen. Architectuurprincipes zijn onderdeel van IT-principes?

Reactie van Stichting Digital Architecture op 4 Juni 2012 op 15.20

Als TOGAF de verbindende schakel tussen alle bloedgroepen moet zijn, waarom is het definiërend kader dan zo rommelig?

Stel dat een gecertificeerde TOGAF9-architect nu voor een afdeling binnen een internationale onderneming de applicatie principes gaat opstellen van de enterprise architectuur, conform TOGAF9, wat komt daar dan uit?

Daar komt dan bijvoorbeeld uit dat 'Technology Independence' (TI) een principe is (zie de TOGAF-docs). Voluit is (TI): “Applications are independent of specific technology choices and therefore can operate on a variety of technology platforms.” Are?? Wanneer ?? Waar dan??
In het architectuurdocument staat het (TI)-principe trots te blinken. Maar (TI) is toch een kwaliteitsaspect of een gedeelte van een uitgangspunt of ontwerpregel: “Whatever you do, design your applications technology independent?” of ‘Technology Independence is a good thing to do, isn’t it?’. Het is goed dat (TI) in een architectuurdocument staat, maar hoe kun je dit (TI)-statement nu operationaliseren naar ontwikkelaars toe of strategen want “… are independent…” is het applicatielandschap nog lang niet? Ontwikkelaar en strategen willen weten wanneer en hoe ze (TI) voor elkaar kunnen krijgen, want aan (TI) zit wel een flink kostenplaatje vast. Hieronder betoog ik dat deze wijze van formuleren van principes in TOGAF niet zuiver genoeg gaat met te weinig houdbaar resultaat.

Ik zou willen dat er een meer zuiver geformuleerd principe uitkomt, dat de gehandhaafde werking van een toekomstvast applicatieconcept beschrijft, zoals: 'Door alleen applicaties te kiezen die zo zijn gebouwd dat je niet vast zit aan 1 operating systeem of 1 applicatieplatform zorg je ervoor dat je als organisatie niet tegen een vendor lock-in aanloopt.' Dit is voor mijn gevoel een principe. Een principe dat de werking beschrijft van bijvoorbeeld een FutureProofApplication-Concept. Technology Independence is geen principe, maar een kwaliteitsaspect waar een organisatie voor zou kunnen kiezen (en dan moeten betalen): All of our applications are technology independent (in 2012). Men stelt dan bijvoorbeeld een uitgangspunt zoals: ‘We streven naar maximale technologie onafhankelijkheid in onze IT-omgeving’. Maar men zou er ook net zo goed niet voor kunnen kiezen (en niet voor willen betalen). Los van of men wel of niet het uitgangspunt kiest, het principe (de werking) van het FutureProofApplication-Concept blijft overeind staan. Of je nu wel of niet kiest voor het concept. Dat is pas duurzaam en toekomstvast.

In Dragon1 wil de architect van de opdrachtgever weten wat zijn strategische uitgangspunten zijn zodat de architect alleen maar concepten kiest waar de opdrachtgever voor gaat betalen (de Dragon1-architect maakt de impact en kosten van het gebruik van dit concept inzichtelijk). Als een TOGAF-architect eigenlijk zelf uitgangspunten onderkend en die in de architectuur zet met het label ‘principes’ er op, waar hij niet precies van weet of de opdrachtgever er ook voor kiest en voor wil betalen, dan is de kans groot dat bij tijdsdruk en gelddruk in het project de ‘so called principles’ worden geschrapt. En dat is nu ook precies wat ik zie bij veel projecten met TOGAF. De opdrachtgevers realiseren zich niet dat de architecten voor hun uitgangspunten kiezen alleen deze onvoldoende goed terug leggen ter akkordering. TOGAF zou in mijn ogen echt andere definities moeten gaan hanteren voor ‘principe’ en ‘applicatie architectuur’ en überhaupt het begrip uitgangspunt moeten gaan onderkennen, wil men architecturen kunnen opstellen die beter houdbaar zijn in zwaar weer.

Sponsoren

Sessies

15/16-11: Landelijk Architectuur Congres meer...

Advertenties

Je kunt hier adverteren

© 2018   Gemaakt door Stichting Digital Architecture.   Verzorgd door

Banners  |  Een probleem rapporteren?  |  Algemene voorwaarden