Het gebruik van agile-methoden (met Scrum als meest populaire) groeit sterk. Agile-aanpakken kenmerken zich door het in korte cycli (van enkele weken) opleveren van werkende en geteste software, waarbij het meest waardevolle als eerste wordt gedaan. Het werk wordt daarbij uitgevoerd door kleine zelfsturende en multidisciplinaire teams. Hoewel veel organisaties agile serieus overwegen of er al ervaring mee hebben, blijkt dat er in de praktijk nog veel misverstanden en vooroordelen over agile-methoden bestaan (zie Automatisering Gids 28 januari 2011: ‘Veel vooroordelen over Scrum’).

Een van die misverstanden is dat agile en architectuur niet samengaan. Door de flexibele en wendbare inslag van agile-aanpakken zou het niet mogelijk zijn om goed onder architectuur te werken. Dit is echter onjuist. In het kader bespreken we de zeven meest voorkomende misverstanden over het schijnbare conflict tussen agile en architectuur.

De hoofdoorzaak van deze misverstanden is dat agile-methoden zich sterk afkeren van ‘Big Design Up-front’. Agile-methoden gaan namelijk uit van voortschrijdend inzicht. Ze baseren zich op de ervaring dat gedurende het ontwikkeltraject geleerd wordt en er zo steeds meer helderheid ontstaat over het op te lossen probleem. Het is daarom onmogelijk om vooraf een volledig ontwerp te maken dat daarna ‘alleen nog maar gebouwd moet worden’. Om die reden gaat agile anders met architectuur om: agile laat de architectuur ‘ontstaan’ tijdens het project.

Misvatting
De grote misvatting is dat architectuur onlosmakelijk verbonden is met ‘Big Design Up-front’. Het is onzin om te stellen dat een architectuurbeschrijving een volledig uitgewerkt ontwerp moet zijn waarin alles in beton is gegoten. Architectuur kan prima functioneren met beschrijvingen op hoofdlijnen, vergezeld van een aantal architecturele principes die in latere iteraties gebruikt worden voor ontwerp en implementatie. Architectuur wordt daarmee wel op een andere manier ingezet maar is nog steeds heel waardevol, ook binnen agile. Ook de rol van een architect is daarmee niet uitgespeeld. Er blijft behoefte aan een persoon met overzicht, inzicht, ontwerpvaardigheden en de communicatieve vaardigheden om softwareontwikkelaars te inspireren en te helpen verstandige keuzes te maken. Echter, dat moet dan wel een agile-denkende architect zijn: een architect die dienend in het team staat en meedoet. Niet iemand die directief een architectuur oplegt zonder actief mee te werken (zie bijvoorbeeld: ‘De dienende architect’ door Viktor Grgic).

Concluderend kan gezegd worden dat Big Design Up-front en agile inderdaad een slecht huwelijk vormen, maar dat agile en architectuur uitstekend kunnen samenleven.

Zeven misverstanden over agile en architectuur

1 Agile negeert dat aanpassingen in de architectuur duur zijn

Aanpassingen met architecturele consequenties zijn kostbaar. Een architectuur is niet eventjes om te gooien. Het idee van een architectuur is dat deze bij voorkeur niet verandert. Agile legt echter juist de nadruk op het omarmen van verandering. Dit lijkt dus haaks te staan op het stabiel houden van de architectuur. Echter, het is helemaal niet het doel van agile-aanpakken om de architectuur zo vaak mogelijk te veranderen. Het is wel zo dat nieuwe inzichten die conflicteren met de dan geldende architectuur zo snel mogelijk bekend moeten worden, zodat ze ook snel in de architectuur verwerkt kunnen worden. Vandaar dat binnen agile heel frequent de software wordt vrijgegeven zodat deze gebruikt kan worden en nieuwe inzichten kunnen ontstaan. Daarom is het ook cruciaal om te prioriteren op waarde. De meest waardevolle zaken van een systeem zitten namelijk het sterkst in de architectuur verwerkt. Als daar wijzigingen in moeten komen dan moeten die zo snel mogelijk worden ontdekt. Agile zorgt daarvoor doordat het belangrijkste als eerste wordt gebouwd en direct kan worden gebruikt. Als daarbij noodzakelijke architectuurwijzigingen naar voren komen, dan zijn die sneller te verwerken omdat ze relatief vroeg bekend zijn.

2 Bij agile loopt de architectuur gevaar door het omarmen van wijzigingen

Agile-aanpakken ‘omarmen verandering’. Nieuwe inzichten en wijzigingsvoorstellen worden niet gezien als een bedreiging voor het halen van de einddatum of voor het slagen van het project, maar als kansen om het product beter te maken en de waarde te verhogen. Binnen agile wordt de architectuur daarom niet in beton gegoten maar aangepast wanneer dat nodig is. Het mag nooit zo zijn dat een grote waardeverhoging wordt afgewezen omdat de architectuur dat niet toestaat. Een architectuur is dienend en niet leidend. Verbeteringen die vragen om een aanpassing van de architectuur en de investering waard zijn, worden doorgevoerd. De business is verantwoordelijk voor de wijzigingsverzoeken via de backlog, de ontwikkelteams blijven binnen hun vakmanschap verantwoordelijk voor de kwaliteit tijdens de iteraties; dus ook voor de architectuur. En hoe later in het traject wijzigingen doorkomen, hoe kleiner de kans dat ze om aanpassingen in de architectuur vragen. Immers, agile pakt alle belangrijke zaken in het begin op en niet aan het einde.

3 Agile documenteert niet, dus wordt de architectuur ook niet vastgelegd

Het is waar dat agile een belangrijke nadruk legt op interactie, communicatie, eindresultaten en samenwerking. Het is echter onjuist te denken dat er binnen agile niets wordt gedocumenteerd. Documentatie die nuttig is (waarde heeft) wordt ook binnen agile opgesteld. In agile-aanpakken wordt een afspraak gemaakt wanneer iets echt af is; in Scrum staat dat bijvoorbeeld in de ‘definition-of-done’. Dus ook het bijwerken van een architectuurbeschrijving kan daarin worden meegenomen. Agile documenteert daar waar nodig, dus zeker ook de architectuurmodellen, maar alleen wanneer deze belangrijk zijn en gebruikt worden.

4 Bij agile bestaat de rol van architect niet, dus is er ook geen architectuur

De meeste agile-benaderingen gaan uit van zelfsturende en multidisciplinaire teams. Specifieke rollen als projectleider, analist of tester worden daar niet expliciet in onderkend. Hierdoor ontstaat soms de indruk dat er geen plaats meer is voor een architect en dus ook dat architectuur er niet meer toe doet. Dit is een misverstand. Ondanks multidisciplinaire teams zal er nog steeds behoefte zijn aan een totaalplaatje. Met het verdwijnen van specifieke rollen zijn niet tevens het belang en het nut van architectuur verdwenen. Het wordt alleen door het hele team opgepakt; ieder teamlid houdt zich bezig met de architectuur. Het opbouwen van domeinkennis binnen een team (en bij de product-owner) vraagt om tijd en ervaring. Een architect die over deze kennis beschikt kan daarom veel waarde hebben voor agile-teams, als teamlid, als product-owner of als adviseur (eventueel voor meerdere teams).

5 Agile is voor kleine projecten en dan is architectuur minder belangrijk

Een vaak gehoord misverstand is dat agile vooral geschikt is voor niet-kritische systemen en kleine projecten. Vooral in onderzoekende en innovatieve projecten zou agile de meeste waarde bieden, maar voor grote bedrijfskritische systemen met een lange levensduur ongeschikt zijn. Die laatste categorie systemen vraagt namelijk om een goed doordachte architectuur die in staat is om aan alle eisen (functioneel en niet-functioneel) te voldoen en de bedrijfs­zekerheid te waarborgen. Echter, bij dit soort systemen kunnen agile-aanpakken nu juist de meeste waarde bieden. Deze systemen zijn enorm gebaad bij het snel inspringen op nieuwe eisen om nog meer businesswaarde te leveren of om de businesscontinuïteit te waarborgen. Vooral tijdens de ontwikkeling van dergelijke systemen speelt voortschrijdend inzicht een cruciale rol, zowel voor de functionele als niet-functionele aspecten. En in dat geval biedt Agile zijn meerwaarde. Als voor deze systemen de architectuur cruciaal is, dan zullen ook agile-aanpakken zich snel en vooral continu bezighouden met die architectuur. En bij elke oplevering van een nieuwe versie van dit bedrijfskritische systeem wordt gekeken of het systeem nog steeds aan alle eisen voldoet.

6 Agile vergeet architectuur doordat er vooral naar de code wordt gekeken

Dit misverstand lijkt misschien op het derde misverstand in dit artikel, namelijk dat agile zich niet druk maakt over documentatie en vooral over programmeren gaat. Er zit echter een veel groter misverstand achter, namelijk dat een architectuur op papier staat: opgeschreven kan worden. Dit klopt niet. Architectuur zit maar op één plek en dat is: in de code. Architectuur is er altijd, zij zit in de software. Binnen agile wordt in korte cycli toegewerkt naar steeds weer een nieuwe versie van het softwaresysteem met de grootste toegevoegde waarde. Dat lukt alleen als je heel goed weet waar die toegevoegde waarde zit. Een goed overzicht over toegevoegde waarde leidt echter ook tot een goede opsplitsing van een systeem en een heldere kijk op de plaatsen waar wijzigingen te verwachten zijn en waar niet. In een agile-architectuur is er dus expliciete aandacht voor waarde aanwezig. Software levert namelijk pas waarde op als hij wordt gebruikt. Het product is pas af als het echt ‘done’ is. Dat geldt ook voor de architectuur: die is pas klaar als het product af is.

7 Agile is een soort prototyping, dus is architectuur minder belangrijk

Dit is vooral een misvatting over agile. Agile en prototyping lijken niet op elkaar. Een iteratie is iets heel anders dan een prototype. Een prototype gooi je weg. Bij agile gooi je iteraties niet weg, dus moet er heel goed over architectuur worden nagedacht. Immers, met alle keuzes word je in de volgende iteraties weer geconfronteerd. Architectuur staat dus juist centraal bij agile, alleen je accepteert dat niet alles vooraf volledig te bedenken is. Uiteraard wordt ook bij agile gezocht naar een passende architectuur op basis van de contouren van het systeem. Maar deze architectuur wordt niet in beton gegoten.

Kees Jan Bender is Senior Consultant en Solution Architect bij iSense Prowareness. Rini van Solingen is CTO bij iSense Prowareness en deeltijdhoogleraar Global Software Engineering aan de TU-Delft. Hij is auteur van ‘De Kracht van Scrum’. Beide auteurs spreken vrijdag 24 juni op het Agile Architecture Event (zie: www.prowareness.nl).