Agile ontmoet architectuur
Hoeveel architectuur heeft een organisatie nodig?Hoeveel architectuur heeft een organisatie nodig? Een jaar of 10 geleden waren er twee extreme standpunten te identificeren. De beginnende agilisten zagen er helemaal niets in; weg er mee! Aan de andere kant van het spectrum de ‘boekhouders’ die het bedrijf volledig ingekaderd en gecatalogiseerd wilden hebben, als ware het een statische postzegelverzameling.
Anno 2016 zijn die standpunten aanzienlijk naar elkaar toegegroeid. In de agile frameworks heeft architectuur een duidelijke plaats gekregen, en geven de guru’s – zij het schoorvoetend – toe dat architectuur onmisbaar is op enterprise schaal. Een definitie van architectuur als “Architecture is the stuff that’s hard to change later. And there should be as little of that stuff as possible” (Martin Fowler) drukt het treffend uit.
Aan de kant van de enterprise architectuur is er ook veel veranderd. Mede onder druk van de economische crisis zijn veel architectuurafdelingen gedownsized. Met de noodzaak om bij te blijven in de aanhoudende reeks van disruptieve innovaties in IT daalde de bereidheid van de business om altijd alles onder architectuur te doen. Er moest meer ruimte zijn voor experimenten, voor al doende leren, voor ondernemerschap. De opkomst van agile werken is in deze context dan ook geen toeval. Er was – en is – een behoefte om een nieuwe balans te vinden. Niet verrassend dus dat het begrip ‘agile architectuur’ de afgelopen jaren steeds meer inhoud heeft gekregen en daarmee ook voet aan de grond.
Zoektocht naar een nieuwe balans
De discussie tussen helemaal géén architectuur en een alles beschrijvende architectuur blijft natuurlijk. Agile werken zet deze discussie slechts op scherp. Hoewel ik als architect nadrukkelijk streef naar een agile manier van werken, heb ik geleerd dat er geen ‘one-size-fits-all’ oplossing bestaat. Er zijn tal van redenen waarom de ene organisatie streeft naar méér architectuur, terwijl de ander juist op zoek is naar minder.
Het maakt dan ook uit waar een organisatie vandaan komt. De neiging bestaat om de slinger eerst maar eens flink de andere kant op te laten gaan. Dat zien we in het dagelijks leven ook. De radicalen willen alles veranderen en gooien nogal eens het kind met het badwater weg. Dat maakt in ieder geval duidelijk dat het anders moet. De conservatieven daarentegen willen koste wat kost het goede behouden. En dat omvat meestal de status quo.
Het vinden van een nieuwe balans is een heftig proces, en leidt in vrijwel alle gevallen tot een nieuw niveau van professionaliteit. Dat geldt dan zowel voor de mensen als voor de voortbrengingsprocessen. Business innovatie, software development, architectuur: ze vinden elkaar op een nieuwe manier die leidt tot een beter resultaat.
Drie praktijkvoorbeelden
Laat ik aan de hand van een aantal voorbeelden uit mijn eigen praktijk toelichten hoe bedrijven een nieuw antwoord geven op de vraag ‘hoeveel is just-enough?’.
1) Waterbedrijf
Dit bedrijf heeft één eigen architect, aangevuld met enkele los-vaste externen. De focus ligt sterk op het ondersteunen van (agile) projecten. Er was geen referentie architectuur, wat leidde tot steeds weer dezelfde discussies. De afgelopen jaren is geïnvesteerd in het op een hoger niveau brengen van de architectuurfunctie. Er is een referentie architectuur opgesteld en gepubliceerd, en er zijn architectuurprocessen ingericht, met als doel om de ontwikkelorganisatie meer zelfredzaam – professioneler – te maken. Het vinden van de juiste balans is een voortdurende uitdaging gebleken: hoeveel referentie architectuur is gerechtvaardigd gegeven de omvang van de IT-operatie? Hoeveel is wenselijk, en hoeveel is haalbaar? De werkdruk vanuit de projecten maakt het lastig om proactief aan samenhang en richting te kunnen werken. Urgent versus belangrijk.
2) Bank
Deze bank kwam een aantal jaren terug tot de conclusie dat de architectuurfunctie topzwaar was geworden. Er waren zóveel referentiemodellen, dat elke wijziging heel veel beheeractiviteit met zich meebracht. Te veel overhead waarvoor te veel architecten nodig waren. Een nieuwe balans werd gezocht in wat genoemd werd: ‘van een modelgebaseerde naar een principe gebaseerde architectuur’. De referentie architectuur werd van vele honderden modellen terug gebracht naar en klein aantal kernmodellen en een twintigtal principes. Er kwamen minder architecten, die nauw verbonden werden met de business en de programma’s, en meer gingen sturen op de essentie.
3) Uitvoeringsorganisatie
Deze grote uitvoeringsorganisatie van de Rijksoverheid is een belangrijke producent van (open) data, zowel voor de eigen processen als voor externe afnemers. Data is zó belangrijk dat er een Chief Data Officer is aangesteld. Deze moet o.a. zorgen dat alle redelijk autonoom opererende onderdelen op een gelijk niveau komen voor wat betreft data management, en dat de rol van Data broker ingevuld wordt. Er is behoefte aan kaders, zodat de eindeloze stroom aan operationele vragen beantwoord kunnen worden: “In welke database slaan we deze data op, en voor hoe lang?”, “Zijn er wettelijke kaders die iets zeggen over de ontsluiting?”, “Is er beleid ten aanzien van het uitbesteden van de inwinning van deze data?”, of: “Wie is bevoegd om ons standpunt tot beleid te verklaren?”. Wat het lastig maakt is dat de focus sterk op de IT ligt, terwijl het feitelijk om de data gaat. Data management en data architectuur zijn bezig met een inhaalrace, die vraagt om een verschuiving van aandacht, waarbij de verbinding tussen bedrijfsprocessen, data en IT beter samenkomen.
Een bewegend doel
De bovenstaande casussen illustreren dat het zoeken naar de balans en de gekozen oplossingen heel situationeel zijn. De wereld van het waterbedrijf (klein, meer architectuur) is een heel andere dan die van de bank (groot, minder architectuur) of de uitvoeringsorganisatie (groot, andere architectuur). Bij het waterbedrijf gaat het nog voornamelijk om IT, terwijl de uitvoeringsorganisatie al jaren heeft geïnvesteerd in IT, data en processen.
Uit de diversiteit van de praktijk kunnen we veel dingen leren. Wat werkt in welk geval? Mankeert de kwaliteit of kwantiteit van architecten, of mankeert het proces? In onze training ‘Architectuur en Agility’ bespreken we heel veel practices uit onze eigen ervaringen. Het is altijd spannend om te zien hoe één en dezelfde aanbeveling door cursisten in hun eigen contexten anders wordt uitgewerkt. Een aanbeveling als ‘Travel Light’ betekent voor de één een trigger om prioriteiten te heroverwegen, voor de ander is het het inzicht dat méér niet altijd beter is.
Agile is momenteel een dominant thema in de IT. Het helpt de architectuur om los te komen van de loodzware verwachtingen die in de loop der jaren zijn opgestapeld. De komende jaren zullen andere technologische ontwikkelingen – big data, internet of things, mobility, etc. – weer om een nieuwe balans vragen: meer of minder, maar in ieder geval anders. Wat mij betreft is agile architectuur nu iets wat we maar beter snel onder de knie kunnen krijgen, want het wordt er de komende jaren vast niet gemakkelijker op. ‘Just, enough’ is een bewegend doel.
Serge Bouwens is een ervaren management consultant, enterprise architect en coach. Als consultant begeleidt hij organisaties bij de inrichting van de IT-functie. Als lead architect opereert hij vaak als meewerkend voorman bij het opstellen van een breed spectrum aan architecturen. Zijn stijl is pragmatisch en gericht op het slaan van bruggen tussen strategie en uitvoering.
