4 Strategieën voor het vervangen van enterprise RPG-applicaties

Daarnaast zijn RPG-applicaties niet geschikt voor mobiele apparaten en moeilijk toe te passen in moderne technologieën, zoals PAAS, SAAS en DAAS. En dat is ook niet vreemd: deze technologieën bestonden nog niet toen RPG opkwam. Een ander probleem is dat RPG-ontwikkelaars schaars worden. Jonge ontwikkelaars leren deze taal niet op school en voelen zich er niet tot aangetrokken. Ze zijn meer geïnteresseerd in C#, Java, Angular of React. De groep RPG-ontwikkelaars wordt dus gemiddeld kleiner en ouder.

Om deze redenen willen veel bedrijven hun RPG-applicaties vervangen door nieuwe. Maar dit lijkt veel gemakkelijker gezegd dan gedaan. Het vervangen van een grote applicatie die al decennia goed werkte, beangstigt bedrijven enorm en daarom wordt dit vaak uitgesteld. Bedrijven zijn bang dat een vervangingsproject hun bedrijf in gevaar kan brengen. Zal de nieuwe applicatie net zo goed zijn als de oude? Wat gaat het effect zijn op onze time-to-market? Maar ook qua organisatie zijn er grote vraagtekens. Is het bedrijf in staat om zo'n groot project succesvol af te handelen? Is er voldoende draagvlak in het bedrijf om de applicatie te vervangen?

En dan is er nog de vraag: wat is de juiste richting voor het bedrijf qua technologie? Er zijn gigantisch veel keuzemogelijkheden. Denk aan termen als: mobiel, cloud, low-code, online, offline, on premise, SAAS, PAAS, DAAS, microdiensten, security, enzovoort.

Besluitvorming en technologie

Hoe weet je wat de goede richting is en is er wel een goede richting? Het gevolg hiervan is dat de vervanging keer op keer wordt uitgesteld. Er zijn veel voorbeelden waarbij dit proces meer dan 15(!) jaar duurt. In zo'n lange tijd veranderen technologieën steeds sneller en de te nemen beslissingen veranderen veel en worden daardoor nog moeilijker. Maar wat is de uitweg uit deze vicieuze cirkel? Hoewel veel technologieën de neiging hebben om een ​​oplossing te bieden voor een deel van de technologische vraagstukken, nemen ze bedrijven niet echt bij de hand bij het vervangen van hun huidige applicatie.

Maar moet technologie zo belangrijk zijn voor bedrijven? Het antwoord is simpel: nee, natuurlijk niet. Bedrijven hebben functionaliteit nodig om hun bedrijf te runnen. Het enige doel van technologie is om de functionaliteit te ondersteunen. En het volgende is zeker: zowel technologie als functionaliteit zullen in de nabije toekomst moeten worden aangepast. In welke richting deze veranderingen zullen plaatsvinden, is moeilijk te voorspellen.

Hoewel nieuwe technologieën veel nieuwe mogelijkheden bieden, hebben ze nog steeds één probleem: veranderingen in technologie vragen om veranderingen in of heropbouw van functionaliteit. En dat maakt de keuze van technologie zo belangrijk, terwijl dat niet zo zou moeten zijn. Wanneer bedrijven met RPG-applicaties alleen functionele en methodologische keuzes hoefden te maken voor hun nieuwe oplossing, dan hadden de meeste bedrijven hun huidige applicatie al wel vervangen.

Scheiding van functionaliteit en technologie

De beste low-code ontwikkelplatformen zijn in staat om ook het technologieprobleem op te lossen, omdat technologie en functionaliteit heel natuurlijk worden opgesplitst. Bij een softwarebouwproces zorgt het projectteam voor het definiëren van functionaliteit in modellen, terwijl de leverancier van het platform ervoor zorgt dat de technologie die de modellen interpreteert altijd up-to-date is met de nieuwste technologische ontwikkelingen.

Het gevolg is dat technologiekeuzes voor bedrijven veel minder belangrijk worden. Zij kunnen zich concentreren op business functionaliteit, precies zoals het hoort.

Strategieën voor het vervangen van RPG-applicaties

Het vervangen van een kernapplicatie die het bedrijf decennia lang goed heeft gediend, heeft een grote impact op de organisatie. Het is tijdrovend, het is een risico en de organisatie heeft het waarschijnlijk nog nooit eerder gedaan. Dus hoe kunnen organisaties dit doen? Wat is de strategie?

Er zijn vier verschillende strategieën voor bedrijven met een kernsysteem dat is gebouwd met RPG:

1. gefaseerde opbouw van nieuwe modules, de kern blijft gelijk
2. volledig opnieuw opbouwen
3. gefaseerde vervanging van modules
4. volledige een-op-een upcycle

Gefaseerde opbouw van nieuwe modules, kern blijft hetzelfde In dit scenario wordt de RPG-applicatie niet verwijderd. Alleen de modules die vervangen moeten worden, worden met het platform gebouwd. Dit kan worden gedaan door een gedeeltelijke upcycle of herbouw van de module. Het is ook mogelijk om een nieuwe module aan te maken, die niet bestaat in de RPG-applicatie. Voordelen: • Er worden alleen modules gebouwd die functionele of technische vervanging behoeven. Nadelen: • Functionele legacy van het kernsysteem bijft bestaan, • Veel interfaces met het kernsysteem moeten worden gebouwd en onderhouden. Wanneer te gebruiken: • Wanneer slechts delen van de applicatie gemoderniseerd moeten worden, • Als de kern een lage functionele legacy heeft, • Als de technische legacy van de kern geen probleem is.

Volledig opnieuw opbouwen Een volledige een-op-een opbouw betekent dat de applicatie helemaal opnieuw wordt gebouwd met het platform. De RPG-applicatie dient uitsluitend als bron om de eisen te definiëren. Voordelen: • Snelle ontwikkeling, • Funcionele legacy wordt verwijderd, • Technische legacy wordt verwijderd. Nadelen: • Heeft meer inspanning nodig dan een een-op-een upcycle. • Meer risico op scope creep. Wanneer te gebruiken: • Wanneer de functionele legacy hoog is en de technische legacy hoog.

Gefaseerde vervanging van modules Wanneer het in één keer vervangen van de kern RPG-applicatie te riskant is of te veel tijd kost, kunnen bedrijven ervoor kiezen om één module tegelijk te vervangen. Dit betekent dat de oude en nieuwe applicatie een interface nodig hebben om met elkaar te kunnen communiceren. Voordelen: • Vervanging van de kernapplicatie is zeer gecontroleerd. Nadelen: • In plaats van functionaliteit te bouwen, moeten interfaces naar het oude systeem worden gemaakt/gewijzigd, • Legacy in het kernsysteem moet in aanmerking worden genomen in de nieuwe applicatie. Dit kan voor uitdagingen zorgen wanneer de structuur van de nieuwe applicatie sterk verschilt van de oude applicatie. Wanneer te gebruiken: • Als de kernapplicatie te groot is om in één keer te vervangen.

Volledige een-op-een upcycle Dit is de meest geavanceerde methode, die de meeste low-code platform leveranciers niet kunnen bieden. Bij een volledige één-op-één upcycle wordt de datamodelstructuur van de RPG-applicatie geïmporteerd in het platform. Na enkele geautomatiseerde verrijkingen heb je direct een applicatie die bestaat uit een database, servicelaag en GUI. Het project zal zich voornamelijk richten op het verfijnen van het datamodel, het herbouwen van businesslogica en het modelleren van de GUI waar nodig. Voordelen: • Zeer snelle ontwikkeling, • Nauwelijks sprake van scope creep, • Functionaliteit blijft hetzelfde, • Technische legacy wordt verwijderd. Nadelen: • Functionele legacy wordt verplaatst naar het nieuwe systeem. Wanneer te gebruiken: • Als de functionele legacy laag is en de technische legacy hoog.

Tot slot
Beslissingen om een ​​RPG-applicatie te vervangen zijn moeilijk, maar wanneer de keuze voor technologie minder belangrijk wordt, wordt de stap naar een nieuwe applicatie een stuk eenvoudiger. Het werken met een low-code platform neemt de technologische zorg weg en biedt verschillende scenario's voor het vervangen van RPG-applicaties.

Bekijk het ​​platformoverzicht als je meer wilt weten over het low-code platform of meld je direct aan voor het eerstvolgende RPG webinar van 1 april.

Door Frank Wijnhout, Principle Solutions Architect bij Thinkwise