IT architectuur: oorzaak van of oplossing voor IT-geschillen?

Ik ben een groot voorstander van Agile werken. Met als belangrijkste redenen dat ik ervan overtuigd ben, dat het niet mogelijk is om vooraf alles te weten. En dat het beter is om tijdens de Agile reis te leren, zeker in een snel veranderende (technologische) wereld. Zodat we uiteindelijk een product opleveren dat echt goed is. Echter biedt agile geen garantie tegen tegenvallers.  

‘Emergent design’ versus ‘Big design up-front’

Voor architectuur en technisch ontwerp geldt iets vergelijkbaars. Architectuur is belangrijk, maar ik geloof niet in een big design up-front (BDUF). Met architecten die in een ivoren toren een mooie enterprise architectuur uitwerken. De beste ontwerpen en architecturen ontstaan vanuit het zelfsturende (volwassen) Agile team. In Agile noemen we dat een emergent design. We werken architectuur slechts uit, voor zover we het voor het huidige increment van het product nodig hebben.

Geen garantie tegen tegenvallers

Vaak gaat het goed. Maar helaas werkt dit niet altijd en kan het soms voor vervelende tegenvallers zorgen. En waar tegenvallers zijn, zijn ook eerder geschillen. Zeker als het om complexe en grote trajecten gaat. Zo waren wij al 3 sprints onderweg met het ontwikkelen van een product waar veel druk op zat. Toezeggingen aan klanten waren gedaan en nu moesten de toezeggingen nog waargemaakt worden. En na 3 sprints gaf het team aan dat ze vast begonnen te lopen. Het leek namelijk verstandig om voort te borduren op een ander product met vergelijkbare functionaliteit. Maar ja, we volgen een Agile proces en in de tijd begon de functionaliteit van het nieuwe product serieus af te wijken van het oude product. En was het nodig om de codebase van het nieuwe product los te trekken van het oude product. En beide producten onafhankelijk van elkaar te ontwikkelen. Veel werk! Dat de datum waarop we live wilden gaan, serieus in gevaar bracht. Dit zette de relatie onder druk. Meestal worden dit soort zaken onderling opgelost, maar soms leidt het tot een procedure, bij arbiters (zoals bij SGOA) of rechtbank.

Werken met architectuurrichtlijnen

Hoe hadden we dit kunnen voorkomen? Bijvoorbeeld, door binnen de organisatie te werken met architectuurrichtlijnen en door architectuur vervolgens als expliciet onderwerp mee te nemen in een sprint. En iedere sprint te starten met een architectuursessie. Of door aan te sluiten bij SAFe en architectuur als backlog items mee te nemen (enablers). Allemaal met als doel om iets verder vooruit te kijken en te bepalen wat er aan architectuurwerk nodig is om in de aankomende sprints te kunnen blijven sprinten.

Ik geloof dus nog steeds niet in BDUF, maar ben er ook van overtuigd dat we meer expliciete aandacht aan architectuur moeten besteden. En waarbij er dus nog voldoende plek is voor (pragmatische) architecten. De kans op een geschil zal daardoor afnemen en dat is in het belang van beide partijen.