Meer rendement uit architectuur door focus op realisatie

Het opstellen van architectuurproducten is voor enterprise- en domeinarchitecten één van de primaire verantwoordelijkheden. Met ‘architectuurproducten’ bedoel ik documenten als de enterprise architectuur, een doelarchitectuur, domeinarchitecturen, thema architecturen etc. De kern van die documenten bestaat uit het beschrijven en uitbeelden van de gewenste situatie (de SOLL, de to-be) vergeleken met de huidige situatie, en de route en volgorde van ontwikkelingen naar die gewenste situatie toe – de roadmap.

Dergelijke architectuurproducten kunnen worden opgesteld naar aanleiding van een concrete verandering of ontwikkeling waartoe de organisatie heeft besloten, maar vaker worden deze producten onafhankelijk van specifieke veranderingen opgesteld.  Ze dienen dan (onder meer) als richtpunt en kader voor concrete veranderacties als programma’s, projecten of epic’s (bij een agile methodiek).

In onze praktijk komen we regelmatig tegen dat het lijvige, uitgebreide documenten zijn. Met relatief veel detail, voor alle ‘lagen’ van de architectuur: business, data, applicatie, techniek. Die uitgebreidheid betekent logischerwijs dat er veel tijd gaat zitten in het opstellen, reviewen, aanpassen en vaststellen van de documenten. De ervaring van Solventa is dat deze tijdsinvestering slecht rendeert. Onze standaard aanpak bestaat uit kort maar krachtige architectuurproducten die de hoofdlijnen beschrijven en meer ruimte openlaten voor invulling gedurende het realiseren van een concrete verandering. Dat sluit beter aan op de realiteit en het verhoogt het rendement van de architectuurpraktijk. Dit is niet alleen onze ervaring – een methodiek als DYA predikt dit overigens al sinds ze bestaat.

Just enough architectuur

Richt je als architect op architectuurproducten die de hoofdlijnen bevatten. De basis bestaat uit de organisatorische doelen en een handzame set aan principes waar het in essentie om draait. Uitgaande van de huidige situatie beschrijft het document de beweging of ontwikkeling die je als organisatie of domein wilt (door)maken. De gewenste situatie geef je weer met een doelarchitectuur in één overzicht, wellicht aangevuld met een een paar modellen. Dit is wat Solventa ziet als ‘just enough’ architectuur.

Advies is om de eerste definitieve versie van zo’n document op te stellen als een timebox. Stel een team samen, zet er een procesbegeleider op (dit zou heel goed extern ingevuld kunnen worden) en stel in een afgebakende periode (doorlooptijd) een ‘MVP’ (minimum viable product) document op. 

Zo’n aanpak borgt dat de resulterende producten relevant en bruikbaar zijn voor de gebruikers ervan (het business management, de stakeholders, IT-architecten) en de tijdsinvestering om ze op te stellen is beperkt te houden.

Argumenten

Ik noem hier drie redenen waarom het vooraf aan een specifieke verandering opstellen van uitgebreide architectuurproducten weinig waarde heeft:

1. De belangrijkste reden: tijdens het plannen, ontwerpen en realiseren van de veranderingen gebeurt nog van alles. Er is altijd sprake van voortschrijdend inzicht en ontwikkelingen in de organisatie en haar omgeving. Agile is daar natuurlijk een reactie op, en heeft als filosofie dat je ruimte maakt voor voortschrijdend inzicht en verandering, in plaats van het te willen voorkomen en beheersen. Ga daarin dan ook mee als architectuur, niet alleen in een agile omgeving maar ook in een organisatie die gebruikt maakt van projecten om te veranderen. Door producten op te stellen die alleen de hoofdlijnen bevatten en juist ruimte laten voor ontwerpbeslissingen later in het proces, just in time.  Dat vermindert het ‘rework’ aan de architectuur en voorkomt tijdverspilling.
2. Veel veranderingen zijn onvoorzien en relatief ingrijpend. Denk aan een fusie, het afstoten van een bedrijfsonderdeel, een strategische koerswijziging of het uit elkaar gaan van eerder gefuseerde organisaties. Dit is de extreme variant van punt 1. Omdat de veranderingen onvoorzien en ingrijpend zijn, passen ze niet in de toekomst zoals die geschetst wordt in de architectuurproducten die onafhankelijk van die verandering zijn opgesteld. De toekomstige situatie dient opnieuw te worden uitgewerkt.
3. (Detail)beslissingen kunnen beter genomen worden in samenwerking met medewerkers die goed thuis zijn in de werkprocessen, deskundig zijn op de inhoud en over situationele kennis beschikken. Die weten wat in de praktijk werkt en niet. Bijvoorbeeld afdelingsmanagers, teamleiders, business analisten of technische experts. Dergelijke functies en rollen zijn over het algemeen niet of beperkt betrokken bij het opstellen van enterprise – en domeinarchitecturen, wat geen probleem is als die architectuurproducten zich beperken tot de hoofdlijnen. Bij de uitwerking van de architectuur zijn deze medewerkers dan juist meer betrokken.

Conclusie: meer focus op het realiseren van verandering

Probeer als architect niet om alles van tevoren in detail te bepalen en in te kaderen. Het kost veel tijd en moeite en in de praktijk zal blijken dat het dat niet waard is. Beperk de architectuurproducten tot de hoofdlijnen. Doe de uitwerking gedurende de realisatie van de verandering en betrek degenen die er (expert)kennis van hebben.

Focus je als architect dan ook meer op de realisatie van veranderingen. Neem deel aan concrete projecten, en/of werk samen met ontwikkelteams. Geef uitleg aan de kaders en de achtergrond van de doelarchitectuur, en ondersteun de uitwerking van de architectuurproducten gedurende de realisatie. Ga in gesprek met de ontwikkelaars of de projectteams; geef input en luister naar hun ideeën en voorstellen ter uitwerking. Stel je faciliterend op. Een architect verbindt, ook (en misschien wel vooral) door de verschillende disciplines van de organisatie met elkaar in contact te brengen.

Zo lever je als architect meer waarde voor je organisatie, en daar gaat het om.