Van Agile startarchitectuur naar Solution Intent

De uitdaging en de Solution Intent

Bij de realisatie is voldoende begrip door de teams nodig van zowel de beoogde oplossing, als van de rol die agile architectuur speelt in de totstandkoming en doorontwikkeling van deze oplossing. We hebben een spreekwoordelijke stip op de horizon nodig maar ook een goed begrip van het huidige systeem.

In de Solution Intent wordt de kennis over het huidige en beoogde oplossing opgeslagen, beheerd en gedeeld. Waar nodig omvat dit zowel vaste – als variabele specificaties en ontwerpen, verwijzingen naar normen, systeemmodellen en worden  zo de functionele als niet-functionele requirements vertaald naar de (solution) architectuur.

De Solution Intent is een middel om een ​​doel te bereiken, een hulpmiddel om inzicht te verkrijgen, besluitvorming te ondersteunen en om naleving van gemaakte afspraken te kunnen toetsen. De beste strategie is, voldoende documentatie (Just Enough Architecture – JEA) en beschikbaar wanneer dat nodig is (Just In Time – JIT).

En daarbij kan de Agile Start Architecture (ASA) helpen.

Start de Solution Intent vanuit de ASA

In veel gevallen starten de agile teams met implementatie zonder enige kennis van de architecturele context. Daarop wachten wordt als vertragend ervaren. In de praktijk blijkt deze architecturele context toch echt nodig. Denk bijvoorbeeld aan een huis waarin een keuken moet komen. De inrichting van de keuken staat nog niet vast, maar er kan wel alvast met bepaalde standaarden rekening gehouden worden, zoals de afmetingen van inbouwapparatuur.

Door met de teams een ASA op te stellen worden een minimaal noodzakelijke context (het fundament) en richtlijnen vanuit de architectuur neergezet.

Dit is tevens een goed begin en stimulans om met de Solution Intent te starten en deze te blijven gebruiken. De Solution Intent bestaat uit een vast en variabel deel om te zorgen dat niet alle specificaties vooraf beschreven hoeven te worden.  Het vaste deel omvat de specificaties die vanaf het begin af bekend zijn, zoals PCI- of AVG standaarden. Deze staan vast en zijn niet onderhandelbaar.

Door in de ASA een aantal onderwerpen te benoemen wordt het vaste deel van de Solution Intent al opgezet en bereiden we het variabele deel voor, zoals:

• Business domein thema’s die vanuit de doelen van de organisatie vertaald worden naar architecturele thema’s;
• Diverse basismodellen en views om de architectuur van de oplossing op hoofdlijnen helder en samenhangend te beschrijven;
• Architectuur requirements en architectuur vraagstukken (enabling value);
• Detail requirements die in de (solution) architectuur geborgd moeten worden.

Het variabele deel van de Solution Intent bevat onderdelen die het voor agile teams mogelijk maakt om verschillende oplossingen te verkennen. Om specificaties te verhuizen van het variabele deel naar het vaste deel is onderzoek nodig waarmee de kennis vergroot wordt die nodig is om besluiten te nemen.

Bijhouden van de Solution Intent

Een architectuur is constant in beweging. Iedere oplossing heeft zijn eigen Solution Intent die wordt bijgewerkt, in samenwerking en samenspraak met de teams die de oplossing realiseren. Zo ontstaat een dynamisch geheel dat op basis van voortschrijdend inzicht continu verder wordt ontwikkeld – uiteraard wel altijd gericht op de waarde van de oplossingen (solution) die moet worden gerealiseerd. Hierbij is onderlinge afstemming tussen de teams en de architect(en) cruciaal.

Wat zijn hierbij de best practices?

Houd alle opties zo lang als mogelijk open

Door besluiten (zolang dit economisch haalbaar is) uit te stellen sluit je zo goed mogelijk aan op de steeds veranderende context, eisen en wensen waarbij voortschrijdend inzicht maximaal wordt benut. In Set-Based Design (SBD) worden eisen en ontwerp-opties zo lang mogelijk flexibel gehouden tijdens het ontwikkelproces. In plaats van vooraf een enkele oplossing te kiezen, identificeert en verkent SBD tegelijkertijd meerdere opties, waardoor suboptimale keuzes in de loop van de tijd worden geëlimineerd.  Dit vraagt een nauwe en brede samenwerking tussen de teams, Architect(en) en Product Managers/Product Owners.

Blijf breed samenwerken met de focus op de solution

Het maken van de Solution Intent is een creatief proces, waarbij het bedenken, geven van feedback en het verfijnen van Solution Intent door ieder teamlid kan worden gedaan. Werk maximaal samen, goede ideeën en nieuwe inzichten komen uit alle lagen van de organisatie.

Communiceer helder: (zo) simpel (mogelijk) en op een precies voldoende detailniveau.

Leg alleen vast wat nodig is om de noodzakelijke besluiten te kunnen nemen. Specificeer detail alleen waar nodig en doe dit zo laat mogelijk. Te veel details vertragen communicatie onnodig en beperken de flexibiliteit bij het uitwerken van oplossingsopties.

Gebruik gemakkelijk te onderhouden documentatiestandaarden: liever modellen dan tekst

De solution is levend, dus de documentatie hiervan is continu aan verandering onderhevig. Wijzigingen in de context, wensen en eisen door voortschrijdend inzicht moeten worden gedocumenteerd. Dit kan arbeidsintensief zijn. Gebruik daarom modellen en visualisaties die gebruikt worden bij Design Thinking, User-Centered Design en Enterprise/Software architectuur. Dit geeft snel en eenduidig inzicht waarbij ook samenhang doeltreffend inzichtelijk gemaakt wordt.

Beheer documentatie op slechts één plek (Single Source of Truth, SSOT)

Maak alle wensen, eisen, beschrijvingen, beslissingen en ander relevant materiaal gemakkelijk toegankelijk, vanuit één lokatie. Dit dient als de ‘Single Source of Truth’. Moderne platformen, zoals Microsoft Teams, bieden mogelijkheden om informatie uit diverse bronnen centraal te ontsluiten, hieraan samen te werken en over te communiceren.

Decentrale besluitvorming ondersteunen

Om nieuwe kennis en nieuwe ideeën te verkennen, zullen verschillende teams hiermee aan de slag gaan. Om trage besluitvorming te voorkomen, stimuleert agile werken om beslissingen decentraal te nemen. Niets is zo frustrerend en vertragend voor teams als ze een nieuw idee hebben verkend maar moeten wachten op centrale besluitvorming terwijl dit niet nodig is. Men moet wel de Solution Intent bijwerken zodat de SSOT centraal te managen en te raadplegen is.

De rol van de agile architect 

De agile architect zorgt er voor dat de teamleden aan de solution werken op basis van de vastgestelde principes en keuzes die in de Solution Intent zijn opgenomen. De architect initieert en stimuleert dit door te starten met een Agile Start Architecture, ook al zijn de Solution Architectuur en de Solution Intent nog niet beschikbaar. Op deze manier wordt optimaal – en bottom up vanuit de teams – gewerkt aan een continu en snel evoluerende oplossing.

Communicatie en samenwerking tussen architect(en) en agile teams dient vanuit een zelfde manier van denken te gebeuren. Zowel architecten als de leden van het development team spreken elkaar aan op het volgen van de agile principes. De architect stelt zich dienstbaar op en zorgt ervoor dat hij beschikbaar en betrokken is bij de teams. Hij/zij laat zien dat de architect het team helpt en er voor het team is. Tegelijkertijd laten de teams zien dat ze de architect ondersteunen, meewerken en meedenken. Zo ontstaat een vruchtbare samenwerking en cultuur waarin wederzijds respect en vertrouwen kernwaarden zijn.

Architecten zijn mede verantwoordelijk voor de oplossing en voeden de feedback-loop vanuit en met de agile teams. Op deze manier nemen de agile teams zelfstandig hun beslissingen waarbij de architect de impact van deze beslissingen op andere teams in de gaten blijft houden.

Samenvatting en conclusie

De Solution Intent is de Single Source of Truth die agile teams doeltreffend ondersteunt bij de ontwikkeling van solutions. Agile teams neigen implementaties te starten zonder enige kennis van de architecturele context, terwijl architecturele context toch echt nodig is. De Agile Start Architecture is een eenvoudige en goede basis waarmee de Solution Intent snel kan worden gestart.

Cruciaal is dat de Solution Intent ook wordt onderhouden, waarbij de teams en architecten nauw samenwerken. Dat is een proces waarin Intentional Architecture en Emergent Design continu op elkaar afgestemd worden. Het is een samenspel waarin balans gezocht wordt tussen korte en langere termijn, waarbij verschillende belangen kunnen botsen.

Heldere communicatie, elkaar blijven betrekken en vertrouwen vormen hiervan de basis: een echte cultuur van samenwerken!

Just do it! Dare to change!

Wij vormen een team consultants bij Capgemini die voor de uitdaging staan ​​om Agile en Architectuur te combineren tot de rol van Agile Architect. De komende tijd publiceren we een serie blogs over de impact die Agile heeft op de rol van de Architect.

Onze eerste blog vind je hier:

De toegevoegde waarde van de Agile Start Architectuur: https://www.capgemini.com/nl-nl/2021/06/de-toegevoegde-waarde-van-de-agile-start-architectuur/

Ons team bestaat uit:

Ben Kooistra Wiger Levering Timo Haakman Hans van Zanten René Beltman Joop Koster

Gert-Jan Kooren Vassil Stoitsev Martin Brommer Jeroen Dijkstra Hans van Rijs Mirko van der Maat

Auteur

Ben Kooistra