It-projecten die onder hoge tijdsdruk worden opgeleverd, vereisen in een latere fase juist een grotere tijdsinvestering. Deze onzichtbare schuldenberg van organisaties, ook wel ‘technical debt’ genoemd, is door de rappe digitalisering tijdens de coronapandemie enkel gegroeid.
Een bank is een it-bedrijf. Andersom: een it-manager is net een bankier. Waar die laatste zicht houdt op het risico dat een lening niet wordt terugbetaald, is het voor it-managers zaak de digitale schuldenberg niet te ver te laten oplopen. Deze zogenaamde ‘technical debt’ is het resultaat van snel opgeleverde it-oplossingen, waarbij bewust is gekozen voor functionaliteit in het hier en nu ten koste van onderhoudbaarheid, schaalbaarheid en aanpasbaarheid op de langere termijn.
De tijd die aanvankelijk wordt bespaard door suboptimaal geschreven code, moet in veel gevallen in een latere fase alsnog worden geïnvesteerd om de programmatuur naar het gewenste kwaliteitsniveau te tillen. Wacht de organisatie hier te lang mee, dan betaalt het ontwikkelteam daarvoor de prijs. Zo wordt het toevoegen van nieuwe functionaliteit stukken lastiger en tijdrovender als er eerder in het ontwikkelproces voor de kortste route is gekozen. De vertraging die dit veroorzaakt verhindert dat de benodigde capaciteit niet wordt ingezet voor het maken van nieuwe functionaliteiten en proposities. Waardecreatie op de lange termijn wordt daardoor bemoeilijkt.
Technical debt kan cybercriminelen in de hand spelen. Zo kan een ontwikkelteam er uit tijdnood voor kiezen om updates aan software-componenten uit te stellen, waardoor kwetsbaarheden blijven bestaan. En laat de onderneming na om in een vroege fase veiligheidstests uit te voeren, dan is de kans groot dat de code in een later stadium alsnog op de schop moet om de securityproblemen op te lossen.
Toch is technical debt niet per definitie slecht. Het kan het resultaat zijn van een bewuste keuze om snel de markt op te gaan met een softwareproduct; zeker voor startende bedrijven is het tijdig binnenhalen van klanten van levensbelang. Ook klantbehoud speelt mee. Nieuwe productfunctionaliteiten voorzien in veranderende behoeften en houden gebruikers betrokken. Technical debt kan daarnaast zijn ingegeven door wet- en regelgeving die rap moet worden geïmplementeerd, of problemen met cyberveiligheid die snelle actie vereisen.
Coronapandemie
Helaas is de noodzaak voor het aangaan van een technische schuld tijdens de coronapandemie over de gehele linie nog eens sterk toegenomen. Bedrijven zagen zich gedwongen om in korte tijd it-oplossingen neer te zetten om klanten digitaal te bedienen en thuiswerken te faciliteren. Kwalitatief hoogstaande softwarecode en -architectuur was simpelweg geen prioriteit. Een recent rapport van softwarebedrijf Software AG laat zien dat meer dan driekwart van de ondernemingen in 2021 meer technical debt heeft opgebouwd dan in de jaren ervoor.
Dat is kwalijk, aangezien organisaties al in 2020 tussen de 20 en 40 procent van hun ontwikkelkosten besteedden aan het aflossen van technical debt, zo blijkt uit onderzoek van McKinsey. Bij het gros (69 procent) van de ondervraagde bedrijven gaat minimaal tien procent van het budget voor nieuwe projecten naar extra werk dat is veroorzaakt door diezelfde schuld, ofwel de rente. Daarmee spendeert de gemiddelde it-ontwikkelaar ongeveer een derde van zijn werkweek aan het wegwerken van- en omgaan met technical debt. Dat is overigens nog los van de halve dag die opgaat aan ‘bad code’; softwarecode waarvan de slechte kwaliteit niet te herleiden is tot een strategische afweging tussen opleveringssnelheid en kwaliteit.
Spanning op de arbeidsmarkt gooit olie op het vuur. De grote hoeveelheid it-vacatures in verhouding tot een beperkt aantal passende kandidaten betekent dat bedrijven het veelal moeten rooien met minder it’ers dan zij zouden willen. Een gebrek aan ontwikkelcapaciteit kan leiden tot het nemen van ‘shortcuts’, met toename van technical debt als resultaat. Kiest een organisatie er juist voor haar digitale schuldenberg weg te werken, dan gaat dat veelal ten koste van zichtbare verbeteringen voor zowel de klanten als het werkplezier van de it’ers in kwestie. Weglopende klanten en werknemers vormen eveneens een bedreiging voor de bedrijfscontinuïteit.
Oren
Kort gezegd, een combinatie van factoren waar niet alleen de it-manager en cio, maar ook de ceo en cfo zich stevig van achter de oren zullen krabben. Gelukkig kunnen zij met de juiste ingrepen de risico’s van technical debt beheersen. Het ontwikkelteam doet er bijvoorbeeld goed aan om elke shortcut te documenteren, de nadien verwachte hersteltijd in te schatten en te prioriteren. Openheid hierover naar de rest van de organisatie en ontvankelijkheid vanuit die organisatie is essentieel. Zo is de feitelijke ruimte voor nieuwe projecten helder en kan realiteitszin bij het stellen van deadlines de opbouw van nieuwe technische schulden verminderen.
En, zoals de bank zou zeggen: geld lenen kost geld. Ook technical debt is niet gratis – zowel het gecontroleerd inzetten als de regelmatige aflossing ervan zal elke organisatie op de lange termijn bestendiger maken.
(Auteur Julia Krauwer is sector banker technologie, media & telecom bij ABN Amro.)
De eerste verschijnselen van deze “technical debt” heb ik al een aantal jaren voor corona gezien, met name bij projecten die op een Agile manier gingen werken.
De filosofie leek vaak te zijn “alles voor de sprint-demo”, waardoor er nogal wat oplossingen gekozen werden die verre van toekomstbestendig waren
Neem daarbij scrummasters die geen “nee” durven zeggen naar opdrachtgevers / stuurgroepen, productowners die nieuwe features (sexy) leuker vinden dan het oplossen van technical debt (saai) en stuurgroepen die hun geld liever uitgeven aan verkoopbare features dan aan onderhoud/verbetering dan is er al snel een begin gemaakt met de basis van de technische schuldenberg …..
Pa Va Ke, je hebt gelijk. De “technical debt” komt al decennia voor. Ook vroeger zag je vaak een slechte verdeling van verantwoordelijkheden, gebrek aan visie en onlogische prioriteiten, met als gevolg commitment problemen en chaotische uitruil van invloed op de ontwikkeling en slechte documentatie. De haastige spoed bij sommige bedrijven tijdens de lock down en de huidige “versnelling” van de digitalisering, heeft dit een beetje erger gemaakt.
IT managers, stuurgroepen ? Blijkbaar stuurt het team toch niet zo zelf. Wat ze nog wel mogen: “elke shortcut te documenteren, de nadien verwachte hersteltijd in te schatten en te prioriteren.” of “om updates aan software-componenten uit te stellen, waardoor kwetsbaarheden blijven bestaan”. De T shaped devsops talenten en de innovatie 🙂
Cyberveiligheid, waardecreatie enzo. Handig zijn met taal is een must. Noem de met de agile geproduceerde en in stand gehouden schuldenberg bijvoorbeeld meteen legacy. Waarom ook niet. Dat is het tenslotte ook. Legacy by design of juist door gebrek aan design. Dan mag je weer een nieuwe berg starten.
Wat was haastige spoed ook alweer : zelden goed.
hoe was alles vroeger : beter
Je kan hem nog platter slaan door het eens uit de IT-wereld te halen.
Snelwegje aanleggen
Neem het aanleggen van een snelweg. Daar zie je dat ook in een wat ander context.
De duimregel daar is dat de kosten voor het aanleggen van een snelweg x 2 moet, om hem de komende 50 jaar te kunnen gebruiken. Dus als een snelweg 5 miljard kost, dan heb je nog eens 5 miljard nodig om de komende 50 jaar te kunnen gebruiken.
Dat is natuurlijk iets anders dan een in de haast aangelegde snelweg, waarbij de onderhoudskosten uit het lood geslagen zijn, en wellicht 5x duurder is dan de oorspronkelijk begrote snelweg van 3 miljard, dat resulteert in de totale kosten van 15 miljard en dus 5 miljard duurder dan de meer realistische totale begroting. Die 3 miljard leek nog zo’n koopje.
Hoe dan ook, welke berekeningen je ook maakt, het probleem zit hem wat mij betreft niet daarin, maar wat enigszins door de commentaren wordt gesuggereerd. Het heeft met professioneel opdrachtgeverschap te maken en daar ontbreekt vaak heel erg aan.
Het gaat niet alleen om professioneel opdrachtgeverschap, ook om professioneel opdrachtnemerschap. In veel gevallen gaan die hand in hand, en inderdaad, niet alleen in de ICT.
Ik roep al jaren dat SOA een ziekte is want is de ‘tech-debt’ niet gewoon het gevolg van een digitaal optimisme als we kijken naar de vluchtige relatie van de business met de realiteit?
En nee, vroeger was niet alles beter Dino want juist de ABN had ooit zoiets als de pijplijn van snelle veranderingen in een behoudend landschap. En netwerkbank redde het niet zonder hulp van de staat want beloofde gouden bergen bleken diepe dalen. Niet in de laatste plaats door een zeer hoge OpEx op verouderde code waar als ik me niet vergis vooral IBM van profiteert.
Geld lenen kost alleen geld als de rente hoger is dan het rendement, met een negatieve rente op een spaartegoed kun je beter investeren in winstgevende projecten. Een technologische schuld kan heel rendabel zijn als we kijken naar het verlies van verkeerde keuzen. Want weglopende klanten hadden we een paar jaar geleden doordat andere spelers een hogere rente op het geplaatste kapitaal boden.
Oudlid, het blijft voor mij een gotspe: SOA met allerlei vormen van proces- en systeemdenken verprutsen en vervolgens roepen dat SOA niet werkt.
Het niet van de grond komen van SOA is juist de hoofdoorzaak van de virtuele schuldenberg (ander woord voor legacy).
Jack, het SOA paradigma gaat vanuit het blikveld van de gebruiker om (online) loketten. Wat er achter het loket gebeurt is door alle abstracties niet meer interessant. SOA paradigma lijkt me daardoor debet aan de legacy doordat er een horizontale laag (ESB?) over vertikale silo’s gelegd werd. Want achterliggende processen en systemen bleven onveranderlijk terwijl er door een abstractie er steeds minder kennis over was:
https://www.youtube.com/watch?v=mJipJwDPJ-g
Ik verwijs naar de Paarse Krokodil omdat we nog altijd dezelfde starheid in processen hebben ondanks een digitaal loket.
Je geeft hier weer een mooi voorbeeld van een SOA done wrong: een SOA die de oorspronkelijke silos intact laat en daarmee inderdaad debet is aan legacy.
Zou een SOA done right niet een weerspiegeling dienen te zijn van de doelen en subdoelen van de gebruiker?
Inderdaad een ijzersterke commercial van ORHA uit 2004!
https://nl.wikipedia.org/wiki/Paarse_krokodil
“De methode doet het niet” door Jaap van Rees, uit 1982, maandblad informatie. Een klassieker.
Om een of andere reden schijnt de auteur het artikel bewust onvindbaar gemaakt te hebben en nog geen online copie gevonden.
Komt er op neer dat eigenlijk alles done right iets goeds oplevert en done wrong niet.
Geldt ook voor reclames, agile ook : simple to understand and difficult to master
Ach ja vroeger..