Nyt udspil til offentlig it-arkitektur: Vi gider ikke flere spaghetti-integrationer

Nye regler for it-arkitektur skal sikre sammenhæng mellem offentlige systemer. På sigt kan reglerne blive kanon for hele den offentlige sektor.

Digitaliseringsstyrelsen har i dag offentliggjort første skud på reglerne for en fælles it-arkitektur, som skal diktere, hvordan it-systemer i det offentlige skal skrues sammen, hvis de skal være i stand til at samarbejde på tværs.

I første omgang vil arkitektur-reglementet gælde alle de konkrete projekter, som er outlinet i den fællesoffentlige digitaliseringsstrategi, der udkom i sommer. Og på sigt kan resten af den offentlige it-udvikling komme med om bord.

Formålet er at undgå, at det offentlige it-landskab består af en serie af isolerede øer, fortæller Jens Krieger Røyen, der er chef i kontoret for data og arkitektur hos Digitaliseringsstyrelsen.

Læs også: Digitaliseringsstyrelsens direktør: Vi leverer markante resultater

»Den måde vi i dag bygger it-systemer på, er ved at vælge standarder og metode fra gang til gang, fra ø til ø. Det vil sige, at når systemer skal kobles sammen, er det et stort og komplekst udviklingsprojekt hver gang,« siger han til Version2.

Situationen kan sammenlignes med den som rejsende stod i før EU fik harmoniseret strømstik, fortæller kontorchefen; hver gang man skulle et sted hen, skulle man have et særligt stik med.

»Her har vi ikke otte forskellige standarder - vi har mange, mange, mange flere varianter. Vi har brug for at have noget fælles. Vi har brug for en offentlig sektor, der er bygget til sammenhæng,« siger Jens Krieger Røyen om projektet.

Gammel vision - nye regler

Problemstillingen er velkendt. Personer der skal udsluses fra fængsler eller har brug for hjælp for både misbrug og en psykisk lidelse havner ofte i et digitalt ingemandsland.

Rambølls undersøgelse 'IT i praksis' vidste sidste år, at den offentlige sektor er usammenhængende, når man betjener sig selv online.

Læs også: It-undersøgelse: Digitale tjenester hænger ikke sammen på tværs af myndigheder

Visionen om at gøre noget ved det er også genkendelig. Ambitionen stod klar allerede i 2003, da Digitaliseringsstyrelsen udgav sin første hvidbog om it-arkitektur:

'Digital forvaltning handler i høj grad om at få de offentlige IT-systemer gearet til at spille sammen,' skrev styrelsen for 14 år siden.

Hvis forordet fra den gamle hvidbog var byttet ud med forordet i den hvidbog, som styrelsen i dag har offentliggjort, ville mange nok ikke studse videre over det.

Men til forskel fra 2003-udgaven kommer de nye regler for it-arkitektur til at være lov for alle it-projekter under de 33 initiativer, der er beskrevet i sidste års digitaliseringsstrategi.

Læs også: Ny digitaliseringsstrategi møder kritik: »Blottet for målbare initiativer«

'På den måde afprøves og modnes den fælles arkitektur,' lyder det i hvidbogen.

»Vi er nået meget langt med den punktvise digitalisering, og nu kan vi se til siden og på potentialet i at skabe sammenhængen. Det er tydeligt, at vi står uden et fælles sprog og en fælles byggevejledning, til at gøre det,« siger Jens Krieger Røyen.

»Og med en stor ulyst til at skulle opfinde det hele fra gang til gang med spaghetti-integrationer. For det bliver både svært og dyrt.«

Opskrift på persondataforordning

Under den overordnede vision har arbejdsgruppen placeret 8 principper for it-arkitektur, der detaljerer ambitionerne. Under principperne er der udstukket i alt 19 arkitektur-regler, som it-projekterne skal følge.

Det sidste kritiske lag for reglerne er endnu ikke udarbejdet. Her skal de standarder og metoder, som projekter skal følge, beskrives detaljeret.

Det vil sige fælles regler for hvordan data dokumenteres, fælles standarder for api'er og en fælles arkitektur for datasikkerhed.

Læs også: Kommentar: Datasikkerhed i regioner er pakket ind i ubrugelige selvfølgeligheder

»Hver gang man har et it-projekt overvejer man, hvilke standarder og metoder, man skal bruge, og hvordan man skal dokumentere arkitekturen,« forklarer Jens Krieger Røyen.

»Der kan sagtens være fem forskellige gode måder at gøre det på, men man skal tage stilling til det hver gang. Og vi kunne lige så godt have en fælles måde at gøre det på, for beskæftigelsesområdet er ikke teknologisk forskelligt fra uddannelsesområdet eller skatteområdet,« fortsætter han.

Læs også: Estlands it-direktør til Danmark: Tag del i open source datasamarbejde

En af de tilføjelser, der kommer til arkitekturen, er en opskrift på, hvordan man praktisk og operationelt kan indlejre EU's nye persondataforordningen i sin arkitektur.

»Så man i et it-projekt ikke selv skal sidde med forordningsteksten og prøve at lure, hvad det betyder i praksis,« forklarer Jens Krieger Røyen.

Råb op

Fælles standarder, specifikationer og metoder skal i sidste ende fjerne en masse arbejde fra projekterne - og dermed spare på kompleksiteten, tiden, pengene og risikoen.

De mange siders teknisk specifikation skal laves i løbet af det næste halvandet år. Og hvis arkitekturen viser sig at være solid, vil regeringen sammen med KL drøfte, om den skal gælde for hele den offentlige sektor.

Læs også: Version2’s læsere: Hvor er de kompetente it-folk bag offentlige it-projekter?

Men inden da håber Jens Krieger Røyen at få input til, om arkitekturprincipperne, som arbejdsgruppen har udpeget, er de rette.

»Det er første gang siden 2003 vi etablerer en samlet ramme for styring af it-arkitektur i den offentlige sektor. Inden vi gør den færdig, vil vi gerne lægge den ud til bred debat for at høre, hvordan vi gør den bedre,« siger kontorchefen.

Jens Krieger Røyen opfordrer derfor også Version2's læsere til at råbe op, hvis der er principper eller grundregler, der burde skæres anderledes end i udkastet fra Digitaliseringsstyrelsen.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (7)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Morten Brørup

Der kan sagtens være fem forskellige gode måder at gøre det på, men man skal tage stilling til det hver gang. Og vi kunne lige så godt have en fælles måde at gøre det på, for beskæftigelsesområdet er ikke teknologisk forskelligt fra uddannelsesområdet eller skatteområdet.

Der er også mange forskellige måder at få byggematerialer til at hænge sammen på. Nogle gange er lim velegnet, nogle gange er loddetin velegnet, nogle gange er søm, skruer eller bolte velegnede, sommetider er mørtel bedst. Og andre gange er et stykke reb eller en skruetvinge det helt rigtige. Det er helt forkert at tro, at "one size fits all"!

Jeg vil derimod opfordre til, at man vælger den bedste løsning til den individuelle opgave. Og på dette punkt kan arkitekturdokumentet indeholde en række eksempler på opgaver og anbefalede løsninger.

Vi har også meget ofte set, at offentlige udviklere har tendens til at genopfinde den dybe tallerken pga. "not invented here"-syndrom.

Derfor vil jeg yderligere anbefale, at man stiller som krav, at der kun undtagelsesvis (og med krav om dokumenteret begrundelse for, hvorfor undtagelsen var nødvendig!) må benyttes selvopfundne protokoller, API'er osv., hvis der findes industristandarder indenfor området. Fx ingen hokuspokus-kryptering (fx NemId JAVA applets), hvis der kan benyttes TLS (fx HTTPS). Og ingen smarte selvopfundne datastrukturer (fx OIOXML), hvis der kan findes industristandarder (fx XBRL). Det har den ekstra fordel, at det er lettere at få et system til at snakke sammen med andre (internationalt udbredte) systemer.

NB: Jeg rammer muligvis lidt forbi med mine eksempler, men jeg håber, at de fremmer forståelsen.

mvh
Morten Brørup
CTO, SmartShare Systems

  • 7
  • 0
Martin Jünckow

Grundlæggende enig, at forsøge at standardisere på arkitekturniveau er håbløst og en forældet tankegang der har vist sig meget dyr i praksis.

Standardiser på snitflader og dataformater og slip ellers arkitekturbeslutningerne fri. For mange tværgående krav forsinker og fordyrere projekterne.

  • 4
  • 0
Lasse Lindgård

"Den måde vi i dag bygger it-systemer på, er ved at vælge standarder og metode fra gang til gang, fra ø til ø. Det vil sige, at når systemer skal kobles sammen, er det et stort og komplekst udviklingsprojekt hver gang"

Jeg tror at vi får blandet en masse ting sammen her.

Arkitektur for enkelte applikationer:
Hvis vi tager det modsatte af at alle laver ting forskelligt, så bliver det at alle laver ting ens. Det betyder også at man aldrig kan bliver klogere og at man ikke kan følge med den tekniske udvikling. Som kunde ville jeg være mere på vagt, hvis en leverandør kommer med samme tilgang som de havde for 5-10 år siden.

Arkitektur for integrationer:
Når vi snakker eksterne grænseflader, så er det ganske rigtigt meget værdifuldt at der ikke er alt for mange tilgange. Her har der også løbende været lavet tiltag i det offentlige. OIO var vel starten. Og nu er man i gang med den store Datafordeler. Jeg ved ikke hvordan det går med eksekvering, men tanken om en EventBus for offentlige data er meget, meget sund!

Non-funktionelle krav:
Hvis digitaliseringsstyrelsen med en arkitektur, mener det som står i billedboksen, så kan det jo gå an. Det er en række non-funktionelle krav, som trods alt giver store friheder til at løse den konkrete opgave optimalt. Og så skal man altid lige huske at prøve at sætte "ikke" foran hver af dem og se om det er noget nogen kunne finde på ikke at gøre af sige selv.

Mangler:
Jeg savner meget at alle offentlige it projekter udvikles som Open Source projekter. Det ville give optimale vilkår for at genbruge arkitektur, kode og viden på tværs. Og det er noget de har stor succes med i England.

Jeg savner også en retningslinje for hvor store systemer, som skal udvikles. En tilgang med flere mindre systemer er sund for at undgå alle skandalerne. Det giver også bedre mulighed for at inddrage mindre leverandører.

  • 7
  • 0
Esben Nielsen

Hvis man løbende skal vedligeholde systemerne - hvis man vil undgå det skal man udskifte kæmpe systemer på een gang, og det ved vi jo hvor godt det går..

Jeg mener, man bør lave en masse små systemer, som man løbende kan opdatere og udskifte efterhånden som tingene ændrer sig. Disse små systemer kan også små selvskaber byde ind på - så længe man kræver åbne snitflader.

Sådan en samling af systemer vil være "spaghetti" med nogle oversættere eller gateways ind i mellem, noget oversættelse fra login på et system til et andet etc. (f.eks en service som fra en ticket fra et AD kan udstede et X509 certifikat til systemer der bruger det som adgangssystem.)
Det offentlige - og ikke nogle tilfældige private firmaer - skal holde et kort over denne spaghetti-infrastrukturen og holde styr på kravene for systemerne, så man netop kan udskifte dele undervejs.

  • 2
  • 0
Jesper Frimann

Det er ikke for sarte sjæle at lave overordnede Strategiske Arkitektur Principper, eller for den sags skyld at lave EA artifakter og deliverables i større org. Og 'det offentlige' er en mastodont org. Og det er, sagt i samme åndedrag, ikke nemt i sådanne store org.'er da der er ekstremt meget politik. Så det kan ende op med at blive det muliges kunst af et kompromis.

Men jeg synes det er lidt deprimerende. For det her dokument viser jo med alt tydelighed, at vi er på offentlig IT arkitektur siden har lidt et knæk. Mange af de arkitektur 'standarder' m.m., som 'skal laves' eksisterede jo i Datacentralen og Kommunedata Regi for 15-20 år siden.
Ja selvfølgelig ville disse dokumenter, set med dagens øjne, være seriøst obsolete. Men det havde de ikke behøvet at være, hvis man havde beholdt 'arkitektur delen' af Datacentralen og Kommune data, og løbende videreudviklede disse dokumenter.

Når man læser arkitektur hvidbogen, så ja.. det er ikke en nem opgave, men det er IMHO ikke, hvad man har brug for i 'det offentlige'.
En af de vigtigste opgaver for arkitektur er valg/beslutninger og derigennem også fravalg af ting. Og der er simpelt hen for mange selvmodsigelser, på den ene side skal du rette dig efter overordnede standarder og principper men på den anden side kan du også selv bestemme.
Og der er rigtig meget 'af det farlige' der skubbes ud til 'projekterne'.

Så ja..

// Jesper

  • 2
  • 0
René Løhde

Jeg vil forvente at de fleste IT-arkitekter kan implementere systemer, som kan sætte kryds ved alle de gode principper, men til hvilken pris?

Jeg savner at dette arbejde bringes ind i en omkostningskontekst. Ord som 'pris' og 'omkostninger' findes ikke i artiklen og kun et enkelt sted i strategi-dokumentet.

  • 2
  • 0
Log ind eller Opret konto for at kommentere