Eonics maakt opdrachtgevers onafhankelijk door ze te helpen met het bouwen van hoge kwaliteit software die tevens toekomstbestendig is. We komen hierbij vaak de volgende situatie tegen: een organisatie moet oude software vervangen maar heeft geen idee waar ze moeten beginnen. In dit artikel legt Eonics CEO Jan Peter Jansen uit hoe dit proces in zijn werk gaat.
De term ‘legacy software’ doet misschien niet bij iedereen een belletje rinkelen. Wanneer we Jan Peter vragen om te omschrijven wat hij hier precies mee bedoelt, wordt het al een stuk duidelijker en herkent iedereen direct het beeld. Jan Peter: “Legacy software is veelal oude maar bedrijfskritische software waaraan aanpassingen doen bijzonder lastig is. Kenmerkend aan dit soort software is een hoge mate van complexiteit en een gebrek aan kennis en documentatie binnen de organisatie. De behoefte om deze software te vervangen door iets nieuws is vaak aanwezig maar in de praktijk is dat niet eenvoudig.”
Hoe het níet werkt
Je zou denken dat je legacy software ‘gewoon’ opnieuw kunt bouwen, maar dan beter en zonder alle problemen. Jan Peter weerspreekt deze veronderstelling: “Het is een veel voorkomende misvatting, de gedachte is dat er in relatief korte tijd een nieuw systeem kan worden gebouwd terwijl de organisatie gewoon doordraait op het oude. Dit werkt in de praktijk eigenlijk bijna nooit. Ten eerste omdat de oude software vaak veel uitgebreider en ingewikkelder is dan wordt aangenomen. Ten tweede blijken er in de tussentijd in de oude software vaak toch wijzigingen nodig te zijn die dan dus in twee systemen moeten worden gebouwd. Een bekend voorbeeld hiervan is het Operatie BRP project van het Ministerie van Binnenlandse Zaken, dat als doel had om de bestaande Basis Registratie Personen te vervangen door een moderne variant. Dit project is na ruim tien jaar, en ongeveer honderd miljoen euro, stopgezet door minister Plasterk.”
Afbeelding: "even" een nieuw systeem bouwen dat het oude vervangt loopt vaak uit in een marathon waarbij de finish nooit in beeld komt
Hoe dan wél?
Als we Jan Peter vragen hoe het dan wél moet aarzelt hij geen moment: “In een vervangingstraject is het belangrijk dat je de nieuwe software in kleine iteraties opbouwt. En het allerbelangrijkst is dat de nieuwe stukken software ook direct in gebruik worden genomen. Daarmee zorg je er namelijk voor dat je niet meer aan oude software hoeft te sleutelen waarmee je dus veel van de continuïteitsrisico’s uitbant. Bovendien kun je dan de nieuwe functionaliteit direct in de nieuwe software bouwen. Vergelijk dit proces met het opnieuw bouwen van een huis. In plaats van, zeer waarschijnlijk zonder goede bouwtekening, een compleet nieuw huis te bouwen en die pas te betreden als die af is, bouw je het nieuwe huis tegen het oude huis aan en neem je ieder nieuw gebouwde deel direct in gebruik. Op de manier kun je ‘de nieuwe keuken’ al heel snel gebruiken. Mochten zich er onverhoopt toch problemen voordoen, ga je even in de oude keuken koken. Tegen de tijd dat de bewoners het oude huis helemaal niet meer gebruiken, weet je zeker dat de migratie voltooid is en dat je alleen de delen van het oude huis hebt vervangen die echt gebruikt werden.”
In de praktijk: oud en nieuw naast elkaar
Dit klinkt allemaal aannemelijk maar hoe werkt het dan precies in de praktijk? Jan Peter: “We beginnen eigenlijk altijd met het neerzetten van het framework van de nieuwe applicatie en iets wat we een ‘routeringsmodule’ noemen. De routeringsmodule weet welke functionaliteit beschikbaar is in de nieuwe software en ‘routeert’ de gebruikers, afhankelijk van de functionaliteit, naar de oude of de nieuwe software. In eerste instantie worden gebruikers dus voor alle functionaliteit naar de oude software gerouteerd maar naarmate de nieuwe software groeit, krijgen ze dus steeds vaker functionaliteit vanuit de nieuwe software voorgeschoteld.
Afbeelding: de routeringsmodule zorgt ervoor dat de gebruikers niks merken van de stapsgewijze veranderingen
Concrete resultaten en continuïteit
Bijkomend voordeel van bovenstaande aanpak is dat je ook direct vanaf de start CI/CD kunt toepassen. Jan Peter: “Eonics werkt eigenlijk altijd conform de zogenaamde DevOps werkwijze. Dit betekent dat we niet alleen het ontwikkelen, maar ook het bouwen, testen en deployen van software zoveel mogelijk automatiseren. Door de inzet van het HyperDev platform en een sterke focus op moderne technieken zijn we in staat om binnen een paar dagen een situatie te creëren waarin iedere software wijziging automatisch en zonder downtime in productie kan worden genomen. Met deze concrete resultaten creëer je vervolgens binnen de organisatie ook draagvlak en een positieve sfeer voor het project. Dit lijkt een bijkomstigheid maar is een niet te onderschatten bijdrage.”
Meer informatie
We hopen dat dit artikel meer inzicht geeft in hoe te denken over het vervangen van oude- voor nieuwe software in jouw organisatie. Zit je nog steeds met vragen of denk je Jan Peter’s adviezen goed te kunnen gebruiken? Kom naar de informatieavond op dinsdag 14 mei of laat je gegevens achter via het onderstaande formulier, dan nemen we zo snel mogelijk contact met je op.
