Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Haastige digitalisering creëert virtuele schuldenberg

Dit artikel delen:

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.

"Zeker voor startende bedrijven is het tijdig binnenhalen van klanten van levensbelang"

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

"En, zoals de bank zou zeggen: geld lenen kost geld"

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.)

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

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..

Dino, het gaat inderdaad om de juiste dingen (in de juiste volgorde) goed doen. Zie ook een interview met Jaap van Rees uit 1994 (http://www.informationdynamics.nl/pwisse/htm/constructieprincipes.htm) waarin Van Rees zegt "De methode doet het nog steeds niet". Van Rees beveelt aan om de nadruk meer op productkwaliteit te leggen en minder op proceskwaliteit.

Jack, de kracht van reclame zit in de beeldspraak want niet alle communicatie is verbaal en een uitgebluste houding zegt al veel. De waarneming van een lijdzaamheid aangaande een starre bureaucratie vraagt cognitieve AI want een goed of fout in de uitvoer lijkt me geen verschil te maken als de uitgangspunten vanaf de tekentafel onjuist zijn.

Haastig digitaliseren met het idee van SOA gaat tenslotte om het 'koppelvlak' met de mens via de transactiemogelijkheden van een web(self) service. Zeven dagen per week en 24 uur per dag open maar toch een personele bezuiniging, wie zegt daar nee tegen?

Academische verwijzingen naar informatiekundige uit een pre-internet tijdperk versus Internet bankieren in het hier en nu lijkt me dan ook een verkeerde weerspiegeling. Want wat zijn de doelen en subdoelen van de gebruiker als we kijken vanuit het perspectief van de klant?

Het intact laten van de silo's heeft uiteindelijk een reden als we kijken naar hedendaagse uitdaging van privacy-by-design, een woord dat vaak voorkomt in oude rapport van WRR over de transitie van e-overheid naar i-overheid. De dagelijkse strijd tussen wat de business wil en wat de klant wil is dan ook een leuke als we kijken naar een transparantie in de algoritmen.

Oudlid, wat betreft de weerspiegeling van doelen en subdoelen hoor je mij verder niets beweren over spiegelneuronen :-)
https://nl.wikipedia.org/wiki/Spiegelneuron
https://www.nemokennislink.nl/publicaties/spiegelneuronen-socialer-dan-gedacht/
Et cetera.

Voor cognitieve AI (in welke vorm ook) loop ik niet warm en wel hierom:
https://dmcommunity.org/2021/01/05/insights-for-ai-from-the-human-mind/

Maar kijk ook even bij de challenges van dit jaar als je toch op deze site bent.

Over het in stand houden van silo’s ben je veel te positief aangezien dit de hoofdoorzaak is van alle ellende die de belastingdienst steeds weer weet te veroorzaken, zoals de beruchte toeslagenaffaire, inclusief de uiterst stroperige afhandeling van de schadeloosstelling van de slachtoffers.

Om nog maar te zwijgen van de mislukte pogingen om het belastingstelsel te moderniseren.

Zolang de zaak niet opnieuw wordt gebouwd onder architectuur (done right) is digitaliseren per definitie een verhogen van de virtuele schuldenberg.

Een oplossing voor de hedendaagse uitdaging van privacy-by-design zou ik zoeken in een adequate information-hiding, en zeker niet in het paardenmiddel van het geïsoleerde, autistische silodenken.

Wat betreft de challenges van dit jaar zie ik een opgave voor 'kamertje verhuren' dus misschien heb je voor je oplossing wat aan:

https://www.deeconometrist.nl/econometrics/kamertje-verhuren/

Aangaande het autistische silo denken in het privacy-by-design probleem kun je niet onthullen wat je niet weet, de onzin van informatie-hiding is als de politieke belofte dat de camerabeelden niet bewaard worden maar ze vervolgens wel bewaard blijken te worden als het om de opsporing van boeren gaat. Nood breekt wet zijn daarmee de ouderwetse silo's met een informatie minimalisatie toch een betere optie als we kijken naar de scope creep van haastige digitalisatie. Oja, met het kamertje verhuren aangaande de toeslagen was er zoiets als maatschappelijke druk om fraudeurs aan te pakken want ouderwets speurwerk leert dat niet iedereen slachtoffer is.

Project Paarse Krokodil van een controle achteraf faalde zoals we ook weer zagen met de onterechte toeslagen voor COVID, want niemand spuugt op gratis geld.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden
Nieuwsbrief

Wil je dagelijks op de hoogte gehouden worden van het laatste ict-nieuws, trends en ontwikkelingen? Abonneer je dan op onze gratis nieuwsbrief.

Vul een geldig e-mailadres in
Vacatures Fintech

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2022-09-28T12:59:00.000Z Julia Krauwer


Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.