I 2020 opdagede den amerikanske rigsrevision en tikkende bombe: en dæmning, der blev drevet af et 18 år gammelt og høj-kritisk it-system.

Ved nærmere inspektion viste det sig, at hardwaren var forældet, og at hverken hardware eller software var supporteret af leverandøren.

Programmeringssproget var forældet, og teknologien havde kendte sårbarheder, som kunne forårsage alvorlig skade på både materiel, økonomi og mennesker.

Det var ikke en enlig svale.

Systemet indgik i en rapport, der afslørede, at 75 % af it-systemerne i den amerikanske stat ikke afsatte budget til modernisering.

På listen over de 10 mest kritiske it-systemer i rapporten var ikke blot dæmningen, men også et system som understøttede det amerikanske luftværns kampparathed. Man fandt i rapporten aldrig ud af, om det it-system overhovedet var supporteret. Man vidste det simpelthen ikke.

Et tredje af de forældede it-systemer var et system fra Homeland Security, som skulle sikre forbindelsen mellem lokaliteter, der indgik i det nationale nødberedskab.

Et fjerde var et klinisk sundhedssystem, hvis modernisering blev beskrevet som "imperativt". Det var bl.a. bygget på et 56 år gammelt programmeringssprog.

Og sådan fortsatte listen.

Et naturligt spørgsmål presser sig på: Ville det mon se meget anderledes ud, hvis Rigsrevisionen i Danmark undersøgte vores forhold?

Hvad var dit moderniseringsbudget sidste år?

Inden Rigsrevisionen kommer så langt, kan vi jo begynde med at spørge os selv hver især: Hvad var mit eget moderniseringsbudget sidete år?

Jeg tænker ikke på dit vedligeholdelsesbudget, men på dit moderniseringsbudget.

Hvis det er et rundt 0, er du på linje med 75 % af de amerikanske myndigheder og i den forstand ikke værre stillet end de fleste andre :-)

Men selvom du starter fra 0, kan du stadig arbejde med at forebygge Legacy. Legacy opstår over mange år, og derfor er det sjældent for sent at gå i gang.

Før vi dykker ned i detaljerne, er her min spiseseddel:

  • Hav en langsigtet strategi (få input til din strategi længere nede)
  • Afsæt budget, og evaluer din indsats
  • Skab overblik over dit interne moderniseringsbehov: Det gør din modernisering billigere på langsigt
  • Hav en evergreen-strategi for dine afhængigheder og hold øje med, hvornår dine eksterne komponenter går end of life: Det forebygger den frygtede big bang-modernisering
  • Stil krav til din leverandør

Forvent, at du skal modernisere

Men lad os starte ved begyndelsen: Forvent, at du skal modernisere.

Uanset hvor nyt dit system er, skal det moderniseres. Det skal ikke blot efterses for sårbarheder. Det skal ikke bare driftes. Det skal ikke alene vedligeholdes.

Det skal moderniseres.

Systemet skal opdateres med nye versioner af de grundkomponenter, det er bygget på. Eksisterende komponenter skal udfases, og nye komponenter skal indfases. Der skal pustes liv i gammel kode. Arkitekturen skal drejes.

Moderniseringer er irriterende, for man føler ikke rigtig, at man får noget for pengene. Det er jo groft sagt det samme system, man har i morgen efter en modernisering, som man havde i går, før man moderniserede.

Men det har også en fordel. For moderniseringer er sjældent kritiske. Hvis de altså bliver foretaget. Det er kun, hvis man flere år i træk nedprioriterer moderniseringer, at de bliver alvorlige, og ofte først efter et årti, at de bliver kritiske. Det afgørende er, at man gør det løbende.

Det betyder, at det er ret nemt at budgettere efter.

Læg en strategi, og afsæt en pulje penge, som er øremærket til modernisering, kom i gang, og evaluer, efterhånden som du lærer, hvad der fungerer i forhold til strategien. En lille pulje er bedre end ingen pulje.

Vid, hvad du skal modernisere som det næste

Moderniseringer kan bestå af opgraderinger eller udfasninger. Og kan være rettet mod både interne og eksterne komponenter.

Al modernisering har nogle øjeblikkelige fordele. Dem ser vi på herunder. Men al modernisering skal også bidrage til at udsætte en potentiel katastrofe: Big Bang-moderniseringen, hvor det samlede system er blevet så forældet, at der ikke er anden vej end at tage fat ved problemets rod. Det er et problem til et helt andet indlæg.

Interne opgraderinger og udfasninger

Interne opgraderinger og udfasninger er moderniseringer rettet mod de komponenter, du selv bygger. Når de moderniseres, kan det være med til at gøre en applikation nemmere at forstå og dermed billigere at ændre.

Det er særligt kritisk, hvis applikationen står over for store investeringer. Interne moderniseringsprojekter kan nemlig bidrage til at gøre systemet nemmere at forstå og dermed udgøre en stor besparelse, når du efterfølgende skal modernisere i større stil - det være sig enten på infrastruktur, kode, arkitektur eller sågar data-niveau. Når dit udviklingsteam siger, at det er vigtigt at investere i teknisk gæld, skyldes det ikke altid kun dit kortsigtede return of investment i form af billigere changes, færre fejl eller større medarbejderglæde, men også, at der er et langsigtet pay-off ved at udskyde eller forsimple en større modernisering. Og så er det altså også bare god karma.

Er du tæt på en stor modernisering, kan der derfor - i modsætning til hvad man skulle tro - faktisk være tilfælde, hvor det giver god mening at modernisere det kode, du snart skal til at lægge i graven.

Så det er min påstand, at hvis din kortsigtede effektiviseringsgevinst måles i hundrede af timer, måles din langsigtede gevinst i tusinder af timer.

Lad os se nærmere på de interne opgraderinger og interne udfasninger:

Interne opgraderinger fokuserer på kildekode eller infrastruktur, der er blevet ukontrollabel over tid.

Normalt skal den slags håndteres af den løbende vedligehold, men har vedligeholdelsesindsatsen været utilstrækkelig, er det et moderniseringsansvar at samle bolden op. Det kan fx ske, hvis systemets arkitektur og dets anvendelse er drevet fra hinanden, så arkitekturen ikke længere understøtter behovene. Eller hvis dele af applikationen over tid er blevet umulige at fejlsøge eller udvide.

Det er de områder af systemet, teamet ikke tør røre ved, fordi det altid går galt.

Hvordan finder du dem? Spørg teamet om, hvor der i kildekoden er mest spaghetti? :-)

Men i moderniseringsøjemed skal du fokusere på delt kode eller delte komponenter. Dvs. kode og komponenter, som andet kode eller andre komponenter er afhængige af. Det er sjældent lige så værdifuldt at modernisere kode, som ingen andre komponenter afhænger af - typisk højt i applikationsstakken. Det er en opgave til det løbende vedligehold.

Hvorfor? Fordi kode, som ingen afhænger af, kan du altid bare skrive om. Kode, som en masse andre afhænger af, er svært at skrive om, for andre dele af systemet har antagelser om den kode. Derfor kan der ud over kortsigtede gevinster være høj, langsigtet værdi i at forsimple koden. Også selvom den på sigt skal skrives helt om. Fordi det indirekte gør mange andre komponenter simplere.

Interne udfasninger fokuserer på de dele af applikationen, hvor en opgradering ikke længere er tilstrækkelig.

Her gennemføres fx en omskrivning, fordi et område i applikationen med tiden har vist sig at være designet forkert og dermed ikke blot kan opgraderes, men må underlægges en egentlig udfasning.

Metoden er den samme: Spørg teamet. Men vær i begge tilfælde opmærksom på at inddrage både udvikling, drift inklusive driftsleverandør og support. Og hav igen særligt øje på delte komponenter, som andre komponenter afhænger af.

Eksterne opgraderinger og udfasninger

Eksterne opgraderinger og udfasninger er moderniseringer af tredjepartskomponenter. Det kan især bidrage til at gøre drift og videreudvikling mere sikkert og effektivt, ligesom det forebygger en big bang-modernisering. Den løbende vedligehold af eksterne afhængigheder kan således udskyde den berygtede store modernisering.

Lad os se nærmere på de eksterne opgraderinger og eksterne udfasninger:

Eksterne opgraderinger kan håndteres effektivt igennem en evergreen-politik, hvor man fx sætter KPI'er for, hvor mange versioner centrale eksterne afhængigheder må være bagud og følger op på dette løbende. Fx 1 major version. Vi har implementeret et årshjul med automatiserede årshjulsopgaver, der sikrer, at vi ikke taber en komponent på gulvet. Alle komponenter kommer til eftersyn hvert år, og vi følger op på de kritiske komponenter hvert kvartal. Uanset om man har en egentlig politik eller ej, er det centralt løbende at gennemse komponenternes versioner og forholde sig aktivt til, om de skal opgraderes.

Nogle cloud-komponenter tilbyder en løsning, hvor man aldrig selv skal opgradere, men hvor cloud-leverandøren tager ansvaret for, at man altid kører på den seneste version. Det giver mulighed for at lægge moderniseringsansvaret ud til tredjeparten.

Har man et stort setup, er der for tiden også fokus på at etablere en egentlig software-stykliste (SBOM) på samme måde som du kender det i simpel form fra fx styklisten i et IKEA-samlesæt. Uden sammenligning i øvrigt :-) Microsoft har for nyligt (juni 2022) open sourcet deres SBOM-tool, som ser ud til at blive vedligeholdt ret aktivt. Det giver et overblik over ikke bare dine egne komponenter, men i princippet den fulde stykliste inklusive de komponenter, dine tredjepartskomponenter afhænger af.

Eksterne udfasninger kommer oftest på tale, når leverandøren af teknologien udfaser den. Mange store leverandører er omhyggelige med at fortælle allerede ved fødslen af en ny major version, hvornår den dør (er end of life/end of support). Men hold også øje med, om dit teknologiske landskab er håndterbart, eller om du har behov for at sende nogle af dine teknologier på pension, så du får en mere strømlinet teknologiportefølje at arbejde med. Følg derfor med i, om dine tredjepartskomponenter stadig er i support, og hav en moderniseringsstrategi for dem, før de dør.

Stil krav til din leverandør

Ejer du ikke selv din software, så gå i dialog med din leverandør. Måske er det ikke al information, de ønsker at dele i detaljer, men bed så i stedet om indsigt i deres interne processer for håndtering af forældet software, og interesser dig for, om de processer og deres artefakter er underlagt ekstern revision. Skal du i udbud, så stil moderniseringskrav i udbuddet.

Men jeg er ved at drukne i Legacy!

Så kan der stadig være initiativer, som vil gøre din Big Bang-modernisering nemmere - afhængigt af din moderniseringsstrategi. Men den store modernisering og strategien for den. Det er et indlæg til en anden dag.