Notify NL

De generieke en open source notificatiedienst van de overheid,
voor de overheid

door | 1 november 2022

Leestijd: 61 minuten

Luister naar onze podcast over Notify

Inhoudsopgave

Update 14-02-2023

Naar aanleiding van onze experimenten zoals in dit artikel beschreven hebben we in januari 2023 met een aantal overheidspartijen verkend of we gezamenlijk een overheidsbrede (sms)notificatiedienst kunnen ontwikkelen. Samen met VNG Realisatie, MijnOverheid (Ministerie van Binnenlandse Zaken en Logius), Dimpact en Gemeente Den Haag zullen vervolgstappen geplot worden langs de volgende assen:

  • Pilot Notify NL / Gemeente Den Haag
  • Architectuur
  • Regie / Beheer

Dit betekent tevens dat het experiment waarbij een selecte groep klanten van de SVB een smsje ontving rondom de betaaldagen van de AOW en kinderbijslag in februari 2023 is afgerond. Dit experiment heeft duidelijk laten zien dat burgers het prettig vinden om proactief middels sms over dergelijke zaken geïnformeerd te worden. Aangezien een overheidsbrede (sms)notificatiedienst niet op hele korte termijn ontwikkeld is, wordt er ondertussen ook binnen de SVB bekeken of en hoe sms-notificaties zouden kunnen werken binnen onze bestaande systemen.

Aanleiding

Burgers verwachten van de overheid proactieve dienstverlening op maat. Een interessant onderwerp daarin is proactieve communicatie van de overheid aan burgers. Een manier kan zijn door vanuit de overheid burgers per SMS te informeren in situaties waarin dat kan helpen. In het Verenigd Koninkrijk is daarvoor op basis van open source Notify ontwikkeld. Notify is een platform waarmee organisaties eenvoudig en snel grote getallen Sms-berichten kunnen sturen. In het Verenigd Koninkrijk wordt dat succesvol door ruim duizend overheden gebruikt.

Zou dat in Nederland ook kunnen werken?

Oftewel: Kan een generieke en open source notificatiedienst voor de gehele overheid een oplossing zijn om burgers vanuit overheidsorganisaties op een proactieve, gemakkelijke, uniforme en efficiënte manier te informeren over gebeurtenissen in de dienstverlening? En wat behelst het om voor de overheid een generieke voorziening te ontwikkelen en lanceren?

Wat is Notify?

Notify NL is een platform waarmee organisaties eenvoudig en snel grote getalen Sms-berichten kunnen sturen. Notify kan je zien als een robotje (API) die zit te wachten op commando’s. Een commando kan bijvoorbeeld zijn “stuur bericht “Beste <naam>, uw betaling is aangekomen.” naar deze lijst met telefoonnummers.” Het robotje zet alle berichtjes klaar en stuurt ze door naar een SMS-gateway. De gateway is een afgenomen dienst bij bijv. CM, die de Sms-berichten vervolgens verstuurt.

Notify voorbeeld van gov.uk

Notify voorbeeld van gov.uk

Notify werkt daarbij als een soort gateway: het wacht op instructies over de timing, de inhoud van het bericht en de ontvanger. Doordat Notify NL met vooraf te programmeren templates werkt, is dit allemaal variabel te maken. Notify werkt het beste met directe application programming interface (hierna: API) koppelingen aan systemen van de afzender, maar kan eventueel ook met geïmporteerde Excel-lijsten gebruikt worden.

De belangrijkste functies van Notify NL op een rij:

  • Vooraf gedefinieerde SMS-berichten (templates) snel en veilig versturen aan een groot aantal ontvangers;
  • De templates zijn per ontvanger te personaliseren, waarbij bijv. persoonlijke aanhef, specifieke contexten, data en andere variabelen mogelijk zijn;
  • Eigen systemen zijn te koppelen aan de applicatie, waardoor automatische verzending mogelijk is. Tevens kan handmatig via je browser een lijst met berichten verstuurd worden.
  • Gebruik makend van de standaard SMS-gateway van de Nederlandse overheid.

Op technisch gebied is Notify NL daarmee vrij eenvoudig. De complexiteit ligt hem in de schaalbaarheid. Om te zorgen dat Notify NL door meerdere overheden gebruikt kan worden moet aan alle strenge eisen van security, privacy, efficiëntie, beheersbaarheid en bruikbaarheid worden voldaan.

De technische infrastructuur van Notify NL

Onderstaande afbeelding presenteert een basisoverzicht van de architectuur van Notify. De blauw gearceerde onderdelen zijn inbegrepen in onze eerste release van het product. De grijze onderdelen zijn mogelijkheden die verdere verkenning vereisen.

Architectuur uitleg plaatje Notify en beschrijft visueel wat er in de tekst is opgenomen.

Architectuur uitleg plaatje Notify

Welke problemen zou Notify NL kunnen oplossen?

Dat is de vraag die we ons als innovatie lab als eerst stelden. Onze aanname was dat burgers in Nederland in bepaalde dienstverleningsprocessen geholpen zijn bij Sms’jes van de overheid. En dat een (SMS-)bericht van de overheid onzekerheden bij burgers op een laagdrempelige manier weg kunnen nemen. Uit een interne brainstorm kwamen al gauw diverse processen waarop burgers mogelijk geholpen kunnen zijn met zo’n (SMS-)bericht:

  • Om klanten te informeren over de betaaldag van de AOW of kinderbijslag;
  • Om klanten een gemaakte (telefonische) afspraak te bevestigen (of hen hieraan te herinneren);
  • Wanneer klanten een openstaande actie hebben staan;
  • Om klanten te informeren dat ze Kinderbijslag kunnen aanvragen nadat ze hun kind hebben aangemeld bij de gemeente;
  • Om klanten te informeren dat de jaaropgave beschikbaar is;
  • Om klanten wonend in het buitenland te informeren over openstaande acties.
Proces inzake aanmelding kind bij gemeente. Deze stappen staat in de tekst beschreven.

Proces inzake aanmelding kind bij gemeente

Aannames en uitgevoerde experimenten

We startten dit onderzoek met een aantal leerdoelstellingen en aannames. Op het hoogste niveau hadden deze betrekking op zeven onderwerpen:

  1. We gaan er vanuit dat burgers behoefte hebben aan notificaties van de overheid (desirability, vanuit het oogpunt van een burger).
  2. We gaan er vanuit dat notificaties van de overheid van toegevoegde waarde zijn voor burgers (viability).
  3. We gaan er vanuit dat overheden behoefte hebben aan een generieke notificatiedienst vanuit de overheid (desirability, vanuit het oogpunt van een overheidsorganisatie).
  4. We gaan er vanuit dat notificaties van toegevoegde waarde zijn voor overheidsorganisaties (viability).
  5. We gaan er vanuit dat Notify NL – conform eisen aan privacy, security en beleid m.b.t. open source – te ontwikkelen is (feasibility).
  6. We gaan er vanuit dat Notify NL bij een geschikte (overheids)partij – conform eisen aan privacy, security en beleid m.b.t. open source – in beheer te nemen is.
  7. We gaan er vanuit dat de kosten van het ontwikkelen, beheren en gebruiken van Notify NL opwegen tegen de baten (viability).

Een onderliggende leerdoelstelling van ons als Novum Innovatie lab was dat we met een open en lerende houding willen ontdekken wat het ontwikkelen van een generieke overheidsdienst behelst. Deze lessen willen wij vervolgens toepassen binnen toekomstige projecten vanuit de gedachte van ‘handelen vanuit één overheid’. Op basis van bovenstaande aannames met betrekking tot wenselijkheid, haalbaarheid en levensvatbaarheid te valideren, ondernamen we meerdere experimenten. De uitkomsten van deze experimenten moeten tezamen leiden tot een geïnformeerde keuze om Notify NL te ontwikkelen en lanceren. De verschillende experimenten die tot nu toe zijn uitgevoerd beschrijven wij hieronder.

Onderzoek bij AOW community leden

In een community van AOW’ers (een steekproef van +/- 300 personen) hebben wij onderzoek gedaan naar de mate van interesse in een notificatiedienst vanuit de overheid. In totaal reageerden 134 personen op onze vragenlijst.

Dit waren de belangrijkste uitkomsten:

  • De meeste respondenten hebben ervaring met het ontvangen van Sms-berichten van organisaties. Zij ontvangen onder meer van PostNL, de GGD, de tandarts of de kapper al Sms-berichten.
  • 56% van de respondenten ervaart het ontvangen van deze Sms-berichten als prettig of zeer prettig. Ruim 71% is geholpen bij deze Sms-berichten.
  • In de context van de SVB (en de overheid) geeft 75% procent van de respondenten voor minstens één situatie aan graag een Sms-bericht van de te ontvangen.
  • Respondenten ontvangen het liefst Sms-berichten wanneer een actie openstaat, om herinnerd te worden aan een afspraak of ter bevestiging van een gemaakte afspraak.
  • 68% van de respondenten geeft aan het liefst Sms-berichten met een persoonlijke aanhef te ontvangen.

Een van de respondenten deed in het forum een aanvulling op zijn/haar response, wat in ons optiek aantoont dat het aanbieden van deze dienst een mooie toegevoegde waarde kan zijn voor specifieke doelgroepen:

“Beste SVB, ik vind SMS-herinneringen prettig. Zolang het geen reclame is mag het van mij. Jullie bedienen niet alleen een groep mensen die herinneringen misschien niet nodig hebben, maar ook veel mensen die hun hoofd vol hebben met problemen. In heb in dat werkveld gewerkt en heb gezien dat herinneringen nooit overbodig zijn. Dus doe het.”

Het betaaldagen experiment

De SVB ontvangt bijna dagelijks telefoontjes en andere vormen van contact met burgers over de betaaldagen van de AOW en Kinderbijslag. Burgers hebben dan vaak vragen over of en wanneer zij hun geld van de SVB ontvangen. Onze aanname was dat we deze burgers kunnen helpen met een SMS-berichtendienst die (2 dagen) voorafgaand aan betaaldagen een Sms-bericht stuurt met de exacte betaaldatum.

Dit zijn de belangrijkste resultaten:

  • Ruim 2100 personen hebben zich aangemeld voor Sms-berichten over betaaldagen.
  • De verdeling van AOW en Kinderbijslag klanten is ongeveer gelijk.
  • Er is een interessante piek in het aantal aanmeldingen waar te nemen rondom de betaaldagen van de AOW en Kinderbijslag. Waarschijnlijk bezoeken meer klanten rondom die dagen de website van de SVB en kiest er vervolgens voor om zich aan te melden voor Sms-berichten rondom de betaaldagen.
  • Deelnemers beoordelen de berichtendienst gemiddeld met een 4,7 / 5 (o.b.v. 20 respondenten)
  • Deelnemers beoordelen het nut van de informatie gemiddeld met een 4,8 / 5 (o.b.v. 20 respondenten)
  • Deelnemers zouden de dienst aanraden aan anderen (score 4,7 / 5 (o.b.v. 20 respondenten)

Notify als technische basis voor een overheidsbrede notificatievoorziening in Nederland

Naar aanleiding van de positieve uitkomsten uit het onderzoek met de AOW community en het betaaldagenexperiment zijn we ons gaan verdiepen in de technische haalbaarheid van een generieke notificatievoorziening op basis van Notify. Derhalve hebben we een externe partij gevraagd een startarchitectuur/ontwerp op te stellen voor een overheidsbrede notificatievoorziening die op basis van Notify op het standaard platform van Logius kan worden gerealiseerd. Hierbij is specifiek gevraagd om (a) te kijken naar zoveel mogelijk hergebruik van de open source versie van Notify van Gov UK; (b) te zorgen dat het kan landen op het Logius Standaard Platform; en (c) rekening te houden met de relevante geldende kaders en richtlijnen in Nederland, en aan te geven:

  • Hoe deze voorziening kan worden ingepast in het landschap van overheidsbrede bouwstenen;
  • Met welke standaarden, richtlijnen, wet- en regeling rekening moet worden gehouden;
  • Welke eisen en onderdelen minimaal moeten zijn ingevuld voor de ontwikkeling van een Minimum Viable Product (MVP) van deze notificatievoorziening;
  • Is het Notify open source project een goede basis hiervoor? In hoeverre kan gebruik gemaakt worden van Notify in zijn geheel (of deelcomponenten van Notify)?

De uitkomsten bovenstaande vraagstelling zijn gebundeld in een rapport . Samenvattend zijn de belangrijkste conclusies en aanbevelingen:

  • Voor het realiseren van een MVP gericht op een eerste versie van een overheidsbrede notificatiedienst op het Logius Standaard Platform biedt de huidige versie van Notify zowel functioneel als non-functioneel een goede basis.
  • Notify biedt op dit moment echter nog niet alle functionaliteit die wordt voorzien in een toekomstige overheidsbrede notificatievoorziening. Dit betekent dat Notify in de toekomst, na de MVP, verder uitgebreid zal moeten worden.
  • Nog niet volledig onderzocht is in hoeverre de huidige code van Notify voldoet aan de alle geldende richtlijnen en standaarden. Eventueel moeten in de toekomst in dit kader ook nog aanpassingen aan Notify plaatsvinden.
  • Onderzoek in hoeverre deze toepassing van Notify past binnen de planvorming van Logius en of het aansluit op de functionele- en architectuur(principes) die Logius wil hanteren.

Overheidsorganisaties zien de meerwaarde van een overheidsbrede generieke notificatiedienst

Voordat je aan de ontwikkeling van een overheidsbrede notificatiedienst begint is het uiteraard wel verstandig om te onderzoeken of hier vanuit andere overheidsorganisaties behoefte aan is. Middels onderstaande video en een bijbehorende vragenlijst verkregen we inzicht in mogelijke overheidsgebruikers, hun behoeften én in concrete use-cases voor Notify NL.

Hierbij vind je een samenvatting van de belangrijkste uitkomsten:

  • We hebben 58 vragenlijsten ontvangen, 27 hiervan waren volledig ingevuld, 31 zijn vroegtijdig gestopt
  • Responses kwamen van verschillende overheidsorganisaties waaronder gemeenten, ministeries, en uitvoeringsorganisaties, maar ook van commerciële partijen.
  • 44% van de participanten gaf aan al gebruik te maken van proactieve notificaties, van de 56% die hier nog geen gebruik van maakt geeft 73% aan wel het nut en de potentie van proactieve notificaties te zien.
  • SMS en email werden voornamelijk genoemd als voorkeurskanalen voor het versturen van proactieve notificaties.
  • De grootste behoefte voor het gebruik van notificaties is om burgers eenzijdig te informeren over statuswijzigingen van aanvragen.
Lees het rapport in tekst

Notify NL – architectuurontwerp Notificatiedienst voor de Nederlandse overheid Versie 1.0 

Managementsamenvatting 

Bestuursorganen binnen de overheid, waaronder de SVB, kunnen met behulp van notificaties burgers informeren over (belangrijke) gebeurtenissen in het be- en afhandelingsproces dan wel over de dienstverlening zelf. Notificaties worden zowel ingezet rondom formele berichten (met rechtskracht) vanuit de overheid, als ook bij informele berichten (zonder rechtskracht) aan burgers vanuit de overheid. 

Novum heeft op basis van notificatievoorziening Notify, die momenteel in het Verenigd Koninkrijk is ontwikkeld en als open source beschikbaar is gesteld, een succesvolle pilot uitgevoerd met betrekking tot notificaties rondom betalingsmomenten voor klanten van de SVB. Zowel burgers als andere overheidsinstellingen onderkennen de toevoegde waarde van notificaties. Op basis van de resultaten van deze pilot is het idee ontstaan verder te onderzoeken of Notify als overheidsbrede notificatievoorziening in Nederland kan worden ingezet. Novum wil als eerste vervolgstap een Minimal Viable Product (MVP) ontwikkelen om hier ervaring mee op te doen. Novum wil dit MVP laten landen op het Standaard Platform van Logius. Logius staat hier positief tegenover. Novum heeft CGI gevraagd een architectuur / ontwerp document op te stellen op basis waarvan kan worden vastgesteld hoe dit MVP op basis van Notify er uit kan zien, en met welke relevante kaders en richtlijnen rekening moet worden gehouden wanneer Notify wordt ingezet als overheidsbrede notificatievoorziening in het landschap van de digitale bouwstenen de e-Overheid. 

Het onderzoek wat CGI rondom het opstellen van het architectuur document heeft uitgevoerd laat zien dat: 

De Wet modernisering elektronisch bestuurlijk verkeer (Wmebv), die op 1-1-2023 in werking treedt, notificaties (met name rondom formele berichten) verplicht gaat stellen en ook eisen gaat stellen aan het proces en de inhoud hiervan; 

Binnen de ontwikkelingen ten aanzien van het Federatief Berichtenstelsel (FBS) wordt de realisatie van notificatiefunctionaliteit voorzien als centrale component binnen een breder landschap van modulair opgebouwde generieke en specifieke componenten. Hiernaast bevat dit FBS-landschap ook centrale voorzieningen voor de registratie van kanaalvoorkeuren en de bereikbaarheid van burgers. 

De Wmebv en de ontwikkelingen rondom het FBS hebben tot gevolg dat er een centrale overheidsbrede notificatievoorziening als onderdeel van de bouwstenen van de e-Overheid wordt voorzien. Het ligt hierbij voor de hand dat Logius (op termijn) de beheerder van deze component wordt. Op dit moment is nog niet duidelijk in hoeverre deze functionaliteit zowel in notificatie rondom formele als informele berichten gaat voorzien en wanneer deze functionaliteit beschikbaar komt. Mogelijk kunnen er ook twee overheidsbrede voorzieningen naast elkaar bestaan. 

Rekening houdend met deze ontwikkelingen is onderzocht hoe een overheidsbrede notificatievoorziening kan worden ingepast in het modulaire architectuur landschap van generieke- en specifiek e-overheidsbouwstenen. Hierbij is tevens aangesloten op de bestaande en reeds in het kader van het FBS voorziene services (bouwstenen). Vervolgens is onderzocht welke onderdelen hiervan door Notify kunnen worden ingevuld en vastgesteld of deze, rekening houdend met functionele- en non-functionele eisen en kaders, voldoende geschikt zijn om vanuit een MVP door te groeien naar een overheidsbrede notificatievoorziening. 

Conclusie is dat Notify in een groot deel van de functionaliteit voorziet die nodig is binnen een overheidsbrede notificatievoorziening. In een deel van de functionaliteit wordt echter op dit moment niet voorzien. Het gaat hier vooral om nog te ontwikkelen services in het kader van het FBS en de registratie van de kanaalvoorkeuren en 

de bereikbaarheid. Omdat deze functionaliteit nog niet beschikbaar is is een uitspraak over welke functionaliteit op termijn aan Notify toegevoegd moet worden of op welke functionaliteiten die generiek beschikbaar moet worden aangesloten nog niet mogelijk. 

Hoewel de architectuur van Notify afwijkt van de op microservices gebaseerde architectuur die Logius hanteert, biedt de oplossing zowel functioneel als non-functioneel voldoende basis voor de ontwikkeling van een MVP op het Logius Standaard Platform om daarmee ervaring rondom informele notificaties met behulp van een overheidsbrede notificatiecomponent op te doen. Dit kan op basis van de huidige functionaliteit van Notify. 

 Afhankelijk van de scope van het MVP (wat wil Novum minimaal met het MVP bereiken?) kan het echter noodzakelijk zijn voor het MVP aanvullende functionaliteiten te realiseren. 

Hoewel het MVP op basis van Notify kan landen op het Logius Standaard Platform, en Logius daar ook achter staat, is (nog) niet vastgesteld in hoeverre deze toepassing van Notify past binnen de planvorming van Logius en of het aansluit op de functionele- en architectuur(principes) die Logius wil hanteren. Dit zou nog nader kunnen worden onderzocht in samenwerking met Logius. 

Onafhankelijk van het antwoord op de vraag of Notify uiteindelijk door kan groeien tot de centrale overheidsbrede notificatievoorziening kan het zinvol zijn praktijkervaring op te doen met SMS-notificaties voor informele berichten. Omdat Notify een al grotendeels ingerichte oplossing is kan dit relatief snel worden gerealiseerd. Naast dat hiermee ervaring kan worden opgedaan kan Notify (wellicht tijdelijk) laagdrempelig in een behoefte van burgers en bestuursorganen te voorzien. 

Het advies is om als vervolgstap een implementatieplan op te stellen waarin de scope van het MVP en daaraan gerelateerd de scope van de implementatie en de aanpak inclusief de uit te voeren activiteiten en planning worden uitgewerkt. Op basis hiervan kan vervolgens een indicatie voor het benodigde budget worden vastgesteld. 

Mede op basis van de ontwikkelingen rondom notificaties in relatie tot de Wmebv en het FBS adviseren wij de vervolgstappen in samenwerking met Logius op te pakken. Op deze wijze wordt het draagvlak voor de oplossing vergroot en blijft de uniforme en voor de burger begrijpelijke toepassing van de notificatievoorziening ook op de lange termijn geborgd.

1 Inleiding 

Deze Project Start Architectuur (ontwerp) heeft betrekking op de realisatie van een overheidsbrede notificatievoorziening op basis van Notify. Deze notificatie oplossing is ontwikkeld door de Government Digital Service in het Verenigd Koninkrijk en als open sources beschikbaar gesteld in Github. 

1.1 De achtergrond van notificaties 

De overheid kent meer dan 1.600 organisatie en instanties, zoals gemeenten, provincies en zelfstandige bestuursorganen en ministeries. Deze overheidsorganisaties voeren de taken (veelal dienstverlening) uit die aan hen zijn opgedragen op basis van wet- en regelgeving. Daar waar deze taken/diensten op burgers betrekking hebben, stuurt de overheid berichten en notificaties om deze burgers op de hoogte te stellen van (belangrijke) gebeurtenissen in het be- en afhandelingsproces. 

1.1.1 Bestuurlijk verkeer 

Voor een overheidsbrede notificatievoorziening richten we ons op berichten en notificaties die in kader van bestuurlijk verkeer worden verstuurd door bestuursorganen met een (semi)publieke taak, zoals gemeenten, waterschappen, landelijke uitvoerders, en pensioenfondsen, gericht aan burgers. 

1.1.2 Formele en overige berichten 

We maken onderscheid tussen formele berichten (berichten met rechtsgevolgen) en overige berichten (meer informatief van aard). Notificaties lenen zich niet voor het verzenden van formele berichten; die moeten worden aangeboden via kanalen met dezelfde juridische status als papieren post (zoals bijvoorbeeld de Berichtenbox van MijnOverheid). Daarnaast kunnen bij notificaties de relevante privacy-kaders (zoals op het gebied van toegangsverlening) niet geborgd worden die vereist zijn bij formele berichten. 

Notificaties lenen zich voor berichten aan burgers met een informatief dan wel dienstverlenend karakter of als trigger (aankondiging) voor een formeel bericht dat in een digitale berichtenbox is geplaatst. Voorbeelden van berichten die zich lenen voor verzending aan burgers als notificatie zijn: 

Betaaldatum of uitbetaling van bv. toeslagen, uitkeringen en tegemoetkomingen; Bevestiging of herinnering van een (telefonisch) gemaakte afspraak; 

Herinnering aan een openstaande actie, zoals het aanleveren van ontbrekende stukken; Aankondiging / signaal in het kader van nieuwe formele informatie in een digitaal portaal of berichtenbox; Statuswijziging in een lopende zaak (in behandeling genomen etc.); 

Signaal over het binnenkort verlopen van een rijbewijs of paspoort; 

Signaal over de openstelling van een nieuwe regeling die mogelijk interessant is voor de burger. 

1.2 Verkenning van een notificatievoorziening op basis van Notify 

Door het toepassen van notificaties op basis van SMS-berichten kan de overheid (een grote groep) burgers op een proactieve, laagdrempelige, uniforme en efficiënte wijze informeren over gebeurtenissen die voor hen relevant zijn in de dienstverlening.

De SVB ontvangt regelmatig vragen van burgers die voorkomen hadden kunnen worden op het moment dat ze deze burgers proactief had geïnformeerd via een notificatie. Het proactief verzenden van notificaties sluit aan bij de doelstellingen van de SVB in het kader van proactieve en persoonlijke dienstverlening aan burgers. 

Novum, het innovatielab van de SVB, heeft eind 2021 een verkenning uitgevoerd rondom het verzenden van SMS-notificaties in het kader van de dienstverlening van de SVB (AOW en Kinderbijslag). 

Deze verkenning heeft plaatsgevonden op basis van Notify. Dit is een notificatie-applicatie die geautomatiseerd sms’jes, e-mails en brieven verstuurt. De Notify-oplossing wordt in het Verenigd Koninkrijk gebruikt om met burgers te communiceren. Burgers kunnen de berichten via SMS ontvangen door zich aan te melden voor de dienst en hun mobiele telefoonnummer op te geven. Notify zet te verzenden berichten door aan de SMS gateway. In het Verenigd Koninkrijk is de dienst (Notify.UK) bottom-up tot stand gekomen en van daaruit doorontwikkeld tot een centrale overheidsdienst, waarmee overheden op grote schaal notificaties (brieven, e mails en SMS-berichten) versturen vanuit één centraal beheerd platform. De dienst wordt in het Verenigd Koninkrijk op dit moment gebruikt voor ruim 5865 diensten door meer dan 1300 overheidsorganisaties. Het beheer van Notify.UK is ondergebracht bij “Gov.UK”. Hiernaast wordt de oplossing ook in Canada (GDC) gebruikt. De code-base van Notify is openbaar en herbruikbaar (open source). 

De verkenning met Notify door SVB / Novum is succesvol afgerond en zowel burgers als andere overheidsorganisaties (waaronder UWV, RVO en ACM) hebben laten blijken positief tegenover het toepassen van SMS-notificaties te staan. Hieruit is de verwachting ontstaan dat een generieke notificatiedienst voor de gehele Nederlandse overheid een oplossing biedt om burgers vanuit overheidsorganisaties op een proactieve, gemakkelijke, uniforme en efficiënte manier te informeren over gebeurtenissen in de dienstverlening. 

1.3 Een overheidsbrede notificatievoorziening 

Er bestaat in Nederland nog geen generieke voorziening binnen de overheid voor notificaties. Novum wil samen met SVB ervaring opdoen met het ontwikkelen en lanceren van een overheidsbrede generieke Notificatiedienst. In dit kader wil Novum een ontwerp voor een notificatiedienst opstellen en tevens een Minimum Viable Product (MVP) ontwikkelen op basis van de open source versie van Notify. In deze MVP versie zullen notificaties middels SMS berichten worden verstuurd. 

Logius biedt voor (generieke) overheidsapplicaties het ‘Standaard Platform’ aan. Op dit platform kunnen overheidsorganisaties binnen een private cloudomgeving van de Rijksoverheid zelf applicaties ontwikkelen en aanbieden. Backend en middleware-onderdelen worden op dit platform volledig uit handen genomen (d.w.z. worden verzorgd door Logius). Het standaard platform biedt daarmee een goede landingsplaats voor een eerste implementatie van deze overheidsbrede notificatiedienst op basis van Notify. Logius staat hier positief tegenover. 

1.4 Vraagstelling 

Stel een startarchitectuur/ontwerp voor een overheidsbrede notificatievoorziening die op basis van Notify op het standaard platform van Logius kan worden gerealiseerd. Hoe ziet een overheidsbrede notificatievoorziening in Nederland eruit? Kijk daarbij naar (a) zoveel mogelijk hergebruik van de open source versie van Notify van Gov UK; (b) zorg dat het kan landen op het Logius Standaard Platform; en (c) hou rekening met de relevante geldende kaders en richtlijnen in Nederland. Geef daarbij aan: 

Hoe deze voorziening kan worden ingepast in het landschap van overheidsbrede bouwstenen; Met welke standaarden, richtlijnen, wet- en regeling rekening moet worden gehouden; Welke eisen en onderdelen minimaal moeten zijn ingevuld voor de ontwikkeling van een Minimum Viable Product (MVP) van deze notificatievoorziening;

  • Is het Notify open source project een goede basis hiervoor? In hoeverre kan gebruik gemaakt worden van Notify in zijn geheel (of deelcomponenten van Notify)? 

Out of scope 

  • In dit document wordt geen inschatting gemaakt van de kosten voor het realiseren van een MVP –
  • In dit document wordt geen implementatieplan voor de realisatie / implementatie van een MVP uitgewerkt. 

1.5 Opbouw van het document 

Dit document geeft antwoord op bovengenoemde vraagstelling. In hoofdstuk 2 wordt de algemene functionele architectuur van de oplossing beschreven. In hoofdstuk 3 wordt ingegaan op de applicatie-architectuur. Hoofdstuk 4 beschrijft de infrastructurele inbedding (technische architectuur). Aansluitend wordt in hoofdstuk 5 de scope van een mogelijke eerste implementatie (Minimum Viable Product) van een notificatievoorziening op basis van Notify uitgewerkt. Hoofdstuk 6 gaat in op mogelijke risico’s. 

2 Functionele architectuur 

2.1 Context generieke Notificatievoorziening 

Notificaties kunnen worden gezien als berichten(verkeer) van overheden aan burgers. Op functioneel niveau kan het proces van berichtenverkeer worden opgedeeld in drie aspecten: 

  • Logistiek: het weten, zoeken, vinden, volgen en delen van berichten; 
  • Inzien: het daadwerkelijk inzien van een bericht; 
  • Reageren: het reageren op een bericht. 

Logistiek: Om een bericht aan een burger te kunnen verzenden is het nodig dat kenbaar wordt gemaakt hoe hij bereikbaar is. Voor de burger waaraan het bericht wordt verzonden is het van belang dat deze de burger bereikt en dat de burger moet kunnen vaststellen dat hij een notificatie (‘nieuw bericht!’) heeft ontvangen. Tevens is het van belang dat het bericht herkend wordt als een notificatie van de overheid (en de burger dus kan herkennen dat het geen phishing is). 

Inzien bericht: Vanuit een notificatie of zijn overzicht met berichten moet de burger in staat zijn een bericht in te zien en desgewenst te bewaren binnen de eigen omgeving. Voor het contact tussen gebruiker en bestuursorgaan kan het nodig zijn dat over en weer duidelijk is dat het bericht daadwerkelijk door het bestuursorgaan is verstuurd en daadwerkelijk bij de gebruiker is bezorgd (Wmebv). 

Reageren bericht: Een bericht staat niet op zichzelf; mogelijk wordt van de burger verwacht dat hij iets moet ondernemen of heeft hij een vraag naar aanleiding van het ontvangen bericht. De burger moet kunnen reageren op het bericht of hier opvolging aan kunnen geven, bijvoorbeeld door contact op te nemen met de overheidsorganisatie. 

Implicaties van bovenstaande voor SMS-notificaties zijn als volgt: 

  • Het mobiele nummer van de burger moet bij overheid bekend zijn. 
  • Er moet kunnen worden vastgesteld dat het bericht afgeleverd is. 
  • De burger moet op zijn mobiele telefoon herkennen dat hij nieuw bericht heeft ontvangen
  • De burger moet kunnen herkennen dat het van de (betreffende) overheid is en veilig is.
  • Het moet voor de burger duidelijk zijn hoe opvolging kan worden gegeven a/h bericht

2.2 Capabilities generieke notificatievoorziening 

Uitgaande van bovenstaande 3 hoofdaspecten rondom berichtenverkeer dient een overheidsbrede notificatievoorziening over de volgende capabilities (waaruit vervolgens functionaliteiten kunnen worden afgeleid) te beschikken:

  Onderwerp    
1.  Regie over bereikbaarheid  De burger is in staat zijn ‘bereikbaarheid’ kenbaar te maken aan de bestuursorganen
2.  Regie over wijze interactie  De burger is in staat aan te geven op welke wijze (via welk kanaal) hij met het/de bestuursorganen wil interacteren
3.  Genotificeerd worden  De burger is in staat een notificatie te ontvangen van de bestuursorganen over een voor hem kenbaar gemaakt bericht

 

4.  Overzicht van berichten  De burger is in staat de berichten die hij heeft ontvangen van het/de bestuursorganen te bekijken 
5.  Kennisnemen  De burger in staat kennis te nemen van een kenbaar gemaakt bericht 
6.  Vervolgactie ondernemen  De burger is in staat in actie te komen n.a.v. een ontvangen bericht
7.  Registratie kennisneming en ontvangst tonen Het is voor het bestuursorgaan inzichtelijk dat een bericht daadwerkelijk is ontvangen door de burger**

** Dit inzicht is onderdeel van de zorgplicht van de overheid die onderdeel is van de Wmebv, die naar verwachting in 2023 in werking treedt. 

2.3 Stakeholders 

Een overheidsbrede notificatievoorziening kent verschillende stakeholders. In de volgende figuur zijn deze opgenomen. Daarnaast is in deze figuur op hoofdlijnen aangegeven welke rol en functie deze in het landschap hebben. 

2.4 Functies overheidsbrede notificatievoorziening 

2.4.1 Uitgangspunten 

De uitgangspunten die wij hebben toegepast bij het beschrijven van de functionaliteiten van een overheidsbrede notificatievoorziening zijn als volgt: 

Hoewel, zoals aangegeven in paragraaf 1.3, de MVP-versie van de overheidsbrede notificatievoorziening op SMS-notificaties gericht zal zijn, ligt het voor de hand dat een dergelijke voorziening (in de toekomst) in meerdere kanalen voorziet. Hierbij kan gedacht worden aan de volgende kanalen: 

  • SMS / OTP1 
  • E-Mail
  • Chat (zoals Whatsapp/Telegram) en andere publieke sociale Apps’ 

1 Een SMS OTP (one-time password) is een veilige autorisatiemethode waarbij een numerieke of alfanumerieke code naar een mobiel nummer wordt gestuurd. Dit wachtwoord is een extra beveiligingslaag die wordt gebruikt om de identiteit van een gebruiker te verifiëren

  • Push-notificaties (mobiel en webbrowser) 
  • Post 
  • De notificatievoorziening moet het daarom mogelijk maken nieuwe kanalen toe te voegen en bestaande kanalen uit te faseren. 
  • Notificaties worden verzonden o.b.v. de opgeslagen voorkeuren van de burgers; Notificaties worden verzonden o.b.v. de door de bestuursorganisatie opgegeven prioriteiten; Bestuursorganen kunnen notificaties enkelvoudig of in bulk verzenden; 
  • De notificatievoorziening gaat onderdeel uitmaken van het landschap van overheidsbrede bouwstenen in Nederland. Op basis van het huidige inzicht lijkt een centrale notificatievoorziening die door alle overheidsorganisaties wordt toegepast voor de hand te liggen. Hiervan is in dit document uitgegaan. Het is echter ook denkbaar dat organisaties binnen een federatief stelsel een eigen implementatie (instanties) van deze voorziening hebben. Zo’n federatieve notificatiedienst is niet nader uitgewerkt in dit document; mocht dit alsnog wenselijk zijn (bijvoorbeeld na verdere besprekingen met Logius) dan zou hier aanvullend onderzoek naar kunnen worden gedaan. 

2.4.2 Functionele componenten overheidsbrede notificatievoorziening 

Deze paragraaf beschrijft de benodigde functionaliteiten van een notificatievoorziening die kan worden ingezet als overheidsbrede generieke notificatievoorziening. Dit wil zeggen dat deze voorziening onderdeel uitmaakt van bouwstenen van de e-overheid en meerdere overheidsorganisaties (bestuursorganen) hiervan gebruik kunnen maken om notificaties aan burgers te verzenden. Omdat de notificatievoorziening moet worden ingepast in het (deels nog te realiseren) modulaire architectuurlandschap van generieke en specifieke e overheidsbouwstenen en omdat Logius als waarschijnlijk toekomstig beheerder van dit landschap een microservice architectuur toepast, is ervoor gekozen de functionaliteiten te beschrijven als afzonderlijk te onderscheiden functionele componenten en services. 

Bij de daadwerkelijke invulling van de applicatiearchitectuur – bijvoorbeeld op basis van Notify UK – kan het zo zijn dat deze voorziet in andere functionele componenten dan hier beschreven, maar die wel voorzien in de hier beschreven gewenste functionaliteit. Deze analyse is nader uitgewerkt in hoofdstuk 3. 

Aan de hand van onderstaande figuur worden hierna de componenten en services toegelicht. De figuur is in bijlage in groter formaat opgenomen. 

Notificatie Clients 

Berichtenmagazijnen: Dit betreft het berichtenmagazijn van de centrale Berichtenbox-oplossing en de federatieve berichtenmagazijnen van de aangesloten overheidsorganisaties (bestuursorganen) van het te realiseren federatieve berichtenstelsel (FBS). 

Berichtenlijst Service: De Berichtenlijst Service maakt een lijst van alle berichten die aan burgers en ondernemers zijn verzonden. De ontvanger heeft via de berichtenlijst toegang tot het bericht in het magazijn waar de verzender het heeft geplaatst. De berichtenlijst service zorgt eveneens voor verzending van notificaties via de generieke berichtenlijst service. 

Enkelvoudige notificatie client: Deze service biedt de mogelijkheid om enkelvoudige notificatieverzoeken aan te maken en te verzenden. De service biedt ook een Userinterface waarmee een gebruiker een notificatie handmatig vanuit een browser kan aanmaken en verzenden. 

Bulk notificatie client: Deze service biedt de mogelijkheid een lijst met contactgegevens naar de Notificatie service te zenden om zo in één keer een groot aantal berichten te versturen. Naast de contactgegevens kan ook de toe te passen template worden aangegeven en de planning (datum, tijd waarop je de notificaties wilt 

verzenden) worden meegegeven. De service biedt ook een Userinterface waarmee een gebruiker handmatig een lijst met te verzenden berichten kan opvoeren, opmaken, plannen en verzenden. 

Notificatie Services 

Template Service: De functie beheert de berichttemplates (sjablonen) voor de verschillende notificatieberichten. De templates zijn zowel per deelnemende organisaties (denk aan layout) als per ontvanger te personaliseren, waarbij bijv. persoonlijke aanhef, specifieke context, data en andere variabelen mogelijk zijn. De templates worden gebruikt om hetzelfde bericht naar meerdere mensen (grote groepen en zo vaak als nodig) te zenden. Hiernaast biedt de functie: 

REST API’s voor het creëren, bijwerken, verwijderen en beheren van berichttemplates; Een userinterface voor het controleren en beheren van bericht templates via een webapplicatie. 

API-integratie: API-integratie zorgt ervoor dat de deelnemende overheidsorganisaties kunnen integreren met de notificatieservice. Op deze wijze kunnen eigen systemen gekoppeld worden, waardoor automatische verzending mogelijk is. 

Centrale notificatie component: De centrale notificatie service zorgt voor het verzenden van vooraf gedefinieerde notificatieberichten aan één, enkele of een groot aantal ontvangers. De berichten worden aangeboden aan de notificatie component door de clients: 

  • Bulknotificatie clients: Deze clients versturen bulkmelding(en). 
  • Enkelvoudige notificatie clients: Deze clients versturen enkelvoudige notificatie(s). 

De services (API’s) zullen zich presenteren aan de clients die voor het opstellen van berichten zorgen en daarbij van de Template Service gebruikmaken. Deze berichten worden ook gevalideerd met behulp van de validatie service. 

De volgende services maken onderdeel uit van de Centrale notificatie component: 

  • Validatie Service: Deze service zorgt voor de validatie van notificatieberichten tegen bedrijfsregels en verwacht formaat. 
  • Prioritering Service: Deze service zorgt op basis van de door de deelnemende organisatie opgegeven prioriteit voor het prioriteren van het verzenden van de notificaties basis van hoge, gemiddelde en lage prioriteit.
  • Planning Service: Deze service biedt de mogelijkheid om de verzending van notificaties de plannen. Denk aan verzending van notificaties binnen een minuut of een uur of op een specifieke dag, week, maand of jaar. 

Notificatie Database: De Notificatie Database zal alle notificatieberichten met hun levertijd, status enz. bewaren. Eventueel kan ook de feedback informatie van de service providers omtrent de aflevering van de notificaties in de database worden opgeslagen. Een en ander uiteraard binnen de kaders van de AVG. 

Event Priority Queues (Event Hub): De Event priority Queues verzenden de ontvangen gevalideerde notificaties met hoge, gemiddelde en lage prioriteit door, via de Gebruikers Selectie Service en de Outbound Handler naar de Event Hub. 

Burger selectie en profiel 

Gebruikers Selectie Service: De gebruikers Selectie Service stelt o.b.v. de bij een notificatie meegegeven persoonsgegevens de Digitaal Bereikbaarheidsprofiel Service de persoonlijke voorkeuren van de gebruiker vast en verzend de notificatie vervolgens door naar de Outbound Handler die de Notificatie doorzet naar de Event-hub. 

Digitaal Bereikbaarheidsprofiel Service: Het Bereikbaarheidsprofiel is de functie waar een burger zijn bereikbaarheid en voorkeuren in contact met de overheid kan beheren. Nadat een burger (gebruiker) zich heeft geauthentiseerd biedt de functie de burger de mogelijkheid om per toegestaan kanaal aan te geven hoe hij bereikbaar is. Denk hierbij aan: 

  • Het emailadres waarop hij berichten wil ontvangen; 
  • Het telefoonnummer waarop hij sms-notificaties wil ontvangen; 

Hiernaast biedt de functie ook de mogelijkheid voor het aan- en afmelden van de notificaties voor kennisgevingen en ook de frequentie waarmee kennisgevingen worden ontvangen. Het bereikbaarheidsprofiel kan worden vormgegeven als generieke functionaliteit binnen de overheid, maar eventueel ook beschikbaar worden gesteld aan bestuursorganen binnen hun eigen informatievoorziening. 

Rationale: Vanuit het perspectief van de burger (gemak en herkenbaarheid) is het uiteindelijk gewenst dat er één gemeenschappelijke plek is voor het beheren van de (digitale) bereikbaarheid, de voorkeuren en kanaaladressen. Dat voorkomt dat een burger op veel verschillende plekken en op telkens andere wijze moet doen en daarnaast voorkomt het ook dat dat profiel niet consistent of niet actueel is. 

Implicaties: Gebruik van deze generieke functie is verplicht voor overheidsorganisaties. Stelselafspraken zijn nodig om de gedeelde verantwoordelijkheid voor en het gebruik van deze functie te regelen.

 

Outbound handler Service: Deze service zal notificatieberichten die klaar staan in de Event Priority Queues verwerken door het pollen hiervan op basis van hun prioriteit (van hoog naar laag) 

Event Hub: De Event hub zendt de Notificatie naar de verschillende adapters. Deze adapters zullen gebaseerd zijn op verschillende kanalen. 

Notificatie Adapters: Dit zijn de adapters die de notificaties die de Event hub aanlevert transformeren en volgens het door hun ondersteunde formaat aanbieden aan de externe serviceproviders. Voorbeelden van deze adapters zijn: 

  • SMS-/OTP-adapter 
  • E-mail-adapter 
  • WhatsApp-adapter
  • Telegram-adapter 

Notificatie Service Providers: Dit zijn de externe serviceproviders, die de daadwerkelijke notificatie ‘transmissie’ verzorgen. Veelal zullen dit SaaS-oplossingen zijn. Voorbeelden zijn: 

  • SMS-Gateway (Nb: voor de Nederlandse overheid is de standaard gateway CM.com) E-mail Gateway; 
  • Mobile Push Notification Service; 
  • WhatsApp API-partner 
  • Telegram API-partner 

NB: De service providers zullen ook informatie teruggeven over de (geslaagde) aflevering van de berichten. 

Notificatie Analyse Service: Deze service voert analyses uit en verzorgt rapportages met betrekking tot de verzonden notificaties. Het biedt een dashboard waarin onder andere per deelnemende organisatie het aantal verzonden berichten is te zien. Andere gegevens die mogelijk in het dashboard getoond kunnen worden zijn: Totaal aantal notificaties per dag/per sec. 

  • Wat is het meest gebruikte notificatie kanaal. 

Ook kan de huidige status van elke notificatie gecontroleerd worden om te zien wanneer het is afgeleverd. 

Logging/Tracking Service: Deze service volgt continu alle verzonden notificaties. Het registreert metadata van de notificaties zoals verzendtijd, afleverstatus, communicatiekanaal, type en aflevering etc. Welke data wordt vastgelegd, en hoe deze worden ontsloten, dient nog nader te worden uitgewerkt, waarbij rekening moet worden gehouden met de geldende kaders van de AVG en geldende auditrichtlijnen. 

2.4.3 Niet-functionele requirements 

Naast de functionele componenten en services dient bij de inrichting van een overheidsbrede notificatievoorziening rekening te worden gehouden met diverse niet-functionele eisen. Uiteraard dient een overheidsbrede notificatievoorziening in ieder geval aan de overheidsbrede eisen op het gebied security, informatiebeveiliging en privacy te voldoen. Hiernaast is schaalbaarheid van de voorziening een belangrijk aspect omdat de dienst voorbereid moet zijn op piekbelasting bij een toenemend aantal klanten. 

Hierna worden de belangrijkste niet-functionele requirements op hoofdlijnen toegelicht: 

Schaalbaarheid: De oplossing moet lineair schaalbaar zijn zonder onderbreking van de dienstverlening (toepassing van automatische op- en afschaling op het containerplatform van het Logius Standaard Platform kan hierbij van nut zijn); 

Beschikbaarheid: De oplossing dient 24*7 hoog beschikbaar te zijn; 

Performance: denk hierbij aan eisen als : 

  • XX% van de e-mails en sms-berichten dient binnen YY seconden verzonden te worden; 
  • Het aantal organisaties dat gelijktijdig van de oplossing gebruik moet kunnen maken;
  • Het gemiddeld en maximaal aantal te verzenden notificaties per dag; 

Cloud native: Volledig cloud native moderne systeem te realiseren; 

Logging: De oplossing voert logging uit van de handelingen van alle gebruikers en het systeem, zodat alle handelingen traceerbaar en onweerlegbaar worden vastgelegd;

Aansluiteisen: Nieuwe klanten kunnen eenvoudig aansluiten (er zijn meerdere aansluitopties beschikbaar voor zowel sterk als minder geautomatiseerde klanten; 

Standaarden forum voor standaardisatie: Alle interfaces zijn gebaseerd op open standaarden van het bureau Forum standaardisatie (www.forumstandaardisatie.nl), of daaraan gelijkwaardig; 

Usability: Voor userinterfaces van de oplossing geldt dat deze dienen te voldoen aan de richtlijnen van de overheid voor een gebruiksvriendelijk website. Deze set van richtlijnen zorgen ervoor dat content op websites en in webapplicaties optimaal bruikbaar en toegankelijk moet zijn voor gebruikers (inclusief mensen met en functiebeperking) op uiteenlopende apparaten en besturingssystemen. In 2018 zijn de Webrichtlijnen 2 op de ‘pas-toe-of-leg-uit’-lijst vervangen door ‘Digitale Toegankelijkheid’. 

Integratie: De oplossing moet API-integratie ondersteunen voor alle modules, integratie met overheidsorganisaties en met de Sms-gateway; 

Beveiliging en Privacy: De oplossing dient BIO en AVG compliant te zijn. Zie voor een nadere toelichting paragraaf 2.4.4. 

2.4.4 Beveiliging en Privacy 

Informatieveiligheid en bescherming van persoonsgegevens zijn belangrijke aspecten van informatiemanagement binnen de overheid en dus ook voor een generieke notificatievoorziening. Om aan de wetgeving te kunnen voldoen is binnen de overheid de Baseline Informatiebeveiliging Overheid (BIO) in gebruik. De BIO is een verzameling van kaders en richtlijnen waar alle aspecten met betrekking tot ICT dienstverlening (bedrijfsvoering, processen, personeel en infrastructuur) aan dienen te voldoen. Daarnaast geldt voor alle organisaties de Algemene Verordening Gegevensbescherming (AVG) die regelt hoe moet worden omgegaan met persoonsgegevens. 

Afhankelijk van de informatie die de overheidsbrede notificatievoorziening bevat en verwerkt, moeten bepaalde beveiligingsmaatregelen worden genomen. Om vast te stellen welke maatregelen dit zijn schrijven zowel de BIO als de AVG voor dat een organisatie risicoanalyses uitvoert met betrekking tot informatieveiligheid (de BIA’s) en privacy (de PIA’s). Op basis van deze analyses wordt het zogenaamde basisbeveiligingsniveau vastgesteld. De BBN-classificatie wordt in de BIO gebruikt om te bepalen welke eisen en maatregelen uit de norm op het gebied van beschikbaarheid, integriteit en vertrouwelijkheid van toepassing om een passend beschermingsniveau te realiseren. 

Om de definitieve set van maatregelen te kunnen vaststellen zullen voor de overheidsbrede generieke notificatieservices bovenstaande analyses moeten worden uitgevoerd. Wij gaan er van uit dat BBN2 (departementaal vertrouwelijk) als basisbeveiligingsniveau volstaat. BBN2 biedt voldoende bescherming van de meest voorkomende categorieën informatie. Dit niveau geldt voor informatie waarbij de niveaus voor beschikbaarheid, integriteit en vertrouwelijkheid de waarde Midden hebben. 

2.5 Relevante bouwstenen van de e-overheid 

Er van uitgaande dat een overheidsbrede notificatiedienst onderdeel gaat uitmaken van de set aan bouwstenen van de e-Overheid is het belangrijk deze binnen dit landschap te positioneren. Het ligt daarbij voor de hand de Notificatieservice de positioneren als een van de Contactfuncties van de e-Overheid. In de volgende figuur is de Notificatiecomponent en het Bereikbaarheidsprofiel geplot in het landschap van bouwstenen van de e Overheid. We hebben het Bereikbaarheidsprofiel apart opgenomen, omdat deze service evenals de notificatieservice als generieke service binnen het landschap van e-Overheidsbouwstenen wordt onderkend. Vervolgens worden de relevante e-Overheidsbouwstenen nader toegelicht.

Onderwerp  Beschrijving

DigiD en andere 

toegelaten middelen

DigiD is het digitale authenticatiesysteem voor overheidsorganisaties en publieke dienstverleners. Met DigiD kunnen zij online de identiteit van burgers vaststellen. Op het moment dat een burger met zijn persoonlijke DigiD inlogt krijgt de overheidsorganisatie via DigiD het Burgerservicenummer (BSN) teruggekoppeld. Naast DigiD is ook eIDAS een toegestaan inlogmiddel voor burgers die in een ander EU-land worden dan Nederland. In de toekomst kunnen bij de in werking treding van de WDO mogelijk ook nog andere inlogmiddelen worden toegestaan.
MijnOverheid MijnOverheid is het digitale loket waar burgers hun persoonlijke gegevens bij overheidsorganisaties kunnen inzien, briefpost van overheidsorganisaties digitaal kunnen ontvangen, en de status van lopende zaken en transacties kunnen volgen op een gemakkelijke én veilige manier. Voor overheidsorganisaties is MijnOverheid een extra kanaal om hun doelgroepen efficiënter te bereiken en daarmee hun diensten toegankelijker te maken en transparantie te claimen.

Berichtenbox voor 

burgers

De Berichtenbox (op MijnOverheid) is de digitale postbus voor berichten van de overheid aan burgers. Als er een bericht in de box staat, wordt dit per e-mail gemeld aan de betreffende persoon. Berichten versturen via de Berichtenbox is (nog) niet mogelijk. NB: De huidige Berichtenbox wordt vervangen door het federatieve berichtenstelsel (FBS), zie paragraaf 2.5.1.
BRP (Basisregistratie Personen) De Basisregistratie Personen (BRP) bevat persoonsgegevens over alle ingezetenen van Nederland en over personen die niet in Nederland wonen – of kort verblijven – maar die een relatie hebben met de Nederlandse overheid, de ‘niet-ingezeten’.
Burgerservicenummer (BSN) Het Burgerservicenummer (BSN) is het persoonsnummer voor contacten met de overheid. Dit unieke nummer helpt om bijvoorbeeld persoonsverwisselingen te voorkomen. Iedereen die zich voor het eerst inschrijft bij een gemeente krijgt een BSN. Deze wordt geregistreerd in de BRP.
Digikoppeling Digikoppeling bestaat uit, door het College Standaardisatie vastgestelde, koppelvlakstandaarden. Die standaarden bevatten logistieke afspraken om berichten juist te adresseren, leesbaar en uitwisselbaar te maken en veilig en betrouwbaar te verzenden. Digikoppeling gaat over de ‘envelop’ en voert uit wat daarop staat. De gegevens gaan dan naar de juiste overheidsorganisatie en naar 

 

Onderwerp  Beschrijving
 

het juiste adres. Aangetekend of juist niet, versleuteld, als herhaalde aanbieding, of retour-afzender. De inhoud van het bericht in de envelop is voor de geadresseerde. Digikoppeling onderkent twee hoofdvormen van berichtenverkeer: bevragingen en meldingen. De vorm van het berichtenverkeer bepaalt welke koppelvlakstandaard moet worden geïmplementeerd. Uitgangspunt van Digikoppeling is dat een organisatie op één plaats in de eigen ICT-infrastructuur een koppelpunt volgens Digikoppeling inricht. 

Digikoppeling Standaarden 

Digikoppeling-compliance voorziening 

CPA-Creatievoorziening 

OIN-register

Diginetwerk

Diginetwerk is een afsprakenstelsel van besloten netwerken. Het netwerk is ontstaan uit het koppelen van een aantal van deze besloten netwerken voor de overheid waardoor minder kruisverbanden nodig waren en kosten bespaard konden worden. Door gemeenschappelijk afspraken te maken op het gebied van connectiviteit, beschikbaarheid, beveiliging en het gebruik van standaarden kan iedere aangesloten organisatie communiceren met elke andere aangesloten organisatie. 

Diginetwerk: voorkeurskanaal voor interne overheidscommunicatie 

Diginetwerk betekent door het besloten karakter dat alle deelnemende organisaties bekend zijn. 

Diginetwerk is door het besloten karakter een veiliger alternatief, zonder de risico’s die met het internet samenhangen (bijvoorbeeld DDOS-aanvallen, hacking en malware), voor het uitwisselen van gegevens tussen overheidsorganisaties. 

Diginetwerk maakt mogelijk om via één netwerkaansluiting efficiënt en betrouwbaar te communiceren met alle aangesloten overheidsorganisaties, Het beheer en de beveiliging van de gekoppelde besloten netwerken worden op een gestandaardiseerde wijze verzorgd.

Webrichtlijnen Webrichtlijnen is een set van eisen waar alle overheidswebsites aan moeten voldoen. Zo zorgen we voor kwalitatief goede websites. Want informatie op websites moet toegankelijk zijn voor iedereen, ook voor mensen met functiebeperkingen, gebruikers van mobiele telefoons en voor alle mogelijke browsers. De Webrichtlijnen bevatten richtlijnen die content op websites en in webapplicaties optimaal bruikbaar en toegankelijk maken voor gebruikers op uiteenlopende apparaten en besturingssystemen. De Webrichtlijnen zorgen ervoor dat content op websites en in webapplicaties ook toegankelijk is voor mensen met een functiebeperking. In oktober 2016 zijn de Webrichtlijnen 2 op de ‘pas-toe-of-leg-uit’-lijst vervangen door ‘Digitale Toegankelijkheid’.

2.5.1 Federatief Berichtenstelsel van Logius 

De Berichtenbox is de persoonlijke, beveiligde postbus op Mijnoverheid.nl voor alle elektronische berichten van de overheid aan individuele burgers. De Berichtenbox kan gebruikt worden als formeel alternatief voor fysieke post – inclusief berichten met rechtsgevolgen. Post in de Berichtenbox heeft namelijk dezelfde juridische status als papieren post, dit in tegenstelling tot e-mailberichten. 

Het Federatief Berichten Stelsel (FBS) is de nieuwe berichtenvoorziening van Logius. FBS vervangt de huidige Berichtenbox voorziening. Met FBS staan berichten in een eigen magazijn of in het nieuwe gedeelde centraal berichtenmagazijn (BBO) van Logius. Als er een nieuw bericht is attenderen zij de burger daarover door het bericht aan te melden in het stelsel. Berichten worden opgenomen in de berichtenlijst en de burger krijgt via de notificatie service een melding (op het door hemzelf gekozen communicatiekanaal) dat er bericht voor hem is. Een burger of ondernemer kan zelf aangeven hoe hij door de overheid benaderd wil worden. 

De burger krijgt via FBS direct toegang tot het bericht in het archief van de dienstaanbieder. Als dienstaanbieders hun archief niet kunnen of willen openstellen is er het BBO: Berichtenmagazijn voor Burgers en Ondernemingen). 

Het FBS is opgebouwd uit diverse componenten: 

  • Interactielaag: De manier waarop er met de burger/ondernemer gecommuniceerd wordt. Generieke Services: De kern van FBS wordt gevormd door een aantal generieke services. Deze bieden de benodigde functionaliteiten voor berichtenverkeer. 
  • Berichtenmagazijnen: Deze zijn van de aangesloten organisatie of de centrale BBO.
  • Afsprakenstelsel: Een set aan afspraken hoe we met elkaar samenwerken in dit stelsel. 

Illustratie opbouw FBS, een stippellijn geeft een stelstelcomponent aan, een doorgetrokken lijn is een afspraak en/of ketenafspraak. 

Toelichting Generieke Services in Federatief Berichtenstelsel 

  • De Berichtenlijst Service maakt een lijst van alle berichten die aan burgers en ondernemers zijn verzonden. De ontvanger heeft via de berichtenlijst toegang tot het bericht in het magazijn waar de verzender het heeft geplaatst. 
  • De Notificatie Service zorgt voor de verzending van notificaties per e-mail, sms, app, etc. direct aan burgers en ondernemers. De verzender van de boodschap bepaalt de inhoud en de opmaak van de notificatie. 
  • De Notificatieprofiel Service geeft de mogelijkheid voor burgers en ondernemers om op één plek aan te geven hoe ze genotificeerd willen worden: via e-mail, sms, app, etc., of helemaal niet. Met de Digitale Bereikbaarheid Service kunnen burgers en ondernemers op één plek aangeven akkoord te zijn met het exclusief ontvangen van digitale berichten via FBS. 

Omdat het uitgangspunt is dat de Notificatieservice wordt ingepast in de set van overheidsbrede bouwstenen is bij het ontwerp van de generieke notificatiecomponenten rekening gehouden met de (generieke) services die in het kader van het FBS worden voorzien. 

2.6 Relevante Wet- en regelgeving 

In deze paragraaf wordt de relevante wet- en regelgeving en andere documenten beschreven die een rol spelen bij de realisatie van een overheidsbrede Notificatievoorziening, namelijk: 

  • Wet modernisering elektronisch bestuurlijk verkeer (WMEBV) 
  • Archiefwet 
  • Algemene Verordening Gegevensbescherming (AVG) 
  • Besluit Informatiebeveiliging Overheid (BIO) 
  • Digitale Toegankelijkheid
  • Verplichte standaarden Forum voor standaardisatie 
  • Positon Paper Berichtenverkeer 

In het vervolg van deze paragraaf worden deze en de impact hiervan op de notificatievoorziening toegelicht. 

Wet modernisering elektronisch bestuurlijk verkeer (WMEBV) 

De Wet modernisering elektronisch bestuurlijk verkeer (WMEBV) regelt dat burgers en bedrijven hun zaken die ze met de overheid moeten doen, digitaal kunnen afhandelen. Deze zal naar verwachting in 2022/2023 (gefaseerd) in werking treden. De wet geeft burgers het recht om in formele procedures op elektronische wijze met de overheid te communiceren. 

Bij het gebruik van een berichtenbox is de overheid verplicht om binnen 48 uur een (e-mail)notificatie te sturen aan de ontvanger van dit bericht. Daarin moet tenminste worden aangegeven wat de aard en rechtsgevolgen zijn van het bericht en eventuele termijnen voor de geadresseerde. Nu ontbreekt deze informatie vaak nog in online notificaties waardoor (het verschil in) de urgentie van een bericht niet overgebracht wordt bij de burger. 

Als blijkt dat een notificatie niet kan worden bezorgd, dient die ten minste eenmaal opnieuw te worden verzonden. Wordt de tweede notificatie weer niet bezorgd, dan moet het bestuursorgaan zich inspannen om de burger op een andere (elektronische) wijze te bereiken. 

Andersom geldt dat een bericht als ‘ontvangen’ wordt beschouwd op het moment dat het bericht het systeem van het bestuursorgaan bereikt, of op andere wijze toegankelijk wordt voor het bestuursorgaan. Eventuele storingen mogen de burger overigens niet worden tegengeworpen door het bestuursorgaan bij daardoor ontstane termijnoverschrijdingen. Tenslotte berust de bewijslast rond de ontvangst en verzending van berichten in een berichtenbox bij het bestuursorgaan. De burger heeft daarbij recht op een afschrift van de loggegevens voor zover die aanwezig zijn. Dit versterkt de positie van de burger bij een conflict over de vraag of een bericht wel of niet verstuurd is. 

Bij berichten van de overheid in een berichtenbox: 

  • Verplichte notificatie bij plaatsing van een bericht in een berichtenbox. 
  • Opnemen van essentiële informatie in een notificatie. Veel berichten zijn routinematig (bijvoorbeeld maandelijks over de studiefinanciering). Sommige berichten vereisen dat binnen een bepaalde termijn wordt gereageerd omdat anders sancties volgen. Aan de notificatie is dat nu niet te zien, waardoor berichten vaak ten onrechte ongelezen blijven. Voorgeschreven wordt dat een notificatie informatie over de aard en de rechtsgevolgen van het bericht moet vermelden, als ook de reactietermijn. 
  • Langs andere weg contact opnemen als een notificatie niet kan worden bezorgd. Als een e-mailadres wijzigt (bijvoorbeeld bij overname van een provider) en iemand vergeet dit bij de Berichtenbox te registreren, dan ontvangt hij geen notificaties meer. Als hierdoor berichten worden gemist, kan dit ernstige gevolgen hebben. Uit de wet volgt dat bij het meermaals niet aankomen van een notificatie contact moet worden opgenomen met de geadresseerde (schriftelijk, telefonisch) om een nieuw adres te verkrijgen.
  • Bewijslast rond de ontvangst en de verzending met een berichtenbox berust bij het bestuursorgaan; de burger krijgt recht op afschrift van de loggegevens. Dit versterkt de positie van de burger bij een conflict over de vraag of een bericht wel of niet verstuurd is. 

https://logius.nl/actueel/nieuwe-notificatieteksten-berichtenbox 

Om die communicatie te vergemakkelijken en verder te digitaliseren heeft de regering verschillende wetsvoorstellen gedaan, waarvan sommige al zijn aangenomen. Een aantal daarvan wordt in dit artikel besproken. 

Archiefwet

De Archiefwet is de belangrijkste wet voor de informatievoorziening van de Nederlandse overheid. Deze wet geeft aan dat overheden hun informatie in goede, geordende en toegankelijke staat moeten brengen en bewaren. Informatie moet makkelijk te vinden en te raadplegen zijn. Ook moeten overheden zorgen voor de vernietiging van informatie die daarvoor in aanmerking komt. Voor zover de generieke overheidsbrede notificatieoplossing gegevens bewaart moet de archiefwet worden toegepast. 

Algemene Verordening Gegevensbescherming (AVG) 

Beschrijft de regels voor de omgang met persoonsgegevens. Afhankelijk van de persoonsgegevens die worden verwerkt in de overheidsbrede notificatievoorziening zijn de maatregelen die zijn opgenomen in de AVG van toepassing. Zie verder paragraaf 2.4.4. 

Besluit Informatiebeveiliging Overheid (BIO) 

De Baseline Informatiebeveiliging Overheid (BIO) beschrijft het basisniveau voor informatiebeveiliging. De BIO wordt gehanteerd binnen de Nederlandse overheid, door het Rijk, Gemeenten, Waterschappen en Provincies. Afhankelijk van het vast te stellen Basisbeveiligingsniveau moeten binnen de overheidsbrede notificatie voorziening maatregelen, zoals opgenomen in de BIO, geïmplementeerd worden. Zie verder paragraaf 2.4.4. 

Digitale Toegankelijkheid 

Sinds 1 juli 2018 is het besluit digitale toegankelijkheid overheid van kracht. Het besluit is de opvolger van de webrichtlijnen. De reden voor het woord ‘tijdelijk’ in de naam is dat de grondslag uiteindelijk wordt geleverd door de Wet digitale overheid. In het Besluit is bepaald dat websites en apps van Nederlandse overheidsinstanties moeten voldoen aan de toegankelijkheidseisen. Het biedt een set van richtlijnen die ervoor zorgt dat content op websites en in webapplicaties optimaal bruikbaar en toegankelijk zijn voor gebruikers (inclusief mensen met een functiebeperking). De richtlijnen gelden daarmee ook voor de onderdelen van de generieke overheidsbrede notificatievoorziening die een User Interface bevatten. 

Verplichte standaarden Forum voor standaardisatie 

Forum Standaardisatie is een adviescommissie die wordt ondersteund door het Bureau Forum Standaardisatie (BFS). Dit bureau is gehuisvest bij Logius, de dienst digitale overheid van het ministerie van BZK. Het forum heeft een lijst met open standaarden opgesteld die binnen de overheid een ‘Pas toe of leg uit’-verplichting hebben. Het gebruik van deze open standaarden zorgt voor interoperabiliteit, kostenbesparingen, digitale duurzaamheid, flexibiliteit, innovatie en meer vrijheid bij het kiezen van leveranciers. De generieke overheidsbrede notificatievoorziening moet, waar relevant, de open standaarden zoals opgenomen in deze lijst toepassen. 

Positon Paper Berichtenverkeer 

Dit position paper geeft deels invulling aan de generieke functie ‘correspondentie door en met de overheid’ van het Beleidskader Digitale Infrastructuur. Digitaal berichtenverkeer betreft alle afspraken, standaarden en voorzieningen die een veilige en betrouwbare digitale berichtuitwisseling tussen de overheid en gebruikers mogelijk maken, waaronder notificaties. De position paper bevat het beeld van de gewenste oplossing zoals door de stakeholders (inclusief BZK) aangegeven. 

3 Applicatie Architectuur 

Dit hoofdstuk beschrijft de applicatie-architectuur van Notify NL, welke is gebaseerd op de bestaande Notify UK implementatie. Als eerste wordt onderzocht welke functies door Notify UK worden geleverd, inclusief non functionals; vervolgens wordt de Notify NL applicatie-architectuur beschreven en wordt een mapping gedaan van de Notify UK implementatie op de generieke notificatie-architectuur zoals beschreven in hoofdstuk 2. 

3.1 Functies van de Notify UK voorziening 

Hieronder is een overzicht opgenomen van de functionaliteit die wordt geleverd door Notify UK: 

  • Front-end 
    • versturen van SMS berichten 
    • versturen van e-mails (buiten scope) 
    • versturen van bestand per email (buiten scope) 
    • versturen van brieven (buiten scope) 
    • Uploaden van contactgegevens 
  • REST API 
    • versturen van berichten (SMS, e-mail, brief) 
    • opvragen van bericht status 
    • opvragen van template 
    • opvragen van ontvangen berichten 
  • API client voor meerdere platformen (Java, .NET, Node JS, PHP, Python, Ruby) Real-time dashboard 
    • overzicht status van verstuurde berichten, aantal failures 
    • onderhouden van message templates, upload in csv formaat 
  • 24-uur online support 

Nadere details van de functionaliteit van Notify UK: https://www.notifications.service.gov.uk/documentation 

Hieronder is een overzicht opgenomen van de Non-functional requirements (NFR) van Notify UK: 

  • Performance: 95% van de berichten wordt verzonden binnen 10 seconden 
  • Two-factor authenticatie (2FA) voor inloggen 
  • API autorisatie via JSON Web Tokens 
  • Gegevens worden versleuteld verstuurd en opgeslagen 
  • Gegevens worden opgeschoond na 7 dagen 

3.2 Mapping van Niet-functionele requirements op het Notify platform 

In deze paragraaf worden de Niet-functionele requirements uit de functionele architectuur van hoofdstuk 2 besproken en gekeken in hoeverre het Notify UK platform bijdraagt aan het behalen ervan. 

Schaalbaarheid: De oplossing moet lineair schaalbaar zijn zonder onderbreking van de dienstverlening (toepassing van automatische op- en afschaling op het containerplatform van het Logius Standaard Platform kan hierbij van nut zijn); 

  • Het Notify UK platform bestaat uit containers die eenvoudig op en afgeschaald kunnen worden.
  • Beschikbaarheid: De oplossing dient 24*7 hoog beschikbaar te zijn;
  • De architectuur van het Notify UK platform is ontworpen voor hoge beschikbaarheid. 

Performance: 

  • 95% van de berichten wordt verzonden binnen 10 seconden door het Notify platform. 
  • Cloud native: Volledig cloud native moderne systeem te realiseren; 
  • Notify UK noemt zichzelf niet expliciet Cloud native. Het Notify UK platform is ontworpen om te kunnen draaien op een container platform. 
  • Logging: De oplossing voert logging uit van de handelingen van alle gebruikers en het systeem, zodat alle handelingen traceerbaar en onweerlegbaar worden vastgelegd;. 
  • Het Notify UK platform biedt standaard logging functionaliteit. Of daarmee volledig voldaan wordt aan deze eis is niet verder onderzocht. 

Aansluiteisen: Nieuwe klanten kunnen eenvoudig aansluiten (er zijn meerdere aansluit opties beschikbaar voor zowel sterk als minder geautomatiseerde klanten); 

Het Notify UK platform biedt standaard de mogelijkheid om nieuwe klanten aan te kunnen sluiten. 

Standaarden forum voor standaardisatie: Alle interfaces zijn gebaseerd op open standaarden van het bureau Forum standaardisatie (www.forumstandaardisatie.nl), of daaraan gelijkwaardig; 

Het Notify UK platform is ontwikkeld in de UK en houdt geen rekening met de open standaarden van het bureau Forum standaardisatie. Wel voldoet het aan de Britse standaarden. 

Usability: Voor userinterfaces van de oplossing geldt dat deze dienen te voldoen aan de richtlijnen van de overheid voor een gebruiksvriendelijk website. Deze set van richtlijnen zorgen ervoor dat content op websites en in webapplicaties optimaal bruikbaar en toegankelijk moet zijn voor gebruikers (inclusief mensen met een functiebeperking) op uiteenlopende apparaten en besturingssystemen. In 2018 zijn de Webrichtlijnen 2 op de ‘pas-toe-of-leg-uit’-lijst vervangen door ‘Digitale Toegankelijkheid’. 

  • Het Notify UK platform is ontwikkeld in de UK en houdt geen rekening met de richtlijnen van de ‘Digitale Toegankelijkheid’. Wel voldoet het aan de Britse standaarden. 

Integratie: De oplossing moet API-integratie ondersteunen voor alle modules, integratie met overheidsorganisaties en met de Sms-gateway; 

  • Het Notify UK platform ondersteunt standaard API-integratie. 

Beveiliging en Privacy: De oplossing dient BIO en AVG compliant te zijn. Zie voor een nadere toelichting paragraaf 2.4.4. 

  • Het Notify UK platform is ontwikkeld in de UK en houdt geen rekening met de richtlijnen van BIO en AVG. Wel voldoet het aan de Britse standaarden.

In de hierna volgende paragrafen wordt de Notify NL applicatie-architectuur op basis van Notify UK nader uitgewerkt, en wordt een mapping gedaan van de functionele applicatie-architectuur van hoofdstuk 2 naar de hierboven genoemde componenten van Notify UK. 

3.3 Actoren 

De volgende actoren hebben een rol in de Notify NL dienst: 

  • Deelnemende overheidsorganisaties 
  • Klanten (burgers) 
  • Beheerders 
    • Notify: functioneel beheer 
    • Logius: functioneel beheer (applicatie leverancier) en technisch (platform team) 

3.4 Technische Componenten 

Deze paragraaf beschrijft de toe te passen technische componenten van het Notify UK platform. 

  • notifications-api (REST API voor beheren van templates, versturen van berichten)
  • notifications-admin (Dashboard voor status overzicht) 
  • notifications-utils (diverse generieke componenten) 
  • notifications-<patform>-client (clients om vauit diverse platformen aan te kunnen sluiten op Notify)
  • content-store (De Content Store is een MongoDB database voor de opslag van de gepubliceerde content van GOV.UK.) 

Daarnaast zijn er door Novum twee nieuwe componenten aan het Notify UK platform toegevoegd: 

  • notifications-frontend (web interface voor beheren van templates, versturen van berichten) 
  • novum-notify (niet bekend wat dit component doet) 

Gebruikte technologie per component van het Notify UK platform: 

  • notifications-api, notifications-admin, notifications-utils: 
    • Python 
  • content-store: 
    • Ruby on Rails, Docker 
  • notifications-<patform>-client: 
    • de technologie varieert per client, zoals Go, Java, NET, PHP, Python en Ruby. 

De componenten van het Notify UK platform staan op GitHub: 

https://github.com/topics/govuk-notify 

3.5 Koppelvlakken en informatiestromen 

Om de benodigde informatiestromen te leveren voor het kunnen versturen van notificaties, zoals beschreven in hoofdstuk 2, voorziet de applicatie-architectuur in de volgende koppelvlakken: 

  • Notify Front-end (web interface voor beheren van templates, versturen van berichten via HTTPS)
  • Notify API (REST API voor beheren van templates, versturen van berichten, via REST API)
  • Notify Admin (Dashboard voor status overzicht, via HTTPS) 
  • CM.com (voor SMS koppeling, via REST API) 
  • DigiD, eHerkenning (voor authenticatie, via SAML 2.0) 
  • buiten scope: email-koppeling 
  • buiten scope: briefpost-koppeling 

3.6 CM.com 

  • CM.com zal optreden als de SMS service provider van het Notify platform. 
  • CM.com heeft daarvoor een SMS API die wordt ontsloten door hun SMS Gateway API. Novum heeft hiervoor al afspraken gemaakt met CM.com. 
  • Het Notify platform stuurt de notificaties via de SMS API naar CM.com, dat deze via SMS verstuurt naar de klanten 
  • Deze koppeling is geen onderdeel van Notify UK, daarvoor zal een maatwerk adapter moeten worden ontwikkeld. 

SMS Gateway API | Wereldwijd SMS berichten versturen en ontvangen: 

https://www.cm.com/nl-nl/sms/sms-gateway-api/ 

Advies: nog nader te onderzoeken 

Het is wenselijk, wanneer meerdere overheidspartijen zijn aangesloten op Notify NL, om te achterhalen welke deelnemende partij een notificatie heeft verstuurd. De API van CM.com voorziet hier niet in. Ook de bestaande Notify UK implementatie en het daarin gebruikte onderliggende platform is hierover niet geheel duidelijk; daar wordt gebruik gemaakt van een elders ontwikkelde content store in MongoDB. In de eerste versie (MVP) is hier nog niet in voorzien, maar het verdient aanbeveling om dit nader te onderzoeken c.q. dit eventueel in een latere fase (na de MVP) alsnog toe te voegen. 

 

3.7 Deployment View 

Notify gaat landen op het Logius Standaard Platform (LSP). 

De componenten van Notify worden als containers gedeployed op Kubernetes clusters van het LSP.

De API’s van Notify worden ontsloten via de Logius API Gateway. 

Notify heeft een koppeling met standaard Logius-diensten als DigiD en eHerkenning.

3.8 Federatieve Autorisatie 

Het voorstel van Novum is om initieel zelf de gebruikersgegevens te verzamelen, en later aan te sluiten op de (nog te ontwikkelen) bereikbaarheidsservice en/of de authenticatiemiddelen van Logius. Gebruikers van deelnemende organisaties kunnen in een later stadium inloggen op de Notify front-end met de overheidsbrede inlogmiddelen eHerkenning of eventueel DigiD. Dit zijn ook diensten van Logius. Het gaat hier in beide gevallen om gebruikers die inloggen op de (notifications) clients van het systeem, d.w.z. om berichten te versturen en templates te onderhouden, of om bereikbaarheid (voorkeurskanaal, contactgegevens / telefoonnummer) te registreren. 

DigiD en eHerkenning (en ook eIDAS) zijn authenticatiemiddelen die worden voorgeschreven door de NORA. 

Voor DigiD en eHerkenning is een SAML 2.0 koppeling nodig. Logius ondersteunt momenteel nog geen OAuth / OpenID Connect. Deze koppeling is geen onderdeel van Notify UK, Daarvoor zal een maatwerk adapter moeten worden ontwikkeld, deze kan later worden toegevoegd. 

Federatieve Autorisatie betekent dat organisaties die aan willen sluiten op Notify, onderdeel moeten zijn van de Federatie. Ze moeten de overheidsbrede diensten als DigiD of eHerkenning ondersteunen en overheidsbrede standaarden als DigiKoppeling hanteren. Om dat mogelijk te maken moet dan een andere adapter worden ontwikkeld en toegevoegd. 

N.B. wanneer Notify in de toekomst gebruik zou willen gaan maken van DigID als inlogmiddel, dient Notify eerst te worden onderworpen aan een formele DigiD-audit. 

3.9 Stakeholders en Partijen 

Novum (opdrachtgever) 

SVB (launching customer) 

CGI (ICT dienstverlener) 

CM.com (SMS service provider) 

Logius (Standaard Platform provider) 

buiten scope: email provider 

buiten scope: briefpost provider 

buiten scope: andere providers dan SMS

 

3.10 Kaders en richtlijnen 

De van toepassing zijnde kaders en richtlijnen van de overheid (waaronder BIO, AVG) en die van Logius (zoals DigiKoppeling, Diginetwerk) zijn reeds benoemd in hoofdstuk 2. Aanvullend geldt vanuit SVB de volgende richtlijn: 

Open source componenten zijn alleen toegestaan indien deze worden ondersteund door de leverancier. 

Verder stelt het Logius Standaard Platform eisen aan de leveranciers die applicaties daarop willen laten draaien. Om een applicatie te kunnen ontwikkelen die op het SP moet draaien, zijn de volgende competenties vereist: 

Leverancier heeft kennis van “Cloud Native” applicatieontwikkeling. 

Leverancier heeft ervaring als ontwikkelaar met Kubernetes. 

Leverancier heeft ervaring met het maken van Docker images, waarbij de Docker containers onder de orkestratie van Kubernetes vallen. 

Leverancier heeft kennis van en ervaring met het gebruik van tools uit de “CNCF Landscape”. Leverancier heeft kennis van en ervaring met het ontwikkelen van Open Source Software. Leverancier heeft kennis van en ervaring met Continuous Integration en Continuous Deployment. Leverancier heeft kennis van en ervaring met NORA, de BIO en de AVG. 

Leverancier werkt volgens de principes van Security by Design en Security by Default Leverancier heeft kennis van en ervaring met PKI (Public Key Infrastructure. 

Bron: https://www.logius.nl/diensten/standaard-platform/standaard-platform-documentatie/eisen-voor leveranciers 

Bovenstaande is een lijst van requirements vanuit het Logius Standaard Platform. Voor het kunnen implementeren van het Notify UK platform zijn mogelijk nog een beperkt aantal aanvullende eisen te benoemen, deze zijn in de huidige versie van dit rapport niet verder uitgewerkt. 

3.11 Mapping van de functionele componenten op de Notify componenten 

In deze paragraaf worden de diverse functionele componenten en services van de functionele architectuur uit hoofdstuk 2 besproken, waarbij een mapping is gemaakt op de componenten van het Notify UK-platform waarmee deze kunnen worden geleverd. 

Berichtenmagazijnen 

Dit betreffen het berichtenmagazijn van de centrale berichtenbox-oplossing en de federatieve berichtenmagazijnen van de aangesloten overheidsorganisaties. 

Het Notify UK platform biedt geen Berichtenmagazijnen. Deze functie is ook niet benodigd als onderdeel van de notificatievoorziening, want deze wordt reeds voorzien in het federatieve berichtenstelsel (Logius FBS). 

Berichtenlijst Service 

De Berichtenlijst Service maakt een lijst van alle berichten die aan burgers en ondernemers zijn verzonden. 

Het Notify UK platform biedt geen Berichtenlijst Service. Deze functie is ook niet benodigd als onderdeel van de notificatievoorziening, want deze wordt reeds voorzien in het federatieve berichtenstelsel (Logius FBS). 

Enkelvoudige notificatie client 

Deze service biedt de mogelijkheid om enkelvoudige notificatieverzoeken aan te maken en te verzenden. 

Het Notify UK platform biedt geen Enkelvoudige notificatie client. Deze functie wordt geleverd door de notificatie clients van het Notify UK platform. 

Bulk notificatie client 

Deze service biedt de mogelijkheid een lijst met contactgegevens naar de Notificatie service te zenden om zo in één keer een groot aantal berichten te versturen. 

Het Notify UK platform biedt geen specifieke bulk notificatie client. Deze functie wordt geleverd door de notificatie clients van het Notify UK platform. 

Template Service 

De functie beheert de berichttemplates (sjablonen) voor de verschillende notificatieberichten. Het Notify UK platform biedt geen separate Template Service. Deze functie wordt geleverd door de front-end van het Notify UK platform. 

API-integratie 

API-integratie zorgt ervoor dat de deelnemende overheidsinstellingen kunnen integreren met de notificatie service. 

Deze functie wordt geleverd door de REST API van het Notify UK platform. 

Centrale Notificatie component 

De Centrale notificatie service zorgt voor het verzenden van vooraf gedefinieerde notificatieberichten aan één, enkele of een groot aantal ontvangers. 

Het Notify UK platform biedt geen separate Centrale Notificatie component. Het verzenden van notificaties is de core functionaliteit van het Notify UK platform. Service voor validatie, planning en prioritering zijn daarbij overigens niet aanwezig. 

Notificatie Database 

De Notificatie Database zal alle notificatieberichten met hun levertijd, status enz. bewaren. Deze functie wordt geleverd door de Content Store van het Notify UK platform. De Content Store is een MongoDB database. 

Event Priority Queues (Event Hub) 

De Event priority Ques verzenden de ontvangen gevalideerde notificaties met hoge, gemiddelde en lage prioriteit door, via de Gebruikers Selectie Service en de Outbound Handler naar de Eventhub. Het Notify UK platform biedt geen Event Hub. In de MVP is nog geen Event Hub benodigd / voorzien. 

Gebruikers Selectie Service 

De gebruikers Selectie Service stelt o.b.v. de bij een notificatie meegegeven persoonsgegevens de Digitaal Bereikbaarheidsprofiel Service de persoonlijke voorkeuren van de gebruiker vast en verzendt de notificatie vervolgens door naar de Outbound Handler die de Notificatie doorzet naar de Event-hub. 

Het Notify UK platform biedt geen Gebruikers Selectie Service. In de MVPis nog geen Bereikbaarheidsprofiel benodigd / voorzien. 

Digitaal Bereikbaarheidsprofiel Service 

Het Bereikbaarheidsprofiel is de functie waar een burger zijn bereikbaarheid en voorkeuren in contact met de overheid kan beheren. 

Het Notify UK platform biedt geen Digitaal Bereikbaarheidsprofiel Service. Het Digitaal Bereikbaar heidsprofiel is een generieke service die is voorzien in de architectuur van het federatief berichtenstelsel (FBS) en hoeft derhalve geen onderdeel de zijn van de notificatievoorziening. 

Outbound Handler Service 

Deze service zal notificatieberichten die klaar staan in de Event Priority Ques verwerken door het pollen hiervan op basis van hun prioriteit (van hoog naar laag). 

Het Notify UK platform biedt geen Outbound Handler Service. In de MVP is nog geen Outbound Handler benodigd / voorzien.

Event Hub 

De Event hub zendt de Notificatie naar de verschillende adapters. Deze adapters zullen gebaseerd zijn op verschillende kanalen. 

Het Notify UK platform biedt geen Event Hub. In de MVPis nog geen Event Hub benodigd / voorzien. 

Notificatie Adapters 

Dit zijn de adapters die de notificaties die de Event hub aanlevert transformeren, en volgens het door hun ondersteunde formaat aanbieden aan de externe serviceproviders. 

In de MVP wordt voorzien in één Notificatie Adapter, voor de SMS-Gateway (via CM.com). Deze is nog niet voorzien in het Notify UK platform en dient als maatwerk te worden ontwikkeld. 

Notification Service Providers 

Dit zijn de externe serviceproviders, die de daadwerkelijke notificatie ‘transmissie’ verzorgen. In de MVPis er één Service Provider, CM.com voor de SMS-Gateway. 

Notificatie Analyse Service 

Deze service voert analyses uit en verzorgt rapportages met betrekking tot de verzonden notificaties. Het Notify UK platform biedt geen separate Notificatie Analyse Service. Deze functie wordt geleverd door het Dashboard van Notify Admin. 

Logging/Tracking Service 

Deze service leest continu de priority Event Prioriteit Ques en volgt alle verzonden notificaties. Het Notify UK platform biedt geen Logging/Tracking Service. In de MVP is nog geen Logging/Tracking Service benodigd / voorzien. 

Autorisatie Component 

Deze component zorgt voor autorisatie van gebruikers. 

Het Notify UK platform biedt geen separate Autorisatie Component. Deze functie wordt standaard geleverd door het Notify UK platform. 

Twee-factor authenticatie 

Hoewel dit niet expliciet is benoemd in de functionele architectuur van hoofdstuk 2, wordt bij Notify gebruik gemaakt van twee-factor authenticatie (2FA) om accounts veilig te houden. Deze functie wordt standaard geleverd door het Notify UK platform. 

Conclusie 

Notify UK voorziet in het overgrote deel van de functionaliteiten zoals beschreven in de functionele architectuur (hoofdstuk 2). Hoewel de functionaliteiten niet beschikbaar zijn als afzonderlijke services biedt Notify UK voldoende basis om te worden ingezet als MVP; dit wordt nader uitgewerkt in hoofdstuk 5. Op het moment dat ervoor wordt gekozen om de MVP door te laten groeien naar een bredere notificatiedienst, kunnen de aanvullende functionaliteiten die nu nog niet in Notify UK aanwezig zijn, als maatwerk aan het platform worden toegevoegd. 

Notify UK is ontwikkeld conform de richtlijnen van de Britse overheid; om vast te stellen of Notify ook voldoet aan de standaarden en richtlijnen van de Nederlandse overheid moeten de overeenkomsten en verschillen tussen de Nederlandse en Britse richtlijnen eerst in kaart worden gebracht. Dit betreft naar verwachting geen omvangrijke zaken (zie ook hoofdstuk 3.2). Op basis van die analyse kan Notify dan verder worden aangepast om te voldoen aan de standaarden en richtlijnen van de Nederlandse overheid. Ook hiervoor zullen dan maatwerk-aanpassingen nodig zijn. 

Op vergelijkbare wijze kan Notify worden aangepast / uitgebreid om het in te passen binnen het landschap van de Nederlandse overheidsbrede bouwstenen. Denk daarbij bijvoorbeeld aan de koppeling met DigiD / eHerkenning en toekomstige uitbreidingen zoals bijvoorbeeld Logius FBS.

4 Technische Architectuur 

De technische architectuur beschrijft de werking van het technisch platform en hoe deze voor Notify wordt uitgewerkt. 

4.1 Gemaakte keuzes m.b.t. het platform 

Tijdens de eerste fase van Notify (PoC/experiment-versie zoals door Novum in 2021 gerealiseerd) is ervoor gekozen om een intern technisch platform te kiezen: een Novum/SVB server met open source producten. Voor de vervolgfase van Notify, de MVP-versie, moet een stevig fundament worden gebruikt. Dit houdt in dat het technisch platform betrouwbaar, veilig, beschikbaar en beheersbaar moet zijn. 

Keuze 1: Logius Standaard Platform 

Voor de Notify MVP-versie is de keuze gemaakt om gebruik te maken van het Logius Standaard Platform (LSP). Het LSP is een private cloudomgeving, opgezet door Logius (onderdeel van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties). Het doel van het LSP is om de overheid en al haar onderdelen een cloudomgeving aan te bieden als Platform as a Service. Het LSP heeft in grote lijnen dezelfde werking als een Cloud Service Provider. Dit houdt in dat het platform wordt beheerd, veilig is, en volgens gemaakte afspraken beschikbaar is. 

Keuze 2: Container-infrastructuur 

Om op het LSP te kunnen landen moet Notify als applicatie worden opgezet middels containers. Een container landschap bestaat uit kleine, geïsoleerde applicatieomgevingen die eenvoudig zijn te deployen en te beheren. In onderstaande afbeelding is het principe afgebeeld. In het kort houdt het in dat Notify bestaat uit verschillende applicaties die samen 1 complete service uitvoeren. De verschillende applicaties maken gebruik van één container platform, één operating system en één infrastructuur. Oudere / meer traditionele applicaties omvatten vaak meerdere VM’s en OS-en, wat voor inefficiëntie kan zorgen als het gaat om overzichtelijkheid, schaalbaarheid en performance. 

Keuze 3: Cloud-native applicatie en infrastructuur 

Een andere voorwaarde om gebruik te mogen maken van LPS is om Notify volgens Cloud Native principes op te zetten. Naast dat het een voorwaarde vanuit Logius is, is het ook een keuze die moet worden gemaakt los 

 

 

van het technisch platform. Door Notify als Cloud Native applicatie te bouwen kan het in principe op elk ander technisch cloud platform landen. 

In bovenstaande afbeelding staan de componenten van Cloud Native. De technische infrastructuur voorziet in de tooling voor alle 4 de onderdelen. De onderdelen Microservices en Containers zijn duidelijker zichtbaar, waar CI/CD en DevOps meer de methode van beheer zijn. 

Het LSP biedt GitLab, Harbor en Nexus aan om CI/CD uit te kunnen voeren en om een DevOps manier van werken aan te houden. 

Keuze 4: Microservice-architectuur 

Deze keuze (microservice-architectuur) is nauw verweven met Keuze 2 (Containers). De applicatielaag van Notify gaat bestaan uit microservices. Hoog-over houdt dit in dat één service (bijvoorbeeld de bijlage-service), als één applicatie wordt geprogrammeerd. 

Bij een traditioneel ontworpen applicatie worden veelal alle services als één applicatie ontwikkeld. Indien er een service tussenuit wordt gehaald, werkt de hele applicatie niet meer. Bij een Microservice-architectuur is dit niet het geval: de applicatie zal blijven werken, ook als er een microservice uit is gehaald. Om weerbare microservices te bouwen, dient er volgens de Twelve-Factor App methodiek te worden ontwikkeld. Deze principes schrijven bijvoorbeeld voor om logging als streams te behandelen en om de build, release en run van een microservice strikt gescheiden te houden en hoe deze uit te voeren. 

Alle microservices landen in containers binnen Docker en worden georkestreerd via Kubernetes. High level ziet een Microservice-architectuur er als volgt uit: 

4.2 Technisch platform & Tooling 

In deze paragraaf worden de diverse onderdelen benoemd die onderdeel zijn van het technisch platform (LPS): 

Onderdeel  Omschrijving
Kubernetes  Kubernetes is een container-orkestratieplatform. Alle services die in containers worden geplaatst, kunnen worden gemanaged via Kubernetes. 
AWS S3  De cloud object storage oplossing, die de data via het web beschikbaar maakt.
Load balancer  Virtuele dienst voor het verdelen van de verzoeken, dwz het notificatieverkeer, over de beschikbare resources.
Ingress  Ingress is een API die externe toegang van de diensten op de clusters beheert.
Nexus  Artefact repository benodigd om de software op te slaan en te verwerken in de build-pipelines (GitLab). 
Prometheus  Kan tracing, metrics en logging ontvangen en weergeven. Prometheus heeft een integratie met Grafana voor dashboards. 
Kafka 

De microservice-architectuur is event driven. Dit houdt in dat alle microservices een producer en/of consumer kunnen zijn van events. Om deze events te configueren en beheren wordt gebruik gemaakt van een cloud native event streaming platform. Kafka heeft 3 key capabilities: 

publiceren en abonneren op streams. de microservices maken gebruik van de door Kafka gegenereerde streams. 

het opslaan van de event streams. 

het verwerken van event streams. 

Kibana  Tooling voor loging, alerts kunnen apart worden toegevoegd. 
Gitlab  Het DevOps platform. Hierop worden alle microservices geplaatst en beheerd. 
Harbor  Harbor wordt gebruikt om de applicaties te verpakken voor deployment. 
Grafana  Dashboards voor monitoring metrics, Grafana heeft een built-in alert module.
Security tooling  Vanuit security oogpunt zijn alle onderdelen voorzien van een enige type security. Echter moet er nog worden over nagedacht welke security tooling er nog meer moet worden aangebracht op het platform. Hierbij kan men wat denken aan HashiCorp Vault om bijvoorbeeld secrets aan te maken en te managen. 

NB deze lijst kan mogelijk nog worden gewijzigd / aangevuld naar aanleiding van de aanvullende onderzoekspunten die hierboven zijn genoemd. 

4.3 Functionele uitwerking van de tooling 

In het onderstaande schema is de werking van het platform ten aanzien van de functionaliteit globaal weergegeven. De verschillende onderdelen van het platform zijn hierboven benoemd in paragraaf 4.2. In het omkaderde DevOps gedeelte zijn alle tools ingezet: van het ontwikkelen van een microservice tot en met het netwerkverkeer benodigd voor het versturen van de notificatie. 

4.4 Overwegingen / te nemen besluiten 

In deze paragraaf worden enige onderwerpen beschreven waarover nog besluiten / keuzes moet worden genomen. Reden hiervoor is dat deze tijdens de ontwerpfase wel ter sprake zijn gekomen, maar er op dit moment nog geen uitspraak over kan worden gedaan. 

Beheer van de applicatie op de technische infrastructuur. De technische infrastructuur wordt beheerd door Logius: zij bieden deze infrastructuur aan als PaaS-dienst. Dit houdt in dat Novum/SVB verantwoordelijk blijft voor het beheer van Notify en het technische onderhoud ervan. Bij het afnemen van een PaaS zijn bijvoorbeeld een server en het operating systeem onder beheer van Logius. Het enige wat bij een PaaS dienst niet wordt beheerd door de PaaS leverancier is de applicatie. In dit geval gaat het om Notify als applicatie. In onderstaande afbeelding is de verdeling te zien tussen wat Logius kan beheren (oranje) en wat een applicatiebeheerder beheert (blauw). 

Het is nog onbekend hoe hier invulling aan gaat worden gegeven. We adviseren om hier in een vroeg stadium tijdens het realiseren van de eerste versie (MVP) een keuze in te maken. Als de implementatie volgens DevOps principes wordt gerealiseerd, is het ontwikkelteam niet gescheiden van het beheer- / operations-team. Om hier een keuze in te maken moet er rekening worden gehouden met de fase waarnaartoe Notify zich beweegt: 

In geval dat Notify direct wordt ingezet als een overheidsbrede notificatiedienst, lijkt het logisch om Notify onderdeel te laten worden van de generieke diensten van Logius. Hierbij zou het beheer van de applicatie ook bij Logius komen te liggen. 

Wanneer Notify initieel niet wordt ingezet als overheidsbrede notificatiedienst maar bijvoorbeeld alleen voor SVB of een beperkt aantal deelnemende partijen, lijkt het logisch om het applicatiebeheer bij SVB (of een andere aangewezen partij) te beleggen. In dit scenario kan nog worden onderzocht of Notify in de toekomst eventueel alsnog bij Logius kan worden belegd. 

Aanvullende security tooling. Ondanks dat diverse security-aspecten worden afgevangen door de diverse gebruikte producten en standaarden, kan het mogelijk zijn dat aanvullende security maatregelen wenselijk zijn. Men kan hierbij denken aan secrets management (certificaten) of het implementeren van een specifieke autorisatie- en authenticatie-structuur. 

Advies 

Het Logius Standaard Platform biedt de benodigde services en tooling om Notify op te kunnen laten landen, op basis van moderne container-technologie. Het is relatief eenvoudig om gebruik te kunnen maken van het Standaard Platform; een aanvraag bij Logius voor het gebruik van de PaaS dienst, oftewel het Logius Standaard Platform, is voldoende. Zie verder de voorwaarden waaraan dient te worden voldaan zoals genoemd in paragraaf 3.10. 

5 Notify NL: Minimum Viable Product 

5.1 Wat is een Minimum Viable Product? 

“Een Minimum Viable Product (MVP) is de eerste versie van een product of dienst die zo vroeg mogelijk wordt uitgerold naar de klant. Het doel is om daarmee zo snel mogelijk feedback te krijgen. Deze feedback is belangrijk om hiermee de belangrijkste vervolgstappen te kunnen nemen.” (bron: Agile Scrum Group) 

Een MVP is dus niet hetzelfde als een Proof of Concept (PoC): een PoC heeft tot doel om te bewijzen dat de oplossing werkt, maar wordt niet uitgerold naar de klant. De door Novum in 2021 uitgevoerde Notify PoC is dus niet zonder meer geschikt om te gebruiken als MVP. In dit hoofdstuk wordt een voorstel gedaan voor een MVP versie van Notify NL. 

5.2 Overzicht MVP 

Onderstaande afbeelding presenteert een basisoverzicht van de architectuur van Notify NL, die is gebaseerd op de architectuur van Notify UK. De blauw gearceerde onderdelen zijn inbegrepen in de eerste release (Minimum Viable Product – MVP) van Notify NL. De grijze onderdelen zijn mogelijkheden die nog een verdere verkenning vereisen. 

5.3 In scope van de MVP 

Het Notify UK platform bevat op dit moment niet alle functionaliteiten zoals onderkend in de functionele architectuur voor een overheidsbrede notificatievoorziening (hoofdstuk 2). Notify biedt echter wel voldoende functionalteit voor een waardevolle MVP gericht op het verkennen / valideren van een overheidsbrede notificiatievoorziening met informele notificaties. Meerdere overheidspartijen kunnen daar dan op worden aangesloten als gebruiker van de MVP. Deze MVP kan worden gerealiseerd op basis van de beschikbare code van Notify UK, waarbij de applicatie landt op het Logius standaard platform en waarbij CM.com wordt ingericht als service provider voor de SMS berichten. 

De volgende onderdelen zijn in scope van de aldus te realiseren MVP: 

Onderdelen van Notify UK: 

Notify Frontend (web interface voor beheren van templates, versturen van berichten via HTTPS) 

Notify API (REST API voor beheren van templates, versturen van berichten, via REST API) 

Notify Admin (Dashboard voor status overzicht, via HTTPS) 

Service Provider voor SMS (CM.com)

In de MVP zelf de gebruikersgegevens verzamelen, en later aansluiten op de authenticatiemiddelen van Logius c.q. op de digitale bereikbaarheidsservice. 

Notify laten landen op het Standaard Platform (SP) van Logius. 

De componenten van Notify worden als containers gedeployed op Kubernetes clusters van het SP. De API’s van Notify worden ontsloten via de Logius API Gateway. 

Ontwikkelen service adapter voor het aansluiten op de service provider CM.com Ontwikkelen authenticatie adapter voor het aansluiten op DigiD / eHerkenning. 

Toelichting: Notify voorziet in de functionaliteiten die onderdeel uitmaken van de volgende functionele componenten / services, zoals beschreven in hoofdstuk 2. De functionaliteiten zijn echter op ander wijze in de applicatiearchitectuur gepositioneerd. 

  • Enkelvoudige notificatie client 
  • Bulk notificatie client 
  • Template Service 
  • API-integratie 
  • Centrale Notificatie component (m.u.v. de validatie- prioritering- en planningsservice) o Notificatie Database 
  • Outbound Handler Service 
  • Autorisatie Component 
  • Notificatie Adapter (wordt niet voorzien in Notify, dient echter wel te worden gerealiseerd in MVP om te kunnen voorzien in communicatie met CM.com) 
  • Twee-factor authenticatie 

5.4 Buiten scope van de MVP 

De volgende onderdelen zijn buiten scope van de MVP: 

Andere Notificatie Adapters / Service Providers dan SMS (email, briefpost, Whatsapp, Telegram, push notificaties etc.) 

Federatieve Autorisatie (met DigiD en eHerkenning) 

Integratie met Berichtenbox 

Diverse functionele componenten en services uit de functionele architectuur van hoofdstuk 2: o Berichtenmagazijnen * 

Berichtenlijst Service * 

Event Hub ** 

Event Priority Queues ** 

Gebruikers Selectie Service ** 

Digitaal Bereikbaarheidsprofiel Service * 

Notificatie Analyse Service ** 

Logging/Tracking Service ** 

* wordt niet voorzien in MVP op basis van Notify (en is waarschijnlijk ook niet nodig voor MVP); de betreffende componenten/services maken onderdeel uit van de toekomstige architectuur van het Logius FBS en worden hierin als zelfstandige services onderkend. 

** wordt niet voorzien in MVP op basis van Notify UK (is waarschijnlijk ook niet nodig voor MVP), maar wordt mogelijk in later stadium alsnog toegevoegd.

 

5.5 Verschil tussen de al uitgevoerde PoC en de MVP 

Een vergelijking tussen de door Novum in 2021 uitgevoerde PoC en de hierboven benoemde MVP levert de volgende verschillen tussen PoC en MVP versie. In de MVP versie zijn de volgende aanvullingen / aanpassingen voorzien: 

Notify laten “landen” op het Logius Standaard Platform (inclusief het voldoen aan de door het LSP gestelde randvoorwaarden, zoals containers die worden gedeployed op Kubernetes clusters) Voldoen aan overheidsbrede standaarden (BIO en AVG) 

Aansluiten op service provider CM.com 

5.6 Conclusie en advies 

Voor het realiseren van een MVP gericht op een eerste versie van een overheidsbrede notificatiedienst op het Logius Standaard Platform biedt de huidige versie van Notify zowel functioneel als non-functioneel een goede basis. Deze MVP moet dan wel gericht zijn op notificaties rondom informele berichten aan burgers vanuit de overheid. 

Notify biedt op dit moment echter nog niet alle functionaliteit die wij voorzien in een toekomstige overheidsbrede notificatiesvoorziening zoals beschreven in hoofdstuk 2. Dit betekent dat Notify in de toekomst, na de MVP, verder uitgebreid moet worden. De belangrijkste aanvullende functionaliteiten die daarbij op dit moment worden voorzien zijn: 

Functionaliteit om aan te sluiten op de (toekomstige) bouwstenen van de e-overheid, zoals de federatieve berichtenbox, het digitale bereikbaarheidsprofiel en authenticatiemiddelen (zoals DigiD); Adapters om aan te sluiten op andere kanalen (service providers); 

Functionaliteit om Notify rijker en robuuster te maken, zoals validatie-, plannings- en prioriteringsfunctionaliteit; 

Functionaliteit voor analyse en logging mede in het kader van security en eventueel het kunnen voorzien in een financieel afrekenmechanisme met deelnemende bestuursorganen; 

Functionaliteit voor het terugmelden van niet-afgeleverde berichten. 

Functionaliteit om naast burgers ook bedrijven te bedienen. 

Nog niet volledig onderzocht is in hoeverre de huidige code van Notify voldoet aan de alle geldende richtlijnen en standaarden zoals uitgewerkt in hoofdstuk 2. Eventueel moeten in de toekomst in dit kader ook nog aanpassingen aan Notify plaatsvinden. 

Het advies is als vervolgstap een implementatieplan voor het MVP op te stellen. In dit implementatieplan worden de doelstelling van het MVP verder verfijnd (wat wil Novum minimaal met het MVP bereiken?) en bepaald of er naast de huidige functionaliteit nog aanvullende functionaliteit nodig is. Vervolgens worden op basis hiervan de scope van de werkzaamheden, de planning en een budget indicatie vastgesteld. 

Hoewel het MVP op basis van Notify kan landen op het Logius Standaard Platform, en Logius daar ook achter staat, is (nog) niet vastgesteld in hoeverre deze toepassing van Notify past binnen de planvorming van Logius en of het aansluit op de functionele- en architectuur(principes) die Logius wil hanteren. Het advies is dit nader te onderzoeken met Logius. Daarnaast is het advies ook Logius in het vervolgtraject nauw te betrekken.

6 Risico’s

Risico (beschrijving) 

Kans 

(K/M/G)

Impact 

(K/M/G)

Maatregel ter 

voorkoming

Maatregel bij optreden

Logius maakt andere keuzes voor de ontwikkeling van een overheidsbrede 

notificatievoorziening.

Medium  Groot 

Vervolgtraject 

afstemmen met 

Logius voordat 

besloten wordt tot het realiseren van een MVP.

Onderzoeken of een MVP met Notify wellicht toch zinvol is om ervaring op te doen en 

eventueel tijdelijk als 

overheidsbrede voorziening kan fungeren. 

Onderzoeken of een MVP met notify alleen voor informele notificaties naast een 

notificatievoorziening voor 

formele berichten kan bestaan 

Logius richt legt prioriteit bij de ontwikkeling van een notificatievoorziening voor formele berichten.  Groot  Midden 

Afstemmen met 

Logius voor het 

vervolgtraject te 

starten.

Onderzoeken of een MVP met notify alleen voor informele notificaties naast een 

notificatievoorziening voor 

formele berichten kan bestaan

Notify blijkt niet aan te 

sluiten op nog te onwikkelen overheidsbrede services, zoals de 

bereikbaarheidsservice en de services van het 

federatief berichtenstelsel. 

Groot  Groot 

Vervolgstraject in nauwe 

samenwerking met Logius uitvoeren.

Eventueel Notify aanpassen, zodat wel aangesloten kan worden.

Contract van CM.com staat geen notificaties toe voor organisaties die niet 

behoren tot de 

Rijksoverheid.

Groot  Groot 

Onderzoeken of 

contract CM het 

toelaat en zo niet een aanvullend 

contract afsluiten

Geen deelnemers die niet 

behoren tot de Rijksoverheid toelaten.

Onvoldoende kennis van (de componenten van) het 

Logius Standaard Platform beschikbaar in het 

ontwikkel- / beheerteam

Medium  Groot 

Ruim vóór de start van development medewerkers met de benodigde kennis en ervaring 

Leverancier 

selecteren die aan die kennis heeft van 

Kennis alsnog 

opbouwen/aantrekken bij de teamleden van het ontwikkel- / beheerteam.

Onbeschikbaarheid van het Logius Standaard Platform Klein  Groot  SLA afspreken met Logius Actie door Logius
Onbeschikbaarheid van CM.com Klein  Groot  SLA afspreken met CM.com Actie door CM.com

Onbeschikbaarheid 

notificatievoorziening

Klein  Groot 

Zorgdragen voor 

een beheerteam

Actie door Oplosgroep

 

Lees het rapport in PDF

Lees het rapport in PDF

Let op: Deze PDF voldoet niet aan de toegankelijkheid eisen

Hoe nuttig was dit bericht?

Klik op een ster om deze te beoordelen!

Het spijt ons dat dit bericht niet nuttig voor u was!

Laten we dit bericht verbeteren!

Vertel ons hoe we dit bericht kunnen verbeteren?

Werk met ons samen aan Notify

15 + 2 =

Deel dit artikel
De eigenaar van deze website heeft zich gecommitteerd aan toegankelijkheid en integratie. Meld eventuele problemen die u tegenkomt via het contactformulier op deze website. Deze site maakt gebruik van de WP ADA Compliance Check-plug-in om de toegankelijkheid te verbeteren.