Vejledning til FDA Rammearkitektur UDKAST

Transkript

1 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 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 itarkitekter, 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 Dette udkast sendes i offentlig kommentering i januar 2018 med det formål at få kvalificeret det overordnede koncept for rammearkitekturen. 2

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 Projekternes arkitekturarbejde Løsningsarkitektens brug af FDA Rammearkitektur Centrale begreber i FDA Rammearkitektur Katalog over byggeblokke i FDA-arkitekturreol Konceptuel model for præsentation af rammearkitekturen Del 2: Styringskoncept Fælles tværgående styring Rammearkitekturens frembringelse og vedligehold Model for fordeling af roller og ansvar Del 3: Krav Principper for efterlevelse (gyldighedsgrad) Typer af tjenester (it-løsningstyper) Afgrænsning af dækningsområde (gyldighedsområde) Administration af krav Rådgivning og yderligere information

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 (FODS). Heraf følger 4

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, 5

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 ) 6

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 7

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 8

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

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

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 11

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

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). 13

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 14

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 FDAkatalog over byggeblokke. Når man har identificeret en FDAbyggeblok, 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. 15

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-, ITeller 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. 16

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 17

18 digitaliseringsstrategi 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 18

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

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

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

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 22

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

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

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

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

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 27

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 itkomponent 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. 28

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

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

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 FDAelementerne gennemløber, illustreret i den efterfølgende figur. 31

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å 32