De ventilator uit Australië: het échte verhaal achter technische schuld

‘Technische schuld’. Dat klinkt meer als iets voor ‘de jongens en meiden van IT’. Een kwestie van refactoren, upgraden, migreren. Even de ‘boel modern trekken’ en klaar.

Was het maar zo simpel.

Technische schuld is een onderwerp voor op de bestuurstafel.

Ward Cunningham gaf het in 1992 de naam: technische schuld. Het idee was dit: software veroudert. Net als machines. Alleen slijt software niet door wrijving, maar door de wereld eromheen. Nieuwe eisen. Nieuwe dreigingen. Nieuwe integraties. Nieuwe mensen (die de oude keuzes niet meer snappen).

En ja, échte technische schuld bestaat ook. Ik zat ooit bij een organisatie met een IBM mainframe dat end-of-life en out-of-support was. Maar de machine was nog hard nodig. Toen een ventilator ermee ophield, eindigde de zoektocht niet bij IBM, maar op een schimmige internetveiling… in Australië. Tweedehands. De vraag was alleen: “Doet ‘ie het nog?” Niemand had enig idee. Ding werd besteld, er werd bovenop de aanschafprijs betaald voor transport en invoerrechten. Alles bij elkaar opgeteld een prijs waarmee je een flink stuk van een modern serverrack kunt vullen.

Klinkt als een hardwareprobleem? Nee. Het was een softwareprobleem met een ventilator.

Kijk, dat mainframe was nodig omdat één cruciaal systeem niet wilde draaien op nieuwere mainframes. Het vervangende systeem was ‘bijna klaar’. Totdat het vertraging opliep. En nog meer vertraging. En nóg meer. En toen het eindelijk richting productie ging, werd het afgekeurd en mocht men terug naar de tekentafel. Het oude systeem draaide dus door. Met een ventilator uit Australië.

Dat is waarom je ‘technische schuld’ zelden oplost met modernere techniek.

Niet met nieuwe hardware. Niet met een nieuw netwerk. Niet met “we gaan naar de cloud”. Want de cloud verhuurt geen begrip. Je kunt daar óók geen Windows 2003 blijven draaien zonder pijn. Je kunt schuld verplaatsen. Verpakken. Verstoppen. Maar je kunt het niet wegkopen.

Technische schuld is meestal geen technisch tekort. Het is een opeenstapeling van keuzes: uitstel dat normaal werd, prioriteiten die nooit echt prioriteiten waren, verantwoordelijkheid zonder mandaat, projecten die starten maar niet afkomen. En een roadmap… die feitelijk vooral troost biedt.

Dus als je schuld wilt afbouwen, begin dan niet bij tooling. Begin bij kennis, eigenaarschap en besluitvorming. Anders eindig je straks ook op een vage veiling tegen discutabele kosten. Alleen heet de ventilator dan ‘migratieprogramma’.

Windows 2003 is geen “legacy”, het is nalatigheid

Software slijt.

Niet omdat er letterlijk een tandwieltje afbreekt, maar omdat alles eromheen blijft bewegen. Besturingssystemen, browsers, protocollen, API’s, compliance-eisen, aanvalstechnieken, devices, verwachtingen van gebruikers. De wereld wordt sneller. Jouw applicatie blijft hetzelfde. En precies dáár begint de slijtage.

Als je vaker mijn blogs leest, weet je dat ik dit blijf herhalen. Omdat ik nog te vaak versleten software tegenkom. En vooral: omdat je het kunt voorkomen.

Ik sprak ooit iemand die zijn autobanden zelfs nog niet wilde vervangen toen het staal er al uit stak. “Kan nog wel even.” Hij vertelde zichzelf dat het zuinigheid was. Wellicht. Het was vooral roekeloosheid. En dat… zie ik meer en meer in de IT.

Voorbeeld. Dit jaar kwam ik nog een Windows 2003-server tegen. “Ja, maar de software draait niet op 2008.” Klopt. En ik zag een oude Wang-machine waar niemand meer van wist wat hij deed. “Als we ’m uitzetten stopt er van alles… maar geen idee waarom precies.” Dat is rijden op je velgen, met een vonkenregen achter je auto, terwijl je jezelf vertelt dat je ‘in control’ bent.

Natuurlijk: meestal is het minder spectaculair. Maar ook met 1,5 mm profiel wil je de winter niet in. Niet alleen omdat het je fanmail van het CJIB kan opleveren, maar omdat je bij de eerste onverwachte remactie ontdekt dat “het ging toch prima?” iets anders is dan “het is veilig”.

En bij software is uitval slechts het meest zichtbare risico. Vaak niet eens het duurste.

Versleten software vreet namelijk stilletjes aan je organisatie:

• Traagheid. De wet van Moore mag afvlakken, maar de sprong tussen hardwaregeneraties is nog steeds gigantisch. Alles wat op oude platforms blijft hangen, betaalt productiviteitsbelasting. Medewerkers wachten. Processen stokken. En niemand schrijft “wachten op systeem” op een urenbriefje. Dus het lijkt gratis. Tot je de rekensom maakt.
• Bruikbaarheid. Oude interfaces, rare beperkingen, onhandige workflows. Je team verzint workarounds, Excelletjes, stappenplannen en “zo doen we dat hier nu eenmaal”. Dat zijn allemaal verborgen FTE’s. En modern werken (thuis, mobiel, flexibel) wordt dan ineens een dure Citrix-/VDI-constructie, terwijl een moderne webapp dit gewoon standaard levert.
• Integratie. Oude software praat in oude protocollen. Dus zet je er een integratieplatform tussen. Kostbaar om te bouwen, kostbaar om te beheren, en vooral: het stapelt complexiteit op complexiteit. Elke extra koppeling is weer een extra plek waar het mis kan gaan.
• Veiligheid. Ik zie nog steeds metingen binnenkomen met verouderde versleuteling, simpelweg omdat het zendende systeem modernere encryptie niet ondersteunt. Voor meetdata is dat al vervelend. Maar diezelfde omgevingen doen vaak óók financiële transacties. Dan is “het werkt nog” geen argument meer. Dan is het een risicoacceptatie - meestal zonder dat iemand dat hardop zo noemt.

Software slijt dus niet ineens. Het slijt elke dag een beetje. Daarmee lopen de verborgen kosten dus ook op. En hoe langer je wacht, hoe duurder het wordt om weer grip te krijgen. Dat is de echte vonkenregen: je ziet ‘m pas als het al brandt.

Waarom “AI fixt onze legacy” een gevaarlijke leugen is

“Hugo, geen probleem man, lossen we op met AI.”

Natuurlijk. Want als je technische schuld weer als een technisch probleem kunt framen, hoef je het niet te hebben over prioriteiten, eigenaarschap en besluitvorming. Veel zorgelijker kan het gewoon niet. En ik heb al menige IT-manager en CIO uitgelegd dat dit de problemen niet alleen verschuift, het verergert het alleen maar.

Voorbeeld: AWS kondigde gespecialiseerde AI-agents aan die technische schuld voor je opsporen en oplossen. In de praktijk: upgrades van Java, Python en frameworks. Code transformeren zodat het weer compileert en draait op iets nieuwers. Handig. Soms zelfs waardevol.

Maar het is vooral: nieuwe rubbers in je brandstofsysteem zetten zodat je oude auto ook op E10 kan rijden.

Je rijdt weer weg. Alleen je blijft in dezelfde auto. Met dezelfde roest. Dezelfde rammels. En dezelfde onderhoudsmentaliteit.

Ik zag een ERP-leverancier die met zo’n AI-migratie van een verouderd low-code platform naar .NET ging. De code werd 1:1 overgezet. Resultaat: moderner platform, langere support-horizon… en precies dezelfde vertragingen, locking-problemen en functionele fouten. Alles wat slecht was, ging netjes mee. De migratie was een verhuizing, geen renovatie.

Dat is het kernprobleem: de huidige generatie AI doet vooral tekstuele transformaties. Ook op code. Het kan syntaxis omzetten, libraries vervangen, patterns herschrijven. Maar het begrijpt je domein niet, je performanceprofiel niet, je datastructuur-rot niet. En al helemaal je organisatiekeuzes niet.

AI kan je helpen om technische schuld sneller zichtbaar te maken en sommige upgrades goedkoper te maken.

Maar het kan je niet redden van schuld die ontstaat door uitstel als strategie. En dat is de oorzaak van de meeste van technische schuld. 

Zolang je blijft denken dat technische schuld ‘iets voor IT’ is, is de inzet van AI als een pleister. Pleisters kunnen de oplossing zijn… Behalve als je ondertussen op velgen rijdt.

Van “het werkt nog” naar “we zijn weer in control”

Technische schuld los je niet op met nóg een tool, nóg een migratie of nóg een sprint ‘opruimen’.

Je lost het op door keuzes te maken. En die keuzes vragen om twee dingen tegelijk:

• techniek (meten, refactoren, moderniseren)
• strategie (eigenaarschap, prioriteit, ritme, stop-go besluiten)

Bij Sciante helpen we al ruim 15 jaar organisaties die klem zitten in legacy, vertragingen en “we durven dit niet aan te raken”. We lossen alles op. En het liefst voorkomen we nieuwe schuld. Maar als de rekening al op tafel ligt, helpen we je ook om gericht af te lossen. Uiteraard zonder je IT stil te leggen en zonder een jarenplan dat mogelijk toch weer uitloopt.

Wil je technische schuld inlossen of voorkomen?

Natuurlijk wil je dat. Plan daarvoor een vrijblijvende afspraak met mij. In 30 minuten brengen we scherp in kaart waar je schuld écht zit, wat het je kost, en welke 3 stappen je als eerste moet zetten om weer grip te krijgen.