Agile en Architectuur: niet tegenstrijdig, maar complementair

Gepubliceerd: 14 oktober 2010 | In: Artikelen > Agile | Door: Edzer Lawerman - Bart Bouwman - Fedor Rutgers -
Peter Tjeerdsma

Een architectuur ontwikkelen in een Agile omgeving roept direct vraagtekens op. Deze
combinatie lijkt niet bij elkaar te passen en vraagt om problemen. Echter, niets is minder waar.
Wanneer we de sterke en zwakke kanten van beide aanpakken naast elkaar leggen, blijken ze
juist complementair te zijn en elkaar zelfs te versterken. Een denktank van technisch
automatiseerder TASK24 heeft zich gebogen over het toepassen van een minimalistische
architectuur in Agile-projecten, een aanpak die de sterke kanten van Agile en architectuur
verenigt.

Stel je eens voor; een huwelijk tussen een Agilist en een architect. Op een mooie zomerdag besluiten ze samen op
vakantie te gaan. De architect houdt van een gedegen voorbereiding. Hij anticipeert op alle mogelijke
weersomstandigheden. Een tijdrovende taak en veel bagage met winterkleding, zomerkleding en regenkleding is het
gevolg. De Agilist bekijkt de weersverwachting een dag van tevoren en neemt maar één passend setje kleren en een
creditcard mee. Hij ziet wel wat voor weer het wordt en koopt passende kleding als hij toch niet de goede kleren
meegenomen heeft. Raar voorbeeld? Nee, tegenwoordig worstelen steeds meer Agile-projecten met het probleem welke
beslissingen je van tevoren moet nemen en welke juist niet. Wat te doen met architectuur? Onnodige ballast of juist
essentieel voor het succes?

Agile en architectuur lijken in tegenspraak met elkaar. Bij architectuur denken veel mensen aan dikke documenten en bij
Agile aan snel software ontwikkelen zonder veel documentatie. Maar als we beter kijken, hebben de twee aanpakken
elkaar nodig en kunnen ze elkaar zelfs versterken. Hieronder hebben we verschillende valkuilen van beide aanpakken
beschreven. Het mooie is dat we de valkuil van de een door een maatregel van de ander kunnen ondervangen.

Onnodig complex
Een valkuil van een architectuurgebaseerde ontwikkelmethode is het creëren van draagvlak bij het ontwikkelteam. Denk
maar aan de architect die vanuit zijn ivoren toren een architectuur bedenkt en vervolgens overdraagt aan het
ontwikkelteam. De Agile-aanpak biedt hiervoor een oplossing: de ontwikkeling van de architectuur is een teamactiviteit,
waardoor het draagvlak van de gezamenlijk gedefinieerde architectuur groot zal zijn.

Een architectuur die alleen nog op papier bestaat, heeft zich nog niet bewezen. Er kleven daarom risico’s aan. Een Agile-
oplossing hiervoor is om architectuurconcepten vroegtijdig op correctheid en haalbaarheid te toetsen door middel van
werkende software.

Een valkuil bij een Agile-ontwikkelmethode is dat niet iedere betrokkene een duidelijk beeld heeft van de belangrijkste
systeemeigenschappen. Om alle neuzen dezelfde kant op te laten wijzen, moeten we de systeemeigenschappen en de
argumentatie waarom deze essentieel zijn voor het succes van het systeem met elkaar communiceren. Dit is een
belangrijke stap in de ontwikkeling van de architectuur. Deze informatie wordt bij voorkeur niet gecommuniceerd via
documenten, maar in de vorm van presentaties, plaatjes en schetsen.

Een veel voorkomend probleem bij Agile is het opschalen van het ontwikkelteam. De communicatie in een groep van vijf
tot zeven personen is relatief eenvoudig. Wanneer de ontwikkelteams groter worden, hebben we een architectuur nodig
om verantwoordelijkheden duidelijk te kunnen verdelen. Architectuur knipt het systeem op in kleinere stukken en laat de
relaties daartussen zien. Door bijvoorbeeld een afbeelding hiervan voor iedereen zichtbaar op te hangen, heeft iedereen
ook hetzelfde beeld van de verdeling van verantwoordelijkheden en een overzicht van de interfaces.

Als het systeem verder evolueert in een Agile-omgeving, bestaat de kans dat aanpassingen aan de software,
bijvoorbeeld in de vorm van code-refactoring, zich gaan richten op het optimaliseren van een eigenschap van een enkele
module ten koste van de eigenschappen van het totale systeem. Dergelijke suboptimalisaties, die eigenlijk afbreuk doen
aan het systeem als geheel, zijn te voorkomen door een goede architectuur te gebruiken. Dit zorgt ervoor dat we het
overzicht over het gehele systeem behouden. Daarbij moeten we de belangrijkste systeemeigenschappen blijven
benadrukken.

In veel projecten wordt een architect verleidt om een architectuur in één keer van tevoren neer te zetten, omdat het
project dan beter beheersbaar lijkt. Voor eenvoudige systemen kan dit werken, maar bij de huidige complexe systemen
is first time right vrijwel onmogelijk. Agile ondervangt dit door de architectuur in iteraties te ontwikkelen, zodat we het
complexe probleem niet in één keer oplossen, maar in meerdere overzichtelijke stappen. De architectuur evolueert als
het ware.

Omdat kwaliteitseisen de architectuur sterk bepalen, brengt de traditionele architectuuraanpak alle kwaliteitseisen van
tevoren in kaart. In de praktijk werkt dit maar gedeeltelijk; de werkelijke kwaliteitseisen ontstaan pas door feedback op
een werkend systeem. Door non-functionele eisen zoals, "het systeem moet snel reageren" te kwantificeren bestaat er
het gevaar dat de eis te strikt wordt gemaakt. Neem als bijvoorbeeld de requirement dat een televisie binnen 150ms
moet zappen naar een ander kanaal. Dit kan erg belastend zijn voor de architectuur, terwijl 500ms misschien ook goed
werkt als je het beeld zwart maakt tijdens het wisselen zodat de teletekst lijnen niet door het beeld vliegen. Agile
voorziet hierin door op vaste tijden een werkend systeem op te leveren, zodat de klant daar direct feedback op kan
geven.

Een valkuil van veel architecten is het overmatig gebruik van generieke concepten en patterns. Dit leidt vaak tot een
onnodig complexe architectuur. In het ergste geval resulteert het in een architectuur die is voorbereid op alles, behalve
op wat er echt gaat komen. Agile geeft hier een antwoord op door zo eenvoudig mogelijk te beginnen en daarna te
refactoren. Genericiteit ontstaat alleen daar waar het werkelijk de software vereenvoudigt.

Minder risicovol
De versterkende factor van Agile en architectuur komt het best naar voren bij het gebruik van een minimalistische
architectuur. Deze bestaat slechts uit die ontwerpbeslissingen die de kritische systeemeigenschappen garanderen.
Hiermee bepalen ze het succes van het systeem voor de business. Het is dus een compacte en daarmee eenvoudig te
veranderen set ontwerpbeslissingen. Het gaat erom dat de businessdoelen de architectuur bepalen en niet andersom. Te
vaak komt het voor dat een architectuur moeilijk aan te passen is, waardoor die de businessdoelen juist gaat
belemmeren.

Wij stellen voor om eerst een minimalistische architectuur te definiëren en daarna het systeem feature voor feature te
realiseren. De architectuur evolueert met de ontwikkeling van iedere feature. Allereerst bouwen we de
architectuurbepalende features van het systeem. Dit om de architectuurkeuzes te valideren. Na elke iteratie
demonstreren we een werkend systeem om feedback van de klant over de geschiktheid van het product te verkrijgen.
De ontwikkeling van een feature vereist aanpassingen in verschillende lagen van de architectuur. Deze wordt daardoor
verder aangescherpt, terwijl automatische tests de kwaliteit van delen van het systeem en het systeem als geheel
bewaken.

De featuregedreven aanpak staat in contrast met een werkwijze die de verschillende modules onafhankelijk van elkaar
ontwikkelt en pas later in het ontwikkelproject met elkaar integreert. De tweede aanpak betekend dat pas laat in het
project, tijdens systeemintegratie, de verkeerde ontwerpkeuzes naar voren komen. Onze aanpak biedt de mogelijkheid
om al in een vroeg stadium werkende software aan belanghebbenden te laten zien. Dit levert waardevolle feedback om
het product aan hun verwachtingen te laten voldoen, waardoor de kwaliteit die ervaren wordt enorm toeneemt.

De architectuur is hierbij niet statisch, maar juist flexibel. Het Agile-ontwikkelproces maakt architectuurwijzigingen
eenvoudiger en minder risicovol. Verkeerd gemaakte keuzes vanwege voortschrijdend inzicht zijn hierdoor veel
eenvoudiger te herstellen. De verschillende feedbacklussen en vangnetten van Agile zorgen ervoor dat de kwaliteit van
het product hierbij niet afneemt.

Architectuur
Ontwikkeling van een softwareproduct is in essentie het nemen van beslissingen, variërend van naamgeving van een
lokale variabele tot de opdeling in modules. Sommige beslissingen zijn lokaal van aard en hebben weinig gevolgen,
andere hebben veel meer impact. De architectuur is die set van ontwerpbeslissingen die de belangrijkste eigenschappen
van het product bepaalt, en daarmee het succes voor de business. Vooral de niet-functionele eigenschappen zoals
performance, uitbreidbaarheid en betrouwbaarheid zijn hierbij belangrijk.
Agile
Agile volgt een iteratieve aanpak. Stap voor stap bouwen we, bijna evolutionair, een product. De gedachte is om risico’s
naar voren te halen en snel te leren van gemaakte fouten. We minimaliseren overhead om zo efficiënt mogelijk tot een
werkend product te komen. We werken met zelfsturende teams, die dagelijks afstemmen in een korte stand-up meeting.
Kennisdeling, mentoring en feedback op werkende software zorgen ervoor dat we fouten in een vroeg stadium
elimineren. Door regelmatig te evalueren, kunnen we snel reageren op geconstateerde problemen. Continu integreren
en geautomatiseerde tests garanderen de blijvende werking van de al gerealiseerde features.

De valkuil van de ene aanpak is te ondervangen met een maatregel van de andere.
 Juiste mix
Een goed praktijkvoorbeeld vinden we bij Neopost. Dit bedrijf uit Drachten ontwikkelt al tientallen jaren
couverteermachines, die documenten verzamelen, vouwen en in een envelop plaatsen. De software ontwikkelen de
Friezen volgens de Scrum-aanpak, een Agile-methode. Voor een nieuw productplatform hebben ze een tijdje terug een
minimalistische architectuur opgezet met als belangrijkste systeemeigenschappen doorvoersnelheid, uitbreidbaarheid en
betrouwbaarheid.

De minimalistische architectuur was snel gedefinieerd waardoor het ontwikkelteam al vrij vlot met de realisatie kon
beginnen. De doelen van de eerste sprints (iteraties) werden gehaald. Hierdoor konden de mechanische prototypes veel
sneller dan vroeger functioneel worden gebruikt. De vroegtijdige feedback van gebruikers en andere belanghebbenden
zorgde voor belangrijke input voor wijzigingen aan de architectuur.

Er gingen ook zaken minder goed. Tijdens de eerste sprints stonden niet alle belangrijke systeemeigenschappen centraal
waardoor de ontwikkelaars afweken van de minimalistische architectuur. Hierdoor introduceerden ze lokale optimalisaties
en ongewenste afhankelijkheden. Dit kwam aan het licht toen de hoge doorvoersnelheid moest worden gerealiseerd. Er
was een ingrijpende refactoring nodig om de ontstane situatie in lijn te brengen met de architectuur. Dankzij de korte
feedbacklussen kwam het team hier vroegtijdig achter en had de refactoring slechts een beperkte impact op het gehele
project.

Een aantal belangrijke lessen zijn hier geleerd:

Een minimalistische architectuur zorgt ervoor dat de realisatie snel en doelgericht kan starten.

De architect moet onderdeel zijn van het ontwikkelteam en nauw betrokken blijven bij de realisatie.

Verder moet hij actief de systeemdoelen blijven uitdragen om kwaliteit op systeemniveau te borgen.

Agile en architectuur vullen elkaar goed aan: architectuur geeft richting en overzicht, Agile geeft vroegtijdige feedback.
Kern van onze aanpak is beginnen met een minimalistische architectuur en deze vervolgens laten evolueren. De juiste
mix van Agile en architectuur hangt altijd af van de omstandigheden in een project. Een absolute regel is er niet.
Experimenteer, leer en verbeter, en betrek hierbij het hele team.

Dit artikel is eerder gepubliceerd in Bits & Chips