Waarom zou je legacy-software moderniseren?

De belangrijkste reden om legacy software te vervangen, is dat er iets aan mankeert of ontbreekt. Bij veel legacy-applicaties is dat niet het geval. Als de software technologisch verouderd is, maar verder functioneel aan de eisen voldoet, heeft het vanuit dat perspectief weinig nut om te moderniseren. Legacy software kan ook functioneel verouderen, waardoor die bijvoorbeeld niet meer in staat is om modernere taken te vervullen. Denk bijvoorbeeld aan het voeden van een webshop of analytics-platform. Ook daar zie je dat bedrijven er eerder voor kiezen een moderne randapplicaties tegen de legacy-applicatie aan te bouwen, dan de legacy-applicatie zelf te moderniseren.

En geef ze eens ongelijk. IT-trajecten rond je primaire business-applicatie zijn complex, duur en risicovol, en hebben een directe impact op je bedrijfsvoering. De veiligste optie is dan om genoegen te nemen met de huidige functionaliteit van je legacy-applicatie en het moderniseren ervan voor onbepaalde tijd uit te stellen. Maar wat nu als er een mogelijkheid bestond om de bestaande functionaliteit te behouden en tegelijk technologisch te vernieuwen?

Werkwijzen voor modernisering

Globaal gezien zijn er drie manieren om een legacy-applicatie te moderniseren, elk met hun eigen voor- en nadelen.

1. Conversie van broncode
Om te beginnen kan je proberen de oude programmeertaal te converteren naar een nieuwe programmeertaal. Daarbij stuit je echter al snel op een aantal problemen. Zo zijn de concepten binnen verschillende talen vaak heel anders. Hoe ga je bijvoorbeeld van een procedureel- naar object-georiënteerd model? Of van een RPG-applicatie op een AS/400 naar een 3-tier applicatie? Of van een karaktergeoriënteerde gebruikersinterface naar een mobiele variant?

Gedurende dit conversieproces gaat meestal het gedachtengoed van je oude applicatie verloren. De conversieprogrammatuur doet verder diverse aannames, waardoor het aantal bugs in de nieuwe applicatie enorm kan toenemen. Door de combinatie van deze dingen is de nieuwe programmatuur eveneens lastig te onderhouden.

2. GUI ervoor zetten (wrappen)
Een veel gekozen oplossing is de code te laten voor wat het is, en een moderne gebruikersinterface boven op de legacy-applicatie te ontwikkelen. Daarmee lijkt het probleem aan de voorkant opgelost, maar de keerzijde is dat je bij elke wijziging in je kernproces zowel de legacy- als de front-end-applicatie moet aanpassen. De doorontwikkeling wordt daardoor nog verder geremd.

Deze werkwijze is alleen een optie bij heel stabiele legacy-producten die geen noodzaak hebben om mee te bewegen met hun omgeving. Een blijvend nadeel is wel dat de kernapplicatie nog steeds onderhouden moet worden met de oude programmeertaal. De vraag is of die ontwikkelaars voldoende beschikbaar zijn, en voor hoe lang nog. Uiteindelijk komt er toch een moment dat de ontwikkelaars en daarmee de legacy software met pensioen gaan.

3. Softwaremodel afleiden
Een nieuwe opkomende werkwijze is door een low-code platform voor core-systemen te gebruiken. Met sommige is het mogelijk om een low-code model af te leiden van de legacy-software, waarmee je het cruciale gedachtengoed van je core-applicaties kunt vastleggen. Gedurende dit proces wordt de meeste kernfunctionaliteit van de applicatie vastgelegd, waaronder de datamodellen, GUI-structuren, processen en vertalingen. Eigenlijk alles wat op meta-niveau beschikbaar is. Het afgeleide model is meestal niet volledig, dat verschilt per technologie en applicatie. Maar het mag duidelijk zijn dat je hiermee een flinke jumpstart realiseert van een moderniseringsproject. In de praktijk kun je 20 tot 50 procent van de functionaliteit afleiden, en dat is voor grote applicaties een enorme besparing.

Doorontwikkelen na moderniseren

Bij elke vorm van legacy-modernisering moet je verder kijken dan het initiële project. Je wilt daarna immers ook weer verder ontwikkelen. Dit is het moeilijkst bij conversie, want dan is het originele gedachtengoed van de applicatie niet meer bekend. Bij ‘wrappen’ blijft het probleem dat je elke wijziging twee keer moet doorvoeren, en daarnaast dure ontwikkelaars moet inhuren voor het werken met de verouderde technologie.

Een low-code model biedt daarentegen wel uitstekende mogelijkheden om eenvoudig door te ontwikkelen. Het is zelfs mogelijk om de modellen automatisch te laten verrijken op basis van slimme analyses van de meta-gegevens. Bovendien levert dit voor de verdere ontwikkeling niet alleen snelheid op, maar ook een uniform proces.

Vermijd nieuwe legacy software

Het vervangen van legacy-software wordt gezien als een belangrijk en groeiend probleem voor de toekomst. Eind 2018 wijdde Gartner er nog een hele conferentie aan. Naarmate de tijd vordert, lopen de onderhoudskosten voor legacy-software namelijk steeds hoger op. En uiteindelijk komt er natuurlijk een moment dat de technologie niet langer ondersteund wordt.

Wat een veel groter probleem is, en waar je vrijwel nooit over hoort, is dat veel organisaties vandaag de dag de legacy voor morgen creëren. Het is tegenwoordig namelijk steeds makkelijker om nieuwe software te implementeren, waarvan niemand weet hoe lang die populair blijft en technologisch wordt ondersteund. Dat is inmiddels een soort van geaccepteerd probleem geworden.

De enige manier om het creëren van nieuwe legacy te vermijden, is door je bedrijfsapplicaties te moderniseren met een low-code platform voor core-systemen dat in staat is van technologie te wisselen. Als je met zo’n platform verder ontwikkelt, heb je de garantie dat de software altijd automatisch technologisch vernieuwd kan worden en dat er geen nieuwe legacy meer ontstaat. Ofwel: een definitieve oplossing voor het legacy-probleem.