Servicebaseret it-arkitektur kan sikre offentlig it og samtidig sænke omkostninger

Med en service-baseret it-arkitektur kan vi, som en af verdens mest digitaliserede nationer, sikre den it, der binder vores omfangsrige velfærdsmodel sammen.

De bedste offentlige it-løsninger gør arbejdet mere effektivt for de dygtige folk, der tager sig af os i mødet med den offentlige sektor. Samtidig sikrer løsningerne, at vores rettigheder og persondata beskyttes som individuelle borgere.

Som offentlige it-indkøber bør du stille din it-leverandør følgende spørgsmål:

”Hvordan sikrer I, at man kan udvikle og vedligeholde vores løsning løbende – både i forhold til sikkerhed, udviklingskrav og omkostning?”

Alt for ofte bliver der i de store it-udbud lagt uforholdsmæssig megen vægt på de umiddelbare omkostninger ved at bygge, modificere eller konfigurere et it-system. Man glemmer at forholde sig til de langsigtede perspektiver, hvor vedligehold og træghed i systemet kan ende med at tippe omkostningsbalancen på sigt.

Det har over tid resulteret i et væld af ufleksible offentlige it-monolitter, der frarøver forvaltningerne reel fremdriftskraft.

Monolitten er den samlede og lukkede it-stuktur som vi de fleste steder – trods vores gode intentioner –  fortsat ender med at bygge, når vi har behov for nye systemer. Men monolitten er dyr på længere sigt.

En mindre ændring kan medføre store omkostninger, fordi andre dele af løsningen risikerer at blive ødelagt, når vi eksempelvis ændrer på den underlæggende datastruktur.

Eksempel: Én dags arbejde kræver 14-dages test

En mindre udvidelse, der reelt kun burde tage en dag, kan ofte vare flere dage og eksempelvis ende i en 14-dages test.  Det sker, fordi det kræver tid og indsigt i store dele af løsningen at få overblik over konsekvenserne af ændringen, og fordi risikoen for fejl andre steder i løsningen er meget høj. Det bliver altså dyrt og omfattende at arbejde sikkert.

Det sker derfor ofte, at man forsøger at samle ændringer i større releases – hvert halve år eller måske bare én gang om året. Det giver dels en lang leveringstid for mindre ændringer og betyder samtidig, at man som kunde og bruger skal forholde sig til mange ændringer på én gang.

Det er i sig selv et problem, men ydermere bliver det at release komplekst og risikerer at introducere nye fejl, når de forskellige ændringer skal flettes sammen.

Over tid vil monolitten have tendens til at vokse, både i størrelse og kompleksitet, og de ovennævnte ændringer vokser med. Monolitten bliver derfor mere og mere statisk og kræver stadig stigende ressourcer til kvalitetssikring, hvilket gør at arbejdsgange og serviceniveau med stor sandsynlighed bliver dårligere over tid.

Løsning: En service-baseret it-arkitektur

Ovenstående er selvfølgelig langt fra tilfredsstillende. Derfor er flere og flere i gang med at skille de store monolitter ad og dermed genvinde udviklingspotentialet i deres it-struktur. Målet er at reducere omkostningerne og den stadigt sigende træghed i videreudviklingen af vores systemer.

En af de mest betydende faktorer i dette er at få opdelt systemerne i reelt uafhængige delsystemer. I monolitten har vi ofte forsøgt at opdele systemet i uafhængige moduler.

“I praksis er modulerne dog ikke uafhængige så længe de arbejder på de samme datastrukturer og databaseskemaer. Når vi virkelig ønsker at reducere ulemperne ved monolitten, er vi nødt til at ændre dette.”

Microservices driver dette princip til et ekstrem, men vi kan også komme langt med mindre drastiske indgreb på vejen til en service-baseret it-arkitektur.

Uafhængighed er det afgørende

Den afgørende faktor for en service-baseret it-arkitektur er uafhængigheden mellem de moduler og komponenter, som systemet opdeles i.

Modulerne skal have deres egne datastrukturer og databaseskema, som ikke er kendt af andre moduler, og der skal defineres snitflader i en kontrakt mellem modulerne, som kun indeholder den information de har til fælles.

De samme begreber kan sagtens findes i flere moduler, men der vil være forskel på det indhold og dermed den datastruktur, de har.

Sagsmodulet – et eksempel på det uafhængige modul

Et sagsmodul kan eksempelvis have en forholdsvis kompleks datastruktur for en sag, mens et dokumentmodul sandsynligvis kan nøjes med at en sag har et navn, et nummer og måske en status.

Ændringer i sagsmodulets datastruktur vil således være ufarlige for dokumentmodulet så længe snitfladen mellem dem fortsat leverer en sag med navn, nummer og status til dokumentmodulet.

“Modulopdelingen sikrer, at vi ikke ødelægger noget, så længe moduler overholder kontrakten med de andre moduler.”

Dermed vil testen for at implementere en mindre ændring i et modul være isoleret til at skulle overskue konsekvenserne inden for modulet. Der er således en meget større sandsynlighed for at ovennævnte en-dags opgave reelt vil kunne udføres inden for én dag, og at testopgaven reduceres til en tilsvarende størrelse.

Såfremt vi bygger vores systemer op som reelt uafhængige moduler og løbende sikrer, at vores moduler har en passende størrelse, vil vi kunne reducere omkostningerne til videreudvikling betydeligt. Dermed får vi langt bedre mulighed for at sikre fremdrift og tilpasning af vores systemer.