Artikel

Architectuur in Agile projecten

De invoering van Scrum in organisaties heeft veel impact op de mensen die er werken en de rollen die zij vervullen. Dit geldt ook voor architecten. Scrum zegt weinig over architectuur en dus vragen veel architecten zich af, “Wat nu?” In dit artikel geven wij antwoord op die vraag. Meer dan ooit is de architect een communicator die alles moet weten. Hij staat midden in het team en heeft een visie op de toekomst.

Architecten die werken in een organisatie die Scrum heeft geadopteerd, hebben twee keuzes: meedoen of afhaken. De architect die zich steeds verder terugtrekt, versteent in zijn ivoren toren. Meedoen dus. In agile projecten is architectuur een belangrijk element voor succes. Het zorgt voor de balans tussen korte en lange termijn. Betrokken architecten staan midden in de realisatie en begrijpen wat gevraagd wordt en wat mogelijk is.

De architect als communicator gebruikt schetsen, ideeën en principes om globale IT oplossingen te ontwerpen en deze af te stemmen met een brede groep van stakeholders. Architecten zorgen voor een gedeelde visie bij iedereen, waarbij dikke architectuurdocumenten achterwege blijven. In plaats daarvan wordt er pragmatisch gekeken naar wat nu belangrijk is. Een goede architect combineert dat met een heldere visie op de toekomst, met oog voor de realiteit.

Architecten vervullen meer dan ooit een verbindende rol. Dicht bij de producteigenaar, om hem te helpen bij het vertalen van zijn wensen naar goede IT oplossingen en het prioriteren van de backlog. Dicht bij de teams om deel te nemen aan de dialoog over de dagelijkse onderwerpen die boven komen drijven. Architecten adviseren en helpen ideeën ontwikkelen voor verbetering.

Adoptie en invoering van Scrum

In de jaren zestig schreef Alfred Chandler al dat de organisatiestructuur van een organisatie verbonden is aan de strategie door de organisatorische processen. In de optimale wereld volgens Chandler geldt het volgende: Structuur volgt Processen volgt Strategie. Het is daarom logisch te stellen dat een procesverandering, zoals het adopteren van Scrum, een verband moet leggen tussen strategische keuzes en de structuur van de organisatie.

Figuur 1: Organisatie volgt Processen volgt Strategie

De toepassing van Scrum in een organisatie is een procesverandering. Het zorgt voor dramatische verandering van de dynamiek van softwareontwikkeling. Het is een manier van werken die begint bij business requirements en eindigt bij werkende software. Echter met de uitspraken van Chandler in het achterhoofd rijzen drie vragen, waarvoor in de agile wereld nog onvoldoende aandacht is:

1. Was de invoering van Scrum een voortvloeisel van de strategie van de organisatie en helpt Scrum de organisatie om de strategie uit te voeren?

Procesveranderingen binnen een organisatie hebben een doel nodig. Zonder een helder doel zal de invoering van een nieuw proces zeker falen. De motieven van invoering van Scrum zijn daarom zeker het onderzoeken waard. Wordt Scrum ingevoerd om de organisatie als geheel beter te laten werken, zodat de strategie verder ingevuld kan worden, of is het een uit de hand gelopen hobby van een IT manager? Een onjuiste aansluiting op de strategie van de organisatie, kan voor veel problemen zorgen bij de implementatie van Scrum.

2. Wordt de organisatiestructuur aangepast en ontstaan er nieuwe afdelingen?

Scrum invoeren betekent de komst van zelforganiserende teams die verantwoordelijkheid nemen om zaken gedaan te krijgen. Maar wat betekent dat voor de oude functionele afdelingen? Houden zij op te bestaan? Zal de rol van de lijnmanager veranderen, en hoe? En wat gebeurt er met ondersteunende IT-afdelingen zoals architectuur, kwaliteit en operaties? Een verandering is nooit geïsoleerd en kan op vele manieren de structuur van de organisatie beïnvloeden.

3. Hoe raakt Scrum de processen die in verband staan met software realisatie?

Processen in een organisatie zijn met elkaar verbonden en hebben elkaar nodig om optimaal te werken. Het Scrum proces heeft bijvoorbeeld een duidelijke invloed op het requirements proces. Maar ook voor de business processen geldt dat ze in staat moeten zijn om veranderingen sneller te adopteren dan voorheen. Daarnaast moeten de ondersteunende IT-processen worden geherdefinieerd in overeenstemming met het Scrum ontwikkelingsproces.

Deze vragen zijn te breed om allemaal te beantwoorden in één artikel. Dit artikel richt zich op de laatste vraag en specifiek over de wijze waarop de invoering van Scrum invloed heeft op de architectuurprocessen en de rol die de architect moet vervullen.

Architecten en Scrum

Het merendeel van de literatuur over de rol van architecten in een agile context richt zich op de agile flow zelf en hoe architecten deze flow zo min mogelijk verstoren. Mike Cohn, in zijn boek “succeeding with agile”, maakt het onderscheid tussen coderende en niet coderende architecten. Hij stelt dat de coderende architecten minder moeite hebben met het vinden van hun nieuwe rol in het agile-ontwikkelproces.

Mike Cohn vindt dat een architect binnen een team zit en in staat moet zijn om zelf software te coderen. Als lid van het team en door zijn ervaring helpt de architect de structuur van de applicatie te doorgronden en een betere software architectuur te realiseren. Scrum kent geen expliciete rol voor niet coderende architecten. De vraag rijst of er echt geen behoefte is aan deze architecten.

Architectuur in een agile omgeving hoort te passen binnen de waarden van het Agile Manifesto. Hieronder bespreken we deze waarden, waarbij we ingaan op wat de consequenties zijn voor de architectenrol. Het geeft een eerste blik op de wijze waarop de architectuurrol wordt beïnvloed door de invoering van Scrum.

1. Individuen en interacties boven processen en tools

De eerste agile waarde stelt dat alles draait om mensen en de manier waarop ze communiceren. Processen en tools kunnen nuttig zijn in bepaalde situaties, maar mogen nooit de nadruk krijgen. Verplichte dikke architectuurdocumenten bij de start van een project of langdurige reviewprocedures van documenten, zijn voorbeelden waar de processen en tools te veel aandacht krijgen. In een Scrum omgeving is dit uit den boze. Architecten verleggen hun focus van schriftelijke communicatie (zenden) naar mondelinge communicatie (dialoog). Ze communiceren met alle belanghebbenden in de organisatie. Architecten communiceren effectief met zowel de producteigenaar als met individuele teamleden. Effectieve communicatie is tweerichtingsverkeer, zodat de architect gevoed wordt met ideeën van anderen. Een architectuurraamwerk zoals TOGAF kan worden gebruikt, maar alleen om de visie echt te laten landen. De methode is niet bepalend voor welke activiteiten de architecten uitvoeren.

2. Werkende software boven uitgebreide documentatie

Architecten werkten in het verleden vaak op grote afstand van de daadwerkelijke software bouwers. Communiceren door middel van uitgebreide ontwerpdocumenten bleek veelal niet bepaald effectief. Hoewel architecten vaak zelf trots zijn op hun architectuurdocumenten, werkt dit anders in een Scrum omgeving. De invoering van Scrum in een organisatie dwingt de architecten om zich veel meer te richten op het communicatieve en faciliterende aspect van hun rol.

Een architect werkt nu veel meer met schetsen. Schetsen van de totaalplaat, schetsen van onderdelen waar problemen ontstaan, schetsen van nieuwe technieken etc. Precies genoeg om zijn rol te vervullen, maar zeker niet te veel. Hij gebruikt schetsen om de communicatie met de betrokkenen te structureren en om de kennis te delen. De schetsen evolueren mee met de inzichten tijdens een project. De input die bijvoorbeeld het ontwikkelteam geeft, wordt verwerkt in de schetsen. De schetsen helpen ook om problemen die ontstaan bij de realisatie van software te analyseren en om oplossingen te bedenken. Aan de hand van schetsen helpt de architect om bij alle belanghebbenden in de organisatie een gemeenschappelijk beeld te vormen, waarlangs iedereen zijn activiteiten richt. De kwaliteit van de software zal daardoor zienderogen verbeteren. Figuur 2 toont een voorbeeld van een dergelijke schets. Deze organisatie wil zijn brondata beschikbaar stellen conform het Master Data Management (MDM) concept. De visie hierop is toegesneden voor de organisatie en is een prima voorbeeld van de schetsen die een architect maakt.

Figuur 2: Voorbeeld van een schets van het Master Data Management concept

3. Samenwerking met de klant boven contractonderhandelingen

Architecten spelen een grote rol bij de alignment van IT en business. In ondernemingen met een complex multisysteem landschap en meerdere agile teams, staan architecten dicht bij de product- eigenaar. Met het schetsen van IT-oplossingen en het geven van inzicht in de complexiteit van deze oplossing, helpen architecten de producteigenaar om zijn prioriteiten vast te stellen. Globale ontwerpkeuzes samen met de producteigenaar maken zorgt voor betere input aan de teams. Zo leveren teams ook beter werk. Een effectieve relatie tussen een producteigenaar en een architect leidt tot verbeterde waardecreatie met minder inspanning.

4. Inspelen op verandering boven het volgen van een plan

De waarde van architectuur en architecten zit juist in het kunnen reageren op verandering. De beste manier om de dagelijkse problemen die vragen om wijziging van koers te ervaren is om dicht bij het ontwikkelteam te zitten. Architecten nemen deel aan praktische ontwerpvraagstukken. Zo ontstaat de architectuur vanuit de praktijk. Het aanpassen van schetsen is een stuk eenvoudiger dan het bijwerken van lijvige architectuurdocumenten. De architect laat de praktijk en de uitvoerbaarheid
leidend zijn en niet zijn oorspronkelijke overtuiging.

De functie van architect in een agile omgeving is dus echt anders dan we gewend zijn. Maar redenerend vanuit de agile principes zijn architecten nog steeds relevant, ook als ze niet zelf coderen. Communiceren en de dialoog met stakeholders is wel een stuk belangrijker geworden. De samenwerking met de producteigenaar helpt om de juiste balans te vinden tussen de business requirements en de IT mogelijkheden. De meeste van bovengenoemde veranderingen zijn gericht op het versterken van de hartslag van de Scrum teams. De software kan sneller worden opgeleverd met hogere kwaliteit, waardoor reeds gemaakte software minder vaak moet worden herontworpen.

De architect en visie

De nadruk bij veel Scrum implementaties ligt vaak op de rol van de architect bij het versterken van de ‘heartbeat’ van de iteraties en het product. Logisch, maar er is meer. Een architect is er ook om de visie te verwoorden en te creëren over hoe de IT ingezet kan worden in de organisatie; de IT als enabler. Hij onderkent en beheert nieuwe ontwerpideeën. Deze ontwerpideeën komen vanuit een strategische alignment met de business doelen en de enterprise architectuur. Het zijn verbeterideeën die bijdragen aan het resultaat en net als business requirements geprioriteerd moeten worden. Ook uit projecten waarbij tijdens het globale ontwerp of tijdens de realisatie van software, nieuwe ideeën ontstaan voor verdere verbetering.

Figuur 3 toont de twee aspecten van de rol van de architect. Aan de ene kant heeft hij een rol te spelen bij de versterking van de hartslag. Aan de andere kant heeft hij ook een rol te vervullen als visionair van de toekomst. In de volgende paragrafen zal voor elke afzonderlijke activiteit uit de Scrum aanpak de rol van de architect worden beschreven.

Figuur 3: Activiteiten van de architect binnen een Scrum omgeving

Product backlog

Traditioneel zijn architecten de hoofdontwerpers in softwareontwikkeling. Projecten starten vaak met een omvangrijk Project Start Architectuur document, opgesteld in enkele maanden tijd en met veel informatie over de te realiseren oplossing. Scrum projecten werkt vanuit de backlog, gevuld met themes, epics, user stories; korte beschrijvingen van wat er gevraagd wordt. Implementaties worden vaak als onderdeel van de sprint geformuleerd. Dus waar is de rol van de architect in dit geheel?

Architecten spelen een rol in de beginfase van een project door te sturen op complexiteit en haalbaarheid. Vooral in grotere organisaties met een grote hoeveelheid van software en systemen is daar expliciete aandacht voor nodig. Door echt te begrijpen wat de business requirements zijn kan je plannen voor te toekomst. Eenvoudige oplossingen die zorgen voor wendbaarheid op de lange termijn vereisen een goed begrip van de business requirements en focus op complexiteitsreductie. Natuurlijk kan je en wil je niet alles van te voren bedenken, we ontdekken pas echt of iets werkt door het te doen. Maar succesvolle projecten hebben een architectuurvisie, die zorgt dat een project niet verzandt in korte termijn oplossingen.

Architecten zetten het eerste globale ontwerp neer en houden focus op het totaalplaatje. Bij het maken van keuzes nemen architecten de rol van facilitator en zorgen ze ervoor dat zoveel mogelijk invalshoeken meegenomen worden. Ze zijn de spil in het multidisciplinaire web. Ze gaan het gesprek aan met producteigenaren over wat echt nodig is en met de agile teams over hoe de software echt werkt.

De ontwerpbeslissingen in het begin van een project worden normaliter in dit stadium op niet meer dan een half A4’tje opgeschreven. Zo voorkomt de architect zich te verliezen in details. De detail invulling doen de teams zelf. Architecten ondersteunen producteigenaren bij het vaststellen van prioriteiten door een eerste schatting te maken van de complexiteit van de oplossing.

Architecten werken epics van de product backlog uit in meer detail, passend binnen de totale architectuurplaat. Hij betrekt hierbij iedereen die daarvoor nodig is. Door dit uit de sprint te halen, kunnen teams zich beter richten op de specifieke oplossing binnen het gebied van hun deskundigheid en op de ‘heartbeat’ van de levering.

Werken in agile teams

Architecten zijn dagelijks aanwezig in agile teams. Hier praten ze mee over aankomende epics en user stories in de volgende sprint. Teams nemen dagelijks ontwerpbeslissingen die ze met de architect toetsen aan de architectuurvisie en het grotere plaatje. Dit zorgt voor samenhang en feedback voor de architect op de globale ontwerpbeslissingen. Architecten zonder ervaring met het werken in teams verliezen het contact met de werkelijkheid en kunnen geen goede architecturen ontwikkelen.

Architecten hebben een belangrijke rol in het toezicht houden op de architectuurprincipes in alle lagen van de architectuur. Dit betekent bijvoorbeeld dat ze moeten weten of alle business rules zijn geïmplementeerd binnen de business layer, of dat klantinformatie altijd wordt opgeslagen in het CRM-component. Dicht bij het team zijn helpt de architect om praktische architectuurprincipes op te stellen. Architectuurprincipes evolueren vanuit zowel een praktisch oogpunt als een visionair oogpunt.

Het samenwerken in teams met ontwikkelaars, testers, performance specialisten, hardware specialisten en meer, helpt bij het creëren en vastleggen van nieuwe ontwerpideeën, die niet altijd direct uitgevoerd worden. Nieuwe ideeën kunnen een impact hebben op meerdere teams, kunnen teveel tijd kosten voor realisatie binnen een sprint, of de expertise is niet beschikbaar binnen het team. De volgende paragraaf beschrijft de manier van werken met deze ideeën.

Omgaan met ontwerpideeën

Architecten die producteigenaren helpen bij het concretiseren van de product backlog en het werken in agile teams gaan vaak op in deze flow. Ze komen niet toe aan het andere aspect van hun rol: het ontwikkelen van de architectuurvisie voor de toekomst. Architecten moeten tijd vrij maken naast hun operationele en ‘heartbeat’ gerichte taken. Zo kunnen ze vooruit kijken naar welke mogelijkheden de IT de organisatie biedt. Het resultaat hiervan zijn ontwerpideeën. Deze komen grofweg op twee manieren tot stand.

Ten eerste ontstaan nieuwe ontwerpideeën in de realisatie flow. Agile teams zijn gericht op het implementeren van nieuw features met een betrouwbare snelheid. Verstoringen worden hierbij geminimaliseerd. Onverwachte issues die de flow verstoren kunnen we uit de iteratie halen en in een ontwerpidee vatten. De producteigenaar kan ze prioriteren en in de flow opnemen.

Nieuwe ideeën kunnen ook voortkomen uit de strategische alignment van de business en IT. Het opstellen van een enterprise architectuur en IT-strategie geven hier voeding aan. IT kan een kritische succesfactor worden van de organisatie en katalysator van veranderingen. Een enterprise architect of de Chief Information Officer is nauw verwant aan het hogere management van de organisatie. Hij of zij werkt samen met hen om te zien op welke manier IT kan worden gezien als één van de belangrijkste productiefactoren van de organisatie. De enterprise architect zal hierbij strategische keuzes vertalen in nieuwe ontwerpideeën. Deze ontwerpideeën zullen vervolgens hun weg vinden naar de product backlog.

In het verleden werden ontwerpideeën uitgevoerd, wanneer de architect vond dat het nodig was. In een agile aanpak werkt dat niet zo. Het uitgangspunt bij het prioriteren van ontwerpideeën is de realisatie van business value. Business value hoeft niet altijd kostenbesparing te zijn, maar kan ook worden gevonden in continuïteit (bijvoorbeeld wanneer het aantal servers niet zal worden uitgebreid zal het hele systeem instabiel worden), of aanpassingsvermogen (sneller nieuwe functionaliteiten toevoegen zonder dat hiervoor te veel refactoring nodig is binnen de teams). De producteigenaar beslist welke ontwerpideeën in de teams worden uitgevoerd. De architect heeft een belangrijke rol bij het promoten en adviseren van deze ontwerpideeën naar de producteigenaar.

Communiceer en balanceer het werk

Als we Chandler’s principes volgen, kunnen we stellen dat bij de adoptie van Scrum de organisatie, processen en strategie op elkaar afgestemd moeten zijn, anders zal het falen. In dit artikel hebben we de afstemming tussen de adoptie van Scrum en de architectuurprocessen onderzocht. We hebben beschreven op welke manier de rol van de architect vorm krijgt om meer business value te creëren.

De invoering van Scrum helpt de architect bij het focussen op de belangrijkste uitkomsten van zijn werk. Hij moet terug naar de basis. Door te focussen op minder documentatie en meer communicatie, kan de architect uitgroeien tot de belangrijkste versneller voor sprint teams en de organisatie helpen bij het bepalen van prioriteiten.

De architect moet zich echter niet verliezen in de dagelijkse problematiek van de producteigenaar en teams. Het toevoegen van visie is ook een belangrijk onderdeel van zijn werk. Elke architect moet daarom de balans weten te vinden in de dagelijkse werkzaamheden. Waar deze balans uiteindelijk uitkomt, zal zich in de praktijk moeten uitwijzen.

Architecten moeten nu wel uit hun ivoren torens komen. Er wordt van hen verwacht dat zij pragmatisch en betrokken zijn, zonder de toekomst uit het oog te verliezen.

Categorie:   
Auteur(s)
afbeelding van niklasodding
Niklas Odding
Xebia - Architect

Niklas Odding is architect bij Xebia en richt zich op de wijze waarop de architectuurfunctie evolueert binnen ondernemingen met Agile systeemontwikkeling.

afbeelding van gerardjanssen
Gerard Janssen
Xebia - Business Unit Manager

Gerard Janssen is business unit manager bij Xebia en verantwoordelijk voor de architectuur groep.

 
Reacties
Mary op zaterdag 12 maart 2011 18:16

Bedankt voor dit prima artikel!
Ook heel praktische handvatten voor architecten die graag uit hun ivoren toren willen komen en nog niet weten hoe dat aan te vliegen.

Chandler beschreef het top down organisatieproces (eigenlijk het management control systeem)waarin de organisatiestructuur de macro (concern) strategie volgt in een 4 tal case studies dat zijn boek "Strategy and Structure: chapters in the history of the industrial enterprise" opleverde en bijgevolg het adagium "structure follows strategy"

Nota bene tegelijkertijd waren er namelijk ook bottom up processen te ontdekken waar je over "strategy follows structure" kunt spreken. Met name wanneer de (lagere) manager een strategie uitzette als er snel een nieuw product op de markt gezet moest worden of een klant binnen gehengeld. Dan zei de concern top "ga vooral je gang"

Vooral dit laatste lijkt meer emergent / meer Agile dan het eerste.
Volgens mij heeft Chandler nooit 'structure follows processes follows strategy' geroepen. Enfin, de verwijzing naar Chandler is in mijn ogen niet zo toepasselijk. Misschien had hier naar Bower & Doz verwezen kunnen worden of naar Burgelman die beide processen met elkaar verenigde.

Maar dat doet aan de verdere inhoud van dit artikel niets af.
De adviezen zouden meer mensen ter harte kunnen nemen

Jeroen op woensdag 16 maart 2011 14:43

"In het verleden werden ontwerpideeën uitgevoerd, wanneer de architect vond dat het nodig was. In een agile aanpak werkt dat niet zo. Het uitgangspunt bij het prioriteren van ontwerpideeën is de realisatie van business value......De producteigenaar beslist welke ontwerpideeën in de teams worden uitgevoerd. De architect heeft een belangrijke rol bij het promoten en adviseren van deze ontwerpideeën naar de producteigenaar."

Vrij vertaald: vroeger keek een architect niet naar business value, maar deed gewoon wat hij dat wat goed was. Sinds we SCRUM hebben realiseert de architect dat hij eigenlijk wat doen wat goed is voor het bedrijf. Een vreemde stelling?

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.