Baggrund

Digitaliseringsstyrelsen har udsendt tidlig udgave af udbudsmaterialet vedrørende Næste Generation Digital Post (NGDP eller DP3).

Markedsdialogmødet 28/8-2017 havde primært til formål at få dialog med potentielle leverandører af NGDP - for at kunne rette til i udbudsmaterialet der hvor dialogen tyder på at der bør ændres noget.

Jeg - Jens - deltog primært for at få fornemmelse af hvordan slut-løsningen ser ud. For at vi i Convergens kan rette vores produktudvikling ind mod det som er vores fremtidige løsninger i forhold til Digital Post.

Husk: Dette er baseret på nuværende information. Alt kan jo ændres frem til udbudsmaterialet er udsendt.

Man forventer at sende udbudsmaterialet ud november 2017.

Man forventer at gå i drift medio 2020.

Figur fra materialets bilag 3 - Kravspecifikation Version 0.8. Turkis = en del af dette udbud.

Vigtige emner med hjem

I forhold til hvad NGDP kan

• En myndighed kan have mange afsendersystemer. Jeg ved ikke om virksomheder kan have mange.
• En Myndighed kan have 4+1 modtagersystemer - 4 til borger.dk, 1 til virk.dk. Virksomheder kan have 1 modtagersystem.
• Myndigheder kommer til at kunne sende til myndigheder uden at det involverer virk.dk.
• En Myndighed kan adresser i forhold til CPR, CVR og MyndighedsID. MyndighedsID er nyt.
• En Person eller en Virksomhed kan adressere i forhold til en MyndighedsID.
• virk.dk-post kan man sætte op til at man ønsker at hente ind i eget system (vi kalder det et afhentningssystem i dag). Gør man det vil Digital Post-løsningen slette Digital Post som er leveret til virksomheden - når det er leveret. Sletningen er ny i forhold til i dag.
• Det at udvikle Visningsklienter (muligheden for at borgere og virksomheder kan læse og sende Digital Post på borger.dk og virk.dk) er ikke en del af dette udbud. Der er et selvstændigt udbudsforløb for dette.
• Fra borgerperspektiv findes i dag elektronisk kommunikation gennem to løsninger: "Digital Post" (til/fra myndigheder) og "E-boks" (til/fra virksomheder). Udbudet handler om "Digital Post", ikke E-boks. Det som borgeren ser i sin Digital Post efter NGDP er i drift er Digital Post, ikke E-boks. Hvis man ønsker at se de to ting i samme grænseflade skal man bruge en Visningsklient som ikke er udviklet af Digitaliseringsstyrelsen.
• Kvitteringsfacilitet (som blev indført i DP2) udgår.
• Der udvikles en overgangsmodel fra DP2 til NGDP. Hvor man kan kalde DP2-snitflader men altså udnytte NGDP-backenden. Det undersøges om det faktisk skal være DP1-snitfladerne, ikke DP2-snitfladerne, der bliver overgangs-snitfladen. Man ser på DP1 fordi man har hørt rygter om at meget få systemer er overgået til DP2-snitfladerne.
• Levering af Digital Post til et afhentningssystem kan ske som
  • Email (S/MIME)
  • REST Push
  • REST Pull (godt - dette var jo sådan set "deprecated" i DP2). Pull både for Virksomheder og for Myndigheder. Pull har ganske få virksomheder kunnet gøre i DP1 (faciliteten blev skjult tidligt i DP1).
• Meddelelsesformatet (svarende til den XML vi kender for Meddelelser i DP1/DP2) gøres transporterbart på Email-format. Hvordan ved jeg ikke, men som jeg forstår det sker det ved at udnytte faciliteter indenfor Internet E-mail standarderne. Det ser ud tiil at der findes der eksempler på Github, hvor man arbejder med formatet (se f.eks. "X-Dk-Digst-Dp3-Recipientid").
• Begrebet Indholdstype/materiale udgår. Man går hen imod en generel model, hvor Meddelelsen selv indeholder det hele; ingen oversættelse fra en IndholdstypeIdentifikator til en tekststreng der vises i Subject på Digital Post Meddelelsen.
• Som en del af Meddelelsen sender man en adviseringstekst som egner sig til at sende ud på SMS.
• Der udvikles et kontaktregister for Personer og Virksomheder. Her vedligeholder man emailadresse, SMS-nummer, Eventuelle andre kontaktpunkter (Facebook-ID, WhatsApp-ID...). På sigt kan denne blive en fællesoffentlig ressource.
• Der udvikles også et myndigheds-kontaktregister. Her findes MyndighedsID. På sigt kan denne blive en fællesoffentlig ressource.
• der findes stadig "masseforsendelse" som betyder at sende mange Meddelelser på en måde, som er mindre belastende for NGDP og måske også for afsender. Sftp-upload af kommasepareret fil, men også i REST-snitfladen.

I forhold til selve NGDP projektet

• Udvikling: NGDP-leverandørens projektorganisation og dele af udviklingsorganisationen skal bo sammen med Digitaliseringsstyrelsen under udviklingen, og i drift-perioden. Alternativt skal Digst-personale flytte ind hos leverandøren.
• Betaling. Bemærkede at leverandøren i sit bud skal forholde sig til (eget) videresalg af løsningen. Der nævnes "udvidet brugsret" i forhold til DIGSTs rettigheder i forhold til koden.
• MitID (erstatningen for NemID) og NemLog-in udvikles i nye udgaver samtidigt med NGDP. Det er disse der skal benyttes.
• Der er tale om et udbud med forhandling. Jeg synes det er en god model - Convergens har haft gode erfaringer med det.
• Der skal være skalerings-faciliteter. Hvis løsningen er hård presset skal det være muligt, hurtigt, at skubbe mere "jern" ind. Det stiller krav.

Undrings-punkter og overvejelser

• Man har et begreb omkring Obligatorisk Digital Post. En mulighed for at sende Digital post til personer der har undtagelse. Der nævnes SU-meddelelser som eksempel. Det undrer mig at man vil lave sådan noget. Man vil tillade at sende Digital Post til nogen som man med sikkerhed ved ikke læser det.
• Det ville være godt at vide noget om hvad man tænker i forhold til Meddelelsers maksimale størrelse. I dag kan en Myndighed sende op til 100MB i en Meddelelse.
• Hvor er understøttelsen af 3. parts leverandører - ud over dokumentation? Jeg tænker på online-fora som digitaliser.dk eller stackoverflow.com. Min gamle kæphest: Det er virkeligt op ad bakke som lille startup at integrere mod DP2; det var oplagt at binde leverandøren til en eller anden form for online-forum-understøttelse, og vedligeholdelse af FAQ.
• Ejerforholdene. Man vil ikke nødvendigvis eje koden. Man taler om "udvidet brugsret". Det ville jeg gerne vide noget mere om hvad det betyder.
• Den arkitektur man beskriver - som går ud på at "motoren" består af ca 4 komponenter med APIer mellem dem - gør at jeg ikke tænker at man kan bruge ren hyldevare. Det er klart, at man kan hente en Database (MySql, MongoDB eller lignenden), og man kan tage et kode-afviklingsprodukt (JBOSS, WebSphere Appplication Server), men sådan mere tæt på færdige produkter (en email-server f.eks.) tvivler jeg på kan placeres ind i denne model. Måske hvis man ser på Open Source email-produkter (Dovecot, Postfix og den slags), hvor jeg ved at ting er mere opdelte, men de kommercielle email-produkter tror jeg ikke kan passe ind, da de er mere monolit-agtige. Tør en leverandør at bygge på Open Source?