Technische schuld begrijpen

Van Wikipedia: “Technische schuld (ook bekend als ontwerpschuld of codeschuld) is “een concept in het programmeren dat het extra ontwikkelwerk weergeeft dat ontstaat wanneer code die op korte termijn gemakkelijk te implementeren is, wordt gebruikt in plaats van de beste algehele oplossing toe te passen”.

Technische schuld kan worden vergeleken met financiële schuld. Als technische schuld niet wordt afgelost, kan deze ‘rente’ opbouwen, waardoor het moeilijker wordt om later wijzigingen door te voeren. Onaangepakte technische schuld verhoogt de software-entropie. Technische schuld is niet noodzakelijkerwijs iets slechts, en soms (bijvoorbeeld als proof-of-concept) is technische schuld nodig om projecten vooruit te helpen. Anderzijds beweren sommige experts dat de metafoor van “technische schuld” de impact ervan vaak minimaliseert, wat resulteert in onvoldoende prioritering van het noodzakelijke werk om deze te corrigeren.”

Het concept van technische schuld komt uit de wereld van de software-engineering, maar het is net zo goed van toepassing op de wereld van IT- en bedrijfsinfrastructuur. Net als bij software-engineering ontwerpen we onze systemen en onze netwerken, en het nemen van kortere wegen in onze ontwerpen, waaronder het werken met minder dan ideale ontwerpen, het inpassen van bestaande hardware en andere slechte ontwerppraktijken, brengt technische schuld voort. Een van de meer significante vormen hiervan komt voort uit het investeren in het “verleden” in plaats van in de “toekomst” en wordt vrij vaak in gang gezet door de sunk-cost-drogreden (oftewel goed geld naar slecht geld gooien).

Het is gemakkelijk om dit dagelijks in bedrijven te zien gebeuren. Er worden nieuwe plannen voor de toekomst gemaakt, maar voordat ze worden uitgevoerd, worden er investeringen gedaan om een oud systeemontwerp werkend te houden, beter te laten functioneren, uit te breiden of wat dan ook. Deze investering wordt vervolgens ofwel vrijwel onmiddellijk een financieel verlies, ofwel, vaker, een prikkel om niet zo snel, zo grondig of zelfs helemaal niet in de toekomstige ontwerpen te investeren. De investering in het verleden kan in het ergste geval verlammend worden.

Dit gebeurt op talloze manieren en is doorgaans onbedoeld. Vaak zijn investeringen nodig om een bestaand systeem naar behoren draaiende te houden en zouden ze, onder normale omstandigheden, gewoon worden gedaan. Maar in een situatie waarin er een toekomstige wijziging nodig of mogelijk gepland is, kan deze investering problematisch zijn. Betere kostenanalyse en triageplanning kunnen dit in veel gevallen echter verhelpen.

Stelt u zich, als niet-technisch voorbeeld, voor dat u een oudere auto bezit die goed heeft gediend, maar over drie maanden aan vervanging toe is. Over drie maanden bent u van plan in een nieuwe auto te investeren omdat de oude niet langer kosteneffectief is vanwege voortdurende onderhoudsbehoeften, lagere efficiëntie enzovoort. Maar voordat uw driemaandenplan om een nieuwe auto te kopen aanbreekt, krijgt de oude auto een kleine storing en vereist nu een aanzienlijke investering om hem rijdend te houden. Geld in de oude auto steken zou een nieuwe investering in de technische schuld zijn. In plaats van een groot bedrag uit te geven om een oude auto nog een paar maanden te laten rijden, is het naar voren halen van het tijdstip om de nieuwe te kopen uiteraard veel verstandiger in financieel opzicht. Bij auto’s zien we dit gemakkelijk (in de meeste gevallen). We besparen geld, potentieel veel, door snel een nieuwe auto te kopen. Als we fors zouden investeren in de oude, verliezen we die investering ofwel over een paar maanden, ofwel riskeren we onze solide financiële planning te wijzigen voor de reeds gemaakte aankoop van een nieuwe auto. Beide gevallen zijn financieel slecht.

IT werkt op dezelfde manier. Een grote som geld uitgeven om een oud e-mailsysteem te onderhouden zes maanden vóór een geplande migratie naar een gehost e-mailsysteem zou waarschijnlijk zeer dwaas zijn. De investering gaat ofwel vrijwel onmiddellijk verloren wanneer het oude systeem buiten gebruik wordt gesteld, ofwel ondermijnt ze onze goede planningsprocessen en brengt ons ertoe niet te migreren zoals gepland en ondermaats werk te leveren voor onze bedrijven, omdat we technische schuld onze besluitvorming hebben laten sturen in plaats van een behoorlijke planning.

Vaak kan een gebrekkige triageoperatie of een onjuiste bevoegdheid om triage uit te voeren de factor zijn die noodinvesteringen in technische schuld veroorzaakt in plaats van snelle, toekomstgerichte investeringen. Dit is slechts één gebied waar belangrijke verbeteringen problemen kunnen aanpakken, maar het is een belangrijk gebied. Dit kan in sommige gevallen ook worden beperkt door middel van “wat als”-planning, waarbij investeringsplannen klaarliggen die afhankelijk zijn van veelvoorkomende of verwachte noodgevallen die zich kunnen voordoen, wat zo eenvoudig kan zijn als capaciteitsuitbreidingsbehoeften als gevolg van groei die optreden voordat de systeemplanning in beeld komt.

Een ander uitstekend voorbeeld van veelvoorkomende technische schuld is de uitbreiding van de opslagcapaciteit van servers. Dit is een scenario dat ik met enige regelmaat tegenkom en dat technische schuld goed illustreert. Het is gebruikelijk dat een bedrijf servers aanschaft die over weinig interne opslagcapaciteit beschikken. Ofwel onmiddellijk, ofwel ergens later, is er meer capaciteit nodig. Als dit onmiddellijk gebeurt, kunnen we zien dat de aangeschafte server een vorm van technische schuld was door een onjuist ontwerp en duidelijk een tekortkoming in het planning- en aanschafproces vertegenwoordigt.

Maar een gangbaarder voorbeeld is de noodzaak om de opslag twee of drie jaar na de aanschaf van een server uit te breiden. Veelvoorkomende uitbreidingskeuzes zijn onder meer het toevoegen van een externe opslagarray die aan de server wordt gekoppeld, of het aanpassen van de server zodat deze meer lokale opslag accepteert. Beide benaderingen zijn doorgaans grote investeringen in een toch al oude server, een server die gemakkelijk veertig procent of meer van zijn nuttige levensduur achter de rug heeft. In veel gevallen kan dezelfde of slechts een iets hogere investering in een geheel nieuwe server resulteren in nieuwe hardware, snellere CPU’s, meer RAM, de benodigde opslag, doelgericht ontworpen en gebouwd, op elkaar afgestemd en met een vernieuwde ondersteuningslevensduur, een kleinere datacenter-voetafdruk, een lager stroomverbruik, nieuwere technologieën en functies, betere leveranciersrelaties en meer, en dit alles terwijl de oorspronkelijke server behouden blijft om te hergebruiken, buiten gebruik te stellen of door te verkopen. De ene manier geeft geld uit aan het ondersteunen van het verleden, de andere kan vaak een vergelijkbaar bedrag aan de toekomst besteden.

Technische schuld is voor veel bedrijven een verlammende factor. Ze verhoogt de kosten van IT, soms aanzienlijk, en kan leiden tot een hoge mate van risico door een gebrek aan planning, waarbij de meeste uitgaven op noodgevallen zijn gebaseerd.