Agile architectuur toegepast – Wat is het en hoe kun je invulling aan Agile architectuur geven

Agile is adaptief. Wat, wanneer aan architectuur te doen ligt aan de context: it depends. Dit artikel legt uit waarom dat zo is en hoe je dan toch invulling aan die architectuur geeft.

Het Agile Manifesto werd ruim 10 jaar geleden geschreven in reactie op de plangedreven standaard aanpak destijds. In de plangedreven aanpak zijn er losse stappen voor het plannen van het werk en het uitvoeren van het werk. Voor het opstellen van een goed plan is een stabiele basis nodig: goed gespecificeerde wensen. Vandaar de uitdrukkelijke behoefte deze specificaties te stabiliseren. Met die wensen in de hand kan een even zo stabiele architectuur worden opgesteld en vervolgens uitgevoerd worden.

Dat blijkt in de praktijk erg lastig; zo zitten we als mensen simpelweg niet in elkaar. De klant ontdekt gaandeweg wat hij wil, het ontwikkelteam ontdekt hoe het te realiseren en de omgeving verandert onderwijl ook nog. Agile pakt planning dan ook anders aan en omarmt al deze verandering, zolang zij de waarde van het eindproduct maar ten goede komt. Daarmee is er geen ondergrond waarop een groots design neergezet kan worden, maar ook geen wens zo’n design neer te zetten: dat zou te fragiel zijn. Dat wil niet zeggen dat architectuur niet langer belangrijk is, maar dat ze robuust moet zijn ten opzichte van veranderingen. Wat dat dan inhoudt? Dat ligt eraan. Hoeveel werk moet je tevoren nog wel doen? Net genoeg.

Kende je deze antwoorden al? Verwacht je 10 jaar na het manifesto dat we iets concreter kunnen worden? Ja, wij ook! En wel nu graag, want vanaf de business zijde voert men de druk op. Succes is niet langer leveren volgens plan, maar business impact maken. Technieken als Impact Mapping, Feature Injection en User Story Mapping winnen snel aan populariteit; allen technieken die ons helpen het juiste product te bouwen. Hoe dat op de juiste manier te doen, met een effectieve architectuur, kan dan ook niet achter blijven. Voor alle duidelijkheid, architectuur is immers een brede noemer, we hebben het binnen dit artikel over software-architectuur, de architectuur van één applicatie.

Architectuur? Wij doen TDD en we schrijven clean code.
Werken met Test Driven Development komt het ontwerp van je code sterk ten goede. Zeker als je van buitenaf, vanaf acceptatietesten, naar binnen werkt, zoals de London School of TDD propageert. Door van buitenaf te werken vermindert de neiging allerlei ‘wat-als’ code toe te voegen. Tevens worden de verbanden tussen classes getest, die bij puur unit testen buiten beschouwing blijven, en bouw je tests die refactoring ondersteunen in plaats van in de weg staan.

Schrijf je dan ook nog nette, cleane code die helder communiceert met de lezer, dan ben je op detailniveau lekker bezig. Maar hoe zit het met het grotere geheel? Hoe documenteer je wat je niet zo 1-2-3 aan de code afleest? Hoe communiceer je daarover en maak je afspraken? Zouden, naast je (test driven opgebouwd) design onder andere een[%1]  aantal overzichtsplaten niet fijn zijn? Het maken en onderhouden daarvan valt volgens ons onder architectuur en is iets wat je bij voorkeur als vakmensen samen doet.

Emergence
Een hardnekkig misverstand is dat agile niet alleen het tevoren uitgewerkte architectuurdocument maar ook de aandacht voor architectuur niet meer nodig zou hebben. De ‘emergence’ genoemd in de principes achter het manifesto wordt dan uitgelegd als ‘komt vanzelf goed’. Een betere interpretatie is: ‘dat doen we gaandeweg met z’n allen’. Architectuur als gezamenlijke activiteit en gezamenlijk gedeeld begrippenkader, ver van een document dat vanuit een ivoren toren als een estafettestokje wordt doorgegeven aan een team.

Kenmerkend voor een emergente eigenschap is namelijk dat hij niet bestaat zonder de onderdelen van het systeem waaruit hij voortkomt, niet terug te leiden valt naar een specifiek onderdeel, maar wel effect heeft op elk onderdeel. Water heeft geen vloeibaarheid als je de moleculen weghaalt, één enkel molecuul is niet vloeibaar, maar vloeit wel in het geheel. Zo bestaat er ook geen (emergente) architectuur zonder applicatie en zonder team, en is geen architectuur terug te voeren op één architect die zich alleen kan terugtrekken, maar is er wel een gedeeld begrippenkader dat invloed heeft op het handelen van de teamleden en op hoe de applicatie eruit komt te zien. In het traditionele op de processen gerichte gedachtegoed valt dit geen plek te geven. Hier zie je dan ook terug dat agile echt een verandering van mindset met zich meebrengt, naar één gericht op mensen en interactie.

Heb je dan nog een losse architect? Misschien niet, zeker niet zoals vanouds. Maar als je met meerdere teams aan een applicatie (of aan zusterapplicaties) werkt, dan helpt het elk team haar eigen focus te behouden wanneer los daarvan iemand de architectuur ondersteunt. Zo’n architect heeft architectuur als primaire focus, maar werkt ten dienste van de teams in plaats van erboven. Hij helpt om de architectuur in de praktijk te bewijzen, probeert zaken uit en schrijft regelmatig met teamleden samen stukken code.

Opties zijn waardevol
Architectuur die open staat voor veranderingen, die ze waar mogelijk makkelijker maakt. Dat is een architectuur die je mogelijkheden niet nodeloos beperkt. Iedere keer dat je een onderdeel invult, beperk je immers je mogelijkheden om met verandering om te gaan. Leg je pas vast wanneer je weet waarom je dat op dat moment doet en zoek actief naar mogelijkheden om beslissingen op een verantwoorde manier uit te stellen. Net zoals je in je privéleven wel gelijk kaartjes koopt voor dat concert waarvan je verwacht dat het snel uitverkocht zal zijn, maar een avond in de kroeg met een paar vrienden pas op het laatste moment afspreekt. Het betekent onder andere: hou het licht. Verzwaar je applicatie niet met zaken die (nog) niet nodig zijn, maar maak het mogelijk deze later toe te voegen. Oftewel, beperk de noodzaak tot aanpassingen in de architectuur door deze uitbreidbaar in te steken, pas het Open-Closed Principle toe op je architectuur.

Simplicity
Licht houden betekent ook eenvoud nastreven: terugbrengen tot het punt waar verder terugbrengen belangrijke waarde zou verwijderen.  Dat gaat over het weglaten van functionaliteit die weinig toegevoegde waarde heeft. Maar het gaat net zo goed over de opbouw van de applicatie zelf. Hoe makkelijker deze op elk niveau begrijpbaar is hoe beter, van een heldere architectuurplaat tot clean code op detailniveau. Besteed ruim aandacht aan de indeling in componenten en vereenvoudig de componenten zelf. Eenvoudige software is aanpasbare software!

Hoe deel je die componenten dan in? Wat schreeuwt de applicatie je tegemoet wanneer je de ontwikkelomgeving opent? Hopelijk welke functionaliteit hij verzorgt, met de gebruikte technieken en frameworks meer naar de randen gedrukt. Alistair Cockburn stelde jaren terug al dat een indeling in schillen natuurlijker is dan één in lagen. Dergelijke indelingen staan recentelijk volop in de belangstelling, zodanig dat ze hopelijk de nieuwe norm worden.

De kern van zo’n indeling begint bij de geboden functionaliteit, de features of, zo je wilt, use cases. Die zijn in veel applicaties helaas maar moeilijk in de code terug te vinden, terwijl juist daar de applicatie én de wensen van de opdrachtgever om draaien. Die taken willen we onderscheiden, los van het business domain waarop ze werken. Je kunt ze dus zien als een schil om het business domain. Om de kern heen vind je de interfaces naar buiten toe. Niet alleen naar de UI, maar ook naar de database en van en naar andere systemen. Je ziet gelijk dat de meest veranderlijke zaken zo makkelijk aan te passen zijn; een andere database, een mobile UI naast de bestaande, ontsluiten van services, etc.

Dependencies wijzen zonder uitzondering naar binnen toe. Elke schil is, dankzij dependency injection, volkomen onafhankelijk van schillen daarbuiten. Maar ook de verschillende interface componenten aan de buitenrand weten niet van elkaars bestaan af. Het model wordt daarom ook wel beschreven als een reddingsboei.

Doen en leren
En in de kern dan, hoe ziet de applicatie er daar uit? Ten opzichte van jouw applicatie zijn wij zo’n architect aan de zijlijn. Dit is dan ook het punt waarop we je zelf op weg sturen. Ga verder vanuit de bekende uitgangspunten: separation of concerns en het streven naar componenten, een beperkt aantal afhankelijkheden en sterke interne samenhang. Voeg daar de door ons beschreven agile principes aan toe: openstaan voor verandering, nauwe samenwerking, emergence, eenvoud, en bovenal: werkende software.

Dat wil zeggen: trek het naar je toe en begin gewoon, niet alleen als aangewezen architect, maar juist ook als ontwikkelaar. Doen en leren is de essentie. Kijk bij net genoeg niet boos naar de architect en zijn werk vooraf, maar vraag je af welke delen daarvan je team al voldoende kan missen en hoe het team kan laten zien dat het een effectievere manier heeft gevonden en in de praktijk brengt. Veel succes!

Verder lezen:

Architectuurmodellen van onder andere Alistair Cockburn (link) en Robert Martin:  
Open-Closed Principle: