Det spøger - Hvordan forhindrer man spøgelser i it-landskabet?

I dette blogindlæg kommer vi vidt omkring, vi starter med at zoome helt ud, fordi vi oplever et skifte. Balanceskålen flytter sig fra at digitalisere arbejdsgange til at modernisere legacy systemer. Derfor lister vi hvilke strategier, der er, når man skal modernisere systemer. Dén største forundring vi møder, er når et nyt system går i luften, hvorfor det gamle system så ikke bliver lukket ned. Vi ser, det kan tage mere end et årti at få lukket det gamle system ned.

Legacy modernisering indebærer at tage den funktionalitet, der ligger i legacy systemer – alt det, de kan og bidrager med til organisationens forretning – og så genimplementere det. Det betyder at bygge det forfra på en tidssvarende og moderne teknologisk platform, og efter et moderne arkitektonisk paradigme. Så de gode og uundværlige funktioner fra legacy systemet flyttes over i et nyt og mere moderne setup. Det nye system vil være mere effektiv, mere fleksibel, nemmere at vedligeholde og klar til fremtidige innovationer. Det er dog ikke altid man har ressourcerne til at lave en total modernisering og nedlukning af legacy systemet.

Fra digitalisering til legacy modernisering

Den offentlige sektor forfølger i særlig høj grad den digitale transformation med kun få ressourcer. De skal derfor vælge mellem at opgradere eller modernisere deres it-systemer (it transformation) eller digitalisere flere arbejdsgange (digital transformation). Hvis organisationerne vælger udelukkende at fokusere på den digitale transformation og negligerer deres it-fundament, kan det resultere i legacy systemer og ophobning af teknisk gæld. Som i sidste ende vanskeliggør introduktionen af nye systemer i organisationen, men også nedlukningen af legacy systemerne.

Efterhånden som organisationerne får digitaliseret deres arbejdsgange, stiger deres behov for modernisering af it-systemer – så legacy systemerne bliver løftet eller erstattet med mere fremtidssikre systemer. Derfor skifter fokus fra digital transformation til IT transformation, så organisationerne kan bevare deres agilitet. Altså fra at fokusere på at digitalisere forretningen, er fokus nu at løfte it-landskabets tilstand.

Vedligehold 

It-organisationer har typisk langt større erfaring med at drifte og vedligeholde eksisterende it-systemer end med at lukke eller udvikle nye. Derfor går størstedelen af it-budgettet til videreudvikling og vedligeholdelse – en nødvendig indsats for at sikre, at systemerne ikke forfalder, men fortsat understøtter forretningen. Problemet opstår dog, når fokus på systemernes faktiske værdi og levetid glipper: Uden klare signaler om, hvornår en geninvestering er påkrævet, når man sjældent at sætte ind, før omkostningerne vokser ukontrolleret. Når vedligeholdelsen svigter, eller den forretningsmæssige værdi falder, står organisationen med en strategisk beslutning: Skal systemet opgraderes, afløses eller udfases? Ofte først i det øjeblik, systemet ikke længere lever op til nye krav, er vanskeligt at supportere eller risikerer at bryde gældende lovgivning, bliver behovet tydeligt.

Legacy strategier

Organisationen kan vælge mellem flere forskellige strategier for it-transformation, som kan kategoriseres på forskellige måder. Særligt interessant er Magnusson, Persson, Torell og Paas’ tilgang, da deres strategier er kortlagt ud fra to centrale parametre: systemkritikalitet og tilgængelige ressourcer. Nedenstående matrix gør det lettere at identificere den strategi, der bedst matcher organisationens aktuelle behov og situation.

Kritikalitets vurdering

Hvor kritisk det er at et system bliver håndteret, afhænger af forskellige parameter:

Værdien systemet giver forretningen – er det forretningskritisk/samfundskritisk?
Overholdelse af lovgivning
Sikkerhedsrisici
Muligheden for supportering – kører det på end-of-life?

Tilgængelige ressourcer

Vurdering af tilgængelige ressourcer kræver man tager stilling til flere ting: 

Organisationens båndbredde, der er en grænse for hvor mange transformationer en organisation kan håndtere  
Medarbejdere til rådighed med de rette kompetencer
Mulige leverandører eller udvikler tilgængelighed
Økonomi

I sidste ende er det en strategisk beslutning som ledelsen skal træffe, hvad de vægter som mest kritisk og tilgængeligheden af ressourcer.

Migreringsstrategi – byg nyt, migrere og luk det gamle

Denne strategi erstatter det eksisterende system med et nyt. Det sker ved at bygge et nyt system, migrere det gamle og efterfølgende lukke det gamle system. 

Organisationen vurderer de forventede omkostninger og den nødvendige indsats ved at modernisere det eksisterende system som betydelig og bruger ressourcerne til at udskifte hele systemlandskabet i etaper. En ny infrastruktur idriftsættes parallelt med den eksisterende med det formål gradvist at overføre driften. Strategien kræver mange ressourcer, særligt når organisationer etablerer nye forretningsområder med potentiale for store gevinstrealiseringer, såsom introduktion af ny teknologi, der kræver nye kompetencer.  

Denne strategi har ofte betydelige omkostninger, mens projektet står på, men der er også oftest potentielle gevinster at høste f.eks. agilitet, reducering af omkostninger og bedre understøttelser af forretningsbehov. Men med nyudvikling er der risici f.eks. dårlig implementering, der kan forhindre den forventede gevinstrealisering.

Omstruktureringsstrategi – delvis refaktorere

Motivationen for strategien er udtjent levetid for eksisterende digital infrastruktur, den fokuserer på at forlænge infrastrukturens livscyklus, ved at refaktorere lidt ad gangen.

Større it-transformationsprogrammer bruges som et middel til at sikre it-modernisering. Intentionen bag disse programmer er enten at afvikle eller modernisere eksisterende systemer, og betydelige ressourcer bruges til modernisering af fundamentet, f.eks. at udskiftning i it-arkitekturen.  

De potentielle gevinster i denne strategi ved en vellykket større renovering er reduceret vedligeholdelsesomkostninger, stabilt system og mindsket integrationskompleksitet. Men der er også en risiko for at mislykkes, og man ender med at tabe sin investering.   Konsekvenserne af denne strategi er enten tabte udgifter eller en vellykket større renovering af systemet, hvilket resulterer i reducerede vedligeholdelsesomkostninger og integrationskompleksitet og en stabil tilstand.

Accepter-strategi – Byg et nyt uden at lukke det gamle ned

Denne strategi er et passivt valg af eksisterende systemer og tilføjer nye systemer. Man håndterer ikke det egentlige problem. Man fortsætter ad den sti, man allerede er på.

I stedet for at afvikle eller modernisere systemer tilføjes nye systemer for at imødekomme skiftende behov. Denne strategi anbefales som udgangspunkt ikke, da det er vigtigt at adressere de organisatoriske aspekter og processer, der også ligger til grund for legacy. 

En af konsekvenserne er, at man ender med mange flere systemer, end man har brug for. Efterhånden får man et stort og rodet it-landskab med mange forskellige systemer. Over tid bliver det dyrere at vedligeholde it-landskabet og mere besværligt at få alle systemerne til at arbejde sammen.

Indkapslingsstrategi – Indkapsle systemet vha. API mv

Strategien fokuserer på at forbedre eksisterende infrastruktur gennem nye arkitektoniske lag, så organisationen bedre kan imødekomme nye krav. 

I denne strategi accepterer organisationen tilstanden af deres nuværende systemer, og bruger løsninger som microservices og API’er til at begrænse problemet. Ved at skifte til en composable arkitektur adskilles systemer fra data gennem arkitektonisk nedbrydning med det formål at skabe hurtige gevinster i form af øgede muligheder for driftsudvikling. 

Konsekvenserne er øgede muligheder for driftsudvikling og lydhørhed overfor nye krav, men over tid også øget teknisk gæld og legacy, da de underliggende systemer ikke tages ud af drift eller moderniseres. 

Opsummering

Alle fire strategier kræver noget forskelligt og jo mere de kræver, jo bedre får organisationen nedbragt den teknisk gæld og håndteret legacy’en i systemet. Valget af strategi beror på kritikalitet, tilgængelige ressourcer, behov og fremtidsudsigterne. 

Migreringsstrategien vil ofte være anset som ‘den dyre og mest korrekte’ strategi. Udfordringen her er oftest at få lukket det gamle system og sendt det på kirkegården. Hvilket resten af blogindlægget fokuserer på.

Omstruktureringsstrategi er ofte nok, såfremt at den tekniske tilstand ikke kræver en total udskiftning. Det kan også være nemmere at komme i gang end migreringsstrategien.

Accepter-strategien er sjældent at foretrække, nogle organisationer kan bedre slippe af sted med denne løsning. Strategien vil oftest have konsekvenser på sigt og systemet ender med at blive et spøgelse i systemlandskabet.

Indkapslingsstrategien kan være fin, hvis man ønsker at købe lidt tid til at anskaffe et nyt system, eller hvis systemet alligevel skal sendes på kirkegården indenfor en kort tidshorisont.’

Hvorfor er det svært at slukke?

Der kan være en række årsager til hvorfor det er svært at lukke et system, selvom man har ressourcer og ledelsens opbakning.

Det gamle system er ikke bygget til at man skal konvertere det. Gamle systemer er sjældent designet med fokus på nem konvertering.

Man har ikke ordentlig indsigt i det gamle system, hvilket gør det svært at sikre, at alt bliver overført korrekt.

De sidste 2-5% special cases, som er uforholdsmæssigt tidskrævende at håndtere.

Risikoen for at miste data der skulle bruges, særligt frygten for at miste vigtige data, selv sjældent brugte, kan skabe modstand mod nedlukning.

Manglende ejerskab på at få systemet lukket, når det nye system først kører kan det være svært at få prioriteret at lukke det gamle.

Eksempel

Pensionssystemer har nogle særlige udfordringer med pensionspolicer der er mere end 100 år gamle og som man ikke sådan lige kan lukke eller ændre. De tilbyder produkter baseret på deres pensionspolicer. Så et køb af et nyt standardsystem, der dækker størstedelen af deres forretning, tvinger pensionsselskabet til at revurdere deres produkter. Det efterlader dem med en beslutning om hvordan de skal håndtere de produkter, der ikke passer ind i en standardløsning, men som de vurderer er en vigtig del af deres forretning. 

Fra spøgelse til kirkegården

Ultimativt ender alle systemer på kirkegården (i det offentlige skal nogen endda afleveres til ‘Rigsarkivet’). Nogle systemer er spøgelser i længere tid, inden de når frem til kirkegården. Men hvordan får man lukket et system ned? De fleste har hørt om it-systemer som tager flere år at få lukket ned, så hvordan undgår man at stå i sådan en situation? Paradokset er, at systemet skal være i god nok stand, for man effektivt kan lukke det ned.

Dette skyldes særdeleshed, at en leverandør er nødt til at kunne forstå hvad der sker i det gamle system for at sikre at det bliver konverteret hensigtsmæssigt. Hvis organisationens behov tilmed har ændret sig, skal man også have så meget styr på dem, at man kan implementere dem i det nye system og undlade de dele, der er overflødige (hvilket er smart for at reducere det nye systems kompleksitet).

Det betyder:

Man er nødt til at have nogenlunde styr på sin dokumentation
Teknologien skal stadig være velkendt nok til at en leverandør kan forstå hvad der sker
Kode og strukturen skal være god nok til at en leverandør kan navigere og forstå den
Man har styr på alle delelementerne – det er sjældent kun en kontakt der skal slukkes 

Det betyder også at når man bygger nyt, bør man bygge det med tanke på at det én dag kan lukkes. Derfor bør man bygge småt og med fokus på én specifik funktion. På den måde vil det også være nemmere at udskifte delene løbende.

Så hvordan gør man det?

Beslutningen er truffet, der er økonomi og ledelsens opbakning, nu skal nedlukningen i gang.

Forventningsafstemning mellem organisationen og leverandøren

Vær tydelig omkring leverancen: skal alt migreres? Hvad er tidshorisonten?
Skal alle data fra det gamle system overføres?
Sørg for, at alle er enige om, hvad der skal leveres, og hvornår.

Klarhed over ‘nye’ behov

Hvad kan det gamle system ikke gøre, som det nye skal kunne?
Hvilke nye funktioner eller forbedringer er nødvendige?

Analyse af det ‘gamle system’

Hvordan fungerer det gamle system egentlig? Hvad gør det godt?
Ofte bruger vi “reverse engineering” til at forstå systemets logik og opbygning.

Vision for det nye system

Hvordan skal det nye system se ud og fungere?
Hvilke tekniske principper skal det følge?

Opbygning af det nye system

Selve udviklingen af det nye system

Konvertering af data

Overførsel af data fra det gamle til det nye system, man starter med det med mest volume. De sidste er de mest tidskrævende.
Sikre en recovery plan for data er på plads 

Nedlukning af det gamle system

Endelig overblik over alle elementerne i det gamle system, som skal slukkes.
Evt gemme de elementer af systemet, som kræves, hvis man skal kunne tilgå data på et senere tidspunkt

Organisationen omkring systemet

Man bør altid sikre sig organisatoriske aspekter ikke fremskynder legacy processen for det nye system (Læs mere her)
Sikre at forretningsprocesser er kompatible med det nye system.
Definere klare roller og ansvarsområder for vedligeholdelse og drift.
Overveje uddannelse og træning for medarbejderne som en del af implementeringen af det nye system så systemet bliver brugt hensigtsmæssigt
Sikre medarbejder accept
Overvåge det nye system og sikre det løbende bliver opdateret

Eksempel

En batchplatform skulle udskiftes, fordi det kørte på en gammel oracle installation. Da platformen er forretningskritisk,, var man nødt til at lave en glidende overgang og det var særlig vigtigt, at intet gik tabt. Kunden og leverandøren afstemmede forventningerne og blev enige om, at den gamle platform skulle lukkes helt ned. Den gamle platform var aldrig bygget til at blive konverteret, så udviklerne blev meget fortrolige med den gamle platform grundet analysen. Efter at den nye platform var bygget, startede de med at de nye udtræk blev behandlet i den nye platform. De sammenlignede løbende data og så at de havde gjort det rigtigt.

Derefter overførte de udtræk i store batches, de sager som lignede hinanden og havde stor volume. Men eftersom de nye udtræk stadig kørte i den gamle platform, skabte det en masse støj, og det var svært at se, hvor langt de var nået. Derfor lavede de én ændring til det gamle platform – det skulle stoppe med at tage de nye udtræk, hvis den nye platform allerede havde taget dem. Det blev tydeligt, hvilke udtræk der stadig lå i den gamle platform, som ikke var flyttet over. De kunne først lukke platformen, når alle udtræk var ude af det, så det var spørgsmål om at følge de sidste til dørs. De sidste udtræk var meget tidskrævende at flytte og da udviklerne havde flyttet det sidste udtræk, var de så nært knyttet til den gamle platform at det var vemodigt at slukke.

Gode råd til nedlukning

At udskifte et IT-system er en proces, der kræver planlægning, kommunikation og samarbejde. Det handler ikke kun om teknik, men også om at forstå forretningsbehov og menneskelige faktorer. Ved at følge disse trin og råd kan du undgå, at gamle systemer bliver til “spøgelser” i jeres IT-landskab.

Forenkle og ensrette processer og produkter: Jo færre særtilfælde, des nemmere bliver det.
Start med analysen: Forstå det gamle system
Enighed mellem kunde og leverandør: Alle skal være enige om, hvornår “færdig” er “færdig”.
Konvertering: Start konverteringen med de største datamængder.
Ændringer i det gamle system: Det kan være nødvendigt at ændre noget i det gamle system for at synliggøre hvornår aktiviteterne er stoppet
Asset management: Hold styr på alle dele af systemet – både det gamle og det nye.
Vær klar til at slette: Men hav en plan for, hvad og hvordan det skal gemmes, og hvordan det kan startes op igen.

At tage kontrol over sin tekniske gæld og legacy handler ikke kun om at rydde op. Det handler om at frigøre potentiale, mindske risiko og styrke evnen til at skabe nyt.

Det kræver mod at slukke, men spøgelser gør det skræmmende at lade være.

De sidste takeaways

I denne serie om teknisk gæld og legacy har vi udforsket, hvad det er, forskellen, nuancerne og hvordan det “smitter”. Afslutningsvis står det klart, at mens teknisk gæld og legacy i sig selv er uundgåelige vilkår i et dynamisk it-landskab, så er måden, vi håndterer udtjente systemer på, afgørende. Ved at anlægge et bredere perspektiv, der også inkluderer de omgivende interne processer og organisatoriske aspekter, kan vi potentielt udsætte tidspunktet, hvor et system bliver legacy og ultimativt skal lukkes ned. Med en klar strategi og fokus på at håndtere kompleksiteten i tide, kan vi undgå, at fortidens systemer bliver til langvarige “spøgelser” i vores it-landskab og i stedet skabe et mere agilt og fremtidssikret it-miljø.

Kilder

Magnusson, J., Persson, P., Torell, J., & Paas, I. (2023). Buridan’s Ass: Encapsulation as a Possible Solution to the Prioritization Dilemma of Digital Transformation. In EGOV-CeDEM-ePart-*.

Magnusson, J., Khisro, J., & Melin, U. (2020). A Pathology of Public Sector IT Governance: How IT Governance Configuration Counteracts Ambidexterity. Lecture Notes in Computer Science, 29–41.

Terry, S., & Chandrasekar, V. (2025). Systems engineering barriers to legacy system evolution: Legacy system assessment. Systems Engineering, 28(2), 207-223.

Wimelius, H., Mathiassen, L., Holmström, J., & Keil, M. (2021). A paradoxical perspective on technology renewal in digital transformation. Information systems journal, 31(1), 198-225.

Marounek, P. (2012). Simplified approach to effort estimation in software maintenance. Journal of Systems Integration (1804-2724), 3(3).