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