Bij de ontwikkeling van een systeem volgens SCRUM door een enkel team is de kwaliteit in handen van het team. ‘Kwaliteit ontstaat vanuit de praktijk’ is de gedachte, want teamleden willen kwalitatief goede software bouwen. De rol van architect, als ontwerper die richting geeft aan de ontwikkeling, is een teamrol die gezamenlijk wordt uitgevoerd door de communicatie en interactie per sprint.
Maar hoe werkt dat bij opschalen van het aantal teams bij het toepassen van het Scaled Agile Framework (SAFe)? In deze blog mijn korte visie op de invulling van de rol van systems architect die wordt geïntroduceerd binnen SAFe, met als voornaamste doel: “to define a shared technical and architectural vision for the System under development. To participate in determining the system, subsystems, and interfaces, validate technology assumptions and evaluate alternatives while working closely with the Agile Release Train”.
Wat betekent dat in de dagelijkse praktijk voor de persoon in kwestie? En voor de betrokkenen in de “programma” laag van het framework? Zoals SAFe stelt is architectuur vooral een samenwerking in de agile context.
Om te beginnen moet veel inspanning zich richten op communicatie en samenwerking. Het principe van decentralized decision-making is immers de voorkeur binnen SAFe, maar bepaalde ontwerpbesluiten kunnen beter centraal worden bestuurd. Denk daarbij aan de definitie van het high level design, het opdelen in subsystemen en componenten en interfaces, het kiezen van bepaalde platformen, het opstellen van de systeem NFR’s en het voorkomen van redundante componenten. Om die keuze goed te kunnen maken moet de architect met veel belanghebbenden afstemmen. Om te beginnen met de teams natuurlijk die hierover ideeën hebben. De teams passen immers elke dag emergent design toe, terwijl de architect de intenties met het systeem als geheel moet bewaken. Maar ook afstemming met de omgeving is noodzakelijk; met klanten, leveranciers, portfolio management en met name product management en de release train engineer om de noodzakelijke enablers te identificeren. Product management moet immers doorlopend balanceren tussen features (value first) en enablers (architecture first). De architect moet zorgen dat er aandacht blijft voor de noodzakelijke fundamenten om de features op te bouwen en zo te werken aan de architectural runway.
Omdat de systems-architect niet op alle plekken tegelijk kan zijn is het noodzakelijk om langs meerdere wegen in SAFe de architectuurrol te borgen. Enerzijds door het bijwonen van de events zoals de PI-planning, product managementoverleg, system demo en inspect & adapt. Maar ook door in de beschrijving van de DoR en DoD van te bouwen user story’s of features de kaders mee te geven aan de teams. Vervolgens dienen die teams zelf te controleren of ze compleet hebben opgeleverd (bijvoorbeeld inclusief noodzakelijke architectuur-documentatie).
Naar mijn ervaring kan het formeren van een architecture community met leden uit de teams zorgen voor draagvlak, haalbaarheid en begrip en de beste garantie dat de bedachte architectuur straks wordt geïmplementeerd zonder dat de system architect continue als bewaker aanwezig moet zijn. Door integratie aan de voorkant, analoog aan wat het systems team doet aan integratie aan de achterkant. Door ervoor te zorgen dat de overkoepelende ontwerpvraagstukken en enablers multidisciplinair worden uitgewerkt voordat ze op de backlog komen als enabler. Niet als “Big Design Up Front” maar als steeds groeiende “intentional architecture”.
De architect werkt dus binnen SAFe minder in een voorschrijvende en controlerende rol aan de oplossing maar meer in een coachende en verbindende rol, werkend vanuit het overzicht dat hij kan geven. Dat overzicht wat we eerder “de architectuur” noemden heeft SAFe omgedoopt in “Solution Intent”; a critical knowledge repository to store, manage, and communicate ‘what is being built’ and ‘how it will be built’.
Want zoals W. Edwards Deming stelt: “Quality begins with the intent”