In spagaat tussen strategie en uitvoering

In spagaat tussen strategie en uitvoering
Agile ontwikkelen is populair. Bedrijven ervaren dynamiek in de markt en daarmee de behoefte om de IT in hoger tempo te wijzigen. Dat lijkt mooi, maar wat betekent dit voor de rol van de Enterprise architect?
Veel organisaties zijn bezig met de transitie van oude ontwikkel-methodieken, zoals waterval, naar een agile manier van werken. Dit leidt tot een grote verandering in het gehele ontwikkeltraject waarin development en operations in één team bij elkaar komen (DevOps-teams). Voor deze agile bottom-up geeft het ‘Scaled Agile Framework’, dat gebaseerd is op de ‘The Big Picture of Enterprise Agility’1, een aantal richtlijnen tot aanpassing van de werkprocessen.
Het doel van agile is om in een zo’n kort mogelijke tijd werkende software te leveren om in te kunnen spelen op snel veranderende omstandigheden. Om dit te bereiken is er minder prioriteit voor documentatie, moeten er zo min mogelijk handovers zijn tussen teams en is het aan te bevelen de deliverables op te delen in kleinere stukken (features) die direct toegevoegde waarde leveren voor het bedrijf. Een ander belangrijk verschil is dat er meer decentrale sturing ligt bij de DevOpsteams onder leiding van product owners. Het implementeren van een agile werkwijze noodzaakt tot herbezinning van de rol van de enterprise-architect. Het Agile Manifesto zegt het volgende: “De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams”.2
Als je dit principe bekijkt met een enterprise-view ontstaat er een probleem. Stel er zijn honderd DevOps-teams. Als deze teams de volledige vrijheid hebben is de kans op wildgroei groot. Te veel vrijheid in de vorm van technologiekeuzes en architectuurpatronen leidt onherroepelijk tot grote complexiteit in het systeemlandschap. De agile methodes hebben geen eenduidige visie op de rol van de enterprise-architect. Hij kan in de transitie naar agile terechtkomen in een spagaat tussen enerzijds het management dat behoefte heeft aan topdown-sturing op bijvoorbeeld complexiteitsreductie, en anderzijds de nieuwe DevOps-teams die sturen op agility. Architecten moeten daarom een nieuwe balans zoeken tussen strategie en uitvoering. De auteurs zien een duidelijke noodzaak voor verandering van de enterprise-architect op drie aspecten, namelijk in de werkproducten, werkwijze en gedrag.
Bondiger referentie-architectuur
Als de hele organisatie agile gaat werken is er meer focus op het direct toevoegen van waarde. Voor de enterprise-architect zien wij daarmee een beweging naar bondiger documenten op alle niveaus van strategie tot uitvoering. Het Scaled Agile Framework wordt door bedrijven zoals ING gebruikt. Accenture benadrukt de toegevoegde waarde ervan voor de alignment tussen teams in zijn publicatie ‘Accenture & Scaled Agile Framework, 2015’.3 Met dit framework worden planningsfasen en deliverables benoemd in een agile proces. Naast de procesinrichting geeft het framework ook handvatten voor het beter structureren van de deliverables zodat er betere aansluiting ontstaat op het agile proces. Er wordt onderscheid gemaakt tussen investment themes, epics en features (figuur 1) .
Figuur 1. Relatie tussen Scaled Agile Framework en architectuurproducten
 
DevOps-teams splitsen features op in meerdere stories en tasks. Stories verwoorden de user requirements in de vorm van use cases. Om de use case te verwezenlijken deelt het DevOps-team de stories op in tasks (figuur 2) . Investment themes volgen uit de strategie van de organisatie en kunnen een looptijd hebben van een half jaar tot zelfs enkele jaren. De businessen IT-managers bepalen samen welke investment themes prioriteit moeten krijgen middels een visualisatiemethode als Kanban. De toegevoegde waarde van de enterprise-architect hierin is het opstellen van een referentie-architectuur waarin hij op basis van de gekozen strategie adviseert over de juiste inhoudelijke richting (targetarchitectuur) en de weg daar naartoe (roadmap). In een agile wereld is het verstandig hierbij het principe ‘keep it simple’ toe te passen.4
Figuur 2. Architectuurproducten gerelateerd aan ‘agile work break down’
 
Bij het nadenken over de strategie en investment themes is er geen behoefte aan een heel boekwerk, maar aan discussies en documenten met voldoende diepgang om richting te geven. Hierbij verdient het aanbeveling de vormgeving zo begrijpelijk mogelijk te houden voor niet-architecten en veel te communiceren, bijvoorbeeld door de documentatie binnen de organisatie digitaal toegankelijk te maken. Hiervoor zijn wiki-achtige tools vaak veel bruikbaarder dan uitgebreide documenten.
Gebruik van standaarden
Een belangrijk onderdeel van de referentie architectuur zijn technologiestandaarden, die aangeven welke IT-oplossingen toegepast mogen worden voor bepaalde functionaliteit. Een klassieke keuze is die tussen maatwerk of pakketoplossingen, waarbij onder andere risico, kosten en time-to-market een rol spelen. Een agile organisatie heeft baat bij duidelijke technologiekeuzes omdat ze kaders aangeven voor de ontwikkelteams. Een ‘technology standards board’ is daartoe een beproefd middel. Business- en IT-managers beslissen samen over de standaarden die het bedrijf hanteert en bespreken voorstellen voor nieuwe standaarden. Ook in het Scaled Agile Framework wordt met standaarden gewerkt, vaak omdat dit extern opgelegd wordt. Dit heeft een belangrijke impact op de ontwerpvrijheden van het agile proces.5
Epice en features
Een ‘epic’ is verandering in de organisatie en in de IT die volgt uit de invest themes. Een epic kan een lifecycle van enkele maanden hebben. Epics worden uitgesplitst in features. Features zijn de uiteindelijke functionaliteiten die toegevoegd worden aan de organisatie. De agile architect kan een zogenaamde epicarchitectuur opstellen. Hierin geeft hij aan wat de businessverandering is en wat de impact is op de organisatie en op de domein- en applicatiearchitectuur. Daarnaast geeft hij aan welke principes, richtlijnen en standaarden van toepassing zijn. Het nieuwe aspect is hier dat een epic-architectuur de traditionele domeinfocus doorkruist, waardoor er samenwerking moet zijn tussen architecten van meerdere domeinen. Tevens zal de epic-architectuur niet alleen door de enterprise-architect opgesteld worden maar is dit een samenwerking van verschillende disciplines, zoals businessmanagers, business-analisten, productmanagers en specifieke lead designers.
 
Een dergelijk team wordt portfolio team genoemd. Een feature is een verdere verdieping van een epic voor een specifiek stuk functionaliteit. Het uitwerken van features kan het beste gebeuren in featureteams. Dat zijn multidisciplinaire teams met business-analisten, productmanagers, een lead designer, leden van DevOps-teams, de IT product owners onder leiding van een integrator en een enterprise-architect. De enterprise-architect kan het featureteam helpen met een zogenaamde feature-architectuur. De feature-architectuur maakt hij alleen als er meer diepgang nodig is op een bepaald aspect, bijvoorbeeld een ingewikkelde use case, security-aspecten of design van high performance-oplossingen. De architect heeft overzicht over de samenhang tussen de verschillende features en kan de teams adviseren. Voor sommige features zal de epic-architectuur voldoende richtinggevend zijn en kan de feature-architectuur achterwege blijven. De DevOps-teams krijgen daarmee meer vrijheid om oplossingen te ontwikkelen binnen de grenzen van de architectuur. De architect moet verantwoordelijk blijven voor de services en de standaard interactiepatronen in het systeemlandschap. Een goede best practice is om hiervoor een ‘cookbook’ te maken dat alle featureen DevOps-teams kunnen gebruiken.
Nieuwe werkprocessen
Met alle veranderingen op het gebied van werkproducten is het ook noodzakelijk om de werkwijze van de architect onder de loep te nemen. De grootste verandering is dat de architect meer accent moet leggen op interactie en communicatie. In een agile wereld kunnen analisten en ontwikkelaars de architect namelijk als ballast ervaren. Als er te veel afstand is tussen de ontwikkelteams en de architect krijgt de laatste al snel een ‘ivoren-toren-imago’. Daarom moet de architect niet te solistisch werken en een architectuur maken die begrepen wordt door de werkvloer. ‘De architect maakt de architectuur’ is verleden tijd en verandert in ‘team en architect maken samen de architectuur’, binnen de strategische context. Een agile enterprise-architect moet de referentiearchitectuur uitleggen en ter discussie durven stellen. Interactie met stakeholders leidt op zijn minst tot meer begrip en vaak tot betere oplossingen. Een goede mogelijkheid voor meer interactie is naast het co-design van epic- en feature-architecturen, het aanwezig zijn bij demo’s, sprintreviews en dergelijke. Zulke mechanismes zorgen voor intensieve betrokkenheid van de architect bij de uitvoering, waardoor hij afwijkingen van architectuur direct kan bespreken. Dit kan leiden tot aanpassingen in de software maar ook in de architectuur. Deze werkwijze laat zich goed combineren met een agile governance-structuur van architectuurboards op buildingblock- of domeinniveau. Onder leiding van domein- of enterprise-architecten worden referentie-, epic- en feature-architecturen besproken en vastgesteld met andere architecten, analisten en eventueel ontwikkelaars. Het vaststellen van een architectuur in een architectuurboard draagt bij aan consistentie. Daarnaast zorgt cross-domein-toetsing in zo’n board voor een hogere kwaliteit van de architectuurbeslissingen. Afwijkingen van de referentie-architectuur moeten worden vastgelegd in een waiver. Communicatie van de genomen beslissingen helpt daarnaast bij het vergroten van het draagvlak voor de architectuur binnen de organisatie.
Trusted advisor
We hebben gezien dat de agile architect interacteert met feature- en DevOpsteams om sturing te geven aan agile software-ontwikkeling. Aan de andere kant heeft de architect de rol om als ‘trusted advisor’ van het management te opereren. Door snel veranderende klantenwensen en de drive om snel werkende oplossingen te leveren, kan de neiging ontstaan om tactische oplossingen te bouwen die afwijken van de referentie-architectuur. Het is de rol van de architect om met het management te sparren over de gevolgen van deze tactische oplossingen. Soms is het nodig om vanwege een commerciële opportunity de strategische roadmap los te laten en een oplossing te ontwikkelen voor de korte termijn. In elk geval moet deze beslissing bewust worden genomen (conscious decision). De enterprise-architect moet
naast het relatienetwerk op het juiste niveau, het vertrouwen van het management hebben om deze rol zo te kunnen spelen. Om hierin succesvol te zijn, dient de architect hieraan veel tijd te besteden die ten koste gaat van de ondersteuning van feature- en DevOps-teams. Ook hier zit hij soms in een spagaat om de schaarse tijd goed te verdelen.
Communicatieskills
Het is binnen een agile werkconcept belangrijk om snel en effectief te communiceren. Het werken in multidisciplinaire portfolio- en featureteams waarin business en IT vertegenwoordigd zijn, is uitstekend geschikt om gezamenlijk tot oplossingen te komen. Maar het opent ook de mogelijkheid om gekozen oplossingsrichtingen opnieuw ter discussie te stellen. Omdat de featurearchitectuur tot stand komt in samenwerking met het feature-team, moet de enterprise-architect leren om heel interactief te werken en open te staan voor architectuuroplossingen die ook door anderen dan architecten worden aangedragen. Goede skills om workshops te leiden of te begeleiden zijn essentieel. Daarnaast moet men ook in staat zijn ideeën eenvoudig op een whiteboard of PowerPoint te visualiseren. Het bij elkaar brengen van verschillende belangen van stakeholders is met agile zichtbaarder geworden dan ooit. Als de architect hierin het vertrouwen weet te winnen van de groep en niet wordt gezien als een politieagent, kan hij heel effectief worden. Ook hierin komt de rol van trusted advisor weer naar voren.
Kritische succesfactorenrent
Om de veranderingen naar een agile enterprise-architectuur goed tot zijn recht te laten komen zijn er een paar kritische succes factoren (KSF’s). We definiëren de volgende KSF’s: governance, agile mindset, informatiedeling en lean kort.
• De governance rondom architectuur moet goed gedocumenteerd zijn. In een agile organisatie moet duidelijk zijn wie welke beslissingen mag nemen en welke verantwoordelijkheden teams hebben in relatie tot de architectuur en het ontwerp.
• Een agile mindset is belangrijk. Het gedrag van de teams moet gestuurd worden vanuit de agile principes. Voorbeelden hiervan zijn teams die bereid zijn om hun software snel en drastisch te veranderen (just enough, just in time) en mislukking zien als een mogelijkheid om te leren.
• Informatiedeling is erg belangrijk. Teams kunnen van elkaar leren door architectuur- en ontwerpbeslissingen met elkaar te delen. Daarvoor moet er in de organisatie tooling beschikbaar zijn waartoe iedereen toegang heeft. Voorbeelden daarvan zijn softwarepakketten zoals Microsoft Sharepoint en Atlassian Confluence.
• Het continu verbeteren van het agile architectuurproces met lean-methodieken is nodig om met een praktische blik te blijven kijken naar de toegevoegde waarde van het proces. Het evalueren van het proces en de vorm van de artefacten is gericht op het zo optimaal mogelijk ondersteunen van de agile teams en andere stakeholders.
Conclusie
Agile enterprise-architectuur is nodig in deze dynamische wereld. In de transitie naar agile architectuur zijn veranderingen nodig in werkwijze, werkproducten en gedrag. De agile enterprise-architect zal deze veranderingen vorm moeten geven en daarmee moeten balanceren tussen ondersteuning van DevOps-teams en behoefte aan langetermijnsturing van het management. Als hem dit lukt, zal de enterprise-architect een belangrijke rol blijven spelen in het agile veranderproces van de organisatie.
 
Tom Aalders (tom.aalders@student.uva.nl) is masterstudent aan de universiteit van Amsterdam. Hij is bachelor afgestudeerd op het onderwerp ‘agile architectuur’ aan de Hogeschool van Amsterdam.
 
Patrick Keijzers (patrick.keijzers@ing.com) is manager enterprise-architectuur.
 
Walter Bakker (walter.bakker@ing.com) is enterprisearchitect. Keijzers en Bakker zijn beiden werkzaam binnen de enterprise-architectuur-afdeling van ING in Nederland.
 
[1] Leffingwell, D. (2009). The Big Picture of Enterprise Agility. Geraadpleegd van http://scalingsoftwareagilityblog.com/wp-content/uploads/2009/11/ the-big-picture-of-enteprise-agilitywhitepaper.pdf
[2] Beck et al. (2001). Manifesto for Agile Software Development. Geraadpleegd van http://www.agilemanifesto.org
[3] Accenture & Scaled Agile Framework. (2015). Key Accenture Learnings on Scaled and Distributed Agile Delivery. Geraadpleegd van http://www.scaledagileframework.com/accenture-case-study/
[4] Ambler, S. W. (2002). Agile Enterprise Architecture -5.2 "Keep it simple". Geraadpleegd op 13 mei, 2015, van http://www.agiledata.org/essays/enterpriseArchitecture.html#Simple
[5] Leffingwell, D. (2010). Agile software requirements: lean requirements practices for teams, programs, and the enterprise. Addison-Wesley Professional.

Tag

Onderwerp



Niet gevonden? Vraag het de redactie!

Heeft u het antwoord op uw vraag niet gevonden, of bent u op zoek naar specifieke informatie? Laat het ons weten! Dan zorgen we ervoor dat deze content zo snel mogelijk wordt toegevoegd, of persoonlijk aan u wordt geleverd!

Stel uw vraag