TOGAF 9 - wat is veranderd?

Officieel wordt TOGAF 9 pas gepresenteerd op de Open Group conferentie in San Diego op 2-4 februari 2009. Vandaag al ontving ik mijn pre-ordered TOGAF 9 boek. Vreemd. TOGAF 9 is nog niet op de Open Group site gepubliceerd en het boek is ook nog niet via Amazon te krijgen. Ik heb het boek overigens hier besteld.

TOGAF 9 is de nieuwste versie van het TOGAF framework. De vorige versie was 8.1.1. De nieuwe versie is niet revolutionair anders dan de 8.1.1 versie maar het is meer een evolutie. De versie is gemoderniseerd (TOGAF 8.1.1 werd in 2006 gepubliceerd) en veel meer uitgediept.

Ten opzichte van de 8.1.1 versie lijken sommige delen van het boek verplaatst naar andere delen in het boek. Ik denk dat de nieuwe plaats vaak meer logisch is. Er zijn veel nieuwe plaatjes met een nieuwe fris ogende look en het algemene gevoel is dat het boek makkelijker leesbaar is wegens de nieuwe fonts en de betere graphics.

TOGAF 9 beschrijft ook meer onderwerpen dan TOGAF 8.1.1 zoals security architecture en SOA. Het gaat ook meer in op de topics dan TOGAF 8.1.1. Er is nu ook een goede glossary van gebruikte termen (in TOGAF 8.1.1 werden termen als building blocks gebruikt zonder veel uitleg over wat dat nu precies was. Hetzelfde gold voor bijvoorbeeld voor Enterprise Continuum en boundaryless information flow). Het bevat ook een betere introductie over TOGAF. In het algemeen is er meer aandacht voor business issues en business alignment.

Iteraties van de ADM zijn beter beschreven evenals het gebruik en de implementatie van ADM in de verschillende domeinen. Risico management, capability based planning en architecture partitioning zijn verder uitgewerkt en uitgebreid met veel plaatjes. Ze kunnen worden gebruikt voor de implementatie van deze zaken in de business.

Het boek is erg dik: 744 pagina's (de 8.1.1 versie was 508 pagina's). Het is een goede referentie met veel tips, templates en checklists voor enterprise architecten en het helpt architecten om TOGAF beter toe te passen. Van harte aanbevolen!

Stakeholders voor technische architectuur

Bij een recente opdracht kwam ik in een discussie met een collega op de vraag wie nu eigenlijk de belangrijkste stakeholders waren van een technische architectuur. We kwamen erop uit dat er eigenlijk slechts één stakeholder was: de systeembeheerder(s).

In de discussie kwamen diverse stakeholders aan bod, zoals de eindgebruikers en het management. Aangezien het echter om een technische architectuur ging, en niet om de functionele architectuur, bleek dat eindgebruikers en management eigenlijk niet geïnteresseerd zouden zijn in de architectuur van het systeem. Als zij iets wilden van het systeem, als ze klachten hadden over de performance, beschikbaarheid of een andere non-functional requirement, dan zouden ze te rade gaan bij hun systeembeheerders.

De systeembeheerders zouden de wensen van de gebruikers vertalen naar technische oplossingen en als het goed is bij de technisch architecten uitkomen.

Ook bijvoorbeeld security eisen die aan het system worden gesteld zouden aan systeembeheerders worden opgelegd. Zij zouden immers moeten zorgen dat het systeem veilig is ingericht. De beveiligingseisen zouden dan ook via systeembeheer bij de architecten (moeten) binnenkomen. Indien er extra eisen aan de beveiliging gesteld zouden worden, of indien het systeem bijvoorbeeld extra verbindingen naar andere partijen moest gaan ondersteunen, dan zouden deze eisen via de business of de eindgebruikers bij systeembeheer binnenkomen. Op hun beurt zouden de beheerders dan bij de architecten uitkomen voor de inrichting van een oplossing.

Als de architectuur van het system bij het ontwerp goed is opgezet dan zijn de toekomstige wensen van systeembeheer makkelijker te realiseren dan zonder een goede architectuur. Als het system bijvoorbeeld schaalbaar is opgezet, dan zijn toekomstige hogere performance-eisen eenvoudiger te implementeren. Als het systeem redundant is opgezet, dan zijn toenemende eisen op het gebied van beschikbaarheid makkelijker in te willigen.

Kortom: zowel bij de opzet van het systeem als bij de exploitatie is systeembeheer gebaat bij een goede architectuur van een systeem. Ze zijn daardoor dus de grootste stakeholder voor architectuur geworden.

Dit artikel is eerder gepubliceerd op de Topics pagina van Computable.

DYA: Ontwikkelen Zonder architectuur

Regelmatig kom ik het tegen: Organisaties implementeren een nieuwe dienst of applicatie onder hoge tijdsdruk. 

Er moet bijvoorbeeld snel iets op de markt komen voor de concurrent het doet (bijvoorbeeld in de telecom sector), of er is een nieuwe wet aangenomen in de tweede kamer die een aanpassing op korte termijn vereist (bijvoorbeeld bij verzekeringsmaatschappijen).

Een belangrijke valkuil is dan dat er een applicatie of service wordt gebouwd die niet voldoet aan de vastgestelde architectuur, of die security eisen niet zo nauw neemt.

Het probleem hiervan is dat de nieuwe service weliswaar snel wordt uitgerold, maar dat er achteraf heel veel werk nodig is om de service te beheren. De kosten hiervoor kunnen hoog oplopen. Ook kan de nieuwe service security problemen veroorzaken. Bovendien is de aansluiting met andere systemen vaak lastig, omdat de andere systemen wel aan de architectuur voldoen.

Een oplossing hiervoor wordt aangedragen in de DYA architectuurmethode.

Hierbij wordt onderscheid gemaakt tussen ontwikkelen onder architectuur en ontwikkelen zonder architectuur. Systemen die onder tijddruk moeten worden ontwikkeld hoeven hierbij niet persé te passen in de vastgestelde architectuur. Echter, nadat het systeem is opgeleverd moet een ontwikkeltraject gestart worden om het systeem opnieuw in alle rust te ontwikkelen, maar dan netjes onder architectuur.

Een mooi streven.

Ik heb dit echter nooit in de praktijk gezien. Als een oplossing eenmaal werkt, dan wordt het zelden vervangen, uitsluitend om aan de architectuur te voldoen. Tijdelijke oplossingen blijken meestal permanent te zijn. Op korte termijn kost het opnieuw ontwikkelen namelijk geld en mankracht, en het levert pas geld op op de lange termijn (voornamelijk beheerkosten). Vaak is dit ook een ander "potje" in het budget.

De enige mogelijk die ik zie is als er alleen van een architectuur kan worden afgeweken als er als onderdeel van het project (bij de start) al budget beschikbaar wordt gesteld voor de her-ontwikkeling. Vooraf zijn de kosten van het ontwikkelen zonder architectuur dan bekend bij de stakeholders, die dan een goede afweging kunnen maken of de additionele kosten in verhouding staan tot de snelle oplevering zonder architectuur.

Een goede inbedding van architectuur in de organisatie (de zogenaamde Architecture Governance), met voldoende mandaad is hiervoor natuurlijk wel noodzakelijk.