Legacy-software moderniseren: 7 methodes

Over de verschillen én hoe het anders kan

Hoe langer je legacy-software blijft onderhouden, hoe hoger de kosten om je systemen te moderniseren. Volgens onderzoeksbureau Gartner moeten bedrijven die voortdurend bezig zijn met het actualiseren van legacy-systemen erop rekenen dat modernisering ze uiteindelijk 3 keer zoveel gaat kosten als beraamd. Hoe effectief ze dit kunnen doen, hangt van de gekozen aanpak af.

Er zijn 7 traditionele methodes voor het moderniseren van legacy-systemen. Ze verschillen niet alleen qua complexiteit en grootte van de investering (tijd en geld), maar ook op het gebied van zakelijke impact.

#1. Encapsulation

Dit is een techniek om legacy-softwarecomponenten te hergebruiken. Hierbij behoud je de originele code in de oorspronkelijk programmeertaal en omgeving en verbind je deze met een nieuwe presentatielaag, inclusief API’s. Je kunt zeggen dat je de legacy-software niet echt moderniseert, maar alleen van een moderne schil voorziet.

Deze methode is met name geschikt in situaties waarin het legacy-systeem van grote waarde is voor de bedrijfsvoering en de code van goede kwaliteit is. Een voordeel is dat het snel resultaat oplevert. De legacy zelf en de bijbehorende problemen pak je hiermee niet aan. Die problemen worden zelfs groter als er aanpassingen moeten worden gedaan in de processen of functionaliteit. Deze moeten nu op meer plekken worden doorgevoerd dan voorheen.

#2. Rehosting

Bij rehosting migreer je het legacy-systeem (bijvoorbeeld een mainframe-applicatie) zonder aanpassingen naar een andere omgeving. Dit kan zowel een fysieke, een virtuele als een cloud-infrastructuur zijn. Vaak is dit de goedkoopste optie met de minste risico’s, omdat je niks verandert aan het oorspronkelijke systeem. Hierdoor zijn er op de korte termijn geen grote negatieve gevolgen voor de bedrijfsvoering.

Dat ‘niks wijzigen’ is meteen ook het belangrijkste nadeel van deze methode: je verplaatst je systeem alleen maar naar een nieuwe omgeving. Het betekent dat je veel tijd en geld investeert in een project waar de organisatie uiteindelijk weinig mee opschiet.

#3. Replatforming

Bij deze methode vindt er eerst een aantal software-updates en kleine code-aanpassingen aan de legacy-applicatie plaats, voordat deze naar een nieuwe cloud-omgeving wordt verplaatst. Zo voeg je nieuwe mogelijkheden toe aan de oorspronkelijke functionaliteit - denk bijvoorbeeld aan het gebruik van een managed database of auto-scaling. Op deze manier kan een legacy-applicatie met minimale aanpassingen toch van nieuwe technieken profiteren. Dit maakt het een goede oplossing voor applicaties waarbij beperkte modernisering voldoende is. Op het gebied van flexibiliteit of gebruiksgemak verandert er echter helemaal niets.

#4. Refactoring

Refactoring betekent dat de bestaande code van een applicatie (of een component daarvan) opnieuw gestructureerd en geoptimaliseerd wordt, terwijl het externe gedrag ongewijzigd blijft. Op deze manier kun je technische problemen in een applicatie oplossen of de applicatie uitbreiden met nieuwe functionaliteit. Je kunt het systeem hiermee groter maken, maar niet naar een nieuwe technologie migreren. Technologisch gezien blijft het een legacy-applicatie.

#5. Re-architecting

Leiden methode 1 tot en met 4 niet tot het gewenste resultaat, dan is re-architecting een mogelijkheid. Je past dan zowel de applicatiearchitectuur als de code aan om de mogelijkheden van het nieuwe, modernere (cloud-) platform volledig te kunnen benutten.

#6. Rebuilding

Als geen van de eerdere methodes werkt, kun je ook de applicatie helemaal opnieuw bouwen met de ‘oude’ specificaties en de ‘oude’ technologie. Het belangrijkste voordeel: de oorspronkelijke code wordt geherstructureerd en opgeschoond, wat mogelijk resulteert in een efficiëntere applicatie met minder bugs.

#7. Replacing

Soms is de applicatie helemaal vervangen door een nieuwe tool de meest efficiënte en snelste manier om je legacy te moderniseren. Je vermijdt zo de hoge kosten van modernisering, maar je kunt niet de bestaande business-logica behouden. Je zult dus moeten investeren in het herschrijven van de business-logica en het aanpassen en configureren van de nieuwe software.

Software gaat steeds korter mee

Of je nu kiest voor een volledige (her)implementatie van een modern softwarepakket of zelf een maatwerk-applicatie laat ontwikkelen, het is slechts een tijdelijke oplossing. Software veroudert steeds sneller en gaat steeds korter mee. Met elke nieuwe implementatie creëer je de legacy van de (nabije) toekomst.

Het kan anders met low-code

Door de snelle ontwikkeling van de low-code softwaremarkt komt daar gelukkig verandering in. Low-code was tot voor kort meestal alleen een aanvulling op het bestaande applicatielandschap en werd vooral gebruikt om nieuwe functionaliteiten en web-dashboards te ontwikkelen. Maar inmiddels bestaan er ook enterprise low-code platforms die organisaties in staat stellen al hun business software permanent te moderniseren, van de front-end applicaties tot de volledige core legacy-infrastructuur.

Met een enterprise low-code platform blijven alle functionaliteiten, datastructuren en applicatieschermen flexibel aanpasbaar. En creëer je dus nooit meer nieuwe legacy. Hoe dat kan en hoe het werkt lees je in het e-book Nooit meer legacy software met enterprise low-code.