Technische schuld

Wees je bewust van je technische schuld

7 mei 2021

Application modernization

Geld lenen kost ook geld

Technische schuld, of technical debt, is een manier om te verwijzen naar iets dat nog niet is opgelost en dat je door omstandigheden vooruitschuift als ‘een zorg voor later’. Je levert iets op, omdat een ad-hocsituatie of deadline het zo vereist bijvoorbeeld, maar bouwt tegelijk een schuld op tegenover zaken die nog moeten aangepakt worden. In softwareontwikkeling staat technische schuld voor het prijskaartje dat je betaalt voor de extra inspanningen die je in de toekomst gaat moeten doen omdat je bewust of onbewust niet altijd gaat (of kan gaan) voor de beste of ideale oplossing. Soms moet je kiezen voor de op dat moment meest aanvaardbare oplossing. Eigenlijk is het een vorm van achterstallig IT-onderhoud, dat je hebt opgelopen door het nemen van shortcuts. Het rechttrekken ervan zal in de toekomst dus een additionele kost met zich meebrengen. 

Technische schuld is een beetje zoals een financiële lening aangaan bij een bank. Je gaat een schuld aan om op korte(re) termijn iets te realiseren en sneller je doel te bereiken. Op zich is hier niets mis mee, maar hoe langer je wacht met het terugbetalen, hoe meer schuld je accumuleert en hoe hoger de rente zal zijn die je moet betalen. Geld lenen kost met andere woorden geld; hetzelfde geldt voor technische schuld. Sommigen vergelijken technische schuld ook wel eens met Tetris, het spel met de blokjes, maar dan in de vorm van software. Hoe sneller de blokjes beginnen vallen, hoe groter de kans op gaten – lees technische schuld - in het bouwwerk, mogelijk tot op het punt dat de situatie onhoudbaar wordt.

Verouderde legacy-applicaties zijn een typisch voorbeeld hiervan - hoewel technische schuld ook bij lean en agile ontwikkelingen opgebouwd wordt, maar daarover in een volgende blog meer. Organisaties wachten vaak te lang met het vernieuwen van oudere systemen waardoor de drempel om te gaan herwerken of moderniseren zo groot is geworden dat ze er vaak niet meer aan durven beginnen. De redenen zijn divers en vaak ook met elkaar verweven: een kluwen van verouderde of slecht leesbare code, de zogenaamde ‘spaghetticode’ waar niemand meer durft aankomen, verouderde databases of onderdelen, slechte uitbreidbaarheid, gebrek aan documentatie of het juiste talent, ...

Legacy

Innoveren met de rem op

Nochtans is het een gezond principe dat hoe sneller je problemen oppakt en oplost, hoe lager de complexiteit en de kost. Een bugfix in het begin van een traject kost bijvoorbeeld 10% van een bugfix op het einde. Of omgekeerd, hoe langer je bepaalde issues blijft vooruitschuiven, hoe groter de complexiteit ervan wordt (exponentiële factor 2.1), en hoe duurder het kostenplaatje. Misschien kom je zelfs tot een punt van onoplosbaarheid, zoals bij het spelen van Tetris. Op die manier zet technische schuld een rem op vooruitgang, en dat is iets wat je te allen tijde moet proberen te vermijden. Zeker in een tijd waarin digitaliseren en moderniseren een voorwaarde zijn om te overleven.

Een bedrijf dat meer dan de helft van zijn IT-budget besteedt aan integraties en het ‘repareren’ van legacy-systemen, zal waarschijnlijk door die IT-erfenis uit het verleden in een technische schuldenspiraal terechtkomen waarin het alleen maar rente betaalt. Daar waar een bedrijf dat op een moderne IT-stack opereert en weinig technische schulden heeft bijna al zijn technologische investeringen kan richten op toekomstgerichte oplossingen en strategische innovatie en op die manier toegevoegde waarde kan creëren voor de volledige organisatie. De meeste bedrijven zitten ergens tussen deze twee uitersten. Waar het op neerkomt, is om kortetermijn en langetermijn – running the business en changing the business - met elkaar te verzoenen in een positieve digitale flow.

Let op de olifant in de kamer

Het moet gezegd worden, technische schuld is niet noodzakelijk een slechte zaak. Je kan technische schuld trouwens ook nooit volledig uitsluiten of voorkomen. Projecten moeten vooruitgang kunnen boeken en je zit nu eenmaal met bepaalde deadlines of tijdelijke beperkingen, waardoor je op een andere manier moet schakelen en soms die snellere binnenweg moet nemen.

Het is echter belangrijk dat je je bij iedere keuze in het ontwikkelingsproces bewust bent van de technische schuld die je opbouwt en plant om er iets mee te doen. Zo blijft het niveau van technische schuld acceptabel en kan de kortetermijnoplossing of shortcut op een redelijke termijn omgezet worden in een structurele oplossing. Technische schuld mag geen blinde vlek worden of de olifant in de kamer die niemand wil zien.

Nochtans zit er tussen bewustzijn en effectieve daadkracht nog vaak een discrepantie. Uit een studie van McKinsey1 blijkt namelijk dat CIO’s zich er wel degelijk van bewust zijn dat er technische schuld is binnen hun organisatie en dat die aan het toenemen is. In de praktijk spenderen ze er eigenlijk weinig of geen budget aan om er ook effectief iets aan te doen. Ze zadelen de organisatie daardoor op met een technologische erfenis die soms heel groot kan zijn om weggewerkt te krijgen. Het onderzoek toont ook aan dat als er dan toch budget wordt uitgegeven aan technische schuld dat dat dan eerder naar nieuwe projecten gaat om daar de technische schuld niet te laten ophopen en minder naar de oudere legacy-applicaties.

Waar komt technische schuld eigenlijk vandaan?

Het ontstaan van technische schuld kan zich op verschillende niveaus bevinden: strategie, architectuur, talent en processen. Een driver op strategisch niveau kan bijvoorbeeld zijn dat de business-strategie van een bedrijf niet goed is uitgeklaard zodat de IT-afdeling ook niet goed weet hoe ze hiermee moet omgaan of op moet anticiperen. Misschien zijn IT en strategie onvoldoende gealigneerd, waardoor er focus wordt gegeven aan de verkeerde IT-initiatieven. Of er is een mismatch tussen financiering en strategie, in die zin dat men wel iets wil doen, maar er geen geld tegenover staat. Ook strategische acquisities en overnames kunnen de complexiteit van het IT-landschap en processen verhogen, met alle risico’s op technische schuld van dien.

Op het architecturale front zijn er ook parameters die meespelen en aanleiding kunnen geven tot technische schuld. 70% van de IT-systemen zou nog op verouderde technologie werkt. Er zijn met andere woorden nog behoorlijk wat legacy-systemen in het applicatielandschap van een gemiddelde organisatie die hoe dan ook kosten blijven genereren voor de business. Zwaar maatwerk en monolithische blokken van code kunnen technische schuld ook in de hand werken, net zoals slechte datamodellen en -kwaliteit of het niet gebruiken van standaarden en API’s.

Daarnaast wordt software nog altijd voornamelijk door mensen gemaakt. Gebrek aan kennis, kunde, zelfs motivatie kan ook een oorzaak van technische schuld zijn. Teams die niet of onvoldoende op elkaar inspelen, zodat het ene team technische schuld voor het andere creëert.

Tot slot heb je ook nog de interne processen die een oorzaak kunnen zijn van technische schuld. Een slechte prioritering van zaken die ontwikkeld moeten worden, slechte ontwikkel- en onderhoudsprocessen die maken dat de codekwaliteit niet goed is. Er is bijvoorbeeld weinig automatisering waardoor nog veel testwerk manueel moet gebeuren wat het risico op fouten verhoogt. Onstabiele IT-operations, slechte disaster-recovery, weinig monitoring, conflicterende of ontbrekende documentatie kunnen ook maken dat IT-teams blind aan het werken zijn en op die manier technische schuld genereren.

Aflossen

Hoe kan je je technische schuld aflossen?

De beste manier om technische schuld af te lossen, is door er geen te creëren, maar dat is zoals gezegd een quasi onmogelijke opdracht. Op een technische schuldenberg blijven zitten, is ook geen optie, net omdat het een rem op vooruitgang en innovatie zet.

In de praktijk is modernisatie voornamelijk een manier om legacy-applicaties en -processen aan te pakken en daarmee ook de technische schuld weg te werken. Zoals in de vorige blog aan bod is gekomen, staan de sterren trouwens goed voor applicatiemodernisatie in die zin dat technologieën zoals cloud, big data en IoT toelaten om modernisatie op een efficiëntere en gemakkelijkere manier aan te pakken en je bedrijf sneller vooruit te helpen zodat ogenschijnlijke struikelblokken niet opwegen tegen de voordelen die het oplevert.

Maar om terug te komen op de eerder vermelde discrepantie; organisaties moeten zich in eerste instantie bewust zijn van technische schuld, het feit dat ze deze best continu monitoren én dat ze die op een redelijke termijn moeten proberen weg te werken. Alleen dan kunnen ze op een efficiënte manier moderniseren en de kost van modernisatie onder controle houden. Het in kaart brengen van technische schuld is belangrijk voor het uittekenen van een modernisatiestrategie, en de mate van automatisering daarin.

Niet zeker waar te beginnen met de schuldaflossing? Ons multidisciplinair team van applicatieconsultants tekent samen met jou het juiste plan van aanpak uit. We kunnen onze expertise en consultancy inzetten op verschillende niveaus, zoals het verbeteren van de strategische aanpak en architecturale planning, het optimaliseren van skills en het prioriteren van processen, inclusief change management, training en coaching.

(1) McKinsey Survey of tech debt among 50 CIO’s, July 2020.

Leg uw modernisatietraject niet alleen af

Wij staan voor u klaar om uw applicaties en IT workloads te transformeren en te optimaliseren op een manier die future proof is.  

Ontdek alle blogs
Lees meer

Schrijf je in en ontvang onze blogs in je mailbox