door Eltjo Poort en Matthijs van Riel
Wat “architecten” we eigenlijk? Vele dingen worden uitgedacht, maar onderliggende principes zijn gelijk. Traditionele, projectgebaseerde governance gebruikt woorden als conveive, elaborate, construct, en transform zijn vervangen door agile termen: “funnel, backlog, analysis en implement. Architectuurwerk verplaatst zich daarmee, maar verdwijnt niet. De belangrijkste verandering is echter, dat je je als architect niet meer 6 maanden bezig bent met een project-start-architectuur, dat vrijgeeft, en dan pas aan de slag gaat. Dat is te traag. Je moet een snellere feedback-loop hebben. Als je je architectuur-beslissingen als primair artifact ziet, dan past dat als van nature in agile.
Het doel van architectuur is altijd al geweest om “the amount of uncertainty” zo snel mogelijk te verkleinen. Die cone wordt verkleind door het nemen van beslissingen. En dat is architectuur! In het begin neem je weinig beslissingen, maar die zijn wel het meest bepalend voor het verdere verloop van het project: bij iedere beslissing wordt de oplossingsruimte kleiner. Een voorbeeld: de basale beslissing in het begin: “we stoppen geen business logica of configuratie-data in de communicatielaag” was leidraad in verreweg het grootste deel van de vervolgbeslissingen. Niet persé hoogdravend, je zou zelfs kunnen zeggen “het intrappen van een open deur”, maar het had wel een grote impact. Alleen al het expliciet maken ervan was cruciaal!
Een volgende: “the best architectures, requirements and teams emerge from self organizing teams”. Emerge betekent niet “for free”. Van vroeger uit was er grote standaardisatie door de architect, nu is het meer “eventual integrity”. Er zijn harde regels, suggesties en nog niet genomen regels. Het deel “suggesties” is open aan zowel de architect en de developer, en dat vraagt overleg! Dat betekent ook dat er meerdere vormen van architectuur is. Van (crowd-sourced) “no named” via “marshalls” en “owners”naar de (centrale) “klassieke” architect (Stefan Toth). Binnen één organisatie kunnen alle vier de typen naast elkaar bestaan, afhankelijk van de type projecten.
Levensfasen architectuur
Welke term je ook gebruikt, iedere architectuur heeft een bepaalde levensloop, die Eltjo beschrijft aan de hand van de levensfasen van de mens:
- Birth: wat hebben onze stakeholders nodig? en hoe kunnen we dat leveren?
- Graduation: is dit het wel de moeite waard? Wat zijn de risico’s en kosten? Als die onder een drempel zijn, en je dat kunt bewijzen, dan krijg je goedkeuring! Ofwel “de business case” is een examen!
- Marriage: je committeert je aan de architectuur. Gaan we nog door? Dit is het moment van trade-off-analyse: na commitment is het erg moeilijk om nog aan te passen. Het moment van ATAM (dat zouden ze bij veel echte huwelijken ook moeten doen 😉
- Childhood
- Legacy
Traditioneel worden in projecten de graduation- en marriage-momenten samengenomen. In Agile moet je dat juist loslaten! En dat is vaak voor projectmanagers moeilijk. Het architectuurdocument an-sich wordt bijzaak, maar het gaat juist om beslissingen. Dus je kunt nadenken over wanneer je die neemt. En dat is Agile!