Met de adoptie van agile werkvormen voor software ontwikkeling is volgens velen de rol van architectuur uitgespeeld. De stelling is dat de scrum teams inherente ontwerpcapaciteit hebben, dus is een aparte architectuur of een ontwerp van te voren overbodig geworden.
Echter in de praktijk loopt dit spaak. Je kunt niet alles “al bouwend” ontwerpen. Zelfs als sprake is van een “platform” met basisfunctionaliteit uit de doos is een architectuur nodig van de gewenste basiscomponenten en hoe die moeten samenwerken. En vaak is een oplossing verbonden met de rest van het IT landschap en dus moet de omgeving in kaart worden gebracht.
Mijn stelling is daarom dat je ook bij agile moet ontwerpen voordat je gaat bouwen als het om complexe oplossingen gaat. Architectuur is een must! Maar op een andere wijze dan bij traditioneel bouwen van software. Namelijk in kleine watervalletjes in plaats van één hele grote.
Hoe dit er in de praktijk uit ziet? Stel je twee teams voor. Het eerste is een ontwerpteam dat op basis van “user stories” de eerste benodigde componenten van het systeem ontwerpt. In samenhang en met het oog op de totaal gewenste functionaliteit. Ze maken dus eigenlijk functionele ontwerpjes maar niet meer dan strikt noodzakelijk voor de eerstvolgende paar sprints. Bij deze agile werkwijze accepteer je ook dat je mogelijk na enige tijd je ontwerpkeuzes moeten herzien en een “redesign” nodig is van je basis. Het tweede team bouwt in een daarop volgende sprint die ontwerpen, test ze en levert ze op. Een klein watervalletje dus!
Ondertussen ontwerpt het ontwerpteam dan weer volgende te bouwen “user stories”. Zo ontstaat een soort haasje over ontwerp/bouw cadans van mini-watervallen in plaats van een paar hele grote. Dat geeft de gewenste mogelijkheid om snel bij te sturen en snel het resultaat te toetsen bij de eindgebruiker. En als het bouwteam tegen ontwerpvraagstukken aan loopt bij de realisatie leggen ze die direct terug bij het ontwerpteam en ze pakken een item op wat wel gebouwd kan worden.
De product owner stuurt voornamelijk op wat het tweede team oplevert. Dat kan hij toetsen aan wat er is gevraagd in de definition of done. Maar het eerste team heeft ook een klankbord nodig. Dat is de lead architect van het systeem. Hij bewaakt vooral de samenhang en consistentie, hergebruik van componenten, oplopende technical debt en de benodigde “architectural features” om een blijvend flexibele oplossing te realiseren. Samen zorgen ze voor een bruikbare én duurzame oplossing. Het ontwerpteam is dus veel dichter betrokken bij het resultaat dan in een traditionele waterval ontwikkeling waarbij de feedback over de bruikbaarheid van de architectuur veel langer op zich laat wachten. Ook moet de lead architect veel sneller besluiten nemen en ontwerpen opleveren. Maar net als bij traditionele software ontwikkeling is er eerst een ontwerp en daarna de bouw. Maar kort cyclisch en iteratief in plaats van sequentieel.
Architectuur staat als discipline dus niet buiten spel bij agile ontwikkelen van software. Maar er moet wel direct toegevoegde waarde worden geleverd! Net zoals direct bruikbare functionaliteit voor de product owner. Dat is de uitdaging voor de architect van de toekomst.