• It Architectuur Amersfoort

  

  • Home
  • Publicaties
  • Blog
  • Effectieve architectuur in een agile context

Effectieve architectuur in een agile context

29 april 2019

Enterprise-architectuur en agile ontwikkeling zijn inmiddels gebruikelijke praktijken, maar de combinatie van beiden blijft een onderwerp van discussie. Enterprise-architecten die zich blijven houden aan hun eerdere aanpak, houding en gedrag komen bedrogen uit. De wereld draait ook zonder hen door. Het is duidelijk dat de combinatie vraagt om iets anders, maar een goede balans vinden tussen lange termijn planning en korte termijn resultaten is voor architecten niet eenvoudig. Een aantal ervaren architecten en managers hebben gezamenlijk een inspiratiesessie gehad over het onderwerp en gezocht naar gemeenschappelijke inzichten. Dit blog item beschrijft het resultaat van de sessie en geeft er een verdere betekenis aan.

Gedrag versus inhoud

agileeaIn de eerste gedachtewisseling tussen de deelnemers werd al duidelijk dat een overgroot deel van het effect van een architect wordt bepaald door zijn of haar gedrag boven de inhoud. Het is de rol van de architect om anderen te beïnvloeden zodat zij doen wat wenselijk is. Tegelijkertijd geldt dat een belangrijk deel van de toegevoegde waarde van een architect ligt in het bieden van structuur en dat vastlegging van deze structuur daarvoor randvoorwaardelijk is. Een architect die alleen praat zal daarom onvoldoende effectief zijn.

Eigenschappen van effectieve agile architecten

In een eerste werkvorm is gezocht naar kritische succesfactoren voor architecten die effectief willen opereren in een agile context. Hieruit volgenden de volgende eigenschappen.

Een duidelijk doel en een duidelijke visie

Een agile ontwikkeling dient naar een duidelijk doel te bewegen en het is de rol van de architect om dit inzichtelijk en concreet te maken, voor zover dat nog niet het geval is. Een doel dat duidelijke waarde levert voor de organisatie, maar dat tevens voldoende vrijheid biedt om bij te sturen; een meerjaren streefdoel. Het kunnen bereiken van dat doel vraagt om een integrale architectuurvisie die duidelijk maakt wat daarvoor nodig is. Tegelijkertijd moet ook de visie ruimte laten om steeds nieuwe inzichten op te doen, te leren, bij te sturen en dus de uiteindelijke oplossing nog niet helemaal vastlegt.

Denken in tussenstappen

Het is duidelijk dat het doel niet in één keer gehaald kan worden en dat nieuwe inzichten tot andere routes zullen leiden. Het doel en de visie zullen daarom ontleedt moeten worden in kleinere behapbare waardevolle tussenstappen. Denk daarvoor in minimum viable products die realistisch zijn. Voorkom teveel kortzichtigheid; houdt rekening met wat logische stappen zijn.

Net genoeg architectuur

De architectuur zelf hoeft in een agile context minder ver te worden uitgewerkt en kan globaler en meer schetsmatig zijn. In een agile context geldt dat werkende oplossingen belangrijker zijn dan de beschrijving ervan (documentatie). Mensen hebben ook steeds minder zin om nog dikke pakken (papier) te lezen; het is al snel “too long to read”. De kunst daarbij is om die dingen op te schrijven die echt belangrijk zijn; de keuzes die bepalend zijn. Een agile architectuur moet overigens wel de doelstellingen, capabilities, principes en diensten beschrijven.

Emergente architectuur

De architectuur is ook niet helemaal vooraf te bedenken. Je moet ook kunnen uitproberen of dingen werken en verrast worden door dingen die anderen bedenken. Het is dus niet nodig dat de architect alles bedenkt en kiest. Het is belangrijker dat een omgeving ontstaat waarin de juiste inzichten en keuzes ontstaan. Om de ontwerpruimte toch wat in te perken helpt het om te denken in patronen. Denk bijvoorbeeld aan iets als een microservice patroon; ontwikkelaars weten direct wat je bedoelt, maar willen ook de vrijheid om te bepalen hoe een specifieke microservice precies werkt.

Communiceren en verbinden

Architectuur gaat voor een belangrijk deel over het verbinden van mensen en teams. Dat vraagt open communicatie, waarbij er alle ruimte is voor eenieder om denkbeelden in te brengen. Vriendelijkheid, empathie en assertiviteit stimuleert dit soort communicatie. Daarnaast is belangrijk dat de architect beschikbaar en aanspreekbaar is, voor zowel teams als stakeholders zoals bijvoorbeeld de directie. Als verbinder zal de architect moeten zorgen dat er (inhoudelijke) consensus komt.

Tonen leiderschap

Alhoewel verbinden zorgt voor maximale betrokkenheid en draagvlak is het ook belangrijk dat er inhoudelijke keuzes worden gemaakt. Daarbij zul je moeten accepteren dat je niet iedereen meekrijgt, mensen je soms niet aardig zullen vinden en dat de tijd voor discussie ook een keer op is. De architect zal daarom leiderschap moeten tonen, geloofwaardig zijn en anderen kunnen overtuigen. Een uitdaging daarbij is de besluitruimte van de architect en tevens het vertrouwen dat de opdrachtgever en management heeft in de architect.

Fundamentele verschuivingen

In andere werkvormen is gezocht naar verschuivingen in architectuur; wat zal in een agile context meer of minder relevant zijn. We hebben zowel gekeken naar de architectuurinhoud (wat beschrijft een architect) als de activiteiten (wat doet een architect). Hieruit kwamen de volgende fundamentele verschuivingen naar voren.

Meer aandacht voor doelstellingen en capabilities

Het is minder belangrijk hoe oplossingen er precies uitzien, zolang deze passen bij het doel. Het concreet krijgen van dit doel, de waarde die dat creëert voor stakeholders en de capabilities die het vraagt is belangrijker in een agile context. Doelstellingen zijn vaak niet vantevoren eenduidig vastgelegd en vraagt daarom expliciete inspanning van de architect, inclusief het begrijpen van de ontwikkelingen die eraan ten grondslag liggen. Capabilities benoemen wat de organisatie en de systemen moeten kunnen, zonder uit te leggen hoe.

Van eisen naar principes

Er worden in een agile context geen gedetailleerde programma’s van eisen meer beschreven. Er is veel meer keuzevrijheid in teams. Principes kun je zien als meer abstracte eisen, die wel richting geven maar tevens bewegingsvrijheid bieden. Het formuleren van principes is daarmee toenemend belangrijk voor architecten. Principes zijn richtinggevende uitspraken die een oplossingsrichting schetsen, zonder te beschrijven hoe de oplossing zelf er precies uit ziet.

Van oplossingsdomein naar probleemdomein

Doordat het minder belangrijk is hoe de oplossing er precies uitziet, zal de architect dat ook niet meer hoeven te modelleren. Denk bijvoorbeeld aan welke apparaten worden gebruikt of hoe de technologie precies werkt, maar denk bijvoorbeeld ook aan het ontwerp van het proces. Het moet wel duidelijk zijn welk probleem moet worden opgelost en hoe het probleemdomein er uit ziet. Het modelleren van de concepten en de diensten die moeten worden geleverd is wel relevant.

Meer nadruk op integratie

De oplossing en daarmee de interne constructie van systemen is minder relevant geworden om te beschrijven. Daarmee verschuift de aandacht naar integratie van systemen. Het is belangrijk om snel inzicht te creëren in de koppelvlakken (API’s) en de data die wordt uitgewisseld. Deze kunnen sterk bepaald zijn door vooraf gedefinieerde contracten of afspraken, die dan een leidende rol vervullen.

Meer begeleiden en coachen

Architecten zullen minder vooraf en meer gedurende ontwikkeling betrokken zijn. Omdat vooraf minder bekend is zullen zij meer op de werkvloer aanwezig moeten zijn om te ondersteunen bij de verdere uitwerking en helpen oplossen van lacunes. Aangezien architecten veelal ervaring en senioriteit inbrengen, zullen zij daarbij al snel een meer inhoudelijk begeleidende en coachende rol vervullen. Toetsing zal nog steeds relevant zijn, maar is meer ondersteunend dan formeel.

Tenslotte

Het is duidelijk geworden dat enterprise-architectur in een agile context echt anders moet. Er moet meer ruimte zijn voor teams om invulling te geven aan keuzes. Doelen en visie zullen bijstelling vragen en de architect wordt meer een coach en begeleider. Een blauwdruk voor hoe het precies moet werken hebben we niet opgesteld en is ook niet wenselijk. Wij willen alleen de principes schetsen waarbinnen anderen hun eigen keuzes kunnen maken.

Danny Greefhorst (Dit e-mailadres wordt beveiligd tegen spambots. JavaScript dient ingeschakeld te zijn om het te bekijken.) is directeur en principal consultant bij ArchiXL

Met dank aan Bas Crompvoets, Anton van Weel, Fernand Rouwendaal, Hans Guldemond, Andre Schrander, Tony Sloos en Manuel Rejen voor hun bijdragen in de inspiratiesessie.

Social Bookmarks

Contact

ArchiXL B.V.
Nijverheidsweg Noord 60A-27
3812 PM Amersfoort

Telefoon: 033 258 5545

E-mail: info@archixl.nl

   

Nieuwsbrief

Wil je op de hoogte gehouden worden van nieuws en ontwikkelingen binnen ArchiXL?

Aanmelden voor de nieuwsbrief