Coda en de zaak van de groeiende enterprise architectuur
Ronald Streekstra
Ik schreef al eerder over de architectuuraanpak die we bij woningcorporaties toepassen (Architectuur met een staartje). In die blog introduceer ik Continuous Outcome Driven Architecture, kortgezegd CODA. CODA legt bloot dat we in de beoefening van ons vakgebied enterprise architectuur veel focus hebben op de “bouw”-kant van ons werk, en weinig aandacht geven aan hoe architecturen “groeien”. Ik roep in die blog op voor meer aandacht voor de groeikant, het zogenaamde laten ontstaan van architecturen.
In de figuur hieronder zie je links de architectuur achtbaan van CODA met rechts daarnaast de bouw -en groeipaden aangegeven.
De afgelopen periode zijn we vooral bezig geweest om architecturen te bouwen bij de klanten. Dat is business as usual. Maar we komen nu in een interessante fase. Er is voldoende gebouwd om de groeipaden van de architectuur achtbaan toe te passen. En het meest spannend is dan natuurlijk, werkt het dan zoals we dachten dat het moest gaan werken?
Ik neem jullie even mee de diepte in de zaak van CODA en de groeiende enterprise architectuur.
Groeiende enterprise architectuur
Een dunne enterprise architectuur
De klant heeft door omstandigheden nog geen strategisch kader en wil daar niet op wachten. We beginnen de CODA achtbaan bovenin en leggen een minimale EA neer. De minimale EA bestaat uit een domeindemarcatie en zes leidende principes voor de ontwikkeling.
De zes leidende principes sturen de ontwikkeling van het landschap. Een daarvan is bijvoorbeeld het denken in domeinen. Dit principe schept als het ware de aanpak onder de enterprise architectuur.
Een domein demarcatie verdeelt de processen, informatieobjecten, afdelingen en IT over een aantal functionele domeinen.
Domeinvisie
Op basis van de afgebakende domeinen bepaalt het bestuur de prioriteit. Dat gebeurt op een verscheidenheid van factoren, waarbij de wens tot domeinvisie-ontwikkeling en noodzaak tot landschapsvernieuwing sterk bepalend zijn. We selecteren de drie prio-domeinen om te gaan ontwikkelen.
Voor een domeinarchitectuur is een domeinvisie noodzakelijk. Volgens een vast en herhaalbaar recept bouwen we met de betrokken afdelingen aan drie domeinvisies (1,2,3). Vaste elementen in de domeinaanpak zijn; knelpunten, SWOT, droom, visie, doelen, doelstellingen, principes, doelarchitectuur, veranderinitiatieven, roadmap.
In de achtbaan kunnen we nu twee richtingen op. Vanuit een domeinarchitectuur kunnen we verder afdalen en beginnen aan bouwblokken (2). De andere richting neemt de de drie domeinarchitecturen samen en voedt deze via een groeipad aan de enterprise architectuur (1).
Groeipad naar enterprise architectuur
Bovenin laten deze drie domeinarchitecturen de enterprise architectuur groeien. Welke overeenkomsten zitten er in de drie architecturen? Welke principes moeten uitstijgen boven het domeinniveau? Zijn er domeinen die stiekem over de domeindemarcatie heengaan en hebben we integratiesessies nodig om tussen domeinen de grens goed te bepalen? Welke informatiebehoefte leeft er tussen de domeinen en welke dataproducten levert elk domein?
In deze ronde oogsten we diverse enterprise principes en zijn we in staat een groot deel van de doelarchitectuur op EA-niveau te schetsen. De geoogste principes worden bij de 1e zes principes gevoegd en dienen als input voor de volgende iteratie waarin we weer drie domeinarchitecturen gaan bouwen.
Doordenken domeinarchitectuur
Onderin werken we domein-veranderinitiatieven uit. Een uitwerking kan bijvoorbeeld een marktverkenning zijn. In ons geval leidt de zoektocht naar de invulling van bouwblokken naar de conclusie dat de geraadpleegde software leveranciers een ontworpen bouwblok niet geheel in kunnen vullen.
Het groeipad terug van de bouwblokken naar de domeinarchitecturen kan nu doorlopen worden. Drie deelfunctionaliteiten waar we graag integraal over willen sturen, kunnen we niet in 1 pakket vinden. We moeten daarmee of afstappen van ons doel, of kijken of we op een andere manier (proces, rapportage) ons doel kunnen bereiken. Dit is input voor de domeinarchitectuur.
Het mooie van de groeilussen is dat ze in relatief weinig tijd met weinig bemensing uitgevoerd worden. De doelarchitecturen worden getoetst en verbeterd. In een volgende lus kunnen we daadwerkelijk een aanbesteding doen. En ook de aanbesteding en later de implementatie gaat ons informatie opleveren die we via het groeipad terug kunnen laten stromen en onze doelarchitecturen sterker maakt.
Nog een rondje
In een volgende iteratie door de achtbaan gebruiken we de verrijkte enterprise architectuur, een stevigere demarcatie en de nieuwe principes vanuit het enterprise niveau om extra kaders mee te geven aan drie nieuwe domeinen (4,5,6).
Hierop bouwen we weer drie nieuwe domeinarchitecturen en kunnen we de enterprise architectuur weer verder groeien
Conclusie
Het toevoegen van het groeipad aan de diverse architecturen maakt het mogelijk te spelen met hoe je architectuur tot stand komt. Je kan spelen met de verhouding tussen bouwen en laten ontstaan. In deze case groeit een minimale enterprise architectuur langzaam tot volwassenheid. Dat kan omdat er actief gebouwd wordt aan domeinarchitecturen.
Case closed…
