Architectuur in SAFe verbeteren met behulp van RCDA

Het is meer dan een decennium geleden sinds we onze ervaringen met agile architectuur hebben gebundeld in onze Risk and Cost Driven Architecture*-aanpak. Sindsdien hebben we gezien dat agile practices mainstream zijn geworden. Frameworks om agile op grote schaal toe te passen, zoals SAFe, hebben steeds grotere organisaties geholpen om de voordelen van agile werken te benutten. Veel organisaties die RCDA-practices toepassen, hebben ook agile-op-schaalpractices geïmplementeerd, vaak gebaseerd op SAFe. In deze blog deel ik enkele van hun ervaringen. Ze tonen aan hoe de combinatie van RCDA en SAFe helpt om architectuur beter te doen.

Schaalvergroting van architectuur

Agile teams hebben een maximale omvang, vaak aangeduid als de two-pizza-regel. Als een systeem, oplossing of organisatie meer werk heeft dan door één team kan worden voltooid, moet het werk tussen die teams op de een of andere manier worden gecoördineerd. Agile-op-schaalframeworks omvatten best practices om die coördinatie te begeleiden. Architectuur speelt hierbij een grote rol. Architectuurstijlen zoals microservices zijn ontworpen om de behoefte aan inter-teamcoördinatie tot op zekere hoogte te minimaliseren, maar er zullen altijd afhankelijkheden tussen teams zijn, bovenop architectuurprincipes, beslissingen en afwegingen tussen teams.

Afhankelijk van de omvang en structuur van een organisatie kunnen er meerdere niveaus van architectuurcoördinatie zijn: coördinatie tussen teams die aan hetzelfde systeem werken (systeemarchitectuur), coördinatie tussen meerdere systemen die samen een bedrijfsprobleem oplossen (solution-architectuur) en coördinatie over een heel bedrijfsdomein of onderneming (enterprise-architectuur). SAFe schrijft architectuurrollen voor elk van deze niveaus voor, genaamd System Architect, Solution Architect en Enterprise Architect. Op teamniveau is er geen voorgeschreven architectuurrol, maar dat betekent niet dat er geen architectuurwerk op dat niveau is: de zelforganiserende teams zijn verantwoordelijk voor hun eigen ontwerpbeslissingen.

Elk van deze niveaus heeft dezelfde architectuurverantwoordelijkheden zoals beschreven in RCDA: ze moeten allemaal de zakelijke en technologische context binnen hun toegewezen scope begrijpen, beslissingen nemen, modellen maken, de architectuur valideren en de realisatie ervan ondersteunen. Het belangrijkste verschil tussen de niveaus zit hem niet in de taken en verantwoordelijkheden, maar in de reikwijdte van de modellen en beslissingen, zoals geïllustreerd in het paraplu-diagram hierboven (credits aan Dana Bredemeyer). Omdat het architectuurwerk op de verschillende niveaus zoveel op elkaar lijkt, wordt het ook op elk niveau effectief ondersteund door RCDA-practices.

Businesswaarde van architectuur

"Een economisch perspectief" is het eerste lean-agile-principe van SAFe. Bij het bouwen van systemen moeten beslissingen over architectuur en prioritering worden genomen in een juiste economische context. Die economische kijk op architectuur is ook altijd het belangrijkste uitgangspunt geweest van RCDA. RCDA-practices hebben zich sterk bewezen in het ondersteunen van dit principe, bijvoorbeeld in het duidelijk articuleren van de business-waarde van architectuur. RCDA helpt niet alleen bij het begrijpen van de businesswaarde van architectuur-epics, -features en -stories, maar ook de waarde van architectuurdocumentatie, -modellen en -beslissingen – vanuit een business-perspectief. Hieronder staan drie verhalen die dit punt illustreren.

Documentatie van solution intent

In een grote publieke-infrastructuurorganisatie werd ons gevraagd te helpen bij de transformatie van de architectuurwerkwijze. De focus van de architecten lag voorheen op hun opleverbare producten, voornamelijk ontwerpdocumenten in het voortraject, die een belangrijke rol speelden bij projectbeheer. SAFe gebruikt een 'solution intent' die ruimte laat voor een architectuur om te ontstaan, maar schrijft geen formaat of granulariteitsniveau voor om die intentie te documenteren. In dit geval was de focus van RCDA op risico en kosten zeer nuttig bij het creëren van nieuwe manieren om zeker te zijn dat investeringen voldoende onder controle waren. De focus verschoof van uitgebreide ontwerpdocumenten naar architectuurbeslissingen met hoge risico- en kostenimplicaties. Minder risicovolle beslissingen werden uitgesteld en het management klaagde niet langer over 'onvolledige ontwerpen'. De waardegedreven architectuurdocumentatie benadering van RCDA was hierbij bijzonder nuttig. We herhaalden deze aanpak later in veel andere organisaties.

Eigenaarschap van enablers en technische schuld

Het implementeren van architectuurbeslissingen vereist werk, en dat werk wordt in agile teams meestal gemanaged als stories op een backlog. Denk aan de bouw of integratie van technische of infrastructuurcomponenten, of werk om technische schuld te verminderen. Dergelijke stories worden 'enablers' genoemd in SAFe, omdat andere features of stories vaak van hen afhankelijk zijn. Door enablers te implementeren wordt de 'architectural runway’ aangelegd. Enablers creëren typisch alleen indirect businesswaarde; de enabler op zichzelf heeft geen directe waarde. Daarom leidt de prioritering van enablers vaak tot discussie, vooral wanneer organisaties SAFe's WSJF (Weighted Shortest Job First) gebruiken voor prioritering van hun backlogs.**
 

Een veel voorkomende valkuil is dat business stakeholders enablers vaak zien als technische nice-to-haves, waarvoor zij geen eigenaarschap voelen - hoewel de integriteit van hun producten er vaak van afhangt ("Waarom betaal je dit niet vanuit je onderhoudsbudget?"). In een grote vervoersorganisatie hebben we dit probleem aangepakt door het waardemodel van Philippe Kruchten voor backlog items te introduceren. Dit model speelt een belangrijke rol in de delivery-practices van RCDA en helpt bij het creëren van transparantie in de waardeontwikkeling van een portfolio of product. Het model positioneert architectuurstories in business-termen, en helpt bij het toewijzen van capaciteit aan enablers.

Veranderende rol van architecten

Het implementeren van een opgeschaalde agile manier van werken heeft veel impact op architecten. Ook al klinken de rolbenamingen van SAFe (enterprise-/solution-/systeemarchitect) bekend, architect zijn in een werkelijk agile organisatie vereist een andere mindset en gedrag. Vooral traditionele architecten die gewend zijn om vooraf gevalideerde ontwerpddocumenten te schrijven, moeten uit hun comfortzone stappen. Ze schrikken soms van het idee van ‘autonome teams’ die zelf architectuur bedrijven. We hebben dit aspect veel aandacht gegeven toen ons gevraagd werd om architecten in de publieke sector en financiële domeinen te coachen. Vooral het leren over de modelleer- en delivery-practices van RCDA hielp hen om vol vertrouwen samen te werken met agile teams bij het nemen van architectuurbeslissingen. De focus op risico en kosten heeft ook geholpen om richtlijnen te creëren voor het bepalen(welke architectuurbeslissingen op welk niveau moeten worden genomen (centrale versus decentrale beslissingsbevoegdheid).

Agile architectuur vereist meer dan een framework

Agile-op-schaalbenaderingen zoals SAFe zijn omvangrijk, en organisaties die ze implementeren hebben vaak moeite om zich naast alle training, nieuwe rollen, cadansen en rituelen ook nog te richten op businesswaarde. Het worden van een werkelijk agile architect vereist veel meer verandering dan de vertrouwd klinkende architectuurrollen van SAFe lijken te impliceren - en niet alleen voor de architecten! SAFe biedt rolbeschrijvingen, verantwoordelijkheden en een raamwerk voor samenwerking, maar is wat dun als het gaat om hoe architectuur te doen. We zien dat de practices van RCDA veel praktische ondersteuning bieden aan architecten en teamleden die meer willen doen dan hun rituelen veranderen. Ze zijn bijzonder nuttig gebleken bij het focussen op businesswaarde en het betrekken van business stakeholders bij architectuur.

* RCDA betekent ook ‘Responsive, Collaborative Digital Architecture’; beide betekenissen dekken de lading van de aanpak.

** WSJF mag nooit gebruikt worden om enablers te prioriteren ten opzichte van niet-enablers: gebruik hiervoor capacity allocation, één van SAFe’s lean budget guardrails