Het Waterfall Wasteland en de Agile Outback

De afgelopen periode heeft CGI’s architectuur-practice samen met een aantal klanten gewerkt aan een manier om de maturiteit van de architectuurfunctie in agile organisaties te meten, op basis van onze Risk and Cost Driven Architecture (RCDA) aanpak. Dit werk heeft tot een opvallende inzichten geleid die we graag in een aantal blogs delen. Dit eerste blog gaat over het balanceren van de verantwoordelijkheden die met architectuur samenhangen, en het vinden van het pad tussen het Waterfall Wasteland en de Agile Outback.

De aard van architectuur

De betekenis van het begrip ‘architectuur’ in de digitale wereld heeft sinds het eerste gebruik ervan een aantal veranderingen ondergaan.

In de originele perceptie in de jaren ’90 ging architectuur over structuren die een abstractie van het te realiseren systeem representeerden. Die abstractie was nodig om om te kunnen gaan met de groeiende complexiteit van typische software-systemen. Vanuit die visie is de belangrijkste verantwoordelijkheid van de architect om (visuele) modellen van het systeem te creëren, en deze modellen te gebruiken voor het valideren van de architectuur.

Rond de eeuwwisseling ontstond er een tweede perceptie, gericht op een nieuwe verantwoordelijkheid: architecten moesten belangrijke beslissingen nemen om de juiste modellen te maken (met ‘juist’ bedoelen we dat de gemodelleerde oplossingen de behoeften van belanghebbenden vervullen). Als ‘abstractie’ en ‘structuren’ beschrijven wat een architect creëert, gaat het beslissen over hoe ze dat creëren.

Rond 2010 kwam daar een derde perceptie bij, deels gedreven door de focus op business-waarde van de agile beweging: het waarom werd toegevoegd aan het wat en hoe van architectuur. Het doel van architectuur werd duidelijk: het beter beheersen van de risico’s en kosten van IT, niet alleen tijdens het ontwerpen. Hiermee werd de verantwoordelijkheid van de architect uitgebreid naar de realisatie van de oplossing.

Het lijstje van architectuurverantwoordelijkheden zou incompleet zijn zonder de voorwaarde zonder welke een architect geen enkele verantwoordelijkheid zou kunnen vervullen: het begrijpen van de context van de oplossing: de belanghebbenden, hun behoeften, en de omgeving waarin de oplossing moet gaan werken.

Daarmee hebben we vijf verantwoordelijkheden van architecten – of beter, van de architectuurfunctie binnen een organisatie: het begrijpen van de context, beslissingen nemen, modelleren, valideren en realisatie van de oplossing. Deze vijf verantwoordelijkheden zijn ook terug te vinden in Philippe Kruchten’s “Things architects really do”, in Eoin Woods’ “Architectural focus areas” en in de RCDA practices die CGI al tien jaar toepast.

Afhankelijkheden

Het is belangrijk te beseffen dat er veel afhankelijkheden bestaan tussen deze vijf verantwoordelijkheden. Om er een paar te noemen:

• Modelleren en beslissen zonder begrip van de context leidt tot verkeerde modellen en beslissingen
• Modelleren impliceert beslissingen nemen (over decompositie, relaties, etc.)
• Zonder modellen en besluiten valt er niets te valideren
• Het realiseren van ongevalideerde beslissingen leidt tot problemen

Dus het vervullen van de vijf verantwoordelijkheden is niet genoeg: er moet ook een goede samenhang zijn.

Goede architectuur

Omdat architectuur over context gaat, bestaat er ook geen ‘goede architectuur’ in absolute zin: het beste wat we kunnen bereiken is een architectuur die goed past bij de behoeften van belanghebbenden in de context. In onze ervaring komen de beste architecturen voort uit een goede balans tussen alle vijf bovengenoemde verantwoordelijkheden. Dit is niet makkelijk: vanwege culturele druk, dogma’s en vooroordelen zijn er veel organisaties die sommige verantwoordelijkheden negeren, met een slechte architectuurfunctie als resultaat. Hieronder geven we twee voorbeelden van waar dit toe kan leiden: het Waterfall Wasteland en de Agile Outback.

De juiste aandacht voor alle vijf de verantwoordelijkheden betekent overigens niet noodzakelijkerwijs evenveel aandacht: afhankelijk van de context kan het zijn dat er meer aandacht nodig is voor modelleren dan voor besluitvorming, en validatie kan in sommige (business-critical) situaties belangrijker zijn dan in andere.

Bij het werken met teams, architecten en belanghebbenden in verschillende organisaties vielen ons een aantal opvallende patronen op in de manier waarop die verantwoordelijkheden werden opgepakt. Om deze patronen te duiden hebben we hieronder twee karikaturen geschetst: het Waterfall Wasteland en de Agile Outback. Let wel, dit zijn slechts karikaturen: de kenmerken zijn overdreven, wat voor sommigen amusant is, en anderen misschien tegen de borst stuit – maar je kunt ze gebruiken om een punt te maken.

Het Waterfall Wasteland

In het Waterfall Wasteland leven de architecten in een ivoren toren. Zij negeren de verantwoordelijkheid voor beslissingen en realisatie, want die zijn elders belegd. Ze hebben een heel duidelijke taakomschrijving: het creëren van perfecte modellen, en het valideren van deze modellen tegen de behoeften van belanghebbenden. Als de resulteren oplossing niet goed werkt is dat duidelijk niet hun probleem. Het idee dat architecten beslissingen moeten nemen, of medeverantwoordelijk zijn voor succesvolle realisatie staat hen tegen: het zou betekenen dat hun succes zou afhangen van de capaciteiten van anderen, en van hun vermogen om samen te werken…

De Agile Outback

In de Agile Outback hebben teams meestal geen architecten (hoewel je er soms eufemismen als ‘pathfinder’ of ‘master builder’ tegenkomt). Modelleren wordt zorgvuldig vermeden, aangezien “de beste architecturen… komen bovendrijven uit zichzelf organiserende teams” volgens het Agile Manifesto. Actief van tevoren modelleren zou de agile goden wel eens kunnen mishagen en het ‘magische’ proces van bovendrijven (emerging architecture) kunnen verstoren. Het valideren van ontwerpen is verloren tijd: failing early and often is een veel snellere manier om te leren en de oplossing te verbeteren.

Essentiële architectuur-vaardigheden

De vijf architectuur-verantwoordelijkheden vormen een goede basis om de essentiële kennis en vaardigheden voor een goede architectuurfunctie te identificeren:

• Om de context te kunnen begrijpen hebben we analytisch vermogen nodig waarmee we de omgeving en belanghebbenden van onze oplossing kunnen duiden, communicatieve en sociale vaardigheden om de behoeftes van belanghebbenden te begrijpen en kennismanagement-vaardigheden om dat begrip te cultiveren en delen.
• Om de juiste beslissingen te nemen hebben we besluitvaardigheid nodig en moeten we zaken goed kunnen afwegen en prioriteren. We hebben ook uitgebreide kennis van de relevante architectuurtactieken en –strategieën nodig binnen onze (business- en technologie-) domeinen.
• Voor het modelleren hebben we creatieve vaardigheden nodig om ons ontwerp te visualiseren, en kennis van de relevante modelleertalen en technieken als decompositie en compositie.
• Voor het valideren hebben we opnieuw analytische en afwegingsvaardigheden nodig, en kennis over technieken voor risicobeheersing, kostenschatting en business cases.
• Om onze realisatieverantwoordelijkheden te kunnen vervullen hebben we leiderschapsvaardigheden nodig als communicatie, overtuigingskracht, luisteren en anticiperen. Maar we moeten ook het een en ander weten over de economische aspecten van het leveren van software-intensieve systemen en de relevante software-lifecycles.

Wie deze lijst bekijkt zal niet verbaasd zijn dat goede overall architecten bijzonder zeldzaam zijn. We zien dan ook dat steeds meer organisaties deze verantwoordelijkheden niet aan één rol toekennen, maar hun architectuurfunctie anders inrichten. Ze creëren een architectuurfunctie: een (mogelijk virtueel) team dat bestaat uit leden die elkaars kennis en vaardigheden complementeren, maar die wel intensief samenwerken om de samenhang en kwaliteit hoog te houden.

Het RCDA Maturity Model is het gereedschap dat CGI architecten en consultants gebruiken om te meten hoe goed teams en organisaties omgaan met deze vijf verantwoordelijkheden. De resultaten van die meting gebruiken we dan om verbeterplannen te maken, en later om de geboekte voortgang in kaart te brengen.

Conclusie

Architectuur kent vijf verantwoordelijkheden: begrijp de context, besluitvorming, modelleren, validatie en realisatie. Organisaties dienen voldoende aandacht te hebben voor ieder van deze verantwoordelijkheden; wat ‘voldoende’ precies inhoudt hangt af van de context. Door dogmatisch bepaalde verantwoordelijkheden te negeren zullen teams verdwalen in het waterfall wasteland of in de agile outback. Om deze verantwoordelijkheden te kunnen realiseren is een breed scala aan kennis en vaardigheden nodig dat lastig in één individu te vinden is; er is vrijwel altijd een team nodig om goede architectuur te realiseren.

CGI’s Eltjo Poort geeft op 6 november 2019 op de O'Reilly Software Architecture Conference in Berlijn een lezing over het Waterfall Wasteland en de Agile Outback getiteld “Measure your agile architecture maturity”.