Technical debt en legacy software: wat het is en wanneer u vervangt
Technical debt is de opgebouwde achterstand tussen hoe een systeem nu in elkaar zit en hoe het eigenlijk zou moeten werken om uw organisatie goed te blijven dienen. Elk systeem bouwt het op; het wordt pas een probleem als de rente (de tijd en het risico van elke volgende wijziging) hoger wordt dan de waarde die het nog oplevert. Deze pagina legt uit waar het begrip vandaan komt, welke signalen wijzen op een systeem dat aan modernisering toe is, en hoe u dat aanpakt zonder de organisatie stil te leggen. Meer weten over de keuze tussen zelf bouwen en een pakket? Bekijk ook build vs buy: maatwerk software of pakket kiezen.
Vraag een onafhankelijke beoordeling Naar de signalenDe schuld-metafoor van Ward Cunningham
De term technical debt komt niet uit een academisch paper, maar uit een ervaringsverslag van softwareontwikkelaar Ward Cunningham uit 1992, geschreven voor het financiële softwarebedrijf WyCash.
De oorspronkelijke gedachte
Cunningham schreef destijds zoiets als: eerste code uitleveren is als een lening aangaan. Een beetje schuld versnelt de ontwikkeling, zolang u die maar op tijd aflost met een herschrijving. Het gevaar ontstaat pas wanneer de schuld niet wordt afgelost. Hij gebruikte de metafoor om niet-technische stakeholders bij WyCash uit te leggen waarom er structureel tijd voor refactoring moest worden vrijgemaakt, niet om onzorgvuldig werk goed te praten.
Hoe de term vandaag gebruikt wordt
In Cunninghams eigen formulering ging het om de afstand tussen uw begrip van het domein op het moment van bouwen en het begrip dat u nu heeft. In het gangbare, bredere gebruik van vandaag staat de term vooral voor bros ontwerp: code en architectuur die moeilijk aan te passen zijn, waardoor elke volgende wijziging langer duurt dan de vorige.
Drie plekken waar technische schuld zich opstapelt
In de praktijk wordt onderscheid gemaakt naar waar de schuld zit, omdat dat bepaalt hoe duur en risicovol aflossen is.
Code-schuld
Rommelige of gedupliceerde code, ontbrekende tests, snelle patches die nooit zijn opgeruimd. Meestal het goedkoopst op te lossen: refactoren zonder dat de buitenkant van het systeem verandert.
Architectuur-schuld
De opzet van het systeem past niet meer bij hoe het gebruikt wordt: een monoliet die eigenlijk los moet kunnen schalen, of modules die zo verweven zijn dat één wijziging overal doorwerkt. Dit vraagt een herontwerp, geen quick fix.
Infrastructuur-schuld
De taal, het framework of het platform waarop het systeem draait, is end-of-life of bijna niemand kent het nog. Dit is waar legacy-systemen als Delphi, COBOL, AS/400 en WinCC typisch in terechtkomen.
Wanneer wordt legacy software een risico?
Niet elk ouder systeem is een probleem. Het wordt urgent zodra een van deze vier factoren meespeelt.
Beveiliging: verouderde taal, groter risico
Microsoft en Google rapporteren onafhankelijk van elkaar dat rond de 70% van de ernstige beveiligingslekken die zij jaarlijks patchen, terug te voeren zijn op memory-safety-problemen in talen als C en C++. Systemen die daar al decennia op draaien en niet langer actief onderhouden worden, stapelen dat risico op zonder dat er nieuwe patches tegenover staan.
Kennis: de mensen die het systeem snappen, vertrekken
COBOL is het bekendste voorbeeld: de taal verwerkt naar schatting nog altijd een aanzienlijk deel van het bancaire betalingsverkeer wereldwijd, terwijl de generatie developers die het onderhoudt met pensioen gaat en er nauwelijks nieuwe COBOL-developers bijkomen. Hetzelfde patroon speelt bij Delphi, AS/400 (RPG) en WinCC-configuraties: de kennis zit vaak bij één of twee mensen.
Compliance: regelgeving verandert sneller dan het systeem kan volgen
Regelgeving zoals de NIS2-richtlijn stelt eisen aan beveiliging en meldplicht die een gesloten legacy-systeem vaak niet zonder ingrijpende aanpassingen kan waarmaken. Zie ook onze uitleg over NIS2 en software op maat.
Integratie: het systeem praat niet met de rest
Moderne tools verwachten een API. Veel legacy-systemen zijn gebouwd vóórdat dat de norm was en hebben geen of een zeer beperkte koppelmogelijkheid, waardoor elke integratie een aparte, kwetsbare tussenlaag wordt.
Zeven signalen dat het tijd is om te moderniseren
Geen enkel signaal op zich is doorslaggevend. Herkent u er drie of meer, dan is een beoordeling van het systeem het overwegen waard.
Er zijn nauwelijks nog developers te vinden die de taal of het platform kennen
Elke vacature voor onderhoud duurt langer dan de vorige, of gaat naar een steeds kleinere groep freelancers.
Elke wijziging kost meer tijd dan de vorige
Een kleine aanpassing raakt onverwacht andere onderdelen; testen kost relatief steeds meer inspanning ten opzichte van de wijziging zelf.
De leverancier van het platform stopt met support
Geen beveiligingsupdates meer, of alleen nog tegen een oplopende premium voor verlengde ondersteuning.
Het systeem kan niet koppelen met de tools die de rest van de organisatie al gebruikt
Data wordt handmatig overgetypt of via losse exports uitgewisseld in plaats van via een koppeling.
Nieuwe wet- en regelgeving vraagt om functionaliteit die het systeem niet heeft
Denk aan meldplichten, logging-eisen of toegangscontrole die pas achteraf tegen het systeem aan gebouwd moeten worden.
De onderliggende infrastructuur is zelf end-of-life
Het besturingssysteem, de database-versie of de runtime waarop het systeem draait, wordt niet langer gepatcht door de fabrikant.
Kennis over hoe het systeem werkt, zit in het hoofd van één of twee mensen
Er is geen actuele documentatie en bij uitval of vertrek van die persoon staat de organisatie stil.
Dit zijn de signalen in vogelvlucht. Een uitgebreidere doorloop, met per signaal een concrete check om te herkennen hoe dringend het is, staat in wanneer moet u uw software laten vervangen.
Veelvoorkomende legacy-systemen die wij vervangen
Elk platform brengt zijn eigen migratie-uitdagingen met zich mee. Vier systemen komen bij ons het vaakst voorbij.
Delphi-applicaties
Vaak Windows-desktopapplicaties uit de jaren negentig en tweeduizend, nog volledig operationeel maar niet meer geschikt voor web- of mobiel-gebruik. Lees meer over Delphi-applicatie moderniseren.
COBOL-systemen
Typisch bij banken, verzekeraars en overheid: grote, kritieke batchverwerkingssystemen waar de risico's van stilstand hoog zijn. Lees meer over COBOL-systeem vervangen.
AS/400 (IBM i)
Veel gebruikt in groothandel, productie en logistiek voor ERP- en voorraadprocessen, vaak met RPG-programmalogica die decennia meegaat. Lees meer over AS/400 vervangen door een modern platform.
WinCC (SCADA/HMI)
Siemens WinCC-installaties op de fabrieksvloer die procesbesturing en monitoring verzorgen, waarbij vervanging zorgvuldig moet gebeuren zonder productie-onderbreking. Lees meer over WinCC vervangen.
Vervangen of moderniseren: geen alles-of-niets-keuze
De keuze staat zelden tussen niets doen en alles in één keer vervangen. In de praktijk zijn er twee routes.
Incrementeel moderniseren
Onderdelen van het oude systeem worden stap voor stap vervangen terwijl de rest doorwerkt: eerst de buitenkant of een specifiek proces, dan de volgende laag. Dit verlaagt het risico per stap en houdt de organisatie werkend, maar vraagt een tussenlaag die oud en nieuw met elkaar laat praten.
Volledige vervanging
Het hele systeem wordt in één traject overgezet naar een nieuw platform, inclusief dataconversie. Dit is overzichtelijker qua architectuur, maar vraagt een zorgvuldige planning van de overgang, inclusief een periode waarin oud en nieuw systeem naast elkaar gecontroleerd worden.
Hoe een moderniseringstraject er in de praktijk uitziet
Ongeacht of u kiest voor incrementeel of in één keer vervangen, doorloopt een zorgvuldig traject in de kern dezelfde vier stappen.
Inventarisatie
In kaart brengen wat het systeem exact doet: welke bedrijfsregels erin verstopt zitten, welke koppelingen er zijn en waar de kennis over het systeem vandaan komt. Bij legacy-systemen zit veel van die logica nergens gedocumenteerd, alleen in de code zelf.
Prioriteren op risico en waarde
Niet elk onderdeel is even urgent. Onderdelen die het meeste beveiligingsrisico dragen of het vaakst wijzigen, komen doorgaans als eerste aan de beurt, niet per se de onderdelen die het makkelijkst zijn.
Bouwen naast het bestaande systeem
Bij een incrementele aanpak ontstaat een koppelvlak dat oud en nieuw laat samenwerken, zodat het bestaande systeem operationeel blijft terwijl het nieuwe onderdeel wordt gebouwd en getest.
Gecontroleerd overzetten en valideren
Data en functionaliteit worden overgezet met een validatieslag: aantallen, historie en bedrijfsregels worden gecontroleerd voordat het oude onderdeel definitief wordt uitgezet.
Veelgestelde vragen over technical debt en legacy software
Een onafhankelijke blik op uw legacy-systeem
Wij beoordelen eerst wat uw huidige systeem doet en waar de risico's echt zitten, voordat we een moderniseringsaanpak voorstellen die past bij uw organisatie.
Plan een vrijblijvend gesprek