Teknisk gæld og legacy bliver ofte brugt i flæng og med rigtig god grund – for har organisationen det ene, har de med stor sandsynlighed også det andet. Lær at navigere i ‘legacy’ og ‘teknisk gæld’: Vi forklarer forskellene, lighederne og fordelene og ulemperne ved at se dem som det samme.
Hvad er teknisk gæld (kort fortalt)?
Teknisk gæld er når man benytter genveje frem for den ‘rigtige’ løsning. Genvejen er hurtig på kort sigt, men på længere sigt kan den lamme it-systemet (og it-porteføljen), hvis det ikke bliver håndteret. Der findes mange definitioner, og Nine opfordrer til, at I selv finder den definition, der passer bedst til jeres situation. Teknisk gæld er nuanceret yderligere i dette blogindlæg.
Alle it-systemer og it-porteføljer har teknisk gæld, eftersom det er et vilkår for it-udvikling. Teknisk gæld opstår løbende, derfor bør målet være, at organisationen har en løbende håndteringsstrategi af sin tekniske gæld. En fuldstændig afbetaling er oftest urealistisk, da teknisk gæld hurtigt opstår. Derfor kan gevinsten af en fuld afbetaling på al teknisk gæld være svær og meget dyr at realisere.
Hvad er legacy?
Ligesom ved teknisk gæld findes der flere definitioner på legacy. Fælles for definitionerne er at legacy bliver beskrevet som software, der er:
- Forældet og gammelt (alle systemer bliver med tiden legacy)
- Kritisk, men skrøbeligt, dyrt at vedligeholde og svær at lave ændringer til
- Typisk bliver det forbundet med mainframe-baserede systemer (f.eks. COBOL). Men moderne software udviklet vha. nye teknikker kan også klassificeres som legacy
- Systemerne er forretningskritiske og derfor tolereres vedligeholdelsesomkostningerne
Altså beskrives legacy systemer som sårbare, forældede og forretningskritiske systemer, der er vanskelige at videreudvikle samt udskifte. Legacy er et vilkår i it-udvikling, det opstår af sig selv og med tiden vil alle systemer blive legacy. Der er adskillige risici forbundet med legacy systemer, der bør mitigeres og håndteres. Herunder at det typisk er svært at bemande legacy systemer, grundet kompleksiteten og den forældede teknologi som kun få kan arbejde i (og de er oftest tæt på pensionsalderen). Legacy systemer forhindrer god it-sikkerhed, hvilket udgør en betydelig risiko, især fordi systemerne er forretningskritiske. I takt med en generelt øget opmærksomhed på it-sikkerhed er fokus på og håndtering af legacy kun blevet mere nødvendig.
Teknisk gæld vs Legacy
Der er adskillige ligheder mellem teknisk gæld og legacy:
- De diskuterer begge software tilstanden, som ikke er optimal
- De giver en forklaring på en reduktion af organisationens effektivitet
- Symptomerne ligner hinanden, og derfor kan det være svært at afgøre om noget er legacy eller teknisk gæld. Konsekvenser de har til fælles er bl.a. ineffektivitet, lamme it-systemer, udgøre et betydelig sikkerhedsrisiko (bagud på opgraderinger, mangel på overvågning etc.)
Teknisk gæld og legacy påvirker hinanden og legacy øger risikoen for at teknisk gæld opstår.
Teknisk gæld optræder tydeligt, når der skal bygges nyt, hvor udviklerne af forskellige grunde tager en genvej, når de løser opgaverne. Dette besværliggør den fremadrettede udvikling. Der er flere faktorer, der spiller ind på, hvorfor udviklerne vælger genvejene, særligt de organisatoriske aspekter har en stor indflydelse. Eksempelvis, kan det være organisationen vælger at optage teknisk gæld for at nå en specifik deadline.
Legacy optræder tydeligt i eksisterende systemer, som formentligt fungerede fint, da de blev bygget. De kræver dog løbende vedligehold og opdateringer i takt med teknologien og omverden ændrer sig, fordi teknologi bliver forældet. Selv hvis man udfører løbende vedligehold er der altid en vis risiko involveret, og på et tidspunkt er det mere omfattende og dyrere at opdatere det gamle end at bygge forfra. Grundene til at man alligevel bibeholder det gamle kan være at det er svært, uoverskueligt og omkostningstungt at bygge nyt.
Hvad er fordelen ved at slå de to begreber sammen?
Der kan være forskellige årsager til at man vælger at slå teknisk gæld og legacy begreberne sammen. De tre typiske årsager:
Prioritering
Begge begreber rummer essentielle udfordringer for it-organisationer. Organisationskultur, tidligere erfaringer og organisationens fokus er medvirkende til at det ene begreb bliver nemmere prioriteret end det andet. Teknisk gæld har haft stor gennemslagskraft, hvilket har gjort nogen ‘rebrander’ legacy som teknisk gæld for legacy opgaver bliver prioriteret. Nu har legacy fået medvind i takt med det øget fokus på it-sikkerhed. Dermed kan teknisk gæld-opgaver nemmere blive prioriteret, hvis de ‘rebrandes’ som legacy.
Strategisk handling
På det strategiske niveau kan det give mening at behandle legacy og teknisk gæld samlet. Eksempelvis, hvis man ønsker at udarbejde en strategi eller proces for håndtering af legacy, vil det være mest hensigtsmæssigt også at inddrage den løbende håndtering af teknisk gæld og legacy.
Kommunikation
Ved at nøjes med at bruge et begreb kan man forsimple kommunikationen til mindre tekniske personer, der ikke har brug for at kende detaljerne. Dertil er det ikke altid nødvendigt at skelne om en konkret uhensigtsmæssighed skyldes legacy eller teknisk gæld.
Så hvorfor giver det mening at skelne mellem begreberne?
Selvom der er fordele ved at samle teknisk gæld og legacy under en paraply, så er der også fordele ved at skelne mellem de to begreber.
Negligering af viden
Legacy har eksisteret i længere tid, som begreb sammenlignet med teknisk gæld, derfor hvis legacy rebrandes som teknisk gæld, risikerer man at negligere den viden, man allerede har opbygget om håndtering af legacy.
Nuancering styrker ‘business casen’
Nuancering af udfordringerne, altså om det er legacy eller en specifik teknisk gæld, er vigtig for at kunne danne sig et overblik. Når man har identificeret de gennemgående udfordringer, kan man bedre overskue konsekvenserne, de nødvendige tiltag og de potentielle gevinster. Dette vil også understøtte ‘business casen’ til at få de fornødne ressourcer og prioriteringer.
Teknisk gæld og legacy er to forskellige begreber, der er nært beslægtede. Teknisk gæld kan kategoriseres på forskellige måder, hvilket du kan læse mere om i dette blogindlæg. I det næste blogindlæg dykker vi ned i legacy-problematikken ved at identificere de typiske årsager, karakteristika og konsekvenser ved legacy, så du kan pinpointe din organisations konkrete udfordringer.
Kilder
- Magnusson, J., Juiz, C., Gómez, B., & Bermejo, B. (2018, May). Governing technology debt: beyond technical debt. In Proceedings of the 2018 International Conference on Technical Debt (pp. 76-84).
Har du spørgsmål – eller bare lyst til en snak?
Mille Kjærsgaard Hansen
Senior Consultant
Mille har en Ph.d. i styring af teknisk gæld i den offentlige sektor og specialiserer sig i at analysere komplekse problemstillinger, omsætte dem til konkrete udfordringer og finde gode løsninger.
Hun deler glædeligt ud af sin viden om tekgisk gæld og legacy både gennem blogposts, oplæg og workshops. Derudover formidler hun sin viden på alle niveauer og relevante områder i organisanisationen.
mkh@nine.dk
+45 60 58 88 03
Har du spørgsmål – eller bare lyst til en snak?
Casper Lund Junge
Direktør
Casper har speciale i digital transformation. Han har flere års erfarfing i at bistå virksomheder med at finde vej i det digitale landskab – altid med en god balance mellem strategi og teknologi.
Han har en stærk baggrund i både rådgivning og salg og står i dag i spidsen for én af Nines fem forretningsenheder. Her driver han forandringer, der gør en forskel for kunderne – og han brænder for at skabe løsninger, der virker i praksis.
clj@nine.dk
+45 30 93 49 31