‘Just enough’ architectuur

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.

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • Good Ideas - Agile en architectuur

    Deze animatie geeft de essentie van agile weer en zet ook de relatie met architectuur op scherp. Maar de kijkers komen niet altijd tot dezelfde conclusies.

    Lees verder
  • U bevindt zich hier

    Architectuur is bij grotere organisaties een volwassen functie. Enterprise Architectuur wordt ingezet om grip te krijgen op de informatievoorziening. Solution Architecturen worden gemaakt om project specifieke oplossingen in te kaderen.

    Lees verder
  • Waar blijft het applaus?

    Het overkomt ons allemaal wel eens. Je hebt je best gedaan op een mooi stuk werk, en je bent trots op het resultaat. De analyse is degelijk, de architectuur die je bedacht hebt is beter dan marktconform, helder gedocumenteerd en gepresenteerd.

    Lees verder
  • Niet met 'n Ferrari in de file

    Deze blog gaat over de agile enterprise, en wat er voor nodig is om agile te worden. (Dan komen we vanzelf weer uit bij architectuur, maar net even anders.)

    Lees verder
  • Het stiefkind van de enterprise architectuur

    Ik stel me voor dat u bij het lezen van deze titel onbewust al heeft ingevuld waar ik het over heb. En ik stel me ook voor dat velen van u het goed geraden hebben. De Architectuur van de Technische Infrastructuur, verder afgekort met TIA.

    Lees verder
  • Decision Driven Architecture

    Met een Decision Driven Architectuur ben je in staat optimaal mee te leven met wat de organisatie belangrijk vindt, nu én in de toekomst. Dat lijkt me een vereiste in deze agile tijden blogt Serge Bouwens.

    Lees verder
  • Architectuur veert weer op!

    In november vond het jaarlijkse LAC congres plaats. "Meestal kom ik terug met de conclusie: er waren wel enkele aardige presentaties, vele bekende gezichten, prima verzorgd. Dit jaar was het echter anders", blogt Serge Bouwens. Lees verder.

    Lees verder
  • Zin en onzin van documentatie

    Willen jullie meer of minder documentatie? Minder! Minder! Minder! Lees verder.

    Lees verder