Att förstå teknisk skuld

Från Wikipedia: “Teknisk skuld (även känd som designskuld eller kodskuld) är “ett begrepp inom programmering som speglar det extra utvecklingsarbete som uppstår när kod som är enkel att implementera på kort sikt används i stället för att tillämpa den bästa övergripande lösningen”.

Teknisk skuld kan jämföras med ekonomisk skuld. Om teknisk skuld inte återbetalas kan den ackumulera ‘ränta’, vilket gör det svårare att genomföra förändringar längre fram. Obeaktad teknisk skuld ökar mjukvaruentropin. Teknisk skuld är inte nödvändigtvis något dåligt, och ibland (t.ex. som ett proof-of-concept) krävs teknisk skuld för att föra projekt framåt. Å andra sidan hävdar vissa experter att metaforen “teknisk skuld” tenderar att förminska konsekvenserna, vilket resulterar i otillräcklig prioritering av det nödvändiga arbetet för att åtgärda den.”

Begreppet teknisk skuld kommer från mjukvaruutvecklingens värld, men det är lika tillämpligt på världen av IT- och affärsinfrastruktur. Precis som inom mjukvaruutveckling designar vi våra system och våra nätverk, och att ta genvägar i våra designer, vilket inkluderar att arbeta med mindre än ideala designer, att införliva befintlig hårdvara och annan dålig designpraxis, ger upphov till teknisk skuld. En av de mer betydande formerna av detta kommer från att investera i det “förflutna” snarare än i “framtiden” och utlöses ofta genom felslutet om förlorade kostnader (även kallat att kasta goda pengar efter dåliga).

Det är lätt att se detta hända i företag varje dag. Nya planer görs upp för framtiden, men innan de implementeras görs investeringar i att få en gammal systemdesign att fortsätta fungera, fungera bättre, expandera eller vad det nu kan vara. Denna investering förvandlas sedan antingen till en nästan omedelbar ekonomisk förlust eller, oftare, blir ett incitament att inte investera i framtidens designer lika snabbt, lika grundligt eller över huvud taget. Investeringen i det förflutna kan bli förlamande i de värsta fallen.

Detta sker på många sätt och är i allmänhet oavsiktligt. Ofta krävs investeringar för att hålla ett befintligt system igång ordentligt och, under normala förhållanden, skulle de helt enkelt göras. Men i en situation där det finns en framtida förändring som behövs eller potentiellt är planerad kan denna investering vara problematisk. Bättre kostnadsanalys och prioriteringsplanering kan dock avhjälpa detta i många fall.

I ett icke-tekniskt exempel, föreställ dig att du äger en äldre bil som har tjänat väl men som ska pensioneras om tre månader. Om tre månader planerar du att investera i en ny bil eftersom den gamla inte längre är kostnadseffektiv på grund av kontinuerliga underhållsbehov, lägre effektivitet och så vidare. Men innan din tremånadersplan att köpa en ny bil infaller drabbas den gamla bilen av ett mindre fel och kräver nu en betydande investering för att hållas igång. Att lägga pengar på den gamla bilen skulle vara en ny investering i den tekniska skulden. I stället för att spendera en stor summa pengar på att få en gammal bil att gå i några månader är det uppenbart drastiskt mycket sundare ekonomiskt att tidigarelägga tidsplanen för att köpa den nya. Med bilar ser vi detta lätt (i de flesta fall). Vi sparar pengar, potentiellt mycket, genom att snabbt köpa en ny bil. Om vi skulle investera tungt i den gamla, förlorar vi antingen den investeringen om några månader eller riskerar att ändra vår solida ekonomiska planering för köpet av en ny bil som redan var beslutad. Båda fallen är dåliga ekonomiskt.

IT fungerar på samma sätt. Att spendera en stor summa pengar på att underhålla ett gammalt e-postsystem sex månader före en planerad migrering till ett hostat e-postsystem skulle sannolikt vara mycket dåraktigt. Investeringen går antingen förlorad nästan omedelbart när det gamla systemet tas ur drift, eller så undergräver den våra goda planeringsprocesser och leder oss till att inte migrera som planerat och göra ett undermåligt jobb för våra företag, eftersom vi lät teknisk skuld styra vårt beslutsfattande snarare än korrekt planering.

Ofta kan en bristfällig prioriteringsverksamhet eller felaktig befogenhet för dem som prioriterar vara den faktor som orsakar akuta investeringar i teknisk skuld snarare än snabba framåtblickande investeringar. Detta är bara ett område där stora förbättringar kan adressera problem, men det är ett betydande sådant. Detta kan också mildras, i vissa fall, genom “tänk om”-planering för att ha investeringsplaner på plats som är beroende av vanliga eller förväntade nödsituationer som kan uppstå, vilket kan vara så enkelt som behov av kapacitetsutökning på grund av tillväxt som inträffar innan systemplaneringen kommer in i bilden.

Ett annat utmärkt exempel på vanlig teknisk skuld är utökning av serverns lagringskapacitet. Detta är ett scenario som jag ser med viss frekvens och som demonstrerar teknisk skuld väl. Det är vanligt att ett företag köper servrar som saknar stor intern lagringskapacitet. Antingen omedelbart eller någon gång längre fram behövs mer kapacitet. Om detta sker omedelbart kan vi se att den inköpta servern var en form av teknisk skuld i form av felaktig design och uppenbart representerar en brist i planerings- och inköpsprocessen.

Men ett vanligare exempel är att behöva utöka lagringen två eller tre år efter att en server har köpts in. Vanliga utökningsval inkluderar att lägga till en extern lagringsenhet att ansluta till servern eller att modifiera servern för att rymma mer lokal lagring. Båda dessa tillvägagångssätt tenderar att vara stora investeringar i en redan gammal server, en server som lätt är fyrtio procent eller mer genom sin användbara livslängd. I många fall kan samma eller endast något högre investering i en helt ny server resultera i ny hårdvara, snabbare CPU:er, mer RAM, den lagring som behövs, ändamålsdesignad och byggd, samordnad och förnyad supportlivslängd, mindre fotavtryck i datacentret, lägre energiförbrukning, nyare tekniker och funktioner, bättre leverantörsrelationer och mer, allt samtidigt som den ursprungliga servern behålls för att återanvändas, pensioneras eller säljas vidare. Det ena sättet spenderar pengar på att stödja det förflutna, det andra kan ofta spendera jämförbara pengar på framtiden.

Teknisk skuld är en förlamande faktor för många företag. Den ökar kostnaden för IT, ibland avsevärt, och kan leda till höga risknivåer genom bristande planering och genom att merparten av utgifterna är nödsituationsbaserade.