Gebruik je legacy-applicatie een lange tijd

Van ‘legacy software’ is sprake als de functionaliteit, het gebruiksgemak, de technologie en gebruikte methodieken tot een onacceptabel niveau zijn afgezakt. Denk aan klanten of gebruikers je die niet meer goed kunt bedienen, beveiligingsissues, wijzigingen die traag en tegen hoge kosten doorgevoerd worden of problematische integratie met andere moderne systemen en cloudplatforms. Het is tijd voor vernieuwing!

Drie scenario’s voor vernieuwing

Wanneer een niche te klein is voor standaardsoftware of er aantoonbaar financieel voordeel te behalen is door maatwerk in te zetten, dan kan het zinvol zijn om te (blijven) investeren in maatwerkapplicaties. Er zijn 3 verschillende scenario’s om je legacy-applicatie toekomstbestendig te maken.

1. Moderne portalen

Bij applicatieontwikkeling gaat het merendeel van de ontwikkeltijd naar de business logica-laag en de user interface die hier overheen ligt, ofwel de schermen die de gebruikers van de applicatie zien. Bij een verouderde legacy-applicatie zijn deze vaak ouderwets en niet in lijn met de verwachtingen van een nieuwe generatie gebruikers. Ook de toegang voor verschillende, vooral externe doelgroepen, zoals klanten en business partners, kan nog weleens een belemmering zijn voor een verouderde legacy-applicatie.

Aan de andere kant: na de bestaande applicatie jarenlang te hebben gebruikt, vinden interne ‘power users’ het vaak juist prettig om veel velden en functies op één scherm te hebben, iets wat bij een webapplicatie maar beperkt mogelijk is. Tegelijkertijd is deze laag na jarenlange doorontwikkeling van het bestaande systeem ook het meest kostbaar om te vervangen.

Een populaire aanpak om de levenscyclus van een legacy-applicatie te verlengen, is dan ook het toevoegen van nieuwe schermen via een of meer moderne webportalen die draaien in de browser. Bijkomend voordeel is dat de legacy-applicatie zo kan blijven communiceren met andere legacy-applicaties. Een ‘hybride scenario’ is daarom ook erg populair: het is vaak een win-win, zowel voor de gebruikers als wat betreft de (beperkte) investering die nodig is.

Voor:

• Nieuwe look & feel en betere gebruikservaring
• Met een beperkte investering nieuwe externe doelgroepen bedienen
• Behoud van de integratie met overige legacy-systemen

Tegen:

• Sommige beperkingen van de oude technologie blijven in stand
• Beperkte vernieuwingen in de businesslogica en workflows
• Mogelijk extra licentiekosten vanwege een toenemend aantal technologieën

2. Alles nieuw, behalve de database

In de vorige optie werden nieuwe schermen toegevoegd via een of meerdere portalen. Hierdoor blijft de impact op de legacy-applicatie weliswaar beperkt, maar blijven ook alle bestaande functionele beperkingen in stand. In de tweede optie wordt alles vernieuwd behalve de database. Alle schermen en de volledige businesslogica worden (voor zover de database dat toelaat, denk aan ‘stored procedures’) worden omgezet naar een volwaardige webapplicatie.

De vernieuwingsslag in de businesslogica brengt veel nieuwe mogelijkheden: betere integratie met ketenpartners, een groter aantal gekoppelde apparaten (bijvoorbeeld IoT-integratie) en een goede aansluiting met ontwikkelingen op het vlak van data analytics (zoals machine learning). Het is echter ook een flink kostbaarder scenario: niet alleen het legacy-systeem zelf gaat tenslotte onder het mes, er wordt ook aandachtig gekeken naar de gekoppelde (legacy)systemen. En je zit dan nog steeds met die ‘oude’ database.

Maar er is hoop: de tijd dat databases van Oracle, Progress of IBM veel betrouwbaarder of beter waren dan die van anderen, ligt ver achter ons. Nu de meeste databases ‘volwassen’ zijn en ontwikkelingen elkaar zo snel opvolgen, zullen organisaties zelden voor deze aanpak kiezen en eerder gaan voor scenario 1 of 3.

Voor:

• Automatiseren van nieuwe inzichten over bedrijfsmodellen en -processen
• Extra mogelijkheden van nieuwe technologieën voor de businesslogica en schermen
• Geen datamigratie nodig
• Geschikt wanneer meerdere legacy-applicaties één database delen

Tegen:

• De vernieuwde applicatie is gebonden aan de (on)mogelijkheden van de bestaande database
• Minder voor de hand liggend vanwege het grote huidige aanbod van volwassen database-oplossingen

3. Volledig vernieuwen

Waar de vernieuwingen in scenario 1 en 2 nog beperkt blijven, gaan in scenario 3 de remmen helemaal los. Bij volledige vernieuwing worden namelijk álle lagen van de applicatie vervangen. Niet alles hoeft overigens per se 100 procent nieuw te zijn in de vernieuwde applicatie. Die moet tenslotte nog steeds passen binnen het bestaande landschap.

In scenario 3 zijn er geen technologische beperkingen meer en kan de volle aandacht naar het toekomstklaar maken van de nieuwe applicatie, zowel vanuit business-oogpunt als technisch. Het is de uitgelezen mogelijkheid om de toekomstvisie van je organisatie in de applicatie te verwerken, zodat deze ook over vijf jaar nog steeds past bij de bedrijfsstrategie.

Naast vrijheid bij de inrichting van de applicatie geeft scenario 3 ook alle ruimte om de wijze van ontwikkelen, testen, uitrollen, monitoren en hosten onder de loep te nemen. Recentere concepten zoals Agile Scrum, geautomatiseerd testen, het continu integreren & uitrollen van nieuwe versies, en het scripten van hosting-omgevingen, sluiten veel beter aan bij een snel veranderende omgeving dan de traditionele methoden en technieken.

Voor:

• The sky is the limit
• Hét moment om businessmodellen en bedrijfsprocessen opnieuw te ontwerpen
• Volledig nieuwe technology stack

Tegen:

• Het meest kostbare scenario
• Risico van ‘oude wijn in nieuwe zakken’ tenzij de business echt vooruit durft te kijken
• Vereist nieuwe teamsamenstelling om het maximale uit de investering te halen.

Welk scenario je kiest, hangt af van de wensen in de organisatie. Die kent tenslotte als geen ander de behoeftes van de klant, de eigen sterke punten en de zwaktes van de concurrentie. Welke optie in jouw geval ook de beste is: met het juiste scenario heb je zeker weten nog jarenlang plezier van je vernieuwde legacy-applicatie.