fb-head-tag-img

De 3 måder at håndtere forældede IT-systemer i din organisation

Du læser nu et gammelt blogindlæg. Der er ikke læst korrektur på dette, og der er muligvis kommet ny information frem siden. Blogindlægget vil blive kigget igennem snarest.

Denne blogpost er skrevet af Simon Miller som har arbejdet med marketing hos HTML24 i cirka 3 år. Når der skrives “jeg” i artiklen er det Simon der skriver. Den er dog blevet redigeret efterfølgende af vores adm. direktør, Bo Møller i fællesskab med vores Head of Development, Mikkel Strunge. God fornøjelse.

Frankensteins monster – Eksempel på legacy

blog-legacy-frankenstein

I min studietid, fik jeg fornøjelsen af, at få et indblik i medarbejderes dagligdag med systemerne på et af Danmarks største hospitaler. Dette var før Sundhedsplatformen blev rullet ud. Jeg havde aldrig oplevet noget lignende. Medarbejderen skulle arbejde i godt 20 forskellige separate systemer, som ikke kunne tale sammen. Medarbejderens skrivebord (på computeren) var plastret til med ikoner for alskens programmer. Der kørte omkring 5-7 programmer på samme tid, som hver især gjorde et specifikt stykke arbejde.

Brugervenligheden fandtes naturligvis ikke. Til at navigere rundt i et af de største systemer, brugte medarbejderen ikke musen, da der ingen knapper eller lignende var. I stedet var der en sort skærm med hvide bogstaver på. Her kunne medarbejderen indtaste koder for at navigere rundt. Koderne var printet ud og lå i fysisk form i en mappe på medarbejderens kontor. Dette var i 2017.

Systemet virkede for mig (såvel som for medarbejderen) komplet kaotisk, ineffektivt, langsomt og ulogisk. Et haltende og langsomt Frankensteins monster, syet sammen af 50 gamle systemer. Det er yderst imponerende, hvordan medarbejderne kunne bruge det. Men det blev også understreget gentagende gange, hvordan der blev brugt ufattelig tid på arbitrært tastearbejde og opslag i manualen. Meget af dette kunne let kunne løses digitalt.

Fra min tid i en af nordens største banker, lærte jeg samme problem at kende. Der var mange systemer, systemerne var uoverskuelige og brugervenlighed var en by i Rusland.

Et levn fra fordums tid

Kort fortalt er et legacysystem, et ældgammelt IT-system. Et levn fra fordums tid, som for 10/20/30 år siden var mægtig smart, men som i dag kan være sløvt, ineffektivt, funktionalitet-manglende og særdeles udskifteligt. Det er disse udskiftelige legacysystemer, som denne artikel beskæftiger sig med.

Virksomheden ser, i dette tilfælde, naturligvis helst legacysystemet udskiftet, til fordel for et nyt og hurtigere system, med alle de funktioner som er blevet efterspurgt af medarbejderne i årevis.

Problemet er, at legacysystemet ikke bare kan udskiftes. Systemet kan være en fuldstændig integreret del, af hvordan virksomheden fungerer, så omkostningerne ved et skift kan være ufatteligt høje. Det nye system kan risikere slet ikke at virke efter intentionerne, eller ikke spille sammen med resten af processerne i virksomheden.

Man kan derfor være stavnsbundet af det gamle forældede legacysystem.

Tag blot Sundhedsplatformen som eksempel på hvorfor udskift af legacysystemer er risikabelt. Sundhedsplatformen er et godt eksempel på de de udfordringer som kan findes, ved at skulle udskifte et Frankensteins monster af et samlet legacysystem, til fordel for et smartere men exceptionelt dyrt nyt system. Nu diskuteres det blandt, om de skal trække Sundhedsplatformen tilbage, og returnere til deres gamle legacy, grundet de mange problemer, som Sundhedsplatformen har ført med sig.

Undgå skandalen

Legacysystemer er typisk kolossalt dyre at vedligeholde, og med god grund.

Legacysystemer kan eksempelvis være kodet i programmeringssprog som COBOL, MUMPS eller sågar BASIC. Sprog som der ikke længere undervises i, hvorfor udbuddet af eksempelvis COBOL-kyndige i Danmark er meget lavt. Efterspørgslen er dog stadig til stede, så virksomheder kan være nødsaget til, selv at uddanne medarbejdere i eksempelvis COBOL.

Jeg læste denne artikel, om at Sundhedsplatformen er bygget med det 52 år gamle programmeringssprog MUMPS, og at “Næsten ingen programmører arbejder længere med MUMPS…“. Og rigtigt nok, så er MUMPS udviklere svære at finde. I.flg.Wiki’en er der blot en håndfuld virksomheder (bl.a. EPIC), som stadig arbejder med det.

Det kan være svært at finde legacyprogrammører. Derfor følger prisen for vedligeholdelse naturligvis principperne i udbud/efterspørgsel.

Foruden store vedligeholdelsesomkostninger, findes ofte problemer med skalering, utilstrækkelig dokumentation, videreudvikling, hastighed og effektivitet.

Overordnet set, findes 3 løsninger

  1. Accepter skyhøj risiko og pris – Byg et nyt system
  2. Forsæt som altid – “I morgens problem, er ikke i dags problem”
  3. Udbyg systemet – Integrér legacy med nye systemer og udfas evt. roligt legacy.

Fordele og ulemper ved løsning 1 åbenlyse. Hvis virksomheden har råd, og hvis samtlige aspekter er blevet så nøje gennemtænkt og planlagt, så det sikres at systemet kan bygges ordentligt; så er løsning 1 at foretrække. Denne løsning kræver dog enorme ressourcer. Der henvises til Sundhedsplatformen, Amanda, Rejsekortet, EFI, Polsag etc.

Løsning 2 er selvsagt. Problemet løses ikke. Det udskydes blot til et senere tidspunkt. I stedet risikeres det, at platformen en dag bryder sammen, og man står uden sit kritiske system. Løsning 2 kan dog være en udmærket løsning, hvis det givne system, hverken er kritisk eller har høj værdi for virksomheden. Hold da systemet i live til det dør af alderdom.

Den gode middelvej findes derfor i løsning 3. Denne er for det foretagende, som ikke er klar til at acceptere den ekstremt høje pris og de risici, som følger ved løsning 1, men som heller ikke kan undvære systemet, hvis det pludselig en dag bryder sammen.

Større etablerede virksomheder, som de jeg selv har oplevet, har ofte legacysystemer, og de mærker konsekvensen af det. Systemerne er langsomme, har ikke de nødvendige moderne funktioner og trænger gevaldigt til at blive skiftet ud.

Derfor kan virksomheder, som ikke klar til at udskifte hele systemet, vælge at udbygge deres nuværende legacy.

Den gyldne middelvej?

Over de seneste år, er der sket en revolution inden for integrations-teknologi. Teknologi, som særligt kan hjælpe virksomheder med gamle systemer. Moderne integrationsteknologi kan eksempelvis benyttes, til at afvikle monolitiske IT-systemer, skulle virksomheden ønske det.

Der er mange interessante måder at løse dette på. Én mulighed er, at bygge en ny og overskuelig frontend, som er den del af systemet, som medarbejderen ser. Det er ofte forbundet med mindre usikkerhed og færre ubekendte at bygge en ny frontend, end at ombygge hele grundsystemet (legacysystemet). Derfra integreres alle systemer virksomheden gør brug af (legacy eller ej), til en platform, som integreres videre til den nye frontend.

Tag dette billede som eksempel.

robotic process automation - api-integration_data-intergation_html24_IT-integration_system-integration

Alle ikonerne er systemer som CRM-systemer, e-mail, ERP, website, lager, journal, fragt, forældet legacy etc. Det store røde ikon i midten, er den integrationsplatform, som distribuerer data fra og til alle systemerne.

Laves en sådan løsning, så bruges de kritiske legacysystemer stadig, dog kun de brugbare (udvalgte) dele. Resten kan ignoreres fuldstændig. Derved bruger man systemernes kritiske funktionaliteter, til at bygge et distribueret microservice-system, som kan forlænge levetiden af legacysystemerne betydeligt.

Har man behov for ny funktionalitet, kan virksomheden med rette, blot udvide det samlede system, med det ønskede nye program. Dette giver ydermere virksomheden mulighed for langsomt at udfase legacy systemernes funktionalitet.

Den gode løsning?

Der findes mange måder at løse legacyproblemer på. Ingen virksomhed, fagforening, bank, statsforetagende, institut, hospital m.fl. er ens. Fælles er dog, at der altid findes en smart løsning til legacyproblemer.

Bør virksomheder feje problemet under gulvtæppet, eller bør de springe ud i et helt nyt system? Der er meget der skal overvejes inden. Måske virksomheder, i stedet bør overveje muligheden for, at forlænge det gamle systems levetid, og roligt udfase det på en smart måde.

I softwarevirksomheden HTML24 arbejdes ofte med kunder, som bruger legacysystemer. Som led i en sikker afvikling af legacysystemer, eller forlængelse af deres levetid, vil løsning 3 typisk blive valgt (Altså at man bevarer gamle systemer for en periode og integrerer disse med nyere platforme). Valget af løsning er altid afhængig af organisationens forretningsmæssige behov.

For nogle organisationer, findes der simple løsninger, som komplet kan udskifte deres legacysystemer, med lav risiko og lave omkostninger. For andre er risiko og omkostninger høje, hvorfor der med fordel kan laves en microservice-arkitektur, eller blot en simpel integration, giver det forretningsmæssig mening.