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

Home / Det offentlige / Service-baseret 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, og de sikrer samtidig at vores rettigheder og persondata beskyttes som individuelle borgere.

Desværre er det ikke helt lige til at tage den rette beslutning om it-leverandøren, da de langsigtede omkostninger for udviklingen af et it-system er svære at overskue.

Med mange års erfaring fra leverandørsiden af de offentlige it-systemer, har jeg gjort mig en række overvejelser om problematikken. Her er ét enkelt spørgsmål, du som den offentlige it-indkøber bør stille din it-leverandør:

”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.

Service-baseret it-arkitektur bør erstatte de klassiske monolitter
Service-baseret it-arkitektur bør erstatte de klassiske monolitter.

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.

Et eksempel fra monolittens verden: É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 det værste er dog, at alene det at release bliver komplekst og risikerer at introducere nye fejl, når de forskellige ændringer skal flettes sammen.

Release bliver for tungt
Med en monolittisk it-arkitektur bliver realease og vedligehold for tungt.

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øsningen: 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.

Service-baseret it-arkitektur
It-systemer bør moduliseres i uafhængige enheder ud fra et serviceprincip.

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 efter min opfattelse kan vi 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.

Service-baseret it-arkitektur
Monolitten skal brydes op i uafhængige moduler.

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.

Mit svar som mangeårig softwarearkitekt i det offentlige

Min faglighed og erfaring viser, at 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.