Artikel

Agile en Architectuur: niet tegenstrijdig, maar complementair

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

Categorie:   
Auteur(s)
afbeelding van edzerlawerman
Edzer Lawerman
TASK24

Edzer is lid van de Technology Group Agile en Architectuur binnen TASK24. Hij is software architect en heeft ruime ervaring in het gebruiken van agile technieken. Hij verzorgt workshops over het invoeren en verbeteren van Agile bij bedrijven.

afbeelding van bartbouwman
Bart Bouwman
TASK24

Bart is lid van de Technology Group Agile binnen TASK24. Vanuit verschillende functies heeft hij een ruime ervaring met Agile en architectuur op kunnen bouwen. Tevens geeft hij Agile coaching en verzorgt hij trainingen en workshops over het invoeren en verbeteren van Agile-proccessen bij bedrijven.

afbeelding van fedorrutgers
Fedor Rutgers
TASK24

Fedor Rutgers is leider van de Technology Group Agile binnen TASK24. Hij is een ervaren, pragmatische, resultaatgerichte project manager. Zijn coachende manier van leiding geven zorgt voor een effectiever team die zijn verantwoordelijk neemt. De projectfocus wordt gericht op het te maken eindproduct: ‘Doe alleen dat wat waarde toevoegt aan het eindproduct'.

afbeelding van petertjeerdsma
Peter Tjeerdsma
TASK24

Peter is lid van de Technology Group Architectuur binnen TASK24. Hij is software architect in een multidiciplinaire omgeving waar hij agile technieken gebruikt om focus, feedback en snelheid in het projectteam te krijgen.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.