Architectuur in een Agile omgeving
4

“Als mijn team elke sprint software moeten leveren, hoe borg ik dan architectuur en welke documentatie heeft wel meerwaarde.”

Dit is een terechte vraag die een IT manager of bezorgd teamlid zou kunnen stellen. En het is een probleem waar menig agile team tegen aanloopt. Ofschoon er geen eenduidige definitie is van de term “software architectuur” is het een van de belangrijkste disciplines om tot succesvolle software te komen. Als je de volgende vijf tips volgt, ben je volgens mij een heel stuk op weg:

architectuur

1. Zorg dat je architectuur net zo “agile” is als je functionaliteit
De kunst is om slechts te maken wat nodig is, maar het zodanig op te zetten dat het eenvoudig te wijzigen is. Wanneer software test driven wordt opgezet met de SOLID principes in het achterhoofd, is het mogelijk om de architectuur mee te laten groeien met de functionele eisen.

2. Borg je ontwikkelwerk (logical view)
Je zou dit kunnen doen door een feature tree van de software op te zetten. De feature tree bevat alle features waaruit de software is opgebouwd, zodat je de userstories onder kunt brengen bij de functionaliteit waar ze bij horen. De userstories vormen dan in feite de implementatiegeschiedenis van een feature waardoor je iedere story kunt herleiden tot een feature en bovenliggende doelstellingen.

3. Borg je processen (process view)
Code moet zichzelf beschrijven. Documentatie door middel van class-en sequence diagrammen zijn arbeidsintensief om actueel te houden. Een workflow daarentegen heeft meerwaarde omdat deze de samenhang van processen in de software laat zien. Wanneer je een feature tree gemaakt hebt, is het ook eenvoudig om workflows bij de gerelateerde feature te borgen.

4. Borg je structuur (development view)
Het is aan te raden om je domein model en componenten model te borgen. Het domein model laat zien wat de relaties tussen entiteiten in je applicatie zijn. Neem in je domeinmodel alleen de namen van de entiteiten op en niet de eigenschappen, die kun je in de code wel terugvinden. Het componenten model laat zien uit welke onderdelen de software is opgebouwd. Ik vind het zelf belangrijk om vooral de focus te leggen op de verantwoordelijkheid van componenten. Ik zou bijvoorbeeld beschrijven dat mijn software gebruikt maakt van Views, TransferModels en Controllers, maar zeker niet iedere view, model en controller beschrijven.

5. Borg je infrastructuur (physical view)
Beschrijf hoe de software in de infrastructuur draait. Bijvoorbeeld een webserver farm met load balancer, een database etc.

Tot slot
Zorg dat documentatie compact en vooral in schema’s en beelden is opgeslagen. Dikke documenten met tekst worden in de praktijk niet gelezen.

Auteur: Menno Jongerius / Bergler Competence Center © 2015