Et opgør med legacy-problemer kræver, at virksomheden er skarp på målsætning, problem og løsning. Baseret på erfaringer fra kundeprojekter leverer Devoteam en guide til de rette analyser og strategier, så virksomheden får det optimale ud af sin investering.
Legacy er en massiv og efterhånden klassisk hovedpine for mange offentlige og private virksomheder. Medierne beretter regelmæssigt om legacy-problemer og -skandaler, hvor uoverskuelige systemlandskaber koster kassen, og fejlslagne moderniseringer koster hoveder.
Samtidig er legacy er ikke kun en økonomisk udfordring, men også strategisk. Den hæmmer virksomhedens innovationsevne, som skal skabe nye digitale services og dermed øge konkurrenceevnen. Og i en tid med COVID-19 er der ekstra pres på den målsætning.
I Devoteam beskæftiger vi os også med legacy hos vores kunder, og vi har nu samlet de seneste års erfaringer fra en række forskellige brancher. Hvordan problemerne tilgås, og hvordan virksomheden kan få det meste ud af sin indsats, det er, hvad denne artikel handler om, men du er også velkommen at se vores DevoTalk om emnet: Ud af legacy IT? Find den rigtige vej frem.
Målsætninger skal udfordres
Vores grundlæggende konklusion er, at selv om mange kender til legacy-udfordringer, er det nødvendigt at analysere såvel problem som løsning for at vælge den rette strategi. Hvornår er et it-system legacy, og hvad ønsker virksomheden reelt at opnå? Hvis ikke du er skarp på målsætningen, risikerer du at sætte ind de forkerte steder eller tidspunkter, hvorved der mistes både tid og penge.
Vi vil endda tillade os at stille spørgsmålstegn ved, om man overhovedet skal væk fra legacy? Når man tænker på, hvad det vil koste i både tid og penge, er alternativet mon så meget bedre? For eksempel er en ofte hørt målsætning, ”vi vil have standardsystemer,” men husk at legacy er udtryk for, at tidligere generationer har investeret i et system, således at det er tilpasset virksomheden. Er man villig til at opgive det privilegium og tilpasse sig et standardsystem? Det kan være, at svaret er ja, men det kræver en analyse af investering og afkast i forhold til det bestående.
Hvornår er det legacy IT?
Det er tilsvarende vigtigt at analysere problemet: Hvornår et it-system er legacy, og hvad indebærer det? Legacy har ikke nødvendigvis noget med systemets alder at gøre. Der er snarere tale om en situation, hvor den nuværende generation af beslutningstagere har arvet et system, der ikke passer til de aktuelle behov. Typisk oplever virksomheder problemer inden for tre områder, ofte alle på samme tid: Drift, udvikling og samarbejde med leverandører.
Figur 1: Typiske problemer oplevet ved legacy-systemer. Figuren viser, at der på den ene side er et samspil mellem drift og udvikling, og på den anden side har vi samarbejdet med leverandøren.
De fleste virksomheder vil kunne nikke genkendende til i hvert fald en del af problemerne i figuren, men for virkelig at forstå systemets tilstand og finde den rette vej ud af problemerne, er vi nødt til at gå et spadestik dybere og undersøge typen af legacy, vi har med at gøre.
Hvilken slags legacy?
Her har vi valgt tre typer analyser af systemets tilstand:
- Er status end-of-life?
- I hvor høj grad er der tale om big ball of mud?
- Er systemet et tilted house?
End-of-life
Den første tilstand, end-of-life, er velkendt, da det her reelt drejer sig om et system, der har levet sin tid ud. Vi vil fokusere på de to andre, som er anti-patterns, dvs. uhensigtsmæssige – men typiske – situationer, som et it-system kan havne i.
Big ball of mud
Big ball of mud har været kendt som begreb i godt 20 år og er, som navnet indikerer, en rodet affære uden nogen tydelig arkitektur eller strategisk retning. Et af de offentligt kendte tilfælde er systemlandskabet hos SKAT, men vi er også stødt på kunder med andre, endnu mere alvorlige tilfælde. Et system kan blive en big ball of mud, når der over tid tilføjes nye features, uden at de bliver implementeret ordentligt, og hvor it-udviklerne ender med at bruge det meste af deres tid på at løse problemer, de selv har skabt.
Tilted house
Tilted house er et anti-pattern af nyere dato, som vi i Devoteam har observeret hos en række kunder og hos nogle større offentlige it-projekter. Her er der tale om et hus, et system, der ikke længere er fit-for-purpose. Systemet er grundlæggende det samme, som det altid har været, men måden, det bruges på, har ændret sig, og forretningen vil nu have noget andet og mere. Hvis virksomheden vælger at tilrette et tilted house med lappeløsninger, risikerer man at ende med en big ball of mud.
Vi foreslår at udføre de disse tre analyser, da de kan indikere hvilken strategi, der er mest velegnet til at komme væk fra legacy.
Veje væk fra legacy – kort og lang bane
Så er vi nået til løsningerne, og nedenstående figur viser seks strategier, hvor de fem er veletablerede samt en sjette, som vi ligeledes har gjort brug af i Devoteam, nemlig genforhandling.
Strategierne har hver deres fordele og styrker. I figuren har vi indikeret, hvor velegnet den enkelte strategi er til at håndtere legacy-systemer, kendetegnet ved end-of-life, big ball of mud og/eller tilted house. Hvilken af strategierne, der i sidste ende er den mest velegnede, afhænger naturligvis også af målsætning samt de situationsbestemte forhold. Strategierne gennemgås kort nedenfor.
Figur 2: Oversigt over strategierne til at komme væk fra legacy med en kort beskrivelse samt angivelse af, hvor egnede de er til at adressere problemerne med end-of-life, big ball of mud og tilted house.
Genforhandling kan være den rigtige strategi, hvis man har en klar målsætning om at nedbringe udgifterne. Vi oplevede det i et projekt med afskaffelse af et legacy-system hos en stor dansk virksomhed, der i lang tid uden det store held havde forsøgt at forhandle systemets økonomi med leverandøren. Da projektet tog fart, blev leverandøren hurtigt mere forhandlingsvillig, og eftersom virksomheden i sidste ende prioriterede økonomien højst, blev projektet lukket og målsætningen opfyldt.
Genforhandling kan opnå resultater på den korte bane, men uden at løse de mere strategiske udfordringer ved legacy. Det samme gælder for de to næste strategier, virtualisér og portér. Virtualisér er en ren serverrums-øvelse, også kaldet Lift and Shift, mens portér betyder, at man beholder systemet, som det er, men med nogle tekniske ændringer, så man kommer over på en mere moderne platform.
Som det fremgår af nedenstående figur, har Genforhandl, Virtualisér og Portér alle en begrænset effekt på problemerne med legacy og bør derfor kun være et første skridt mod et egentligt opgør med dem.
Figur 3: De seks strategier mappet ift., i hvor høj grad de løser problemerne med legacy (x-aksen) og ift. investeringsomfang (y-aksen).
Et sådant opgør kræver en mere langsigtet – og dyrere – tilgang: Modernisér, Standardisér eller Reorganisér.
Modernisering tager udgangspunkt i kodebasen, hvor det går ud på at modernisere, hvor det er muligt. Dvs. man gennemgår fra modul til modul og vurderer, om det er værd at refaktorere, omskrive eller evt. udskifte. Denne strategi handler ikke så meget om nye forretningsbehov, men om at opfylde de pt. understøttede behov på en teknisk bedre måde. Alligevel er modernisering for større systemer en krævende og som regel dyr øvelse.
Standardisering tager i stedet udgangspunkt i forretningens behov. Hvad er der brug for, og i hvor høj grad kan et eller flere standardsystemer tilgodese de behov? Målet er at opnå en god udnyttelse af standardsystemer, og der skal typisk tilrettes en del internt i virksomheden for at udnytte standardsystemernes muligheder. Derfor skal en standardisering ske i tæt dialog med forretningen og med ledelsens opbakning. Ikke alt kan løses med standardisering, og virksomheden vil typisk stå tilbage med et restbehov, hvor der er brug for specialudvikling eller specialtilpasninger.
Endelig er der reorganisering, som er en interessant strategi, fordi den ikke som sådan går i clinch med legacy-problemet, men derimod isolerer det i en operational backbone. Kort sagt opdeles it-landskabet i to, hhv. operational backbone til den daglige drift og en digital platform til innovation med API’er til at sikre den nødvendige dataudveksling mellem de to som vist i nedenstående figur.
Figur 4: Reorganisering af legacy-systemet ved at etablere en ny digital platform til at håndtere ændringer. Den gamle operational backbone isoleres fra ændringspresset for nye digitale produkter.
Det betyder, at forretningens krav om digital innovation nu håndteres ved at udvikle på en separat cloud-baseret platform. Det er vores erfaring, at når virksomheder efterlyser mere fleksibilitet ift. legacy, er det netop mht. udvikling af kundevendte digitale services, og ved reorganisering kan det nu foregå på en dedikeret platform.
Modellen er udviklet af Jeanne Ross et. al. fra MIT’s CISCR (Center for Information Systems Research). Du kan læse mere i bogen Designed for Digital fra 2019.
Afsæt ressourcer og tænk langsigtet
Legacy er som nævnt et velkendt problem for mange virksomheder, men det betyder langt fra, at også løsningen er den samme for alle. Vi anbefaler, at man først og fremmest tager sig tid til at analysere både problem og målsætning for at finde frem til den rette strategi. Og der skal afsættes tilstrækkeligt med ressourcer, hvis man for alvor vil problemet til livs. Ellers består problemet – en uønsket arv, der hæmmer virksomhedens konkurrenceevne.
Hvis du vil vide mere om ovenstående, fra analyser til strategier eller måske noget helt tredje, er du velkommen til at kontakte Peter.
