Select your language

De snelheid waarmee nieuwe technologie beschikbaar komt en de razendsnelle opkomst van nieuwe bedrijfsmodellen maakt wendbaarheid tot een noodzakelijke competentie voor organisaties. Agile en Lean werken kunnen hierin een grote bijdrage leveren. Dat leidt tot grote veranderingen in de wijze van werken, organiseren en ook in de cultuur van organisaties. Tijdens de overgang naar agile werken zijn 'architecten' al snel verdacht: Zij zijn degenen die vooraf een 'groot(s)' ontwerp willen maken; zij leggen beperkingen op aan ontwikkelteams die vernieuwingen willen realiseren; enzovoorts. Het werken onder architectuur moet ook veranderen, zodat het juist een versterking en versnelling van het agile werken oplevert.... maar hoe dan?

In dit artikel onderzoeken we het antwoord op deze vraag vanuit het perspectief van een project waarin de realisatie van een of meer applicaties of systemen met agile en scrum wordt georganiseerd. Het portfolio niveau wordt in een volgend artikel besproken <under construction>.

 

Architectuur in agile / scrum projecten

Agile werken wordt het meest toegepast binnen projecten, nog voordat de gehele organisatie (van systeemontwikkeling of breder) op een agile leest geschoeid wordt. Srcum is hierbij een van de meest gebruikte benaderingen, die we hier dan ook bekend veronderstellen. Hoe draagt de architect(uur) het beste bij aan het succes van een 'agile' project, zowel tijdens de uitvoering van het project als daarna? Het antwoord ligt in de eerste plaats al besloten in de formulering van deze vraag: De architecten moeten gericht zijn op het succes van het project en niet alleen op handhaving van bestaande of nieuwe regels uit de bovenliggende architecturen. In de praktijk blijkt de relatie met projectmanager(s), product owner(s), opdrachtgever en andere betrokkenen veel beter te werken, wanneer architecten vanuit deze grondhouding opereren. De rol van de architect is om de verbinding te maken, zodat het projectresultaat ook in het grotere geheel past en voldoet aan eisen als beheerbaarheid en aanpasbaarheid. Met de onderstaande praktische onderwerpen en tips kun je invulling geven aan de architectenrol(len) bij een agile project.

1. Succes van het project als 'Leitmotif' 

2. Van Project Start Architectuur (PSA) naar vraaggestuurde 'Projectarchitectuur'

3. Ondersteunen van de projectmanager, product owner en opdrachtgever

4. Balans tussen 'intentional architecture' en 'emergent design' (of kwaliteit voor korte en lange termijn)

5. Afhankelijkheden in de omgeving organiseren

6. Sparring partner van de scrumteams

7. Borging van de projectarchitectuur

Hieronder zijn deze onderwerpen nader ingekleurd. Met de werkwijze en samenwerking die hieruit ontstaat bereiken we een goede balans tussen agile werken en architectuur.

Wanneer hier wordt gesproken over 'de architect(en)' wordt gedoeld op de projectarchitect of solution architect, maar ook op domein- en thema-architecten en enterprise architecten die bij het project betrokken zijn. 

 

1 Succes van het project als Leitmotif 

Alle betrokkenen bij een project - agile of niet - zijn, als het goed is, gericht op het succes van het project. Daarbij kan de definitie van dat succes bij aanvang door iedere betrokkene nog wel verschillend ingevuld worden. Een architect die toezicht houdt op een project of als projectarchitect helpt in het project heeft mede als opdracht te zorgen dat het project voldoet aan de bovenliggende architecturen. In de praktijk kan dit gemakkelijk en ongemerkt leiden tot een opstelling waarin een architect vooral aangeeft wat niet voldoet omdat het strijdig is met eerderee architectuurkeuzes. Of de architect probeert een richting op te leggen aan het project, die niet wordt gedeeld door bijvoorbeeld de scrumteams, omdat zij een andere oplossing voor ogen hebben. Het gevolg hiervan is een zich herhalend patroon, waarbij de architecten tegenover de andere projectbetrokkenen komen te staan. De kans is groot dat het projectteam, gesteund door de opdrachtgever, een andere richting wil kiezen of in de agile context een keuze wil uitstellen ("Laten we gewoon beginnen, dan ontdekken we wel hoe dit wordt opgelost!"). Het is duidelijk dat de invloed van de architect(en) op het project beperkt zal zijn. Bijsturen leidt tot frictie en 'technical debt' die later moet worden opgelost. 

Een architect die als Leitmotif 'succes van het project' kiest, zeker in de communicatie met opdrachtgever, projectleider en projectteam kan daarom veel beter bijdragen en kan zich ontwikkelen tot een gewaardeerd adviseur voor alle betrokkenen. Vanuit die positie is het eenvoudiger om eventuele beperkingen of vooraf vastgestelde keuzes vanuit de enterprise of domeinarchitectuur als onderdeel van de oplossing te presenteren. Hierbij past ook om waar nodig (agile!!) eerder vastgestelde kaders ter discussie te stellen, wanneer de leerervaring vanuit het project hiertoe aanleiding geeft.

 

2 Van Project Start Architectuur naar vraaggestuurde 'Projectarchitectuur'

Een Project Start Architectuur (PSA, conform DYA®) is bedoeld om de (architectuur)kaders vast te leggen waarbinnen het project gerealiseerd moet worden, inclusief een globale schets van de oplossing. De PSA wordt opgeleverd samen met het Project Initiatie Document (PID) of projectplan en vormt hiermee een twee-eenheid. Bij agile projecten levert het opstellen van deze documenten een forse spanning op, omdat een 'big design up front' niet past in de agile en lean denkwijze. Dit betekent dat de architectuur vorm krijgt gedurende de loop van het project. De PSA kan dan het beste worden gezien als de eerste versie(s) van de projectarchitectuur. Een aanpak die daarbij in de praktijk goed werkt is om in de architectuurdocumentatie een lijst met nog te beantwoorden (architectuur)vragen op te nemen, waardoor een vraaggestuurde projectarchitectuur ontstaat. Je kunt dit ook de backlog voor de architectuur noemen. Deze aanpak past goed in de agile benadering waarbij onzekerheid gedurende het project wordt omgezet in een werkende oplossing. De vragen maken duidelijk op welke punten het architectuurwerk hieraan bijdraagt.

Voor een PSA (projectarchitectuur bij het projectplan/PID) moeten voldoende vragen zijn beantwoord om:

  • de initiële businesscase voor het project op te stellens;
  • de scope van de oplossing (diensten, processen, applicaties en infrastructuur) of het probleem voldoende af te bakenen;
  • de afhankelijkheden met andere projecten en systemen op hoofdlijnen in beeld te brengen;
  • de backlog voor de eerste iteraties van de scrumteams te vullen; 
  • de belangrijkste risico's van het project af te dekken, deels door procesafspraken over vervolganalyses en keuzemomenten;
  • een initiële kostenraming ('lean budget)' voor het project op te stellen. 

Hiermee geven we invulling aan het principe 'just enough, juist-in-time architectuur'. Wat genoeg of voldoende uitwerking is hangt mede af van de positie die stakeholders hierbij innemen. Dit laat zich samenvatten in het antwoord op de vraag: Hebben de gezamenlijke stakeholders (waaronder natuurlijk de opdrachtgever, projectmanager en projectteam) op basis van de vastgelegde hoofdlijnen vertrouwen in een succesvol project? Zo ja, dan snel van start! Naarmate in de organisatie meer ervaring is met agile werken zal het antwoord sneller 'ja' zijn.

 

3 Adviseren van de projectmanager, product owner en opdrachtgever

In lijn met de voorgaande punten zullen de projectarchitect of solution architect, maar ook domein- en thema-architecten en enterprise architecten gericht zijn op het projectsucces en de beantwoording van relevante architectuurvragen. De precieze invulling van de architectenrollen hangt af van de concrete casus en organisatie, maar meestal zal één van de architecten de rol van projectarchitect vervullen (dat kan in de praktijk ook de domein- of thema-architect zijn). De projectarchitect is bij voorkeur lid van het projectteam en coördineert vanuit die rol de bijdragen van andere architecten aan het project.

De product owner is verantwoordelijk voor het vullen van de backlog en prioriteert in overleg met de projectmanager en stakeholders de user stories. De architect(en) ondersteunen hierbij door tijdig de projectarchitectuur in te kleuren, zodat duidelijk wordt wat er gerealiseerd en voorbereid moet worden in de scrumteams. De projectarchitectuur geeft hierbij zicht op de scope van de oplossing, de globale oplossingsrichting en componenten waaruit de oplossing bestaat en randvoorwaarden die hierbij moeten worden ingevuld. De product owner(s) en stakeholders zijn natuurlijk betrokken bij het vormgeven van de architectuur, bijvoorbeeld door deelname aan ontwerpsessies waarin ook demo's van de reeds gerealiseerde onderdelen gegeven kunnen worden. Een belangrijk aandachtspunt voor het projectteam is hoe het werk wordt verdeeld over de teams en hoe de beschikbare competenties in de scrumteams aansluiten op hetgeen gerealiseerd moet worden. Zo vormt de architectuur de basis van waaruit de scrumteams zo zelfstandig mogelijk (onderdelen van) de oplossing kunnen realiseren. 

De architecten adviseren niet alleen de projectmanager en product owner, maar adviseren ook de opdrachtgever(s) als kwaliteitsbewaker voor het project en vanuit zicht op het grotere geheel, van waaruit de globale oplossingsrichting wordt bepaald. In de driehoek opdrachtgever - projectmanager - architect worden afspraken voorbereid over de scope en richting van de oplossing en de wijze waarop de belangrijkste risico's worden afgedekt. De nadruk van de architect ligt daarbij op inhoud en kwaliteit van de oplossing, terwijl de projectmanager in de praktijk vaak de nadruk legt op de benodigde middelen, organisatie en doorlooptijd.

 

4 Balans tussen 'intentional architecture' en 'emergent design' (of kwaliteit voor korte en lange termijn)

Scrumteams hebben een grote mate van vrijheid nodig om zelfstandig de beste oplossing te kunnen realiseren. De (deel)oplossing die door een team gerealiseerd wordt staat echter niet op zichzelf: Het is een afgebakende component in een groter geheel, er zijn afgesproken standaarden en begrippen (onder meer in het datamodel), er zijn te hergebruiken standaard componenten, enzovoorts. Ook moet de gerealiseerde oplossing niet alleen nú werken voor de afnemers, maar ook in de toekomst kunnen worden uitgebreid en verbeterd. Dit vraagt om een goede balans tussen de 'intentional architecture' en het 'emergent design' dat vanuit de realisatie duidelijk wordt. Je kunt ook zeggen dat de oplossingsruimte voor het team begrensd wordt door de (project)architectuur, waarbij er voldoende ruimte moet zijn om een optimale oplossing te realiseren.

Het bewaken van deze balans is een uitdaging voor de betrokken architecten. De onderstaande punten kunnen hierbij helpen:

  • Geef de scrumteams informatie 'op maat' over de projectarchitectuur;
  • Zorg voor voldoende zicht op het emergent design (onder meer door betrokkenheid bij refinement van user stories en sprint reviews);
  • Vraag je af waar blokkades voor toekomstige ontwikkelingen kunnen ontstaan en welke keuzes dat kunnen oplossen;
  • Betrek de scrumteams (lead developers) bij het oplossen van vragen voor de projectarchitectuur; 
  • Geef de product owner en scrumteams zo goed mogelijke informatie over gemaakte afspraken en standaarden (bijvoorbeeld tijdens refinement sessies of de voorbereiding daarop).

 

5 Afhankelijkheden in de omgeving van het project organiseren

Eén van de lastigste taken voor scrumteams is het beïnvloeden van de omgeving waarvan het team deels afhankelijk is. Zelden staat een oplossing geheel op zichzelf en vaak zijn interfaces met andere processen en systemen nodig voor een succesvol project. Hier kunnen de architecten een belangrijke bijdrage leveren, want zij overzien ook de andere systemen of applicaties en de ontwikkelingen die daarin plaatsvinden. Ook kunnen de architecten richting geven aan de andere projecten of zorgen voor directe afstemming en afspraken tussen project- en scrumteams. 

Een belangrijk hulpmiddel hierbij zijn één of meer contextdiagrammen in de projectarchitectuur en een overzicht van gebruikte infrastructurele voorzieningen (ook voor development, security enz.) en bestaande en toekomstige koppelingen tussen applicaties.  

 

6 Sparring partner van de scrumteams

Uit het voorgaande blijkt al dat de projectarchitect een sterke verbinding met de scrumteams (incl. product owners) nodig heeft. Wanneer binnen de teams belangrijke keuzes over de inrichting gemaakt moeten worden is de projectarchitect een 'natuurlijke' sparring partner voor het team. Deze relatie komt meestal niet vanzelf tot stand en moet actief gestimuleerd worden. De projectarchitect volgt hiervoor actief de user stories die voorbereidend zijn op volgende sprints en die expliciet of impliciet om een keuze vragen voor de wijze van realiseren. Ook kan de proiduct owner in dergelijke user stories opnemen dat afstemming met de projectarchitect (en/of andere architecten) vereist is. De projectarchitect neemt relevante keuzes over in de projectarchitectuur, zodat alle teams overzicht hebben omtrent de belangrijkste keuzes.  

 

7 Borging van de projectarchitectuur 

De projectarchitectuur wordt actief beheerd gedurende de looptijd van het project, maar heeft na afronding van het project geen bestaansrecht meer en zal 'verouderen' doordat latere wijzigingen niet verwerkt worden. Daarom is het belangrijk dat relevante informatie uit de projectarchitectuur ergens wordt vastgelegd en beheerd, waarna de projectarchitectuur zelf kan worden gearchiveerd. Enerzijds zullen veel beslissingen worden opgenomen in de relevante domeinarchitectuur en/of thema-architecturen. Informatie over de interne structuur van de oplossing (appicatie) kan worden vastgelegd in een applicatie-architectuur, die als onderdeel van het applicatiebeheer steeds actueel wordt gehouden.

In de meeste agile projecten wordt gebruik gemaakt van een wiki waarin relavante documentatie (zoals de resultaten van 'onderzoekstories') wordt vastgelegd. De applicatie-architectuur kan integraal onderdeel zijn van deze omgeving, waarbij periodiek een versie van de applicatie-architectuur gegenereerd wordt uit deze documentatie.

  

 

Deze website gebruikt cookies voor functionele doeleinden en verbetering van de site. We gebruiken geen cookies voor marketing doeleinden en advertenties. Door de site te gebruiken accepteer je deze cookies.
Ok