Voor je start met het ontwikkelen van een nieuw systeem, denk je na over het eindproduct. Over het einddoel. En ook over de manier waarop je daar gaat komen. Welke technieken ga je gebruiken, welke functionaliteiten moeten er gebouwd worden en waarom? Daar komt architectuur om de hoek kijken.
Waar we voorheen in het begin heel hard nadachten over wat we gingen bouwen en een zogenaamd ‘big design up front’ maakten, werken we tegenwoordig wel wat anders. Emergent design betekent geen enorm document aan het begin, maar een technisch ontwerp dat ontstaat tijdens het ontwikkelen. Een ontwerp dat meegroeit met veranderende wensen en behoeften. En daar kan ook jouw project van profiteren.
Traditioneel en een tikkie achterhaald
Vroeger, in de tijd van big design up front, maakte een aantal architecten vooraf een compleet dichtgetimmerd en hoog-niveau technisch-document waarin ze verantwoordelijkheden, technologieën en integratiepunten vastlegden. Ook de te bouwen componenten en de koppelingen tussen al die te ontwikkelen bouwblokken werden vastomlijnd beschreven.
Deze methode was jarenlang razend populair, vooral omdat het ‘t projectteam én de klant een gevoel van voorspelbaarheid en controle gaf.
Zo’n starttraject duurde alleen ontzettend lang en was dus een behoorlijke investering. Om er dan steevast – tijdens het ontwikkelen – achter te komen dat bepaalde zaken technisch helemaal niet mogelijk waren. Het kostte vervolgens veel tijd om de architect daarvan te overtuigen; die moest weer een nieuw technisch ontwerp realiseren en je was zo weer een paar weken verder. Als dat niet duur en oncontroleerbaar is!
Als opdrachtgever ontdekte je vaak pas als je (delen van) een systeem zag, of het ook écht aan je wensen voldeed. Of dat je misschien nog wel andere functionele wensen had, waar je simpelweg nog niet aan gedacht had. Bovendien konden je wensen gedurende een ontwikkeltraject ook veranderen, je organisatie stond immers ook niet stil. Dus tenzij je bij Nasa werkte en Space Shuttles bouwde, was er een nieuwe manier van projectaanpak en ontwikkelen nodig.
Architectuur die organisch groeit
Bij emergent design staat er niet zoveel vast in het begin en ontstaat de architectuur gedurende het ontwikkelproces. Soms denken mensen dat je bij emergent design ‘gewoon maar doet en wel ziet waar het schip strandt’. Dat is absoluut niet het geval! Dat het ontwerp organisch groeit en meebeweegt, betekent niet dat je helemaal niets van te voren vastlegt.
Wat je namelijk wel van tevoren oplevert, is een zogenaamde referentiearchitectuur. Meestal een Powerpoint-presentatie en een klein begeleidend document, vaak in de vorm van een Wiki. In zo’n referentie-architectuur neem je op een vrij abstract niveau requirements op, noem je de belangrijkste eisen op het gebied van performance, integratie en technologie. Ook bespreek je de coding standards, naamgevingsconventies, eisen voor de lay-out en zaken als de releasestrategie en versiebeheerrichtlijnen. Maar alles wat je in het begin opschrijft, ligt niet vast. Het vormt – samen met een lijst van functionele requirements – een startpunt. Het is een ‘levend’ document dat meebeweegt op de golven van het ontwikkeltraject.
Je kunt emergent design niet los zien van de manier van werken. Het hoort bij een Agile-ontwikkelstijl: methodes als Kanban en Scrum dus. Ontwikkelteams werken naast elkaar aan functionaliteiten, waarbij je bepaalde functionele requirements met kleinere ontwikkelteams of in kleinere werkpakketten oppakt. Mocht je tijdens het ontwikkelen ontdekken dat de referentiearchitectuur niet meer voldoet, dan pas je die aan.
Het gevolg is dat je flexibel bent en dat je systeem organisch groeit. Omdat je in een Agile-ontwikkeltraject te maken hebt met een voortdurende feedbackloop, bouw je een systeem dat straks écht doet wat je wil. Het ontwikkelteam, andere teams en de product owner en stakeholders bij de klant kijken elke keer weer of een opgeleverde functionaliteit wel aan de wensen voldoet. Is dat niet het geval? Dan kan er supersnel worden geschakeld.
Uit onderzoek blijkt bovendien dat gemiddeld 60 procent van de gebouwde functionaliteiten niet of nauwelijks worden gebruikt. Als je van te voren precies vastlegt wat je gaat bouwen, spendeer je dus altijd veel kostbare tijd en budget aan functionaliteiten die niemand gebruikt. Zonde! Als je Agile-ontwikkelt, begin je met de quick wins, de functionaliteiten waar je gebruikers het meest aan zullen hebben en die de meeste risico’s wegnemen.
Hoe slaagt een Emergent design-project?
Wat is er nodig om emergent design en een bijbehorend Agile-traject tot een succes te maken? Ten eerste heb je een goede referentiearchitectuur nodig. Hoewel bij emergent design elke ontwikkelaar zo nu en dan de ‘pet’ van architect opzet, is een communicatieve, empathische en geduldige lead architect geen overbodige luxe. Of, afhankelijk van de rolverdeling binnen de organisatie, een goede lead developer. Die bewaakt het hele proces en stuurt bij waar nodig.
Vertrouwen
Ook onmisbaar is vertrouwen. Vertrouwen tussen de architect en developers. En tussen de developers en de ontwikkelteams onderling. Maar ook vertrouwen vanuit de klant, dat er uiteindelijk écht een fantastisch systeem komt dat aan de wensen en eisen voldoet, zonder dat de kosten de spuigaten uitlopen. Ook al is dat in het begin nog moeilijk voor te stellen.
Reversability & complexiteit
Bij emergent design is het belangrijk dat je het systeem zo eenvoudig mogelijk houdt. Ontwikkelaars hebben de neiging om voor iedere onzekerheid en mogelijke toekomstige implementatiemethode, code te abstraheren. Een voorbeeld; stel je moet voor elke gebruiker informatie opslaan. De requirement is dat het met een cookie moet gebeuren. Maar misschien moet het in de toekomst wel in een database. Een ontwikkelaar bedenkt dan het liefst een oplossing voor beide implementatiemethodes. Dat is intellectueel uitdagend en leuk om te doen, maar kost meer tijd en geld en maakt het systeem onnodig complex.
Het is essentieel om alleen te bouwen wat je nodig hebt en je continu af te vragen; ‘stel, we kiezen voor een simpele oplossing die geen rekening houdt met de toekomst. Hoe duur en hoe pijnlijk is het om het later nog te moeten bouwen?’ Maar ook: ‘hoe groot is de kans dat die extra implementatiemethode straks nodig is?’ Dit noemen we reversability. Is het niet pijnlijk, dan hou je je aan de KISS (Keep It Simple Stupid) en YAGNI (You Aren’t Gonna Need It) principes. Zo hou je de flow in je traject en besteed je alleen kostbare tijd aan wat je daadwerkelijk nodig hebt.
Communicatie
Het allerbelangrijkste zijn communicatie en documentatie. Het is goed om je te realiseren dat iedereen anders communiceert en op een andere manier informatie tot zich neemt. De één leest graag (mee), de ander stelt het liefst vragen en gaat actief een gesprek aan. Aan al die communicatie- en informatiebehoeften moet je voldoen als je wil dat het systeem organisch groeit. Communicatietools kunnen daarbij een belangrijke rol spelen. En dan heb ik het niet over e-mail, daar moet je echt zo min mogelijk gebruik van maken. E-mail is niet open genoeg omdat niet iedereen kan meelezen en discussies vaak langs elkaar heen lopen.
Communicatie- en documentatietools
Binnen Aviva Solutions werken we met allerlei communicatie- en documentatiemethodes. Stel, er moet iets veranderd worden aan de referentiearchitectuur, dan passen we de Powerpoint-presentatie en Wiki aan. Daarvan krijgen mensen een notificatie. Zo’n Wiki-functionaliteit zit bijvoorbeeld in GitHub, Sharepoint, en ook in Confluence van Atlassian. Daarnaast loggen we iedere wijziging in een intern blog of log design.
Een discussieplatform als Slack of Flowdock is ideaal om snel vragen te stellen aan de juiste persoon met de juiste kennis. Omdat deze platforms open zijn, kan de rest meelezen. Ook dat bevordert open informatiedeling en communicatie.
Zeker als je werkt met Github of een ander Git-platform (zoals Bitbucket of Visual Studio Team Services) heb je te maken met een code review process. Ook dat is een vorm van communicatie. Als een team een aanpassing wil maken in de broncode, gebeurt dat niet direct in de code, maar met een zogenaamde pull request. Diverse ‘sub system owners’ die ieder hun eigen specialisme hebben (denk aan front-end, Java, browsers, database performance) krijgen een request om de nieuwe code te reviewen.
Al die digitale communicatietools zijn natuurlijk erg prettig en voor een bepaald type ontwikkelaars echt dé manier om te communiceren (denk vooral aan de meer introverte en stille types). Soms is het erg fijn om elkaar even face to face te zien. Regelmatig las ik daarom ook tech meetups in. We bespreken dan veelgemaakte fouten, leggen veranderende richtlijnen goed uit en zorgen dat bepaalde onderwerpen weer even top of mind zijn.
Moderne manier van ontwerpen
Werk je Agile en met emergent design, dan trek je de juiste mensen aan. Ook intelligente ontwikkelaars werken namelijk veel liever Agile dan volgens traditionele methodes. Het proces is daarnaast transparant, flexibel en dynamisch. Geen gevalletjes van ‘dat heb ik niet gedaan, dat was mijn voorganger’. Geen over-de-muur-gegooi. Maar wel efficiënt, effectief en kostenbesparend werken.
Ja, je weet inderdaad niet van tevoren wat je precies gaat bouwen en krijgen. En die onzekerheid kan best spannend zijn. Maar je weet wel veel zekerder dat het systeem straks helemaal naar wens zal zijn, zonder het budget en de planning in gevaar te brengen.
