September 2019

Fælles digital arkitektur- anvendelse og udbredelse

Agenda

• Michael Bang Kjeldgaard, Digitaliseringstyrelsen:– FDA – status på de vigtigste rammer, produkter og anvendelser

• Peter Falkenberg, KL – Anvendelse og udbredelse

• Henrik Hammer Jordt, DR / Region Midtjylland – Arkitektursammenhæng i regionerne

Baggrund og ophæng

Fællesoffentlig

digitaliseringspagt

Væsentlige elementer i FDA

Vision og mål

Hvidbog Rammearkitektur Metoder Arkitekturreview

Referencearkitekturer og byggeblokke

Datastandarder

Tekniske specifikationer

Retningslinjer og vejledninger

Reviewproces

Vejledninger

Tjeklister

Arkitekturrapporter

FDA er en vejledning i, hvordan man bygger digitale løsninger med fokus på alle de relevante perspektiver fra strategiske mål for opgaveløsning til teknisk løsning.

Principper og arkitekturregler

5

Hvidbogens regler – peger på hvad projekter skal gøre

Udvalgte arkitekturprodukter i FDA-reolen

Hvad kan du finde på FDA-reolens hylderStyring

Sikkerhed

Strategi

Opgaver

Information

Applikation

Infrastruktur

Jura

Fælles styringsfora (fx SDA), Retningslinjer for arkitekturreview, Retningslinjer for formidling og dokumentation af arkitektur, Vejledning til arkitekturdokumentaion med ArchiMate, Vejledning om arkitekturmetode, Kurser, Netværk

Referencearkitektur for deling af data og dokumenter, Regler for begrebs- og datamodellering, Fælles sprog for datakvalitet, Modelkatalog, Datasætkatalog, Datastandarder, Sag og dokumentstandarder, Anvendelsesprofil for organisation og Klassifikation, Retningslinjer for stabile http-URIer

Retningslinjer for webservices (REST), [Vejledning om genbrug af data i selvbetjeningsløsninger], [Standard for beskrivelse af it-systemer], Lov og gode råd om webtilgængelighed

Fælles infrastruktur fx NemID/MitID, NemLogin, eID Gateway, Digital Post, NemKonto, Borger.dk, Fælles protokoller fx OIOIDWS, [eDelivery], Datadistributørkatalog

Referencearkitektur for brugerstyring, Vejledninger til sikkerhedsarbejdet, [Målbillede fællesoffentlig sikring af fortrolighed]

FODS, Digitaliseringsspagt, Hvidbog med principper og arkitekturregler, Introduktion til Fællesoffentlig Rammearkitektur, Arkitekturmodel og katalog med byggeblokke

Principper og vejledninger om digitaliseringsklar lovgivning, Lov om vejledninger om databeskyttelse og GDPR, eIADS-forordningen

FORM-opgavekatalog, Referencearkitektur for Selvbetjening, [Referencearkitektur for overblik over egne sager og ydelser], [Referencearkitektur for tværgående processer]

Eksempler på anvendelse Store tværoffentlige initiativer: Tværgående brugerrejser, fx flytning og skilsmisse

Borger og virksomhedsvendt overblik over egne data, fx sager, ydelser, aftaler, frister

Ministerier og styrelser, fx SKAT / UFST

STAR

SDFE

Anvender og bidrager til fx: Retningslinjer for arkitekturdokumentation

Referencerarkitekturer og byggeblokke

Arkitekturreview

Specifikationer (begrebs- og datamodeller, integrationsmønstre, protokoller)

Infrastruktur (NemID/MitID, Nemlogin, Digital Post, Datafordeler osv.)

Fælles digital arkitektur –anvendelse og udbredelse

• Referencearkitektur for Observation og Måling

• Begrebsmodel for sletning• Komponent/datamodel for indsamling af

data vedr. brug af selvbetjening.

Rammearkitektur med status ‘På vej’2

Rammearkitektur med status ‘Optaget i Rammearkitekturen’3Arkitekturstyring• Fælleskommunale Arkitekturmål*• Fælleskommunale Arkitekturprincipper- og regler*• Kriterier for optagelse i den fælleskommunale

rammearkitektur• Domænestruktur• Styringsmodel for indhold på INFO.rammearkitektur.dk

Modeller, processer mm.• Datamodel for Fælleskommunalt Geodatasamarbejde• Sagsprocesmønster• Selvbetjeningsmønster

• Beslutningsguide for it-indkøb• LoRA Organisationsservice• MOX

Rammearkitektur med status ‘Laboratorium’1

Byggeblokke• Abonnement (Besked abonnement)• Arkiv• Besked fordeling• Indkomst• Identitet• Lovgrundlag (Retskilde)• Læremiddel• Partskontakt• Proces• Print/udskrivning• Regel• Ansættelsesforhold (Tidligere

Virksomhed Job (medarbejder))

Indhold i den fælleskommunale rammearkitektur pr. 24. juni 2019

Byggeblokke• Ydelse• Bevilling• Effektuering• Samtykke• Lokation• Aktør• Myndighed• Facilitet• Postering økonomi• Betaling

Byggeblokke• Objekt• Dokument*• Sag*• Klassifikation*• Organisation*• Person• Virksomhed• Adresse• Matrikel• Ejerfortegnelse• Ejerskab• Bygning (bygværk)

• Ejendomsvurdering• Geografisk inddeling• Tilstand• Indsats • Aktivitet

+ Sammenhængs-model for Tilstand, Indsats og Aktivitet

2 Arkitekturprodukter, som er under udarbejdelse og forventes godkendt af Arkitekturboardet til optagelse i rammearkitekturen inden for 3- 6 måneder.

1 Arkitekturprodukter, der har en relevans fælleskommunalt, men som Arkitekturboardet har vurderet ikke har et niveau, så det kan optages i rammearkitekturen.

*Samt udfasede versioner heraf

3 Arkitekturprodukter, der er godkendt af Arkitekturboardet på vegne af It-Arkitekturrådet

ARKITEKTURPRINCIPPERMapning af fælleskommunale og fællesoffentlige arkitekturprincipper/regler

2

3

4

5

6

7

8

1Arkitektur styres på rette niveau efter fælles rammer

Arkitektur fremmer sammenhæng, inno-vation og effektivitet

Arkitektur og regulering understøtter hinanden

Sikkerhed, privatliv og tillid sikres

Processer optimeres på tværs

Gode data deles og genbruges

It-løsninger samarbejder effektivt

Data og services leveres driftssikkert

A1.1 Styr på arkitekturen på rette niveauer og sammenhængende

A1.2 Optimér arkitektur efter projektet og de fælles mål

A1.3 Anvend fælles ramme for beskrivelse af arkitekturen

A1.4 Sørg for at projektets arkitektur reviewes

A1.5 Hav tilstrækkelige kernekompetencer til arkitekturarbejdet

A2.1 Anvend og udbyg den fællesoffentlige rammearkitektur

A2.2 Anvend åbne og internationale standarder

A2.3 Undgå afhængighed af leverandører og proprietære teknologier

A2.4 Byg forandringsparat med udgangspunkt i brugeren

A2.5 Stil data og løsninger til rådighed for private

A3.1 Tag højde for juridiske bindinger i forhold til deling og genbrug af data og it-systemer

A3.2 Bidrag til digitaliseringsklar lovgivning

A4.1 Opfyld krav til informationssikkerhed og privatlivsbeskyttelse

A4.2 Anvend fælles arkitektur for informationssikkerhed

A5.1 Design sammenhængende brugerrejser

A5.2 Optimér tværgående processer efter fælles mål

A6.1 Del og genbrug data

A6.2 Anvend fælles regler for dokumentation af data

A6.3 Giv data den kvalitet som efterspørges

A6.4 Udstil oplysninger om datakilder, begreber og datamodeller

A7.1 Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder

A8.1 Levér data og services i henhold til aftalte servicemål

B6 Der er defineret entydigt ejerskab af byggeblokke

B9 Adskil det foranderlige fra det uforanderlige

B7 Betydelige forretningshændelser meddeles omverdenen

B1 Byggeblokke genbruges på tværs af it-løsninger

A1

A2

C2

B4

A3

B2

B3

B5

C4

B8

C3

C5

C5

C1

ARKITEKTURPRINCIPPER

Arkitekturregel 2.3: Undgå afhængighed af leverandører og proprietæreteknologierOffentlige myndigheder skal så vidt muligt undgå tekniske løsninger, der skaber bindinger til specifikke leverandører og til proprietære teknologier og produkter. Dette medvirker også til at udvikle et marked, hvor flere leverandører kan konkurrere om at levere systemer og services innovativt, billigt og fleksibelt til den offentlige sektor, og hvor der både er plads til standardløsninger og moduler fra flere leverandører baseret på åbne snitflader.

Det betyder at:

I forbindelse med nyanskaffelser og videreudvikling af it-løsninger stilles så vidt muligt krav om anvendelse af åbne standarder med stor udbredelse, der er uafhængige af bestemte leverandører, teknologier eller produkter.

Hvor det er relevant anvendes bæredygtige open source komponenter. Der sikres aftalemæssige og tekniske rammer for, at der senere kan skiftes til en anden leverandør, herunder at

data er dokumenteret og kan trækkes ud af it-løsningen. Data skal kunne importeres og eksporteres i et fælles vedtaget forretningsdomænemodel og –format.

Kommunal vinkelDet er vigtigt at forstå at systemerne er ”forvaltere” (og ikke ejere) af kommunens data og at denne forvaltning kun er for en periode. Over tid vil der komme andre systemer, der forvalter de samme data. Derfor er det vigtigt at systemerne arbejder efter en fælles fagdomænemodel og at data kan im- og eksporteres i dette format. På den måde kan data overdrages til og leve videre under andre ”forvaltere”.

Endvidere er det vigtigt at der er åbne interfaces, således at andre systemer kan arbejde videre med de data, som skabes og vedligeholdes i et system.I indkøbs- eller udbudssituationen skal, allerede ved kontraktindgåelsen, tages højde for og indarbejdes aftaler om det efterfølgende leverandørskift.

STATUSANGIVELSE

ARKITEKTURBESKRIVELSENavn: ’Fællesoffentlig referencearkitektur for selvbetjening, version 1.0’

Type: ’Referencearkitektur’

Status: ’Færdig’

Gyldighed: Planlagt godkendelse på Arkitekturboardmøde 2019/Q3

Målgruppe: ’Den primære målgruppe er arkitekter tilknyttet offentlige digitaliseringsprojekter, herunder enterprise-arkitekter, forretningsarkitekter, løsningsarkitekter, it-arkitekter m.v.Strategidelen henvender sig desuden til projektledere og beslutningstagere, herunder forretningsansvarlige, digitaliseringschefer, it-chefer, afdelings- og kontorchefer og andre med rollen som systemejer.Dokumentet er i sin helhed også relevant for leverandører, og det anbefales at de sætter sig grundigt ind i referencearkitekturen.

***

Anvendelse og anbefalingReferencearkitekturen har overordnet set to anvendelseskontekster: Standardiseringsprojekter, der skal identificere, udvælge og eventuelt udarbejde fælles standarder, samt løsningsprojekter, der har til opgave at udvikle selvbetjeningsløsninger. I forhold til standardiseringsprojekter anvendes referencearkitekturen til at udpege standarder, der understøtter skabelsen af sammenhængende, effektive, sikre og brugervenlige løsninger på tværs af sektorer, nationalt og transnationalt. Referencearkitekturen fokuserer på at rammesætte, kravsætte og vejlede fællesoffentlige selvbetjeningsløsninger, domæneløsninger og enkelte myndigheders selvbe-tjeningsløsninger.I forhold til løsningsprojekter anvendes referencearkitekturen i forbindelse med konceptualisering af løsningsarkitektur og kravspecificering. Den kan fx også anvendes i forbindelse med specificering af standardiserede snitflader….

MODELREGLER

BYGGEBLOKKE

Arkitektursammenhæng i regionerne

FDA arkitekturkonference 23. april 2018Henrik Hammer Jordt, Region Midtjylland

Interessenter i sundhedsvæsenet

5 Regioner 98 Kommuner

~4-5000 privatpraktiserende læger

5 mio borgere

Regeringen

KommunernesLandsforening

Danske Regioner

Folketinget og ministerierne

Politisk niveau

Sundhedsfagligt niveau

Patientforeninger

Strategiske rammer

Forstå hele opgaven

Proces

Data

ResultaterOpgave

Styring

Sikkerhed

Strategi

Opgaver

Information

Applikation

Infrastruktur

Jura

Styringsrammer RealiseringsforløbFremgangsmåde

Vision og mål

Sikkerhedsstandard

Juridiske rammer

Forretningsstruktur

Forretningsobjekter og begreber

Applikationsstruktur og integrationsmønstreInfrastrukturmønstre

Målarkitektur (resumé)

Sikkerhedsmodel og regler

Juridisk fortolkning

Processer

Informations- og datamodeller

Applikationslandskab og integrationerInfrastrukturlandskab

Løsningsarkitektur (resumé)

Sikkerhedskontroller

Juridisk praksis

Arbejdstilrettelæggelse

Fysiske datamodeller

Applikationsdesign og konfigurationInfrastrukturkonfiguration

Konceptuel(Overbliksniveau)

Logisk(Designniveau)

Fysisk(Realiseringsniveau)

I idéfasener fokus på ledelsens

krav til

målarkitektur

med overordnet beskrivelse af de

forretningsmæssige mål og den ønskede løsnings egenskaber

som grundlag for projekt

I analysefasener fokus på kundens

krav til

løsningsarkitektur

med logisk analyse og fastlæggelse af de

væsentligste elementer i arkitekturen som

grundlag for anskaffelse og/eller

(videre)udvikling

I gennemførelsesfasener fokus på

leverandørens

løsningsbeskrivelse

med detaljeret fastlæggelse af alle

elementer i løsningen til udvikling og

overdragelse til drift. Omfatter

systemkonfiguration.

FDA

Arkitekturanalyse

Målbillede

Love, regler og strategi

Behov og ønsker

Løsnings-arkitektur

Løsnings-beskrivelse

Logisk infrastruktur

design

It-systemer

Løsningsarkitekt+ projektteam

Leverandør Infrastruktur-arkitekt Driften

Kommuneplan Lokalplan Grundplan

Analyse Gennemførsel Drift

Rammer for løsningen

Krav for løsningen Udvikling og dokumentation af løsningen

• Mål/vision• Evner• Pixiproces• Begreber• Applikationer

• Swimlanes• Use cases• User stories• Logisk

datamodel• Integrationer• Sikkerhed• Kravliste

(Detaljeret design for det samlede system)

• Miljøer• Komponenter• Servere• Netværk• Backup• Monitorering

Jura Jura

AnalysefaseIdefase

It-arkitektProjektets

arkitekturleverancer

Projektleder

Strategier og politiske mål

Teamwork

Mål og strategier for RSIMål og strategier for projektet

Projektgrundlag

Mini Business Case

Fuldstændig PID

Fuld Business Case

Organisation

Teknik

OrganisationSemantisk

sammenhængTeknik

følgende faser..

Monitorering og kvalitetssikring af projektets it-

leverancer

AnskaffelseEtableringRealisering

ArkitekturedskaberKernemodel

Patientbehandlingsproces

Fagområder

National infrastruktur

Regionernes systemområder

Kapabiliteter

Begrebsmodel

Opsummering

• Arkitekturarbejde skaber sammenhæng

• FDA er vores fælles metoderamme

• RITA anbefaler at FDA anvendes i de fælles projekter

27

Fællesoffentlige arkitekturprodukter til forskellige roller

Digitaliseringsstrategiens vision, mål og initiativer

Hvidbogens principper

Hvidbogens arkitekturregler

Fællesoffentlig rammearkitektur, standarder, referencearkitekturer

FDA retningslinjer for fx begrebs- og datamodeller og webservices

Styregruppe

Projektleder

Arkitekt