Is er nog een rol weggelegd voor de enterprise-architect nu organisaties steeds meer agile worden? De traditionele enterprise-architect, gewapend met degelijke methodes, stappenplannen en geavanceerde modellen, lijkt de dinosaurus van het agile tijdperk te worden. Te groot, te log, te traag in zijn werken en daardoor niet opgewassen tegen de snelheid van de agile wereld. Of vraagt agile werken juist meer dan ooit om enterprise-architecten, vragen Eric Onderdelinden, Erik Hegeman, Martijn Hensema en Erik van Ramshorst zich af.

Al die zelfsturende, autonome, agile teams verliezen maar al te snel het zicht op het grotere geheel waaraan zij een bijdrage moeten leveren. Zij laten zich sturen door de prioriteiten van de product owner. Die heeft vaak wel goed zicht op wat de business wil, maar ontbeert de diepgaande IT-kennis om een juiste afweging te maken tussen gedegen en snel. Daarnaast kijken product owners vaak niet over de grenzen van hun eigen afdeling of proces.

Uiteraard wordt in de moderne tijd meestal voor snel gekozen, ook al gaat dit ten koste van degelijkheid. Begrippen als technology debt (achterstallig onderhoud) en refactoring (preventief onderhoud) zijn de product-owner dikwijls vreemd. Dat betekent dat de technische kwaliteit van systemen voortdurend verslechtert en het geld voor noodzakelijk onderhoud aan andere zaken wordt besteed. Vaak komt dit in het nieuws als computerstoring, maar in werkelijkheid gaat het gewoon om slecht ontwikkelde, onderhouden of geteste systemen die niet langer naadloos aansluiten op het grotere applicatielandschap.

Teloorgang van traditionele architectenrol

Als consultant mogen wij bij heel wat organisaties in de keuken kijken. Daarbij vallen twee dingen op als het gaat om de relatie tussen enterprise-architectuur en een agile way-of-working.

Enterprise-architecten worden vaak gezien als innovatieremmend, onbegrijpelijk, te traag en te dogmatisch. Een gemiddeld agile team slaagt er prima in om zich aan vertragende en als overbodig geziene controles en checks van architecten te ontworstelen. De architect verliest daarmee zijn toegevoegde waarde en relevantie en dat leidt tot observatie twee: het aantal enterprise-architecten wordt kleiner.

Voor het groepje architecten dat overblijft ziet de toekomst er prachtig uit

Organisaties kijken steeds kritischer naar wat enterprise-architecten bijdragen en hoeveel er nodig zijn om de beoogde bijdrage te leveren. Omdat bovendien een (flink) deel van het architectuurwerk naar cloudproviders verschuift, blijken er minder – misschien zelfs wel veel minder – enterprise-architecten nodig te zijn in de gemiddelde organisatie.

De opkomst van de nieuwe architectenrol

Tot zover het slechte nieuws. Het goede nieuws is dat die kleinere groep enterprise-architecten in steeds meer agile wordende organisaties wel steeds interessanter en uitdagender werk krijgen. Zij moeten daarvoor beschikken over heel specifieke en vaak ook nieuwe vaardigheden. Deze vaardigheden zijn schaars en daarmee goed betaald. Voor het kleine, selecte groepje enterprise-architecten dat overblijft in agile organisaties ziet de toekomst er prachtig uit.

Welke skills hebben die nieuwe enterprise-architecten dan nodig? Om het praktisch te maken illustreren we dit door de rol van de architect te belichten op strategisch, tactisch en operationeel niveau binnen een agile organisatie. Waar nuttig illustreren we de vaardigheden aan de hand van het Scaled Agile Framework (SAFe). Veel organisaties gebruiken SAFe als basis om hun agile werkwijze op te schalen. Andere voorbeelden zijn LeSS (Large Scale-Scrum) en het Spotify-‘model’. Voor de vaardigheden van de architect maakt dat echter weinig uit. Omdat we SAFe het meest tegenkomen, gebruiken we dat voor de voorbeelden.

Agile architectuur

Op strategisch niveau, binnen SAFe de portfoliolaag genoemd, is een enterprise-architect vooral bezig met planningsactiviteiten. Hij of zij werkt hierin nauw samen met de business en domeinarchitecten. De enterprise-architect vertaalt strategische initiatieven naar uitvoerbare bouwblokken. Daarbij maakt hij/zij onderscheid tussen functionele bouwblokken die direct (business)waarde leveren en technische bouwblokken die het fundament vormen voor de functionele bouwblokken. Op deze manier wordt al in de strategische fase een solide balans tussen technische kwaliteit en business gezocht en gevonden.

Op tactisch niveau, binnen SAFe de programmalaag genoemd, speelt de solution-architect de hoofdrol. Systemen en ontwikkelteams zijn zodanig ontworpen en georganiseerd dat zij zo autonoom mogelijk (business)waarde kunnen leveren. De solution-architect bewaakt hierbinnen het overzicht en de afhankelijkheden.

De agile (delivery)teams vullen het operationele niveau in, binnen SAFe de teamlaag genoemd. Agile teams zijn zo autonoom mogelijk, uiteraard binnen de context waarin zij werken. De solution-architect wordt vaak alleen geconsulteerd wanneer teams er zelf niet uit komen. Agile teams en systemen hebben afhankelijkheden. Afhankelijkheden tussen systemen voor het ontwikkelen van functionaliteit of bij het in productie nemen (deployment) van functionaliteit die meerdere systemen raakt. In beide gevallen is er afstemming nodig.

Verschuiving in de skillset van de architect

De agile teams moeten zo veel mogelijk focussen op het leveren van businesswaarde door het ontwikkelen van nieuwe functionaliteit en zo min mogelijk op het managen van de afhankelijkheden. Het managen van die afhankelijkheden is daarmee een rol van de solution-architect. In de praktijk zien we dat er vaak één architect per twee á drie teams nodig is, om die afhankelijkheden onder controle te houden.

Praktische handvatten

Voor kleinere veranderingen, het ontwikkelen van een appje, het maken van een mooi dashboard, het optimaliseren van een enkel proces, werken die kleine onafhankelijke multidisciplinaire agile teams supergoed. Maar voor grotere veranderingen, zoals het introduceren van een nieuw product of dienst waarbij marketing, logistiek, administratie, facturatie en helpdesk gelijktijdig gereed moeten zijn, werkt die structuur met die zelfsturende teams aanmerkelijk minder goed.

De (online) marketingcampagne kan pas beginnen als het product gereed is. Het moet te bestellen zijn, het moet geleverd kunnen worden, het moet betaald kunnen worden en de servicedesk moet vragen kunnen beantwoorden. De autonomie van de teams die elk aan een van die onderwerpen werken begint dan tegen te werken. Om gelijktijdig de eindstreep te halen is coördinatie onvermijdelijk.

Als er ook nog tussentijdse synchronisatiemomenten zijn – noodzakelijk in het kader van het moderne minimum viable product-denken waarbij producten vroegtijdig worden gelanceerd en in snelle iteraties worden verbeterd – dan is coördinatie op strategisch, tactisch en operationeel niveau een randvoorwaarde voor succes.

Op het strategische niveau moet de enterprise-architect een agile architectuur realiseren om de teams te ondersteunen. De belangrijkste uitdaging is om de verschillende onafhankelijke teams voldoende samenhang en sturing te bieden terwijl de autonomie niet wordt aangetast. Dit betekent dat de architect aan de ene kant individuele teams voldoende vrijheid moet geven om van de gewenste architectuur af te wijken ten behoeve van innovatie of wisselende businessprioriteiten.

Aan de andere kant mag de architect niet het overzicht verliezen en moet hij/zij teams helpen te convergeren naar de gewenste architectuur. In de praktijk betekent dit het bieden en voortdurend communiceren van begrijpelijke en relevante overzichtsplaten en actieve deelname aan planningssessies.

Op tactisch niveau bewaakt de solution-architect de technische afhankelijkheden tussen de lopende projecten. Op dit niveau is de hoogste prioriteit ervoor te waken dat de trein niet stil komt te staan. Dit gebeurt als de workload van een van de teams te hoog oploopt en alle andere teams moeten wachten op een kritische component. Belangrijk hierin is om teams te ondersteunen met een ‘tijdelijk design’ om prototyping en innovatie te ondersteunen en naar een ‘gewenst design’ te gaan naarmate een product wordt doorontwikkeld.

De architect helpt dus bij het maken van een eenvoudiger design of breekt een complexe component op in kleinere delen waaraan meerdere teams kunnen werken. Dit vraagt om een combinatie van diepgaand technisch inzicht, het bewaren van het overzicht en excellente communicatie-skills.

Solution-architecten worden vaak alleen geconsulteerd wanneer teams er niet uitkomen

Op teamniveau ondersteunt een architect meer op de achtergrond en zorgt dat transitiedesigns goed gecommuniceerd zijn. Zijn belangrijkste rol bestaat uit het voorkomen van ongewenste technology debt – klungelwerk in gewoon Nederlands – zowel binnen de individuele agile teams als tussen de teams onderling. Het opbouwen van technology debt wordt ten dele opgevangen doordat agile teams vaak zelf verantwoordelijk zijn voor het beheer. Daardoor worden ze feitelijk gedwongen om dit af te vangen.

Het opbouwen van technology debt tussen teams, bijvoorbeeld door onhandige integratiekeuzes, wordt niet zomaar voorkomen omdat er geen echte eigenaar van zo’n probleem is. Hier is regie over de teams heen voor nodig is; dat is nadrukkelijk de rol van de architect.

De skills van de nieuwe architect

Hierboven is beschreven hoe het werk van de architect verandert door de introductie van agile werken op steeds grotere schaal. Dit veranderende werk betekent ook dat de skills veranderen. De rol is echter niet fundamenteel anders geworden, maar de balans tussen de benodigde vaardigheden om succesvol te zijn, is verschoven. Specifieke skills die in het verleden belangrijk waren zijn dat nu nog – soms zelfs nog meer dan vroeger.

Technische competentie was altijd al belangrijk voor een succesvolle architect en is nu nog belangrijker geworden. De combinatie van de enorme innovatie die op dit moment plaatsvindt in de cloud waarbij voortdurend nieuwe diensten worden geïntroduceerd, en de versnellende businessverandering zorgt ervoor dat de tijd om technische besluiten te nemen steeds korter wordt.

Tijd voor uitgebreide productvergelijkingen is er niet meer. Een product moet binnen uren of dagen bruikbaar zijn. De architect moet daarom diepgaande kennis hebben om die afweging snel te kunnen maken. Opzoeken klinkt modern, maar kost helaas in de moderne, snelle, agile wereld teveel tijd. Je moet het weten en meteen besluiten.

Voor communicatie geldt een vergelijkbaar verhaal. Het was altijd al de rol van de architect om verschillende stakeholders te verenigen achter een oplossing. In de agile wereld is dat niet anders, hoewel er nu vaak nog meer alternatieven zijn. De uitdaging is daarmee groter geworden en de tijd om tot een compromis te komen kleiner. Kortom, de skill communicatie moet nog verder aangescherpt worden.

Sturen op degelijkheid moet expliciet zijn vastgelegd als target state (reference architecture). De belangrijkste verandering is de actief coördinerende rol op strategisch, tactisch en operationeel niveau. Daar waar de architect in het verleden zijn toekomstvisie geduldig achter zijn bureau in alle nauwkeurigheid kon uitwerken, moet hij/zij nu voortdurend actief rondlopen in de programma’s, projecten en agile teams.

Daar waar de architect in het verleden kon sturen op een scherp vastgelegde toekomst, de zogenaamde target state, moet deze nu voortdurend beslissingen nemen met een ingewikkelde balans tussen snel en degelijk. En hij of zij moet een heel scherp gevoel hebben voor waar een compromis kan en waar het echt niet kan. Gezien de autonomie van de agile teams zal dat op een coachende manier moeten gaan, daar waar in het verleden een autoritaire houding volstond.

Ten slotte is nabijheid tot ontwikkelteams belangrijk. Wat veranderd is, is het type bruggen dat de architect bouwt. Vroeger was deze bezig de brug tussen business en IT te slaan. Dat hoeft niet meer: in de agile werkwijze is de samenwerking tussen business en IT verweven, met name binnen teams, waardoor de architect een sleutelrol heeft tussen de teams. De positie van de architect verschuift hiermee langzaam van boven de teams naar steeds meer in en tussen de teams.

Conclusie: de nieuwe architect

De nieuwe architect moet dus balanceren tussen de korte en de lange termijn waarbij innovatie en prototyping ondersteund worden met tijdelijke designs:

  • Er is niet altijd sprake van een duidelijk transitiepad van de ‘as-is’ naar de ‘to-be’. Architecten moeten omgaan met meer transities.
  • De organisatie moet vanuit technologisch perspectief zo wendbaar mogelijk gemaakt worden (agile architectuur).
  • De nieuwe architect kan niet langer wegkomen met een pure ‘poortwachtersrol’ maar moet innovatie actief ondersteunen.
  • De positie van de architect verschuift; hij/zij staat niet meer boven de teams maar beweegt zich ertussen.
  • De architect is niet langer tussen IT en business gepositioneerd, maar tussen de autonome agile teams.

Door Eric Onderdelinden, Erik Hegeman, Martijn Hensema en Erik van Ramshorst,
werkzaam bij Deloitte Technology in de service line enterprise-architecture (contact: eonderdelinden AT deloitte.nl)

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter