“Wat is de impact van het Agile werken op de ... - scrum… · Bezoekadres Postadres el 15 -...

“Wat is de impact van het Agile werken op de manier waarop met architectuur wordt omgegaan en wat betekent dit voor de rol van de architect?”

Kees jan Bender, ProwarenessVictor Grgic, LeanArch.euRini van Solingen, Prowareness, TU Delft

Bezoekadres Postadres Tel: 015 - 2411800 www.prowareness.nl Prowareness Postbus 2903 Fax: 015 - 2411821 www.scrum.nl2601 CT Delft 2601 CX DelftBrassersplein 1

Inhoudsopgave

1. Inleiding 2

2. Agile Architectuur, wat is dat? 3

3. Hoe komt een Agile Architectuur tot stand? 5

4. Hoe gaat Agile Architectuur om met verandering? 7

5. Wat betekent Agile Architectuur voor de rol van de architect en het team? 9

6. Conclusie 13

7. Referenties 13

8. Over de auteurs 14


1. InleidingWanneer organisaties zich oriënteren op het gebruik van Agile werkwijzen ontstaat al snel de vraag op welke manier ze met architectuur om moeten gaan. Agile heeft ten slotte de neiging om niet al te ver vooruit te plannen en beslissingen uit te stel-len tot een later tijdstip waarop meer kennis beschikbaar is. In traditionele omgang met architectuur nemen we echter belangrijke beslissingen juist vooraf. Het is dan ook logisch dat de combinatie van Agile en Architectuur in eerste instantie wat ongemakkelijk aanvoelt. Dat is het centrale thema van deze whitepaper. Agile werken heeft namelijk verstrekkende gevol-gen voor het omgaan met architectuur. We proberen daarom in deze whitepaper antwoord te geven op de vraag:

“Wat is de impact van het Agile werken op de manier waarop met architectuur wordt omgegaan en wat betekent dit voor

de rol van de architect?”

Daarbij wordt tevens gekeken naar een aantal principes en best practices over hoe je om kunt gaan met architectuur bin-nen Agile softwareontwikkeling. De volgende hoofdvragen komen in deze whitepaper aan bod:

- Wat betekent Agile Architectuur?

- Hoe komt een Agile Architectuur tot stand?

- Hoe gaat Agile Architectuur om met verandering?

- Wat betekent Agile Architectuur voor de rol van de architect en het team?


2. Agile Architectuur – Wat is dat?

Het gebruik van Agilemethoden (met Scrum als meest popu-laire) groeit sterk. Agile aanpakken kenmerken zich door het in korte cycli van enkele weken opleveren van werkende en ge-teste software die klaar is voor productie. Het resultaat is de levering van daadwerkelijke toegevoegde waarde voor de eindgebruiker en de business. Hierdoor ontstaat een sterke terugkoppeling vanuit business en gebruikers naar ontwikkel-teams. Bovendien wordt altijd het meest waardevolle als eerste gedaan én productierijp opgeleverd. Het werk wordt daarbij uitgevoerd door kleine, zelfsturende en multidisci-plinaire teams.

Architectuur in een Agile omgeving maakt onderdeel uit van het totale geheel van een groot aantal verschillende disciplines die samen zorgen voor een continue flow van probleem naar werkende oplossing. Dit proces herhaalt zich iedere sprint. De architectuurdiscipline zelf wordt ingevuld door het gehele team ondersteund door verschillende domein experts. In Agile Architectuur worden besluiten zo laat mogelijk genomen. Dit is gebaseerd op het lean principe: ‘decide at the last responsible moment’. Tegelijkertijd wordt zeer vroeg en zo nodig iedere sprint opnieuw samen met betrokkenen stilgestaan bij de opties, visie, afwegingen, standaarden, enzovoort. De daad-werkelijke besluiten worden echter net voor de implemen-tatie van het betreffende besluit genomen en met eventuele nieuwe inzichten kan ieder besluit later weer teruggedraaid worden. Dit vraagt dan ook dat architecturele keuzes zelden tot nooit het gevolg hebben dat er geen weg terug meer is. Kortweg: architecturele keuzes mogen nooit in beton gegoten worden. Doordat sprints een relatief korte verandering bevat-ten, zijn de besluiten in Agile Architectuur over het algemeen ook relatief klein en kunnen in de komende sprints al in de software geëffectueerd worden.

2.1. Vloeibare architectuur

Wat architectuur Agile maakt is de omarming van alle mogeli-jke veranderingen. Het team streeft er naar om alle architectu-urbesluiten vervangbaar te maken. Architectuur wordt dus als het ware vloeibaar gemaakt. Op deze manier hoeft men in het begin zeer weinig tot geen tijd te besteden aan een basisarchi-tectuur. De basisarchitectuur bevat slechts significante beslui-ten. Een besluit mag significant genoemd worden wanneer de kosten van verandering hoog zijn. Kortom, het is raadzaam om zo weinig mogelijk significante beslissingen te nemen. Een Agile Architectuur is daardoor eenvoudiger vervangbaar en aanpasbaar, zelfs het fundament ervan. Dit wordt voornamelijk bereikt door eenvoud. Bij het maken van een architectu-urkeuze, kiest men altijd voor de meest eenvoudige oplossing die net voldoende ondersteuning biedt voor te implementeren systeemfuncties in de komende sprint.

Deze werkwijze is niet te verwarren met de term “flexibele” architectuur. Een flexibele architectuur impliceert een sterke mate van voorspelbaarheid van welk deel van een architectuur flexibel hoort te zijn. Een volledig flexibele architectuur bestaat niet. De pogingen tot deze zijn slechts zeer prijzig. Een gede-gen en op de toekomst voorbereide architectuur is volgens de Agile Architectuur principes het product van voortdurende feedback vanuit gebruikers en business waar vervolgens het team telkens op acteert. Op deze wijze wordt architectuur in een Agile omgeving steeds beter. Het team is ook continu met architectuur bezig, echter doordat het om kleine stappen gaat kost het ook niet veel tijd.

2.2. Welke architectuur hebben we het over?

Architectuur kent meerdere verschijningsvormen op verschil-lende abstractieniveaus. Wanneer er over architectuur gespro-ken of geschreven wordt is het goed om eerst helder te maken welke architectuur precies bedoeld wordt. Architectuur is een containerbegrip, het betekent verschillende dingen voor verschillende personen. Je kunt een hele goede discussie over architectuur voeren zonder exact te begrijpen waar de ander het precies over heeft. We hebben het in deze whitepaper voornamelijk over het ontwerp van een software systeem (software architectuur1) en de samenhang daarvan met andere applicaties en informatiesystemen. De architectuur is dan het 1 De meeste vormen van architectuur (informatie architectuur, enterprise architectuur, security architectuur, etc.) hebben doorgaans weinig met architectuur te maken. Ze voegen doorgaans weinig toe. Het zijn slechts aspecten die per situatie meer of minder van belang zijn. Agile enterprise architectuur is gewoon Agile architectuur, maar dan over de afdelingen en projecten heen. Zolang een architect niet direct in een team zit of met teams samenwerkt, wat is hij/zij dan precies aan het doen? Hier laten we het echter voorlopig maar even bij omdat dit thema (diversiteit in architectuur) een onderwerp (en discussie) op zichzelf is.


resultaat van systeemontwikkeling binnen een project waaraan één of meerdere Agile ontwikkelteams bijdragen.

2.3. Waarom is het handig een architectuur op een Agile manier te laten ontstaan?

Voordat we inzoomen op het wat en hoe aangaande Agile Architectuur willen we eerst ingaan op de motivatie waarom je dit zou moeten doen. Immers, het is ook mogelijk om een architectuur op de klassieke manier vooraf uit te werken, om vervolgens de implementatie van de software via korte itera-ties op een Agile wijze te realiseren. Dat is overigens een werk-wijze die we in de praktijk regelmatig aantreffen. Het nadeel daarvan is dat de architectuurdiscipline dan geen onderdeel uitmaakt van een continue flow en daarmee een blokkerende stap wordt in het leveren van business value iedere iteratie. Het tweede nadeel is dat een dergelijke aanpak geen reken-ing houdt met voortschrijdend inzicht. Bij systeemontwikkel-ing tast je doorgaans in het donker, omdat er voorschrijdend inzicht aanwezig is.

Dat is nu net waar de schoen wringt: voortschrijdend inzicht zit in de kern van systeemontwikkeling. Een deel van de archi-tecten is echter van mening dat ze in het donker kunnen zien. Ze proberen overal rekening mee te houden en zijn daarvoor bewapend met zeer omvangrijke methodieken en modellen die zouden kunnen vertellen wat er in het donker zoal te zien zal zijn.

Een andere groep architecten probeert niet de toekomst te voorspellen en werkt wel op basis van voortschrijdend inzicht. Echter, de kosten van voortdurende architectuurveranderingen in een niet-Agile omgeving zijn zodanig hoog dat de omgeving ofwel het projectmanagement dat niet accepteert. Vraag een architect naar de grootste frustraties in diens rol en de kans is groot dat er een antwoord volgt in de trant van: “Als ik alles van te voren had geweten, dan had ik het toch net even iets anders gedaan.”. Immers, we vragen van een architect eigen-lijk het onmogelijke: in een omgeving waar veel verandert, waar nog volop ontdekt en geleerd wordt en waar voortschri-

jdend inzicht een gegeven is, vragen we van de architect om een architectuur op te zetten die voor elk toekomstig scenario geschikt is. Aangezien architecten niet helderziend zijn en geen glazen bol hebben, is het niet realistisch van hen te vragen om een architectuur te bedenken die mee kan bewegen met alle onvoorziene wijzigingen.

Daarnaast is een frustratie van veel architecten dat zij weliswaar een mooie architectuur hebben bedacht, maar dat deze slechts gedeeltelijk daadwerkelijk in het systeem inge-bouwd is. Als de architect niet continue uitlegt en controleert, is de kans groot dat het uiteindelijke systeem niet volledig aan het architectuurontwerp voldoet. In het kort: aangezien de architectuur uiteindelijk maar op één plaats zit, in de software, is het belangrijk dat iedereen die de implementatie verzorgt ook volledig conform de architectuur denkt en werkt. In de ogen van architecten is bewaking een nobele taak, zodat we op langere termijn een goede architectuur krijgen. Teams hebben hier echter grote moeite mee omdat ze zich te veel gecontroleerd voelen, ze de architectuur onvoldoende onder-schrijven, begrijpen of omdat de bedachte architectuur sim-pelweg niet werkt in de praktijk. Zelfs als deze uitdagingen zijn opgelost kan de omgeving niet accepteren dat zoiets belangri-jks als een architectuur door één persoon of een kleine groep mensen kan worden opgelegd.

Beide frustraties van de gemiddelde architect worden binnen Agile Architectuur opgelost. Ten eerste wordt de architectuur niet vooraf volledig vastgelegd, maar laat men deze ontstaan tijdens ontwikkeling. Daarvoor bestaat de mooie term “emerg-ing architecture”, de architectuur komt als het ware “boven-drijven”. Dat gaat niet vanzelf en lukt alleen als iedereen die daar bij betrokken is hier voldoende aan bijdraagt en over meedenkt. Vandaar ook dat het team centraal staat. Gezamen-lijk werkt het team aan de architectuur en bepaalt gezamenlijk welke beslissingen worden genomen. Zodoende wordt de ar-chitectuurvisie en de uitwerking gedeeld door alle teamleden en is de kans dus ook veel groter dat het zijn weerslag vindt in de software. Bovendien delen alle teamleden als het ware de architectrol waardoor het ook niet noodzakelijk is om alles vooraf uit te denken. Het is immers mogelijk om architectuur-beslissingen uit te stellen tot het laatst verantwoorde moment.

Kortom, naast de noodzaak om goede afspraken te maken over architectuur binnen Agile omgevingen, is Agile Architectuur ook in staat om een aantal van de basisproblemen met archi-tectuur in de meer traditionele en lineaire werkwijzen op te lossen. Agile Architectuur is dus geen probleem, maar vooral een oplossing!


3. Hoe komt een Agile Architec-tuur tot stand?In de traditionele architectuurbenadering wordt vooraf aan de bouw van software eerst een architectuur document gemaakt. Deze heten bijvoorbeeld SAD (Software Architecture Docu-ment) of PSA (Project Start Architectuur). De gedachte hier-achter is: “het wijzigen van architectuur is kostbaar, dus je kunt er maar beter zo vroeg mogelijk uitgebreid over nadenken om de kans op wijziging zo klein mogelijk te maken”.

In de Agile benadering is het uitgangspunt gelijk, maar de oplossing is net andersom. Bij Agile Architectuur luidt het adagium: “het wijzigen van architectuur is kostbaar, neem ar-chitectuurbeslissingen daarom zo laat mogelijk om de impact van verkeerde beslissingen zo klein mogelijk te houden en creativiteit zijn werk te laten doen door voortdurend te leren van ervaringen”. Een te vroeg genomen besluit heeft als gevolg dat het besluit niet meer overwogen wordt. Nieuwe inzichten worden nauwelijks in beschouwing genomen en tegen de tijd dat het besluit geëffectueerd wordt is het vaak niet eens meer duidelijk wat het besluit is en vooral waarom die genomen is. Daar komt bovendien de noodzaak tot het documenteren vandaan. Bij Agile is dus sprake van architectuur die geleidelijk evolutionair tot stand komt, waarbij zoveel mogelijk getracht wordt om alle opties open te houden.

We zijn in deze whitepaper begonnen met de constatering dat een op Agile manier tot stand gekomen architectuur niet wezenlijk hoeft te verschillen van een architectuur die via een traditioneel proces tot stand gekomen is. Aan de architectuur zelf zou dat niet te zien hoeven zijn. Een architectuur is een architectuur. Achteraf na een project is er maar één architec-tuur, los van de manier waarop deze tot stand is gekomen. De belangrijkste Agile principes voor het architectuurproces zijn ‘net op tijd’ en ‘net genoeg’. Op basis hiervan worden ontwerp-beslissingen genomen. Dit heeft tot gevolg dat voortschrijdend inzicht geen ‘bedreiging’ voor de architectuur is, maar een

kans biedt om de architectuur (nog) beter te maken. Daarna-ast zorgt continue vereenvoudiging (refactoring) er voor dat steeds de eenvoudigste oplossing overblijft. Kwaliteit van een architectuur zit dus voor een belangrijk deel in de eenvoud er-van. Het volgen van een Agile benadering biedt daardoor een grotere kans om tot een hogere kwaliteit te komen.

De ‘net op tijd’ en ‘net genoeg’ principes zijn erop gebaseerd dat het meestal niet efficiënt is om tijd te besteden aan zaken die op dit moment nog niet belangrijk zijn. Ten eerste, omdat er een grote kans is dat het verwachte beeld veranderd zal zijn tegen de tijd dat het wel belangrijk is geworden. Ofwel: later in het proces weten we altijd meer dan in het begin. Ten tweede, het niet doen van minder belangrijke zaken levert je tijd op die je beter kunt besteden aan zaken die op dit moment al belangrijk zijn. Het is ook een soort van wetmatigheid dat zaken die écht belangrijk zijn ook al helder zijn. Als het niet helder is, hoe kan je dan weten dat het belangrijk is?

Het ontwerpen van een Agile Architectuur houdt onder meer in dat er continu alleen de op dat moment significante besliss-ingen worden genomen. De architectuur zal dan gaandeweg het project al lerende verder worden ingevuld. De meest significante beslissingen zijn die beslissingen die hoge ve-randerkosten met zich mee brengen als ze langer zouden worden uitgesteld. Aan het begin van het project zijn dat er natuurlijk tamelijk veel zoals de keuze voor een type applica-tie, architectuurstijl en technologie. Naarmate er een aantal iteraties gedaan is worden het er geleidelijk aan minder. Er is in die zin dus wel sprake van enig ontwerp vooraf, echter niet meer dan strikt noodzakelijk. Maar ook niet minder! Begin dus met wat de meest eenvoudige en waarschijnlijke architectuur


is volgens de kennis van dat moment. Wijzig het architectuur-model op basis van wat nodig is volgens de laatste inzichten en wanneer dat nodig is.

Als er een grote impact is bij onjuistheid van belangrijke ar-chitectuurbeslissingen, dan is het wel goed om het ontwerp in code eerst te bewijzen met een werkend product. Dit kan door het opzetten van een architectuurskelet en het maken van een “vertical slice” van een end-to-end scenario, waar-bij alle relevante lagen van de applicatie geraakt worden. Daarnaast kan men een “spike” doen wanneer men over on-voldoende kennis en ervaring beschikt over een technische oplossing. Een spike is een time box periode van enkele dagen waarbinnen een bepaald technisch concept wordt ontwikkeld om de werking van het concept aan te tonen. Een reden kan bijvoorbeeld zijn om eerst meer kennis op te doen van een nieuwe technologie of 3rd-party component, alvorens beslo-ten wordt deze in te zetten. Doe dit liefst op zo’n manier dat het resultaat eenvoudig is te integreren in de oplossing, dan heeft het de meeste waarde. Een spike is meestal een on-derdeel van de backlog voor een sprint. Een spike lijkt op een “proof-of-concept” met een cruciaal verschil. Een product van een succesvolle spike wordt niet weggegooid, maar gebruikt om functionaliteit te leveren. Ook bij een spike die meer dan enkele mandagen duurt dient men zich altijd af te vragen of technologie niet te complex is of dat door gebrek aan kennis externe hulp ingeroepen moet worden. Als dat het geval is dan is het namelijk lastig om het ‘eenvoud’ principe te kunnen vasthouden.

Kortom:

• Neem steeds alleen architectuurbeslissingen gebas-eerd op wat je tot dan toe weet en nodig hebt; dus ‘net op tijd en net genoeg’.

• Vul de architectuur al lerende in of herzie eerdere besluiten zodat architectuur evolueert gaandeweg het project en met het voortschrijdende inzicht.

• Begin gewoon in de eerste iteratie de architectu-urkeuzes te maken voor de hoogst geprioriteerde user stories of use cases.

• Maak een vertical slice of doe spikes om onzekere architectuurbeslissingen te bewijzen maar zorg er wel voor dat deze een werkend (en demonstreerbaar) product opleveren.

4. Hoe gaat Agile Architectuur om met verandering?Agile aanpakken geven de voorkeur aan het inspelen op veran-dering boven het volgen van een gedetailleerd plan. Hoezeer je ook zou willen dat de architectuur van een systeem niet ve-randerd hoeft te worden (omdat de kosten daarvan vaak hoog zijn), het is vaak onvermijdelijk. Een goede Agile aanpak zorgt ervoor dat noodzakelijke verandering in een zo vroeg mogelijk stadium bekend wordt (wanneer de kosten nog relatief laag zijn) en zo snel en goedkoop mogelijk worden doorgevoerd. Dit wordt bereikt op de volgende manieren:

1. Door te prioriteren op businesswaarde en de belangrijk-ste zaken voor de business eerst te doen. Dat dwingt je automatisch om de belangrijke architectuurbeslissingen vroeg te nemen, want die zullen daarin het sterkst naar voren komen.

2. Door na elke iteratie een werkend product op te leveren. Noodzakelijke verandering door fouten in het ontwerp raken op die manier vroeg bekend.

3. Door optimaal gebruik te maken van alle beschikbare kennis in het team. De architect staat er niet alleen voor bij het maken van nieuwe maar ook van veranderde architectuurkeuzes.

4. Door Test-Driven Development (TDD) en refactoring tools wordt het team steeds verder in staat gesteld architectuurveranderingen snel en goedkoop door te voeren.

5. Door iedere sprint tijd te reserveren om de (eventuele) ontstane technische achterstand direct in te halen om de dure ophoping van achterstand te voorkomen.

6. Door een ver doorgevoerde geautomatiseerde testing op verschillende niveaus (unit, component, integraties, user interface, database) kan men vrijwel direct na elke ingrijpende aanpassing met grote zekerheid weten of het systeem nog steeds naar behoren functioneert.

7. Door dagelijks inzicht in de kwaliteit door middel van geautomatiseerde kwaliteitsbewaking.

8. Door te kiezen voor ontwikkelomgevingen met grote mate van vrijheid gebaseerd op erkende standaarden, waarmee een ontwikkelaar zich ondersteund voelt en niet beperkt wordt bij het doorvoeren van substantiële en noodzakelijke aanpassingen.


4.1. Ontwerp voor verandering, maar houd het simpel!

Het is niet alleen de Agile werkwijze zelf die telt bij het kun-nen omgaan met verandering. Het is bovenal het principe om altijd te ontwerpen met mogelijke verandering in het vooruit-zicht. Dit houdt in dat de veranderbaarheid (changeability) een basiskenmerk van elk Agile ontwikkeld systeem zal zijn. Het sleutelwoord daarbij is ‘eenvoud’. De veranderbaarheid van een systeem is namelijk sterk afhankelijk van de mate van complexiteit van de oplossing. Hoe complexer het systeem, hoe minder makkelijk het kan worden aangepast. Agile Ar-chitectuur streeft daarom naar een continue vereenvoudig-ing van systemen. Hoe simpeler, hoe beter: en gereed voor de toekomst. Zorg er daarom voor dat het ontwerp altijd zo eenvoudig mogelijk is. Dit is tevens in lijn met het eerder geno-emde ‘net genoeg’ principe.

Wees daarnaast voorzichtig met het ontwerpen van generieke en flexibele constructies. Het idee achter dit soort constructies is meestal dat ze met een eenmalige extra inspanning kunnen worden gemaakt die je dan later vanzelf terugverdient. Dit is echter alleen het geval als dat ook daadwerkelijk gebeurt. De kans is veel groter dat je veel tijd besteed aan het zo generiek mogelijk inrichten (met alle nadelige gevolgen voor bijv. test-baarheid, begrijpelijkheid, analyseerbaarheid en performance) om er vervolgens later niets aan te veranderen. Ze maken het systeem echter complexer en moeilijker testbaar. Agile werk-wijzen gaan er vanuit dat latere aanpassingen alleen nodig zijn als ze écht veel extra waarde opleveren. In dat geval is extra inspanning ook geoorloofd. Met andere woorden, het gener-iek en flexibel inrichten heeft een veel te grote kans om het doel voorbij te schieten met grote nadelige gevolgen op tijd, kosten en kwaliteit. Concentreer je daarom liever op datgene wat nu belangrijk is en hou dat zo simpel mogelijk. Maak iets pas generiek als later blijkt dat de constructie vaker wordt ge-bruikt en om een generieke implementatie vraagt (tijdens het refactoren). Het vooraf generiek opzetten voor iets dat later nog gaat komen (lees: dus minder belangrijk is), is feitelijk het verdraaien van prioriteiten. Iets dat belangrijk is mag nooit ingewikkelder worden opgezet ten gunste van iets dat minder belangrijk is.

Bij het nadenken over eenvoud in architectuurontwerp ko-men als vanzelf design patterns ter sprake. Het kopje boven dit stukje en ook het voorgaande punt lijken wellicht het gebruik van ontwerppatronen te ontmoedigen. Dat is echter niet de bedoeling. Design patterns kunnen zeer bruikbaar zijn, zeker in situaties waar nog veel onbekend is, kan het heel handig zijn om van start te gaan met het meest voor de handliggende patroon. Het is wel zo dat overmatig gebruikte patronen het risico in zich hebben om tot onnodige complexiteit en het gevreesde ‘over-architecting’ te leiden. In de basis zijn ont-

werppatronen reeds bewezen, simpele oplossingen voor com-plexe problemen. Je kunt wel altijd goed nagaan of jouw prob-leem wel zo complex is als datgene wat het patroon in staat is op te lossen. Vaak bieden patronen gradaties van complexiteit en volstaat het om de simpelste vorm ervan te implementeren. Desgewenst kan later complexiteit worden toegevoegd, mocht dat belangrijk genoeg zijn en voldoende noodzakelijk. Denk daarbij ook weer na over het moment waarop je een patroon introduceert, pas op het moment waarop de behoefte er werkelijk is. Een concreet voorbeeld is een SOA implementatie. Begin altijd met slechts een enkele business service die zeker gebruikt wordt. Het is dus sterk af te raden om bij een SOA implementatie te beginnen met generieke technische services en oplossingen als een ESB of een services registry.

Een ideale toets is jezelf af te vragen wat de benodigde inspan-ning is om het gekozen patroon los te laten of te vervangen (lees: changeability). Als die erg hoog begint te worden, dan is dat een indicatie dat er geen simpele oplossing is gekozen. Hou het simpel betekent dus ook dat je moet blijven vereenvoudi-gen. Dat heeft betrekking op de source code die in eerdere iteraties is opgeleverd. Ga ook grootschalige herstructurering niet uit de weg als dat de code vereenvoudigt en de leesbaar-heid en onderhoudbaarheid ervan vergroot. Schroom bijvoor-beeld niet om een gebruikt patroon weer weg te refactoren als het onnodig blijkt te zijn. Een hoge mate van geautomati-seerde testability (regressietest) is hiervoor een belangrijke randvoorwaarde. Na het refactoren moet je snel en helder bewijs kunnen genereren dat de snelheid, betrouwbaarheid en kwaliteit nog hetzelfde of beter zijn.

In de traditionele manier van architectuur ontwerpen is er een sterke neiging om uitdagingen “weg te abstraheren”. Dit uit zich in het aankopen of het bouwen van raamwerken waarmee dit type problemen wordt aangepakt. Dit heeft weinig met ver-eenvoudiging te maken. De uitdagingen worden omzeild en ge-


negeerd met vaak rampzalige gevolgen later in het traject. Een voorbeeld: “We moeten veel web services uit deze bron ontslu-iten. Met TIBCO, Oracle, IBM ESB en kant-en-klare adapters is dat zo opgelost. Het zijn immers allemaal web services.” Dit is echter te kortzichtig. Het is gedreven door over-simplificering van de uitdaging en niet vereenvoudiging van de oplossing. Het probleem wordt simpeler voorgesteld en opgelost met een grote en complexe externe oplossing. Het moge duidelijk zijn dat dit de veranderbaarheid naar de toekomst niet versterkt.

Agile focust op datgene waarvan we vandaag weten dat het belangrijk is. Het zou echter dom zijn om de ogen volledig te sluiten voor alles wat in de toekomst belangrijk kan worden. Hoewel er ontworpen en gebouwd wordt voor wat nu bekend is, kun je op een eenvoudige manier toekomstige scenario’s opstellen (change cases). Hierbij wordt aangegeven wat de waarschijnlijkheid en de globale impact van een mogelijke toekomstige ontwikkeling is, bijvoorbeeld dat de door het sys-teem geregistreerde gegevens via het internet ontsloten gaan worden. Dergelijke scenario’s kun je gebruiken om te toetsen in welke mate het systeem aan dergelijke scenario’s kan wor-den aangepast. Houd goed in de gaten dat het hierbij te doen is om dit laatste: is het mogelijk? Het opstellen van change cases moet geen poging zijn om de toekomst te regisseren en het systeem daar alvast op in te richten. We baseren het sys-teem vandaag alleen op de kennis van nu.

Kortom:

• Ontwerp met mogelijke verandering in het vooruitzicht en zie verandering als een kans om de kwaliteit van de archi-tectuur te verhogen.

• Zorg ervoor dat changeability en testability hoog gepri-oriteerde kwaliteitseisen zijn; toets het systeem dus ook hierop (bijvoorbeeld via de Definition-of-Done).

• Houd het ontwerp zo simpel mogelijk, voorkom ´over-architecting´. Wees voorzichtig met het ontwerpen van generieke en flexibele constructies en ga verstandig om met design patterns.

• Review de architectuur regelmatig gezamenlijk. Blijf refac-toren en vereenvoudigen en herstructureer indien nodig.

• Gebruik change cases om te toetsen of de architectuur voldoende is voorbereid op mogelijke scenario’s.

5. Wat betekent Agile Architec-tuur voor de rol van de architect en het team?Tot nu toe hebben we vooral gesproken over het wat en hoe van de Agile Architectuur. We hebben het echter nog nauweli-jks gehad over de rol van de architect zelf. Agile werkt vooral met zelfsturende teams. Wat betekent dit voor de architect? Zit die in het team? Wordt deze slechts adviserend aan de teams? Moet de architect een andere baan zoeken? De rol van de architect verandert namelijk wel degelijk. Eén persoon kan maar zelden een slimmere oplossing bedenken en doorvoeren dan een team. Het leven van de architect verandert dus. En grondig.

5.1. Architectuur is van het team

In Agile softwareontwikkeling is het hele team verantwoordeli-jk voor het creëren en onderhouden van de architectuur. De verantwoordelijkheid ligt niet bij een enkele persoon in de rol van architect. Naar gelang een team uit meer of minder ervaren teamleden bestaat kan dit de vraag oproepen of het team er toe in staat is om deze verantwoordelijkheid op zich te nemen. Er bestaat immers het risico dat de meest ervaren persoon de architectuurbeslissingen naar zich toetrekt. Dit kan een nadelige invloed hebben op de toewijding van het team en daarmee ook op de kwaliteit. Een architectuur hoort bij alle teamleden in het hoofd te zitten, meedoen met het ontwerp ervan zorgt daar nu juist voor.

Bovendien vereist het ontwikkelen van architectuur specifieke kennis en vaardigheden die misschien niet allemaal in het team aanwezig zijn. Domeinkennis, weten wie de belangheb-benden en wat hun belangen zijn, weten hoe je de kwaliteit-seisen boven tafel krijgt en het hebben van overzicht over het totaalplaatje van een oplossing en z´n omgeving, zijn hiervan


een paar voorbeelden. De vraag is dan ook: hoe kun je een team uitrusten met de benodigde kennis en vaardigheden en de randvoorwaarden scheppen waaronder zij de juiste archi-tectuurbeslissingen kunnen nemen?

Het antwoord op deze vraag is door bij Agile projecten van enige complexiteit en/of omvang (denk aan meerdere teams) een teamlid of teamleden te hebben met de benodigde speci-fieke architectuurcompetenties zoals domeinmodellering, veel .NET of enterprise java kennis, beveiliging, cloud, enzovoort. “De architect” voor al uw problemen bestaat namelijk niet. Architecten moeten wel in het team staan. Met ‘in het team staan’ wordt bedoeld dat de Agile architect zich actief in het team moet bewegen, oog heeft voor wat er dagelijks binnen het team speelt en weet waar de concrete uitdagingen liggen. Dit kan zijn als fulltime meewerkend teamlid, maar het is ook goed mogelijk dat hij of zij deze rol voor meerdere teams ver-vult.

Het belangrijkste is dat de Agile architect volledig betrokken is bij de concrete bouw van de software. Dit in tegenstelling tot een architect die vanuit een andere locatie met een schuin oog het team in de gaten houdt en alleen af en toe meedenkt of zelfs alleen maar producten reviewt. In onze beschouwing dragen zulke personen niet bij aan het product, dus ook niet aan de architectuur, en zijn dus ook eigenlijk helemaal geen architect. Een architect doet mee!

Kortom:

• Leg de verantwoordelijkheid voor de architectuur bij het team, niet bij één persoon.

• Een Agile architect staat in het team.

5.2. De rol van Agile architect

Uit het voorgaande blijkt al voor een belangrijk deel welke eisen aan de Agile architect gesteld worden. Het moet iemand zijn die zijn of haar kennis en ervaring op het gebied van archi-tectuur ter beschikking stelt aan de teams. Het is iemand die in staat is kennis op zo’n manier over te dragen dat het team in staat is om zelf de juiste beslissingen te nemen. De Agile archi-tect is dus vooral ook een coach die de teamleden kan helpen hun taken zo goed mogelijk uit te voeren.

De Agile architect initieert en faciliteert. Dit kan bijvoorbeeld het organiseren van workshops zijn, waarin gezamenlijk aan-dacht wordt besteed aan architectuurontwerpzaken, zoals domain en user interface modelleren, deployment modeling of het opstellen van kwaliteitseisen. Dit kan ook zijn het ad hoc of gepland bij elkaar roepen van de teamleden in een korte meet-ing om het team snel tot een gezamenlijke oplossing (voor

een specifiek probleem) te laten komen. Het draait feitelijk om de zaken die de traditionele architect gewend was solo op te pakken. Deze worden in een Agile team door het gehele team gedaan.

Het komt natuurlijk voor dat een team nog niet volwassen is in de manier waarop men met elkaar samenwerkt om effectief invulling te geven aan architectuur. Dit probleem dient hoe dan ook op zichzelf te worden opgelost en het is dus geen reden om een architectuurtaak alsnog buiten het team te beleggen.

Eerder hadden we het over een architect die ‘in het team’ staat. Soms wordt ook wel gesproken over een ‘hands-on’ ar-chitect. Betekent dit dan dat de architect moet mee program-meren? Is Agile Architectuur een degradatie van de architect? Wordt deze eigenlijk weer senior developer?

Het antwoord op de deze vragen is: nee, niet perse. Al is het wel zo dat een architect die ook programmeert de code beter kent en zeker oog heeft voor de implementatiedetails en de problemen die soms aan ontwerpkeuzes vastzitten. En daar gaat het om. Elke zichzelf kritisch beschouwende architect moet zich afvragen hoe hij/zij in staat is om optimaal tot de beste architectuur te komen, zonder mee te programmeren. Hoe kun je echt de ins en de outs van het systeem weten, zonder mee te werken?

Het is daarnaast belangrijk dat het team goed op de hoogte is en op de hoogte blijft van een eventueel veranderde bedri-jfsvisie en/of productvisie. De architect zorgt er voor dat het hele team het product en de doelstellingen begrijpt, wie de belanghebbenden en wat de randvoorwaarden en risico’s zijn. Deze zijn van invloed op de te nemen architectuurbeslissingen. Het team kan alleen goede beslissingen nemen als er een geza-menlijke visie op het product is. De teamleden moeten het-zelfde mentale model van het systeem proberen te krijgen. Een eerste stap om tot zo´n gezamenlijk mentaal model te komen is bijvoorbeeld het creëren van een product vision box. Dit is een workshop waarin het team in kleine groepjes de opdracht krijgt om de voor- en achterkant van een blanco kartonnen doos zo te ontwerpen alsof het product in die doos verkocht zal worden. Dit laat de teamleden op een creatieve manier nadenken over wat je met het product kan en waar het toe dient. Elk groepje presenteert na verloop van tijd het resultaat waarna geprobeerd wordt tot een gezamenlijke visie op het product te komen.

De teams zijn vaak druk bezig met het opleveren van function-aliteit. De Agile architect houdt oog op het grotere geheel, de communicatie over teams heen en de stakeholder belangen.

Kortom:

• Zorg voor een Agile architect die goed in staat is ken-nis over te dragen en coachend op te treden.


• Zorg voor een Agile architect die initieert en faciliteert maar die het team zelf met oplossingen laat komen.

• Zorg voor een Agile architect die de code kent en oog heeft voor de implementatiedetails van ontwerp-keuzes.

• Zorg ervoor dat het team een gezamenlijke visie op het product deelt.

5.3. Modelleer, documenteer en communiceer op een Agile manier

Een Agile aanpak waardeert werkende software hoger dan uit-gebreide documentatie. Het uitgangspunt is alleen dat er niet meer gedocumenteerd wordt dan strikt noodzakelijk.

In de meer traditionele werkwijzen wordt architectuur vooraf ontworpen en is er dus een medium nodig om het ontwerp vast te leggen en te communiceren naar belanghebbenden. Het is in een dergelijk paradigma dan ook evident dat architec-tuur gedocumenteerd wordt. Gebruikelijke vormen daarbij zijn tekstuele beschrijvingen van de architectuur aangevuld met grafische representaties van modellen, hetzij in documenten of in een modelleer- (case)tool (views genoemd). Het is te ge-makkelijk om daaruit te concluderen dat de architectuur van een systeem dus bestaat uit de hele verzameling documenten en modellen die er over zijn opgeleverd.

Agile Architectuur leert ons dat de architectuur van een sys-teem voor een groot deel bestaat uit de mentale modellen (in de hoofden van de teamleden) en de code waaruit het systeem is opgebouwd. Die code is namelijk een weerslag van de mentale modellen in de teams. Er wordt bij Agile niet meer dan noodzakelijk gedocumenteerd, dus dat dwingt ook om juist naar de code te kijken als je wilt weten hoe het sys-teem fundamenteel in elkaar zit. Vanuit het view point van het bouwteam representeert niets de architectuur beter dan dat, de architectuur is als het ware de code. Eventuele modellen kunnen dan ook beter achteraf zo nodig uit de code worden gegenereerd dan vooraf te worden vastgelegd met alle risico’s

op inconsistenties.

Om de code die rol van kennisoverdrager te kunnen laten vervullen is het belangrijk dat deze zo duidelijk mogelijk is geschreven (self explanatory code) en zo eenvoudig mogelijk te begrijpen is. Hoe duidelijker de code is geschreven, hoe minder commentaarregels in de code nodig zijn om de code uit te leggen. In commentaarregels schuilt eenzelfde gevaar als in gewone documenten, namelijk dat ze uit sync gaan lopen met de code zelf als die later gewijzigd wordt. Ook hier dus weer een goede reden voor eenvoud. Eenvoud zorgt voor be-grijpelijkheid.

Bovenstaande wil dus niet zeggen dat er verder niet gedocu-menteerd wordt. Over het algemeen kun je zeggen dat alleen gedocumenteerd wordt wat businesswaarde heeft, in die zin dat het ook daadwerkelijk gebruikt wordt. Documentatie moet wel geoptimaliseerd zijn voor doelgerichte en doelmatige communicatie. Dit betekent bijvoorbeeld dat een model niet altijd met toeters en bellen volledig uitgelijnd in Visio hoeft te worden getekend. Waarschijnlijk is de ruwe schets in geza-menlijkheid op het whiteboard tot stand gekomen en begrijpt iedereen dat plaatje ook. Hang de foto aan de muur of plaats deze op een Wiki waar iedereen op elk moment bij kan. Dat is meestal al meer dan voldoende.

Zoals gezegd is documentatie slechts een medium voor ken-nisoverdracht. Het belangrijkste van alles is echter dat de ben-odigde kennis in de hoofden van de teamleden zit. De meest efficiënte manier om dat te bereiken blijft altijd directe interac-tie tussen de teamleden en eventuele andere belanghebben-den onderling. Stelregels daarbij zijn dus:

• Schrijf een zichzelf uitleggende code.

• Documenteer alleen stabiele zaken, geen specu-latieve.

• Documenteer alleen de sleutelaspecten van de ar-chitectuur (domeinmodel, UI-model, deployment model).

• Documenteer ontwerpbeslissingen en gebruikte stan-daarden.

• Modelleer op het whiteboard en neem foto’s.

• Documenteer op een communicatieve wijze dit kan bijvoorbeeld een Wiki zijn, maar kies vooral een mani-er die het team prettig vind.

• Communiceer zoveel mogelijk direct verbaal.


6. ConclusieOp een Agile manier omgaan met systeemontwikkeling heeft de toekomst. Het is ondenkbaar dat werkwijzen overleven die er van uitgaan dat er niets verandert en dat er geen voortschri-jdend inzicht is. Verandering staat zo centraal in ons vak, dat het ondenkbaar is dat werkwijzen gaan overleven die verand-ering proberen te neutraliseren.

Organisaties die in al hun enthousiasme overstappen op een Agile manier van werken krijgen vroeg of laat te maken met vraagstukken rond architectuur. Hoe om te gaan met architec-tuur in een Agile manier van werken is een zeer relevante en legitieme vraag. In deze whitepaper hebben we aangegeven dat het antwoord op deze vraag zit verscholen in het laten ont-staan van de architectuur tijdens het project. Vooraf uitdenken is onmogelijk. ‘Net op tijd en net genoeg architectuur’ is het adagium en laat het team zelf gezamenlijk de architectuur tot stand komen in het project. Houd deze architectuur vooral simpel en aanpasbaar ‘vloeibare architectuur’ vat dit prima sa-men. Bovendien is de rol van de architect en de manier waar-op deze zijn rol invult, een belangrijk deel van het antwoord op de vraag hoe je binnen Agile met architectuur om moet gaan.

We staan in ons vakgebied nog maar aan het begin van deze omslag. Plangedreven aanpakken zullen naar verwacht-ing grootschalig vervangen worden door Agile werkwijzen die in staat zijn veel sneller om te gaan met verandering en voortschrijdend inzicht. Hoe hierin met architectuur om te gaan en hoe de architect daarin het best tot zijn recht komt, zal voorlopig nog wel even ter discussie blijven staan.

Deze whitepaper heeft zich slechts beperkt tot het topje van de ijsberg. Let op, het is wél een ijsberg!


7. Bronvermelding• De Dienende Architect, Viktor Grgic, 22 mei 2010

• Principles for the Agile Architect, Agile Architect, 2010

• Is Design Dead?, Martin Fowler, mei 2004

• Agile Survey 2010, The State of Agile Development, Re-port, Version One, 2010

• Agile Principles, The Agile Manifesto: http://www.agile-manifesto.org/principles.html, 2001

• Lean Architecture – for software development, James O,Coplien & Gertrud Bjørnvig, 2010

8. Over de auteursKees Jan Bender is senior consultant en solution architect bij iSense Prowareness. Hij heeft jarenlange ervaring op het gebied van software ontwikkeling en teamleiding vanuit een architectrol in verschillende aansprekende software projecten. Vanuit zijn rol als architect en als werknemer van een volledig Agile opererende organisatie is Kees Jan zeer betrokken bij de opmars van Agile werkwijzen en de gevolgen daarvan voor zijn vakgebied.

Viktor Grgic is een freelancer, vaak geziene spreker over Agile Architectuur en IT architect die in zijn dagelijks werk Lean en Agile principes hanteert. Viktor heeft in zijn loopbaan als archi-tect vele software projecten geleid en architecten gecoacht. Hij heeft onder andere leiding gegeven aan het architectuurteam van Nieuw Handelsregister bij Kamer van Koophandel en een lead SOA / integratie architect rol vervuld bij ProRail. Viktor is momenteel werkzaam bij Port of Rotterdam (Havenbedrijf) als Agile IT Architect en Coach. Viktor is intensief betrokken bij de Agile Architectuurpropositie van iSense Prowareness.

prof.dr.ir. Rini van Solingen is CTO bij iSense Prowareness en deeltijdhoogleraar Global Software Engineering aan de Tech-nische Universiteit Delft. Rini is auteur van het boek ‘De Kracht van Scrum’, het enige managementboek over Agile software development dat inmiddels in 4 talen is verschenen. Rini is op Twitter te volgen via @solingen maar is ook te bereiken via: [email protected] of [email protected]. Hij kijkt uit naar uw reactie.


Over Prowareness...Prowareness bestaat uit ongeveer 50 enthousiaste profes-sionals verspreid over drie vestigingen in Amerika, India en Nederland. Ons team bestaat uit een sterke combinatie van diverse, ervaren specialisten die beschikken over een dui-delijke (toekomst)visie. Binnen Prowareness hebben wij het Agile-principe hoog in het vaandel staan. Onze teams werken volgens Scrum, zowel binnen als buiten het ontwikkelen van software.

Agile teamssnelle time-to-market te realiseren. Bij Prowareness zijn wij ons hiervan bewust. Waarom langer wachten dan noodza-kelijk? Neem geen risico, maar bekijk de mogelijkheid van werkende software in 30 dagen met Prowareness en Hyper-productive Agile Teams. Door goed te prioriteren kunnen wij de functionaliteit met de meeste businesswaarde het eerst klaar hebben, waardoor uw terugverdientijd aanzienlijk wordt verkort.

Agile coachingDe kans op een volwassen software implementatie wordt groter naarmate ervaringen uit eerdere trajecten meegeno-men worden in het ontwikkelproces. Om deze reden biedt Prowareness diensten aan op het gebied van Agile Coaching. Agile is hierbij geen doel op zich, maar slechts een middel voor snellere en betere software development. Wij willen u verder helpen en gebruiken Agile daarbij als leidraad.

Agile developersWerkt u met Agile en bent u op zoek naar een nieuwe Pro-grammeur? Wij horen vaak dat het moeilijk is om iemand ter (tijdelijke) versterking, uitbreiding of vervanging aan te nemen in een team dat Agile werkt. Prowareness beschikt over een groot netwerk Agile specialisten waarmee wij u continuïteit kunnen bieden. Daarbij hebben wij geen ‘bankzitters’, maar doen wij een specialistische search naar uw nieuwe Agile medewerker.

Agile trainingU kunt zich onder andere laten certificeren tot Scrum Master en Product Owner, maar ook doorleren na het behalen van het Scrum Certificaat tijdens Meesterschap in Scrum. Als enige in Nederland bieden wij meerdere Nederlandstalige Scrum Trainers met Rob van Lanen, Henk Jan Huizer en Jeroen van Menen, welke allen gecertifieerd zijn bij Scrum.ORG. Naast de Scrumrollen bieden wij ook Agile en Architectuur Master-classes en training op het gebied van opdrachtgeverschap en outsourcing. Kijk voor een geheel overzicht op datum ook in onze kalender.

Agile cockpitHet managen van uw Agile team is nog nooit zo gemakkelijk geweest. Agile Cockpit biedt u een uniek en eenvoudig over-zicht welke u kunt aanpassen aan uw eigen wensen. Agile Cockpit is een project management tool gebaseerd op beste practices van Agile Software Development. Alle beno-digdheden voor het werken met een Agile Team vindt u hierin terug. Tevens stimuleert Agile Cockpit de actieve samenwer-king tussen het team, de klant en andere stakeholders. Agile Cockpit is zo gebouwd dat teams ook hun eigen applicaties kunnen toevoegen.

Daarbij beschikt Agile Cockpit over een eigen server waarin u alle project gerelateerde informatie kunt opslaan. Denk hierbij aan de informatie van de verschillende teamleden, de Product Backlog, uw Sprint planning en de Burn Down. Agile Cockpit werkt ook uitstekend samen met Microsoft Team Foundation Server 2012 en de mogelijke Scrum templates. Sterker nog, het combineren van deze progamma’s werkt zelfs nog sneller en makkelijker.

“Wat is de impact van het Agile werken op de ... - scrum… · Bezoekadres Postadres el 15 -...

Documents

Transcript of “Wat is de impact van het Agile werken op de ... - scrum… · Bezoekadres Postadres el 15 -...