Forstå teknisk gjeld

Fra Wikipedia: “Teknisk gjeld (også kjent som designgjeld eller kodegjeld) er “et konsept innen programmering som gjenspeiler det ekstra utviklingsarbeidet som oppstår når kode som er enkel å implementere på kort sikt brukes i stedet for å anvende den beste overordnede løsningen”.

Teknisk gjeld kan sammenlignes med monetær gjeld. Hvis teknisk gjeld ikke tilbakebetales, kan den akkumulere ‘renter’, noe som gjør det vanskeligere å implementere endringer senere. Uadressert teknisk gjeld øker programvareentropi. Teknisk gjeld er ikke nødvendigvis negativt, og noen ganger (for eksempel som et proof-of-concept) er teknisk gjeld nødvendig for å drive prosjekter fremover. På den annen side hevder noen eksperter at «teknisk gjeld»-metaforen tenderer til å minimere konsekvensene, noe som resulterer i utilstrekkelig prioritering av det nødvendige arbeidet for å korrigere det.”

Konseptet teknisk gjeld kommer fra programvareteknikkverdenen, men gjelder i like stor grad for IT og forretningsinfrastruktur. Som i programvareteknikk designer vi systemene og nettverkene våre, og å ta snarveier i designene – noe som inkluderer å arbeide med mindre enn ideelle design, innlemme eksisterende maskinvare og andre dårlige designpraksiser – produserer teknisk gjeld. En av de mer betydelige formene for dette stammer fra å investere i «fortiden» snarere enn i «fremtiden», og utløses ganske ofte gjennom den nedlagte kostnadens feilslutning (også kjent som å kaste gode penger etter dårlige.)

Det er lett å se dette skje i bedrifter hver dag. Nye planer legges for fremtiden, men før de implementeres gjøres det investeringer for å få et gammelt systemdesign til å fortsette å fungere, fungere bedre, utvides eller lignende. Denne investeringen blir da enten et nesten umiddelbart økonomisk tap eller, oftere, et insentiv til ikke å investere i fremtidsdesignene like raskt, like grundig eller muligens ikke i det hele tatt. Investering i fortiden kan bli lammende i de verste tilfellene.

Dette skjer på mange måter og er generelt utilsiktet. Ofte er investeringer nødvendige for å holde et eksisterende system i gang ordentlig og ville under normale omstendigheter simpelthen bli gjort. Men i en situasjon der det er en fremtidig endring som er nødvendig eller potensielt planlagt, kan denne investeringen være problematisk. Bedre kostnadsanalyse og triageplanlegging kan avhjelpe dette i mange tilfeller.

I et ikke-teknisk eksempel: tenk deg å eie en eldre bil som har tjent godt men som er klar for pensjonering om tre måneder. Om tre måneder planlegger du å investere i en ny bil fordi den gamle ikke lenger er kostnadseffektiv på grunn av kontinuerlige vedlikeholdsbehov, lavere effektivitet og så videre. Men før din tre-månedersplan om å kjøpe en ny bil inntreffer, lider den gamle bilen en mindre feil og krever nå en betydelig investering for å holdes i gang. Å putte penger i den gamle bilen ville være en ny investering i teknisk gjeld. I stedet for å bruke en stor sum penger på å få en gammel bil til å gå noen måneder, er det åpenbart langt mer fornuftig å fremskynde tidspunktet for kjøp av den nye. Med biler ser vi dette lett (i de fleste tilfeller.) Vi sparer penger, potensielt mye, ved raskt å kjøpe en ny bil. Hvis vi skulle investere tungt i den gamle, taper vi enten den investeringen om noen måneder, eller vi risikerer å endre vår solide økonomiske planlegging for kjøp av en ny bil som allerede var gjort. Begge tilfeller er dårlige økonomisk.

IT fungerer på samme måte. Å bruke en stor sum penger på å vedlikeholde et gammelt e-postsystem seks måneder før en planlagt migrasjon til et hostet e-postsystem ville sannsynligvis være svært uklokt. Investeringen går enten nesten umiddelbart tapt når det gamle systemet tas ut av drift, eller den undergraver våre gode planleggingsprosesser og fører til at vi ikke migrerer som planlagt, og gjør en dårlig jobb for virksomhetene våre fordi vi lot teknisk gjeld styre beslutningstakingen vår i stedet for ordentlig planlegging.

Ofte kan en dårlig triageoperasjon eller utilstrekkelig myndighet til triagespillere være faktoren som forårsaker nødinvesteringer i teknisk gjeld i stedet for raske fremtidsrettede investeringer. Dette er bare ett område der store forbedringer kan løse problemer, men det er et viktig ett. Dette kan også dempes, i noen tilfeller, gjennom «hva-hvis»-planlegging for å ha investeringsplaner klare betinget på vanlige eller forventede nødssituasjoner som kan oppstå, noe som kan være så enkelt som kapasitetsutvidelsebehov på grunn av vekst som skjer før systemplanlegging kommer inn i bildet.

Et annet godt eksempel på vanlig teknisk gjeld er utvidelse av serverlagringskapasitet. Dette er et scenario jeg ser med en viss hyppighet og som illustrerer teknisk gjeld godt. Det er vanlig at et selskap kjøper servere som mangler stor intern lagringskapasitet. Enten umiddelbart eller litt ned i veien trengs mer kapasitet. Hvis dette skjer umiddelbart kan vi se at serveren som ble kjøpt var en form for teknisk gjeld i feil design og representerer åpenbart en svikt i planleggings- og innkjøpsprosessen.

Men et mer vanlig eksempel er å trenge å utvide lagringen to eller tre år etter at en server er kjøpt. Vanlige utvidelsesalternativer inkluderer å legge til et eksternt lagringsarray som kobles til serveren, eller å modifisere serveren for å ta imot mer lokal lagring. Begge disse tilnærmingene tenderer til å være store investeringer i en allerede gammel server – en server som lett er førti prosent eller mer gjennom sin nyttige levetid. I mange tilfeller kan den samme eller bare litt høyere investeringen i en helt ny server resultere i ny maskinvare, raskere CPU-er, mer RAM, den nødvendige lagringen, formålsdesignet og -bygget, justert og fornyet støtteperiode, mindre datasenteravtrykk, lavere strømforbruk, nyere teknologier og funksjoner, bedre leverandørrelasjoner og mer – alt mens den originale serveren beholdes for gjenbruk, pensjonering eller videresalg. Den ene måten bruker penger på å støtte fortiden, den andre kan ofte bruke sammenlignbare penger på fremtiden.

Teknisk gjeld er en lammende faktor for mange bedrifter. Det øker IT-kostnadene, noen ganger betydelig, og kan føre til høye risikonivåer gjennom mangel på planlegging der det meste av forbruket er nødbasert.