Fælles digital arkitektur - anvendelse og udbredelse. September 2019

Transkript

1 Fælles digital arkitektur - anvendelse og udbredelse September 2019

2 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

3 Baggrund og ophæng Fællesoffentli g digitaliserings pagt

4 Væsentlige elementer i FDA Hvidbog Rammearkitektur Metoder Arkitekturreview Vision og mål Principper og arkitekturregler 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.

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

6 Udvalgte arkitekturprodukter i FDA-reolen

7 Hvad kan du finde på FDA-reolens hylder Styring 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 Strategi Jura Sikkerhed Opgaver Information Applikation Infrastruktur 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, eiadsforordningen Referencearkitektur for brugerstyring, Vejledninger til sikkerhedsarbejdet, [Målbillede fællesoffentlig sikring af fortrolighed] FORM-opgavekatalog, Referencearkitektur for Selvbetjening, [Referencearkitektur for overblik over egne sager og ydelser], [Referencearkitektur for tværgående processer] 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

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

9 Fælles digital arkitektur anvendelse og udbredelse

10 Indhold i den fælleskommunale rammearkitektur pr. 24. juni 2019 Rammearkitektur med status Laboratorium 1 Beslutningsguide for it-indkøb LoRA Organisationsservice MOX Byggeblokke Abonnement (Besked abonnement) Arkiv Besked fordeling Indkomst Identitet Lovgrundlag (Retskilde) Læremiddel Partskontakt Proces Print/udskrivning Regel Ansættelsesforhold (Tidligere Virksomhed Job (medarbejder)) Rammearkitektur med status På vej 2 Referencearkitektur for Observation og Måling Begrebsmodel for sletning Komponent/datamodel for indsamling af data vedr. brug af selvbetjening. Byggeblokke Ydelse Bevilling Effektuering Samtykke Lokation Aktør Myndighed Facilitet Postering økonomi Betaling Rammearkitektur med status Optaget i Rammearkitekturen 3 Arkitekturstyring 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 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 1 Arkitekturprodukter, der har en relevans fælleskommunalt, men som Arkitekturboardet har vurderet ikke har et niveau, så det kan optages i rammearkitekturen. 2 Arkitekturprodukter, som er under udarbejdelse og forventes godkendt af Arkitekturboardet til optagelse i rammearkitekturen inden for 3-6 måneder. 3 Arkitekturprodukter, der er godkendt af Arkitekturboardet på vegne af It-Arkitekturrådet *Samt udfasede versioner heraf

11 ARKITEKTURPRINCIPPER Mapning af fælleskommunale og fællesoffentlige arkitekturprincipper/regler Arkitektur styres på rette niveau efter fælles rammer Arkitektur fremmer sammenhæng, innovation og effektivitet Arkitektur og regulering understøtter hinanden A1.1 Styr på arkitekturen på rette niveauer og sammenhængende A2.1 Anvend og udbyg den fællesoffentlige rammearkitektur A3.1 Tag højde for juridiske bindinger i forhold til deling og genbrug af data og itsystemer A1 A1.2 Optimér arkitektur efter projektet og de fælles mål A2.2 Anvend åbne og internationale standarder A3.2 Bidrag til digitaliseringsklar lovgivning B4 A1.3 Anvend fælles ramme for beskrivelse af arkitekturen A2 A2.3 Undgå afhængighed af leverandører og proprietære teknologier A1.4 Sørg for at projektets arkitektur reviewes A2.4 Byg forandringsparat med udgangspunkt i brugeren A1.5 Hav tilstrækkelige kernekompetencer til arkitekturarbejdet A2.5 Stil data og løsninger til rådighed for private B6 Der er defineret entydigt ejerskab af byggeblokke B9 Adskil det foranderlige fra det uforanderlige C Sikkerhed, privatliv og tillid sikres Processer optimeres på tværs Gode data deles og genbruges A3 B2 A4.1 Opfyld krav til informationssikkerhed og privatlivsbeskyttelse A5.1 Design sammenhængende brugerrejser A6.1 Del og genbrug data C1 B3 B8 A4.2 Anvend fælles arkitektur for informationssikkerhed A5.2 Optimér tværgående processer efter fælles mål A6.2 Anvend fælles regler for dokumentation af data B5 C3 A6.3 Giv data den kvalitet som efterspørges A6.4 Udstil oplysninger om datakilder, begreber og datamodeller 7 It-løsninger samarbejder effektivt A7.1 Design og udstil snitflader efter fælles integrationsmønstre og tekniske standarder C5 B7 Betydelige forretningshændelser meddeles omverdenen B1 Byggeblokke genbruges på tværs af it-løsninger 8 Data og services leveres driftssikkert A8.1 Levér data og services i henhold til aftalte servicemål C4 C5

12 ARKITEKTURPRINCIPPER Arkitekturregel 2.3: Undgå afhængighed af leverandører og proprietære teknologier Offentlige 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 vinkel Det 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.

13 STATUSANGIVELSE

14 ARKITEKTURBESKRIVELSE Navn: 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 Anvendelse og anbefaling henvender sig desuden til projektledere og beslutningstagere, herunder Referencearkitekturen har overordnet set to anvendelseskontekster: Standardiseringsprojekter, der skal identificere, udvælge og eventuelt forretningsansvarlige, digitaliseringschefer, it-chefer, afdelings- og kontorchefer og andre udarbejde fælles standarder, samt løsningsprojekter, der har til opgave at udvikle selvbetjeningsløsninger. I forhold til standardiseringsprojekter med anvendes rollen referencearkitekturen som systemejer. 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 Dokumentet fællesoffentlige selvbetjeningsløsninger, er i sin helhed domæneløsninger også relevant og enkelte for myndigheders leverandører, selvbe-tjeningsløsninger. og det anbefales at de sætter sig I forhold grundigt til løsningsprojekter ind i referencearkitekturen. anvendes i forbindelse med konceptualisering af løsningsarkitektur og kravspecificering. Den kan fx også anvendes i forbindelse med specificering af standardiserede snitflader. ***

15 MODELREGLER

16 BYGGEBLOKKE

17 Arkitektursammenhæng i regionerne FDA arkitekturkonference 23. april 2018 Henrik Hammer Jordt, Region Midtjylland

18 Interessenter i sundhedsvæsenet Politisk niveau Sundhedsfagligt niveau ~ privatpraktiserende læger Regeringen Folketinget og ministerierne 5 mio borgere Kommunernes Landsforening Danske Regioner 5 Regioner 98 Kommuner Patientforeninger

19 Strategiske rammer

20 Forstå hele opgaven Opgave Resultater Data Proces

21 FDA Styring Konceptuel (Overbliksniveau) Styringsrammer Logisk (Designniveau) Fremgangsmåde Fysisk (Realiseringsniveau) Realiseringsforløb Strategi Jura Sikkerhed Opgaver Information Applikation Infrastruktur Vision og mål I idéfasen er fokus på ledelsens Juridiske rammer krav til Sikkerhedsstandard målarkitektur med overordnet Forretningsstruktur beskrivelse af de forretningsmæssige Forretningsobjekter mål og den ønskede og begreber løsnings egenskaber som grundlag for Applikationsstruktur projekt og integrationsmønstre Infrastrukturmønstre Målarkitektur (resumé) Løsningsarkitektur I analysefasen (resumé) I gennemførelsesfasen er fokus på kundens er fokus på Juridisk fortolkning Juridisk praksis krav til leverandørens Sikkerhedsmodel løsningsarkitektur og regler Sikkerhedskontroller løsningsbeskrivelse med logisk analyse og med detaljeret Processer fastlæggelse af de Arbejdstilrettelæggelse fastlæggelse af alle væsentligste elementer elementer i løsningen Informationsi arkitekturen og som Fysiske til datamodeller udvikling og datamodeller grundlag for overdragelse til drift. anskaffelse og/eller Omfatter Applikationslandskab (videre)udvikling og Applikationsdesign systemkonfiguration. og integrationer konfiguration Infrastrukturlandskab Infrastrukturkonfiguration

22 Arkitekturanalyse Løsningsarkitekt + projektteam Leverandør Infrastrukturarkitekt Driften Behov og ønsker Målbillede Løsningsarkitektur Løsningsbeskrivelse Logisk infrastruktur design It-systemer Love, regler og strategi 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 Analyse Gennemførsel Drift Kommuneplan Lokalplan Grundplan Rammer for løsningen Krav for løsningen Udvikling og dokumentation af løsningen

23 Teamwork Idefase Analysefase følgende faser.. Strategier og politiske mål Mål og strategier for RSI Mål og strategier for projektet Projektleder Projektgrundlag Mini Business Case Fuldstændig PID Fuld Business Case Anskaffelse Etablering Realisering It-arkitekt Projektets arkitekturleverancer Jura Organisation Teknik Jura Organisation Semantisk sammenhæng Teknik Monitorering og kvalitetssikring af projektets itleverancer

24 Arkitekturedskaber Kernemodel Kapabiliteter Patientbehandlingsproces Fagområder Begrebsmodel Regionernes systemområder National infrastruktur

25 Opsummering Arkitekturarbejde skaber sammenhæng FDA er vores fælles metoderamme RITA anbefaler at FDA anvendes i de fælles projekter

26

27 Fællesoffentlige arkitekturprodukter til forskellige roller Digitaliseringsstrategiens vision, mål og initiativer Hvidbogens principper Styregruppe Hvidbogens arkitekturregler Projektleder Fællesoffentlig rammearkitektur, standarder, referencearkitekturer Arkitekt FDA retningslinjer for fx begrebs- og datamodeller og webservices 27