Teknisk gæld bliver ofte omtalt, som om det primært er et teknisk problem. Noget udviklerne har lavet, arkitekterne burde have forhindret, eller noget gammelt kode og infrastruktur, som ingen længere helt tør røre ved.
Selvfølgelig findes der teknisk gæld, som ganske enkelt skyldes dårlige tekniske beslutninger. Vi mennesker laver fejl, nogle løsninger bliver designet dårligt, og andre gange vidste vi simpelthen ikke bedre på det tidspunkt, hvor beslutningen blev truffet.
Men meget af den tekniske gæld, jeg har set gennem årene, har en anden oprindelse. Den begynder længe før den dårlige kode, den midlertidige integration eller den server, som stadig står og kører ti år senere. Den begynder ofte med en beslutning om prioritering og en sætning, de fleste mennesker i IT nok har hørt mere end én gang:
“Vi gør det ordentligt senere.”
Det er dér, teknisk gæld meget ofte starter som ledelsesgæld.
Den hurtige løsning er ikke nødvendigvis problemet
Der er ikke noget forkert i at vælge en hurtig løsning. Nogle gange er en midlertidig løsning præcis den rigtige beslutning. Virksomheden kan have brug for at komme hurtigt på markedet, et kritisk problem skal løses nu, eller organisationen har endnu ikke nok information til at designe den langsigtede løsning.
Man kan sagtens træffe en bevidst beslutning om at acceptere teknisk gæld. Problemet opstår først, når den midlertidige løsning bliver permanent, uden at nogen nogensinde tager stilling til det.
Det lille workaround, der skulle holde tre måneder, bliver stadig brugt fire år senere. Den integration, som skulle erstattes “i næste fase”, bliver en kritisk del af virksomhedens platform. Den gamle server får endnu en livsforlængelse, fordi et andet projekt endnu en gang bliver vurderet vigtigere.
På et tidspunkt holder det op med at være en midlertidig teknisk beslutning og bliver i stedet en organisatorisk vane.
“Vi tager det næste kvartal”
De fleste tekniske teams kender sandsynligvis samtalen. Specialisterne siger, at en løsning bør moderniseres. Der er kommet flere workarounds, driften er blevet vanskeligere, og ændringer tager længere tid end tidligere. Ledelsen lytter, og alle er enige om, at det selvfølgelig bør løses.
Men først skal den næste release lige ud. Derefter kommer et vigtigt kundeprojekt, så et regulatorisk krav, en spareøvelse og endnu en strategisk satsning. Pludselig er der gået tre år.
Det interessante er, at ingen nødvendigvis har truffet én stor beslutning om at ignorere den tekniske gæld. Den er vokset gennem hundredvis af små og isoleret set rationelle prioriteringer.
Hver enkelt beslutning gav måske mening på det tidspunkt. Problemet var summen af dem.
Det er netop derfor, jeg mener, at teknisk gæld også er et ledelsesproblem. Nogen skal have ansvaret for at se længere end næste deadline og forstå, hvad der sker, når “ikke lige nu” bliver gentaget tilstrækkeligt mange gange.
Teknisk gæld sender renter
Metaforen med gæld er god, fordi gæld ikke nødvendigvis er dårlig. Virksomheder låner penge hele tiden, fordi det kan være rationelt at bruge ressourcer nu og betale senere. Men ingen ansvarlig økonomidirektør ville betragte gæld som gratis kapital.
Der følger renter med.
Det samme gør der med teknisk gæld, men renterne er sværere at se på resultatopgørelsen. De kommer i form af længere leveringstid, flere fejl, mere manuel drift, vanskeligere integrationer, højere cloud-omkostninger, langsommere onboarding, dårligere sikkerhed og specialister, som bruger mere og mere tid på at forstå gamle løsninger.
Den nye feature, der burde tage to uger, tager pludselig seks, fordi tre gamle systemer skal håndteres først. Den lille ændring kræver regressionstest af et helt landskab, fordi ingen længere helt forstår afhængighederne. Migreringen, som ledelsen troede kunne klares på et halvt år, bliver til et flerårigt program.
Det er renterne på den gæld, organisationen tidligere valgte ikke at betale tilbage.
Og ligesom med økonomisk gæld bliver renterne sjældent mindre af at vente.
Det farlige er, at organisationen vænner sig til det
Teknisk gæld kommer sjældent med en stor rød alarm. I stedet bliver den langsomt normaliseret.
En proces tager fire timer, men sådan har den jo altid fungeret. En deployment kræver tolv manuelle trin, men holdet har skrevet en glimrende vejledning. Kun én medarbejder ved, hvordan en bestemt integration fungerer, men vi kan jo bare spørge ham. Et system kan ikke patches uden risiko for at ødelægge noget andet, så vi lader det være.
På et tidspunkt holder organisationen op med at se gælden som gæld. Den bliver bare en del af måden, man arbejder på.
Det synes jeg er noget af det farligste, fordi dårlig arkitektur på den måde også begynder at påvirke organisationens forventninger til, hvad der overhovedet er muligt. Tre måneders leveringstid opleves pludselig som hurtigt. Store driftsvinduer bliver accepteret. Manuelle processer bliver betragtet som nødvendige.
Og når nogen endelig foreslår at ændre fundamentet, bliver svaret: “Det bliver alt for stort et projekt.”
Det er det muligvis også blevet. Men det er netop en af konsekvenserne af at have ventet.
Arkitekten kan se problemet uden at kunne løse det
Her synes jeg, vi rammer en vigtig forskel mellem teknisk ansvar og organisatorisk ansvar.
En arkitekt kan sagtens identificere teknisk gæld, dokumentere konsekvenserne, foreslå alternativer og beskrive risikoen ved at fortsætte. Men arkitekten kan ikke nødvendigvis beslutte, at virksomheden skal bruge seks måneder og flere millioner kroner på at modernisere platformen.
Det er en prioriteringsbeslutning og dermed også en ledelsesbeslutning.
Derfor bliver det lidt for nemt, når organisationer bagefter spørger: “Hvorfor lod IT det blive så slemt?”
Et mere relevant spørgsmål kunne være: Hvilke beslutninger traf vi år efter år, som gjorde det rationelt for IT at fortsætte sådan?
Hvis alle incitamenter belønner levering nu, mens ingen belønner vedligeholdelse af fundamentet, er resultatet ikke særlig overraskende.
“Forretningen vil have features”
En sætning, jeg har hørt mange gange, er: “Forretningen vil jo have nye features. De vil ikke betale for teknisk oprydning.”
Det kan sagtens være sandt, men så har IT-ledelsen efter min mening også en opgave. Man kan ikke forvente, at resten af forretningen selv kan vurdere konsekvenserne af teknisk gæld.
En salgsdirektør skal ikke nødvendigvis vide, hvad en ti år gammel integration betyder for fremtidig leveringstid. En produktchef kan heller ikke forventes at forstå, hvorfor endnu et workaround øger risikoen i hele platformen. Det er præcis derfor, vi har teknologiledelse.
Hvis IT kun siger: “Vi vil gerne refaktorere noget”, mens forretningen siger: “Vi kan få 20 procent mere omsætning med denne feature”, så taber den tekniske oprydning selvfølgelig.
Teknisk gæld skal derfor oversættes til forretningsmæssige konsekvenser. Hvad koster den i leveringstid? Hvor stor risiko skaber den? Hvilke fremtidige muligheder blokerer den? Hvor meget ekstra drift kræver den? Hvornår bliver gælden så stor, at nye initiativer bliver mærkbart dyrere?
Det er dér, samtalen bliver strategisk.
Teknisk gæld bør stå på risikoregistret
Jeg synes ofte, organisationer behandler teknisk gæld for uformelt. Der findes måske en backlog med 300 tekniske forbedringer, som kun IT selv kigger på.
Men hvis en konkret teknisk gældspost potentielt kan stoppe vækst, skabe alvorlige sikkerhedsproblemer eller gøre en kritisk platform næsten umulig at ændre, er det ikke længere bare et teknisk backlog-item.
Så er det en forretningsrisiko.
Ledelsen behøver ikke forstå alle tekniske detaljer, men den skal forstå konsekvensen ved ikke at handle. Bestyrelsen behøver heller ikke forstå præcis, hvordan ransomware virker for at tage cyberrisiko alvorligt. På samme måde behøver direktionen ikke kunne læse kildekoden for at forstå, at en central platform er blevet så skrøbelig, at virksomhedens strategiske handlefrihed bliver reduceret.
Når teknisk gæld når det niveau, hører diskussionen hjemme i ledergruppen og ikke kun i arkitekturrummet.
Deadline-kulturen skaber ofte gælden
Der findes organisationer, hvor næsten alle projekter starter med en urealistisk deadline. Man spørger ikke: “Hvor lang tid tager det at løse ordentligt?” Man siger i stedet: “Vi skal være live 1. november” og forsøger derefter at få virkeligheden til at passe til datoen.
Når tiden bliver knap, bliver kvaliteten ofte den fleksible variabel. Test reduceres, dokumentation udskydes, arkitekturforbedringer fjernes, automatisering kommer “senere”, og den midlertidige løsning bliver valgt.
Det kan være nødvendigt en enkelt gang. Problemet opstår, når organisationen arbejder sådan konstant.
Så har man ikke længere et teknisk problem. Man har en ledelsesmodel, der systematisk producerer teknisk gæld.
I sådan en organisation hjælper det ikke ret meget at bede udviklerne om at “arbejde mere langsigtet”, for systemet omkring dem belønner det modsatte.
Roadmaps viser ofte kun det nye
Der er også noget interessant ved den måde, vi planlægger på. Roadmaps er typisk fulde af nye produkter, funktioner, markeder, platforme og AI-initiativer. Det eksisterende fundament får sjældent samme visuelle opmærksomhed.
Men der findes ingen naturlov, som siger, at al kapacitet skal bruges på at bygge nyt.
Hvis en organisation konstant bruger 100 procent af sin kapacitet på nye initiativer, bør den heller ikke blive overrasket over, at vedligeholdelse og modernisering aldrig sker.
Det minder lidt om at eje et hus og bruge alle pengene på nye møbler, mens taget langsomt bliver mere og mere utæt. På et tidspunkt er det ikke længere særligt vigtigt, hvilken sofa man har lyst til at købe.
Ikke al teknisk gæld skal betales
Det er også vigtigt ikke at gøre teknisk gæld til noget moralsk, hvor gammel teknologi automatisk er dårlig teknologi.
Der findes løsninger, som aldrig behøver blive perfekte. Et system kan være gammelt og grimt, men stadig fungere glimrende og være billigt at drive. Hvis det skal udfases om to år, kan en større modernisering være spild af penge.
Derfor synes jeg heller ikke, målet bør være “zero technical debt”. Det ville både være dyrt og naivt.
Målet bør i stedet være at vide, hvilken gæld man har, hvorfor man har accepteret den, hvilke renter man betaler, og hvornår den eventuelt bør afvikles.
Teknisk gæld bliver først rigtig farlig, når den er ukendt, ubevidst eller konsekvent ignoreret.
CTO’en skal kunne beskytte fundamentet
Her mener jeg, at CTO’en eller IT-ledelsen har et særligt ansvar. Ikke for at sige nej til alle deadlines eller kræve perfekte løsninger, men for at beskytte organisationens langsigtede teknologiske handlefrihed.
Det kan betyde, at man nogle gange skal være den upopulære person i rummet og sige: “Ja, vi kan godt levere det på tre måneder, men så påtager vi os en gæld, som vi skal betale næste år.” Eller: “Vi kan godt bygge endnu en integration oven på den gamle platform, men så bliver den kommende migrering tilsvarende dyrere.”
Ledelse handler ikke kun om at gøre det muligt at levere hurtigt nu. Det handler også om at sikre, at organisationen stadig kan levere hurtigt om tre år.
Det er en væsentlig forskel.
Teknisk gæld er akkumulerede beslutninger
Når man møder en organisation med meget teknisk gæld, er det fristende at kigge på systemlandskabet og spørge: “Hvordan kunne nogen designe det sådan?”
Men ofte er det det forkerte spørgsmål, for ingen designede nødvendigvis det nuværende landskab som helhed.
Det voksede frem gennem én midlertidig integration, én udsat opgradering, én deadline, én fusion, én spareøvelse, én undtagelse fra standarden og endnu en beslutning om at tage problemet næste år.
Hver enkelt beslutning kan have været rationel på det tidspunkt. Det er summen, der med tiden bliver irrationel.
Derfor er teknisk gæld efter min mening ofte bedst forstået som historien om organisationens tidligere prioriteringer.
Arkitekturen husker de beslutninger, organisationen har glemt.
Teknisk gæld fortæller noget om kulturen
Et systemlandskab fortæller også noget om den organisation, der har skabt det.
Hvis næsten alt er specialbygget, kan det være tegn på en kultur, hvor lokale behov konsekvent vandt over standardisering. Hvis ingen systemer bliver udfaset, kan organisationen have svært ved at sige farvel til gamle løsninger. Hvis alt er ekstremt centralt kontrolleret, kan det afspejle en organisation med lav autonomi.
Og hvis der findes hundredvis af midlertidige workarounds, kan det meget vel være resultatet af mange års deadline-drevet ledelse.
Arkitektur er derfor ikke kun teknologi. Den er også et aftryk af organisationens beslutninger, incitamenter og kultur.
Det synes jeg er værd at huske, når vi taler om teknisk gæld.
Gæld skal være et bevidst valg
Jeg tror ikke, vi kan undgå teknisk gæld, og det bør vi heller ikke nødvendigvis forsøge.
Nogle gange er det fuldstændig rationelt at låne fra fremtiden for at skabe værdi nu. Men så skal vi vide, at vi gør det. Vi skal vide, hvad vi låner, hvorfor vi gør det, hvilke renter vi forventer at betale, og hvornår vi planlægger at gøre noget ved det.
Hvis organisationen konsekvent siger “senere” uden at definere, hvornår senere er, så er det ikke længere en strategi. Det er bare udsættelse.
Efter tilstrækkelig lang tid bliver regningen desuden sendt videre til mennesker, som måske slet ikke var med til at træffe de oprindelige beslutninger: det nye udviklingsteam, den næste arkitekt eller den næste CTO.
Teknisk gæld starter ofte længe før teknikken
Når vi står med gamle systemer, besværlige integrationer og platforme, som er blevet dyre at ændre, er det nemt at pege på teknologien. Men teknologien har sjældent selv besluttet, at moderniseringen kunne vente.
Serveren sagde ikke: “Lad os tage det næste kvartal.” Arkitekturen besluttede heller ikke at prioritere endnu en feature frem for oprydningen.
Det gjorde mennesker.
Derfor synes jeg, at teknisk gæld skal diskuteres i ledergruppen mindst lige så meget som i arkitekturrummet. For nogle af de vigtigste årsager til teknisk gæld findes ikke i kildekoden. De findes i prioriteringerne, incitamenterne og beslutningerne omkring den.
Teknisk gæld starter ofte som ledelsesgæld. Og hvis ledelsen ikke er med til at betale den tilbage, ender IT med at betale renterne alene.