In 5 stappen naar een architectuurpraktijk in Agile organisaties

Architectuurpraktijk in Agile organisaties

Herijken van de visie

Een succesvolle architectuurpraktijk in een Agile organisatie start volgens Ton Eusterbrock met het herijken van de visie op architectuur in de context van de besluitvorming en de veranderaanpak. Benieuwd naar de 5 stappen die hij voorstelt? Laat je inspireren door deze long read. Meer weten? Meld je aan voor de DYA Dag op 4 september 2020!

Naar DYA Dag

Als Practice Lead Enterprise Architectuur geef ik regelmatig training op het gebied van Enterprise Architectuur (EA). Het meest voorkomende leerdoel dat ik de laatste jaren tegenkom is: “hoe doe ik EA in een Agile organisatie”. Het meest gegeven advies dat ik van anderen krijg is: “de markt vraagt om de ontwikkeling van een Agile-architectuur methode”.

Het zal je niet verbazen dat ik als antwoord geef dat DYA de ideale benadering is voor de inrichting van een EA-praktijk in een Agile organisatie. Maar het zal je mogelijk wel verbazen dat mijn wedervraag niet is hoe ze Agile doen maar waarom.

Ik ken eigenlijk geen organisaties die nog niet op de een of andere manier een Agile manier van werken aan het implementeren zijn. Van Scrum tot SAFe®, allerlei methodes komen voorbij. Van alle organisaties die Agile werken zijn in veel gevallen de architecten aan het worstelen met hun rol en bijdrage in verandertrajecten. Wat me daarbij vaak opvalt is dat architectuur niet zelden dogmatische benaderd wordt op het gebied van de gekozen methode en werkwijze.

In DYA wordt Enterprise Architectuur, in de breedste zin, gepositioneerd als ondersteuning van besluitvorming in de verandering van de enterprise. Het inrichten van een architectuurpraktijk vraagt daarbij om een situationele benadering. Een succesvolle architectuurpraktijk in een Agile organisatie start daarom met het herijken van de visie op architectuur in de context van de besluitvorming en de veranderaanpak. Om architectuur een effectieve bijdrage te laten leveren stel ik een herijking voor aan de hand van 5 stappen:

  1. Stel vast in welke context besluiten genomen moeten worden.
  2. Stel vast door wie besluiten worden genomen.
  3. Stel vast wanneer worden besluiten genomen.
  4. Stel vast hoe architectuur gecommuniceerd moet worden.
  5. Herdefinieer de visie op architectuur in de organisatie.

Stap 1: Stel vast in welke besluitvormingscontext jouw organisatie zich bevindt

Het meest belangrijke aspect voor het inrichten van elke werkwijze: Wat vraagt de context? Het invoeren van Agile maakt een organisatie niet per se wendbaar in de wijze waarop producten en diensten naar de markt worden gebracht. Zeker niet als de benodigde veranderingen erg voorspelbaar en planbaar zijn. Wanneer kies je dan voor Waterval en wanneer voor een Agile aanpak? Ga je dan uit van de driver dat alle hippe en jonge medewerkers alleen nog Agile willen werken een grote rol of baseer je de motivatie op inrichten van gewenste wendbare besluitvorming.

Dave Snowden heeft met het Cynefin framework een treffende categorisering gemaakt van de contexten waarin besluiten genomen moeten worden. Zijn boodschap is dat iedere context een eigen benadering nodig heeft. Een Agile aanpak werkt bijvoorbeeld goed in de complex context uit het Cynefin model, daar waar een aanpak van analyse en blauwdrukken beter past bij de complicated context. Dit heeft niet alleen implicaties voor de verander-aanpak (Agile vs Waterval) maar ook voor de stijl van architectuur. De contexten waar architectuur het meest tot haar recht komt zijn complicated en complex. In de complicated context past een architectuurstijl van analyse en blauwdrukken. Terwijl in de complex context een emergente architectuurstijl op basis van ‘Just enough, just in time’ beter tot haar recht komt. Echter, in een organisatie kan het voorkomen dat verschillende contexten naast elkaar bestaan, met daaruit volgend elk hun eigen behoefte aan architectuuraanpak.

Cynefin framework

Figuur 1: Schets van het Cynefin framework (Stoop)

Stap 2: Waar moet besluitvorming in de organisatie plaatsvinden?

De governance in een organisatie moet passend zijn bij de context. Wanneer je Agile in je organisatie doorvoert moet je realiseren dat deze benadering gebaseerd is op twee belangrijke pijlers. De eerste is decentralisatie van besluitvorming als gevolg van de decentrale autonome teams en de tweede is die van multidisciplinariteit van de teams. 

Werkelijke wendbare organisaties kunnen pas snelheid van handelen realiseren als de besluitvorming decentraal georganiseerd is. Bij voorkeur ligt deze bij de teams zelf. Een mooi overzicht hiervan staat bijvoorbeeld het rapport The 5 Trademarks of Agile Organizations van McKinsey. De context van besluitvorming is belangrijke input voor de inrichting van de architectuurpraktijk: Bij de centraal georganiseerde besluitvorming past de rol van architect als de ‘expert’. Bij een meer decentrale besluitvorming is het belangrijker dat architectuur een competentie van de organisatie is. Architectuur is dan een gedeelde verantwoordelijkheid waar meerdere functies in betrokken worden zoals bijvoorbeeld ontwerpers, analisten en Scrummasters. In die situatie past de rol van een architect als facilitator die het vooral het architectuurproces en -denken stimuleert.

Denk overigens niet dat je met één governance model voor de gehele organisatie uit de voeten kan. Dit geldt zeker in de situatie van decentrale besluitvorming. Om een effectieve en efficiënte besluitvorming te realiseren moet de governance structuur toegespitst zijn op de verschillende contexten van de domeinen. De stakeholders, spelregels, de besturing et cetera, kunnen per context anders zijn. Dat geldt dan ook voor de architectuurpraktijk: het geheel aan visie, werkwijze (proces en product) en competenties (persoon) zoals beschreven in de DYA-aanpak (DYA® Stap voor stap naar professionele enterprise-architectuur). Deze moet ook passend zijn bij de context. Binnen een domein dat zich inricht conform Agile richt je de architectuurpraktijk anders in dan in een domein dat gericht is op voorspelbare fasen in een waterval aanpak. 

Deze context-georiënteerde inrichting van architectuur is leidt dan automatisch tot meerdere varianten van de architectuurpraktijk: een Multi-Dynamische Architectuur.

Een uitdaging voor de architectuur is dat deze altijd gericht is op samenhang. Kan de samenhang wel een uitgangspunt zijn bij differentiatie in de architectuurpraktijk? In The 5 Trademarks of Agile Organizations wordt nog een belangrijke pijler onderkend; namelijk de voorwaarde van het hebben van duidelijk gedeelde doelen en de visie van de organisatie. Daar hoort dan bij dat deze vertaald moeten worden naar bruikbare strategische kaders. Voor architectuur betekent het dan ook dat niet alleen de inrichting van de architectuurpraktijk als model belangrijk is maar ook de inhoud van architectuur, de kaders op alle niveaus, heroverwogen moet worden: De nieuwe inhoud moet rekening houden met alle contexten in de organisatie. Alleen dan kan architectuur waarde toevoegen aan de besluitvorming in de verschillende contexten van de organisatie.

Stap 3: Wanneer worden besluiten genomen?

DYA procesmodel

In het DYA-model speelt de strategische dialoog een grote rol in het architectuurproces. Als de context erkent wordt en helder is waar besluiten genomen worden, ga dan op zoek naar de momenten waarop besluiten genomen worden. Iedere methode of veranderaanpak heeft hiervoor zijn eigen rituelen ingericht. In Prince2 waren hiervoor deliverables en mijlpalen benoemd. Een Projectinitiatie document welke door een stuurgroep moet worden geaccordeerd is daar een voorbeeld van. 

In een Agile organisatie veranderen ook deze rituelen. Veel organisatie gebruiken daarbij frameworks als Scrum of SAFe®. Een product backlog refinement sessie is één van de rituelen waar afstemming plaatvind over de betekenis en impact van de verandering waar de architectuur principes bekend moeten zijn. Hier moet men immers weten welke vrijheden er zijn binnen de ontwerpruimte. 

Architecten moeten zich bewust zijn van de rituelen en hun bijdrage hierop afstemmen. Dat gaat vaak niet meer samen met de aanpak uit het verleden. Dit heeft dus ook impact op de bijbehorende deliverables. Projectstart architecturen (PSA’s) zijn geschikt om sturing te geven aan voorspelbare resultaten en bijbehorende werkpakketten om projecten te initiëren. In Agile ligt veel meer het doel vast dan het werk en de volgorde van werkzaamheden. Besluiten over het ontwerp worden niet meer allemaal voorafgaand aan het werk genomen maar zijn onderdeel van de iteratieve aanpak geworden die in Agile gebruikelijk is. 

Bij DYA staat net als bij Agile de verandering centraal. DYA stelt dat de richting van de verandering in de strategische dialoog bepaald wordt. Het verschil tussen 2001 (het ontstaan van DYA) en nu in 2020 is dat de strategische dialoog niet meer alleen bij de Informatie Manager of bij de CEO plaatsvindt, maar meer bij de Product Owner en het team. 
Een architectuurbeschrijving gericht op de doelen, die veel meer een visie op de realisatie uitdrukt dan het ontwerp van de realisatie zelf, zal bij het hoger management veel meer waarde hebben. Daar worden de besluiten genomen over strategische thema’s en incrementen van meerdere sprints. Richting het Agile team, die in iteraties van sprints werkt, moet de architect borgen dat een continu besluitvormingsproces in iedere iteratie van de realisatie mogelijk wordt gemaakt. Op het niveau van de Product Owner en het team is de architect niet meer de expert die alles zelf opstelt, maar faciliteert zij/hij architectuur als competentie in de organisatie, het team in dit geval.

Stap 4: Hoe gaat de architectuur gecommuniceerd worden?

De eerste waarde van Agile stelt menselijke interactie boven afgesproken processen en tools. Dit betekent dat communicatie in een Agile omgeving meer via persoonlijke communicatie gaat en minder via het opleveren van een (mooi) procesontwerp. Dit stelt andere eisen aan de vaardigheden van een (solution) architect.  Een (solution) architect zal zich bijvoorbeeld eerder moet gaan bekwamen in story-telling dan in BMPN 2.0.

In een Agile omgeving staat het omarmen van verandering en het opleveren van een werkend product centraal. Het gevolg hiervan is dat de architectuur deze uitgangspunten ook moet omarmen, op de 3 aspecten Proces, Product en Persoon (zie figuur 3). Qua taal (Product) moeten we ons realiseren dat een gedetailleerde blauwdruk niet meer past. Een aanpassing dorvoeren op een blauwdruk kan zo maar enkele weken tot maanden duren. De verwachting van levertermijnen bij de Product Owner en het tempo waarmee een (volwassen) Agile team nieuwe software kan opleveren is enkele tot vele malen groter.  

Architectuur moet daarom minstens net zo iteratief en wendbaar zijn die aansluit bij de inrichting van de Agile organisatie. De architect in een Agile organisatie moet dus snel kunnen inschatten wat de relevante kaders zijn, iteratief kunnen opleveren en deze helder communiceren. De grote uitdaging voor een architect is hierbij om de grote lijn en de traceerbaarheid te bewaken. Architecten in een Agile organisatie moeten een andere taal leren en eentje die ook nog eens aansluit bij een 'Just enough Just in Time Architectuur', een van de bekendste principes vanuit DYA. 

Het is niet alleen de architect waar andere vaardigheden worden gevraagd. Het is ook de architectuur bijdrage die veranderd. De Enterprise Architectuur kan in een Agile organisatie niet meer de details van een oplossing voorschrijven. Het zijn de teams die hun eigen keuze mogen maken, binnen de kaders die door architectuur zijn gesteld natuurlijk. De Enterprise Architectuur zal daarom ook moeten veranderen. De grote uitdaging van Enterprise Architectuur gaat zijn hoe de samenhang tussen de verschillende autonome ontwikkelingen wordt behouden en het bepalen van de mate van ontwerpvrijheid (het mandaat) binnen de teams.

Om de samenhang en de impact van keuze te overzien zijn nieuwe hulpmiddelen nodig. De causal loop diagram is hier een voorbeeld van. Zie daarvoor ook de blog van Hans Nouwens die dient als introductie in de Casual Loop Diagram. Met één hulpmiddel zijn we er niet. Welke dit zouden moeten zijn we aan het verkennen en zal deels ook door de praktijk worden bepaald, mits we ook gaan werken conform een architectuur werkwijze die aansluit bij Agile.

Stap 5: Herijk de visie op de architectuurpraktijk in jouw organisatie

DYA visie op architectuur

Een architectuurpraktijk ingericht conform DYA geeft invulling aan drie aspecten: Product, Proces en Persoon. Deze invulling is in lijn met de visie van de organisatie op de rol van architectuur. Wanneer de organisatie verandert naar een Agile organisatie heeft impact op de gehele organisatie. Daarmee heeft het ook impact op architectuur. De ervaring leert ons dat de verandering naar een Agile organisatie een langdurig proces is. Dat betekent dat de architectuur ook gedurende een lange periode zal mee veranderen met de organisatie. Een emergente organisatieverandering vraagt ook om een architectuurpraktijk die ruimte biedt aan deze emergentie. De Agile werkwijze zal niet de laatste invloed zijn die de visie op architectuur zal doen veranderen. De vorige vier stappen zijn cruciaal om de nieuwe visie op architectuur inhoud te geven en de bouwstenen Product, Proces en Persoon in te vullen voor de veranderende architectuurpraktijk. Deze vijfde en laatste stap heeft als doel om de samenhang van de verandering te ondersteunen.

Sensemaking Architecture

Organisaties en hoe organisaties functioneren veranderen door de tijd heen, want niets staat stil. Architecten moeten daarom ook blijven reflecteren op hun rol, hun bijdrage en aanpak. Steeds meer organisaties veranderen in een Agile organisatie. Het besef dat de context van organisaties complex is en de behoefte van organisaties om in een steeds sneller veranderende wereld mee te kunnen veranderen vraagt om een fundamenteel andere aanpak van architectuur. Met DYA geven we daarom ook nieuwe betekenis aan architectuur. 'Sensemaking Architecture': een architectuur die niet alleen past bij een (deels) complexe context, maar daarnaast ook meer gericht is op de mens, op menselijke waarden en op het duiden van dynamiek. 

Kom naar de DYA Dag!

Ben je geïnteresseerd geraakt in deze zienswijze en wil je weten wat de impact hiervan is op onze visie op Enterprise Architectuur en wat dit betekent voor DYA? Kom dan op 4 september naar de DYA Dag!

Aanmelden DYA Dag

Deel dit artikel

Kan ik je helpen?