Systemet er legacy - og hvad betyder det? 

Legacy systemer er sårbare, forældede og forretningskritiske systemer, der er vanskelige at videreudvikle samt udskifte. Det kan være svært at konkretisere, hvad der er den egentlige udfordring, handlemulighederne og gevinsterne heraf. Oftest virker det som om at hele systemet er utilstrækkeligt og bør ændres, en opgave, som for de fleste, kan virke uoverskuelig og det kan være svært at få den nødvendige opbakning fra ledelsen. Det skyldes, mangel på nuanceringer og at legacy definitioner ofte er brede og blander forskellige elementer sammen: årsager, karakteristika og konsekvenser. Dermed er business casen svær at gennemskue og italesætte.

Hvordan får man ledelsen til at interessere sig for legacy? 

Legacy forhindrer strategiske mål. Virksomheders visioner kan blive forhindret af en legacy barriere, der besværliggør, og nogle gange umuliggør, realisering af virksomhedens strategier. Fordi legacy systemer gør det svært for virksomheder at levere brugervenlige systemer, supportere eller overholde lovgivning og compliance (herunder GDPR og ISO27001). Ydermere, vanskeliggør de gevinstrealiseringen ved at være datadrevet og implementere nye teknologier. Der er også en økonomisk gevinst i at nye teknologier bruger meget færre ressourcer i datacenteret. For eksempel er en simpel opgradering fra Java 8 til Java 17 i gennemsnit en besparelse i omegnen af 40% på kapacitet. 

Derudover følger legacy systemer sjældent bedste praksis inden for it-sikkerhed, og de indeholder ofte komponenter, der har flere kendte sårbarheder. Legacy systemer kan også være langsomme eller bare ikke længere understøtte den mest effektive arbejdsproces. Legacy systemer forhindrer ikke blot daglig drift, den direkte truer organisationens evne til at nå sine langsigtede, strategiske mål og bevare konkurrenceevnen i markedet.

Årsager – Hvordan er vi endt her?

De fleste legacy systemer fungerer udmærket, når de bliver bygget. Men omverdenen er omskiftelig, og det er derfor svært at forhindre at systemet på et tidspunkt bliver forældet. Mange opfører sig som om at it-systemer kan holde for ‘evigt’, ved ikke at tage stilling til hvor længe systemet forventes at kunne holde, før det igen skal udskiftes. Man bør holde øje med sine systemer, ved for eksempel et årligt tjek: 

Vurdere systemets tilstand
Lave et årshjul med de forventede ændringer
Identificere hvilke udfordringer systemet har eller kommer til at få 
Inkorporere mitigerende handlinger for udfordringerne i årshjulet

Tid er én årsag til at systemer bliver legacy, men det forklarer ikke hvorfor nogle systemer hurtigere bliver legacy sammenlignet med andre. De fleste ønsker at deres systemer skal holde så længe som muligt. Dog kan det være svært at vide hvilke parametre man kan skrue på for at det sker, altså hvor man skal foretage forebyggende tiltag.

Du kan udsætte at et system bliver legacy, hvis du adresserer årsagerne. Overordnet set bliver (legacy) systemer påvirket af (1) teknologiens udvikling, (2) organisation og (3) interne processer. 

Teknologiens udvikling

Teknologisk forældelse er en uundgåelig proces, selv hvis man vedligeholder systemet løbende. Der er en indbygget risiko for man når til et punkt, hvor der ikke er nogen der kender det specifikke framework eller sprog det blev udviklet i. It-afdelinger kan ikke spå om fremtiden og derfor må man forberede sig på at systemet ikke kan leve evigt. For at sikre et systems fremtidsudsigter bør fokus i udviklingsfasen være at bygge systemet til at være robust og fleksibelt. Det vil gøre det nemmere at konvertere de forskellige dele til anden teknologi. Her spiller løsningsarkitekturen en væsentlig rolle, for uden en god grundlæggende arkitektur er det ikke muligt løbende at udskifte de enkelte dele. Tager man let på denne del og laver for hårde koblinger, fordi det her og nu er nemmest, øger man på sigt frekvensen i udskiftning af (del)systemer.

Organisatoriske aspekter

Organisationer, som designer it systemer, er begrænset til at producere designs, som kopierer kommunikationsstrukturerne af disse organisationer (conways lov). I denne sammenhæng betyder det, hvis man vælger at erstatte et legacy system fuldstændigt, kan det nye system arve ‘de organisatoriske aspekter’ og dermed hurtigt blive til ‘legacy’. Organisationen spiller en afgørende rolle i, om et system udvikler sig til legacy. Det er derfor vigtigt at have fokus på både struktur, processer og kultur i organisationen for at sikre, at de rette rammer for systemudviklingen. 

Interne processer 

Mangelfulde eller ineffektive interne processer kan føre til, at selv et velfungerende system hurtigt udvikler sig til legacy. Det er derfor vigtigt at have fokus på processerne: hvilke regler og retningslinjer der gælder, samt det politiske landskab systemet befinder sig i. Arbejdsprocesser bør identificeres, (evt. optimeres), dokumenteres og understøttes på en hensigtsmæssig måde af it-systemerne. Processtyring gør det muligt at mitigere risici og skabe et system, der understøtter ens behov og processer. Gennem processtyring kan man nemmere identificere, når processer og behov ændrer sig meget, at præmissen for systemet har forandret sig. I sådanne tilfælde bør man være opmærksom på, hvad det kræver for at systemet stadig kan understøtte ens behov på en hensigtsmæssig måde.

Så selvom man ikke kan ændre eller forudse teknologiens udvikling, kan man stadig foretage nogle ændringer, der forbedrer vilkårene for systemet.

Karakteristika: Hvordan nuancerer vi legacy udfordringerne?

Legacy består af en række områder, som kan inddeles efter eget ønske, bemærk, visse tværgående aspekter går igen, herunder dokumentation og fejlhåndtering. For at få et mere detaljeret indblik i, hvad der karakteriserer et legacy system, kan man dykke ned i de enkelte områder:

Sikkerhed

Et af de mest alvorlige kendetegn ved legacy systemer er manglen på indbygget sikkerhed. Dette kan skyldes, at systemet blev udviklet før nutidens sikkerhedsstandarder, eller at sikkerheden er blevet implementeret på en utilstrækkelig måde. Det kan også være, at systemet benytter “custom” sikkerhedsløsninger, der ikke følger gængse it-sikkerhedsstandarder. Alternativt at sikkerhed er implementeret på en uhensigtsmæssig måde, hvilket skaber sårbarheder.

Test

Testdækningen i legacy systemer er ofte mangelfuld eller ikke eksisterende, hvilket øger risikoen for fejl og ustabilitet. Der kan være dårlig testdækning på alle lagene af systemet, tests der ikke tester eller lav grad af testautomatisering. I værste fald kan systemet være svært eller umuligt at teste.

Data 

Der er ofte problemer med data i legacy systemer: dårlig datakvalitet, mangel på data governance, uhensigtsmæssig eller usammenhængende data og en dårlig databasestruktur. Nogle gange er der brugt de helt forkerte datalagringsteknologier, eftersom alle data ikke nødvendigvis passer i den relationelle model (RDBMS). Disse problematikker gør det svært effektivt at udnytte data, træffe datadrevne beslutninger og udgør en barriere for nye datadrevne teknologier.

Organisatorisk aspekt

En væsentlig faktor ved legacy systemerne er den omgivende organisation. En af de største udfordringer er, at arkitekturen skal binde IT og forretning sammen, så IT-landskabet understøtter de forretningsmæssige behov. Uden klare retningslinjer og implementering af bedste praksis for udvikling forringes fundamentet for god udvikling betydeligt. Mangel på en klart defineret ansvarshavende, der løbende kan sikre systemets tilstand. Hyppig udskiftning af medarbejdere, især udviklere, vanskeliggør vedligeholdelsen af systemet på en hensigtsmæssig måde. Derudover kan manglende forankring i forretningen føre til, at systemet ikke udvikler sig i takt med de reelle behov. Det gør at forretningen ikke får det forventede udbytte af systemet. Dårlig kommunikation og manglende samarbejde mellem IT og forretning kan også bidrage til, at et system hurtigt bliver betragtet som legacy.

Drift

Legacy kan også medføre udfordringer i driften og den underliggende software supply chain. Ofte ses en hård kobling til et specifikt driftsmiljø, hvilket skaber sårbarhed og manglende fleksibilitet. I stedet bør man tilstræbe løsninger, der kan understøtte flere forskellige driftsscenarier – en tilgang, der ofte anvendes i udviklingen af produktsoftware. En sådan abstraktion på driften sikrer, at systemet kan installeres og opereres i varierende miljøer uden store tilpasninger. Eksempelvis kan en uhensigtsmæssig langsom, kompleks og/eller skrøbelig byggeproces, eller driftskonfigurationer, der er “hårdt-kodet” i løsningen øge tidsforbrug, risiko, sårbarhed og afhængigheden af den nuværende infrastruktur. 

Kvalitet

Teknisk forældelse er et klassisk kendetegn ved legacy systemer. Dette kan komme til udtryk som forældet teknologi, kompliceret eller stor kodebase, et kodesprog, der ikke er optimalt til formålet. Vi ser også forældet hardware, en ikke-skalerbar database, mangelfuld eller forældet dokumentation. Arkitektur spiller en vigtig rolle, hvis den ikke følger organisationens rammer, ‘bedste praksis’, er usammenhængende, eller dårlig anvendelse af frameworks.

Forretning

Mangel på sporbarhed, altså mangel på klare og dokumenterede forretningsregler og forretningsprocesser, forværrer vilkårene for systemet og besværliggør fremtidige udskiftninger af hele eller dele af systemet. Man bør overveje hvordan man kan spore reglerne, som er defineret i koden, når de skal vedligeholdes. Deri hvorvidt reglerne er selvstændige moduler der kan udskiftes. Mangel på en klar vision og retning for systemet, gør det sværere at sikre en sammenhængende arkitektur. Lovgivningstunge systemer er derfor ekstra udfordret, da lovgivningen kan ændre retning, hvilket kan være svært at forudse.

Eksterne afhængigheder

Legacy systemer har ofte integrationer til gamle tredjepartskomponenter, eksterne systemer og standardløsninger, hvilket skaber afhængigheder og gør opgraderinger vanskelige. Mangelfulde opgraderinger af afhængigheder kan udgøre betydelige sikkerhedsrisici. 

Opsummering – skab dig et overblik

Ved at identificere disse karakteristika kan man få et bedre overblik over, hvor udfordringerne ligger, og hvilke områder man bør adressere. Man er nødt til at være opmærksom på alle de dele som ens system består af og dermed er afhængig af (såsom ‘eksterne afhængigheder’). Et godt sted at starte er at have styr på sin software supply chain.

Konsekvenser – Hvad er Business casen?

Når ledelsen ser de konkrete konsekvenser af legacy systemer, bliver det tydeligere, hvorfor det er en strategisk og økonomisk prioritet at adressere problemet. Konsekvenserne kan være mange og vidtrækkende og påvirke både den daglige drift og virksomhedens strategiske mål, foruden at være en tung økonomisk byrde.

Der er en række konsekvenser, som ofte ses i forbindelse med legacy systemer, der går fra sikkerhed og lovgivning til bemanding.

Risici og lovgivning

Svært at holde compliant ift. bedste praksis, lov-regulativer mv.: Legacy systemer kan gøre det vanskeligt at overholde gældende lovgivning og bedst praksis inden for it-sikkerhed og datahåndtering.

Sikkerhedsrisiko: Ældre systemer har ofte sikkerhedshuller og sårbarheder, der kan udnyttes af hackere, hvilket øger risikoen for databrud og andre sikkerhedsmæssige problemer.

Vendor lock-in: Man kan blive bundet til en bestemt leverandør eller teknologi, hvilket begrænser fleksibiliteten, mulighed for at konkurrenceudsætte og øger omkostningerne.

Dyrt og performer dårligere

Lavere performance: Legacy systemer kan være langsomme og ineffektive, hvilket påvirker produktiviteten og brugertilfredsheden. Som en yderligere konsekvens heraf kan det have betydelige omkostninger at skalere systemet. Dertil er det spild af ressourcer og ikke “grøn” udvikling.

Højere tidsforbrug: Det kan tage længere tid at udføre opgaver og processer i legacy systemer, hvilket spilder ressourcer.

Dyrt at vedligeholde: Vedligeholdelse og support af ældre systemer kan være dyrt og kræver specialiseret viden.

Problemer med bemanding

Svært at ansætte: Det kan være svært at ansætte udviklere til at vedligeholde systemet. De kan enten ikke magte den teknologi der måske er forældet, eller der er ikke nogen der ønsker at arbejde med teknologien eller systemet.

Svært at introducere nye udviklere: Nye udviklere kan have svært ved at forstå og arbejde med komplekse og forældede systemer. 

Svært at videreudvikle: Det kan være svært og risikabelt at foretage ændringer og tilføjelser til legacy systemer.

Øget kompleksitet og flere begrænsninger

Svært at opdatere: Opdatering af legacy systemer kan være en kompliceret og en tidskrævende proces.

Øger kodekompleksiteten: Legacy systemer har ofte en kompleks og rodet kodebase, der er svær at overskue og vedligeholde.

Begrænser teknologivalg: Man kan være begrænset i sine valg af nye teknologier og løsninger, da de skal kunne integreres med det eksisterende legacy system.

Opsummering – Kortlæg konsekvenserne

I kan med fordel kortlægge konsekvenserne i forhold til de identificerede legacy opgaver for at tydeliggøre gevinsterne ved at modernisere eller udskifte systemerne. Dette vil hjælpe med at skabe en forståelse for, hvorfor det er nødvendigt at prioritere legacy håndtering højt i organisationens digitaliserings- eller transformationsstrategi.

Hvad stiller man op med legacy?

Legacy er en uundgåelig skæbne for it-systemer. Ved at prioritere robuste organisatoriske strukturer og velfungerende interne processer kan vi aktivt udskyde eller endda minimere risikoen for at systemer udvikler sig til legacy. En stærk sammenhæng mellem it og forretning, klare retningslinjer, tydelige ansvarsområder og effektive arbejdsgange skaber et solidt fundament, der sikrer systemernes levedygtighed og fleksibilitet. Med en proaktiv tilgang, hvor vi lærer af tidligere erfaringer og tilpasser os løbende, kan vi skabe systemer, der ikke blot understøtter nutidens behov, men også er rustet til fremtidens udfordringer og muligheder. Så lad os se legacy som en mulighed for at styrke vores organisation og skabe it-løsninger, der er både holdbare og innovative.

Læs de andre indlæg i blogserien

Hvad er teknisk gæld, og hvorfor er det værd at beskæftige sig med?

Teknisk gæld eller legacy: hvad er forskellen?

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). 

Irani, Z., Abril, R. M., Weerakkody, V., Omar, A., & Sivarajah, U. (2023). The impact of legacy systems on digital transformation in European public administration: Lesson learned from a multi case analysis. Government Information Quarterly, 40(1), 101784.

Srinivas, M., Ramakrishna, G., Rao, K. R., & Babu, E. S. (2016). Analysis of legacy system in software application development: A comparative survey. International Journal of Electrical and Computer Engineering, 6(1), 292

Bakar, H. K. A., & Razali, R. (2013, November). A preliminary review of legacy information systems evaluation models. In 2013 International Conference on Research and Innovation in Information Systems (ICRIIS) (pp. 314-318). IEEE.

M’baya, A., Laval, J., & Moalla, N. (2017, December). An assessment conceptual framework for the modernization of legacy systems. In 2017 11th International Conference on Software, Knowledge, Information Management and Applications (SKIMA) (pp. 1-11). IEEE.

Ransom, J., Somerville, I., & Warren, I. (1998, March). A method for assessing legacy systems for evolution. In Proceedings of the Second Euromicro Conference on Software Maintenance and Reengineering (pp. 128-134). IEEE.

Monteiro, A., & Vieira, G. (2022). Guiding legacy systems for evolution. PmatE: a case study of maintenance and engineering. Journal of Information Systems Engineering and Management, 7(1), 11689.