Een bestaande applicatie moderniseren of herschrijven?

Een oude applicatie wordt moeilijk om te laten evolueren, en de verleiding is duidelijk: alles opnieuw doen. De code “is niet meer te volgen”, releases maken bang, één persoon draagt de kennis. Een herschrijving belooft een proper systeem. Ze belooft ook maanden zonder zichtbare waarde, en daarna een omschakeling waarin oud en nieuw hetzelfde moeten zeggen over de data. Dat tweede punt is doorgaans het echte onderwerp.

Voor u kiest, benoemt u wat vastzit. Niet het gevoel. De kost van de volgende wijziging, het risico om het systeem aan te raken, en wat de bedrijfsvoering verliest als er niets beweegt.

Waarom oudere applicaties moeilijk evolueren

De leeftijd van de code verklaart niet alles. Een oude basis die begrepen is, met tests op de regels die tellen, kunt u nog wijzigen. Wat vastloopt, is de stapel beslissingen die nooit zijn opgeschreven.

De deployment is manueel en niemand durft er op vrijdag aan te komen. De businesslogica zit verspreid tussen een scherm, een batch en een trigger. Er is geen betrouwbare manier om te weten of een wijziging een zeldzaam geval heeft gebroken. De ontwikkelomgeving lijkt niet meer op productie. Afhankelijkheden kunt u niet meer bijwerken zonder neveneffecten.

Daarbovenop zit de kennis. Als één persoon weet waarom een berekening zo is, wacht elke evolutie op zijn kalender. De software is niet alleen moeilijk te wijzigen. Ze is moeilijk over te dragen.

Signalen dat moderniseren nodig wordt

Enkele signalen komen samen terug:

• een kleine wijziging vraagt herhaaldelijk een onevenredige termijn;
• correcties veroorzaken regressies op trajecten die niemand in het hoofd had;
• legitieme vragen vanuit de business worden geweigerd omdat “het systeem dat niet kan”;
• omwegen — exports, dubbele invoer, lokale scripts — dragen intussen een deel van het proces;
• een release is een gebeurtenis, geen routine;
• de versie van het platform wordt niet meer bijgehouden, en een securityfix wacht daarom.

Eén signaal rechtvaardigt geen project. Meerdere, op een tool die kritiek werk draagt, rechtvaardigen minstens de opties te vergelijken. Het probleem vanuit de klant staat in bedrijfssoftware moderniseren.

Optie 1: nog onderhouden

Onderhouden is een beslissing, geen mislukking. Ze is rationeel als de software het werk nog doet, de gevraagde evoluties zeldzaam zijn, en het risico om aan te raken groter is dan de kost om zo verder te gaan.

Ze houdt op rationeel te zijn als “we raken er niet meer aan” het beleid wordt, ook voor een kwetsbaarheid of een bedrijfsverplichting. Onderhouden veronderstelt nog een minimum: weten hoe u deployt, weten wie verantwoordelijk is, een bruikbare kopie van de data hebben, en niet afhangen van een machine die niemand zou kunnen herbouwen.

Als die voorwaarden standhouden, kan de juiste beweging zijn om de paar kritieke trajecten te documenteren en een herhaalbare deployment terug te zetten, zonder een herschrijving te openen.

Optie 2: geleidelijk moderniseren

Moderniseren betekent hier het systeem per zone wijzigen terwijl het de bedrijfsvoering blijft dienen. Het nuttige patroon is het strangler-patroon: het nieuwe traject neemt één concreet geval over, het oude gaat verder voor de rest, en de grens is expliciet.

In de praktijk zijn dat enkele hefbomen, geen nieuwe look:

• een domein isoleren — een type dossier, een berekening, een integratie — achter een stabiele interface;
• stoppen met regels toe te voegen in de zone die u hebt beslist te verlaten;
• die zone dekken met tests op de gevallen die pijn doen, voor u ze verplaatst;
• de deployment herhaalbaar maken, vaak met cloud en beheer, zodat elke stap omkeerbaar is;
• omschakelen wanneer de nieuwe zone standhoudt in reële omstandigheden, niet wanneer ze “af” lijkt op een demo.

Het tempo is minder spectaculair dan een herbouw. Het levert een nuttig traject voor het programma af is, en het houdt het oude systeem als vangnet tot de cijfers kloppen.

Optie 3: herschrijven

Een herschrijving is gerechtvaardigd als de fundamentele beperkingen de rest te duur maken. Het datamodel kan de echte gevallen niet dragen zonder permanente kronkels. Het platform heeft geen updatepad meer. Verantwoordelijkheden zijn zo gemengd dat een zone isoleren evenveel kost als ze herbouwen. Of de bedrijfsactiviteit is van aard veranderd, en de tool codeert een organisatie die niet meer bestaat.

U moet nog altijd het juiste systeem herschrijven. Scherm per scherm overnemen bevriest de omwegen in het nieuwe. Het voorbereidende werk is hetzelfde als voor nieuwe software: rollen, beslissingen, uitzonderingen, welke data de referentie is. Kaderen en architectuur voor u een nieuwe repository opent, vermijdt het oude probleem te herbouwen in een recentere syntaxis.

Een herschrijving kost ook aandacht. Terwijl ze vooruitgaat, moet het oude systeem blijven leven. Als het team beide niet kan, klopt de planning niet, hoe goed het doel ook oogt.

Optie 4: vervangen door iets dat al bestaat

Soms loont het specifieke niet meer. Het proces is standaard geworden, de lokale afwijkingen zijn gewoontes eerder dan voordelen, en een product op de markt dekt de behoefte tegen een lagere kost — licentie, integratie en invoering inbegrepen.

De toets is niet “bestaat er een product”. Het is “zijn onze afwijkingen de kost om ze te dragen nog waard”. Als ze dat niet zijn, verandert het project van aard: parametrering, datamigratie, interfaces met wat u houdt, en het bewuste laten vallen van enkele eigenheden.

Als ze dat wel zijn, eindigt een generieke tool vaak omringd door informeel maatwerk. Beter dat te weten voor u tekent.

Het echte onderwerp: de data

Gebruikers beoordelen het nieuwe systeem met één vraag: staan mijn dossiers erin, en kloppen ze?

Migratie is geen script op het einde. Het is een ontwerpbeperking. Welke entiteiten verhuizen? Welke historiek moet leesbaar blijven, en welke mag in een archief? Welke sleutels laten oud en nieuw overeenkomen? Wat is de kwaliteit van de data vandaag — duplicaten, inconsistente statussen, velden die voor iets anders worden gebruikt dan hun naam?

Een eerlijk plan rekent op een verschil. U vergelijkt aantallen open dossiers, voorraden, saldi, niet alleen het aantal rijen. U beslist op voorhand welk verschil aanvaardbaar is op de dag van de omschakeling, en wie daarna mag corrigeren.

Zonder die vergelijking faalt de properste herschrijving op het moment dat ze de praktijk ontmoet. Nieuwe code heeft geen geheugen. De data wel.

Vermijd de big bang

Alles op een vrijdagavond uitzetten veronderstelt dat het nieuwe systeem volledig is, dat de data kloppen, dat partnerinterfaces zijn gevolgd, en dat mensen er maandag in kunnen werken. Die voorwaarden zijn zelden samen waar.

Co-existentie is trager uit te leggen en veiliger om te leven. Het oude systeem blijft de referentie voor trajecten die nog niet zijn verhuisd. Het nieuwe neemt één stroom, met een duidelijke manier om te zien waar een dossier zit. U kunt één zone terugdraaien zonder het hele project terug te draaien. U vraagt mensen niet om twee keer in te voeren, behalve in een kort en gemeten venster.

Een big bang is soms onvermijdelijk, bijvoorbeeld als een partnerinterface maar met één systeem praat. Dan bereidt u hem voor als een operatie: een repetitie op een kopie, stopcriteria, een benoemde rol voor iedereen op de dag zelf. Het is geen hoop meer.

Hoe kiest u?

Onderstaand raster geeft geen score. Het dwingt de criteria af die de beslissing echt veranderen.

Criterium	Nuttige vraag
Kritikaliteit	Is een onderbreking van enkele uren op te vangen, of stopt de stroom met de tool?
Schuld	Is de kost van de volgende wijziging nog leesbaar, of is elke vraag een ontdekking?
Kennis	Weet iemand nog waarom de regels zo zijn, en kan die het opschrijven?
Afhankelijkheden	Welke systemen en partners breken als het datacontract verandert?
Waarde van het specifieke	Zit wat u onderscheidt in deze tool, of in de manier van werken errond?
Horizon	Bestaat dit proces over drie jaar nog in deze vorm?

Als de kritikaliteit hoog is en de kennis dun, begint u met het systeem deploybaar en observeerbaar te maken voor u de kern vervangt. Als het specifieke weinig resterende waarde heeft, kijkt u naar een bestaand product voor u code schrijft. Als de data vuil zijn, slaat geen scenario die stap over.

Bouwen van de vervanging, of van de nieuwe zone, komt na die sortering. De betere beslissing is niet die welke de meeste nieuwe code produceert. Het is die welke de volgende wijziging gewoon maakt, zonder de historiek te verliezen waarop de business steunt.