Næste generation Digital Post rapport for Analyse 2.1

Transkript

1 Næste generation Digital Post rapport for Analyse 2.1 Udført for Digitaliseringsstyrelsen version 1.0 Pelle Borgsten og Christian Callsen

2 Indholdsfortegnelse 1 Indledning 1 2 Model A Kontinuerlig transition 5 3 Model B Hurtig idriftsættelse af Næste generation DP 36 4 Model C Markedsbaseret kommunikationsinfrastruktur 45 5 Perspektivering 70 6 Referencer 71 Appendix A. Mål og delmål 72 Appendix B. Funktionalitet 74 Appendix C. Kommunikationsscenarier 75 OptimumIT

3 Kapitel 1 - Indledning og afgrænsning 1 Indledning Digitaliseringsstyrelsen har identificeret et behov for at forny it-understøttelsen af kommunikationen mellem myndigheder, borgere og virksomheder. Derudover er der et behov for at realisere en mere omkostningseffektiv løsning til Digital Post. Digitaliseringsstyrelsen har derfor igangsat Analyse 2.1, som én ud af 6 analyser. I Analyse 1 bliver der udarbejdet og analyseret mulige løsningsscenarier for Næste generation Digital Post. Digitaliseringsstyrelsen anbefales at sammenholde de udarbejdede modeller med resultaterne fra de øvrige analyser og den kommende økonomiske estimering. På den baggrund kan Digitaliseringsstyrelsen udarbejde en indstilling til KC-styregruppen, som består af repræsentanter fra Erhvervsstyrelsen, Udbetaling Danmark, SKAT, Kommunernes Landsforening, Danske Regioner og Digitaliseringsstyrelsen. 1.1 Sammenfatning Digitaliseringsstyrelsen har givet OptimumIT til opgave at identificere den bedst egnede model for den fremtidige målarkitektur for Næste generation Digital Post, inden for et bredt spektrum af muligheder. Opgaven indeholder således identifikation af relevante modeller samt udvælgelse af tre realiseérbare modeller til videre analyse. Vurderingen udføres baseret på en forretningsmæssig rammesætning udarbejdet af Digitaliseringsstyrelsen. Opgaven er udført i løbende samarbejde med Digitaliseringsstyrelsen. Analysen har en række væsentlige afgrænsninger, som følger: Analysen skal udarbejdes på basis af forhåndenværende materiale i Næste generation Digital Post projektet. Analysen skal ikke indeholde en detaljeret økonomisk estimering af modellerne, men blot en overordnet kvalitativ vurdering af omfang inden for anlæg og drift. Analysen skal ikke indeholde en detaljeret nedbrydning af al ønsket funktionalitet til Næste generation Digital Post. Analysen skal ikke vurdere udbudsegnethed af den nuværende løsning eller muligheden for gennemførsel af et eller flere forskellige anskaffelser under udbud. Under analysen er der fremkommet en række centrale drivere. Modeller identificeret under analysen er vurderet og udvalgt under hensyntagen til disse drivere. De centrale drivere er som følger: Alle modeller skal understøtte juridisk frigørende virkning for myndighederne. Et centralt lager for borgeres og virksomheders meddelelser er et ufravigeligt krav til alle modeller. Et selvstændigt kontaktregister er ønskeligt uanset valget af model, så kontaktregisteret kan anvendes til andre fællesoffentlige løsninger. Modeller med en distribueret it-arkitektur, hvor komponenter har en velafgrænset ansvarsfordeling, er ønskelige. En monolitisk model (siloløsning) er fremadrettet ikke attraktiv. OptimumIT Side 1 af 75

4 Graden af ønsket konkurrenceudsættelse af komponenterne til Digital Post er højt prioriteret. Forsyningssikkerhed vejer dog tungere end markedsgørelse. Øget fokus på at borgere og virksomheder selv kan vælge hvor de tilgår deres Digitale Post. Modeller der understøtter private udbydere af adgang til Digital Post foretrækkes. Øget fokus på risici ved mulige modeller samt transitionen for it-systemerne. Analysen består af 3 faser. Fase 1 sikrer en bred afdækning af mulige kandidater med efterfølgende visitering til tre kandidater. Fase 2 analyserer hver af de tre identificerede kandidater. Fase 3 vurderer egnetheden af hver af de tre identificerede kandidater. Analysens fase 1 har identificeret 12 modeller for den fremtidige Næste generation Digital Post. Fase 1 er gennemført i tæt samarbejde med Digitaliseringsstyrelsen og i dialog med interessenter fra bl.a. Kommunernes Landsforening, Danske Regioner, Udbetaling Danmark samt en række kommunale og statslige myndigheder. Digitaliseringsstyrelsen og OptimumIT har i fællesskab visiteret de 12 identificerede modeller og udpeget 3 modeller: Delvis hjemtagelse, der er basis for Model A Kontinuerlig transition Ny Digital Post Variant 1, der er basis for OptimumIT Side 2 af 75

5 Model B Hurtig eneration Digital Post Nem Variant 1, der efter påbegyndelse af analysens fase 2 blev erstattet med den nuværende Model C Markedsbaseret kommunikationsinfrastruktur, grundet de identificerede centrale drivere og risici ved modellen i fase 2 Analysens fase 2 har analyseret de tre valgte modeller ud fra en række vurderingskriterier, constraints, rammedimensioner og fokusområder opstillet af Digitaliseringsstyrelsen. Disse indgår alle i vurderingen af modellerne i den afsluttende fase 3. Model A er en hjemtagelse af den eksisterende løsning, og har en målarkitektur med fælles meddelelsesfordeler af meddelelser mellem anvendere. Model A har en strategi for glidende transition fra den nuværende løsning til målarkitekturen. Model B tilvejebringer en målarkitektur svarende til Model A, men Model B realiserer målarkitekturen i et skridt, hvilket vil sige én samtidig anskaffelse af komponenterne og udfasning af den eksisterende løsning. Model C tilvejebringer en målarkitektur som grundlæggende består af to delløsninger, baseret på én kommunikationsinfrastruktur. Den første delløsning i Model C understøtter kommunikation mellem myndigheder og større virksomheder samt indbyrdes mellem myndigheder. Den anden delløsning i Model C understøtter kommunikation mellem myndigheder og borgere/mindre virksomheder. Begge delløsninger er umiddelbart nødvendige for at kunne realisere de kommunikationsmønstre, som er mulige i dag, fx myndighed til myndighed og myndighed til borger. Model C har derfor en strategi med at realisere begge delløsninger samtidigt og dermed en samtidig udfasning af den eksisterende løsning. I forbindelse med udførslen af fase 2 er det fremkommet, at analysen ikke har kunnet få leveret højniveaukrav af Digitaliseringsstyrelsen. Analysen har i fase 2 i stedet for funktionelle højniveaukrav vurderet modellernes evne til opfyldelse af gevinster, mål og delmål for projektet i stedet for de funktionelle højniveaukrav. Analysen har yderligere anvendt produktkvalitetsmodellens 8 dimensioner fra ISO/IEC 25010:2011 i stedet for de nonfunktionelle højniveaukrav. Fase 2 identificerede udfordringer med teknologivalg og vurdering af markedets villighed til at levere kritiske dele for Model C. Endvidere fremkom ny viden fra et besøg i Norge, som resulterede i en variant af Model C med mange af de samme egenskaber, bedre leverancesikkerhed, men også med større økonomisk omfang. Model C blev derfor udskiftet med denne nye variant. Den beskrevne Model C er derfor identificeret sent i analyseforløbet, og er som følge heraf blevet analyseret gennem et tidsmæssigt væsentligt kortere forløb end for Model A og Model B. Analysens fase 3 er udført som en kvalitativ vurdering af hver enkelt af de tre modeller ud fra følgende 5 vurderingsdimensioner: Realisering af mål og gevinster ved Næste generation Digital Post Softwaremæssige kvalitative egenskaber (baseret på ISO/IEC 25010:2011) Risiko Migrationsstrategi Overslag over økonomisk omfang inden for anlæg og drift Den overordnede vurdering af modellerne er vist i følgende tabel. Vurderingen angivet i tre trin God, Mellem og Mindre god, hvor God er den bedste vurdering og Mindre god er den dårligste vurdering: OptimumIT Side 3 af 75

6 Dimension Model A Model B Model C Realisering af mål og gevinster Mellem God God Softwaremæssige kvalitative egenskaber God God God Risiko Mellem Mindre god Mindre god Migrationsstrategi God Mindre god Mellem Overslag over økonomisk omfang Mellem Mellem Mindre god Tabel 1 Overordnet vurdering af de tre modeller Det er OptimumITs forståelse, at vurderingsdimensionerne risiko, økonomi og migrationsstrategi vægter tungere end de øvrige vurderingsdimensioner. Tages denne vægtning i betragtning, er Model A samlet set bedre end Model C og Model B. Hvis Digitaliseringsstyrelsen ønsker hurtigst muligt at overgå til Næste generation Digital Post, vil Model B blive vurderet som den mest attraktive.. Hvis Digitaliseringsstyrelsen vælger, at anvendelse af løsninger tilvejebragt af markedet vægter højest (markedgørelse) og færre fællesoffentlige komponenter på sigt, så vil Model C blive vurderet som den mest attraktive. Digitaliseringsstyrelsen anbefales følgende, efter at KC-styregruppen har valgt en model: Digitaliseringsstyrelsen anbefales at analysere de eksisterende snitflader og integrationer for Digital Post 2 yderligere, for at sikre en sømløs overgang til den valgte model. Ændringer til snitflader og integrationer vurderes udgøre et væsentligt element i de samlede udgifter. Digitaliseringsstyrelsen anbefales at gennemføre en nedbrydning af kapabiliteter i Digital Post i et business capability map, så det sikres, at al væsentlig funktionalitet er medtaget. Digitaliseringsstyrelsen anbefales at udarbejde en detaljeret migrationsstrategi baseret på ovenstående nedbrydning af kapabiliteter. Digitaliseringsstyrelsen anbefales at hjemtage det forretningsmæssige ejerskab og ansvar for de udstillede snitflader ved at forvalte anvendelse af datastandarder og ensretning af klassifikationer. Hjemtagelsen vil sikre at Digitaliseringsstyrelsen kan sikre konkurrenceudsættelse og kontinuitet i løsningen. OptimumIT Side 4 af 75

7 2 Model A Kontinuerlig transition Fokus for Model A Kontinuerlig transition er at sikre kontinuerlig anvendelse af Digital Post for myndigheder, borgere og virksomheder. Derudover er fokus at sikre, at transition mod målarkitekturen sker med så lav risiko som muligt og uden store ændringer for borgere, virksomheder og myndigheder på kort sigt. Målarkitekturen skal anvende mulighederne i den kommende Digitaliseringsstrategi mest muligt. Digitaliseringsstrategien giver mulighed for anvendelse af et centralt kontaktregister og øget anvendelse af sikkerhedskomponenter. Der ønskes ikke en samlet central siloløsning. Model A består overordnet af en række større komponenter. Model A realiserer målarkitekturen i 3 faser, hvor delmængder af løsningen tages ud af den eksisterende version af Digital Post 2 (DP2) i hver fase. Transition og migration er uddybet i afsnit 2.7. Nedenstående figur viser den eksisterende Digital Post løsnings (venstre side af figuren) transition over i målarkitekturen (højre side). Pilene illustrerer hvor komponenter i den eksisterende løsning ender i den nye løsning. De forskellige farver er blot anvendt for bedre at synliggøre, hvor hver komponent ender. Figur 1 Overblik over DP2 transition til Model A DP2 vil fortsætte under den nuværende kontrakt inklusive et sidste migrationsår og er dermed fuldt udfaset per 1/ De eksisterende snitflader på DP2 kan derfor anvendes indtil udfasningen er komplet, men myndighederne/virksomhederne skal opdatere deres integrationer til de nye snitflader for at opnå de mulige gevinster. Transitionen er beskrevet i detaljer i afsnit 2.7. Målarkitekturen udnytter de nye muligheder i Digitaliseringsstrategien ved at anvende det kommende fællesoffentlige kontaktregister (FKR) og fællesoffentlig sikkerhed til at understøtte dele af Digital Posts nuværende kapabiliteter inden for sikkerhed og kontaktoplysninger. I forhold til den eksisterende DP2 løsning vil Model A på sigt være udvidet til at inkludere opdaterede datastandarder, samt muligheden for at private leverandører kan levere services og portaler. Datastandarder giver samlet et bedre grundlag for interaktion mellem borger og myndigheder, mellem virksomhed og myndighed, samt interaktion mellem myndigheder end den nuværende løsning. Den nuværende løsnings adresseringsformat for myndigheder kan dog indgå som grundlag for en ny datastandard. OptimumIT Side 5 af 75

8 Borger til borger og virksomhed til virksomhed er teknisk muligt, men er som udgangspunkt ikke medtaget i denne løsning. 2.1 Overblik over modellen Modellens arkitektur består af en række uafhængige komponenter, som tilsammen giver de fornødne kapabiliteter. Modellens arkitektur har følgende væsentlige egenskaber: Borgeres og virksomheders væsentlige elektroniske dokumenter ligger i et centralt lager varetaget af det offentlige. En central meddelelsesfordeler med ansvaret for at videredistribuere meddelelser til det centrale lager eller udvalgte aftagersystem. Meddelelsesfordeleren vil have mulighed for at afsende servicemeddelelser og ikke væsentlige meddelelser direkte til de kanaler - fx mobil eller , som borgeren har valgt i kontaktregisteret. Modellen kan garantere, at alle grupper af borgere og virksomheder får en anvendelig bruger- eller systemgrænseflade til håndtering af meddelelser i Digital Post. Modellen anvender et hub-and-spoke arkitekturmønster, hvor lageret er én kanal blandt flere mulige kanaler fx NemSMS til servicebeskeder. Private udbydere har i nogen grad mulighed for at udbyde private brugergrænseflader, som kan vise dokumenter fra private og offentlige eller specialiserede rollebaserede snitflader fx for kuratorer. Frigørende virkning sker ved modtagelse hos meddelelsesfordeleren, der garanterer at meddelelsen leveres til lageret. Systemejerskabet over løsningen vil dække flere myndigheder. Leverancen af Meddelelsesfordeler og kontaktregister har en kritisk afhængighed af den nye sikkerhedsløsning. Leverancen af nye grænseflader på borger.dk og virk.dk har en kritisk afhængighed af, at DP2 stiller en snitflade til rådighed for vise og modtage post. Begge afhængigheder kan dog kompenseres ved at have en midlertidig løsning eller fortsætte DP2, indtil forsinkelsen er løst, dog ikke efter 1/ DP2 har i dag en administrationsportal, som varetager personalization, opsætning af fordeling, opsætning af aftaler for aftagersystemer og modtagersystemer, håndtering af rettigheder samt vedligehold af kontaktinformation og kontakthierarkier. Disse kapabiliteter splittes op i flere komponenter i målarkitekturen. Sikkerhed (jf. afsnit 2.5.6) vil således varetage funktionaliteten om rettigheder og aftaler. Kontaktregisteret vil varetage kontaktinformation og organisationshierarkier. Personalization vil blive varetaget af virk.dk og borger.dk. Det er forventningen, at kontaktregister og sikkerhed vil anvendes af mange andre it-systemer end Digital Post. OptimumIT Side 6 af 75

9 2.1.1 Målarkitektur for Model A Følgende diagram viser målarkitekturen for model A og illustrerer de væsentligste kapabiliteter (vist med lyseblå) for komponenter (vist med blå). Endvidere er hver komponent grupperet efter deres placering i det fællesoffentlige it-landskab. Administrationsgrænseflader er ikke vist som en væsentlig kapabilitet, men hver komponent har en administrationsgrænseflade. Forretningslogik er medtaget som en kapabilitet for at illustrere, at portalen skal understøtte en række features og forretningslogik, som den eksisterende DP2 løsning i dag understøtter. Figur 2 Målarkitektur for Model A Kontinuerlig transition Ovenstående komponenter udstiller og anvender en række snitflader. Disse illustreres i komponentdiagrammet nedenfor, som beskriver de udstillede snitflader i Digital Post, samt hvilke OptimumIT Side 7 af 75

10 komponenter, der anvender dem. Sikkerhed til autentifikation og autorisation er ikke medtaget i diagrammet, da autentifikation og autorisation indgår i alle snitflader. Figur 3 Komponentdiagram for Model A Kontinuerlig transition Komponentdiagrammet beskriver de udstillede og anvendte systemsnitflader i Digital Post. Borger.dk og virk.dk henter meddelelser fra lageret og sender meddelelser til meddelelsesfordeleren. De anvender det fællesoffentlige kontaktregister til at hente tilmelding til Digital Post og kan vise kontaktinformation for brugeren. Borger.dk/virk.dk har i diagrammet ikke en integration til underskrift funktionaliteten i sikkerhed, men dette vil være muligt. Private udbydere tilbyder portaler og services til borgere og virksomheder. Private udbydere kan læse meddelelser fra lageret og sende via meddelelsesfordeler på vegne af en given borger eller virksomhed. Den private udbyder skal selv validere, at modtageren er tilmeldt Digital Post. Meddelelsesfordeleren kan modtage meddelelser fra andre it-systemer på vegne af en myndighed, borger eller virksomhed og videresende til det centrale lager, en selvudbyder eller andre kanaler såsom NemSMS. Meddelelsesfordeleren kan anvende kontaktregisteret til at hente yderligere kontaktinformation som en del af adresseringen Fællesoffentligt kontaktregister udstiller to snitflader til læsning af kontaktoplysninger og opret/læs tilmelding til Digital Post. Vedligehold af kontaktregisteret er ikke en del af NgDP, og er derfor ikke vist på denne tegning. Lageret indeholder arkivet for Digital Post for borgere og virksomheder. Den udstiller to snitflader - en til læsning af meddelelser og en til modtagelse af meddelelser. Advisering/NemSMS er medtaget for at vise, at meddelelsesfordeleren kan distribuere til andre kanaler end lageret. Advisering vil sende en , mens NemSMS vil sende en SMS til modtagerens mobilnummer. Selvudbyder er de myndigheder og virksomheder som selv varetager visning, opbevaring og afsendelse af meddelelser i Digital Post. Ved afsendelse skal selvudbyderen validere om modtageren er tilmeldt digitalt post. Selvudbyderen afhenter meddelelser fra OptimumIT Side 8 af 75

11 Meddelelsesfordeleren. Såfremt selvudbyder har valgt at opbevare sin post i det fællesoffentlige lager, så vil selvudbyderen selv skulle integrere til lageret. Komponenterne i målarkitekturen består af følgende: Betegnelse Beskrivelse Kapabiliteter Borger.dk og Virk.dk har en brugergrænseflade til Digital Post. Brugergrænseflade til borgere og virksomheder til visning af Digital Post. Brugergrænseflade til alle typer borgere og virksomheder Send Meddelelse Se modtagne meddelelser Meddelelsesfordeler NemSMS Sikkerhed Fællesoffentligt kontaktregister Lager Indeholder funktionalitet til at modtage og distribuere meddelelser. I denne model sikrer Meddelelsesfordeleren frigørende virkning ved modtagelse. Udstiller muligheden for at sende notifikationer via SMS og adviseringer via . Indeholder aktørers rettigheder til Digital Post, administrationsgrænseflade til håndtering af rettigheder og aftaler, Identity provider eller tilsvarende samt service til underskrift og andre services, jf. afsnit Indeholder kontaktoplysninger (Mobil-nr. og , tilmelding til Digital Post, rettighed til anvendelse af selvbetjeningsløsninger etc.) på borgere, virksomheder og myndigheder. Kan også indeholde organisationshierarki for myndigheder og virksomheder, hvor organisationshierarkiet angiver struktur og relationen mellem opgaver og organisationsenheder. Lager til modtagne meddelelser for borgere og virksomheder. Administration af personalization af brugergrænsefladen Systemgrænseflade Teknisk kvittering Send Modtag Afsendelse af SMS Afsendelse af Roller og rettigheder itsystemer og andre aktørers adgang til indbakker Rettigheder til anvendere af udstillede snitflader Underskrift/signering Digitale Persondata som e- mail, telefonnummer etc. Tilmeldingsliste til Digital Post og andre kanaler. Organisationsstruktur Lageret kan modtage meddelelser fra OptimumIT Side 9 af 75

12 Selvudbyder En myndighed eller virksomhed som selv varetager modtagelse, visning, opbevaring og afsendelse af Digital Post. En selvudbyder vil skulle efterkomme en række krav så det sikres, at meddelelser fra meddelelsesfordeleren altid modtages. meddelelsesfordeleren og udstiller en læse snitflade som kan anvendes af borger.dk/virk.dk eller private udbydere. Modtagelse af meddelelser Send meddelelser Vis meddelelser Opbevaring af meddelelser Understøttet indhold i modellen Følgende indhold understøttes i modellen: Væsentlig meddelelse, ikke-væsentlig meddelelse og notifikationer (understøttes på samme niveau og i samme kvalitet) Faktura (kan vedhæftes en mail der agerer som følgebrev) Indkaldelser (der kan afgives svar på en indkaldelsesmail) Høring (der kan afgives officielle svar men høringsdokumenter skal være indeholdt i den udsendte høringsmeddelelse) Følgende indhold understøttes ikke: Delt dokument (der understøttes kun notifikation om ændringer til dokumentet) Projekthåndtering 2.2 Kommunikationsscenarier mellem systemets komponenter og aktører i målarkitekturen. I dette afsnit beskrives hvordan Digital Post flyder mellem borgere, virksomheder og myndigheder i målarkitekturen. Flowet beskrives gennem UML sekvensdiagrammer. Modellen understøtter i fuldt omfang kommunikation fra borgere og virksomheder til og fra myndigheder. Modellen understøtter i fuldt omfang envejskommunikation mellem borgere, virksomheder og myndigheder. Dette inkluderer, at borgere, virksomheder og myndigheder kan sende Digital Post til alle øvrige tilmeldte modtagere. Borger til borger og virksomheder til virksomheder er pt. ikke medtaget i modellen, men det er teknisk muligt at udvide med dette scenarie. Hvis dette foretages kan det forventes at være en væsentlig udgift at understøtte brugerrejserne for borgere og virksomheder ved understøttelse af de to kommunikationsscenarier. OptimumIT Side 10 af 75

13 Modellen understøtter tovejskommunikation i mellem borgere, virksomheder og myndigheder. Kommunikationens anvendelighed kræver dog, at der anvendes en ny datastandard, hvor dialogen kan opmærkes for både virksomheder og myndigheder. I den nuværende DP2 løsning er metadata opmærkning forskellig alt efter om modtageren er en virksomhed eller myndighed, hvor muligheden for at tilknytte metadata til virksomheder er mere begrænset. I det følgende beskrives flowet mellem aktører og modellens komponenter. Komponenternes anvendelse af sikkerhed er ikke medtaget i diagrammet. Bemærk at flowet primært illustrerer flow of data og ikke flow of control. I diagrammerne står aktøren/komponenten øverst ved hver svømmebane. En fyldt pil: betyder en synkron forespørgsel, en ikke udfyldt pil er asynkron og en Tilmeldingssvar stiplet pil er et svar på en synkron forespørgsel. I det følgende beskrives kommunikationsscenarierne for envejskommunikation mellem aktørerne ved brug af modellens komponenter. Dialogscenarier opnås ved at sammensætte disse scenarier Myndighed til Myndighed Kommunikation mellem myndigheder sendes via meddelelsesfordeleren. Den afsendende myndighed tilknytter metadata om modtageren. Fordeleren kan anvende kontaktregistreret og autoklassificering til at vælge den mest relevante modtager hos den modtagende myndighed, hvis der er en fællesoffentlig gevinst herved. Dette fremgår af analyse 2.6. OptimumIT Side 11 af 75

14 Afsendersystem Fordeler Kontaktregister Aftagersystem Afsend meddelse Mulig Autoklassification Send meddelelse Gem meddelelse B: Send teknisk kvittering Lever forretningskvittering Figur 4 Flow mellem myndigheder I Flow mellem myndigheder sendes meddelelser mellem afsender- og modtagersystem. Afsendersystemet sender et myndighedsidentifikator på modtageren, mens aftagersystemet bestemmes af Meddelelsesfordeleren, som har rettighed til at tilgå den modtagne myndighedsdata Myndighed til Borger & Virksomhed (brugergrænseflade) Når myndigheden sender til borger og virksomhed, som anvender et centralt lager, så er det myndighedens fagsystems ansvar at validere, at modtageren er tilmeldt Digital Post samt at tilføje relevant metadata til meddelelsen. OptimumIT Side 12 af 75

15 Myndighedens Fagsystem Kontaktregister Fordeler Lager Andre kanaler Generér Digital Post Opslag på tilmeldt Borger Tilmeldingssvar Send Meddelelse Kvittering Mulig Autoklassificering Frigørende virkning Forretningskvittering som meddelelse, hvis det ønskes Figur 5 Myndighed til Borger & Virksomhed I Flow mellem myndigheder og borger/virksomhed sendes meddelelser mellem afsender og lager. Afsendersystemet sender et aktørid på modtageren. Meddelelsesfordeleren foretager autoklassifikation hvis der er en fællesoffentlig gevinst herved, fx til anvendelse i portalen. Opslag i organisationhierarki foretages hvis der er en fællesoffentlig gevinst herved, fx i form af kanalvalg for borgeren. Meddelelsesfordeleren sender altid til lageret, hvis det er en væsentlig meddelelse, som kræver frigørende virkning eller ønsket af afsender eller modtagerens valg i kontaktregistret. Meddelelsesfordeler sender til en andre kanaler, hvis det er mærket som servicebesked eller mindre væsentlig meddelelse. Som udgangspunkt sender Meddelelsesfordeleren altid til lageret. OptimumIT Side 13 af 75

16 2.2.3 Myndighed til Virksomhed (systemgrænseflade) Myndighedens Fagsystem Kontaktregister Fordeling Aftagersystem Opslag på tilmeldt virksomhed Tilmeldingssvar Send Meddelelse Autoklassering Muligt opslag i organisationshierarki Send til lager Kvittering Send teknisk kvittering Figur 6 Myndighed til Virksomhed (systemgrænseflade) I Flow mellem myndighed til virksomhed sendes meddelelser mellem afsendersystemet og aftagersystemet. Afsendersystemet sender et aktørid på modtageren. Meddelelsesfordeleren foretager autoklassifikation og sender til aftagersystemet. Bemærk at dette medfører, at meddelelser sendt til aftagersystemer ikke persisteres i lageret for virksomheden. Det vil derfor være virksomhedens eget ansvar at opbevare og vise modtagne meddelelser. Den frigørende virkning sker ved afsendelse til fordeleren som videresender alle meddelelser til virksomhedens lager Borger, Virksomhed til Myndighed (brugergrænseflade) I Flow mellem borger/virksomhed og myndighed sendes meddelelser mellem den fællesoffentlige portal og aftagersystem. Afsendersystemet sender et aktørid på modtageren, hvorefter meddelelsesfordeleren foretager autoklassifikation og sender til lageret. OptimumIT Side 14 af 75

17 Webbrowser (Borger/Virksomhed) Fællesoffentlig Portal (Borger.dk/Virk.dk) Kontaktregister Fordeler Aftagersystem Login på portal (NemLog-in) Vis indbakke Opret mail Find tilmeldte Vis modtagere Vælg modtager Svar med tilmeldte Autoklassering Send kvittering Send forretningskvittering Vis besked leveret Figur 7 Borger, Virksomhed til Myndighed(brugergrænseflade) I Flow mellem borger og virksomhed til myndighed sendes meddelelser mellem portal og aftagersystem. Portalen sender et aktørid på modtageren, hvorefter meddelelsesfordeleren foretager autoklassifikation, finder aftagersystem i fælleskontaktregisteret og sender til aftagersystemet. Bemærk at dette medfører at sendte meddelelser til myndigheder ikke persisteres i lageret Virksomhed til Myndighed (systemgrænseflade) I Flow mellem virksomhed og myndighed sendes meddelelser mellem afsendersystem og modtagersystem. Afsendersystemet sender et aktørid på modtageren, hvorefter meddelelsesfordeleren foretager autoklassifikation og sender til modtager. OptimumIT Side 15 af 75

18 Afsendersystem Fordeler Kontaktregister Aftagersystem Afsend meddelse Mulig Autoklassification Send meddelelse Gem meddelelse B: Send teknisk kvittering Lever forretningskvittering Figur 8 Virksomhed til myndighed I Flow mellem virksomheder og myndigheder sendes meddelelser mellem afsendersystem og aftagersystem. Afsendersystemet sender et myndighedsid på modtageren, hvorefter meddelelsesfordeleren foretager autoklassifikation og finder myndigheden i kontaktregisteret. Bemærk at det er virksomhedens ansvar at gemme sendte meddelelser, da de ikke persisteres i lageret En-til-mange kommunikationsscenarier Modellen understøtter fuldt, at én afsender kan kommunikere med flere modtagere, og at disse kan svare individuelt. Det er muligt at sikre, at en bestemt modtager kan besvare afsenderen og ikke andre (med)modtagere ved at angive det i dataformatet. OptimumIT Side 16 af 75

19 Modellen understøtter ikke, at alle modtagere altid besvarer og at svaret altid sendes til alle andre modtagere (dvs. kræve svar til alle ) Mange-til-mange kommunikationsscenarier Modellen understøtter ikke, at flere myndigheder står som fælles afsender af Digital Post, idet der kun kan være én afsender på en given meddelelse. 2.3 Forretningsmæssige mål Modellen vurderes at opfylde forretningsbehovene på højt niveau, men det reduceres til mellem niveau grundet den senere samlede exit af den eksisterende løsning. Envejs- og tovejskommunikation er understøttet, således at interaktion i NgDP er bedre håndteret. Virksomheder kan enten vælge en fællesoffentlig portal eller en anden (privat) udbyder til adgang af Digital Post. I transitionen vil tovejskommunikation være begrænset, da anvendere, som benytter den eksisterende løsning, ikke vil sende meddelelser med yderligere tilknyttede metadata. Hvis kontaktregisteret understøtter det, kan fordeleren levere til dybere adressering i myndigheder og virksomheder. Fordeleren vil endvidere afkoble it-systemerne, så afsendersystemet ikke nødvendigvis skal kende aftagersystemernes endpoints og teknologi valg. Private udbydere kan tilgå et fælles lager, som giver mindre valgfrihed for leverandører, men sikrer en nem exitmulighed for borgere og virksomheder. Nedenstående tabel er en vurdering af modellens opfyldelsesgrad af gevinster: Gevinst Vurdering Fordele Ulemper G1: Berigelse af Metadata G2: Bedre understøttelse af visning og udfyldelse af formularer G3: Anvendelse af kommunikationslog God Mellem God Datastandarder for metadata giver mulighed for struktureret berigelse. En central fordeler kan give mulighed for en fællesoffentlig kapabilitet for autoklassificering. Datastandarder giver mulighed for bedre afsendelse. En Meddelelsesfordeler giver mulighed for, at en dialogtråd kan gives til brugeren på tværs af aktører. Såfremt en berigelse kræver data fra det lokale it-system som modtager meddelelsen, så er en central løsning til berigelse af data mindre anvendelig, da det vil være komplekst at integrere i alle lokale it-miljøer. Lageret vil i transitionsperioden ikke nødvendigvis kunne lagre ny metadata, som ikke er en del af den nuværende snitflades informationsmodel. Hvis en kommunikationslog skal give mest værdi, skal alle involverede it-systemer indgå i loggen. Digital Post modtager umiddelbart ikke meddelelser sendt mellem it-systemer inden for den samme myndighede/virksomhed, og vil derfor kun indeholde en OptimumIT Side 17 af 75

20 Gevinst Vurdering Fordele Ulemper G4: Forbedre adressering G5: Kontaktregister G6: Segmentering af henvendelsestyper God God God Kontaktregister og central fordeler giver mulighed for bedre routing, hvis opgaver og organisation kobles sammen. Kontaktregisteret anvendes i videst muligt omfang i denne model. Meddelelsesfordeleren gør det muligt at segmentere hændelsestyper og vælge kanal baseret på typen. delmængde af det samlede billede. Fordeling til skrivebordet, som en del af en lokal input management løsning, vil være mindre hensigtsmæssigt, hvis der kræves viden om state i det eksisterende it-miljø for modtageren. Her vil et input management system være nødvendigt for at løfte opgaven. Der vil i en periode være kontaktinformation i DP2 og i det nye kontaktregister, hvilket kan medføre dobbelt vedligehold af data. Segmentering vil som udgangspunkt være afsenderens ansvar, da det kan være en kompleks beslutning af vælge de rigtige henvendelsestyper. Følgende er en vurdering af modellens opfyldelsesgrad af NgDP projektets mål og delmål [Se bilag A for projektets mål og delmål]: Mål/delmål Vurdering Fordele Ulemper PM1 God Modellen er en kommunikationsinfrastruktur som kan håndtere sikker, dokumenterbar og uafviselig post. DM1 God Modellen kan sikre flere kanaler og typer af Digital Post med forskellige egenskaber. DM2 God Kontaktregisteret vil indeholde de nødvendige oplysninger. Sikkerhedsmodellen vil gøre det enkelt for borgere og virksomheder at administrere hvilke myndigheder og itsystemer, som har adgang til itsystemet. DM3 Mellem Den centrale meddelelsesfordeler kan håndtere en-til-mange kommunikation og en-til-en Modellen er i mindre grad en erstatning for tunnelmail. Pt. ingen. Pt. ingen. Mange-til-mange meddelelser skal hånderes i afsenderens itsystemer. OptimumIT Side 18 af 75

21 Mål/delmål Vurdering Fordele Ulemper kommunikation. DM4 Mellem Den fælles brugergrænseflade på borger.dk og virk.dk sikrer alle aktører en tilgængelig og brugervenlig grænseflade. Markedet kan endvidere bygge grænseflader til specifikke grupper, fx kuratorer, og dermed hæve deres brugeroplevelse. PM2 God Modellen anvender i høj grad fællesoffentlig infrastruktur til at sikre attraktiv og fokuseret kommunikationsinfrastruktur. Modulariseringen af målarkitekturen sikrer større frihed til valg af prismodel og finansieringsmodel. DM5 God Målarkitekturen kan konkurrenceudsættes regelmæssigt med veldefinerede snitflader baseret på datastandarder. PM3 God Mulighed for udvikling af komponenter alene giver bedre mulighed for videreudvikling ved at sænke risiko og forenkle udskiftning af leverandører. DM6 God Målarkitekturen åbner op for muligheden for konkurrenceudsættelse og differentieret udbudsstrategi. PM4 God Større anvendelse af datastandarder og anvendelse af organisationshierarki vil muliggøre bedre inputhåndtering. DM7 God Øget anvendelse af datastandarder vil sikre at indhold kan viderebehandles. DM8 God En central meddelelsesfordeler kan sikre at snitfladerne er enkle, ensartede og baserede på datastandarder, da Digitaliseringsstyrelsen kan sætte kravene til leverandøren. PM5 God Brugergrænsefladen på virk.dk og borger.dk kan bedre Det kan være komplekst at sikre post for kommunikationsscenariet virksomhed til virksomhed/borger anvender meddelelser fordeler og det centrale lager. Dette kan gøres attraktivt via incitamentsmodeller. Modellen afhænger af introduktionen af nye fællesoffentlige komponenter. Modellen vil primært tilvejebringe løsningens komponenter og i mindre grad facilitere markedets frembringelse af disse. Større ændringer kan kræve at alle komponenter ændres, hvilket vil være en øget kompleksitet i leverandørstyringen. Pt. ingen. Mere kompleks adressering i løsningen vil kræve vedligehold af organisationsstrukturer og opsætning regler for routing. Jf. PM4 Opdateringer af snitflader kræver ændringer i målarkitekturens komponenter. Skift mellem it-systemer hos afsender og modtager for at skabe OptimumIT Side 19 af 75

22 Mål/delmål Vurdering Fordele Ulemper understøtte single sign on og dermed bedre selvbetjeningsløsninger. DM9 God Målarkitekturen åbner op for større valgfrihed og bedre brugergrænseflader leveret af myndigheder tæt på deres brugere og leveret af markedet. PM6 Mellem Modellen understøtter at digital post fra myndigheder og virksomheder lagres i et centralt lager. PM7 God Modellen forudsætter paralleldrift med DP2 og den nye løsning ved en langsom udskiftning i en periode. På den måde kan myndigheder og virksomheder skifte systemgrænseflader i deres eget tempo. en sammenhængende brugerrejse vil stadig kræve en procesmotor som håndteres decentralt fx af et fagsystem. Pt. ingen væsentlige. Der er ingen mekanismer i modellen, der kan sikre, at lageret anvendes af virksomheder. Der vil være dobbeltvedligehold af DP2 og den nye løsning i en periode. Samlet set vurderes opfyldelsen af gevinster, projektets mål og delmål til at være på mellem niveau. 2.4 Arkitekturprincipper Det vurderes at modellen opfylder arkitekturprincipperne på et godt niveau. Forretningsbehovene sætter løsningen inden for modellens begrænsninger, og sikkerhed er en integreret del af modellen. Arkitekturen understøtter mulighed for private udbydere af portaler og services, hvilket gør konkurrence og innovation muligt efter transitionen. Modellens arkitektur baseres på løst koblede komponenter med veldefinerede snitflader, givet graden af standardisering på især afsendelse og modtagelse af meddelelser. Dermed understøtter modellen også interoperabilitet og åbenhed. Arkitekturens anvendelse af komponenter, herunder Sikkerhed og Meddelelsesfordeler giver en arkitektur med en række single points of failures. Endvidere vil en del komponenter skulle tilvejebringes. Især vil kontaktregisteret og fællesbrugerrettighedssystemet skulle kunne udbygges. Nedenstående tabel giver en oversigt over opfyldelsen af arkitekturprincipper. Scoren er angivet ved tal, hvor 3 er udmærket, 2 er god, og 1 er mindre god. Arkitekturprincip Vurdering Rationale Forretningsbehov 3 Modellen har en høj opfyldelse af forretningsmål jf. afsnit 2.3. OptimumIT Side 20 af 75

23 Informationssikkerhed 3 Modellen understøtter kravene for personfølsomhed, sikkerhed og kryptering på forbindelserne, fx via TLS/SSL. Fællesoffentlig metoderamme 3 Informationsmodeller anvendes efter principperne i datastandardisering i sektorerne. Der fokuseres på overholdelse af internationale standarder. Projektmodellen forventes at følge den fællesstatslige projektmodel, herunder sikring af det rette niveau af afklaring og risikohåndtering. Borgere og virksomheder 3 Flytningen af udviklingen af brugergrænseflade til borgere og virksomheder til virk.dk og borger.dk vil medføre at it-understøttelsen af arbejdsgangene bliver mere målrettet deres forretningsbehov. Processer bør optimeres 2 Funktionalitet for administration af Sikkerhed (fx tilsluttede systemer, fuldmagt), information om kontakter udskilles, således at funktionaliteten ligger tæt på de systemer, hvor data vedligeholdes. Endvidere vil større anvendelse af standardiserede snitflader give større mulighed for optimering af processer på tværs. Data og services bør genbruges 2 Det er en fordel at Kontaktregister, Sikkerhed og lager kan anvendes af andre it-systemer og services. Styrk konkurrence og innovation 3 Modularisering og ejerskabsmodellen i løsningen sikrer, at komponenter kan konkurrenceudsættes og facilitere markedet. Forsyningssikkerheden på kernefunktionalitet vejer dog tungere end markedsgørelse på de centrale komponenter. Løst koblede komponenter 3 Komponenterne er løst koblede med anvendelsen af datastandarder. Fleksible løsninger 2 Komponenterne er fleksible, men har indbyrdes afhængigheder. Komponenterne Sikkerhed og Fællesoffentligt Kontaktregister er således kritiske for de øvrige komponenter. Anskaffelsesmuligheder 3 Mange af de udstillede komponenter findes allerede i dag i forskellige varianter i det fællesoffentlige itlandskab. Der er således god basis for, at de valgte komponenter kan tilvejebringes under udbud. Interoperabilitet 3 Interoperabilitet sikres ved at anvende høj grad af datastandarder og en klar versionsstrategi for snitflader, som udstilles. Sikkerhed 3 Løsningen skal basere sig på kendte sikkerhedsstandarder og metoder (fx SAML 2.0 og TLS/MPLS). Konkrete sikkerhedskrav kendes ikke i detaljer, men det skal være i fokus, at data kan bevæge sig igennem forskellige driftsmiljøer. Åbenhed 3 Modellen giver større valgfrihed for borgere og OptimumIT Side 21 af 75

24 virksomheder. Skalerbarhed 3 Modellens komponenter vurderes skalerbare, både horisontalt og vertikalt. 2.5 Softwaremæssige kvalitative egenskaber Model A vurderes overordnet til at have meget gode softwaremæssige kvalitative egenskaber, da modellen har en god vurdering på alle otte dimensioner. Man skal dog være opmærksom på, at den samlede løsning er karakteriseret ved et stort antal integrationer til meddelelsesfordeleren og kontaktregisteret Funktionel Egnethed Funktionel egnethed vurderes ud fra funktionalitet i bilag B og kommunikationsscenarierne i bilag C. Kommunikationsscenarierne er opfyldt for alle scenarier, dog undtaget mange-til-mange forsendelser, som vil resultere i en meddelelse per modtager og afsender Performance For de fællesoffentlige portalers vedkommende må det forventes, at tilsvarende performance vil kunne leveres. Det forventede omfang på 85 millioner meddelelser per år giver et gennemsnit på cirka 3 meddelelser per sekund. Dette vurderes at kunne håndteres af de enkelte komponenter. Der skal senere suppleres med en måling af spidsbelastningen. Kontaktregisteret er i dette, såvel som i de øvrige modeller, centralt. Det er derfor vigtigt, at performance af kontaktregisteret sikres gennem design, udvikling og implementering Kompabilitet Målarkitekturens systemgrænseflader har en høj grad af kompatibilitet, givet brug af eksisterende, modne teknologistandarder, samt facilitering af opdaterede datastandarder. I transitionen vil både de eksisterende snitflader og de nye snitflader være tilgængelige Usability Brugervenligheden af de fællesoffentlige portaler skal sikres gennem design og udvikling. Alle borgere skal kunne anvende løsningen, hvilket sandsynligvis kræver overholdelse af - som minimum - dele af WCAG 2.0 standarden i brugergrænsefladen. Dette er i tråd med kravene til de eksisterende fællesoffentlige portaler, og det må derfor forventes, at de eksisterende projekter bag borger.dk og virk.dk har erfaring med dette. Brugervenlighed kan endvidere blive et konkurrenceparameter for de private udbydere i modellen, hvilket vil komme borgere og virksomheder til gode Pålidelighed Det forventes, at tilsvarende pålidelighed vil kunne leveres for de fællesoffentlige portalers, meddelelsesfordeler og fællesoffentligt kontakt register. I transitionsperioden vil DP2 kunne leveres med samme driftssikkerhed som i dag, hvilket er tilfredsstillende. OptimumIT Side 22 af 75

25 Forsendelse af servicebeskeder og andre mindre væsentlige meddelelser sker på SMS og , der er velkendte og modne teknologier, som har en høj grad af pålidelighed. Pålideligheden af den samlede løsning kan øges ved at samle driftsafviklingen af komponenterne hos 1-2 driftsleverandører Sikkerhed Den eksisterende Digital Post løsning håndterer selv aftaler og brugeres rettigheder til postkasser. Denne funktionalitet udskilles i modellen og håndteres i stedet af sikkerhedskomponenten. De fællesoffentlige portaler anvender den fuldmagts- og underskriftsfunktionalitet der implementeres gennem den fællesoffentlige brugerrettighedsstyrings komponent (FBRS) og NemLog-in, der indgår i sikkerhedskomponenten. Sikkerhedskomponenten styrer adgangen fra de fællesoffentlige portaler til borgeres og mindre virksomheders meddelelser, så borgere har læseadgang til lageret, men afgrænset til eget personnummer samt eventuelle fuldmagter. Understøttelse af single-sign-on er nødvendig for at sikre sømløs integration til fx selvbetjeningsløsninger. Den konkrete opgavefordeling mellem it-systemerne i Sikkerhedskomponenten er ikke endeligt fastlagt. Private udbydere skal tilbyde en sikkerhed, der er tilsvarende, men dette vil skulle løses via certificeringsprogrammets krav til udbyderen. Kommunikation mellem komponenterne skal have sikkerhed på forbindelsesniveauet (transport level security), eller tilsvarende Vedligeholdelse Modellen understøtter ikke specifikt vedligeholdelse, men afkobling og distribuering af komponenterne, samt anvendelse af standarder vil øge muligheden for vedligehold af hver enkelt komponent. DP2 vedligeholdelse i transitionsperioden inkluderer et minimum af udvikling, og det forventes at være så stabilt som muligt Portability Modellen vurderes rimeligt portabel i forhold til driftsplatforme. Umiddelbart vil både kontaktregister, FBRS og lager skulle porteres. Ved anvendelse af en fælles driftsplatform vil systemerne kunne porteres samlet i tilfælde af skift af driftsleverandør. 2.6 Ejerskab, drift og forvaltning I modellen skal alle komponenterne - lager, meddelelsesfordeler, fællesoffentligt kontaktregister, og sikkerhed - tilvejebringes fællesoffentligt. De fællesoffentlige portaler skal enten tilvejebringes helt eller delvist eller faciliteres sammen med borger.dk og virk.dk. Digitaliseringsstyrelsen skal facilitere, at der opstår et marked for private udbydere af brugergrænseflader. Dette skal bl.a. ske ved markedsgørelse af funktionalitet samt definition af governance og evt. et certificeringsprogram. OptimumIT Side 23 af 75

26 Digitaliseringsstyrelsen skal sikre driftsafvikling af sikkerhed, kontaktregisteret, meddelelsesfordeler, lager og eventuelt de fællesoffentlige portalers visning af Digital Post. I modellen skal Digitaliseringsstyrelsen således tilvejebringe infrastruktur- og applikationsdrift samt applikationsvedligehold af kontaktregisteret. Til de fællesoffentlige portaler må det antages, at Digitaliseringsstyrelsen skal tilvejebringe applikationsvedligehold af visningen af Digital Post og muligvis også applikationsdrift. Digitaliseringsstyrelsen anbefales at have en fælles driftsstrategi, som sikrer en samlet, stabil driftsafvikling. Digitaliseringsstyrelsen skal være ansvarlig for et standardiserings- og certificeringsprogram, så private udbydere kan understøttes. 2.7 Migration og transition Målarkitekturen for Model A og Model B er ens. Transitionen er dog væsentligt forskellig. Nedenstående figur viser den eksisterende Digital Post løsnings (venstre side af figuren) transition over i målarkitekturen (højre side). Pilene illustrerer hvor komponenter i den eksisterende løsning ender i den nye løsning. De forskellige farver er blot anvendt for bedre at synliggøre, hvor hver komponent ender. Figur 9 Overblik over Model A En af de store udfordringer ved transitionen er, at alle myndigheder og virksomheder skal ændre deres it-løsninger i mindre omfang. Samtidigt ønskes størst mulige kontinuitet for borgere og virksomheder. Udskillelse af grænseflader fra den eksisterende løsning er komplekst, men højt prioriteret for myndighederne især på virksomhedsområdet. En udskillelse vil medføre, at DP2 skal udstille en grænseflade til at vise meddelelser fra myndigheder og virksomheder, og at der skal udarbejdes en ny portal for henholdsvis borger.dk og virk.dk. Selvom det er komplekst og kræver videreudvikling af DP2, vil en hurtig udskillelse af grænsefladen give mulighed for en hurtigere forbedring af brugergrænsefladerne. OptimumIT Side 24 af 75

27 En anden mulighed ville være at indkøbe et nyt lager med målarkitekturens snitflade tidligt i transitionen. Det vil imidlertid medføre at alle aftagersystemer og integrationer skal ændres i starten af transitionen, fordi lageret ikke anvender samme datastandard, kontakthierarkier, sikkerhed og opmærkning som den eksisterende løsning. Det vil derfor være en fordel at lageret kan sameksistere i den eksisterende løsning i transitionsperioden, fordi det sikrer, at den nuværende opsætning af aftagersystemer og konfigurationen i administrationsportalen kan bevares i transitionsperioden. Meddelelsesfordeleren kan ikke direkte udskiftes i den nuværende løsning, men det kunne være en mulighed at anskaffe en ny meddelelsesfordeler, som kan modtage og distribuere post. Den nye fordeler vil så sende videre til DP2, hvis modtageren ikke er migreret til den nye løsning. Dette kan gøres ved at registrere meddelelsesfordeleren som afsendersystem i DP2 løsningen. Det vil give mulighed for hurtigere gevinster med dataopmærkning og en attraktiv prismodel for de meddelelser, som ikke sendes videre til den eksisterende Digital Post. Sikkerhed og fællesoffentligt kontaktregister er kritiske afhængigheder, da de andre komponenter bygger oven på dem. Sikkerhed og fællesoffentligt kontaktregister er derfor nødvendige for at kunne udfase lageret, meddelelsesfordeler, portal og systemgrænseflader fra den eksisterende løsning. Ovenstående argumentation udmønter sig i en transitionen for Model A i to faser: Fase 1 som realiserer en ny brugergrænseflade og meddelelsesfordeler som fungerer parallelt med DP2. Det betyder at de eksisterende snitflader udstilles af DP2, mens de nye snitfalder, med mindre opdateringer, udstilles af meddelelsesfordeleren. Dermed skal meddelelsesfordeleren ikke implementere alle eksisterende snitflader. Konfigurationsdata vil ikke blive migreret i første fase, men eksistere parallelt, mens meddelelser kun findes i DP2 lageret. Fase 2 som anskaffer et nyt lager, migrerer meddelelser til det nye lager fra DP2 og herefter udfaser DP2. Det resulterer i følgende transitionsarkitektur for fase 1 i Model A: OptimumIT Side 25 af 75

28 Figur 10 Transitionsarkitektur for Model A Man vil således have en Meddelelsesfordeler som kan give effektiv kommunikation til større virksomheder og myndigheder, samt nye forbedrede grænseflader til borgere og især virksomheder fra 1/ Tilsvarende skal de nye komponenter anvende fællesoffentligt kontaktregister og fællesoffentlig brugerrettighedsstyring i ny version. Disse to komponenter antages også at være klar ca. 1/ Fase 2 går i pilotdrift 1/ og afsluttes i 1/ Nedenstående figur illustrerer et faseopdelt transitionsforløb og den efterfølgende drift af den nye infrastruktur. Faseangivelsen er baseret på den fællesstatslige projektmodel. Ide- og Analysefaser er således markeret samlet med I, Anskaffelsesfaser er angivet med A, Gennemførelsesfaser med G, pilotdrift med P og Realiseringsfaser med R. Den røde streg markerer en overgang mellem gennemførelse og pilotdrift/realisering. Figur 11 Overordnet tidsp lan for Model A OptimumIT Side 26 af 75

29 Model A understøtter muligheden for at migrere borgere og virksomheders eksisterende digitale post meddelelser ind i den nye løsning. Data for meddelelser ligger i DP2 til udgangen af 2020, hvorfra de skal migreres til det nye lager. Administrationsportalen, Kontakthierarkier og andet metadata udgår gradvist fra den eksisterende løsning og skal derfor ikke migreres. De anbefalede migreringsstrategier er derfor: Fuld datakonvertering til det fællesoffentlige lager idet der foreligger en specifikation af udtræksformatet, der kan anvendes til indlæsning. Den nuværende Digital Post løsning anvendes som centralt lager indtil udgangen af Ved skift af udbyder for centralt lager skal borgeren eller virksomheden ikke foretage migrering af data, da der er et centralt lager Kommunikationsscenarier mellem modellens komponenter og aktører i transitionens fase 1 I dette afsnit beskrives kommunikationsscenarier for hvordan digital post flyder mellem borgere, virksomheder og myndigheder i transitionen. I denne fase af transitionen er der tilvejebragt en meddelelsesfordeler, kontaktregister og brugergrænseflader udstillet af borger.dk og virk. DP2 er stadig en kørende løsning med snitflader til it-systemer, egen brugergrænseflade, lager og håndtering af rettigheder. Alle borgere anvender som udgangspunkt den nye grænseflade på borger.dk. De virksomheder som anvender DP2 brugergrænsefladen vil tilsvarende anvende den nye grænseflade på virk.dk. De virksomheder, som anvender afhentningssystemer, kan frit vælge tidspunktet for at skifte til meddelelsesfordeleren. I transitionsperioden vil der således være virksomheder, som anvender den eksisterende DP2 løsning, og virksomheder som anvender meddelelsesfordeler. I begge tilfælde vil modtagne meddelelser lagres i DP2. Flowet beskrives gennem UML sekvensdiagrammer nedenstående afsnit. Transitionen beskrives i ovenstående afsnit. Modellen understøtter i fuldt omfang kommunikation mellem borgere, virksomheder og til og fra myndigheder. I det følgende beskrives flowet mellem aktører og modellens komponenter. Autentificering/autorisering mellem komponenter er ikke medtaget i diagrammet Myndighed til Myndighed Myndighed til myndighed sendes via fordeleren. Den afsendende myndighed tilknytter metadata om modtageren. Meddelelsesfordeleren anvender kontaktregistreret og autoklassifikation til at vælge den mest relevante modtager hos modtagende myndighed. Såfremt modtagende myndighed i en kort periode stadig anvender DP2, vil dokumentet sendes til DP2, som videresender til myndigheden via den eksisterende funktionalitet i DP2. OptimumIT Side 27 af 75

30 Afsendersystem Kontaktregister Meddelelsesfordeler DP2 Aftagersystem Opslag på myndighedid Send Meddelelse Mulig Autoklassificering Muligt opslag i organisationshierarki Anvendelses af den nye løsning Send til DP2 Forretningskvittering som meddelelse, hvis det ønskes Figur 12 Flow mellem myndigheder i transitionen for Model A I Flowet beskrives hvorledes myndigheder sender meddelelser mellem afsendersystem og aftagersystem. Afsendersystemet sender et myndighedsidentifikator på modtagende myndighed, men aftagersystemet bestemmes af meddelelsesfordeleren Myndighed til Borger & Virksomhed (brugergrænseflade) I Flow mellem myndigheder og borger/virksomhed sendes meddelelser fra afsendersystem til lager eller direkte til virksomhedens aftagersystem. Afsendersystemet sender et aktørid på modtageren, hvorefter meddelelsesfordeleren udfører autoklassifikation og vælger kanalen. OptimumIT Side 28 af 75

31 Afsendersystem Kontaktregister Meddelelsesfordeler DP2 Aftagersystem Opslag på tilmeldt Borger/virksomhed Tilmeldingssvar Send Meddelelse Mulig Autoklassificering Muligt opslag i organisationshierarki Anvendes den nye løsning? Send til DP2 Forretningskvittering som meddelelse, hvis det ønskes Figur 13 Myndighed til Borger & Virksomhed for Model A I Flow mellem myndigheder og borger/virksomhed vil der i transitionen være tre muligheder: Borgere og virksomheder som anvender DP2 lager og brugergrænsefladen. Virksomheder som har et aftagersystem registreret hos DP2 Virksomheder som har et aftagersystem registreret hos meddelelsesfordeleren Meddelelsesfordeleren foretager autoklassifikation, hvis der er en fællesoffentlig gevinst herved. Det er en mulighed at Meddelelsesfordeleren kan sende via andre kanaler fx SMS eller , hvis det er mærket som servicebesked eller mindre væsentlig meddelelse. Som udgangspunkt sendes altid til lageret Borger, Virksomhed til Myndighed (brugergrænseflade) I Flow fra virksomhed eller borger til myndighed sendes meddelelser fra den fællesoffentlige portal til aftager. Portalen sender et aktørid på modtageren, hvorefter meddelelsesfordeleren foretager en autoklassifikation og sender til aftagersystemet. Bemærk at dette medfører at meddelelser sendt til aftagersystemer ikke persisteres i lageret. I dette tilfælde vil det være virksomhedens eget ansvar at gemme afsendte meddelelser. I tilfælde af at myndigheden anvender DP2 videresender meddelelsesformidleren til DP2. OptimumIT Side 29 af 75

32 Webbrowser (Borger/Virksomhed) Fællesoffentlig Portal (Borger.dk/Virk.dk) Kontaktregister Fordeler Aftagersystem DP2 Login på portal (NemLog-in) Opret mail Find tilmeldte Vis modtagere Svar med tilmeldte Send Send kvittering Send til DB2 Videresend fra DB2 Figur 14 Borger, Virksomhed til Myndighed(brugergrænseflade) I Flow mellem borger og virksomhed til myndighed sendes meddelelser mellem portal og aftagersystem. Portalen sender et aktørid på modtageren, hvorefter meddelelsesfordeleren sender til aftagersystemet. Bemærk at dette medfører at sendte meddelelser til myndigheder ikke persisteres i DP2 lager. Hvis myndigheden stadig anvender DP2, videresender meddelelsesfordeleren til DP2, som sender til myndighedens aftagersystem Virksomhed til Myndighed (systemgrænseflade) I Flow mellem virksomheder og myndigheder sendes meddelelser mellem afsendersystem og aftagersystem. Afsendersystemet sender en myndighedsid på modtageren, hvorefter meddelelsesfordeleren foretager en autoklassifikation og finder myndigheden i kontaktregisteret. Bemærk at det er virksomhedens ansvar at gemme sendte mails, da de ikke persisteres i lageret. OptimumIT Side 30 af 75

33 Afsendersystem Kontaktregister Meddelelsesfordeler DP2 Aftagersystem Opslag på tilmelding Tilmeldingssvar Send Meddelelse Mulig Autoklassificering Muligt opslag i organisationshierarki Anvendes den nye løsning? Send til DP2 Forretningskvittering som meddelelse, hvis det ønskes Figur 15 Virksomhed til myndighed I Flow mellem virksomheder og myndigheder sendes meddelelser mellem afsendersystem og aftagersystem. Afsendersystemet sender et myndighedsid på modtageren, hvorefter meddelelsesfordeleren foretager autoklassifikation og finder myndigheden i kontaktregisteret. Bemærk at det er virksomhedens ansvar at gemme sendte meddelelser, da de ikke persisteres i lageret En-til-mange kommunikationsscenarier Transitionsarkitekturen, som understøtter at én afsender kan kommunikere med flere modtagere, og at disse kan svare individuelt. Det er muligt at sikre, at en bestemt modtager kan besvare afsenderen og ikke andre (med)modtagere. Tilsvarende er det ikke muligt at sikre at alle modtagere altid besvarer til alle andre modtagere (dvs. kræve svar til alle ) Mange-til-mange kommunikationsscenarier Modellen understøtter ikke, at flere myndigheder står som fælles afsender af Digital Post, idet der kun kan være én afsender på en given meddelelse. 2.8 Risikoanalyse Risikoanalysen nedenfor indeholder de identificerede operationelle risici, som vil kunne medføre at projektet NgDP ikke realiseres som planlagt. OptimumIT Side 31 af 75

34 Risikovurderingen indeholder for hver risiko en beskrivelse, kategorisering, og en vurdering af risikoens effekt (sandsynligheden for, at risikoen indtræffer, og påvirkningen hvis dette sker). Desuden angives et forslag til korrigerende handlinger, samt en vurdering af risikoens effekt efter korrigerende handlinger. Beskrivelse Kategori Sandsynlighed og Påvirkning Korrigerende handlinger Residual risiko Krævede lovmæssige ændringer ved at have flere systemejere m.m. er problematisk Juridisk, Implementering Lav sandsynlighed, Høj påvirkning. Digitaliseringsstyrelsen bliver systemejer for alle komponenter. Mindre impact, men en systemejer kræver aftaler med involverede styrelser. Brugervenlighe d og driftsmæssig tilgængelighed er utilstrækkelig i fællesoffentlige distribueret arkitektur Teknisk, Leverandørstyrings opgaven Har en mellem sandsynlighed, med en mellem påvirkning tilsvarende andre offentlige projekter. Digitaliseringsstyrelsen sikrer samarbejde med øvrige myndigheder inden udbud, herunder bør Digitaliseringsstyrelsen overveje at konsolidere driftsafviklingen på få driftsleverandører. Ved en eller to ansvars havende leverandører vil driftsmiljøets stabilitet sikres bedre. Krævede lovmæssige ændringer for opbevaring af elektroniske dokumenter for borgere og mindre virksomheder Juridisk, Implementering Høj risiko og høj påvirkning af projektet. Lovgivninger i dag er primært rettet mod at udskifte papirpost med digital post, herunder sikring af frigørende virkning baseret på et it-system. Lovgivningen skal opdateres således at andre meddelelsestyper er dækket og målarkitekturen dermed er understøttet lovgivningen. Risikoen er stadig høj, men påvirkningen bliver lav. Kontakt registeret bliver flaskehals Teknisk, driftssituationen Lav risiko, høj påvirkning. Under tilvejebringelsen fokuseres på afklaring af performance- og skaleringsbehov. Dette vægtes højt under anskaffelsen og afprøves inden overtagelse. Lav risiko, lav påvirkning. OptimumIT Side 32 af 75

35 Beskrivelse Kategori Sandsynlighed og Påvirkning Korrigerende handlinger Residual risiko Markedsgørelse lykkes ikke Forretning, Leverancesikkerhed Mellem risiko, men lavere påvirkning fordi alle kritiske komponenter tilvejebringes. Manglende anskaffelse kan modsvares ved markedsdialog og incitamentsstruktur. Lav risiko ved dialog og stadig lav påvirkning. Ændringen af løsningen medfører for store ændringer for interessenter Forretning, Implementering Lav risiko fordi transitionen sker glidende og datamigrering er mindre kompleks. Høj påvirkning, da store ændringer kan påvirke realiseringsmulighederne. Digitaliseringsstyrelsen afsætter ressourcer til at understøtte borgere, virksomheder og myndigheder. Væsentlige interessenter høres om udbudsmateriale og implementeringsplaner. Lav risiko, men påvirkningen kan mindskes ved inddragelse. Den eksisterende leverandør kan ikke levere nye snitflader inden for tidsrammen Forretning, Leverancesikkerhed Høj sandsynlighed grundet tidligere leverance forløb og høj påvirkning, da brugergrænseflader ikke kan udvikles uden adgang til lageret. Integrationen mellem de to komponenter skal begrænses til det mindst mulige. Endvidere bør der være en incitamentsstruktur og inddragelse, som styrer leverandørens adfærd. Sandsynligheden kan gøres mindre ved at påbegynde arbejdet hurtigst muligt. Sandsynligheden kan nedsættes og påvirkningen burde kunne håndteres Fx ved udsættelse af driftsstart eller scope reduktion. Samlet set vurderes risikobilledet til at være på mellem niveau. På grund af den nuværende situation med kontraktophør er et nulscenarie ikke muligt. Denne model har en langsom udfasning med en så tidlig driftsstart som muligt, hvilket sikrer tid til korrigerende handlinger fra programledelse og styregruppe. Der udestår væsentlige juridiske afklaringer, og leverancesikkerheden for videreudvikling af DP2 skal sikres på et tidligt tidspunkt i programmet. En øget risikostyring fx ved anvendelse af paralleldrift vil påvirke business casen negativt i forhold til økonomien. Der er dog gevinster ved at kunne realisere dele af målarkitekturen på et tidligere tidspunkt end en samlede idriftssættelse. 2.9 Økonomiske egenskaber De økonomiske egenskaber vurderes kvalitativt på overordnet niveau. Vurderingen anvender skalaen Mindre godt, Mellem og Godt. OptimumIT Side 33 af 75

36 Vurderingen for Model A er som følger: Anlæg: Mindre godt Model A vurderes til vurderingsniveauet Mindre godt for anlægsomkostninger. Model A vurderes således til at have et relativt højt niveau af anlægsomkostninger, idet der skal tilvejebringes en række fællesoffentlige komponenter, eksempelvis til visning af Digital Post i fællesoffentlige portaler. Det forventes dog, at komponenterne, der skal anskaffes, i høj grad vil kunne anskaffes som standardprogrammel. I forbindelse med tilvejebringelsen af Model A skal data migreres fra den eksisterende løsning, men det vurderes at udgøre en relativ begrænset anlægsomkostning, da migreringen kan baseres på eksisterende kontrakt med leverandøren af eksisterende løsning. Drift: Mellem Model A vurderes til vurderingsniveauet Mellem niveau for driftsomkostninger. Model A vurderes således at have et middel niveau af driftsomkostninger. Det vægter positivt at den fremtidige løsning for Model A forventes at have væsentligt lavere driftsomkostninger baseret på en kapacitetsbaseret afregningsmodel i sammenligning med den nuværende løsnings forbrugsbaserede afregningsmodel. Det vægter negativt at driftsomkostningerne vil dog i en periode være forhøjet grundet parallel drift af løsningen for Model A sammen med den nuværende løsning. Myndigheder: Godt Model A vurderes til vurderingsniveauet Godt for de samlede omkostninger for andre myndigheder. Model A vurderes således at have et lavt niveau af omkostninger for andre myndigheder, idet myndighederne kun skal bekoste en relativ simpel transition af integrationer til Model A, samtidig med at udgiftsmodellen for brug af løsningen i højere grad end for den nuværende løsning afspejler de faktiske omkostninger. Det er yderligere med til at begrænse myndighedernes omkostninger at transitionsperioden er lang nok til, at myndighederne har mulighed for at transitionere integrationerne som en del af planlagte videreudviklingsaktiviteter. Det er en forudsætning, at det er muligt at de nye snitflader kun har mindre opdateringer. Selv mindre påvirkninger af de eksisterende snitflader vil således medføre forøgede, samlede omkostninger for andre myndigheder, idet det samlede antal integrationer er relativt stort. Antallet af integrationer er opgjort til Sammenfatning af Model A Samlet set vurderes Model A at opfylde vurderingsparametrene og rammesætningen på et godt niveau. Projektmål, delmål og gevinster vil i høj grad kunne realiseres. Dog trækker det vurderingen lidt ned, at transitionen først er afsluttet 1/ Modellen lever i høj grad op til projektets arkitekturprincipper og de kvalitative egenskaber særligt i forhold til løst koblede komponenter, interoperabilitet og konkurrenceudsættelse. Modellen giver mulighed for en høj grad af offentligt ejerskab over kritiske komponenter, således at komponenterne kan genudbydes regelmæssigt. Endvidere vil anvendelse af datastandarder give en højere udnyttelse af gevinsterne ved dataopmærkning og intelligent brug af data. Det vil dog give Digitaliseringsstyrelsen en opgave med forvaltning af datastandarderne. Modellen har samlet set et risikobillede på mellem niveau. Især påvirkningen af myndigheder og virksomheder vil være lav, jf. afsnit 2.8. OptimumIT Side 34 af 75

37 Samlet set vurderes modellen som det bedste valg, idet modellen indeholder en mellem opfyldelse af mål og gevinster og har et mellem udgiftsniveau. Det vægter positivt, at Digitaliseringsstyrelsens får en standardiseret og driftssikker løsning ved brug af standardbaserede komponenter, samt en kontinuerlig overgang med mellem risikobillede. Det vægter negativt, at der er væsentlige omkostninger i en transitionsperiode samt en moderat mere kompleks itarkitektur ved driftsafvikling. OptimumIT Side 35 af 75

38 3 Model B Hurtig idriftsættelse af Næste generation DP Denne model baseres på tilvejebringelse af en ny løsning, som afløser for den eksisterende DP2 løsning. Et nulscenarie er pt. ikke muligt, da kontrakten udløber 1/ Efter en overordnet juridisk afklaring vil der herefter skulle udarbejdes et nyt udbud på en ny løsning og den nuværende løsning kan ikke videreføres. Model B skal endvidere understøtte de væsentligste drivere i projektet. Det har derfor været resultatet af fase 2, at modellen har samme målarkitektur som Model A, men med en anderledes transition og migrering. Transitionen sker ved model B på én gang uden mellemliggende transitionsarkitekturer. Nedenstående figur viser den eksisterende Digital Post løsnings (venstre side af figuren) transition over i målarkitekturen (højre side). Pilene illustrerer hvor komponenter i den eksisterende løsning ender i den nye løsning. De forskellige farver er blot anvendt for bedre at synliggøre, hvor hver komponent ender. Figur 16 Overblik over DP2 transition til Model B DP2 vil løbe i den nuværende kontrakt inklusive et sidste migrationsår og er dermed fuldt udfaset medio De eksisterende snitflader på DP2 kan derfor anvendes indtil den nye løsning idriftsættes. 3.1 Overblik over modellen Løsningen består af række uafhængige komponenter, som tilsammen giver den fornødne funktionalitet. Målarkitekturen væsentligste egenskaber svarer til Model A, og der henvises derfor til afsnit 2.1, hvor målarkitekturen beskrives. 3.2 Kommunikationsscenarier mellem modellens komponenter og aktører I dette afsnit beskrives hvordan digital post flyder mellem borgere, virksomheder og myndigheder i målarkitekturen. Modellen understøtter i fuldt omfang kommunikation mellem borgere, virksomheder og til og fra myndigheder. Modellen understøtter tovejskommunikation mellem borgere, virksomheder og myndigheder. Kommunikationens anvendelighed kræver dog, at der anvendes en ny datastandard, hvor dialogen OptimumIT Side 36 af 75

39 kan opmærkes for både virksomheder og myndigheder. I den nuværende DP2 løsning er metadata opmærkning forskellig, alt efter om modtageren er en virksomhed eller myndighed, fordi muligheden for at tilknytte metadata til virksomheder er mere begrænset. Kommunikationsscenarierne svarer til Model A, og der henvises derfor til afsnit 2.2, hvor kommunikationsscenarierne mellem aktører og modellens komponenter beskrives. 3.3 Forretningsmæssige mål Modellen understøtter sikker, uafviselig og effektiv kommunikation mellem myndigheder, borgere og virksomheder. Modellen har en hurtigere idriftsættelse af næste generation Digital Post, hvilket vægter positivt. I det følgende er en vurdering af gevinster, mål og delmål. I nedenstående er de mål, som er forskellige fra Model A, angivet med blå skrift. Følgende er en vurdering af modellens opfyldelsesgrad af gevinster: Gevinst Vurdering Fordele Ulemper G1: Berigelse af Metadata G2: Bedre understøttelse af visning og udfyldelse af formularer G3: Anvendelse af kommunikationslog G4: Forbedre adressering G5: Kontaktregister G6: Segmentering af henvendelsestyper God God God God God God Datastandarder for metadata kan give mulighed for struktureret berigelse. En central fordeler kan give mulighed for en fællesoffentlig komponent. Datastandarder giver mulighed for bedre afsendelse. En Meddelelsesfordeler giver mulighed for at en dialogtråd kan gives til brugeren. Kontaktregister og central fordeler giver mulighed for bedre routing, hvis opgaver og organisation kobles sammen. Kontaktregisteret anvendes i videst muligt omfang i denne model. Meddelelsesfordeleren gør det muligt at segmentere hændelsestyper og vælge Såfremt en berigelse kræver data fra det lokale it-system som modtager meddelelsen, så er en central løsning mindre anvendelig. Eksisterende data skal dog migreres. Hvis en kommunikationslog skal give mest værdi, skal alle involverede it-systemer indgå i loggen. Fordeling, som en del af input management, vil være mindre hensigtsmæssigt, hvis der kræves viden om state i det eksisterende it-miljø for modtageren. Her vil et input management system være nødvendigt for at løfte opgaven. De eksisterende kontakthierarkier skal konverteres til det nye kontaktregister. Segmentering vil som udgangspunkt være afsenderens ansvar. OptimumIT Side 37 af 75

40 Gevinst Vurdering Fordele Ulemper kanal baseret på typen. Følgende er en vurdering af modellens opfyldelsesgrad af projektets mål og delmål: [Se bilag A for projektets mål og delmål] Mål/delmål Vurdering Fordele Ulemper PM1 God Modellen er en kommunikationsinfrastruktur, som kan håndtere sikker, dokumenterbar og uafviselig post. DM1 God Modellen kan sikre flere kanaler og typer af Digital Post med forskellige egenskaber. DM2 God Kontaktregisteret vil indeholde de nødvendige oplysninger. Sikkerhedsmodellen vil gøre det enkelt for borgere og virksomheder at administrere hvilke myndigheder og itsystemer, som har adgang til itsystemet. DM3 Mellem Den centrale meddelelsesfordeler kan håndtere en-til-mange kommunikation og en-til-en kommunikation. DM4 Mellem Den fælles brugergrænseflade på borger.dk og virk.dk sikrer alle grupper en tilgængelig og brugervenlig grænseflade. Markedet kan endvidere bygge grænseflader til specifikke grupper, fx kuratorer, og dermed hæve deres brugeroplevelse. PM2 God Modellen anvender i høj grad fællesoffentlig infrastruktur til at sikre attraktiv og fokuseret kommunikationsinfrastruktur. Modulariseringen af målarkitektruren sikrer større frihed til valg af prismodel og finansieringsmodel. DM5 God Målarkitekturen kan konkurrenceudsættes regelmæssigt med veldefinerede snitflader baseret på Modellen er i mindre grad en erstatning for tunnelmail. Pt. ingen. Pt. ingen. Mange-til-mange meddelelser skal håndteres i afsenderens itsystemer. Det kan være komplekst at sikre post fra virksomhed til virksomhed/borger anvender det centrale lager. Modellen afhænger af introduktion af nye fællesoffentlige komponenter. Modellen vil primært tilvejebringe løsningens komponenter og i mindre grad facilitere markedets frembringelse af dem. OptimumIT Side 38 af 75

41 Mål/delmål Vurdering Fordele Ulemper datastandarder. PM3 God Mulighed for udvikling af komponenter alene giver bedre mulighed for videreudvikling ved at sænke risikoen og forenkle udskiftningen af leverandører. DM6 God Målarkitekturen åbner op for muligheden for konkurrenceudsættelse og fleksible kontrakter. PM4 God Større anvendelse af datastandarder og anvendelse af organisationshierarki vil muliggøre bedre inputhåndtering. DM7 God Øget anvendelse af datastandarder vil sikre at indhold kan viderebehandles DM8 God En central meddelelsesfordeler kan sikre at snitfladerne er enkle, ensartede og baserede på datastandarder. PM5 God Brugergrænsefladen på virk.dk og borger.dk kan bedre understøtte single sign on og dermed bedre selvbetjeningsløsninger. DM9 God Målarkitekturen åbner op for større valgfrihed og bedre brugergrænseflader leveret af myndigheder tæt på deres brugere og leveret af markedet. PM6 Mellem Modellen understøtter at digital post fra myndigheder og virksomheder lagres i et centralt lager. PM7 Mindre god En ny løsning kan være bagud kompatibel i et vist omfang. Større ændringer kan kræve at alle komponenter ændres, hvilket vil give en øget kompleksitet i leverandørstyringen Pt. ingen. Mere kompleks adressering i løsningen vil kræve vedligehold af organisationsstrukturer og opsætning af regler for routing. Jf. PM4 Opdateringer af snitflader kræver ændringer i målarkitekturens komponenter. Skift mellem it-systemer vil stadig kræve en procesmotor som håndteres decentralt af fx et fagsystem. Pt. ingen væsentlige. Det kan ikke garanteres at virksomheder ønsker at anvende dette lager. Modellen forudsætter en transition fra DP2 i løbet af en relativt kort periode. Samlet set vurderes opfyldelsen af gevinster, projektets mål og delmål til at være på godt niveau. 3.4 Arkitekturprincipper Opfyldelsen af arkitekturprincipper i målarkitekturen svarer til Model A, og der henvises derfor til afsnit 2.4. OptimumIT Side 39 af 75

42 3.5 Softwaremæssige kvalitative egenskaber Opfyldelsen af softwaremæssige kvalitative egenskaber i målarkitekturen svarer til Model A, og der henvises derfor til afsnit Ejerskab, drift og forvaltning I Model B skal alle komponenterne - Lager, Meddelelsesfordeler, fællesoffentligt kontaktregister, sikkerhed og brugergrænseflader - tilvejebringes fællesoffentligt, og derefter realiseres ved én samlet idriftsættelse. Erfaringsmæssigt vurderes sådanne idriftsættelser mere risikable end gradvise ændringer. De fællesoffentlige portaler skal enten tilvejebringes helt eller delvist eller faciliteres sammen med Borger.dk og Virk.dk. Digitaliseringsstyrelsen skal facilitere, at der opstår et marked for private udbydere af brugergrænseflader. Dette skal bl.a. ske ved markedsgørelse af funktionalitet samt definition af governance og et certificeringsprogram. Digitaliseringsstyrelsen skal sikre vedligehold, videreudvikling og driftsafvikling af kontaktregisteret, meddelelsesfordeler, lager og eventuelt de fællesoffentlige portalers visning af Digital Post. Til modellen bør Digitaliseringsstyrelsen have en fælles driftsstrategi, som sikrer en samlet stabil driftsafvikling. Her kan man med fordel overveje at samle komponenterne i et driftsmiljø med en ansvarlig driftsleverandør. Det vil forenkle leverandørstyringen og leverancesikkerheden. Digitaliseringsstyrelsen skal være ansvarlig for en forvaltningsopgave for et standardiserings- og certificeringsprogram, så private udbydere kan understøttes. 3.7 Migration og transition Som angivet ovenfor, er målarkitekturen for Model A og Model B ens, men transitionen er væsentligt forskellig. Som illustreret i nedenstående tegning skal følgende overordnede komponenter udskiftes som en del af transitionen. Pilene angiver hvor komponenternes kapabiliteter flyttes hen. De forskellige farver er blot anvendt for bedre at synliggøre, hvor hver komponent ender. Figur 17 Migration for Model B En væsentlig udfordring ved transitionen er, at alle myndigheder og virksomheder skal ændre deres it-løsninger, hvilket påvirker den ønskede kontinuitet for borgere og virksomheder. OptimumIT Side 40 af 75

43 I denne model har det været i fokus hurtigt at kunne idriftsætte næste generation Digital Post. Alle komponenter anskaffes på samme tid og leveres samlet, som illustreret nedenfor. Nedenstående figur illustrerer et transitionsforløb og den efterfølgende drift af den nye infrastruktur. DP2 vil være udfaset i medio Faseangivelsen er baseret på den fællesstatslige projektmodel. Ide- og Analysefaser er således markeret samlet med I, Anskaffelsesfaser er angivet med A, Gennemførelsesfaser med G, pilotdrift med P og Realiseringsfaser med R. Den røde streg markerer en idriftsættelse eller pilotdrift: Modellen understøtter at migrere borgeres og virksomheders eksisterende digitale post meddelelser ind i den nye løsning. Data ligger for indeværende i DP2, hvorfra de skal migreres til det nye lager. Desuden skal kontaktinformation og andet metadata overføres fra den eksisterende løsning til nye de komponenter, eller også manuelt indlæses på ny. Overflytning af data vil imidlertid være en større migreringsopgave end Model A, fordi alle kontaktstrukturer, aftaler og meddelelser skal migreres. De nye komponenter må forventes at have en anderledes datastruktur, hvilket vil øge kompleksiteten af migrationen. Det kan derfor være en fordel med et læsearkiv for DP2 eller en fælles læsearkiv løsning. De anbefalede migreringsstrategier er derfor: Fuld datakonvertering af meddelelser til det fællesoffentlige lager idet der foreligger en specifikation af udtræksformatet, der kan anvendes til indlæsning. Et læsearkiv til den nuværende Digital Post løsning (DP2) uden mulighed for konvertering, men mulighed for manuelt at videresende eksisterende meddelelser. Det vil fjerne datakonverteringsopgaven, men det vil dog være et væsentligt udviklingsprojekt for den eksisterende leverandør. Ved skift til en privat udbyder for portaler skal borgeren eller virksomheden ikke foretage migrering af data, da der er et centralt lager. 3.8 Risikoanalyse Risikoanalysen nedenfor indeholder de identificerede operationelle risici, der vil kunne medføre at projektet NgDP ikke kan realiseres som planlagt. Risikovurderingen indeholder for hver risiko en beskrivelse, kategorisering, og en vurdering af risikoens effekt (sandsynlighed for at risikoen indtræffer, og påvirkningen hvis dette sker). OptimumIT Side 41 af 75

44 Desuden angives et forslag til korrigerende handlinger, samt en vurdering af risikoens effekt efter korrigerende handlinger. En del risici i Model B er de samme som i Model A. De risici, der er forskellige fra Model A, er markeret med blå. Beskrivelse Kategori Sandsynlighed og Påvirkning Korrigerende handlinger Residual risiko Krævede lovmæssige ændringer ved at have flere systemejere m.m. er problematisk Juridisk, Implementering Lav sandsynlighed, Høj påvirkning. Digitaliseringsstyrelsen bliver systemejer for alle komponenter. Mindre impact, men en systemejer kræver aftaler med involverede styrelser. Brugervenlighed og driftsmæssig tilgængelighed er utilstrækkelig i fællesoffentlige distribueret arkitektur Teknisk, Leverandørstyrings opgaven Har en mellem sandsynlighed, med en mellem påvirkning tilsvarende andre offentlige projekter. Digitaliseringsstyrelsen sikrer samarbejde med øvrige myndigheder inden udbud, herunder bør Digitaliseringsstyrelsen overveje at konsolidere driftsafviklingen hos få driftsleverandører. Ved en eller to ansvarshavende leverandører vil driftsmiljøets stabilitet sikres bedre. Krævede lovmæssige ændringer for opbevaring af elektroniske dokumenter for borgere og mindre virksomheder Juridisk, Implementering Høj risiko og høj påvirkning af projektet. Lovgivningen i dag er primært rettet mod at udskifte papirpost med digital post, herunder sikring af frigørende virkning baseret på itsystemet. Dette vil skulle opdateres så andre meddelelsestyper er dækket og målarkitekturen er understøttet lovgivningen. Risikoen er stadig høj, men påvirkningen er håndteret, så den samlede effekt bliver lav. OptimumIT Side 42 af 75

45 Beskrivelse Kategori Sandsynlighed og Påvirkning Korrigerende handlinger Residual risiko Kontakt registeret bliver flaskehals Teknisk, driftssituationen Lav risiko, høj påvirkning. Under tilvejebringelsen fokuseres på afklaring af performance- og skaleringsbehov. Dette vægtes under anskaffelsen og afprøves inden overtagelse. Lav risiko, lav påvirkning. Markedsgørelse lykkes ikke Forretning, Leverancesikkerhed Mellem risiko, men lav påvirkning, fordi alle kritiske komponenter tilvejebringes. Manglende anskaffelse kan modsvares ved markedsdialog og incitamentsstruktur. Lav risiko ved dialog og stadig lav påvirkning. Ændringen af løsningen medfører for store ændringer for interessenter Forretning, Implementering Høj risiko, fordi transitionen sker på en gang og datamigrering er kompleks, Risikoen har høj påvirkning, da myndigheder og interessenter har kort tid til at agere inden kontraktudløb på alle komponenter. Digitaliseringsstyrelsen afsætter ressourcer til at understøtte borgere, virksomheder og myndigheder. Væsentlige interessenter høres om udbudsmateriale og implementeringsplaner. Mellem risiko og høj påvirkning af projektet i en kortere periode. OptimumIT Side 43 af 75

46 Beskrivelse Kategori Sandsynlighed og Påvirkning Korrigerende handlinger Residual risiko Kravene til den nye løsning er ikke komplette og der er mange kritiske afhængigheder Forretning, Leverancesikkerhed Høj sandsynlighed grundet tidligere leverance forløb og høj påvirkning, da alle komponenter udskiftes og kontrakten ikke kan forlænges ud over 1/ Man kan evt. kompensere ved prototype eller proof of concept forløb, hvor komponenternes testes i sammenhæng. Sandsynligheden nedsættes kun marginalt og påvirkningen kan fx håndteres ved at nedsætte scope af løsningen. Samlet set vurderes risikobilledet til at være på mindre godt niveau. Grundet den nuværende situation med kontraktophør er et nulscenarie ikke muligt. Denne løsning har en hurtigere samlet udfasning medio Det giver meget lidt tid til korrigerende handlinger fra programledelsen og styregruppen. Endvidere er der samme væsentlige juridiske afklaringer. En kompleks migration og mange kritiske afhængigheder påvirker business casen negativt. Derudover vil myndigheder og virksomheder have kort tid til at ændre eksisterende integrationer. 3.9 Økonomiske egenskaber De økonomiske egenskaber vurderes kvalitativt på overordnet niveau. Vurderingen anvender skalaen Mindre godt, Mellem og Godt. Vurderingen for Model B er som følger: Anlæg: Mindre godt Model B vurderes til vurderingsniveauet Mindre godt for anlægsomkostninger. Model B vurderes således til at have et relativt højt niveau af anlægsomkostninger, idet der tidligt i forløbet skal tilvejebringes en række fællesoffentlige komponenter, eksempelvis til visning af Digital Post i fællesoffentlige portaler. Komponenten til visning i fællesoffentlige portaler forventes at kunne genbruges til visning i både Borger.dk og Virk.dk. Yderligere skal der gennemføres en migrering af data fra den nuværende løsning i forbindelse med transitionen til og ibrugtagningen af løsningen for Model B. Denne migrering er med til at forøge anlægsomkostningerne. Drift: Mellem Model B vurderes til vurderingsniveauet Mellem for driftsomkostninger. Model B vurderes således til at have et middel niveau af driftsomkostninger, idet den fremtidige løsning for Model B forventes at have væsentligt lavere driftsomkostninger baseret på en kapacitetsbaseret afregningsmodel i sammenligning med den nuværende løsnings forbrugsbaserede afregningsmodel. Det forventes dog at være fordyrende for at OptimumIT Side 44 af 75

47 transitionen skal gennemføres samlet og med én fælles, samtidig ibrugtagning af den nye løsning og at den nye løsning derfor skal have bagudkompatible snitflader. Myndigheder: Mellem Model B vurderes til vurderingsniveauet Mellem for de samlede omkostninger for andre myndigheder. Model B vurderes således til at have et mellem niveau af omkostninger for andre myndigheder, dog vægter det negativt at myndighederne inden for en kort tidsramme skal transitionere integrationer og migrere både data og metadata, herunder kontaktinformation og sikkerhedsinformation, i forbindelse med transitionen til og ibrugtagningen af den nye løsning. Det er dog med til at begrænse de samlede omkostninger for andre myndigheder, at transitionen af integrationerne er relativt simple og at udgiftsmodellen for brug af løsningen, i højere grad end for den nuværende løsning, afspejler de faktiske omkostninger Sammenfatning af Model B Samlet set vurderes Model B at opfylde vurderingsparametrene og rammesætningen på et godt niveau. Projektmål, delmål og gevinster vil i høj grad kunne realiseres. Dog vil især målet om kontinuitet opfyldes i mindre grad. Model B lever som ved Model A i høj grad op til projektets arkitekturprincipper og de kvalitative egenskaber - særligt ift. løst koblede komponenter, interoperabilitet og konkurrenceudsættelse. Model B giver som ved Model A mulighed for en høj grad af offentligt ejerskab over kritiske komponenter, så komponenterne kan genudbydes regelmæssigt. Derudover vil anvendelse af datastandarder give en højere udnyttelse af gevinsterne ved dataopmærkning og intelligent brug af data. Det vil dog give Digitaliseringsstyrelsen en opgave med forvaltning af datastandarderne. Modellen har samlet set et risikobilledet på mindre godt niveau. Særligt mængden af kritiske afhængigheder og mulig påvirkning af interessenter vil trække ned, jf. afsnit 3.8. Samlet set vurderes modellen som det mest risikable valg. På trods af at modellen indeholder en god opfyldelse af mål og gevinster, så har den et mindre godt udgiftsniveau. Det vægter positivt at Digitaliseringsstyrelsens får en standardiseret og driftssikker løsning ved brug af standardbaserede komponenter i den samlede løsning. Det vægter negativt, at der er væsentlige omkostninger i en kort transitionsperiode. 4 Model C Markedsbaseret kommunikationsinfrastruktur Kommunikation mellem myndigheder og kommunikation mellem større virksomheder har en række enslydende behov til en Digital Post løsning til udveksling af sikker og uafviselig post. Tilsvarende har kommunikation mellem myndigheder og borgere/mindre virksomheder andre behov for udveksling af sikker og uafviselig post. Model C erstatter den eksisterende løsning med to delløsninger. Den første delløsning har ansvaret for at vise, opbevare og sende forsendelser for borgere og mindre virksomheder. Den anden delløsning er baseret på NemHandel konceptet og har ansvaret for at sende forsendelser, mens myndigheder og større virksomheder selv har ansvaret for opbevare og vise forsendelser. OptimumIT Side 45 af 75

48 Modellen vil være udvidet til at håndtere bedre interaktion mellem borger og myndighed, virksomhed og myndighed og interaktion mellem 2 eller flere myndigheder ved at anvende datastandarder. Transition og migration for Model C er uddybet i afsnit 4.7. Model C realiserer målarkitekturen i en transitionsfase svarende til Model B. Som illustreret i nedenstående tegning skal følgende overordnede komponenter udskiftes som en del af transitionen. Pilene angiver hvor komponenternes kapabiliteter flyttes hen. De forskellige farver er blot anvendt for bedre at synliggøre, hvor hver komponent ender. Figur 18 Transition for Model C DP2 vil løbe i den nuværende kontrakt inklusive dele af det sidste migrationsår og er dermed fuldt udfaset medio De eksisterende snitflader på DP2 kan derfor anvendes indtil den nye løsning idriftsættes. 4.1 Overblik over modellen Målarkitekturen består af række uafhængige komponenter, som tilsammen giver den fornødne funktionalitet. Målarkitekturen har bl.a. følgende væsentlige egenskaber: Borgeres elektroniske dokumenter ligger i et centralt fællesoffentligt lager. Mindre virksomheders elektroniske dokumenter kan efter eget ønske ligge i en central itløsning. Løsningen til visning, opbevaring og afsendelse af borgeres og mindre virksomheders post sker gennem én samlet delløsning bestående af en række uafhængige komponenter. OptimumIT Side 46 af 75

49 Modellen kan garantere, at alle grupper af borgere og virksomheder får en anvendelig bruger- eller systemgrænseflade til forsendelse af Digital Post. Myndigheders og større virksomheders post formidles gennem private service providers. Digitaliseringsstyrelsen sikrer formidlingen gennem datastandarder, en certificeringsordning, samt et service provider katalog. Private udbydere har i højere grad mulighed for at udbyde private løsninger som services, portaler eller som service providers, som kan vise dokumenter fra private og offentlige eller specialiserede rollebaserede snitflader for fx kuratorer. Administrationsdelen på den nuværende løsning transitioneres til de komponenter, som har ansvaret derfor. Model C har følgende væsentlige karakteristika: Sikrer en ny målarkitektur med to delløsninger bestående af uafhængige komponenter til håndtering af forskellige kommunikationsscenarier. Anvender peer to peer til afsendelse uden fællesoffentlig meddelelsesfordeler og anvender kun lager til borgere og mindre virksomheder, hvor det er relevant. Muliggør at markedet kan agere service providers, samt udvikle portaler og services. OptimumIT Side 47 af 75

50 4.1.1 Målarkitektur for Model C Følgende diagram viser målarkitekturen for model C og illustrerer de væsentligste kapabiliteter (vist med lyseblå) for komponenter (vist med blå). Endvidere er hver komponent grupperet efter deres placering i det fællesoffentlige it-landskab. Administrationsgrænseflader er ikke vist som en væsentlig kapabilitet, men hver komponent har en administrationsgrænseflade. Forretningslogik er medtaget som en kapabilitet for at illustrere, at portalen skal understøtte en række features og forretningslogik, som den eksisterende DP2 løsning i dag understøtter. Borgere / Mindre virksomheder Myndigheder / Større virksomheder Afsendelse Modtagelse Send til Service Provider Send til Lager Modtag fra Service Provider Modtag fra Lager Fællesoffentlige løsninger Private udbydere Borger.dk Virk.dk Løsninger Portal for borgere Forretnings logik Forretnings logik Portal for virksomheder Services Portaler Kommunikationsinfrastruktur Service Providers Lager Service Metadata Publisher Modtag Send Arkiv for borgere Arkiv for virksomheder Katalog for myndigheder Katalog for virksomheder NemSMS Fællesoffentlig infrastruktur Sikkerhed Fællesoffentligt kontakt register NemID NemLogin FBRS Underskrift Tilmelding til offentlige systemer Kontakt information Figur 19 Model C Målarkitektur for Markedsbaseret kommunikation Ovenstående komponenter har en række snitflader. Komponentdiagrammet beskriver de udstillede snitflader i Digital Post. Sammenhængen i målbilledets komponenter er illustreret nedenfor. Sikkerhed er ikke medtaget, da det er en infrastrukturkomponent, som indgår i alle snitflader. OptimumIT Side 48 af 75

51 Borger.dk/ Virk.dk Selvudbyder e Private udbydere Hent post Send Send Opret/Læs Tilmelding Kontaktregis ter Læs Lager Send til lager Modtag Service Provider Modtag Service Metadata Publisher Underskriv Sikkerhed Figur 20 Komponentdiagram for Model C Komponentdiagrammet beskriver de udstillede og anvendte snitflader i Digital Post. Borger.dk og virk.dk henter meddelelser fra lageret, sender meddelelser til myndigheder og større virksomheder via service providers eller direkte til lageret. Borger.dk/Virk.dk anvender det fællesoffentlige kontaktregister til at hente tilmelding til digital post og kan vise kontaktinformation for brugeren. Borger.dk/virk.dk har i diagrammet ikke integration til underskrift funktionaliteten i sikkerhed, men dette ville være muligt. Private udbydere tilbyder portaler og services til borgere og virksomheder. Private udbydere kan læse meddelelser fra lageret og sende via service providers på vegne af en given borger eller virksomhed. Den private udbyder skal selv validere, at modtageren er tilmeldt Digital Post. Sikkerhed udstiller en underskriftsservice, som er en public notarius service, som kan underskrive på vegne af borger/virksomhed. Fællesoffentligt kontaktregister udstiller to snitflader til læsning af kontaktoplysninger samt opret/læs tilmelding. Vedligehold af kontaktregisteret er ikke en del af NgDP og er derfor ikke vist på denne tegning. Lager indeholder arkivet for Digital Post for borgere og virksomheder. Den udstiller to snitflader - en til læsning af meddelelser og en til modtagelse af meddelelser. Advisering/NemSMS er ikke medtaget, og skal realiseres af myndighederne selv. Selvudbyder er de myndigheder og virksomheder som selv varetager visning, opbevaring og afsendelse af meddelelser i Digital Post. Ved afsendelse skal Selvudbyder tjekke om modtageren er tilmeldt digitalt post, meddelelser modtages fra og sendes til Service Providers. Service Provider kan modtage meddelelser og finde modtageren i Service Metadata Publisher og videresende beskeden eller sende beskeden til lageret, hvis modtageren er en borger/mindre virksomhed. Service Metadata Publisher indeholder et katalog over service udbydere og deres endpoints. OptimumIT Side 49 af 75

52 Model C består af følgende komponenter: Betegnelse Beskrivelse Kapabiliteter Brugergrænseflade til Digital Post (Borger.dk, Virk.dk) Sikkerhed Kontaktregister Lager Selvudbyder Brugergrænseflade til borgere og mindre virksomheder til visning af Digital Post. Indeholder aktørers rettigheder til Digital Post, administrationsgrænseflade til håndtering af rettigheder og aftaler, Identity provider eller tilsvarende samt service til underskrift og andre services, jf. afsnit Kontaktregisteret indeholder kontaktoplysninger (mobil nr. og , tilmelding, anvendelse af selvbetjeningsløsninger etc.) på borgere, virksomheder og myndigheder, samt muligheden for organisationshierarki for myndigheder og virksomheder. Organisationshierarkiet kan indeholde organisationens struktur, og relationen mellem opgaver og organisationsenheder. Lager til modtagne meddelelser for borgere og virksomheder. En myndighed eller virksomhed som selv varetager modtagelse, visning, opbevaring og afsendelse af Digital Post. En selvudbyder vil skulle efterkomme en række krav så det sikres, at meddelelser fra meddelelsesfordeleren altid modtages. Brugergrænseflade til alle typer borgere og mindre virksomheder Send Meddelelse Se modtagne meddelelser Administration af personalization af brugergrænsefladen. Roller og rettigheder itsystemer og andre aktørers adgang til indbakker Rettigheder til it-systemer som tilgår services Underskrift/signering. Digitale Persondata som e- mail, telefonnummer etc. Tilmeldingsliste til Digital Post og andre kanaler Organisationsstruktur. Lageret kan modtage meddelelser fra meddelelsesfordeleren og udstille en læse snitflade som kan anvendes på borger.dk/virk.dk eller private udbydere. Modtagelse af meddelelser Send meddelelser Vis meddelelser Opbevaring af meddelelser. OptimumIT Side 50 af 75

53 Betegnelse Beskrivelse Kapabiliteter Service Metadata Publisher Service Providers Indeholder et katalog over service providers for myndigheder og et katalog for virksomheder. Private udbydere kan være Service Providers som kan modtage og videresende post mellem myndigheder og større virksomheder. Figur 21 Tabel over komponenter i Model C Understøttet indhold i modellen Følgende indhold understøttes i modellen: Udstil hvilke myndigheder og større virksomheder som anvender en given service provider. Udstil hvilke service providers som er tilgængelige. Modtag og send meddelelse. Væsentlig meddelelse, ikke-væsentlig meddelelse og notifikationer (understøttes på samme niveau og i samme kvalitet) Faktura (kan vedhæftes en mail der agerer som følgebrev) Indkaldelser (der kan afgives svar på en indkaldelsesmail) Høring (der kan afgives officielle svar men høringsdokumenter skal være indeholdt i den udsendte høringsmeddelelse) Følgende indhold understøttes ikke: Delt dokument (der understøttes kun notifikation om ændringer til dokumentet) Projekthåndtering Advisering ved modtagelse af post for større virksomheder og myndigheder samt advisering af NemSMS for større virksomheder. 4.2 Kommunikationsscenarier mellem modellens komponenter og aktører I dette afsnit beskrives hvordan digital post flyder mellem borgere, virksomheder og myndigheder i modellen. Kommunikationsscenarierne beskrives gennem UML sekvensdiagrammer. Modellen understøtter i fuldt omfang kommunikation mellem borgere, virksomheder og til og fra myndigheder. Modellen understøtter tovejskommunikation i mellem borgere, mindre virksomheder og til og fra myndigheder. Modellen understøtter i mindre omfang tovejskommunikation mellem myndigheder/større virksomheder. Her har myndigheden og virksomhedens it-systemer til afsendelse og modtagelse af Digital Post selv ansvaret for visning og besvarelse. Dermed kan anvendelse af fx dialogintegrationer og lignende besværliggøres. I det følgende beskrives kommunikationsscenariet mellem aktører og modellens komponenter. Autentificering/autorisering er ikke medtaget i diagrammet, da dette indgår i alle snitflader. OptimumIT Side 51 af 75

54 4.2.1 Understøttelse af envejs- og tovejskommunikation Modellen understøtter envejskommunikation i fuldt omfang mellem borgere, virksomheder og myndigheder. Dette inkluderer at borgere, virksomheder og myndigheder kan sende Digital Post til alle øvrige (evt. tilmeldte) modtagere. Modtagernes service provider er registreret i kontaktregisteret. Service providerens endpoint information er registreret i service metadata publisher. Modellen understøtter tovejskommunikation imellem borgere, mindre virksomheder og til og fra myndigheder via besvar funktionen i bruger- og systemgrænsefladen. Dog kræver det at myndighedernes it-system er i stand til lagre og vise ekstra metadata. I det følgende beskrives kommunikationsflowet for envejskommunikation mellem aktørerne ved brug af modellens komponenter Myndighed, Større virksomhed til Myndighed, Større virksomhed Myndighed til myndighed sendes via service providers. Hver modtager er tilknyttet en service provider ved at have indgået en aftale mellem myndigheden og service provideren. Service provideren kan finde information om andre service providers og deres end points i service metadata publisher. Myndighedens service provider findes i kontaktregisteret. Den frigørende virkning sker, når det afsendende it-systemet modtager en kvittering fra det modtagende it-system. Såfremt meddelelsen ikke når frem, træder den frigørende virkning ikke i kraft. OptimumIT Side 52 af 75

55 Afsendelse Service Provider Service Metadata Publisher Kontaktregister Serviceprovider Modtagelse Find modtager Tilføj metadata Send meddelse Gem afsendt besked Meddelelse leveret Meddelelse leveret Meddelelse leveret Figur 22 Flow mellem myndigheder via service providers. Den afsendende myndighed finder modtageren og dennes service provider i kontaktregistret og tilknytter metadata om modtageren. Myndigheden sender til service provideren. Service provideren anvender service metadata publisher til at finde modtagerens service provider end point. Herefter sendes meddelelsen og modtagerens service provider videresender til modtageren Myndighed, Større virksomhed til Borger, Mindre Virksomhed (brugergrænseflade) Ved forsendelse mellem myndighed til borger eller mindre virksomhed sender myndigheden til det centrale lager. Den frigørende virkning sker, når lageret modtager beskeden. OptimumIT Side 53 af 75

56 Afsender Kontaktregister Lager Generér Digital Post Figur 23 Myndighed til Borger & Virksomhed I flowet sendes meddelelsen mellem afsender og lager. Afsendersystemet slår op i kontaktregistret for at validere, at borgeren er tilmeldt Digital Post, eller om virksomheden er en mindre virksomhed, som anvender den fællesoffentlige løsning. Herefter sendes meddelelsen til Lageret, som kvitterer ved modtagelse Borger, Mindre Virksomhed til Myndighed, større virksomhed Borgere og mindre virksomheder anvender den fællesoffentlige løsning udstillet af virk.dk og borger.dk til at sende meddelelser til myndigheder og større virksomheder. Meddelelsen leveres ved, at den fællesoffentlige løsning finder modtagerens service provider og sender til direkte til den. Den fællesoffentlige løsning har derfor selv rollen som afsendende service provider (selvudbyder) i dette tilfælde. OptimumIT Side 54 af 75

57 Borger.dk / virk.dk Service Provider Service Metadata Publisher Kontaktregister Serviceprovider Modtagelse Lager Find modtager Generer digital post Send meddelse Gem meddelelse Meddelelse leveret Meddelelse leveret Meddelelse leveret Gem afsendt post Figur 24 Borger, Mindre virksomhed afsender til Myndighed, Større virksomhed I Flow mellem borger, mindre virksomhed til myndighed og større virksomhed finder portalen modtagerens service provider, hvorefter meddelelsen sendes via service providers. Til sidst persisteres den afsendte besked i lageret med besked om, at meddelelsen er leveret En-til-mange kommunikationsscenarier Modellen understøtter, at én myndighed og/eller en større virksomhed kan sende samme meddelelse til flere modtagere ved at afsende en batch eller tilsvarende til en service provider. Service provideren vil dog være nødt til at sikre, at meddelelser distribueres til rette service provider eller den fælles offentlige løsning for hver modtager. Det er muligt at sikre, at en bestemt modtager kan besvare afsenderen og ikke andre (med)modtagere ved at besvarelsen opmærkes med tilstrækkelig metadata Mange-til-mange kommunikationsscenarier Modellen understøtter ikke, at flere myndigheder står som fælles afsender af Digital Post, idet der kun kan være én afsender på en given meddelelse Tunnelmail Målarkitekturen kan kun erstatte tunnelmail i begrænset omfang. Det vil være muligt for et afsendersystem at finde en modtagers service provider i kontaktregisteret, såfremt det er registreret der. Det vil dog være en større opgave for, at en service provider kan levere direkte til en medarbejder. OptimumIT Side 55 af 75

58 Den funktionelle egnethed ved denne løsning vurderes umiddelbart som lavere, da det vil være mere kompliceret i forhold til, at medarbejderen sender en til modtageren. 4.3 Forretningsmæssige mål Modellen vurderes i høj grad at opfylde forretningsbehovene på et mellem niveau grundet den senere realisering af målarkitekturen. Envejs- og tovejskommunikation er understøttet, så interaktionen nu er bedre håndteret. Virksomheder kan enten vælge en fællesoffentlig portal, eller alternativt en anden (privat) udbyder til adgang til Digital Post. I transitionen vil tovejskommunikation være begrænset. Hvis kontaktregisteret understøtter det, kan fordeleren levere til dybere adressering i myndigheder og virksomheder. Service providers vil endvidere afkoble myndighedens it-systemer, så afsendersystemet ikke nødvendigvis skal kende aftagersystemernes endpoints og teknologi valg. Private udbydere kan tilgå et fælles lager, som giver mindre valgfrihed for leverandører, men sikrer en nem exitmulighed for borgere og virksomheder. Følgende er en vurdering af modellens opfyldelsesgrad af gevinster: Gevinst Vurdering Fordele Ulemper G1: Berigelse af Metadata G2: Bedre understøttelse af visning og udfyldelse af formularer G3: Anvendelse af kommunikationslog G4: Forbedre adressering G5: Kontaktregister Mellem Mellem Mellem God God Datastandarder for metadata kan give mulighed for struktureret berigelse. Datastandarder giver mulighed for bedre afsendelse. Løsninger til at håndtere lokalt lagrede meddelelser kan bedre indgå i det decentrale it-landskab. Kontaktregisteret og Service providers giver mulighed koble modtagere og service providers. Kontaktregisteret anvendes i videst mulige omfang i denne model. Håndtering af metadata vil kræve en decentral håndtering og indgåelse af aftaler med en leverandør for hver myndighed/større virksomhed. Meddelelser til myndigheder og større virksomheder vil ske i egen visningskomponent. Dermed kan integrationen til formularsystemer kompliceres. En kommunikationslog skal tage højde for, at meddelelser kan være til de to delløsninger. Service providers vil skulle udvides til at håndtere mere end adressering til fordøren hos modtageren. Kontaktinformation fra DP2 skal migreres. OptimumIT Side 56 af 75

59 Gevinst Vurdering Fordele Ulemper G6: Segmentering af henvendelsestyper Mellem Der kunne være forskellige service providers, som tilbyder forskellige kanaler og priser. Det vil i så fald være samme pris for afsender og en mindre pris for modtager. Alle meddelelser skal enten håndteres af mindst to Service providers eller det centrale lager. Transaktionsprisen kan derfor blive højere end fx anvendelse af en central meddelelsesfordeler. Følgende er en vurdering af modellens opfyldelsesgrad af projektets mål og delmål: [Se bilag A for mål og delmål] Mål/delmål Vurdering Fordele Ulemper PM1 God Modellen er en kommunikationsinfrastruktur, som kan håndtere sikker, dokumenterbar og uafviselig post. DM1 Mellem Modellen kan indeholde meddelelser med indhold baseret på forskellige datastandarder. DM2 God Kontaktregisteret vil indeholde de nødvendige oplysninger. Sikkerhedsmodellen og service providers vil gøre det enkelt for borgere og virksomheder at administrere hvilke myndigheder og it-systemer, som har adgang til it-systemet. DM3 Mellem Service providers og den centrale løsning kan håndtere en-tilmange kommunikation og en-tilen kommunikation. DM4 Mellem Den fælles brugergrænseflade på borger.dk og virk.dk sikrer borgere og mindre virksomheder en tilgængelig og brugervenlig grænseflade. Markedet kan endvidere bygge grænseflader til specifikke grupper som fx kuratorer og dermed hæve deres brugeroplevelse. Modellen er i mindre grad en erstatning for tunnelmail med direkte adressering fx mellem to medarbejdere. Modellen kan i mindre grad håndtere servicebeskeder for myndigheder og større virksomheder i forhold til den nuværende løsning. Pt. ingen. Mange til mange meddelelser skal håndteres i afsenderens itsystemer. Det kan være komplekst at sikre, at post fra virksomhed til mindre virksomhed/borger anvender det centrale lager. Brugervenlighed i de lokale systemer skal sikres af myndigheden og de større virksomheder. OptimumIT Side 57 af 75

60 Mål/delmål Vurdering Fordele Ulemper PM2 God Modellen anvender i høj grad fællesoffentlig infrastruktur til at sikre attraktiv og fokuseret kommunikationsinfrastruktur. Modulariseringen af målarkitektruren sikrer større frihed til valg af prismodel og finansieringsmodel. DM5 God Målarkitekturen kan konkurrenceudsættes regelmæssigt med veldefinerede snitflader baseret på datastandarder. Service providers konkurrerer på markedsvilkår. PM3 God Mulighed for udvikling af komponenter alene giver bedre mulighed for videreudvikling ved at sænke risikoen og forenkle udskiftning af leverandører. DM6 God Målarkitekturen åbner op for muligheden for konkurrenceudsættelse og fleksible kontrakter, samt markedsgørelse via service provinders. PM4 God Større anvendelse af datastandarder vil muliggøre bedre inputhåndtering. DM7 God Øget anvendelse af datastandarder vil sikre, at indhold kan viderebehandles. DM8 Mellem Datastandarder vil ensarte indholdet. Modellen afhænger af introduktion af nye fællesoffentligt komponenter, men dog færre end i model A. Priserne for myndigheder og større virksomheder afhænger af priserne på service providers. Her vejer det negativt, at en udsendelse til en anden myndighed vil kræve to service providers. Modellen vil primært tilvejebringe løsningens komponenter og i nogen grad facilitere markedets frembringelse af disse. Større ændringer kan kræve, at alle komponenter ændres, hvilket vil give en øget kompleksitet i leverandørstyringen. Pt. ingen. Mere kompleks adressering i løsningen skal håndteres af de lokale løsninger, men de lokale løsninger vil kunne anvendes til andet en Digital Post, fx input fra blanketløsninger og skanning. Jf. PM4. De afsendende systemer skal både kunne sende til lageret og service providers. Umiddelbart vil de have hvert sit integrationsmønster, da håndteringen af frigørende virkning er forskellig, og service providers er leverandører, som Digitaliseringsstyrelsen ikke har et kontraktforhold med. OptimumIT Side 58 af 75

61 Mål/delmål Vurdering Fordele Ulemper PM5 God Brugergrænsefladen på virk.dk og borger.dk kan bedre understøtte single sign on og dermed bedre selvbetjeningsløsninger. DM9 God Målarkitekturen åbner op for større valgfrihed og bedre brugergrænseflader leveret af myndigheder tæt på deres brugere og leveret af markedet. Større virksomheder kan anvende den service provider, som understøtter deres behov bedst. PM6 Mellem Modellen understøtter, at digital post fra myndigheder og virksomheder lagres i et centralt lager for mindre virksomheder og borgere. PM7 Mellem Den fælles idriftsættelse anvender komponenter tilvejebragt af markedet samt mindre komplekse fællesoffentlige komponenter. Modellen er derfor mindre kompleks end Model B. Skift mellem it-systemer vil stadig kræve en procesmotor, som håndteres decentralt fx af et fagsystem. Endvidere vil dynamiske visninger i lokale itsystemer, som opbevarer og viser post, kræve en investering. Pt. ingen væsentlige. Det kan ikke garanteres, at virksomheder ønsker at anvende service providers. Derudover vil større virksomheder have ansvaret for deres eget lager. Modellen forudsætter en idriftsættelse af de to løsninger samtidigt eller parallelt, da integrationer til myndigheder og større virksomheder baserer sig på et andet integrationsmønster. Samlet set vurderes opfyldelsen af gevinster, projektets mål og delmål til at være på et godt niveau. 4.4 Arkitekturprincipper Model C vurderes at opfylde arkitekturprincipperne på højt niveau. Målarkitekturen understøtter mulighed for, at private udbydere kan levere både portaler og service providers. Modellens arkitektur baseres på løst koblede komponenter med veldefinerede snitflader og med anvendelse af datastandarder. Dermed understøtter modellen også interoperabilitet og åbenhed. Følgende diagram giver en oversigt over opfyldelsen af arkitekturprincipperne. Scoren er angivet med tal, hvor 3 er udmærket, 2 er god, og 1 er mindre god. Arkitekturprincip Vurdering Rationale Forretningsbehov 3 Modellen har en høj opfyldelse af forretningsmål jf. afsnit 4.3. OptimumIT Side 59 af 75

62 Arkitekturprincip Vurdering Rationale Informationssikkerhed 3 Modellen understøtter kravene for personfølsomhed, sikkerhed og kryptering på forbindelserne, fx via TLS/SSL. Fællesoffentlig metoderamme 3 Informationsmodellerne anvendes efter principperne i datastandardisering i sektorerne. Der fokuseres på overholdelse af internationale standarder. Projektmodellen forventes at følge den fællesstatslige projektmodel, herunder sikring af det rette niveau af afklaring og risikohåndtering. Borgere og virksomheder 3 Flytningen af udviklingen af brugergrænseflade til borgere og virksomheder til virk.dk og borger.dk vil medføre, at it-understøttelsen af arbejdsgangene bliver mere målrettet deres forretningsbehov. Processer bør optimeres 2 Processer for administration af sikkerhed (fx fuldmagt) og kontakter udskilles, så processerne ligger tæt på de systemer, hvor data vedligeholdes. Endvidere vil større anvendelse, af standardiserede snitflader give bedre muligheder for optimering af processer på tværs. Data og services bør genbruges Styrk konkurrence og innovation 2 Det er en fordel at kontaktregister, sikkerhed og lager kan anvendes af andre it-systemer og services. Det er en ulempe, at meget af det eksisterende konfigurationsdata ikke genbruges i væsentligt omfang. Endvidere anvender modellens to løsninger hvert sit integrationsmønster. 3 Modulariseringen og ejerskabsmodellen i modellen sikrer, at komponenterne kan konkurrenceudsættes. Dermed faciliteres komponenternes markedsgørelse. Forsyningssikkerheden på kernefunktionalitet vejer dog tungere end markedsgørelsen på de centrale komponenter for borgere og mindre virksomheder. Service providers åbner op for et nyt marked af løsninger. Løst koblede komponenter 3 Komponenterne er løst koblede med anvendelsen af datastandarder. Fleksible løsninger 2 Komponenterne er fleksible, men har indbyrdes afhængigheder. Komponenterne Sikkerhed, Service Metadata Publisher og Fællesoffentligt Kontaktregister er således kritiske for de øvrige komponenter. Anskaffelsesmuligheder 3 Mange af de udstillede komponenter findes allerede i dag i forskellige varianter i det fællesoffentlige itlandskab. Der er således god basis for at modellens komponenter kan tilvejebringes under udbud. NemHandel fungerer i dag under mange af de samme principper som de service providers, der lægges op til i modellen. Interoperabilitet 3 Interoperabilitet sikres ved at anvende høj grad af OptimumIT Side 60 af 75

63 Arkitekturprincip Vurdering Rationale datastandarder og en klar versionsstrategi for de snitflader, som udstilles. Sikkerhed 3 Modellens løsninger skal basere sig på kendte sikkerhedsstandarder og metoder, fx SAML 2.0 til adgangsstyring og TLS/MPLS til sikring af forbindelserne mellem komponenterne. Åbenhed 3 Modellen giver større valgfrihed for borgere og virksomheder via understøttelsen af service providers. Skalerbarhed 3 Modellens komponenter vurderes skalerbare både horisontalt og vertikalt. 4.5 Softwaremæssige kvalitative egenskaber Model C vurderes overordnet til at have meget gode softwaremæssige kvalitative egenskaber, da modellen har en god vurdering på alle otte dimensioner. Man skal dog være opmærksom på, at den samlede løsning er karakteriseret ved at have to separate delløsninger med hvert sit integrationsmønster Funktionel Egnethed Funktionel egnethed vurderes ud fra funktionalitet bilag B og kommunikationsscenarier bilag C. Kommunikationsscenarierne er opfyldt for alle scenarier. Dog gælder det for mange-til-mange forsendelser, at det vil resultere i én meddelelse per modtager og afsender i stedet for én fælles meddelelse som modtagere og afsendere deles om. Arkitekturen understøtter mulighed for private udbydere af funktionalitet til borgere og virksomheder, samt services og service providere, hvilket resulterer i den bedst mulige markedsgørelse. Modellens delløsning til borgere og mindre virksomheder leverer en stabil og integreret brugergrænseflade med mulighed for sømløs integration til andre borgervendte og virksomhedsvendte løsninger. Modellens delløsning til større virksomheder og myndigheder anvender veldefinerede, standardbaserede snitflader. Dermed understøtter modellen interoperabilitet og åbenhed Performance Modellens delløsning til borgere og mindre virksomheder der anvender fællesoffentlige portaler, må forventes at kunne levere performance som minimum svarende til den eksisterende løsning. Det forventede omfang på 85 millioner meddelelser årligt svarer til et gennemsnit på 3 meddelelser i sekundet. Selv med en væsentlig stigning i niveauet vurderes det, at belastningen kan håndteres af de enkelte komponenter. Kontaktregisteret er centralt og anvendes ved online opslag via en udstillet snitflade. Det er derfor vigtigt, at performance og skalerbarhed af kontaktregisteret sikres gennem design og udvikling, samt dimensionering af driftsmiljøet. OptimumIT Side 61 af 75

64 4.5.3 Kompabilitet Modellens systemgrænseflader sikre en høj grad af kompatibilitet ved brug af datastandarder for meddelelser, samt en fællesoffentlig sikkerhedsmodel. Kompleksiteten øges af det faktum, at der anvendes forskellige snitflader mellem lager og service providers. Til gengæld skal de it-systemer, der kun sender meddelelser til borgere, integrere til en meget enkel snitflade Usability Brugervenligheden af de fællesoffentlige portaler skal sikres gennem design og udvikling. Alle borgere skal kunne anvende løsningen, hvilket sandsynligvis kræver overholdelse af - som minimum - dele af WCAG 2.0 standarden i brugergrænsefladen. Dette er i tråd med kravene til de eksisterende fællesoffentlige portaler, og det må derfor forventes, at de eksisterende projekter bag borger.dk og virk.dk har erfaring med dette. Brugervenlighed kan endvidere blive et konkurrenceparameter for de private udbydere i modellen, hvilket vil komme borgere og virksomheder til gode Pålidelighed For de fællesoffentlige portalers vedkommende må det forventes, at pålidelighed svarende til det eksisterende niveau for borger.dk og virk.dk vil kunne leveres. Modellens løsninger vil teknisk kunne garantere, at Digital Post kan leveres uafviseligt og sikkert. For at sikre pålidelig leverance af meddelelser og dermed garantere uafviselighed og frigørende virkning, vil det for service providers kræve brug af både tekniske- og forretningsmæssige kvitteringer Sikkerhed De fællesoffentlige portaler integreres med sikkerhedskomponenten for at sikre autentifikation og autorisation af borgere og virksomheder. De fællesoffentlige portaler anvender den fuldmagts- og underskriftsfunktionalitet, der implementeres gennem den fællesoffentlige brugerrettighedsstyrings komponent (FBRS) og NemLog-in, der indgår i sikkerhedskomponenten. Den eksisterende Digital Post løsning håndterer selv aftaler og brugeres rettigheder til postkasser. Denne funktionalitet udskiftes i modellen og håndteres i stedet af sikkerhedskomponenten. Sikkerhedsbehovene forventes at være de samme for modellens løsning til borgere og mindre virksomheder som til Model A. Sikkerhedskomponenten styrer adgangen fra de fællesoffentlige portaler til borgere og mindre virksomheders meddelelser, således at borgere har læseadgang til lageret, men afgrænset til eget personnummer samt eventuelle fuldmagter. Understøttelse af single-sign-on er nødvendig for at sikre sømløs integration til fx selvbetjeningsløsninger. Modellens løsning til større virksomheder og myndigheder anvender sikkerhedskomponenten i forbindelse med brug af komponenternes snitflader. Sikkerhedskomponenten styrer adgangen fra større virksomheders og myndigheders it-systemer til komponenterne. Den konkrete opgavefordeling mellem it-systemerne i Sikkerhedskomponenten er ikke endeligt fastlagt. En simplere realisering er ikke mulig, givet den centrale driver om at undgå silo-baserede løsninger. OptimumIT Side 62 af 75

65 4.5.7 Vedligeholdelse Modellen er ikke defineret til specifikt at maksimere den samlede vedligeholdelsesevne. Det forventes, at modulariseringen samt standardanvendelse øger vedligeholdelsesevnen for hver enkelt komponent. Dermed bør den samlede vedligeholdelsesevne øges. Modellens brug af to delløsninger medfører, at den enkelte delløsning kan fokusere på de kerneopgaver og forretningsbehov med lav grad af afhængighed af hinanden. Vedligehold af service providers vil endvidere være den konkrete leverandørs ansvar Portability Modellen vurderes portabel i forhold til driftsplatforme. Ved transition til anden driftsleverandør vil kontaktregisteret, sikkerhedskomponenten, service metadata publisher og lager skulle porteres. Risikoen forbundet hermed kan reduceres ved at anvende en fælles driftsplatform, så systemerne porteres samlet. Det vil desuden give mulighed for lettere skift til en anden vedligeholdelsesleverandør. 4.6 Ejerskab, drift og forvaltning I modellen skal komponenterne lager, fællesoffentligt kontaktregister, fællesoffentlige sikkerhedskomponenter, service metadata publisher, samt brugergrænsefladerne via borger.dk og virk.dk tilvejebringes fællesoffentligt. Det kan være en fordel at tilvejebringe kontaktregisteret og service metadata publisher sammen, da disse to komponenter har en funktionalitet der minder om hinanden. De fællesoffentlige portaler skal enten tilvejebringes helt eller delvist af NgDP projektet eller anskaffes i regi af projekterne bag borger.dk og virk.dk. Digitaliseringsstyrelsen skal facilitere, at der opstår et marked for private udbydere af service providere samt sekundært brugergrænseflader og service. Dette skal bl.a. ske ved markedsgørelse af funktionalitet samt definition af governance og et certificeringsprogram. Service providere til NemHandel understøttes i dag af det private marked., Grundet det forventede større volumen er det derfor sandsynligt, at markedet i fremtiden vil blive attraktivt. Digitaliseringsstyrelsen skal sikre driftsafvikling af kontaktregisteret, sikkerhedskomponenten, service metadata publisher, lager og eventuelt de fællesoffentlige portalers visning af Digital Post, og skal derfor tilvejebringe infrastruktur- og applikationsdrift samt applikationsvedligehold. Digitaliseringsstyrelsen skal forvente at tilvejebringe applikationsvedligehold af visningen af Digital Post og muligvis også applikationsdriften heraf, til de fællesoffentlige portaler borger.dk og virk.dk. Digitaliseringsstyrelsen bør definere en fælles driftsstrategi for de fællesoffentlige komponenter, der sikrer samlet stabil driftsafvikling. Digitaliseringsstyrelsen skal være ansvarlig for et standardiserings- og certificeringsprogram, så private udbydere kan understøttes. Der skal defineres en governance struktur for etablering og videreudvikling af de nuværende datastandarder, så gevinster ved bedre dialog og øget metadataopmærkning kan realiseres. 4.7 Migration og transition Målarkitekturen for Model C består grundlæggende af to løsninger baseret på en fællesoffentlig infrastruktur. Som illustreret i nedenstående tegning skal følgende overordnede komponenter OptimumIT Side 63 af 75

66 udskiftes som en del af transitionen. Pilene angiver hvor komponenternes kapabiliteter flyttes hen. De forskellige farver er blot anvendt for bedre at synliggøre, hvor hver komponent ender Figur 25 Transition fra den eksisterende Digital Post løsning til Model C. Pilene viser opsplitningen af de eksisterende komponenter til Model C s komponenter. Den nuværende løsning har ansvaret for afsendelse, opbevaring og visning for alle borgere/virksomheder og myndigheder, samt myndighed til myndighed (som virksomhed). Løsningen for borgere og mindre virksomheder har ansvaret for afsendelse, opbevaring og visning af meddelelser mens løsningen for myndigheder og større virksomheder har ansvaret for afsendelse. For at dække de nuværende understøttede kommunikationsscenarier vil der være forskellige muligheder for transition: 1. Realisere løsningen til borgere og mindre virksomheder først, det vil medføre at myndighed til myndighed kommunikation ikke kan lade sig gøre og virksomheder ikke vil kunne afhente eller sende post på andre måder end gennem brugergrænsefladen. Det vil påvirke lokale implementeringer med forøget risiko og omkostninger. 2. Realisere løsningen til borgere og mindre virksomheder først og udvide løsningen til at understøtte myndighed til myndighed kommunikation og at virksomheder kan afhente eller sende post. Det vil øge omkostningerne til midlertidig funktionalitet i den første løsning, og kræve at virksomheder/myndigheder først henter fra løsningen til borgere og mindre virksomheder og derefter fra service providers. 3. Realisere begge løsninger samtidigt, det vil give større risiko i projektets gennemførelsesfase og en big bang udrulning svarende til Model C. Her vil vurderes 1. løsning til ikke at være gangbar, da det vil fjerne funktionalitet fra Digital Post i en periode. 2. løsning vil medføre at scope for løsningen til borgere og mindre virksomheder svarer til Model A/B, dermed vurderes løsning 3 til at være det bedste valg. Anvendelse af løsning 3 vil medføre at meddelelser og konfiguration fra den eksisterende løsning skal migreres, herunder historik, kommunikationslog, kontaktinformation, sikkerhed og andre OptimumIT Side 64 af 75

67 metadata. Større virksomheder og myndigheder kræver ikke migration af meddelelser i projektets gennemførelse, da det i stedet sker når virksomheder vælger at overgå til service providers i stedet for det centrale lager. Løsningen til borgere og mindre virksomheder bør derfor indeholde en eksport funktion. Myndigheder skal hjemtage det midlertidige virksomhedsarkiv som myndigheden i dag har som en del af den eksisterende løsning. I forbindelse med idriftsættelse af model C kan der enten indføres paralleldrift i en kortere periode eller en såkaldt frozen zone. Paralleldrift er det mest realistiske, da frozen zone vil medføre, at den eksisterende Digital Post 2 løsning ikke kan anvendes i en periode. Idriftsættelsen kan forenkles ved at service provideren optræder som aftagersystem i Digital Post 2. Større virksomheder, der overgår til den nye løsning, er selv ansvarlige for opbevaring og visning af meddelelser. Den frigørende virkning i den nye løsning til større virksomheder og myndigheder forventes at kræve en forretningskvittering for det modtagende system. Virksomheders og myndigheders forretningssystemer skal kunne håndtere, at forretningskvitteringer for afsendte meddelelser leveres asynkront. Der skal etableres et arkiv hos virksomheder og myndigheder for afsendte meddelelser. Det vil påvirke business casen negativt, at myndigheder skal understøtte en mere kompleks integration end den eksisterende. Myndigheders lagrede meddelelser i den eksisterende Digital Post løsning skal migreres, da modellens delløsning til myndigheder ikke indeholder et arkiv for myndigheders meddelelser. For større kommuner og regioner må der forventes parallel drift, det det ikke forventes at være muligt for alle it-systemer der anvender Digital Post at overgå til den nye løsning samtidigt. Myndigheder skal gennemføre en transition for at håndtere, at meddelelser sendes direkte til lageret for borgere og mindre virksomheder - eller via en service provider til større virksomheder og andre myndigheder. Hvert system som skal sende til begge løsninger skal således etablere en integration til to forskellige snitflader (en til hver af modellens løsninger) med hvert sit integrationsmønster. Det vil muliggøre at ændringer i snitfladen i den ene af modellens to løsninger ikke at påvirker den anden snitflade, hvilket kan give færre ændringer til anvendersystemet. Tidsplanen for transitionen er beskrevet på nedenstående figur. Faseangivelsen på figuren er baseret på den fællesstatslige projektmodel. Ide- og Analysefaser er således markeret samlet med I, Anskaffelsesfaser er angivet med A, Gennemførelsesfaser med G, pilotdrift med P og Realiseringsfaser med R. Den røde streg markerer idriftsættelse og overgang til drift. De anbefalede migreringsstrategier er derfor: OptimumIT Side 65 af 75