Vejledning til FDA Rammearkitektur

UDKAST

Januar 2018

2

Forord I forbindelse med godkendelsen af hvidbogen om fællesoffentlig digital arkitektur i maj

2017 blev det aftalt, at der skal etableres en fællesoffentlig rammearkitektur (”FDA

Rammearkitektur”) i regi af den fællesoffentlige digitaliseringsstrategi 2016-2020.

Formålet er at understøtte sammenhængende digitale services, datadeling og

tværgående samarbejde. FDA Rammearkitekturen skal være et redskab til gode

arkitekturvalg. Den skal fungere som et fælles sprog og skabe overblik over den fælles

base af standarder, specifikationer og komponenter.

Formålet med denne vejledning er, at give en indføring i grundkoncepterne i forhold til

den fællesoffentlige rammearkitektur. Den primære målgruppe er forretnings- og it-

arkitekter, som skal anvende rammearkitekturen som en integreret del af deres

arbejde i forbindelse med offentlig digitalisering.

Rammearkitekturen kan ses som en samling af legoklodser med tilhørende

vejledninger i, hvordan man bruger dem: De overordnede vejledninger er

referencearkitekturer indenfor forskellige områder som fx brugerstyring. De giver

principper, sprog og løsningsmønstre for løsninger i forbindelse med digitalisering. De

udpeger desuden de vigtigste byggeblokke, som skal anvendes. Det kan være i form af

specifikationer og standarder, men de kan også pege på løsninger og komponenter, der

konkret udmønter dele af FDA Rammearkitekturen. Fx er MitID og NemLogin løsninger,

der kan anvendes til at efterleve referencearkitektur for brugerstyring, som er den

første godkendte FDA referencearkitektur.

FDA Rammearkitektur er underlagt styring af styregruppen for data og arkitektur.

Projekterne i digitaliseringsstrategien skal følge de fællesoffentligt aftalte krav til

anvendelse og underlægges arkitekturreview.

Den første udgave af Vejledning til FDA Rammearkitektur forventes godkendt og

publiceret i løbet af første halvår 2018. Dette udkast sendes i offentlig kommentering i

januar 2018 med det formål at få kvalificeret det overordnede koncept for

rammearkitekturen.

3

Indhold

Forord................................................................................................................... 2

Introduktion ......................................................................................................... 4

Del 1: Grundkoncept ............................................................................................. 4

Formål ....................................................................................................................... 4

Hvem skal følge FDA Rammearkitektur? ................................................................... 5

Hvad er FDA Rammearkitektur? ................................................................................ 6

Arkitektur på forskellige niveauer ............................................................................. 8

Fælles fundament for lokale løsninger ...................................................................... 9

Fra strategi til realisering ......................................................................................... 11

Projekternes arkitekturarbejde ............................................................................... 12

Løsningsarkitektens brug af FDA Rammearkitektur ................................................ 14

Centrale begreber i FDA Rammearkitektur ............................................................. 15

Katalog over byggeblokke i FDA-arkitekturreol ...................................................... 20

Konceptuel model for præsentation af rammearkitekturen .................................. 22

Del 2: Styringskoncept ......................................................................................... 24

Fælles tværgående styring ...................................................................................... 24

Rammearkitekturens frembringelse og vedligehold ............................................... 25

Model for fordeling af roller og ansvar ................................................................... 32

Del 3: Krav .......................................................................................................... 33

Principper for efterlevelse (gyldighedsgrad) ........................................................... 33

Typer af tjenester (it-løsningstyper) ....................................................................... 34

Afgrænsning af dækningsområde (gyldighedsområde) .......................................... 35

Administration af krav ............................................................................................. 36

Rådgivning og yderligere information .................................................................. 36

4

Introduktion

Dette dokument beskriver de overordnede rammer for den fællesoffentlige

rammearkitektur (FDA Rammearkitektur) på konceptuelt niveau. Dokumentet er

målrettet arkitekter (entreprise arkitekter, forretningsarkitekter, løsningsarkitekter) og

udgøres af tre dele:

Del 1: Grundkoncept beskriver den grundlæggende fortælling om rammearkitekturen,

herunder beskrivelse af de centrale begreber.

Del 2: Styringskoncept beskriver de styringsmæssige rammer for rammearkitekturens

frembringelse og vedligeholdelse, herunder koncepter for procedurer, processer, roller

og ansvar.

Del 3: Kravkoncept beskriver en model for krav til rammearkitekturens anvendelse.

Del 1: Grundkoncept

FDA Rammearkitektur kan betragtes som en samling af legoklodser med tilhørende

vejledninger i, hvordan man bygger digitale løsninger – med fokus på alle de relevante

aspekter fra jura til teknik.

Den fællesoffentlige hvidbog om digital arkitektur er udtryk for en stærk vision, fælles

mål og klare principper for, hvordan staten, kommunerne og regionerne i fællesskab vil

skabe et sammenhængende digitalt Danmark. FDA Rammearkitektur er et vigtigt fælles

skridt i realiseringen af dette. Rammearkitekturen vil være en katalysator for at bringe

Danmark op på et nyt niveau af digital modenhed, hvor der kan skabes sammenhæng

fra det internationale til det lokale, og hvor den enkelte myndighed kan bygge egne

løsninger på et fælles fundament.

Formål FDA Rammearkitektur har fokus på det fælles – det der eksisterer mellem

myndigheder, organisationer og aktører. FDA Rammearkitektur skal modvirke, at

systemer leveret af forskellige leverandører til forskellige aktører giver silo-systemer,

der ikke taler sammen. Rammearkitekturen er således en form for byggevejledning, der

gælder på tværs af aktører og sektorer, og som skal bruges for at bygge

sammenhængende løsninger.

FDA Rammearkitektur understøtter fælles mål i forbindelse med digitalisering og den

fælles arkitekturvision, som er formuleret i hvidbogen om digital arkitektur udarbejdet

i regi af Den fællesoffentlige digitaliseringsstrategi 2016-2020 (FODS). Heraf følger

5

også, at det er behovene i FODS initiativerne der bestemmer, hvilke elementer, der skal

indgå i rammearkitekturen.

FDA Rammearkitektur skal være et redskab til gode arkitekturvalg, der understøtter

FODS initiativernes udvikling og drift af sammenhængende it-løsninger.

Rammearkitekturen skal skabe overblik over den fælles base i form af mønstre,

standarder, specifikationer og komponenter, der med fordel kan anvendes. En

væsentlig rolle for FDA Rammearkitektur er også at bidrage til at udpege områder, hvor

der er behov for fælles standarder, specifikationer og fælles løsninger.

Rammearkitekturens vigtigste rolle er at rammesætte og understøtte udvikling og drift

af sammenhængende it-løsninger ved at sætte rammer for arbejdet med

løsningsarkitektur i digitaliseringsprojekter, som er led i digitaliseringsstrategien. Det

kan fx være fælles infrastrukturkomponenter som Digital Post, MitID eller et

Kontaktregister. Det kan også være projekter, som har til formål at understøtte

samarbejde og datadeling gennem nødvendig tilpasning af eksisterende eller

kommende løsninger hos den enkelte myndighed eller fælles løsninger i et domæne

som fx sundhedsdomænet eller i kommunerne. Det kan fx være i forbindelse med

realisering af mål om selvbetjeningsløsninger der understøtter bedre og tværgående

brugerrejser. En væsentlig rolle for rammearkitekturen er også at bidrage til at udpege

områder, hvor der er behov for fælles standarder og fælles løsninger.

Nedenstående figur illustrerer hvordan rammearkitekturen er styret og understøtter

fælles forretningsmål og sætter rammer for og understøtter udvikling af it-løsninger til

fælles og lokale projekter, som er underlagt den fælles styringsramme.

Hvem skal følge FDA Rammearkitektur? FDA Rammearkitektur skal anvendes af projekter under digitaliseringsstrategiens

initiativer. Dette omfatter dels løsningsprojekter vedrørende fællesoffentlige

komponenter og services i form af infrastrukturløsninger som fx borger.dk og virk.dk,

6

digital post, MitId og NemLogin, dels projekter, der indebærer at myndigheders

løsninger skal kunne arbejde samme og dele data. Desuden er rammearkitekturen

styrende for det fællesoffentlige arbejde med at udvikle fælles standarder i regi af

strategien.

Krav og anbefalinger i forhold til rammearkitekturen gælder som hovedprincip, når der

er tale om nyudvikling eller større ændringer. Der kan derudover aftales nærmere om

implementering i eksisterende løsninger efter nærmere aftale mellem de offentlige

parter og eventuelt andre berørte parter. Der kan derudover være andre regelsæt, der

kræver ændringer i eksisterende løsninger.

Rammearkitekturen kan anvendes af offentlige myndigheder og digitaliseringsprojekter

i øvrigt. Governance for overholdelse af kravene i løsninger, der ikke er omfattet af

aftalerne i den fællesoffentlige digitaliseringsstrategi, skal således aftales i den

konkrete kontekst af de relevante aktører.

Hvad er FDA Rammearkitektur? FDA Rammearkitektur kan betragtes som en samling af legoklodser med tilhørende

vejledninger i, hvordan man bygger digitale løsninger – med fokus på alle de relevante

aspekter fra strategiske mål for opgaveløsning til teknisk løsning. FDA Rammearkitektur

er med andre ord en fællesoffentlig enterprise arkitektur med et særligt fokus på

interoperabilitet på tværs af domæner.

Rammearkitekturen udgøres på sigt af de elementer, som er særligt vigtige at

indarbejde i digitale løsninger. På overordnet niveau beskrives disse i en række

referencearkitekturer, som giver en fælles fortælling om, hvordan man laver digitale

løsninger i form af principper, sprog og løsningsmønstre i forbindelse med

digitalisering. På et detaljeret niveau består rammearkitekturen af byggeblokke, i form

af fx specifikationer og standarder, og kan pege på løsninger og komponenter, der

konkret udmønter dele af rammearkitekturen. Fx er MitID og NemLogin løsninger, der

kan anvendes til at efterleve referencearkitektur for brugerstyring.

Den første version af den fællesoffentlige rammearkitektur bygges op omkring

referencearkitekturer som behandler væsentlige emner og problemstillinger, som har

bredt ophæng i digitaliseringsstrategiens initiativer. Der er for nuværende identificeret

behov for seks referencearkitekturer ud fra behovene i FODS projekter. Disse samt

deres status og forankring er givet nedenfor:

1. Selvbetjening (Status: Færdig / Ansvar: Initiativ 1.2.)

2. Overblik over egne sager og ydelser (Status: Udvikling / Ansvar: Initiativ 1.3)

3. Tværgående processer (Status: Kandidat / Ansvar: Ikke aftalt)

4. Deling af data og dokumenter (Status: Udvikling / Ansvar: Initiativ 8.1)

5. Brugerstyring (Status: Optaget / Ansvar: Initiativ 8.1)

6. Robust og sikker drift (Status: Kandidat / Ansvar: Ikke aftalt )

7

Efterfølgende figur illustrerer, hvordan disse seks referencearkitekturer udgør de

overordnede puslespilsbrikker, og derved udgangspunktet for arbejdet med FDA

Rammearkitektur.

Referencearkitekturerne skal bidrage til at skabe kapaciteten til at understøtte en

effektiv, sammenhængende og transparent service for borgere og virksomheder, som

er målrettet den enkeltes behov gennem:

Referencearkitektur for selvbetjening har fokus på borgernes og virksomheders møde

med de digitale services, og skal gøre anvendelsen så nem og overskuelig som muligt

for borgere og virksomheder og samtidig understøtte innovation og effektivisering i

den offentlige opgaveløsning.

Referencearkitektur for overblik over egne sager og ydelser har fokus på at skabe

overblik for borgere og virksomheder vedrørende sagsbehandling og udbetaling af

ydelser. Til forskel fra referencearkitekturen for selvbetjening er udgangspunktet ikke

datafangst, men adgang til oplysninger og status på sager, ydelser og lign.

Referencearkitektur for tværgående processer har fokus på, at processer på tværs af

myndigheder såvel som mellem den offentlige og den private sektor, skal kunne hænge

sammen via udnyttelse af løse koblinger og deling af data. Til forskel fra

referencearkitektur for selvbetjening omhandler denne også processer, der ikke

indebærer selvbetjening, men fx samarbejde om administrativ sagsbehandling i flere

myndigheder eller om patientbehandling på tværs af hospital og hjem.

Referencearkitektur for deling af data og dokumenter har til formål at vejlede i valget

mellem mønstre for videregivelse af oplysninger, herunder anvendelse af udstillede

8

data - typisk via API i system-til-system-integrationer samt forsendelse af meddelelser

indeholdende data, herunder dokumenter.

Referencearkitektur for brugerstyring har fokus på styring af brugere og rettigheder på

tværs af it-services i føderationer på grundlag af fælles sikkerhedsmodeller, standarder

og infrastruktur.

Referencearkitektur for sikker og robust drift har fokus på sikker, robust og effektiv

infrastruktur for driften af de it-services, der indgår på alle lag og områder i det fælles

digitale økosystem, men med fokus på de centrale dele og på sikring mod kritiske

nedbrud og kaskadeeffekter.

Disse seks referencearkitekturer dækker tilsammen en række centrale områder i

opbygningen af offentlige digitale løsninger, som sikkert og effektivt skal kunne fungere

i samspil med henblik på tværgående brugerrejser og processer samt deling af data.

De enkelte referencearkitekturer er bedste bud på nuværende tidspunkt. Den enkelte

referencearkitektur forventes derfor at blive genstand for revision med henblik på fx at

opdatere indholdet efterhånden som der gøres erfaringer, nye behov opstår og nye

områder modnes. Tilsvarende vil der kunne aftales yderligere referencearkitekturer,

som supplerer de seks områder, som allerede er identificeret.

Referencearkitekturerne beskriver vision og mål og udpeger de vigtigste byggeblokke.

De beskriver på konceptuelt niveau hvordan, de skal bringes i anvendelse. De enkelte

referencearkitekturer kan revideres med udvidet scope eller suppleres med yderligere

referencearkitekturer. Fx vil det være relevant at referencearkitektur for brugerstyring

suppleres med emnerne samtykke og fuldmagt.

Byggeblokke er de elementer, som arkitekturen og løsninger består af. Disse kan deles

op i to grundtyper, som begge indgår i rammearkitekturen:

Arkitekturbyggeblokke der er abstrakte elementer, som arkitekterne bruger til at

specificere løsninger.

Løsningsbyggeblokke der er konkrete elementer, som opfylder en

arkitekturbyggebloks specifikationer og kan indgå i løsninger.

FDA Rammearkitektur er defineret ved det til enhver tid gældende indhold, som er

godkendt af styregruppen for data og arkitektur, som værende del af

rammearkitekturen. Et samlet overblik vil blive publiceret og opdateret løbende på

FDA’s hjemmeside arkitektur.digst.dk.

Arkitektur på forskellige niveauer Det er ikke et mål at definere alle elementer i den fællesoffentlige arkitektur for

digitalisering. Fokus er på det nødvendige og tilstrækkelige for at sikre

9

sammenhængende, effektive og sikre digitale it-services, der understøtter tværgående

processer og datadeling.

Hvidbogen fastslår som overordnet princip, at arkitektur skal styres på rette niveau

efter fælles rammer. Det dækker et spænd fra den lokale løsningsarkitektur til

internationale tekniske standarder. De fleste it-løsninger udvikles reelt i et spændfelt

mellem løsningsarkitektur for projektets konkrete løsning, enterprise arkitektur for den

ansvarlige organisations it-portefølje og hensyn til tværgående samarbejde og

datadeling, som understøttes af fælles interoperabilitetsarkitektur. På alle niveauer kan

der defineres en målarkitektur, som er styrende for en given løsning.

FDA Rammearkitektur svarer på mange måder til den fælleskommunale

rammearkitektur, hvor fokus er på monopolbrud og tværgående sammenhæng i de

kommunale it-løsninger og til det fælleseuropæiske samarbejde om arkitektur og

infrastruktur, hvor fokus er på interoperabilitet over landegrænser. Tilsvarende

fastlægges der fælles arkitektur, standarder og infrastruktur i et domæne som

sundhedsområdet. FDA Rammearkitektur kan betragtes som en national profilering af

det fælleseuropæiske arbejde med arkitektur, standarder og infrastruktur (fx EIF, EIRA

og CEF Digital). Aktører, der leverer byggeblokke og it-løsninger til det danske digitale

økosystem, skal i princippet også orientere sig mod EU. FDA Rammearkitektur vil her

hjælpe disse aktører ved at fungere som en indgang, således at de fleste aktører kan

nøjes med at forholde sig til EU-perspektivet indirekte via FDA.

Fælles fundament for lokale løsninger FDA Rammearkitektur er både fælles rammer og et fælles fundament for den enkelte

myndighed, når de skal anskaffe og tilpasse løsninger. Det skal være nemt at bygge og

EIF, EIRA og CEF Digital

The European Interoperability Framework (EIF) - er udgangspunkt for The European Interperability Reference Architecture (EIRA). EIRA er en grundlæggende referencemodel, der definerer de vigtigste arkitekturbyggeblokke set i relation til at etablere interoperable digitale services. EIRA definerer en taksonomi over de centrale begreber og deres vigtigste relationer. EIRA kan ses som et grundlæggende fundament for FDA Rammearkitektur. EIRA er udviklet i regi af programmet Interoperability Solutions for European public Administration (ISA). EIRA definerer over 150 byggeblokke, som vurderes relevante for at skabe interoperable digitale tjenester. Den danske rammearkitektur vil så vidt muligt bygge på EIRA. I EIF beskrives visionen om det digitalt sammenhængende Europa som det digitale indre marked (DSM) , hvor det digitale grundlag for EU’s fundamentale rettigheder vedrørende fri bevægelse af services, varer, borgere og kapital implementeres. For at facilitere og accelerere udviklingen af DSM tilbyder EU gennem initiativet Connecting Europe Facility (CEF) et antal arkitektur- og løsningsbyggeblokke (CEF Byggeblokke), der understøtter grundlæggende kapabiliteter til implementering af sammenhængende offentlige services, fx eID, eDelivery, eInvoicing og eTranslation.

10

anskaffe lokale løsninger, der kan indgå i et digitalt økosystem med andre digitale

løsninger på tværs af myndigheder, domæner og landegrænser, hvor det er relevant.

Også selv om de enkelte løsningsbyggeblokke kommer fra mange forskellige

leverandører. Det skal være nemt at levere til det offentlige, på baggrund af klare

rammer, gennemsigtig styring af den fælles rammearkitektur og adgang til relevant

information.

Nedenstående figur illustrerer opbygningen af et fælles fundament af arkitektur,

standarder og fælles infrastruktur for den enkelte løsning. Fundamentet spænder fra

det internationale og fællesoffentlige til et afgrænset domæne som fx

sundhedsområdet eller det fælleskommunale område.

Formålet med det fælles fundament er - via fælles arkitektur- og løsningsbyggeblokke,

at danne grundlag for effektive, sikre og interoperable løsninger, når myndigheder og

virksomheder skal anskaffe nye eller tilpasse eksisterende løsninger. Derfor er

samarbejde, koordinering og sammenhæng på tværs af de enkelte lag også afgørende.

De orange kasser i toppen af figuren viser projekters it-løsninger, som er sammensat af

– og dermed genbruger - en række forskellige arkitektur- og løsningsbyggeblokke, som

kan være defineret, specificeret, udviklet og leveret fra et eller flere af de

underliggende lag i modellen.

Figuren illustrerer også, at både it-løsninger og genbrugelige arkitektur- og

løsningsbyggeblokke, udvikles, vedligeholdes og anvendes på forskelligt niveau og i

forskellig styringskontekst. Hver kasse i figuren repræsenterer en egen

styringskontekst. Et eksempel kan være, at en it-løsning i hjemmeplejen, på hospitalet

og hos den privatpraktiserende læge skal overholde fælles standarder udpeget af

Sundhedsdatastyrelsen, som bygger på internationale standarder for

sundhedsområdet. Samtidig med dette skal de samme løsninger overholde standarder

som anvendes fællesoffentligt på tværs af ressortområder, fx til

brugerrettighedsstyring og dataudveksling.

11

Typisk vil initiativet til fælles arkitektur, standarder og infrastruktur komme fra de

overordnede internationale eller nationale niveauer.. FDA Rammearkitektur kan

imidlertid også få indhold fra et domæne eller lokalt niveau. Det kan fx være fordi, der,

som grundlag for tværgående snitflader på tværs af to forvaltningsområder, er behov

for at udarbejde fælles, sammenhængende begrebs- og datamodeller.

For at der er tillid til det fælles fundament skal dette leve op til de relevante behov og

krav til udvikling, drift og vedligeholdelse på tværs af niveauer. Dette udgør en

grundlæggende styringsmæssig udfordring, som der skal tages højde for gennem

samarbejde og koordinering både horisontalt og vertikalt.

Fra strategi til realisering Nedenstående figur viser hvordan, der med udgangspunkt i den fællesoffentlige

digitaliseringsstrategi og Hvidbogen om fællesoffentlig digital arkitektur kan etableres

sammenhængende løsninger.

I den øverste del er det de overordnede strategiske perspektiver der er i spil. Her

udpeges områder for fælles referencearkitektur og byggeblokke i form af standarder og

infrastruktur. Eksempler på områder er selvbetjening, brugerstyring og deling af data

og dokumenter. Det indledende arbejde for FDA Rammearkitektur består i at

udarbejde en række referencearkitekturer, som fastlægger de vigtigste principper og et

fælles sprog ved at udpege og definere arkitekturbyggeblokke. Figuren viser, hvordan

der i forlængelse af dette kan gennemføres uddybende strategiske analyser, uddybning

af arkitekturbyggeblokke samt vurdering af relevante standarder. Og endelig hvordan

der på baggrund af dette kan der fastlægges målbillede og strategi for realisering og

migrationer. Målbilledet beskriver de ønskede kapabiliteter og de byggeblokke, der

12

skal til for at opnå disse. Migrationsstrategien beskriver de overordnede skridt der skal

til i forhold til udvikling og ibrugtagning af byggeblokkene i alle de relevante løsninger.

De strategiske beslutninger på ledelsesniveau danner grundlag for arkitekternes

arbejde med udvikling af referencearkitekturer og arkitektur- og løsningsbyggeblokke,

herunder fastlæggelse af fælles standarder og specifikation af krav til fælles

infrastruktur. Det kan fx vedrøre fælles krav til datas egenskaber og snitflader samt

anvendelse af særlige infrastrukturkomponenter som fx MitID. På dette niveau

udformes en detaljeret plan, som understøtter strategien for realisering og migration.

På det nederste niveau er det leverandørerne (i praksis både kunden og den

kommercielle leverandør), der går i gang med at designe og udvikle de konkrete

løsningsbyggeblokke - ligesom når håndværkerne går i gang med at bygge et hus. Her

kan en række fælles byggeblokke være en forudsætning for, at lokale løsninger kan

udvikles. Når de fælles løsningsbyggeblokke i form af standarder og infrastruktur er på

plads, er det fælles fundament lagt for udrulning i lokale løsninger hos den enkelte

myndighed - og ud til borgere og virksomheder.

Projekternes arkitekturarbejde I forlængelse af Hvidbog om fællesoffentlig digital arkitektur udarbejdes en fælles

dokumentationsramme med et sæt retningslinjer for arkitekturdokumentation i

digitaliseringsprojekter. Projekter skal udarbejde relevant arkitekturbeskrivelse,

således at projekter kan styres og koordineres med henblik på at udvikle it-løsninger,

der understøtter sikker og effektiv deling af data og tværgående processer.

Standarden ISO/IEC/IEEE 42010 “systems and software engineering - architecture

description” definerer fire områder, som skal indgå i arkitekturarbejdet:

Arkitekturbeskrivelse, Arkitekturperspektiver, Arkitekturrammeværk og

Arkitekturbeskrivelsessprog. Et arkitekturperspektiv (viewpoint) er en formalisering af

en måde at se på en arkitektur på, fra et bestemt synspunkt, som udtrykker en eller

flere interessenters bekymringer. Et arkitekturrammeværk er et sæt af prædefinerede

og forbundne arkitekturperspektiver. Ifølge ISO 42010 standarden skal en

arkitekturbeskrivelse omfatte følgende:

Identifikation og overblik over den arkitektur som udtrykkes

En kort beskrivelse af hvad arkitekturen handler om i sin essens. Fx hvilke

forvaltningsopgaver der skal understøttes og hvilke it-komponenter der indgår?

Her skal et digitaliseringsprojekt lave en kort beskrivelse der i tekst og billeder

beskriver den tekniske løsning i en forretningskontekst. Fx i form af et overordnet

målbillede, der beskriver de mest centrale elementer (byggeblokke) og deres

relationer og egenskaber.

13

Identifikation af interessenter (stakeholdere) og deres bekymringer (concerns)

Fx ledelse, jurister og sikkerhedseksperter i forhold til strategi, styring,

lovmedholdelighed og sikkerhed. Eller borgeren og medarbejderen som brugeren i

forretningen. Eller informationsarkitekt og udvikler i forhold til applikation og

integrationer. Eller dem som er ansvarlige for infrastruktur og drift.

Her skal projektet lave et kortfattet overblik over de vigtigste interessenter med en

liste af deres fælles eller individuelle “spørgsmål” til løsningens egenskaber

Definition af de arkitekturperspektiver der anvendes i arkitekturbeskrivelsen og en

mapning til interessentbekymringer til disse

En formalisering af en måde at se på en arkitektur på, fra et bestemt synspunkt, som

udtrykker en eller flere interessenters bekymringer. Her definerer FDA i alt otte

grundlæggende perspektiver - et for hver af hvidbogens principper. Disse kan mappes

til andre kendte arkitekturrammeværker som det europæiske EIF/EIRA, TOGAF og OIO

EA. Retningslinjer for arkitekturdokumentation i digitaliseringsprojekter definerer

nogle minimumskrav til visninger (views), der udarbejdes med brug af Archimate i

projekterne i FODS. Derudover kan projekterne frit udarbejde supplerende visninger

med brug af Archimate konventioner. Ligeledes kan projekterne udarbejde andre

visninger, som følger relevante standarder som fx BPMN eller UML. For sådanne kan

der være supplerende regler som fx Fællesoffentlige regler for begrebs og

datamodeller.

Her skal projektets dokumentation understøtte gældende fællesoffentlige

retningslinjer for udarbejdelse af arkitekturdokumentation i

digitaliseringsprojekter.

En arkitekturvisning og dets arkitekturmodeller for hvert arkitekturperspektiv

Her definerer FDA i alt otte grundlæggende visninger (et for hvert af hvidbogens otte

principper) på overordnet niveau. Disse kan suppleres med yderligere visninger og

modeller, fx en uddybende proces- eller datamodel. Disse tegnes med brug af

modelsproget Archimate, som anvendes til en helhedsorienteret beskrivelse på

overordnet niveau på tværs af de otte perspektiver. Derudover vil der i et projekt

typisk være behov for uddybende beskrivelser af fx processer og arbejdsgange (i

BPMN) som del af opgaveperspektivet eller begreber og data (i UML) som del af

informationsperspektivet. Archimate, BPMN og UML er arkitekternes sprog, som skal

sikre præcision, men dette kan ikke forstås af alle og skal derfor ofte suppleres med

mere enkle og letforståelige visualisering og forklaringer.

Her skal projektet udarbejde overordnet dokumentation i Archimate og supplere

med andre beskrivelser efter behov i forhold til projektet og hvor langt det er.

NB! Som generelt kommunikationsprincip bør projektet udarbejde det der skal til

for at kommunikere til den pågældende målgruppe (interessenter/stakeholdere).

14

Regler for sammenhæng, information om sammenhæng og en liste over kendt

inkonsistens mellem det indhold der kræves i arkitekturbeskrivelsen

Det kan fx være regler for fælles begreber og genbrug af data eller regler for

samarbejde mellem applikationer og deres snitflader. Udgangspunktet er her de krav,

som er beskrevet i de fællesoffentlige arkitekturregler, som er defineret i hvidbogen.

Her skal projektet kort beskrive de væsentligste relationer og udfordringer som fx

inkonsistens i begreber, data eller snitflader, som skal indgå i en løsning der skal

understøtte tværgående samarbejde og genbrug..

Arkitekturrationale

Forklaringer, begrundelser, rationaler for beslutninger i forhold til den beskrevne

arkitektur. I tværoffentlig sammenhæng er der særligt fokus på de valg, som har

betydning for tværgående samarbejde og genbrug af data og fælles løsninger.

Her skal projektet beskrive - kort eller langt efter behov - de væsentligste

overvejelser og beslutninger med konsekvens for løsningens arkitektur, herunder

funktionelle og ikke funktionelle egenskaber.

Løsningsarkitektens brug af FDA Rammearkitektur Når et projekt skal udvikle en ny it-løsning eller videreudvikle en eksisterende løsning,

vil projektets løsningsarkitekt kunne tage udgangspunkt i FDA Rammearkitekturs

referencearkitekturer og byggeblokke, som er beskrevet i Archimate. Der vil typisk

være supplerende vejledninger, der giver støtte til hvordan man anvender disse

enkeltvist eller i sammenhæng.

Det kan fx være en myndighed, der skal anskaffe en selvbetjeningsløsning med

integration til eksterne registre og til eget fagsystem og ESDH system. Her vil

rammearkitekturen fx kunne bidrage med referencearkitekturer, herunder vedrørende:

- Selvbetjening som beskriver en grundlæggende fælles arkitektur for selvbetjening

med fokus på gode og tværgående brugerrejser

- Sag og ydelse, der beskriver en arkitektur for at levere et tværoffentligt overblik til

borger eller virksomhed over egne sager og ydelser

- Deling af data og dokumenter, der beskriver en fælles tilgang til deling og genbrug

af data, herunder modeller for integration mellem it-systemer

- Brugerstyring, der beskriver en tværgående arkitektur for håndtering af

brugerrettigheder

Desuden vil FDA Rammearkitektur kunne bidrage med en række mere konkrete

løsningsbyggeblokke i form af fx:

- Begrebs- og datamodeller for de data, som skal udveksles og som kan danne

grundlag for anvendelsesprofil til udarbejdelse af snitfladebeskrivelser

15

- Meddelelsesformat for forsendelse af dokumenter der sendes via digital post

- Protokoller for teknisk udveksling

- Teknisk specifikation af token til bruger-id og rettighedsstyring

Løsningsarkitektens opgave er bl.a. at sætte FDA-byggeblokkene ind i egen kontekst og

beskrive dette.

Det vil sige, at arkitekten - ud fra projektets formål og kontekst – skal identificere de

relevante byggeblokke. Det sker ved – ud

fra egen skitse - først at finde de relevante

arkitekturbyggeblokke i det fælles FDA-

katalog over byggeblokke.

Når man har identificeret en FDA-

byggeblok, tjekker man, om der i

kataloget også peges på en konkret

løsningsbyggeblok, og om der er formelle

krav til, at den skal, bør eller kan

anvendes.

Arkitekten skal hvor relevant argumentere for valg og eventuelle behov for tilpasning

eller videreudvikling, fx i form af profilering af eksisterende specifikationer.

Byggeblokkataloget kan betragtes som fælles baseline og omfatter byggeblokke fra

både Danmark og EU.

Løsningsarkitekten vil kunne finde vejledning i, hvordan man bruger den fornødne

“lim” når man skal anvende byggeblokkene i praksis, herunder muligheder og

begrænsninger i forhold til lokal tilpasning og til- og fravalg.

Løsningsarkitekten kan ved at anvende FDA-retningslinjerne for projekters

arkitekturdokumentation lave egen dokumentation i form af arkitekturmodeller, der

genbruger relevante dele af FDA Rammearkitekturens modeller.

Fællesnævneren er her brugen af modelleringssprog, som er standarden Archimate for

den overordnede arkitektur og UML for begrebs og datamodeller. Løsningsarkitekten

kan hente disse modeller online og importere dem i eget værktøj, idet de overholder et

åbent og standardiseret udvekslingsformat.

Centrale begreber i FDA Rammearkitektur Arbejdet med FDA Rammearkitektur indebærer en fælles forståelse af og tilgang til

arkitekturarbejdet. Dette afsnit beskriver - med udgangspunkt i nedenstående

begrebsmodel - de centrale begreber og deres sammenhæng i forhold til arbejdet med

at udvikle og anvende FDA Rammearkitektur.

16

Rammearkitektur er arkitektur inden for en veldefineret, organisatorisk kontekst, som

sætter fælles rammer for arkitektur i denne kontekst.

Arkitektur er en struktur af komponenter, deres indbyrdes relationer og de principper

og retningslinjer, der styrer deres design og udvikling over tid. Komponenterne - eller

elementerne - er det der også beskrives som byggeblokke, når der er fokus på genbrug

af arkitekturelementer.

En byggeblok repræsenterer en (potentielt genanvendelig) del af en forretnings-, IT-

eller arkitektonisk kapabilitet, der kan kombineres med andre byggeblokke til at levere

løsninger.En model er en repræsentation af et emne af interesse. Den centrale del af

arkitekturarbejdet - det logiske arbejde - kan beskrives som modellering og en

arkitektur som en arkitekturmodel. En rammearkitektur eller en løsningsarkitektur kan

betragtes som overordnede arkitekturmodeller, mens en byggeblok er et segment af

de overordnede modeller.

En arkitekturmodel kan beskrive en tilstand på et givent tidspunkt: En eksisterende

arkitektur (as is), en fremtidig målarkitektur (to be eller målbillede) eller en arkitektur

på vejen fra as is til to be (transition). En målarkitektur kan være beskrevet mere eller

mindre detaljeret og ud fra forskellige perspektiver og med forskelligt omfang. Fx kan

en målarkitektur kan være en overordnet beskrivelse af de fremtidige fællesoffentlige

digitale infrastrukturkomponenter på teknisk niveau. Eller en konkret

løsningsarkitektur kan fx være en detaljeret beskrivelse af de byggeblokke, der skal

indgå i en given løsning.

FDA Rammearkitektur skal ses i forhold til begrebet enterprise arkitektur, som også

kaldes EA eller virksomhedsarkitektur. EA er en end-to-end (holistisk), domæneneutral

tilgang til design af arkitekturen for en enterprise eller en løsning. Omfanget for det vi

kalder ”enterprise” kan være en enkelt organisation (fx virksomhed eller styrelse), en

koncern (fx et ministerium eller en kommune) eller tværorganisatorisk på grundlag af

en samarbejdsaftale (fx fællesoffentligt eller fælles europæisk). Målet med EA er at

skabe sammenhæng mellem strategi, forretningsudvikling og it-portefølje. FDA

Rammearkitektur er en slags enterprise arkitektur med fokus på tværorganisatorisk

interoperabilitet.

Nedenstående figur viser de centrale dele af FDA Rammearkitektur universet.

17

Fortællingen til denne figur er i korte træk:

FDA Rammearkitektur følger hvidbogens otte principper og beskrives

helhedsorienteret gennem otte perspektiver på interoperabilitet, som understøtter

principperne.

FDA Rammearkitektur udfoldes gennem en række referencearkitekturer, som definerer

en række fælles, genbrugelige arkitekturbyggeblokke indenfor et afgrænset område.

Arkitekturbyggeblokke specificerer en række egenskaber ved det digitale løsninger

indenfor et eller flere af de otte perspektiver. Hver af disse er der logisk set kun én af.

Løsningsbyggeblokke er byggeblokke, der kan realisere en arkitekturbyggebloks

specifikationer. Hver af disse kan der være flere alternativer af, som man kan vælge

mellem.

Løsningsskabeloner peger på en række arkitektur- og løsningsbyggeblokke i relation til

en afgrænset type løsninger, og kan anvendes som grundlag for løsningsarkitektur.

Løsningsarkitektur er en beskrivelse af en bestemt forretningsaktivitet, og hvordan it

understøtter denne aktivitet.

Løsninger følger en løsningsarkitektur og implementerer løsningsbyggeblokke.

I det følgende beskrives de centrale begreber nærmere.

Rammearkitektur FDA Rammearkitektur er en generaliseret arkitektur, som ikke er løsnings- eller

organisationsspecifik, men gælder indenfor en kontekst, nemlig Den fællesoffentlige

18

digitaliseringsstrategi 2016-2020. Dvs. en kontekst som til enhver tid kan defineres

gennem aftalerne i samarbejdet mellem de fællesoffentlige parter i Danmark.

FDA Rammearkitektur baseres på en referencemodel og en arkitekturstil.

Referencemodellen beskriver ontologien over komponenter og deres relationer og er i

FDA-regi Archimate, der er forankret i Open Group. Arkitekturstilen er overordnet

serviceorienteret arkitektur (SOA), som kan realiseres på mange forskellige måder. FDA

Rammearkitekturs fokus er på tværgående processer og datadeling og på de

nødvendige og tilstrækkelige fællesnævnere i forhold til den til enhver tid givne aftalte

kontekst. FDA Rammearkitektur udfoldes gennem en række referencearkitekturer.

Hvidbogens arkitekturprincipper FDA Rammearkitektur følger den fællesoffentlige hvidbog om fællesoffentlig digital

arkitektur, som definerer otte overordnede arkitekturprincipper. Principperne

suppleres af en række supplerende arkitekturregler, som fastlægger god praksis.

Principperne anvendes som led i styringen af fællesoffentlige digitaliseringsprojekter

og dækker tilsammen otte perspektiver på den digitale arkitektur: Styring, strategi,

jura, sikkerhed, opgaver, information, applikation og infrastruktur.

Arkitektur- og interoperabilitetsperspektiver Et arkitekturperspektiv er et perspektiv ud fra hvilken en arkitektur kan anskues for at

sikre, at et bestemt emne bliver belyst på en konsistent måde - fx sikkerhed. I

sammenhæng med FDA Rammearkitektur, hvor der er særligt fokus på

interoperabilitet, kan vi også kalde disse for interoperabilitetsperspektiver.

FDA Rammearkitektur definerer otte perspektiver, som vi også kan kalde

interoperabilitetsperspektiver: Styring, strategi, jura, sikkerhed, opgaver, information,

applikation og infrastruktur. De otte perspektiver er en fælles grundstruktur i en

helhedsorienteret dokumentation og dækker tilsammen hvidbogens otte principper.

FDA Rammearkitektur bygger her på det europæiske interoperabilitetsrammeværk

(EIF).

Figuren viser de otte grundlæggende arkitekturperspektiver med EU-betegnelserne

nævnt i parentes. Hvert af de

horisontale perspektiver kræver

særlig opmærksomhed, når en ny

offentlig service skal udvikles –

populært sagt: Fra lov til løsning. I

FDA Rammearkitektur suppleres

disse grundlæggende perspektiver af

tre perspektiver - styring, strategi og

sikkerhed som tilsvarende kræver

særlig opmærksomhed, men som

19

også går på tværs af de fem førstenævnte perspektiver. Styring på alle områder,

strategi for forhold til lovgivning, og sikkerhed end-to-end..

Referencearkitektur FDA Rammearkitektur udfoldes gennem arkitekturdokumenter, kaldet

referencearkitekturer. En FDA-referencearkitektur er en generaliseret arkitektur, der er

baseret på best-practise erfaring og beskriver en domæneneutral arkitektur indenfor et

afgrænset fokusområde. En FDA-referencearkitektur er en helhedsorienteret

fortælling, der dækker hvidbogens otte arkitekturprincipper og tilsvarende

arkitekturperspektiver. En FDA-referencearkitektur udpeger og definerer

arkitekturbyggeblokke og kan anvendes til at pege på løsningsbyggeblokke og områder

for fælles standarder og fælles løsninger, herunder særligt fælles

infrastrukturkomponenter.

Arkitekturbyggeblokke En byggeblok er en delmængde som beskriver et enkelt aspekt af den overordnede

arkitekturmodel. En FDA arkitekturbyggeblok (ABB) er, baseret på TOGAFs defintion og

EIRAs fortolkning, en abstrakt komponent, som indfanger arkitekturkrav og som styrer

og vejleder udviklingen af løsningsbyggeblokke. En ABB repræsenterer en (potentielt

genbrugelig) komponent af kapabilitet inden for et af de otte hovedperspektiver, som

kan kombineres med andre byggeblokke. EN ABB kan kombineres af andre ABB (højere

niveau ABB), og kan således have forskelligt niveau af kompleksitet. En ABB beskriver

generiske karakteristika og funktionalitet. ABB anvendes til at beskrive

referencearkitekturer, løsningsarkitekturskabeloner og løsningsarkitektur for konkrete

løsninger.

Løsningsbyggeblokke En FDA løsningsbyggeblok (LBB) er, baseret på TOGAFs defintion og EIRAs fortolkning,

et konkret element, som definerer implementeringen og overholder de specificerede

forretningskrav i forhold til en eller flere arkitekturbyggeblokke. I et teknisk perspektiv

(applikation og infrastruktur) er en LBB et specifikt produkt eller en

softwarekomponent, som enten kan udvikles eller købes. I de øvrige perspektiver er de

typisk dokumentation, fx i form af en konkret procesmodel (opgave-perspektiv) eller

datamodel (informations-perspektiv).

Løsningsarkitekturskabelon En løsningsarkitekturskabelon er en specifikation, der indeholder en delmængde af

FDA-byggeblokke og nogle eventuelt yderligere mulige byggeblokke. Den fokuserer på

de vigtigste byggeblokke, som er nødvendige i forhold til at bygge en interoperabel

løsning, der adresserer en bestemt forretningskapabilitet, som indebærer deling af

forretningsinformation. En løsningsarkitekturskabelon kan trække elementer fra flere

FDA-referencearkitekturer og vil kunne pege på abstrakte arkitekturbyggeblokke og på

konkrete løsningsbyggeblokke, som aftales i forhold til anvendelse i et givent domæne.

20

Løsningsarkitektur En løsningsarkitektur er, med udgangspunkt i TOGAF, en beskrivelse af en bestemt

forretningsaktivitet, og hvordan it understøtter denne aktivitet. En løsningsarkitektur

omfatter typisk et enkelt projekt. Den støtter oversættelsen af krav til detaljerede

specifikationer af krav til forretningens opgaveløsning og it-systemets egenskaber. Den

understøtter ligeledes planlægningen af en portefølje af implementeringsopgaver. En

løsningsarkitektur kan understøttes af en løsningsarkitekturskabelon. En

løsningsarkitektur kan beskrive en tilstand på et givent tidspunkt. Fx den aktuelle

tilstand (as is) og den ønskede fremtidige tilstand (to be eller målarkitektur) eller

tilstand på vejen (transitioner).

Løsning En løsning består af en eller flere løsningsbyggeblokke, som opfylder et givent behov

hos en interessent. En it-løsning er opfyldelse af et system- eller forretningsbehov, der

involverer it som middel til opfyldelse af behovet. Ideelt set er en it-løsning en

implementering af en løsningsarkitektur. Indenfor konteksten af FDA Rammearkitektur

er en løsning typisk en interoperabel it-løsning, der understøtter deling af information

mellem offentlige myndigheder, med borgere og virksomheder og på tværs af

landegrænser.

En løsning kan være omfattet af målarkitektur på flere niveauer og i flere kontekster.

Udover den grundlæggende målarkitektur for løsningen i sig selv, kan den fx indgå som

del af en samlet målarkitektur på entreprise arkitektur niveau for en myndighed hvor

fokus er på effektiv drift eller som del af en fællesoffentlig målarkitektur som led i den

fællesoffentlige digitaliseringsstrategi, hvor fokus er på egenskaber i forhold til

interoperabilitet.

Katalog over byggeblokke i FDA-arkitekturreol FDA Rammearkitektur indeholder en stor mængde fælles arkitektur- og

løsningsbyggeblokke, som arkitekter og andre aktører i offentlige

digitaliseringsprojekter skal kunne orientere sig i. Derfor er det vigtigt, at det er så

nemt som muligt at finde disse.

Alle byggeblokke placeres i et katalog, der er struktureret som en reol, som dækker de

otte perspektiver. Arkitekturreolen deles desuden op i tre abstraktionsniveauer:

Konceptuel, logisk og fysisk.

Det konceptuelle niveau repræsenterer det, som er den arkitektoniske tolkning af

forretningens forståelse, og som ledelsen ønsker at skab. Det logiske niveau

repræsenterer arkitekternes og specialisternes bud på, hvordan det kan designes, og

det fysiske niveau repræsenterer leverandørernes og udviklernes bud på, hvordan det

kan bygge i praksis i en given kontekst.

21

Med en fælles arkitekturreol bliver det nemmere at dele og genfinde byggeblokke efter

en fælles systematik ligesom på et bibliotek. Nedenstående figur illustrerer en række

tænkte eksempler på arkitektur- og løsningsbyggeblokke, der er placeret i de

forskellige dele af helhedsperspektivet og på de tre abstraktionsniveauer i en

arkitekturreol.

Kataloget over byggeblokke opbygges med udgangspunkt i en taksonomi over de

grundlæggende arkitekturbyggeblokke. FDA-taksonomien har taget udgangspunkt i og

er mappet til EIRAs taksonomi, der definerer ca. 150 arkitekturbyggeblokke (version

2.0). Den kan således betragtes som en dansk profilering af EIRA. FDA Rammearkitektur

definerer på baggrund af arbejdet med de fire første referencearkitekturer yderligere

pt. cirka 100 arkitekturbyggeblokke, der er specialiseringer af de basale byggeblokke i

EIRA. Der er således i alt defineret cirka 250 arkitekturbyggeblokke fordelt på de otte

FDA-arkitekturperspektiver per november 2017 (version 0.5).

Hvor det er relevant opmærkes byggeblokke med angivelse af hvilket domæne, de er

relevante i forhold til.

På hjemmesiden for FDA, arkitektur.digst.dk, vil der [i løbet af 1. halvår 2018] være

oplysninger om byggeblokke, herunder information om status og krav til anvendelse.

22

Konceptuel model for præsentation af rammearkitekturen Byggeblokkene kan fordeles på en række funktionelle hovedområder i en konceptuel

model over det digitale økosystem, som er udviklet i regi af det fælleseuropæiske

rammeværk for interoperabilitet (EIF), jf. højre del i nedenstående figur : Styring af

integrerede offentlige tjenester. Populært kaldet ”spillepladen”.

Modellen består af seks hovedområder:

1. Aktører, som omfatter brugerne og de roller som de kan tildeles.

2. Adgang og integrerede offentlige services, som er de tjenester inkl.

brugergrænsefladen, disse kan anvende

3. Koordinering og integration af servicelevering, som er det mellemlag, der søger for

at sætte indholdet sammen til understøttelse af den enkeltes aktuelle opgave

4. Kataloger, som er en støtte til koordinering og integration, hvor der deles

information om fx hvor kildedata findes og er modelleret

5. Datakilde og grundlæggende services, er det lag hvorfra tjenesterne henter de

data, som præsenteres for brugeren og til fx at foretage beregninger

6. Sikkerhed og privatliv, som går på tværs af de øvrige områder med henblik på at

understøtte tværgående sikkerhed og privacy.

Sammenhængen til FDA-referencearkitekturerne er i store træk:

Referencearkitekturerne for selvbetjening, overblik over sag og ydelser samt

tværgående processer har især fokus på hovedområderne aktører, adgang og

23

integrerede tjenester samt koordinering og integration af servicelevering. Kataloger er

en vigtig støttefunktion.

Referencearkitekturene for deling af data og dokumenter, for sikker og robust

infrastruktur samt brugerstyring har fokus hovedområderne datakilder og

grundlæggende services og sikkerhed. Også her er kataloger en vigtig støttefunktion.

Nedenstående figur er en visning, der viser illustrerer et højniveau overblik over de

vigtigste arkitekturbyggeblokke, som er identificeret i arbejdet med ovennævnte

referencearkitekturer. NB! Der er pt. tale om et tidligt udkast pr januar 2018. Kun de

vigtigste elementer er medtaget af hensyn til overskueligheden i denne visning.

Udvælgelsen er begrundet i at arkitekturbyggeblokke anvendes i flere

referencearkitekturer eller er helt centrale for den enkelte referencearkitektur. Der er

tale om en blandet visning med fokus på byggeblokke der vedrører

hovedperspektiverne opgaver, information og applikation. Byggeblokkene er i denne

visning indplaceret i forhold til hovedområder i den konceptuelle model –

”spillepladen”. Bemærk også, at de basale EIRA byggeblokke ikke er synlige i denne

visning.

24

Del 2: Styringskoncept

For at leve op til de visioner og målsætninger, som parterne har til FDA

Rammearkitektur, er der behov for en stærk governance i forhold til de elementer, som

godkendes og efterfølgende publiceres på FDA hjemmesiden arkitektur.digst.dk, som

en del af FDA Rammearkitektur.

Rammearkitekturen forventes at være i løbende udvikling. Eksisterende elementer vil

blive opdateret og nye vil komme til.

Fælles tværgående styring Den fællesoffentlige rammearkitektur styres efter de rammer, der er fastlagt i

hvidbogen.

I regi af digitaliseringsstrategien er det Styregruppen for data og arkitektur (SDA), der

har ansvaret for den fællesoffentlige digitale arkitektur. SDA løser denne opgave med

reference til Porteføljestyregruppen for digitaliseringsstrategien, der igen refererer til

parterne bag digitaliseringsstrategien: Regeringen, KL og Danske Regioner.

SDA har følgende opgaver i regi af digitaliseringsstrategien:

- At fastlægge og levere en fælles arkitektur for digitaliseringsstrategiens initiativer,

konkret hvidbog og tilhørende referencearkitekturer, specifikationer, standarder

mv.

- At sikre anvendelse af den fælles digitale arkitektur på tværs af hele

digitaliseringsstrategien under hensyntagen til det enkelte initiativs business case,

herunder foretage reviews af arkitekturen i digitaliseringsstrategiens initiativer.

SDA har det overordnede ansvar for FDA Rammearkitektur, herunder tværgående

koordinering og kvalitetssikring af referencearkitekturer og byggeblokke samt ansvar

for optagelse af referencearkitekturer, byggeblokke og standarder og specifikationer i

FDA Rammearkitektur. SDA har, med bistand fra sekretariatet for 8.1 forankret i

Digitaliseringsstyrelsen, tillige ansvar for at den fællesoffentlige arkitektur

vedligeholdes. Herunder at der skabes de fornødne rammer og aftaler om

vedligeholdelse af de enkelte elementer.

SDA er ansvarlig for at overvåge, at alle rammearkitekturens væsentlige elementer er

forankret i en ansvarlig organisation. Dette kan være i fællesoffentlig styregruppe e.l.

Det er det enkelte projekt og ansvarlig styregruppe, der har det initielle ansvar for

frembringelse og vedligehold af referencearkitekturer og byggeblokke indtil andet

aftales.

25

Rammearkitekturens frembringelse og vedligehold Det fællesoffentlige samarbejde om arkitektur og standarder er under løbende

udvikling og revision på baggrund af input fra en række forskellige kilder.

Model for input til rammearkitekturen Indholdet i FDA Rammearkitektur kommer forskellige steder fra:

1. Elementer, som repræsenterer givne vilkår for offentlige digitale løsninger, og som er givet ud fra lov og forpligtende aftaler på internationalt og nationalt plan, fx GDPR-forordningen og persondataloven. Disse indarbejdes løbende i rammearkitekturen af sekretariatet for initiativ 8.1 som en del af den fælles dokumentation og overblik over rammesættende arkitektur. Formålet hermed er at støtte overblik, rådgivning og arkitekturreview. Disse elementer kan betegnes som vilkårs- og forudsætningselementer

2. Elementer, som parterne aftaler udvikles i regi af FODS, og som forankres og vedligeholdes af en ansvarlig aktør eller et fælles forum efter aftale med SDA. Det kan fx være fælles begrebs- og datamodeller. Disse elementer kan være baseret på internationale standarder (dansk profilering) eller udviklet fra bunden i regi af strategien (egenudviklede elementer)

3. Endelig indgår der i FDA Rammearkitektur også elementer, som parterne identificerer som relevante, men som er udviklet i andet regi og derfor skal vurderes egnede til at indgå i rammearkitekturen. Det kan fx være en teknisk standard i form af en transportprotokol. Disse kan optages gennem godkendelse af SDA. Denne type elementer kan danne grundlag for egenudviklede elementer i form af fx dansk profilering af standarder (adopterede elementer)

Denne grundlæggende opdeling er illustreret i nedenstående figur.

Det bemærkes, at governance i forhold til FDA-rammearkitektur kun relaterer sig til

egenudviklede og adopterede elementer.

26

Model for modning af FDA-elementer Et element i FDA Rammearkitektur, uagtet om det er en referencearkitektur eller en

byggeblok, gennemgår typisk en modning fra idé til at elementet er i en sådan tilstand,

at det kan godkendes til optagelse i FDA Rammearkitektur. I løbet af denne modning vil

der skulle ske et arbejde med at konkretisere idéen, udvikle, teste og afprøve

elementet i pilotprojekter, dialog med interessenter m.m. Der arbejdes derfor med fem

kategorier af status for elementer i FDA Rammearkitektur: Koncept, udvikling, ,

godkendt, optagetog udfasning.

Kandidat – betyder at elementet er kandidat til at indgå i FDA-rammearkitekturen.

Udvikling – betyder at elementet enten udvikles, videreudvikles eller vurderes i

forhold til egnethed, hvis det allerede eksisterer. Dette omfatter også afprøvning

og ”servicetjek”.

Færdig – betyder at elementet er godkendt som færdigt og klar til anvendelse ved

beslutning i det forum som er ansvarligt for projektet (fx en styregruppe).

Optaget – betyder at elementet er optaget i FDA ved beslutning i SDA.

Udfases – betyder at elementet ikke længere anbefales anvendt fremadrettet ved

beslutning i SDA.

De første tre kategorier – kandidat, udvikling og færdig kan betragtes som en pipeline

for indholdet i rammearkitekturen. Dermed kan elementer med denne status være

relevante at kende for projekter, selv om de ikke er optaget. Disse elementer guider

projekter i deres planlægning, så det er tydeligt hvad der er under udvikling til

fællesoffentligt brug og dermed også, hvad et projekt evt. ikke selv behøver at

udarbejde samt eventuelle kommende krav til en given løsning.

Kategorien optaget er de elementer, som efter vurdering og eventuelt afprøvning er

fundet egnede til optagelse i FDA Rammearkitektur. Disse skal iagttages for alle

projekter i digitaliseringsstrategien og anvendes, hvor det er relevant. Dvs. at projekter

skal forholde sig til disse elementer og redegøre for beslutninger om genbrug, bidrag

og afvigelser i forhold til relevante elementer. Det kan være ift. principper, som gives

af referencearkitekturer, eller specifikationer og standarder, der dikterer en række valg

for projektet og dermed letter designfasen. Det kan også være anvendelse af idriftsatte

fællesoffentlige komponenter, fx MitID og Nemlogin.

Bemærk særligt, at der er forskel på at et element er 1) godkendt som færdig

projektleverance, 2) er optaget i FDA-rammearkitekturen og 3) at der stilles konkrete

krav til dets anvendelse. Sidstnævnte kræver et formelt mandat til at stille

obligatoriske krav om anvendelse af løsningsbyggeblokke i konkrete it-løsninger. Dvs.

27

at obligatoriske krav kun kan stilles af et forum med relevant mandat – dvs. hjemmel

efter lov eller efter aftale mellem relevante parter.

Udfases er en status, der tildeles af SDA til elementer, der tidligere har haft kategorien

optaget, men som af teknologiske, organisatoriske eller andre årsager ikke længere

vurderes egnede til anvendelse. Et projekt bør orientere sig i denne kategori, så man fx

ikke baserer et løsningsdesign på specifikationer eller standarder, der ikke forventes

egnede eller vedligeholdt. Bemærk at en udfasning i praksis kan løbe over en årrække

pga. bindinger til eksisterende anvendelse.

Sammenhængen mellem de fem kategorier er vist i nedenstående figur og gennemgås

efterfølgende i forhold til en række hovedprocesser, der understøtter den samlede

livscyklus fra konceptuel idé over udvikling og godkendelse til optagelse i FDA,

anvendelse og endeligt til udfasning.

Ansvarsplaceringen i denne model er som følger:

Sekretariatet for FDA har ansvar for første del, hvor et behov for et fælles element

identificeres som kandidat til optagelse.

Den aktør eller det forum, som er projektejer/projektstyregruppe har ansvar for

udvikling og godkendelse af leverance til anvendelse/produktion er placeret hos.

SDA er ansvarlig for optagelse i FDA og eventuel udfasning af FDA er forankret.

Proces for identifikation af kandidater til FDA Alle initiativer, projekter og interessenter har mulighed for at foreslå kandidater til FDA

Rammearkitektur på baggrund af behov. SDA og sekretariatet for initiativ 8.1 har også

mulighed for at indmelde kandidater, typisk på baggrund af rådgivning og reviews, især

tværgående anbefalinger. Det kan være elementer, som skal udvikles fra bunden, eller

eksisterende elementer, der vurderes at have relevans som del af FDA, fx standarder

udviklet i regi af tidligere fællesoffentlige arbejder eller internationale standarder.

Alle kandidater indmeldes til sekretariatet for initiativ 8.1, der vedligeholder det

samlede overblik over pipeline til FDA Rammearkitektur. Ved indmeldelse vurderer

sekretariatet om elementet har potentiale for fællesoffentlig anvendelse. Er det

tilfældet får elementet status kandidat. Der tages dialog med den indmeldende part

om elementet er planlagt til udvikling i regi af et projekt i digitaliseringsstrategien. Er

28

det tilfældet monitoreres elementet, og det vil efter projektliggørelse skifte status til

udvikling.

Er der ikke aftale om, at elementet udvikles i regi af digitaliseringsstrategien og bliver

elementet vurderet som centralt for en fællesoffentlige digitale arkitektur, laves der en

indstilling til SDA. Sekretariatet for initiativ 8.1 kan indstille til SDA, at der i regi af

initiativ 8.1 igangsættes et projekt til udvikling og/eller, at en igangsættelse drøftes

med en relevant styregruppe i regi af digitaliseringsstrategien.

Proces for udvikling af elementer Kriterierne for, at et element kan skifte status fra kandidat til udvikling er:

- At elementet er omfattet af aftale mellem de fællesoffentlige parter

- At der er aftalt finansiering og styring for frembringelsen eller vurderingen af

produktet (herunder projektliggørelse af udvikling af nye elementer og vurdering

eller ”serviceeftersyn” af eksisterende elementer)

- At der er aftalt proces vedr. evt. rådgivning, arkitekturreview og eventuel offentlig

kommentering hvor relevant

Når et element projektliggøres skiftes status til udvikling. Heri ligger, at det

pågældende element, fx en referencearkitektur, specifikation, standard eller it-

komponent skal ny- eller videreudvikles eller vurderes.

Udvikling og vurdering af elementer kan ske i regi af alle relevante initiativer og

projekter i digitaliseringsstrategien og med forankring i pågældende styregruppe.

Omfatter projektet et allerede færdigt produkt, gives et serviceeftersyn i form af en

vurdering efter aftalt metode: Kvaliteten vurderes og der ses på relevans af elementet.

Selve gennemførelsen af projektet vil typisk være underlagt styring gennem offentligt

anvendte projektmodeller. Elementer under udvikling vil typisk skulle underlægges

arkitekturreview, jf retningslinjer for arkitekturreviews. Desuden tilbydes rådgivning til

projektet af sekretariatet for initiativ 8.1.

Et projekt har ansvar for at aftale med sekretariatet for initiativ 8.1, hvilke og hvornår

reviews skal gennemføres. Sekretariatet for initiativ 8.1 har efter indgået aftale med

projektet ansvar for at gennemføre reviews, udarbejde review-rapporter samt sikre

efterfølgende behandling i SDA.

Referencearkitekturer skal underlægges offentlig kommentering, hvor myndigheder,

leverandører, forskere og andre interesserede inviteres til at bidrage med faglige

kommentarer med henblik på kvalitetssikring. Der kan for andre væsentlige elementer

også aftales en offentlig kommentering.

29

Ansvaret for den offentlige kommentering påhviler det enkelte projekt, og koordineres

med sekretariatet for initiativ 8.1 bl.a. med henblik på en hensigtsmæssig timing og

faglig koordinering på tværs af beslægtede leverancer og processer.

Tekniske standarder og specifikationer analyseres med anvendelse af CAMSS (Common

Assessment Method for Standards and Specifications), der er en metode for vurdering

af tekniske specifikationer, som er udviklet i regi af EU’s ISA program.

Det påhviler det pågældende projekt, der ønsker at få optaget en standard eller en

teknisk specifikation i rammearkitekturen, at gennemføre denne vurdering.

Sekretariatet for initiativ 8.1 kan give rådgivning om analysemetoden efter aftale. Med

henblik på overordnet koordinering bør sekretariatet for initiativ 8.1 repræsenteres i

arbejdet med udvikling af referencearkitekturer.

Projektet og dets styregruppe eller SDA kan ønske at et element afprøves, inden det

godkendes som færdig leverance eller inden det optages i FDA.

Fx sætter specifikationer i form af datamodeller, integrationsmønstre og tekniske

protokoller nye rammer og krav til digitaliseringsprojekter, som rammer dybt ind i de

tekniske løsninger. Det er derfor centralt, at rammer og krav understøtter projekterne

og den fællesoffentlige digitale arkitektur – og ikke er en hindring. Mange projekter vil

derfor have behov for at der sker en afprøvning - en test af kvalitet, relevans og

anvendelighed af produktet - før det godkendes til optagelse FDA Rammearkitektur.

Selve afprøvningen af et element vil som med elementer under udvikling ofte styres i

hht. offentlige projektmodeller. Sekretariatet for initiativ 8.1 vil yde rådgivning, og hvor

relevant kan afprøvningen underlægges et arkitekturreview.

Proces for optagelse af elementer i den fællesoffentlige rammearkitektur Kriterierne for, at et element kan skifte status fra færdig til optaget er:

- At det overholder hvidbogens principper

- At det overholder aftalte krav til egenskaber

- At det har været gennem aftalt proces vedr. evt. rådgivning, arkitekturreview og

offentlig kommentering

- At det samlet set vurderes relevant, egnet og modent til optagelse og anvendelse

af SDA. Sekretariatet indstiller på baggrund af de første tre kriterier

Elementer i form af referencearkitekturer og byggeblokke, fx specifikationer og

standarder, som frembringes i regi af FODS godkendes af ansvarlig styregruppe. Efter

godkendelse i ansvarlig styregruppe kan elementet optages i FDA Rammearkitektur ved

beslutning af SDA.

30

Beslutning om optagelse i FDA Rammearkitektur sker ved forelæggelse for SDA under

forudsætning af godkendelse i egen styregruppe, samt at krav til metode og

procedurer er overholdt. Hertil skal krav og anbefalinger som SDA har givet i

forbindelse med tidligere behandling, herunder i forbindelse med arkitekturreview,

iagttages.

I forbindelse med beslutning om optagelse skal der være en afklaret styring, eventuelt

support og vedligehold, fremadrettet for det pågældende element, ligesom eventuelle

kendte formaliserede krav til anvendelse af elementet klart skal fremgå i indstillingen.

Efter at et element er besluttet optaget i FDA Rammearkitektur skifter status for

elementet til optaget.

Når elementer er optaget i FDA rammearkitektur bringes de formelt i anvendelse

indenfor rammerne af FODS. Det betyder, at alle projekter, hvor det er relevant, skal

forholde sig til dem. Der kan evt. stilles yderligere krav til obligatorisk anvendelse, som

rækker længere end den projektkontekst, som elementet oprindeligt blev udviklet til. I

korte træk betyder dette, at forskellige aktører på baggrund af hjemmel eller aftale kan

beslutte, at der stilles krav om (obligatorisk) anvendelse af specifikke FDA-elementer i

veldefinerede kontekster – fx i forbindelse med selvbetjeningsløsninger der indgår i en

fællesoffentlig flytteguide for borgere. Beslutninger kan være i regi af en FODS

styregruppe, men kan også foretages af andre aktører. Omfanget for krav til

anvendelse kan være generelt eller afgrænset i forhold til et givent domæne, en given

type løsning, et konkret projekt eller en helt specifik løsning.

Sekretariatet for initiativ 8.1 understøtter, at elementer kan opmærkes med

information om krav til deres anvendelse, og at denne information holdes opdateret.

SDA monitorerer anvendelsen af FDA Rammearkitektur gennem arkitekturreviews og

sekretariatet for initiativ 8.1’s rådgivning til projekterne.

SDA har desuden ansvar for

- Monitorering af anvendelse

- Evaluering af værdiskabelsen

- Sikring af vedligehold

- Plan for revision af indhold

Modtagelse af feedback fra anvendere er en væsentlig del af monitoreringen.

Modtagelse af feedback kan ske i regi af sekretariatet for initiativ 8.1 eller i regi af den

aktør, der er ansvarlig for elementet. Det påhviler sekretariatet for initiativ 8.1 at sikre

den praktiske koordinering af håndteringen af feed-back.

Sikring af vedligehold af elementet sker i dialog mellem pågældende ansvarlig for

elementet og sekretariatet for initiativ 8.1. Sekretariatet kan på baggrund af denne

dialog indstille til SDA, at elementet evalueres mhp. revision.

31

Revision planlægges på baggrund af indkomne emner i emneloggen. SDA kan indstille

til relevante ansvarlige fora (styregrupper mv.), at der skal eller bør ske en revision af

enkelte elementer som fx referencearkitekturer, specifikationer, vejledninger.

Proces for udfasning af elementer Kriterierne for beslutning om udfasning fra FDA omfatter:

- At produktet af SDA vurderes ikke længere at være relevant eller at overholde opdaterede og aftalte krav til egenskaber

- At der er gennemført en analyse af konsekvenserne ved udfasning og aftalt en plan for håndtering af væsentlige udfordringer afledt af udfasning

Forslag til udfasning kan komme fra alle aktører. Det kan eventuelt være aftalt på et

tidligt tidspunkt fx i form af en model for versionshåndtering.

I forbindelse med aftale om nye elementer bør der samtidig ske en vurdering af, om

det giver anledning til udfasning af andre elementer.

SDA har det overordnede ansvar for koordinering af udfasning af elementer i

rammearkitekturen såsom referencearkitekturer eller byggeblokke, herunder

specifikationer og vejledninger eller fælles komponenter i form af open source

applikationer eller it-services.

Det endelige ansvar for udfasning påhviler den styregruppe e.l., som har ansvar for det

pågældende element.

Udfasning skal varsles i god tid (efter nærmere aftale) og gennem publicering af

opdateret status.

Procesmodel for livscyklus for FDA-elementer De foregående processer danner tilsammen en procesmodel for livscyklus, som FDA-

elementerne gennemløber, illustreret i den efterfølgende figur.

32

Model for fordeling af roller og ansvar Dette kapitel beskriver roller og ansvar i forbindelse med videreudviklingen af

elementerne i FDA Rammearkitektur.

Følgende aktører er relevante i forhold til governance af FDA Rammearkitektur:

- Porteføljestyregruppen - Øvrige styregrupper i FODS - Styregruppen for data og arkitektur (SDA) - Sekretariatet for initiativ 8.1 (KDA) - Øvrige sekretariater for FODS initiativer - Arbejdsgrupper o.l. - Projekter i FODS - Myndigheder - Leverandører - Andre eksterne interessenter

Den efterfølgende figur beskriver disse aktører i forhold til rammearkitekturen.

Den første gruppe er interessenter (stakeholders) i forhold til digitaliseringsstrategien,

FDA Rammearkitektur og de løsninger, der påvirkes af disse. Deres roller har fokus på

33

dialog, formidling, koordinering og styring. Det omfatter fx formidling af

rammearkitekturen, dialog om dens indhold og egenskaber, koordinering i forhold til

andre styringskontekster som fx den fælleskommunale rammearkitektur eller det

fælleseuropæiske arbejde med arkitektur og infrastruktur. I nogle tilfælde indgår der

også tværgående styring, som rækker ud over FODS og FDA.

Den anden gruppe er de styringsfora, som er etableret som del af governance for FODS

og FDA. Deres roller har fokus på relationen til interessenter samt til den interne

strategi og retning, koordinering, kvalificering, review og kvalitetssikring.

Den sidste gruppe er løbende drift og udvikling, som omfatter projekterne i FODS-

initiativerne, som er de aktører, der udfører det løbende arbejde med udvikling,

afprøvning, vedligehold, anvendelse og drift af rammearkitekturens produkter. Denne

gruppe omfatter sekretariatet for initiativ 8.1, som er ansvarlig for rådgivning, review

og sagsbehandling i forbindelse med optagelse af elementer i FDA Rammearkitektur.

Sekretariatet for initiativ 8.1 har desuden ansvar for tværgående koordinering,

afhængighedsstyring, konfigurationsstyring, fælles overblik og kommunikation.

Del 3: Krav Udgangspunktet for FDA Rammearkitekturen er, at den skal anvendes af projekterne i

den fællesoffentlige digitaliseringsstrategi og kan anvendes af andre offentlige

projekter. I praksis betyder dette, at der indenfor rammerne af strategien kan

håndhæves krav til projekters arkitekturarbejde og til it-løsningers egenskaber. Disse

krav forventes løbende at blive aftalt af strategiens parter i regi af de fælles

styringsfora og overordnet governance i forhold til overholdelse håndhæves gennem

arkitekturreview i regi af SDA.

FDA Rammearkitekturs krav og anbefalinger gælder som hovedprincip, når der er tale

om nyudvikling eller større ændringer. Der kan derudover aftales nærmere om

implementering i eksisterende løsninger efter nærmere aftale mellem de offentlige

parter og eventuelt andre berørte parter. Der kan derudover være andre regelsæt, der

kræver bagudrettede ændringer.FDA Rammearkitekturen kan anvendes frit, men hvis

myndigheder eller andre ønsker at anvende FDA Rammearkitekturens elementer og

stille krav og udøve governance - udover FODS - må dette aftales særskilt. Det

anbefales imidlertid, at man her – så vidt muligt - følger samme koncept som beskrevet

i det følgende.

Principper for efterlevelse (gyldighedsgrad) Der opereres med tre grader af krav og til hver disse er der knyttet en metode i forhold

til håndtering af afvigelser.

34

Skal Hovedprincippet for efterlevelse af krav er som følger: Principper, regler og krav

angivet med “SKAL” er krav, som skal efterkommes. Ønsker man ikke at følge et krav

SKAL man søge dispensation hos SDA og give en forklaring på hvorfor man ikke ønsker

at følge kravet.

Bør Principper, regler og krav angivet med “BØR” er anbefalinger, som bør efterkommes,

men der er ikke krav om det. Efterkommer man det ikke, skal man på forespørgsel

kunne give en begrundelse for ikke at gøre det ud fra et ”følg eller forklar”-princip.

Kan Principper, regler og krav angivet med ”KAN” er vejledende, som myndighederne kan

efterkomme efter behov. Disse er der ikke krav om at man kan forklare ud fra et ”følg

eller forklar”-princip.

Typer af tjenester (it-løsningstyper) Der vil typisk være forskel på hvilke typer af tjenester/løsninger disse krav gælder for,

og med hvilken grad (SKAL/BØR/KAN) de gælder. Typologien nedenfor tager

udgangspunkt i ejerskab og rolle i det digitale landskab, primært med hensyn til hvem,

der skal anvende en given løsning.

Der skelnes mellem følgende typer af tjenester:

- Tværoffentlige tjenester - Domænetjenester - Anvendertjenester - Øvrige tjenester

Tværoffentlige tjenester Rolle: Central tjeneste, der fx fungerer som fælles løsning eller infrastruktur for andre

tjenester på nationalt / tværgående niveau.

Ejerskab: Fællesoffentligt eller statsligt. Eventuelt privat medejerskab.

Anvendere: Myndigheder som tjenesteudbydere. Eventuelt private virksomheder som

tjenesteudbydere. Borgere og virksomheder som slutbrugere.

Eksempler: NemID/MitID, NemLog-in, Datafordeler, Digital Post, Borger.dk, Virk.dk.

Domænetjenester Rolle: Central tjeneste, der fx fungerer som fælles løsning eller infrastruktur for andre

tjenester inden for et veldefineret domæne, som fx sundhed, undervisning,

beskæftigelse.

35

Ejerskab: Fællesoffentligt, fællesregionalt, fælleskommunalt, fællesstatsligt eller

statsligt. Eventuelt privat medejerskab.

Anvendere: Myndigheder som tjenesteudbydere. Eventuelt private virksomheder som

tjenesteudbydere. Borgere og virksomheder som slutbrugere.

Eksempler: Uni*Login, Miljøportalen, Interregionalt BilledIndeks og Fælles

Bibliotekssystem.

Anvendertjenester Rolle: Decentral (forretnings)tjeneste, der anvender fællesoffentlige og domæne

tjenester. Kan fx være forpligtet til at levere indhold til en fællesoffentlig portal.

Ejerskab: Statslig, regional, kommunal, privat

Anvendere: Medarbejdere, borgere og virksomheder som slutbrugere.

Eksempler: Selvbetjeningsløsninger og fagsystemer hos myndigheder og relevante

private aktører, der anvender efter aftale, fx laboratorier, banker, forsikringsselskaber.

Øvrige tjenester Rolle: Tjenester, som ikke indgår ikke i det aftalte omfang af tjenester nævnt ovenfor.

Vil typisk ikke være forpligtet til at levere indhold til portaler, men kan være forpligtet

af andre regler og aftaler, fx i forhold til deling og genbrug af data. Anvender

fællesoffentlige og domæne tjenester.

Ejerskab: Statslig, regional, kommunal, privat

Anvendere: Medarbejdere, borgere og virksomheder som slutbrugere.

Eksempler: Fagsystemer og infrastrukturløsninger i myndigheder og private

virksomheder.

Afgrænsning af dækningsområde (gyldighedsområde) Der anvendes to typer afgrænsning af det område, hvor et krav gælder

(gyldighedsområde): Opgaveområde og organisatorisk.

Opgaveområde Opgaveområde angiver hvilken del af den offentlige opgaveløsning, som er omfattet af

et krav. Fx om det gælder i et specifikt opgaveområde som fx sundhed, uddannelse,

flytning. Her anvendes som udgangspunkt den fællesoffentlige opgavenøgle (FORM)

som fælles taksonomi til at opmærke afgræsning.

36

Organisatorisk område Organisatorisk område angiver det organisatoriske scope, herunder hvilken sektor eller

organisation kravet gælder for. Fx om det gælder for alle myndigheder på tværs af stat,

regioner og kommuner eller fx kun for staten, eller om det gælder for private

virksomheder og borgere.

Administration af krav Sekretariatet for initiativ 8.1 skal på sigt vedligeholde og udstille en fællesoffentlig

oversigt over krav, som på sigt kan udvikles til et kravkatalog. Det indeholder en samlet

liste over de væsentligste principper, regler og andre typer krav om fx anvendelse af

standarder og byggeblokke, som angives i denne referencearkitektur.

Rådgivning og yderligere information

FDA Rammearkitektur er en væsentlig hjørnesten i digitaliseringsstrategiens arbejde

med at sikre en sammenhængende digital offentlig sektor, gennem anvendelse af den

fællesoffentlige arkitektur, kvalitetssikrer og bidrager til bedre digitale løsninger.

FDA Rammearkitektur udgør fundamentet for den arkitekturstyring, der igangsættes i

regi af digitaliseringsstrategiens initiativ 8.1.

Sekretariatet for initiativ 8.1 tilbyder sparring og rådgivning til relevante projekter, og

alle projekter er velkomne til at kontakte sekretariatet på arkitektur@digst.dk med

spørgsmål og ønsker til sparring.

FDA Rammearkitektur

arkitektur.digst.dk