Hoe omgaan met architectuur?

Karel is onderweg naar een gesprek met Jochem de architect van het programma en Benjamin. Benjamin is een kennis van Jochem en hij is architect bij een organisatie die vijf jaar ervaring heeft met sneller kunnen leveren.

Wendbaarheid huidige legacy

Ik schud Benjamin de hand, wij pakken koffie en zoeken een ruimte. Iedereen stelt zich aan elkaar voor, daarna stel ik Benjamin de vraag: “Wat zijn jouw ervaringen met releasemanagement van legacy?”. Benjamin legt uit wat zijn ervaringen zijn. In het verleden gingen releases vaak maar één keer per kwartaal naar productie. Daarnaast was het tot stand komen van een nieuwe release een volgordelijke aanpak: eerst analyse, dan bouw, dan test en dan integratietest. Een wendbare applicatie kende men niet, in tegenstelling tot wat je tegenwoordig veel vaker ziet.

Benjamin ziet nog bij verschillende organisaties maatwerksystemen met een variëteit aan coderegels (codelines). “Dat begrijp ik niet helemaal.” zeg ik. Benjamin legt uit dat een codeline een verzameling van functionaliteit is waaruit een werkende applicatie voortkomt. Vaak werkt iedere programmeur op zijn eigen manier aan een stukje functionaliteit. Dit moet ergens gecombineerd worden en dat noem je codelines.

Branchen en mergen

Ik vraag Benjamin wat branchen en mergen is. Benjamin antwoordt dat bij software ontwikkeling verschillende releases in verschillende codelines ondergebracht zijn. Er worden aparte stukjes code geïsoleerd om hele specifieke functionaliteit te bouwen. Hiermee zorg je dat niet de gehele applicatie wordt verstoord als er iets fout gaat. De functionaliteit per codeline loopt vaak uiteen en dan moeten de verschillende codelines worden gebranched, uit elkaar gehaald, en na aanpassing van die code, weer gemerged worden, weer samengevoegd. Het terugzetten van stukjes geïsoleerde functionaliteit in de codeline heet dus mergen.

Als codelines dan, na aanpassingen, weer teveel uit elkaar gaan lopen wat betreft de programmeercode, dan kan dit leiden tot fouten en dat kost veel tijd. Daarnaast draagt veelvuldig branchen en mergen zeker niet bij aan wendbare systemen. Het is nou eenmaal een bewerkelijk proces waarbij de kans op fouten groot is.

Wendbare software

Wendbare software vraagt om een applicatie die zodanig is opgebouwd dat hij flexibel in kan spelen op veranderende omstandigheden. Denk aan verschillende versies van de software. Hierdoor kun je altijd met een versie van de software naar productie en hoef je functionaliteit nooit uit de applicatie te halen om toch naar productie te kunnen.

Het is wel zo dat bij systemen die in het verleden zijn ingericht, het lastig is om ze wendbaar te krijgen. Daarvoor is bovenmatige inspanning nodig of misschien zelfs wel een gewijzigde inrichting of zelfs helemaal opnieuw programmeren van die software. Met de kennis van applicatieontwikkeling en de eisen die er in het verleden aan werden gesteld, was daar niets fout aan en vonden wij dit de normale werkwijze.

Altijd naar productie

Benjamin geeft aan dat hij als uitgangspunt hanteert, dat hij als architect ervoor zorgt dat software maar één weg kent en dat is altijd naar productie en dat dit onafhankelijk van andere versies van de software kan.

Uitgangspunten

Jochem kijkt hem vragend aan en zegt: “Hoe doe jij dat dan precies?” Benjamin gaat verder met zijn verhaal en zegt dat er drie belangrijke uitgangspunten zijn. De eerste heb ik zojuist toegelicht: een codeline. Maar om een codeline te kunnen gebruiken maken wij gebruik van punt twee ‘feature toggles’ en als derde ‘interface versioning’.

Feature toggles

Jochem kijkt verbaasd en vraagt aan Benjamin wat feature toggles zijn. “Dit zijn een soort aan- en uitknoppen in de software. Als je aan het programmeren bent staat de knop uit, dit wil zeggen dat de code waar je op dat moment aan werkt, niet wordt geactiveerd en de functionaliteit is niet zichtbaar. Als je klaar bent met de ontwikkeling kun je de code aanzetten, bijvoorbeeld in een testomgeving om te testen. In productie staat de code nog steeds uit. De code wordt pas aangezet als de business de functionaliteit nodig heeft en alles goed is getest. Gaat er in de tussentijd een versie van de software naar productie, dan bevat die dus wel jouw code maar wordt die nog niet geactiveerd en kan dus ook geen kwaad in de productieomgeving.”

Interface versioning

“Dit wordt gebruikt zodat een software component om kan gaan met verschillende versies binnen de gehele applicatie. Het kan zijn dat jouw component iets verwacht van een ander component, maar deze staat nog niet in productie. Jij wilt hier vanwege het uitgangspunt ‘één weg’ (altijd door naar productie) niet op wachten. Oplossing is dan om te zorgen dat jouw component met de huidige én de nieuwe onderdelen overweg kan. Dan kun je wanneer jij dat wilt naar productie.”

Voordelen

Ik vraag Benjamin: “En wat heeft jullie dit opgeleverd?”. Benjamin antwoordt: “Het heeft ons snellere klanten-feedback, grotere wendbaarheid, een betere codekwaliteit en meer focus op het ontwikkelen van software opgeleverd.”

“Hoe hebben jullie dit geïmplementeerd?”, vraag ik. “Door klein te beginnen hebben we dit gerealiseerd. Zo houd je het overzichtelijk en blijven de eventuele gevolgen beperkt als er toch iets fout gaat.

Wij hebben een architectuur oplossing gekozen waardoor wij gefaseerd over konden gaan, er was dus geen big bang nodig, met alle risico’s die daarbij horen. Het heeft ons wel veel inspanning gekost en in het begin ging er ook echt wel eens wat fout, maar hiervan hebben wij ook veel geleerd. Wij zijn van één release per kwartaal naar een release op aanvraag gegaan.”. “Wauw” zeggen Jochem en ik tegelijkertijd. Wij praten nog wat verder over de details en daarna nemen Jochem en ik afscheid van Benjamin. We spreken met hem af dat hij ons komt ondersteunen. Zo willen wij ook gaan werken en daar kunnen we zijn hulp goed bij gebruiken!

Architectuur

Vijf overwegingen rondom Architectuur:

1. Stel vast wat de uitgangspunten waren bij het ontwikkelen van de legacy software
2. Probeer zoveel mogelijk te werken in één codeline
3. Werk met software die maar één weg kent: naar productie
4. Gebruik feature toggles en interface versioning
5. Maak een weloverwogen keuze bij de transitie van huidige legacy naar een wendbaar systeem en neem hier de tijd voor

Pas je deze tips toe, dan zul je merken dat het wendbaar opleveren van software wordt verbeterd.

Dit is deel 10 uit de serie agile dagboeken van Karel, IT projectmanager en Charmaine, agile transformateur. Wil je de hele serie lezen, start dan hier.

Herken jij je in het verhaal en heb je een vraag? Stel deze aan Charmaine. Zij zal jouw vraag behandelen tijdens een gesprek met een van de medewerkers van WeDoa bij het koffieapparaat. Mail je vraag aan redactie@kwdrm.nl

Wil jij weten of jouw organisatie geschikt is voor agile? Lees dan ons boekje Agile geschikt/ongeschikt. Je kunt ook een test in de KWD-app invullen: is mijn organisatie agile geschikt of ongeschikt? De KWD-app is te vinden in de App-store en Google Play store.