Vad är en teknisk skuld och hur skapas den?
Du har säkert hört begreppet ”legacy” slängas runt i tekniska sammanhang. Översätter vi “legacy” till svenska förstår vi att det handlar om ett arv. Här syftar man till ett tekniskt arv som skapas under produktutvecklingsfasen och som ger upphov till en teknisk skuld. Den tekniska skulden uppstår när utvecklare behöver prioritera hastighet över framtidssäkrad kod för att påskynda leveransen. Över tid skapar denna strategi problem givet att inget fokus läggs på att refaktorisera (förbättra) befintlig kod. Detta har att göra med att komplexiteten ökar och stabiliteten minskar i takt med att applikationen förädlas. Den tekniska skulden utgör gapet mellan levererad kvalitet och optimal kvalitet.
Ovan bild illustrerar den lång/kortsiktiga konsekvensen av att fokusera på framtidssäkrad kod.
För knappt ett år sedan ställdes vi på Visma Financial Solutions AB inför ett vägskäl gällande vår tekniska skuld. Ett vägskäl som gav oss 3 alternativ:
- Fortsätta med nuvarande system med odefinierbart mycket legacy som kostar multum att underhålla och som omöjliggör en innovativ teknisk framtid.
- Hitta ett “off-the-shelf” system som tillgodoser våra nuvarande och framtida behov.
- Ta saken i egna händer; samla all intern branschkunskap och tillsätt ett utvecklingsteam 100% dedikerade att parallellt med nuvarande system bygga en helt ny affärsplattform.
Efter en diger förstudie mynnade beslutet ut i att vi vill äga vår framtid vilket endast var möjligt genom att ta saken i egna händer; samla all intern branschkunskap och tillsätt ett utvecklingsteam 100% dedikerade att parallellt med nuvarande system bygga en helt ny affärsplattform. Detta är varför vi idag internt sitter och utvecklar en helt ny affärsplattform som kommer ge oss stora konkurrensfördelar och som fokuserar på att bygga en framtidssäkrad och skalbar produkt. Ett beslut som vi känner oss väldigt priviligerade över att ha haft möjlighet att ta då vi både har den tekniska och branschmässiga kompetensen internt inom bolaget.
Att försumma en teknisk skuld kan blir dyrt
Försumma inte den tekniska skulden, den är reell! Skulden behöver liksom vilken monetär skuld som helst betalas av då den dagligdags skapas räntekostnader om man inte amorterar. Räntekostnaderna utgörs av den utökade tid och således pengar det tar att förädla applikationen som blir mer komplex för varje dag man avstår från att refaktorisera. För att åtgärda detta måste man skapa andrum för utvecklingsteamet att fokusera på att förbättra befintlig kod framför att alltid utveckla nya funktioner.
En anledning till att man på ledningsnivå generellt inte diskuterar teknisk skuld är för att den inte är uppenbar. Teknisk skuld är komplex att förstå sig på, svår att kvantifiera och väldigt abstrakt i sin karaktär. Den är däremot en stor faktor till att tidsplaner inte hålls, delmål i projekt inte uppnås eller att produkten man utvecklar inte når önskad kvalitet.
Ovan tabell illustrerar differensen mellan en finansiell skuld och en teknisk skuld och varför den tekniska skulden är abstrakt
Hitta balans mellan en snabb och hållbar lösning
Det finns kortsiktiga vinster med att leverera en ny produkt utan att lägga fokus på att refaktorisera kod men glöm inte att vinsterna kan ätas upp av kostnader längre fram. I slutänden handlar det om att hitta balans mellan hastighet och hållbarhet. Internt har vi fått stor respekt för den tekniska skulden och dess långsiktiga konsekvenser. Därför har vi också stöd från ledningen att lägga fokus på kvalitet för att inte om 5 år åter målat in oss i ett hörn. Givetvis är det dyrare att skapa kvalitet men vi ser det endast som en initialt kostnad som över tid kommer bespara oss pengar i termer av maintenance för vår produkt.
Vi har inom projektet valt att definiera var vi ligger i den klassiska “projektledningstriangeln” för att tydliggöra för alla vad vi räknar som viktigast och vad som ligger till grund för diverse beslut. Modellen nedan syftar till att illustrera förhållandet mellan kvalitet, tid och kostnad samt att dessa enheter är varandras constraints.
Ovan bild syftar till att illustrera hur vi viktar ovan enheter när vi bygger vår nya affärsplattform.
Fördelarna vi kommer att utvinna när vi är färdiga tangerar både kostnadsbesparing, automation, riskreduktion, prestandaförbättring & ökad intäktspotential ect. Detta kommer inte per automatik med hjälp av ett nytt system utan kräver en organisation som främjar ett nytt arbetssätt som vårt nya affärssystem kommer ge upphov till. Vi behöver också säkerställa att resurser som idag hanterar vårt nuvarande systems tillkortakommanden genom manuellt administrativt jobb arbetar på ett mer proaktivt intäktfokuserat sätt. Att vi inom tech säkerställer att vi mäter hur stor andel utveckling vi lägger på nya features, buggar och refaktorisering för att säkra ett långsiktigt kvalitativt system. Att vi formerar bolaget utifrån vår mjukvara då det är den vi kommer kunna förädla och således kapitalisera på, ett synsätt som blir utmanande, nytt och väldigt kul!
Som en kollega uttryckte det efter att ha förstått vidden av att ta kortsiktiga affärsbeslut i ett stort sofistikerat system: ”En god idé är inte alltid en god idé.”
Skribent
Carl-Johan Molin
Carl-Johan Molin arbetar som Head of Technology på Visma Financial Solutions AB med huvudfokus att driva bolagets tekniska mognad, innovation och SaaS-produkter till nya nivåer. Carl-Johan har sin bakgrund inom produktutveckling och business intelligence, något han starkt brinner för och gärna för en dialog kring! Fritiden spenderas mestadels med att agera clown för sina 6-månaders tvillingar. Kontakt: [email protected]
Nyfiken på en karriär inom Visma?