Artikel

Rol van architectuur in een Agile aanpak

Ondanks alle mooie verhalen levert de traditionele architectuur aanpak nog niet of nauwelijks de beoogde resultaten. Met een agile aanpak lijkt dit wel te gaan lukken. Geven we met agile het stuur dan weer in handen van de ontwikkelaars die in eerste instantie die spaghettibrij hebben veroorzaakt? Hetgeen wat we juist met architectuur proberen te voorkomen? En welke rol heeft architectuur en de architect dan nog in een agile aanpak? Op naar de praktijk...

Bij een logistiek bedrijf loopt een grootschalig project waarbij een aantal legacy systemen vervangen dienen te worden. Daarbij gaat het om de ondersteuning van een bedrijfskritisch proces met hoge eisen aan betrouwbaarheid en beschikbaarheid. De systemen zijn voorzien van een groot aantal interfaces, zowel intern als extern, met diverse uiteenlopende functies zoals het combineren van administratieve informatie met GEO, management informatie en processturing. Verder zijn er hoge verwachtingen op het gebied van aanpasbaarheid, flexibiliteit, kwaliteit en (lage) kosten. Functionaliteit zal gefaseerd opgeleverd worden, gedurende een langere looptijd (aantal jaren). Een complex en uitdagend geheel dus. Na diverse pogingen is uiteindelijk gekozen voor een agile aanpak (in dit geval SCRUM). Deze aanpak blijkt succesvol te werken. Hoe kan het dat bij een dergelijk complex project, in tegenstelling tot bijvoorbeeld RUP, een agile methode als SCRUM wel succesvol is?

Een deel van het succes heeft met de SCRUM methodiek zelf te maken, waarbij communicatie en de gebruiker centraal staan, de producteigenaar bepaalt en er continu een volledige ‘software life cycle’ wordt doorlopen. Maar welke rol en plek heeft architectuur en de architect dan in een agile aanpak?

Architectuur als bindmiddel tussen business en ICT

In de loop der tijd zijn bedrijven steeds meer afhankelijk geworden van hun informatievoorziening. Het is een bepalende factor in hun bedrijfsvoering geworden en ook een substantiële kostenpost. Intussen is het systeemlandschap uitgegroeid tot één grote “lappendeken” van geïsoleerde systemen die nauwelijks meer te wijzigen en aan elkaar te knopen zijn. Het resultaat hiervan is dat de ICT een ‘disabler’ geworden is voor de gewenste en benodigde veranderingen.

Als reactie hierop is het architectuur denken ontstaan. Architectuur is het middel om business en ICT beter op elkaar te laten aansluiten, zowel nu als in de toekomst, tegen acceptabele kosten. Architectuur zorgt voor samenhang, overzicht, communicatie, kaders en richting.

Met het introduceren van architectuur ontstond ook de rol van de architect. De architect is de bruggenbouwer, hij slaat de brug tussen business en ICT, hij zorgt voor overzicht, kan zowel op strategisch als uitvoerend niveau opereren, hij is domeinexpert, weet wat de mogelijkheden en onmogelijkheden zijn, geeft richting aan oplossingen en bewaakt deze.

Architectuur is de remmende factor

Bij het merendeel van de - zeker grotere - bedrijven is het werken onder architectuur en de functie van architect gemeengoed geworden. Er is een heel circus opgetuigd met frameworks, richtlijnen, start architecturen, methodieken, modellen en tooling. Het uitvoeren en beheren hiervan biedt heel wat mensen een dagtaak. Dit is echter een alsmaar groeiende kostenpost, waarvan je kunt afvragen of die nog in verhouding staat met wat het oplevert.

De door de architecten beoogde resultaten blijven vaak uit. ICT trajecten gaan zeker niet sneller, leveren vaak niet de beoogde functionaliteit en er is ook nog geen sprake van flexibiliteit en herbruikbaarheid. In tegendeel. Architecten beschouwen alles in zijn totale samenhang waardoor de scope continu wordt opgerekt. Hoe meer architecten, hoe meer overleg en discussie, hoe langzamer de besluitvorming. De uiteindelijk voorgeschreven oplossingen worden vaak gezien als complex, moeilijk te begrijpen, niet praktisch en onuitvoerbaar. Met als gevolg dat architectuur dermate vertragend werkt en de oplossing dermate complex wordt dat ICT wederom de remmende factor is, terwijl architectuur dat toch juist zou moeten oplossen.

Agile

In reactie hierop is agile ontstaan. Bij agile staat de gebruiker centraal. Alles is gericht op het leveren van business value. Dit vertaalt zich in het zo snel mogelijk opleveren van een werkend product, in dit geval software. Het zo snel mogelijk opleveren van werkende software gaat uit van een aantal agile principes. Uit oogpunt van architectuur zijn de belangrijkste principes:

  • Eliminate waste
  • Make the simplest thing that can possibly work
  • Decide as late as possible
  • No big design up front

Dat betekent dat er niet gewerkt wordt vanuit een op voorhand uitgewerkte architectuur, maar dat telkens voor de op dat moment meest eenvoudige oplossing gekozen wordt. Een reden om niet te werken vanuit een volledig uitgewerkte architectuur is dat dit, zeker in het begin, leidt tot te zware en complexe oplossingen, die niet nodig zijn voor wat op dat moment gevraagd wordt. Gedurende een deel van het traject is er dan sprake van “ballast”, waardoor simpelweg minder functionaliteit geleverd kan worden in dezelfde tijd, voor hetzelfde geld.

Het op voorhand bepalen van de architectuur gaat er ook vanuit dat de gebruiker weet wat hij wil en dat dit niet verandert gedurende het traject. In de praktijk zie je echter dat dingen die op voorhand heel belangrijk leken en geleid hebben tot bepalende elementen in de architectuur, gedurende het traject toch niet meer nodig blijken te zijn.

Het maken van een keuze op het moment dat het echt moet, verhoogt ook de kans op de juiste keuze, simpelweg omdat je dan meer weet. Eén van de grootste uitdagingen in de architectuur is het onderkennen van subsystemen, componenten en modules. Maximale samenhang en minimale koppeling blijft iets arbitrairs. Het onderkennen hiervan zal veel beter gaan naarmate de situatie concreet is.

In de praktijk...

In het eerder omschreven project was op voorhand een architectuur uitgedacht gebaseerd op SOA. Deze architectuur bestond uit een opeenstapeling van lagen met daaroverheen een opsplitsing naar diverse onafhankelijke subsystemen (componenten). Deze moesten door middel van webservices via een ESB communiceren met de front-end. De gebruiker vroeg in een sprint een simpel overzichtslijstje op het scherm. Dit betekende het optuigen van drie subsystemen, het realiseren van een aantal webservices, die vervolgens met behulp van de ESB georchestreerd dienden te worden. Voor deze simpele functionaliteit moest dus een heel circus opgetuigd worden, wat voor dat moment pure ‘waste’ was. Uitgaande van de meest simpele oplossing voor dat moment was dit lijstje in no time gebouwd.

Agile is architectuur

Het primair gericht zijn op het zo snel mogelijk leveren van functionaliteit wekt de indruk alsof bij agile geen sprake zou zijn van architectuur. Dit is zeker niet het geval. Bij een agile aanpak is (de interne) kwaliteit van het systeem juist zeer belangrijk. Alleen met een kwalitatief hoogwaardig systeem kunnen de snelheid van ontwikkelen, testen en uitleveren gehaald blijven worden. Er moet tenslotte iedere 2 à 3 weken nieuwe productierijpe functionaliteit geleverd worden.

Het verschil is alleen dat de architectuur niet op voorhand wordt bepaald, maar ontstaat uit de functionaliteit, ofwel “form follows function”. Dit kan leiden tot situaties die vragen om refactoring. De hele aanpak is dan ook gericht op het continu kunnen omgaan met veranderingen.

Agile en grote complexe systemen

Van origine is agile ontstaan uit de ontwikkeling van kleinere, vaak stand alone en web-based applicaties. Langzaam maar zeker zie je deze werkwijze ook doordringen bij de ontwikkeling van grotere en complexere systemen. Hoewel refactoring een integraal onderdeel is van de agile aanpak, zie je dat de impact van refactoring (exponentieel) groter wordt met de omvang van het systeem. Dit heeft te maken met de hoeveelheid code, het niet meer met 100% zekerheid alles kunnen testen en het feit dat er meerdere teams bij betrokken raken.

Een van de belangrijke succesfactoren van een agile aanpak bij grote systemen is dan ook het minimaliseren / voorkomen van onnodige (grootschalige) refactoring. Met onnodig bedoelen we refactoring die voorkomen had kunnen worden door van tevoren wat verder vooruit te kijken. Het tijdig aandacht hebben voor architectuur is dan ook een belangrijke maatregel om onnodige (grootschalige) refactoring te minimaliseren en randvoorwaardelijke zaken tijdig geregeld te hebben.

Verschillende tijdhorizons

Het tijdig aandacht hebben voor architectuur komt tot uiting doordat er in een agile aanpak meerdere momenten zijn waarop nagedacht wordt over de constructie en functie van het systeem. Net als bij elk ander project zul je ook voor de goedkeuring van een agile project een idee moeten hebben over wat het project gaat opleveren en wat het gaat kosten. Met name de kosten worden bepaald door de oplossingsrichting en de daarbij benodigde mensen en middelen. Ook voor het op hoofdlijnen vaststellen van de migratiestrategie is dit inzicht gewenst.

Het project of deelproject (in geval van een programma) start met een ‘Envisioning’ fase (zie Scott Ambler). In deze fase wordt gezamenlijk de visie bepaald en is er sprake van ‘initial architectural modeling’. Hierin wordt een gemeenschappelijk beeld bepaald van de oplossingsrichting voor het gehele project.

Een project is verdeeld in sprints (iteraties) van twee à drie weken. In iedere sprint worden zogenaamde user stories (beschrijvingen van functionaliteit vanuit gebruikersperspectief) gerealiseerd. Tijdens een sprint vinden de meest concrete keuzes plaats en wordt uiteindelijk de werkelijke architectuur bepaald. Elke user story is echter als het goed is al meerdere malen door de teams besproken alvorens deze daadwerkelijk gerealiseerd gaat worden. Je kunt zeggen dat er al een aantal sprints vooruit wordt gekeken.

Zo zie je dus dat er op meerdere momenten wordt nagedacht over de constructie en functie ofwel architectuur van het systeem, waarbij de mate van vooruit kijken verschilt en daarmee ook de diepgang.

In de praktijk...

Het project is niet gestart vanuit een agile aanpak. Na een uitgebreid aanbestedingstraject had het bedrijf besloten om de regie weer in eigen hand te nemen. Gekozen was voor RUP als methodiek, met SCRUM als omgangsvorm. Vanuit het aanbestedingstraject lag een uitgebreide blauwdruk. Tijdens de elaboratiefase was men conform RUP bezig de architectuur verder uit te diepen en technisch te bewijzen. De technische risico’s werden met proof of concepts e.d. uit de weg gewerkt. De organisatie bestond uit drie teams - twee ontwikkelteams en een architectuur & QA team (AQUA). In totaal waren er zeven architecten. Deze waren verantwoordelijk voor de architectuur. Met veel overleg werden vele architectuurbesluiten genomen en uitgebreid gedocumenteerd. De architectuur werd beschreven in een SAD, en vervolgens moesten de ontwikkelaars zich hieraan gaan houden.

 

Intussen werd er wel conform SCRUM gewerkt in sprints, met een product backlog (prioriteitenlijst van de functionele eisen) en de aanwezigheid van product owners (vertegenwoordiger van de business die eigenaar is van de product backlog en daarmee de functionaliteit bepaalt). Na een aantal sprints ontstond het gevoel dat het op deze wijze combineren van RUP en SCRUM niet de manier was – er kon namelijk te weinig functionaliteit in de sprints geleverd worden, terwijl er wel al twee volledig opgetuigde ontwikkelteams bezig waren. Op dat moment is besloten volledig voor SCRUM te gaan.

 

Allereerst is men terug gaan werken naar de meest eenvoudige oplossing voor de functionaliteit van dat moment. Zo werden bijvoorbeeld subsystemen en bepaalde lagen weer geëlimineerd en evenzo het inzetten van een ESB en Processerver. Momenteel wordt zelfs gedacht aan het afschaffen van de webservices.

 

Het programma is verdeeld in tranches. Voor de eerste tranche is een roadmap opgesteld van vier releases. Voor iedere release is kort en krachtig bepaald wat het doel is, welke brokken functionaliteit erin zitten en hoe het systeem in het landschap past qua interfaces. Dit geheel is beschreven in een paar PowerPoint sheets. Dit geeft voldoende richting en inzicht in wat er gaat komen. De praktijk heeft ook geleerd dat deze releases inhoudelijk al een paar keer veranderd zijn.

Meer in detail staat het werk en de prioritering hiervan op de product backlog. De product backlog wordt vooral gedreven vanuit gewenste functionaliteit. Er wordt geprobeerd om zoveel mogelijk architectuur bepalende elementen te koppelen aan functionaliteit. In de praktijk blijkt dit voor een groot deel te lukken. Zaken die normaal gesproken als non-functional requirements worden beschreven, maken nu deel uit van user stories (denk aan performance eisen, security, logging en auditing, e.d.). Technische vraagstukken worden op het moment dat dit nodig is door middel van spikes (het uitproberen van een technische oplossing van een user story) getackeld.

 

De kunst is ervoor te zorgen dat dit soort “thema’s” tijdig genoeg de aandacht krijgen, ofwel dat ze de benodigde prioriteit krijgen. Dit kan alleen door de product owner van het belang hiervan te overtuigen. Hiermee wordt afgedwongen dat je geen architectuur doet om de architectuur, maar dat er ook daadwerkelijk vraag naar moet zijn. Zolang je de product owner hier niet van kunt overtuigen, zal het ook niet gebeuren.

 

De product backlog wordt regelmatig met de teams besproken in de vorm van design en pokersessies (sessie waarin user stories worden verkend, besproken en wordt ingeschat hoeveel tijd het kost om deze te realiseren).

Oude wijn in nieuwe zakken?

Je zou kunnen denken dat dit toch hetzelfde is als bij de traditionele aanpak van architectuur. Initial architectural modeling is toch niks anders dan bijvoorbeeld een Project Start Architectuur bij DYA. Dat is echter niet waar. Bij agile wordt het bepalen van de oplossingsrichting door de teams gedaan en wordt dit niet door architecten bepaald die dit opleggen aan de teams. Er wordt niet meer tijd besteed dan nodig, het moet ‘just good enough’ zijn. Afhankelijk van de omvang van het project zijn dit een aantal uren tot een paar weken. Ook de manier waarop de resultaten worden vastgelegd is vrij te bepalen door de teams. Er hoeft dus geen gebruik gemaakt te worden van formele methodes en tooling.

In de praktijk...

Bij het eerder genoemde project is bijvoorbeeld een Wiki ingericht. Hierop kan iedereen uit de teams relevante informatie opvoeren, aanvullen en wijzigen. In tegenstelling tot het SAD waarmee begonnen is, zie je dat architectuurelementen nu bestaan uit foto’s van white board schetsen, kleine schema’s met enige toelichting, voorbeeldcode. Feitelijk het minimale wat de teams nodig hebben bij het uitvoeren van hun werk.

Bestaat de architect dan nog wel?

In agile wordt de architectuur bepaald door de teams en niet door een architect. Is er dan nog wel sprake van een architect? De agile aanpak vraagt om zeer ervaren en deskundige ontwikkelaars. Het toepassen van best practices en ‘design patterns’ is bijvoorbeeld essentieel voor de kwaliteit van het systeem. Bestaat het team uit uitsluitend ervaren (agile) mensen dan is feitelijk een architect overbodig.

Zeker bij grotere projecten, met meerdere teams zie je dat niet iedereen dezelfde vaardigheden heeft. In dat geval is er nog wel zoiets als de rol van (software)architect. Deze wordt ingevuld door hetzij softwarearchitecten hetzij door ervaren ontwikkelaars. De architect werkt met de ontwikkelaars samen om vanuit zijn expertise de teams te adviseren en te stimuleren in het vinden van de beste oplossingen. Een architect kan nooit iets opleggen aan de teams. Het team is en blijft verantwoordelijk en bepaalt.

In de praktijk...

In het project zitten nu nog twee architecten, beiden in het ondersteuningsteam (dus buiten de ontwikkelteams). Er is een softwarearchitect die zeer ervaren is in agile software ontwikkeling en Java. Hij kijkt met name naar de interne kwaliteit van het systeem. Hij adviseert, ondersteunt en stimuleert de ontwikkelteams bij de constructie van het systeem. De ander is een informatie architect die meer gericht is op de inbedding van het systeem in het applicatielandschap en het voldoen aan de corporate kaders.

 

Er is geen sprake van een “architecture owner” (zoals Scott Ambler voorstelt). Dat impliceert namelijk dat architectuur eigendom zou zijn van één of een aantal personen en dat is juist niet de bedoeling.

 

Er is een Technical Advisory Board waarin de corporate architecten en de projectarchitecten zitten. Hierin worden de binnen het project gekozen oplossingsrichtingen besproken om te kijken in hoeverre ze passen binnen het corporate beleid.

Conclusie

Architectuur is investeren in de toekomst, maar niet ten koste van. Het doel heiligt niet altijd de middelen. Een onderneming is te zeer afhankelijk van zijn informatievoorziening en daarom moet er beweging zitten in de ICT.

Met de agile aanpak wordt optimaal geleverd wat de business vraagt, maar met oog voor de kwaliteit van het systeem. Daarbij is de aanpak en het systeem volledig gericht op het kunnen omgaan met veranderingen, waardoor ook de zo gewenste aanpasbaarheid en flexibiliteit geleverd worden. Belangrijk hierbij is dat deze aanpak ervoor zorgt dat het vertrouwen van de business in de ICT hersteld wordt. Het vertrouwen en de bewezen oplossingen bieden een fundament van waaruit verder gewerkt kan worden richting ondernemingsbrede oplossingen zoals herbruikbare componenten.

De architectuur wordt bepaald door de teams. De rol van architect wordt feitelijk door iedereen vervuld en staat niet meer boven de teams. Wanneer toch nog sprake is van een expliciete architectenrol dan is deze ter ondersteuning van het team en niet meer als de bepaler en bewaker.

Het verschil tussen een traditionele architectuur aanpak en een agile aanpak kan als volgt getypeerd worden:

Categorie:   
Auteur(s)
afbeelding van marcocoopmans
Marco Coopmans
G*NIE - Informatie Architect

Ik ben ruim 20 jaar werkzaam in de IT, waarvan de laatste 10 jaar als architect. Sinds 2007 ben ik als onafhankelijk Informatie Architect werkzaam bij G*NIE en begeleid ik (middel)grote ondernemingen bij het bepalen en uitvoeren van hun architectuur op diverse vlakken. Mijn werkzaamheden bevinden zich op het raakvlak tussen business en IT, zoals het vertalen van beleid en strategie naar informatiebeleid en (enterprise) architectuur. Ik ben werkzaam geweest op zowel enterprise- als op projectniveau. Specialisaties zijn componenten architectuur, applicatie integratie, en Business Intelligence. Mijn doel is een optimale aansluiting tussen business en IT. IT is een complexe materie, maar wordt af en toe ook onnodig complex gemaakt. De kunst is om het eenvoudig, begrijpbaar en inzichtelijk te maken, voor zowel de klant als voor de IT organisatie. Een aantal opdrachtgevers waren ING Bank / Rabobank International / Pensioenfonds PGGM / ENECO Energie / Havenbedrijf Rotterdam.

 
Reacties
Henk Ledderhof op woensdag 20 oktober 2010 13:06

Via via je artikel ontvangen.
Leuk om zo alles op een rij te zien. Van de week ook een presentatie van Victor gezien bij het Agile consortium.
Uiteraard kan ik je artikel goed volgen en vind ik het leuk om te lezen dat de weg die we zo hebben ontdekt ook een half jaar later nog een goede weg lijkt te zijn.
Het was leuk met je te hebben samengewerkt.

Groet, Henk

Ton Eusterbrock op maandag 8 november 2010 14:59

Beste Marco,

Als architect heb ik weinig tot geen ervaring met werken in een Agile team. Ik heb wel gewerkt bij opdrachtgevers waar Agile de aanpak was van bouwtrajecten.

In he artikel werd ik getriggerd door de opmerking "Architectuur als bindmiddel tussen business en ICT".
in zoverre ga ik hierin mee dat het hebben van goede designpatterns voor (systeem)ontwikkeling daar een goed voorbeeld van is.
Maar architectuur is niet alleen een vak dat geldt voor de ICT ontwikkeling. op LinkedIn las ik de uitspraak in de EA Network discussie groep "Architectuur is niet het bindmiddel tussen ICT en de business, maar het bindmiddel tussen strategie en de realisatie van een onderneming"

Persoonlijk vind ik dit een doelstelling die beter omschrijft wat een succes van architectuur kan zijn. Dit kan tegelijkertijd ook elden voor een deel van een organisatie (lees: alleen ICT). Maar ultiem natuurlijk van de hele onderneming.
Ik geef toe dat dit wel vraagt om een hoog volwassenheidsniveau in het omgaan met architectuur.

Vanuit die gedachte vind ik het dan ook jammer dat Agile wordt beperkt tot voornamelijk het ICT voortbrengingsproces. Agile lijkt me namelijk een geschikt middel voor welke vernieuwing dan ook , of het nu gaat om software of de invoering van een nieuw productassortiment. En de grootste winst zit hem daarbij denk ik vooral in het werken in multidisciplinaire teams.

Marco Coopmans op dinsdag 9 november 2010 7:53

Beste Ton,

Allereerst bedankt voor je reactie!

Als ik naar arrchitectuur kijk vanuit de invalshoek van ''bieden van samenhang', zie ik altijd 2 richtingen: namelijk horizontaal -dat is de samenhang tussen business en ICT - en verticaal - dat is de samenhang tussen strategie en uitvoering.

Dit artikel beperkt zich (gezien de case) tot het softwareontwikkelproces op een agile manier en daarmee zit je al in de uitvoering en ligt het accent ook meer op de horizontale samenhang. Ik ben het met je eens dat de kracht van architectuur ook zeer zeker zit in de vertaling van strategie naar uitvoering. Dit is ook een onderwerp waarin ik in een volgend artikel aandacht aan wil besteden.

Dat agile ook zeker toe te passen is in andere voortbrengingstrajecten staat buiten discussie. Het agile gedachtengoed is ook ontstaan in de autoindustrie (denk aan Lean, Six Sigma en lees maar eens "The Toyota way").

Groet, Marco.

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.