Architectuur zonder frictie: lessen uit 15 jaar agile governance

Vijftien jaar geleden presenteerden we op de WICSA 2011-conferentie het eerste paper over Risk- and Cost-Driven Architecture (RCDA, tegenwoordig ook bekend als Responsive, Collaborative Digital Architecture). Nog steeds worstelen organisaties met de vraag hoe architectuur waarde toevoegt zonder agile teams te vertragen.

De kern van de zaak was eenvoudig: architecten moeten hun aandacht richten op wat daadwerkelijk van belang is voor de business. De naam verwijst naar het inzicht dat “wat van belang is” verrassend vaak neerkomt op de risico’s die spelen en de kosten om deze te adresseren — in plaats van op volledigheid, templates of vooraf gedefinieerde processen.

Dit perspectief blijkt opvallend duurzaam. In de afgelopen jaren krijg ik regelmatig de vraag hoe architectuurgovernance zich verhoudt tot agile manieren van werken. Veel organisaties worstelen hier nog steeds mee. Traditionele governance-aanpakken, met hun nadruk op centrale sturing, vooraf gedefinieerde artefacten en fasegewijze besluitvorming, sluiten vaak slecht aan bij autonome teams, snelle feedbackcycli en continue verandering. Daardoor wordt governance óf ervaren als een belemmering voor delivery, óf verliest het geleidelijk zijn invloed.

In de afgelopen 15 jaar heb ik in uiteenlopende organisaties aan deze problematiek gewerkt, heb ik een aantal terugkerende patronen gezien in hoe deze spanning zich manifesteert — en hoe ermee kan worden omgegaan. De volgende lessen blijken daarbij consequent waardevol.

1. Vertel teams niet wat ze moeten doen, help ze betere keuzes maken

Twintig jaar geleden werd architectuur gekenmerkt als “Kaderstellend en borgend”. Verschuif de focus van het stellen van kaders naar inhoudelijk leiderschap. In agile omgevingen wordt van teams verwacht dat zij zelf ontwerpkeuzes maken. Architectuurrichtlijnen die kaderstellend zijn, worden daarom al snel gezien als externe inmenging.

Een effectievere benadering is om duidelijk te maken welke aandachtspunten in een bepaalde context relevant zijn — en waarom. Wanneer architecten hun inbreng formuleren in termen van risico’s, afwegingen en mogelijke consequenties, dragen zij direct bij aan de kwaliteit van besluitvorming zonder de autonomie van teams te ondermijnen. Deze verschuiving — van sturen naar faciliteren — is subtiel maar fundamenteel. Het vraagt van architecten om hun gezag te baseren op inhoudelijk leiderschap in plaats van op hiërarchische goedkeuring, en daarmee hun vaardigheden uit te breiden.

2. Blijf niet op abstract niveau, ga waar nodig de diepte in

Architectuurdiscussies en -modellen zijn vaak relatief abstract. Hoewel dat nuttig kan zijn voor alignment, is het zelden voldoende om beslissingen op te baseren. Dit kan leiden tot een kloof tussen de beoogde architectuur en de feitelijke situatie in het digitale landschap.

In de praktijk ontstaan veel van de belangrijkste risico’s en kosten juist bij concrete ontwerpkeuzes. Om relevant te blijven, moeten architecten daarom kunnen schakelen tussen abstractieniveaus en, waar nodig, ook in details treden. Gregor Hohpe noemt dit “descending on the architect elevator”. Dit verkort feedbackloops en versnelt het leerproces. Het is geen verlies van overzicht, maar juist een manier om ervoor te zorgen dat architectuurdenken verbonden blijft met echte beslissingen.

3. Beschouw architectuur als evoluerende kennis, niet als documentatie

In veel organisaties is architectuurgovernance nog sterk gekoppeld aan templates en omvangrijke documentatie. In de loop der tijd worden hier vaak extra hoofdstukken en eisen aan toegevoegd, bijvoorbeeld als reactie op incidenten uit het verleden. Het resultaat is een groeiende hoeveelheid documentatie die lastig te onderhouden is en zelden daadwerkelijk wordt gebruikt bij besluitvorming.

Architectuurkennis is echter per definitie dynamisch. Deze zit in besluiten, in de onderliggende afwegingen en in de manier waarop inzichten zich ontwikkelen. Lichtgewicht, continu bijgewerkte artefacten — zoals besluitenregisters, geïdentificeerde aandachtspunten (concerns) en stakeholdergerichte views — ondersteunen governance doorgaans effectiever dan statische, documentgedreven benaderingen, zeker in agile omgevingen.

4. Gebruik risico en kosten als leidende taal

Een van de meest praktische aspecten van RCDA is het expliciet gebruiken van risico en kosten als basis voor architectuurdiscussies. Dit biedt een gemeenschappelijke taal die technische overwegingen verbindt met businessvraagstukken. Het helpt om prioriteiten inzichtelijk te maken, afwegingen te structureren en de focus te leggen op die beslissingen die daadwerkelijk significant zijn. Tegelijkertijd vermindert het de behoefte aan abstracte discussies over principes of methodologische voorkeuren, die in concrete situaties vaak beperkte waarde toevoegen.

Wat betekent dit voor architectuurgovernance?

Het aanpassen van architectuurgovernance aan agile context betekent niet simpelweg het afschalen van bestaande praktijken (“we hechten minder waarde aan documentatie”) of het hernoemen van bekende concepten. Het vraagt om een verschuiving in focus.

Governance verschuift van het afdwingen van naleving van vooraf gedefinieerde structuren naar het ondersteunen van goed geïnformeerde besluitvorming op momenten waar architecturale impact significant is. Dit betekent dat architecten teams op het juiste moment betrekken (en andersom), op het juiste detailniveau, en rond vraagstukken die in hun context daadwerkelijk relevant zijn. Het vraagt ook om een selectiever gebruik van governance-mechanismen, waarbij de inspanning wordt gericht op waar deze het meest bijdraagt aan duurzame resultaten.

Vijftien jaar na het eerste RCDA-paper is dit perspectief nog altijd actueel. Sterker nog, de noodzaak om architectuur te verankeren in risico, kosten en context is alleen maar toegenomen. Organisaties die dit omarmen, maken architectuur weer zichtbaar waardevol in plaats van een verplicht proces