Architectuurontwerp met autonome teams

Volgens het agile manifest ontstaan de beste architecturen uit zelforganiserende teams. Het woord ontstaan (‘emerge’) heeft hier enige kritiek gekregen, omdat het lijkt te impliceren dat zo’n architectuur vanzelf tot stand komt (dat is niet zo), en dat dat geen aanzienlijke inspanning vergt (dat is wel zo). Ik geef hier de voorkeur aan het woord ontwerpen (in plaats van ontstaan), omdat het wijst op een doelbewuste activiteit. De belangrijkste boodschap van dat beroemde (of beruchte) emergentieprincipe is niet om intentioneel ontwerpen te ontmoedigen, maar om duidelijk te maken dat agile teams het beste werken als ze autonoom zijn. Met andere woorden, een buitenstaander mag niet de architectuur dicteren - de teams ontwerpen die zelf.

Het uiteindelijke gevolg van bovenstaande principe is dat agile teams competenties voor het ontwerpen van architecturen nodig hebben. Vorig jaar speelde Transavia, een van onze klanten, in op deze behoefte. Zij wilden de vaardigheden van hun agile teams op dit gebied aanscherpen en vroegen ons een opleidingscurriculum voor architectuurontwerp te ontwikkelen voor niet-architecten. Elk van hun 20 teams werd uitgenodigd om een vertegenwoordiger aan de cursus te laten deelnemen, als gids voor het architectuurontwerpproces in hun zelforganiserende team. Sommige teams stuurden producteigenaren, andere tech-leads, zo af en toe een informatieanalist. We hebben 10 volle dagen met hen doorgebracht, verspreid over drie maanden, in een soort Architecture Boot Camp, en we hebben daar veel van geleerd.

Autonoom architectuurdenken

Het leren begon voor ons meteen met de selectie van de cursusonderwerpen. Naast de noodzakelijke technische inhoud, zoals inleidingen in moderne softwaretechnologieën, applicatie-integratie en beveiligingsstrategieën, moesten we het concept van architectuurdenken overbrengen. Wat is architectuurdenken in een agile team?

Op basis van onze eerdere ervaringen met architectuurontwerp in teams besloten wij ons te concentreren op twee belangrijke aspecten:

• Architectuur zien in termen van stakeholderwaarde
• Afwegingen maken bij ontwerpbeslissingen

Architectuur in termen van stakeholderwaarde

Een van de problemen die agile teams hebben met architectuur is dat het soms wordt gezien als iets dat bedrijfswaarde in de weg staat in plaats van mogelijk maakt. Daar kunnen verschillende redenen voor zijn. Zo worden verbeteringen onder de motorkap, zoals refactoring of het leggen van architecture runway, gezien als het weglekken van capaciteit bij de teams - capaciteit die anders gebruikt zou kunnen worden om nieuwe features te creëren. Een ander voorbeeld zijn architectuur-compliance regels die teams beperken in hun ontwerpkeuzevrijheid en vertragingen kunnen veroorzaken.

In ons curriculum draaien we deze perceptie om, zodat architectuur door de teams en hun tegenhangers in de business als iets positiefs wordt gezien. Een belangrijke vaardigheid daarbij is het vertalen van de impact van dit architectuurwerk (de enablers) in bedrijfstermen, zodat de waarde ervan gemakkelijker kan worden uitgelegd aan belanghebbenden. Dit geeft teams ook het vertrouwen om belanghebbenden in de business te benaderen om deel te nemen aan het ontwerp van 'hun' enablers. Deelnemers aan de cursus doen een aantal oefeningen gericht op het spreken van de taal van de business, zoals een business case voor vermindering van technical debt. Ze oefenen ook technieken zoals architectuur-roadmapping om enablers te prioriteren op basis van huidige en toekomstige bedrijfsbehoeften.

Afwegingen bij ontwerpbeslissingen

Een focus op de waarde voor de belanghebbenden leidt ook tot betere ontwerpbeslissingen. Kennis van goede ontwerpprincipes alleen is niet voldoende op architectuurniveau: architectuur is context, dus voor beslissingen met grote impact moeten de teams in staat zijn de beslissingscriteria te herleiden tot de waarde voor de belanghebbenden. En dat vereist vaak een veel nauwere betrokkenheid van business stakeholders dan teams gewend zijn. Maar hoe krijgen we de aandacht van 'de business' voor onderwerpen die op het eerste gezicht puur technisch lijken?

Business stakeholders betrekken bij ontwerpbeslissingen lijkt soms een flinke uitdaging, maar dit is waar de vaardigheid 'architectuur in termen van stakeholderwaarde' loont. Hun betrokkenheid bij het besluitvormingsproces is eigenlijk heel essentieel, want zonder die betrokkenheid kan het team niet de zo belangrijke waarom-vragen stellen die de echte verhalen en drijfveren achter de eisen van de belanghebbenden blootleggen. Dergelijke achtergrondverhalen leiden vaak tot nieuwe, voorheen onbekende beslissingscriteria, die op hun beurt het ontwerp van het team volledig kunnen omgooien - wat leidt tot oplossingen die aanzienlijk beter aansluiten bij de behoeften van de business.

Een techniek die erg populair is gebleken (en gemakkelijk in de praktijk toe te passen) zijn decision stories. Een decision story vat de essentie van een ontwerpbeslissing in één zin, net zoals een user story dat doet voor een business-behoefte: "In de context van <context>, geconfronteerd met <vraagstukken>, hebben we besloten voor <keuze>, en niet <afgewezen alternatieven>, om <criteria> te bereiken, waarbij we accepteren dat <nadelen>." De kracht van de decision story is dat hij beknopt genoeg is om snel de essentie van een beslissing te doorgronden, maar toch een redelijke mate van onderbouwing stimuleert. Het opnemen van afgewezen alternatieven en nadelen is bijzonder waardevol gebleken, omdat het laat zien dat er werk is gestopt in de beslissing, en dat het team zich bewust is van alternatieven en nadelen. De decision story laat de lezer zien dat het team niet gewoon het eerste het beste idee heeft gevolgd. Teams die deze techniek gebruiken, vinden het gemakkelijker om belanghebbenden ervan te overtuigen dat hun ontwerp goed in elkaar zit. Wij gebruiken decision stories als waardevolle aanvulling op uitgebreidere technieken zoals trade-off tabellen en ADR's (Architectural Decision Records).

Ervaringen

Dat was het: alle vaardigheden die wij essentieel vonden voor architectuurdenken. "Leren jullie ze niet over modelleren en documenteren", zult u zich misschien afvragen? Zeker, daar besteden we ook enige tijd aan - maar altijd in het licht van de waarde voor de belanghebbenden, zoals blijkt uit onze aanpak voor waardegedreven architectuurdocumentatie.

Het is nu drie maanden geleden dat de eerste lichting teamleden het Architeture Boot Camp heeft gevolgd, en uit een eerste evaluatie blijkt dat de effecten van de training zichtbaar worden. De teams beginnen ontwerpbeslissingen te documenteren en betrekken hun stakeholders bij het proces. Tijdens de evaluatie werd ook duidelijk dat de grootste uitdaging voor sommige teams inderdaad is om de aandacht van de business stakeholders te krijgen. Teams die vooraf niet goed op één lijn zaten met hun belanghebbenden in de business, vonden het veel moeilijker om het geleerde toe te passen. Er is hier ook een rol weggelegd voor de architecten van de organisatie buiten de teams - zij kunnen de getrainde teamleden coachen en helpen omgaan met problemen die de teamgrenzen overschrijden, door de Architect Elevator (ook onderdeel van de bootcamp-training) te berijden.

Uit onze discussies over architectuur elders blijkt dat niet alleen Transavia behoefte heeft aan architectuurontwerpvaardigheden in teams. Om de ontwikkeling van deze vaardigheden in andere organisaties te faciliteren, hebben we onlangs de Architecture Boot Camp beschikbaar gesteld als een open inschrijving curriculum. Als u geïnteresseerd bent: de eerste open architectuur bootcamp vindt van maart tot mei 2023 in Nederland plaats.