Ik was bezig bij een klant met het inrichten van een enterprise architectuur. Het was lastig om te beginnen en het startpunt te bepalen. Er waren zeker architecten aan het werk, maar die waren eigenlijk alleen bezig met technische ontwerpen binnen projecten. Lees hoe we in een jaar tot een architectuur zijn gekomen die daadwerkelijk bijdraagt aan de businessresultaten.
De verbinding met de business kon ik eigenlijk niet vinden en een bovenliggend architectuur raamwerk al helemaal niet. Hoewel ik hier en daar wel wat architectuur onderdelen tegenkwam, hier eens een PSA en daar eens een dienstbeschrijving, had ik toch het gevoel dat de architectuur volwassenheid ongeveer nul was.
Na enig dralen zijn we gestart met het onderbouwen van de architectuur keuze. Dus vaststellen dát we onder architectuur wilden werken. Het bleek al snel dat alle lagen van de organisatie het belang van werken onder architectuur al onderschreven, het was alleen nooit, eeehm, onderschreven.
Als eerste hebben we een heel simpel document opgesteld waarin we aangaven dat het ontwikkelen van architectuur een onderdeel op de roadmap van de organisatie was. Dit zorgde voor borging van het architectuur ontwikkelproces. Dit was zonder dat we op dat moment al een inschatting konden maken van de nodige kosten of inspanningen. Heel belangrijk bleek dat architectuur niet als onderdeel van IT werd gepositioneerd, maar als onderdeel van de business. Dus IT vertegenwoordiging in de boardroom. Als je dat niet doet blijft architectuur een IT feestje en krijg je nooit de rest van de organisatie mee.
Vervolgens bleek, mazzeltje, dat we aan konden haken bij een lopend (Cobit) classificatietraject. Zonder hier in al te veel details op in te gaan konden we de gestes die Cobit met betrekking tot architectuur doet direct gebruiken voor het ontwikkelen van onze Enterprise Architectuur. Win-Win. Voorbeeldje: Cobit stelt dat het een goed idee is om een informatie architectuur te hebben en te gebruiken en geeft vrij gedetailleerde richtlijnen hoe dit in te richten. Mooi. Dat wilden natuurlijk ook als onderdeel van onze Enterprise Architectuur. Zo bleken er na een aantal dagen ‘architectuur onderdelen sprokkelen’ al best wat bruikbare producten te zijn. Het lastige was alleen dat de samenhang ontbrak. Op het moment dat je een PSA template, een architect en een handvol bouwblokken hebt dan doe je wel iets met architectuur, maar kun je zeker niet spreken van een geïmplementeerde enterprise- of informatie architectuur die een bijdrage levert aan de business.
De volgende stap was dan de keuze van een raamwerk om de bij elkaar gesprokkelde architectuur producten aan op te hangen en om inzicht te krijgen welke te ontwikkelen. We kozen voor TOGAF, vooral omdat dit een bekend merk is en je je hier nauwelijks een buil aan kan vallen. We realiseerden ons best dat wanneer we wat verder in de architectuur ontwikkeling zouden zitten het zou kunnen dat TOGAF toch niet de best passende keuze bleek. Maar je kan dan beter van de ene structuur naar een andere overstappen, dan van een losse bende aan spullen naar een structuur. Daarbij geeft TOGAF met de ADM ook een richting aan het ontwikkelen van architectuur en dat konden we in deze fase goed gebruiken.
Lastig was nog om voldoende resources vrij te spelen van de waan van de dag om de nodige architectuurproducten en samenhang te ontwikkelen. Dit lukte het beste door binnen de toch al lopende projecten slim na te denken en bij alles wat opgeleverd werd, werd gekeken hoe dit bij kon dragen aan de enterprise architectuur. Zo werd als onderdeel van een project de PSA template opgewaardeerd, een PEA template ontwikkeld en beschreven hoe deze in samenwerking tussen architectuur en project gebruikt zouden worden. Alle technische objecten werden direct als bouwblok vastgelegd (volgens het good old DYA bouwblokken model) en op SharePoint in een repository klaargezet voor volgende projecten. Zo ontwikkelen we nu nog steeds de Enterprise Architectuur. Een beetje komt uit het Cobit compliance traject, een beetje uit de technische projecten en TOGAF geeft de richting aan. Hoewel we er nog lang niet zijn, is nu al te merken dat we echt architectuur bedrijven. Er zijn nauwelijks nog op zichzelf staande acties en iedereen (project, architectuur, business, informatiemanagement en beheer) is zich bewust van de potentiele bijdrages aan architectuur.
De planning laat zien dat het reëel is dat we over een jaar op een architectuur volwassenheid van 3 zitten. Dat betekent dat we niet alleen de architectuur spullen hebben, maar dat we ze ook zinvol ten dienste van de organisatie inzetten.
Van 0 tot 3 in een jaar. Het kan. Ik heb het gezien.
Comments are closed.