Architectuur kan ook agile zijn

Sinds de introductie van het begrip agile rond de eeuwwisseling wordt er gepuzzeld hoe het te verenigen is met architectuur. Er lijkt een fundamenteel verschil in doelstellingen te bestaan: architecten zoeken stabiliteit en toekomstvastheid, agilisten zoeken wendbaarheid, een soort toekomst 'los'heid. Om de juiste balans te kunnen vinden moeten zowel agile-aanhangers als architecten hun eigen discipline op een iets andere manier bekijken.

Sommigen vinden onder architectuur en agile werken tegenstrijdig. Het lijdt geen twijfel dat de manier waarop de agile-beweging aankijkt tegen Big Up-Front Design (BUFD) op het eerste gezicht lijnrecht tegenover het werken onder architectuur staat. Deze perceptie van onverenigbaarheid wordt versterkt door het door Philippe Kruchten amusant beschreven verschijnsel dat de agile-beweging zich soms als een religie gedraagt, compleet met dogma’s en verkettering van andersdenkenden (KRUCHTEN2007). Op blogs gaan agile-aanhangers wild tekeer tegen iedere suggestie dat van tevoren nadenken over architectuur soms nuttig kan zijn, of dat niet alle belangrijke (kwaliteits-)eisen achteraf nog kunnen worden ingevuld via het magische ‘refactoren’ van een it-oplossing.

Wie goed kijkt, ziet dat architectuur en agile twee kanten van een spectrum vertegenwoordigen. Waar op het spectrum je project het beste kan verblijven hangt af van de context. Barry Boehm suggereert dat de ideale plaats op dit spectrum afhankelijk is van drie factoren die bepalen hoeveel architectuur vooraf nodig is: de grootte van het project, de veranderlijkheid van de omgeving en de mate waarin de it-oplossing kritiek is voor de bedrijfsvoering (BOEHM2010).

Agilisten kunnen succesvoller worden als ze de projectcontext meenemen in hun oordeel over het nut van architectuur, maar wat kunnen architecten doen om de kloof tussen agile en architectuur van hun kant te dichten? De principes uit het Agile Manifesto zijn lang genegeerd door de architectuur-beweging, althans zo lijkt het als je bijvoorbeeld naar Togaf kijkt, het populaire architectuur-framework van de Open Group.  De Togaf Architectuurmethode ADM vereist nog steeds behoorlijk zware documentatie, geproduceerd door vaak logge processen als Business Architecture, Information Systems Architecture en Technology Architecture. Voor een wendbare architectuur-omgeving zijn dit soort EA-aanpakken niet geschikt. In de wereld van de software-architectuur zie je wel langzaam lichtere architectuur-aanpakken opkomen, zoals de ‘Just Enough Software Architecture’-aanpak van George Fairbanks (FAIRBANKS2010). Deze meer wendbare aanpakken zien architectuur niet meer hoofdzakelijk als een ontwerpdiscipline, maar meer als een manier om risico’s te beheersen en met onzekerheden om te gaan.

Een recent beschikbaar gekomen agile architectuur-aanpak is Risk- and Cost Driven Architecture (RCDA) voor solution-architectuur. Deze aanpak is ontwikkeld om het gat tussen enterprise-architectuur en software-architectuur te dichten. Bestaande software-architectuur praktijken zijn namelijk vaak te beperkt voor de complexiteit en scope van de oplossingen die ontworpen moeten worden, maar de enterprise-architectuur praktijken zijn vaak  te log voor de wendbaarheid die wordt vereist door tijdsdruk en frequent optredende onzekerheden en veranderingen. De RCDA-aanpak neemt een aantal aspecten uit agile software-ontwikkelmethodes over. Zo werkt de aanpak met een backlog van architectuurvraagstukken die soms dagelijks geherprioriteerd worden op economische gronden.

Het geheim van het agile maken van architectuurwerk zit hem, net als bij agile software-methodes, in het op een andere manier kijken naar wat het werk oplevert. Zo levert een agile software-ontwikkelteam niet een ‘big-bang  systeem’, maar een continue stroom van verbeteringen aan een systeem. Op dezelfde manier levert een agile architect niet een ‘big up-front design’, maar een continue stroom van architectuurbeslissingen die stap voor stap de onzekerheden en risico’s rond complexe it-oplossingen onder controle brengen. Hoeveel architectuur er moet worden ingebouwd wordt dan niet bepaald door agile dogma’s als ‘You Ain’t Gonna Need It’ (YAGNI), maar door economische afwegingen die de werkelijke waarde van architectuur bepalen.

Samenvattend, architecten kunnen veel doen om de kloof met agile te dichten. Dat is ook dringend nodig, want anders verliezen architectuurafdelingen alle voeling met it-ontwikkelafdelingen, waar agile werken de norm aan het worden is, en met de business, waar de vraag vandaan komt sneller en beter in te spelen op veranderende (markt)omstandigheden. De belangrijkste verandering die architecten moeten maken is dat ze architectuur niet meer zien als een vooraf aan projecten op te leveren ontwerpdocument, maar als een continu proces van besluitvorming met als doel om risico’s, kosten en onzekerheden onder controle te brengen. Zo kunnen architecten de toegevoegde waarde en flexibiliteit leveren die de business van ze verwacht.