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.