Als ik ze op de werkvloer spreek, lijkt er soms een enorme kloof te bestaan tussen architecten en agile ontwikkelaars. De agile ontwikkelaars verwijten de architecten met een “big design up front” en knellende regels te komen die hun creativiteit en effectiviteit in de weg staan. De architect verwijt de agile teams alle kanten op te gaan (behalve natuurlijk de goede kant die de architect heeft uitgedacht) en daarmee een zo optimaal mogelijk systeemlandschap in de weg te staan.
De positie die Enterprise architectuur inneemt in de informatievoorziening lijkt op eerste gezicht haaks te staan op het agile gedachtegoed. Traditioneel kijkt Enterprise architectuur naar wat de business nodig heeft en hoe de business zich de komende 5 tot 10 jaar gaat ontwikkelen. Vanuit het bestaande IT-landschap wordt een visie opgesteld, over welke IT-voorzieningen er moeten komen, om de business in de toekomst zo optimaal mogelijk te kunnen ondersteunen. Deze visie vormt de basis voor roadmaps, uitgezet in de tijd. Er wordt governance ingericht om de systeemontwikkeling aan te laten sluiten bij de spelregels van de vastgestelde architectuur. Het doel van de Enterprise architectuur is hierbij om de business behoefte te optimaliseren over alle, bij de informatievoorziening, betrokken aspecten. Deze drang naar optimalisatie leidt in de regel tot strakke kaders voor de systeemontwikkeling.
In de loop van de tijd zijn bedrijven en organisaties voor hun bedrijfsvoering steeds afhankelijker geworden van ICT. Hand in hand met deze toename zijn de kosten voor ICT hoog opgelopen. Systeemlandschappen werden steeds complexer en er ontstond een spaghetti van onderlinge afhankelijkheden. In de jaren ‘80 en ‘90 van de vorige eeuw zien we als reactie op deze oplopende kosten en complexiteit, architectuur als verbinding tussen business en ICT opkomen.
Helaas blijkt dat werken onder architectuur niet altijd de beloftes waar maakt. In praktijk zien we nogal eens, dat als het in de projectuitvoering spannend wordt en er deadlines dreigen te worden gemist, het verleidelijk is om de architectuurprincipes overboord te gooien. Ook wordt architectuur soms als vertragend ervaren. Er moet immers eerst een Project Start Architectuur (PSA) worden geschreven. Als deze PSA dan ook nog de snelle, kort door de bocht oplossing die de business voor ogen had om zeep helpt, draagt dat niet bij in het naar waarde schatten van architectuur.
Aan de andere kant van de kloof staat de agile werkwijze. Deze werkwijze focust zich op het snel opleveren van waarde en direct business rendement. Met motto’s als “faal snel en vaak” en “zorg voor directe terugkoppeling in tegenstelling tot het in één keer goed willen doen”. Agile ontwikkelen vindt plaats met zelfsturende teams die de vrijheid en kennis hebben zelf hun richting te bepalen. Of zoals het Agile Manifesto zegt: "The best architectures, requirements, and designs emerge from self-organizing teams". Binnen Scrum is er dan ook geen specifieke rol beschreven voor de architect.
De business is in het algemeen erg enthousiast over agile ontwikkelen. Dankzij de agile werkwijze wordt namelijk snel waarde voor de business opgeleverd. Door de directe terugkoppeling worden resultaten tastbaar en kan direct worden bijgestuurd. De business zit weer zelf aan het roer van de systeemontwikkeling. Keerzijde is dat afdelingen als architectuur en beheer hun grip op de ontwikkeling van het landschap lijken te verliezen. Hoe kan de architect nog verantwoordelijk zijn voor de optimalisatie van het IT-landschap als de business de ontwikkeling direct, buiten de architectuur om, aanstuurt?
Wordt er met meerdere scrum-teams gewerkt dan blijkt het een hele uitdaging de resultaten van deze teams op elkaar aan te laten sluiten. Hoe voorkom je dat deze teams ieder een eigen oplossing voor overeenkomstige problemen realiseren? Vaak blijkt pas achteraf dat, in plaats van de door de teams opgeleverde point solutions, de keuze voor een meer geïntegreerde oplossing beter was. Er zijn diverse frameworks die het opschalen van de agile werkwijze ondersteunen. ‘Scaled Agile Framework’ (SAFe) is een veelgebruikte methode om de agile werkwijze in een grotere omgeving te structureren. SAFe erkent de noodzaak van architectuur en geeft de architect een rol in het ontwikkelproces. Binnen SAFe is de ook rol ‘Enterprise Architect’ gedefinieerd. De ‘Enterprise Architect’ is onder meer verantwoordelijk voor de strategische architectuurbeslissingen, zoals technologische keuzes en keuzes voor infrastructuur. Door het opstellen en onderhouden van een ‘Intentional Architecture’ wordt richting gegeven aan de systeemontwikkeling.
De ‘Architectural Runway’ legt binnen SAFe het pad waarlangs de features en nieuwe capabilities zo optimaal mogelijk gerealiseerd kunnen worden. Deze Runway bestaat uit de code, componenten en technische infrastructuur en bij de samenstelling van deze ‘Architectural Runway’ hebben de diverse architecten een belangrijke rol. Voor de realisatie van de Runway kent SAFe Enablers. Met deze Enablers wordt al het werk zichtbaar gemaakt dat nodig is voor efficiënte ondersteuning van het opleveren van business functionaliteiten.
Maar ook bij SAFe zal de architect zijn spreekwoordelijke ivoren toren moeten verlaten. Om als architect in een agile omgeving tot je recht te komen, moet je de agile werkwijze begrijpen en omarmen. Je moet invoelen waar je werk als architect ophoudt en waar je de agile teams de vrijheid moet geven zich te kunnen ontplooien. Je komt als architect niet meer weg met het schrijven van dikke architectuurrapporten en het aanleggen van lijstjes met voorschriften waar ontwikkelaars zich aan moeten houden. Je hebt als architect nog steeds een belangrijke rol, maar deze zal meer een coachende en op wisselwerking met de teams gebaseerde inhoud hebben dan een voorschrijvende.
In een agile omgeving zal je je als architect ook meer agile moeten gedragen. Als architect zul je de agile teams kunnen helpen hun blik gericht te houden op die stip op de horizon. Maar je moet ook als architect in staat zijn die stip te laten bewegen, als daar vanuit de teams goede argumenten voor zijn. In de teams zit als het goed is veel kennis en denkkracht. Door als architect ruimte te geven en gebruik te maken van deze kracht, ontstaat een betere architectuur.
Mijn tips voor de architect in de agile wereld zijn:
-
Omarm het Agile gedachtegoed. Doorleef het en pas het toe in je werk als architect.
Door zelf meer agile te worden als architect kan je de voordelen van deze werkwijze beter op waarde schatten en vind je aansluiting bij de ontwikkelteams. Zorg dat je vertrouwd bent met de agile rituelen en pas ze ook zelf toe in je eigen werk.
-
Beschouw architectuur als een middel niet als doel. Faciliteer de realisatie van de architectuur in plaats van deze af te dwingen. Ondersteun de teams met het inbrengen van kennis over de architectuur en laat ze de voordelen van de architectuur zien en beleven.
-
Plaats de stip op de horizon, maar laat deze stip wel agile meebewegen met de ontwikkelingen. Architectuur is niet meer eens in de 5 tot 10 jaar een dik rapport met de onwrikbare marsorders voor de systeemontwikkeling, maar een continu proces dat de systeemontwikkeling gidst.
