Incrementele doorontwikkeling versus herbouw van systemen

Het klinkt zo verleidelijk: met een schone lei beginnen. Al het geleerde toepassen op een volledig nieuw te bouwen oplossing. Geen compromissen vanwege bestaande klanten, en het perfecte systeem met de nieuwste frameworks opzetten. Wij zijn er echter van overtuigd dat herbouw van een systeem juist níet de manier is om klanten een duurzame oplossing te bieden. Stef Roskam, VP Engineering bij Otherside at Work, vertelt over onze visie op deze strategische keuze

“Het is een bewuste beslissing om in te zetten op incrementele doorontwikkeling van de Xpert Suite. En niet klanten na een paar jaar bouwen een nieuwe ‘versie 2’ aan te bieden. Onze klanten waarderen dat ook, omdat dit een positieve invloed heeft op de continuïteit van onze dienstverlening en de manier waarop nieuwe functionaliteiten beschikbaar worden gemaakt.”

In dit blog leggen we uit waarom wij kiezen voor incrementele doorontwikkeling en wat dit betekent voor onze klanten.

Wat is het verschil tussen herbouw en incrementele doorontwikkeling?

Laten we eerst verduidelijken wat we bedoelen met herbouw en incrementele doorontwikkeling. Stef legt uit: “Herbouw houdt in dat een systeem volledig opnieuw wordt opgebouwd, waarbij het oude en nieuwe systeem compleet los van elkaar staan. Dit betekent dat er een harde overgang is tussen het oude en nieuwe systeem voor de klant, vaak met een nieuwe implementatie, migratie en uitgebreide gebruikerstrainingen.

Incrementele doorontwikkeling is gericht op het geleidelijk herbouwen of refactoren van bestaande code. Dit betekent dat we stapsgewijs verouderde onderdelen herschrijven of verbeteren om het systeem up-to-date te houden. Het belangrijkste verschil is dat er geen grote, plotselinge overgang is, maar dat veranderingen geleidelijk worden doorgevoerd.”

 Waarom Otherside at Work niet voor herbouw kiest

Voor ons is herbouw geen goede oplossing, Stef geeft hiervoor verschillende redenen:

• “De omvang van de codebase: Het succes van een herbouwtraject hangt sterk af van de omvang van de codebase. Een codebase van tien manjaar is aanzienlijk eenvoudiger te herbouwen dan een codebase van tweehonderd manjaar.
• Hoge kosten en klantverlies: Als je kiest voor herbouw moet je twee systemen onderhouden: het oude systeem en het nieuwe systeem. Daar zijn meer mensen voor nodig, en dat is dus simpelweg duurder. Ook moeten klanten op den duur overstappen. Bij een platform als Xpert Suite vraagt dat veel begeleidingstijd. Er zijn daardoor altijd klanten die de overstap niet willen of kunnen maken. In de praktijk zie je daarom dat er klanten afhaken tijdens een herbouwtraject.
• Code freeze: Bij een volledige herbouw moet de ontwikkeling van nieuwe functionaliteiten vaak worden stopgezet voor het oude systeem, omdat alle aandacht en middelen naar de herbouw gaan. Dit betekent dat er een “code freeze” plaatsvindt, waardoor klanten lange tijd geen nieuwe functionaliteit ontvangen. In een markt waar continu nieuwe ontwikkelingen plaatsvinden, zoals wet- en regelgeving en AI-oplossingen, kan dit betekenen dat klanten achteropraken. Met incrementele doorontwikkeling kun je wel direct nieuwe ontwikkelingen beschikbaar stellen binnen je bestaande oplossing.
• Nieuwe code is niet altijd direct beter: Code die bijvoorbeeld 10 jaar bestaat is “battle hardened”. De code is beproefd op veel edge cases en deze zijn door bug fixes afgehandeld. Ook is de code vaak geoptimaliseerd om met de gewenste load om te kunnen gaan. Je wil deze eigenschappen meenemen in je nieuwe code, maar ze zijn niet altijd makkelijk te doorgronden. Hierdoor is de kans groot dat je goed werk ‘weggooit’ en fouten maakt in de nieuwe code die in de bestaande code al waren opgelost.” 

Voordelen van incrementele doorontwikkeling

Otherside at Work kiest voor incrementele doorontwikkeling, omdat deze strategie een aantal belangrijke voordelen biedt. Stef licht toe:

• “Kleinere risico's bij verandering: Bij incrementele doorontwikkeling worden nieuwe onderdelen stap voor stap in gebruik genomen, waardoor eventuele problemen direct zichtbaar worden en snel kunnen worden opgelost. Soms missen we edge cases waar onvoldoende kennis van is en oudere code is soms niet goed te lezen. Maar door de incrementele manier van werken zijn die risico’s wel kleiner dan bij een big bang.
• Geleidelijke verbetering voor de klant: Door incrementeel te ontwikkelen, worden veranderingen geleidelijk doorgevoerd, wat betekent dat klanten makkelijker kunnen wennen aan nieuwe functionaliteiten. Bij kleine veranderingen delen we release notes. Bij grote veranderingen kunnen we ervoor kiezen om de verandering geleidelijk door te voeren door eerst een deel van de gebruikers te laten testen. Als er geen problemen voordoen of als deze zijn opgelost, kan iedereen over. Dat maakt het gewenningsproces veel minder ingrijpend.”

Uitdagingen van incrementele doorontwikkeling

Hoewel incrementele doorontwikkeling veel voordelen biedt, zijn er ook enkele uitdagingen. Allereerst is het belangrijk dat de software modulair is opgezet. De technische componenten moeten los van elkaar te vervangen zijn. Hierbij is één van de grootste uitdagingen de integratie van oude en nieuwe onderdelen.

Ook moet je tijdens incrementele doorontwikkeling rekening houden met bestaande gebruiksvormen van je applicatie en wat gebruikers fijn of niet fijn vinden. Dit kan een uitdaging lijken, maar is eigenlijk een “blessing in disguise”. “Het dwingt je om al vroeg in het proces rekening te houden met de praktische toepassing van je oplossing, iets wat bij een volledige herbouw pas duidelijk wordt zodra de eerste gebruikers ermee aan de slag gaan. De grote uitdaging is dus de juiste balans vinden tussen rekening houden met de beperkingen uit de praktijk, en je gebruikers durven te sturen naar verandering.”

Tot slot vereist incrementele doorontwikkeling discipline en consistentie om ervoor te zorgen dat de softwarekwaliteit geleidelijk verbetert. Stef vertelt: “Uiteindelijk ontkom je er niet aan om alles te vernieuwen. Softwareontwikkeling van 20 jaar geleden is immers niet te vergelijken met nu en gebruikte frameworks en platforms waar je op draait worden end-of-life verklaard. Soms kiezen we voor het alleen refactoren van een bestaande module. Dit doen we als de bestaande code dicht genoeg bij onze target architectuur ligt. Als de kwaliteit van de code onvoldoende is of te ver van de bedachte architectuur ligt, dan moeten we deze herschrijven. Uiteindelijk zullen we op deze manier alles vernieuwen, maar dat gebeurt stapsgewijs.” 

De toekomst van Xpert Suite

Xpert Suite is volop in ontwikkeling. Stef vertelt over de toekomst: “We krijgen steeds meer op zichzelf staande domain services. Een domain service bevat de werking van een volledig afgebakend functioneel domein, van backend tot frontend. Hierdoor worden de verschillende onderdelen functioneel en technisch kleiner en is de software onafhankelijk van elkaar beheersbaar. Dit betekent dat we sneller en eenvoudiger upgrades kunnen uitvoeren, zonder dat dit invloed heeft op de rest van het systeem. Hierdoor blijft de snelheid van ontwikkeling hoog en kunnen we ons pakket voortdurend onderhouden en uitbouwen.”

Conclusie: waar organisaties op moeten letten bij hun softwareleverancier

Dankzij de keuze voor incrementele doorontwikkeling hebben we klanten die al 15 jaar dezelfde software kunnen gebruiken, zonder grote migraties en al het werk wat hierbij komt kijken. Tegelijkertijd kunnen ze toch gebruikmaken van nieuwe AI-modules en software die volledig up-to-date is en gebruikmaakt van de nieuwste frameworks.

Stef adviseert organisaties om goed te kijken naar de reputatie en aanpak van een softwareleverancier, vooral als software het primaire proces van hun bedrijf ondersteunt. “Het is belangrijk om zeker te weten dat je leverancier op lange termijn in staat is om de software te vernieuwen en onderhouden. Te vaak zien we dat bedrijven een keuze maken op basis van de huidige functionaliteit en prijs, zonder aandacht te besteden aan de lange termijn”, zegt Stef. “De vraag ‘Zien we deze leverancier over vijf jaar nog steeds goed presteren?’ wordt niet altijd gesteld. En dan kan goedkoop duurkoop zijn, omdat er een groot migratieproject nodig is.”

Wat zouden organisaties dan moeten vragen aan een leverancier? “Het belangrijkste is om te vragen hoe het life cycle management van de software is geregeld. En natuurlijk ook naar het bewezen track-record op dat vlak. Als een leverancier al eerder voor herbouw heeft gekozen, dan is het belangrijk om daar verder op door te vragen”, stelt Stef.

Contact

De Xpert Suite is een innovatief, datagedreven portal voor bedrijfsgezondheid en sociale zekerheid. Het portal is voor medewerkers, leidinggevenden, HR-professionals, bedrijfsartsen, volmachten en verzekeraars. Iedere gebruiker krijgt een eigen toegang die volledig is ingericht op zijn specifieke behoeften.

Meer weten over de Xpert Suite? Neem contact met ons op.