Notify NL – architectural design Notification service for the Dutch government Version 1.0 

Management summary 

Administrative bodies within the government, including the SVB, can use notifications to inform citizens about (important) events in the handling and handling process or about the service itself. Notifications are used both for formal messages (with legal force) from the government and for informal messages (without legal force) to citizens from the government. 

Based on the Notify notification facility, which is currently being developed in the United Kingdom and made available as open source, Novum has carried out a successful pilot with regard to payment moment notifications for SVB customers. Both citizens and other government institutions recognize the added value of notifications. Based on the results of this pilot, the idea arose to further investigate whether Notify could be used as a government-wide notification facility in the Netherlands. As a first next step, Novum wants to develop a Minimal Viable Product (MVP) in order to gain experience with this. Novum wants to land this MVP on the Standard Platform of Logius. Logius is positive about this. Novum has asked CGI to draw up an architecture / design document on the basis of which it can be determined what this Notify-based MVP can look like, and which relevant frameworks and guidelines must be taken into account when Notify is used as a government-wide notification facility in the landscape of the digital building blocks of e-Government. 

The research that CGI has conducted around the drafting of the architecture document shows that: 

The Electronic Administrative Traffic Modernization Act (Wmebv), which will come into force on 1-1-2023, will make notifications (particularly regarding formal messages) mandatory and will also set requirements for the process and its content; 

Within the developments with regard to the Federative Message System (FBS), the realization of notification functionality is provided as a central component within a broader landscape of modularly constructed generic and specific components. In addition, this FBS landscape also contains central facilities for the registration of channel preferences and the accessibility of citizens. 

The Wmebv and the developments surrounding the FBS mean that a central government-wide notification facility is provided as part of the e-Government building blocks. It is obvious that Logius will (in due course) become the manager of this component. At the moment it is not yet clear to what extent this functionality will provide notification for both formal and informal messages and when this functionality will become available. It is also possible that two government-wide facilities can co-exist. 

Taking these developments into account, it was investigated how a government-wide notification facility can be fitted into the modular architecture landscape of generic and specific e-government building blocks. This also connects to the existing services (building blocks) already provided for in the context of the FBS. Subsequently, it was investigated which parts of this can be completed by Notify and it was determined whether these, taking into account functional and non-functional requirements and frameworks, are sufficiently suitable to grow from an MVP to a government-wide notification facility. 

The conclusion is that Notify provides a large part of the functionality required within a government-wide notification facility. However, part of the functionality is currently not provided. This mainly concerns services still to be developed in the context of the FBS and the registration of channel preferences and 

reachability. Because this functionality is not yet available, it is not yet possible to make a statement about which functionality should be added to Notify in the long term or to which functionalities that should be generically available. 

Although Notify's architecture differs from the microservices-based architecture used by Logius, the solution offers both a functional and non-functional basis for the development of an MVP on the Logius Standard Platform to gain experience with informal notifications using a government-wide notification component. to do. This is possible based on the current functionality of Notify. 

 However, depending on the scope of the MVP (what does Novum want to achieve with the MVP as a minimum?), it may be necessary to realize additional functionalities for the MVP. 

Although the MVP based on Notify can land on the Logius Standard Platform, and Logius also supports it, it has not (yet) been determined to what extent this application of Notify fits within the planning of Logius and whether it fits in with the functional and architecture (principles) that Logius wants to use. This could be further investigated in collaboration with Logius. 

Irrespective of the answer to the question of whether Notify can eventually grow into the central government-wide notification facility, it may be useful to gain practical experience with SMS notifications for informal messages. Because Notify is a largely configured solution, this can be realized relatively quickly. In addition to the fact that experience can be gained with this, Notify can (perhaps temporarily) meet a need of citizens and administrative bodies in an accessible manner. 

The advice is to draw up an implementation plan as a follow-up step, in which the scope of the MVP and the related scope of the implementation and the approach, including the activities to be carried out and planning, are elaborated. Based on this, an indication for the required budget can then be determined. 

Partly based on the developments surrounding notifications in relation to the Wmebv and the FBS, we recommend taking the next steps in collaboration with Logius. In this way, support for the solution is increased and the uniform application of the notification facility that is understandable to the public is also guaranteed in the long term.

1 Introduction 

This Project Start Architecture (design) relates to the realization of a government-wide notification facility based on Notify. This notification solution was developed by the Government Digital Service in the United Kingdom and made available as open sources in Github. 

1.1 The background of notifications 

The government has more than 1,600 organizations and bodies, such as municipalities, provinces and independent administrative bodies and ministries. These government organizations carry out the tasks (often providing services) assigned to them on the basis of legislation and regulations. Where these tasks/services relate to citizens, the government sends messages and notifications to inform these citizens of (important) events in the handling and handling process. 

1.1.1 Administrative traffic 

For a government-wide notification facility, we focus on messages and notifications that are sent in the context of administrative traffic by administrative bodies with a (semi-)public task, such as municipalities, water boards, national administrators, and pension funds, aimed at citizens. 

1.1.2 Formal and Other Messages 

We distinguish between formal messages (messages with legal consequences) and other messages (more informative in nature). Notifications are not suitable for sending formal messages; which must be offered through channels with the same legal status as paper mail (such as the MijnOverheid Message Box). In addition, notifications cannot guarantee the relevant privacy frameworks (such as in the area of granting access) that are required for formal messages. 

Notifications are suitable for messages to citizens with an informative or service-providing character or as a trigger (announcement) for a formal message placed in a digital message box. Examples of messages that lend themselves to being sent to citizens as a notification are: 

Payment date or payment of, for example, allowances, benefits and allowances; Confirmation or reminder of an appointment made (by telephone); 

Reminder of an outstanding action, such as the delivery of missing documents; Announcement / signal in the context of new formal information in a digital portal or message box; Change of status in a pending case (under consideration, etc.); 

Signal about the imminent expiration of a driver's license or passport; 

Signal about the opening of a new scheme that may be of interest to citizens. 

1.2 Exploring a notification facility based on Notify 

By applying notifications based on SMS messages, the government can inform (a large group of) citizens in a proactive, accessible, uniform and efficient manner about events that are relevant to them in the provision of services.

The SVB regularly receives questions from citizens that could have been prevented if it had proactively informed these citizens via a notification. The proactive sending of notifications is in line with the objectives of the SVB in the context of proactive and personal services to citizens. 

At the end of 2021, Novum, the innovation lab of the SVB, conducted an exploratory study into sending SMS notifications in the context of the services provided by the SVB (AOW and Child Benefit). 

This exploration was based on Notify. This is a notification application that automatically sends text messages, e-mails and letters. The Notify solution is used in the UK to communicate with citizens. Citizens can receive the messages via SMS by registering for the service and providing their mobile phone number. Notify forwards messages to be sent to the SMS gateway. In the United Kingdom, the service (Notify.UK) was created bottom-up and developed from there into a central government service, with which governments send notifications (letters, e-mails and text messages) on a large scale from one centrally managed platform. The service is currently used in the UK for over 5865 services by over 1300 government organisations. Notify.UK is managed by “Gov.UK”. In addition, the solution is also used in Canada (GDC). The Notify code base is public and reusable (open source). 

The exploration with Notify by SVB / Novum has been successfully completed and both citizens and other government organizations (including UWV, RVO and ACM) have shown a positive attitude towards the use of SMS notifications. This led to the expectation that a generic notification service for the entire Dutch government would offer a solution to inform citizens from government organizations in a proactive, easy, uniform and efficient manner about events in the service. 

1.3 A government-wide notification facility 

There is as yet no generic provision within the government for notifications in the Netherlands. Together with SVB, Novum wants to gain experience in developing and launching a government-wide generic notification service. In this context, Novum wants to draw up a design for a notification service and also develop a Minimum Viable Product (MVP) based on the open source version of Notify. In this MVP version, notifications will be sent via SMS messages. 

Logius offers the 'Standard Platform' for (generic) government applications. On this platform, government organizations can develop and offer applications themselves within a private cloud environment of the national government. Backend and middleware components are completely taken care of on this platform (ie are provided by Logius). The standard platform therefore offers a good landing place for an initial implementation of this government-wide notification service based on Notify. Logius is positive about this. 

1.4 Question 

Set up a starting architecture/design for a government-wide notification facility that can be realized based on Notify on the standard Logius platform. What does a government-wide notification facility in the Netherlands look like? Look at (a) reusing the open source version of Notify from Gov UK as much as possible; (b) make sure it can land on the Logius Standard Platform; and (c) take into account the relevant applicable frameworks and guidelines in the Netherlands. Please indicate: 

How this provision can be fitted into the landscape of government-wide building blocks; Which standards, guidelines, legislation and regulations must be taken into account; Which minimum requirements and components must be completed for the development of a Minimum Viable Product (MVP) of this notification facility;

• Is the Notify open source project a good basis for this? To what extent can Notify be used in its entirety (or sub-components of Notify)? 

Out of scope 

• This document does not estimate the costs of achieving an MVP –
• This document does not elaborate an implementation plan for the realization / implementation of an MVP. 

1.5 Structure of the document 

This document answers the above question. Chapter 2 describes the overall functional architecture of the solution. Chapter 3 discusses the application architecture. Chapter 4 describes the infrastructural embedding (technical architecture). Subsequently, in chapter 5, the scope of a possible initial implementation (Minimum Viable Product) of a notification facility based on Notify is elaborated. Chapter 6 discusses possible risks. 

2 Functional architecture 

2.1 Context generic notification facility 

Notifications can be seen as messages (traffic) from governments to citizens. On a functional level, the messaging process can be divided into three aspects: 

• Logistics: knowing, searching, finding, tracking and sharing messages; 
• View: actually viewing a message; 
• Reply: replying to a message. 

Logistics: In order to be able to send a message to a citizen, it is necessary to indicate how he can be reached. It is important for the citizen to whom the message is sent that it reaches the citizen and that the citizen must be able to determine that he has received a notification ('new message!'). It is also important that the message is recognized as a notification from the government (so that citizens can recognize that it is not phishing). 

View message: From a notification or his overview of messages, the citizen must be able to view a message and, if desired, save it within his own environment. For the contact between user and administrative body it may be necessary that it is clear to both sides that the message has actually been sent by the administrative body and has actually been delivered to the user (Wmebv). 

Reply message: A message does not stand on its own; the citizen may be expected to take action or may have a question in response to the message received. The citizen must be able to respond to the message or follow up on it, for example by contacting the government organisation. 

Implications of the above for SMS notifications are as follows:  The citizen's mobile number must be known to the government.  It must be possible to determine that the message has been delivered.  The citizen must recognize on his mobile phone that he has received a new message The citizen must be able to recognize that it belongs to the (relevant) government and that it is safe. It must be clear to the citizen how follow-up can be given to a message

2.2 Capabilities generic notification facility 

Based on the above 3 main aspects of message traffic, a government-wide notification facility must have the following capabilities (from which functionalities can then be derived):

	Subject
1.	Control over accessibility	Citizens are able to make their 'accessibility' known to the administrative bodies
2.	Directing wise interaction	Citizens are able to indicate in what way (via which channel) they wish to interact with the administrative authorities
3.	Get notified	The citizen is able to receive a notification from the administrative authorities about a message made known to him

 

4.	Overview of messages	The citizen is able to view the messages he has received from the administrative authorities
5.	Take note	The citizen is able to take cognizance of a message that has been made known
6.	Take follow-up action	The citizen is able to take action in response to a received message
7.	Show registration acknowledgment and receipt	It is clear to the administrative body that a message has actually been received by the citizen**

** This insight is part of the government's duty of care that is part of the Wmebv, which is expected to come into effect in 2023. 

2.3 Stakeholders 

A government-wide notification facility has various stakeholders. These are included in the following figure. In addition, this figure outlines the role and function they have in the landscape. 

2.4 Government-wide notification facility functions 

2.4.1 Principles 

The principles that we have applied when describing the functionalities of a government-wide notification facility are as follows: 

Although, as indicated in section 1.3, the MVP version of the government-wide notification facility will focus on SMS notifications, it is obvious that such a facility will (in the future) provide multiple channels. The following channels can be considered: 

• SMS/OTP1 
• E-mail
• Chat (such as Whatsapp/Telegram) and other public social Apps' 

1 An SMS OTP (one-time password) is a secure authorization method in which a numeric or alphanumeric code is sent to a mobile number. This password is an additional layer of security used to verify a user's identity

• Push notifications (mobile and web browser) 
• Post 
• The notification facility must therefore make it possible to add new channels and to phase out existing channels. 
• Notifications are sent based on the citizens' saved preferences; Notifications are sent based on the priorities specified by the administrative organization; Governing bodies can send notifications singly or in bulk; 
• The notification facility will become part of the landscape of government-wide building blocks in the Netherlands. Based on the current understanding, a central notification facility that is used by all government organizations seems obvious. This is the starting point in this document. However, it is also conceivable that organizations within a federated system have their own implementation (bodies) of this facility. Such a federated notification service is not further elaborated in this document; if this is still desirable (for example after further discussions with Logius), additional research could be done into this. 

2.4.2 Functional components of government-wide notification facility 

This section describes the required functionalities of a notification facility that can be used as a government-wide generic notification facility. This means that this facility is part of the building blocks of e-government and several government organizations (administrative bodies) can use it to send notifications to citizens. Because the notification facility must be fitted into the (partly yet to be realized) modular architecture landscape of generic and specific e-government building blocks and because Logius, as the likely future manager of this landscape, applies a microservice architecture, it has been decided to describe the functionalities as separately distinguishable functional components and services. 

In the actual implementation of the application architecture – for example based on Notify UK – it may be the case that it provides functional components other than those described here, but which do provide the desired functionality described here. This analysis is further elaborated in chapter 3. 

The components and services are explained below using the figure below. The figure is included in a larger format in the appendix. 

Notification Clients 

Message warehouses: This concerns the message warehouse of the central Message Box solution and the federated message warehouses of the affiliated government organizations (administrative bodies) of the federative message system (FBS) to be realized. 

Message List Service: The Message List Service lists all messages sent to citizens and entrepreneurs. The recipient can access the message in the warehouse where the sender placed it through the message list. The message list service also sends notifications via the generic message list service. 

Single notification client: This service provides the ability to create and send single notification requests. The service also provides a User Interface that allows a user to create and send a notification manually from a browser. 

Bulk notification client: This service offers the possibility to send a list of contact details to the Notification service in order to send a large number of messages at once. In addition to the contact details, the template to be applied can also be indicated and the schedule (date, time on which you want the notifications 

send) are provided. The service also provides a User Interface that allows a user to manually create, format, schedule, and send a list of messages to send. 

Notification Services 

Template Service: The function manages the message templates (templates) for the various notification messages. The templates can be personalized for both participating organizations (such as layout) and per recipient, whereby personal salutation, specific context, data and other variables are possible, for example. The templates are used to send the same message to multiple people (large groups and as often as necessary). In addition, the function offers: 

REST APIs for creating, updating, deleting, and managing message templates; A user interface for controlling and managing message templates via a web application. 

API integration: API integration ensures that the participating government organizations can integrate with the notification service. In this way, own systems can be linked, making automatic dispatch possible. 

Central notification component: The central notification service sends predefined notification messages to one, a few or a large number of recipients. The messages are presented to the notification component by the clients: 

• Bulk notification clients: These clients send bulk notification(s). 
• Single notification clients: These clients send single notification(s). 

The services (APIs) will present themselves to the message composing clients using the Template Service. These messages are also validated using the validation service. 

The following services are part of the Central Notification component: 

• Validation Service: This service ensures the validation of notification messages against business rules and expected format. 
• Prioritization Service: This service prioritises, based on the priority specified by the participating organization, the sending of the notifications based on high, medium and low priority.
• Scheduling Service: This service offers the possibility to schedule the sending of notifications. Think of sending notifications within a minute or an hour or on a specific day, week, month or year. 

Notification Database: The Notification Database will store all notification messages with their delivery time, status, etc. Optionally, the feedback information from the service providers regarding the delivery of the notifications can also be stored in the database. All this, of course, within the framework of the GDPR. 

Event Priority Queues (Event Hub): The Event Priority Queues forward the received validated notifications with high, medium and low priority through the User Selection Service and the Outbound Handler to the Event Hub. 

Burger selection and profile 

User Selection Service: The User Selection Service determines the personal preferences of the user based on the personal data provided with a notification, the Digital Accessibility Profile Service and then forwards the notification to the Outbound Handler, which forwards the Notification to the Event hub. 

Digital Accessibility Profile Service: The Accessibility Profile is the function where a citizen can manage his accessibility and preferences in contact with the government. After a citizen (user) has authenticated, the function offers the citizen the opportunity to indicate per allowed channel how he can be reached. Think about: 

• The e-mail address on which he wishes to receive messages; 
• The phone number on which he wants to receive SMS notifications; 

In addition, the function also offers the option to opt in and out of the notifications for notifications and also the frequency with which notifications are received. The accessibility profile can be designed as a generic functionality within the government, but may also be made available to administrative bodies within their own information provision. 

Rationale: From the perspective of the citizen (convenience and recognisability), it is ultimately desirable that there is one common place for managing (digital) accessibility, preferences and channel addresses. This prevents a citizen from having to act in many different places and in different ways each time, and it also prevents that profile from being inconsistent or not up to date. 

Implications: Use of this generic function is mandatory for government organizations. System agreements are necessary to regulate the shared responsibility for and the use of this function.

 

Outbound handler Service: This service will process notification messages waiting in the Event Priority Queues by polling them based on their priority (highest to lowest) 

Event Hub: The Event Hub sends the Notification to the different adapters. These adapters will be based on different channels. 

Notification Adapters: These are the adapters that transform the notifications provided by the Event hub and serve them to the external service providers according to their supported format. Examples of these adapters are: 

• SMS/OTP adapter 
• Email adapter 
• WhatsApp adapter
• Telegram adapter 

Notification Service Providers: These are the external service providers, who take care of the actual notification 'transmission'. These will often be SaaS solutions. Examples are: 

• SMS-Gateway (Note: for the Dutch government the default gateway is CM.com) E-mail Gateway; 
• Mobile Push Notification Service; 
• WhatsApp API partner 
• Telegram API partner 

Note: The service providers will also return information about the (successful) delivery of the messages. 

Notification Analysis Service: This service performs analyzes and provides reports regarding the sent notifications. It offers a dashboard that shows, among other things, the number of messages sent per participating organization. Other data that may be shown in the dashboard are: Total number of notifications per day/per sec. 

• What is the most used notification channel. 

Also, the current status of each notification can be checked to see when it was delivered. 

Logging/Tracking Service: This service continuously monitors all sent notifications. It registers metadata of the notifications such as sending time, delivery status, communication channel, type and delivery, etc. Which data is recorded, and how this is made accessible, needs to be worked out in more detail, taking into account the applicable frameworks of the GDPR and applicable audit guidelines. 

2.4.3 Non-functional requirements 

In addition to the functional components and services, various non-functional requirements must be taken into account when setting up a government-wide notification facility. Naturally, a government-wide notification facility must in any case meet government-wide requirements in the field of security, information security and privacy. In addition, scalability of the facility is an important aspect because the service must be prepared for peak loads with an increasing number of customers. 

The most important non-functional requirements are explained in outline below: 

Scalability: The solution must be linearly scalable without service interruption (application of automatic up- and down-scaling on the container platform of the Logius Standard Platform can be useful here); 

Availability: The solution must be highly available 24*7; 

Performance: consider requirements such as: 

• XX% of the emails and text messages must be sent within YY seconds; 
• The number of organizations that must be able to use the solution simultaneously;
• The average and maximum number of notifications to be sent per day; 

Cloud native: Full cloud native modern system to realize; 

Logging: The solution logs the actions of all users and the system, so that all actions are traceable and irrefutably recorded;

Connection requirements: New customers can easily connect (multiple connection options are available for both highly and less automated customers; 

Standards forum for standardization: All interfaces are based on open standards of the Forum standardization bureau (www.forumstandaardisatie.nl), or equivalent; 

Usability: User interfaces of the solution must comply with government guidelines for a user-friendly website. This set of guidelines ensures that content on websites and web applications must be optimally usable and accessible for users (including people with and functional disabilities) on a variety of devices and operating systems. In 2018, the Web Guidelines 2 on the 'comply-or-explain' list were replaced by 'Digital Accessibility'. 

Integration: The solution must support API integration for all modules, integration with government organizations and with the SMS gateway; 

Security and Privacy: The solution must be BIO and GDPR compliant. See section 2.4.4 for a further explanation. 

2.4.4 Security and Privacy 

Information security and protection of personal data are important aspects of information management within the government and therefore also for a generic notification facility. In order to comply with the legislation, the Government Information Security Baseline (BIO) is in use within the government. The BIO is a collection of frameworks and guidelines that all aspects related to ICT services (business operations, processes, personnel and infrastructure) must comply with. In addition, the General Data Protection Regulation (GDPR) applies to all organizations, which regulates how to handle personal data. 

Depending on the information that the government-wide notification facility contains and processes, certain security measures must be taken. To determine which measures these are, both the BIO and the AVG prescribe that an organization carries out risk analyzes with regard to information security (the BIAs) and privacy (the PIAs). Based on these analyses, the so-called basic security level is determined. The BBN classification is used in the BIO to determine which requirements and measures from the standard in the field of availability, integrity and confidentiality apply to achieve an adequate level of protection. 

In order to determine the definitive set of measures, the above analyzes will have to be carried out for the government-wide generic notification services. We assume that BBN2 (departmentally confidential) is sufficient as a basic security level. BBN2 provides adequate protection for the most common categories of information. This level applies to information where the Availability, Integrity, and Confidentiality levels have a value of Medium. 

2.5 Relevant e-government building blocks 

Assuming that a government-wide notification service will become part of the set of e-Government building blocks, it is important to position it within this landscape. It is therefore obvious to position the Notification Service as one of the Contact functions of e-Government. In the following figure, the Notification component and the Accessibility profile are plotted in the landscape of eGovernment building blocks. We have included the Accessibility Profile separately, because this service, like the notification service, is recognized as a generic service within the landscape of e-Government Building Blocks. Subsequently, the relevant e-Government building blocks are explained in more detail.

Subject	Description
DigiD and others  authorized resources	DigiD is the digital authentication system for government organizations and public service providers. With DigiD they can determine the identity of citizens online. When a citizen logs in with his personal DigiD, the government organization receives feedback via DigiD on the citizen service number (BSN). In addition to DigiD, eIDAS is also a permitted means of login for citizens who are living in an EU country other than the Netherlands. In the future, when the WCO comes into force, other login methods may also be allowed.
MyGovernment	MyGovernment is the digital counter where citizens can view their personal data at government organizations, receive digital letters from government organizations, and track the status of current affairs and transactions in an easy and secure manner. MijnOverheid is an additional channel for government organizations to reach their target groups more efficiently, making their services more accessible and claiming transparency.
Message box for  citizens	The Message Box (on MyGovernment) is the digital mailbox for messages from the government to citizens. If there is a message in the box, this will be notified to the relevant person by e-mail. Sending messages via the Message Box is not (yet) possible. Note: The current Message Box will be replaced by the federated message system (FBS), see section 2.5.1.
BRP (Basic Registration of Persons)	The Municipal Personal Records Database (BRP) contains personal data about all residents of the Netherlands and about people who do not live in the Netherlands – or stay for a short time – but who have a relationship with the Dutch government, the 'non-resident'.
Citizen service number (BSN)	The citizen service number (BSN) is the personal number for contacts with the government. This unique number helps to prevent mistaken identity, for example. Everyone who registers with a municipality for the first time receives a BSN. This is registered in the BRP.
Digilink	Digi coupling consists of interface standards established by the Standardization Board. These standards contain logistical agreements to address messages correctly, to make them legible and interchangeable and to send them safely and reliably. Digi Koppel deals with the 'envelope' and carries out what is written on it. The data then goes to the right government organization and to

 

Subject	Description
	the right adress. Registered or not, encrypted, as a repeated offer, or return to sender. The contents of the message in the envelope are for the addressee. DigiLink recognizes two main forms of message traffic: inquiries and reports. The form of the message traffic determines which interface standard must be implemented. The starting point of Digi Koppel is that an organization sets up a link point according to Digi Koppel at one location in its own ICT infrastructure.  Digilink Standards  DigiLink compliance facility  CPA Creation Facility  OIN registry
Diginetwork	Diginetwerk is an agreement system of closed networks. The network was created by linking a number of these private networks for the government, so that fewer cross connections were needed and costs could be saved. By making joint agreements in the field of connectivity, availability, security and the use of standards, every affiliated organization can communicate with every other affiliated organization.  Diginetwerk: preferred channel for internal government communication  Due to its closed character, Diginetwerk means that all participating organizations are known.  Due to its private character, Diginetwerk is a safer alternative, without the risks associated with the internet (for example DDOS attacks, hacking and malware), for exchanging data between government organisations.  Diginetwerk makes it possible to communicate efficiently and reliably with all affiliated government organizations via a single network connection. The management and security of the linked private networks are provided in a standardized manner.
Web Guidelines	Web Guidelines are a set of requirements that all government websites must meet. This is how we ensure high-quality websites. Because information on websites must be accessible to everyone, including people with disabilities, mobile phone users and all possible browsers. The Web Guidelines contain guidelines that make content on websites and web applications optimally usable and accessible for users on a variety of devices and operating systems. The Web Guidelines ensure that content on websites and in web applications is also accessible to people with disabilities. In October 2016, the Web Guidelines 2 on the 'comply or explain' list were replaced by 'Digital Accessibility'.

2.5.1 Logius Federated Messaging System 

The Message Box is the personal, secure mailbox on Mijnoverheid.nl for all electronic messages from the government to individual citizens. The Message Box can be used as a formal alternative to physical mail - including messages with legal consequences. Mail in the Message Box has the same legal status as paper mail, unlike e-mail messages. 

The Federative Messaging System (FBS) is the new messaging facility of Logius. FBS replaces the current Message Box facility. With FBS, messages are stored in their own warehouse or in the new shared central message warehouse (BBO) of Logius. If there is a new message, they alert the citizen by registering the message in the system. Messages are included in the message list and the citizen receives a notification via the notification service (on the communication channel of his choice) that there is a message for him. A citizen or entrepreneur can indicate how he wants to be approached by the government. 

The citizen gets direct access to the message in the archive of the service provider via FBS. If service providers cannot or do not want to open their archives, there is the BBO: Message Warehouse for Citizens and Companies). 

The FBS is made up of several components: 

• Interaction layer: The way in which communication takes place with the citizen/entrepreneur. Generic Services: The core of FBS is formed by a number of generic services. These provide the necessary functionality for messaging. 
• Message warehouses: These belong to the affiliated organization or the central BBO.
• Agreement system: A set of agreements on how we work together in this system. 

Illustration structure FBS, a dotted line indicates a system component, a solid line is an agreement and/or chain agreement. 

Explanation Generic Services in Federated Messaging System 

• The Message List Service lists all messages sent to citizens and entrepreneurs. The recipient can access the message in the warehouse where the sender placed it through the message list. 
• The Notification Service sends notifications by e-mail, SMS, app, etc. directly to citizens and entrepreneurs. The sender of the message determines the content and format of the notification. 
• The Notification Profile Service gives citizens and entrepreneurs the opportunity to indicate in one place how they want to be notified: via e-mail, SMS, app, etc., or not at all. With the Digital Accessibility Service, citizens and entrepreneurs can indicate in one place that they agree to receive digital messages exclusively via FBS. 

Because the starting point is that the Notification Service will be fitted into the set of government-wide building blocks, the (generic) services provided in the context of the FBS have been taken into account in the design of the generic notification components. 

2.6 Relevant Laws and Regulations 

This section describes the relevant legislation and regulations and other documents that play a role in the realization of a government-wide Notification facility, namely: 

• Electronic Administrative Traffic Modernization Act (WMEBV) 
• Archives Act 
• General Data Protection Regulation (GDPR) 
• Government Information Security Decree (BIO) 
• Digital Accessibility
• Mandatory standards Forum for standardization 
• Positon Paper Messaging 

These and their impact on the notification facility are explained in the remainder of this section. 

Electronic Administrative Traffic Modernization Act (WMEBV) 

The Electronic Administrative Traffic Modernization Act (WMEBV) stipulates that citizens and companies can conduct their business with the government digitally. It is expected to enter into force (in phases) in 2022/2023. The law gives citizens the right to communicate electronically with the government in formal proceedings. 

When using a message box, the government is obliged to send an (e-mail) notification to the recipient of this message within 48 hours. This must at least indicate the nature and legal consequences of the message and any time limits for the addressee. At the moment, this information is often still missing in online notifications, so that (the difference in) the urgency of a message is not conveyed to the citizen. 

If it turns out that a notification cannot be delivered, it must be resent at least once. If the second notification is not delivered again, the administrative body must make an effort to reach the citizen in another (electronic) way. 

Conversely, a message is considered 'received' the moment the message reaches the administrative body's system, or becomes accessible to the administrative body in some other way. Incidentally, any disruptions may not be held against the citizen by the administrative body in the event of time limits being exceeded. Finally, the burden of proof regarding the receipt and transmission of messages in a message box rests with the administrative body. The citizen is entitled to a copy of the log data insofar as this is available. This strengthens the position of citizens in the event of a conflict about whether or not a message has been sent. 

For messages from the government in a message box: 

• Mandatory notification when posting a message in a message box. 
• Include essential information in a notification. Many messages are routine (e.g. monthly about student finance). Some messages require a response within a certain period of time, otherwise sanctions will follow. This is currently not visible in the notification, which means that messages often wrongly remain unread. It is prescribed that a notification must state information about the nature and legal consequences of the message, as well as the response time. 
• Contact us by other means if a notification cannot be delivered. If an e-mail address changes (for example when a provider is taken over) and someone forgets to register it with the Message Box, he will no longer receive notifications. Missing messages as a result can have serious consequences. It follows from the law that if a notification fails to arrive several times, the addressee must be contacted (in writing, by telephone) to obtain a new address.
• The burden of proof regarding receipt and dispatch with a message box rests with the administrative body; the citizen is entitled to a copy of the log data. This strengthens the position of citizens in the event of a conflict about whether or not a message has been sent. 

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

To facilitate and further digitize this communication, the government has made several legislative proposals, some of which have already been adopted. Some of them are discussed in this article. 

Archives Act

The Archives Act is the most important act for the provision of information by the Dutch government. This law indicates that governments must ensure that their information is kept in a good, orderly and accessible state. Information must be easy to find and consult. Governments must also ensure that information that qualifies for this is destroyed. Insofar as the generic government-wide notification solution stores data, the Archives Act must be applied. 

General Data Protection Regulation (GDPR) 

Describes the rules for handling personal data. Depending on the personal data processed in the government-wide notification facility, the measures included in the GDPR apply. See also section 2.4.4. 

Government Information Security Decree (BIO) 

The Baseline Information Security Government (BIO) describes the basic level for information security. The BIO is used within the Dutch government, by the national government, municipalities, water boards and provinces. Depending on the Basic Security Level to be determined, measures, as included in the BIO, must be implemented within the government-wide notification facility. See also section 2.4.4. 

Digital Accessibility 

Since 1 July 2018, the Digital Accessibility Decree has been in force. The decree is the successor to the web guidelines. The reason for the word 'temporary' in the name is that the basis is ultimately provided by the Digital Government Act. The Decree stipulates that websites and apps of Dutch government agencies must meet the accessibility requirements. It provides a set of guidelines to ensure that content on websites and web applications is optimally usable and accessible to users (including people with disabilities). The guidelines therefore also apply to the parts of the generic government-wide notification facility that contain a User Interface. 

Mandatory standards Forum for standardization 

Forum Standardization is an advisory committee that is supported by the Bureau Forum Standardization (BFS). This office is housed at Logius, the digital government service of the Ministry of the Interior and Kingdom Relations. The forum has drawn up a list of open standards that have a 'comply or explain' obligation within the government. The use of these open standards ensures interoperability, cost savings, digital sustainability, flexibility, innovation and more freedom in choosing suppliers. The generic government-wide notification facility must, where relevant, apply the open standards as included in this list. 

Positon Paper Messaging 

This position paper partly gives substance to the generic function 'correspondence by and with the government' of the Digital Infrastructure Policy Framework. Digital messaging concerns all agreements, standards and facilities that enable safe and reliable digital messaging between the government and users, including notifications. The position paper contains the picture of the desired solution as indicated by the stakeholders (including the Ministry of the Interior and Kingdom Relations). 

3 Application Architecture 

This chapter describes the application architecture of Notify NL, which is based on the existing Notify UK implementation. The first is to examine which functions are provided by Notify UK, including non-functionals; Next, the Notify NL application architecture is described and a mapping is done from the Notify UK implementation to the generic notification architecture as described in Chapter 2. 

3.1 Features of the Notify UK Service 

Below is an overview of the functionality provided by Notify UK: 

• Front end 
  • sending SMS messages 
  • sending emails (out of scope) 
  • sending file by email (out of scope) 
  • sending letters (out of scope) 
  • Upload contact information 
• REST API 
  • sending messages (SMS, e-mail, letter) 
  • request message status 
  • request template 
  • requesting received messages 
• Multi-platform API client (Java, .NET, Node JS, PHP, Python, Ruby) Real-time dashboard 
  • overview status of sent messages, number of failures 
  • maintain message templates, upload in csv format 
• 24-hour online support 

Further details of Notify UK functionality: https://www.notifications.service.gov.uk/documentation 

Below is an overview of Notify UK's Non-functional requirements (NFR): 

• Performance: 95% of messages are sent within 10 seconds 
• Two-factor authentication (2FA) for login 
• API authorization via JSON Web Tokens 
• Data is sent and stored encrypted 
• Data is purged after 7 days 

3.2 Mapping of Non-functional requirements on the Notify platform 

In this section, the Non-functional requirements from the functional architecture of Chapter 2 are discussed and the extent to which the Notify UK platform contributes to achieving them. 

Scalability: The solution must be linearly scalable without service interruption (application of automatic up- and down-scaling on the container platform of the Logius Standard Platform can be useful here); 

• The Notify UK platform consists of containers that can be easily scaled up and down.
• Availability: The solution must be highly available 24*7;
• The architecture of the Notify UK platform is designed for high availability. 

performance: 

• 95% of the messages are sent within 10 seconds by the Notify platform. 
• Cloud native: Full cloud native modern system to realize; 
• Notify UK does not explicitly call itself Cloud native. The Notify UK platform is designed to run on a container platform. 
• Logging: The solution logs the actions of all users and the system, so that all actions are recorded traceably and irrefutably. 
• The Notify UK platform offers standard logging functionality. Whether this requirement is fully met has not been investigated further. 

Connection requirements: New customers can easily connect (there are several connection options available for both highly and less automated customers); 

The Notify UK platform offers the option to connect new customers as standard. 

Standards forum for standardization: All interfaces are based on open standards of the Forum standardization bureau (www.forumstandaardisatie.nl), or equivalent; 

The Notify UK platform has been developed in the UK and does not take into account the open standards of the Forum standardization agency. It does meet British standards. 

Usability: User interfaces of the solution must comply with government guidelines for a user-friendly website. This set of guidelines ensures that content on websites and web applications must be optimally usable and accessible for users (including people with disabilities) on a variety of devices and operating systems. In 2018, the Web Guidelines 2 on the 'comply-or-explain' list were replaced by 'Digital Accessibility'. 

• The Notify UK platform has been developed in the UK and does not take into account the 'Digital Accessibility' guidelines. It does meet British standards. 

Integration: The solution must support API integration for all modules, integration with government organizations and with the SMS gateway; 

• The Notify UK platform supports standard API integration. 

Security and Privacy: The solution must be BIO and GDPR compliant. See section 2.4.4 for a further explanation. 

• The Notify UK platform has been developed in the UK and does not take into account the guidelines of BIO and GDPR. It does meet British standards.

In the following paragraphs, the Notify NL application architecture based on Notify UK is further elaborated, and a mapping is made from the functional application architecture of Chapter 2 to the components of Notify UK mentioned above. 

3.3 Actors 

The following actors have a role in the Notify NL service: 

• Participating government organizations 
• Customers (citizens) 
• Administrators 
  • Notify: functional management 
  • Logius: functional management (application supplier) and technical (platform team) 

3.4 Technical Components 

This section describes the technical components of the Notify UK platform to be used. 

• notifications-api (REST API for managing templates, sending messages)
• notifications-admin (Status overview dashboard) 
• notifications-utils (various generic components) 
• notifications- client (clients to connect to Notify from various platforms)
• content-store (The Content Store is a MongoDB database for storing GOV.UK's published content.) 

In addition, Novum has added two new components to the Notify UK platform: 

• notifications-frontend (web interface for managing templates, sending messages) 
• novum-notify (not known what this component does) 

Technology used per component of the Notify UK platform: 

• notifications-api, notifications-admin, notifications-utils: 
  • Python 
• content store: 
  • Ruby on Rails, Docker 
• notifications- -client: 
  • the technology varies by client, such as Go, Java, NET, PHP, Python, and Ruby. 

The components of the Notify UK platform are on GitHub: 

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

3.5 Interfaces and information flows 

To provide the necessary information flows for sending notifications, as described in chapter 2, the application architecture provides the following interfaces: 

• Notify Front-end (web interface for managing templates, sending messages via HTTPS)
• Notify API (REST API for managing templates, sending messages, via REST API)
• Notify Admin (Status overview dashboard, via HTTPS) 
• CM.com (for SMS connection, via REST API) 
• DigiD, eHerkenning (for authentication, via SAML 2.0) 
• out of scope: email link 
• out of scope: letter post link 

3.6 CM.com 

• CM.com will act as the SMS service provider of the Notify platform. 
• CM.com has an SMS API for this, which is accessed through their SMS Gateway API. Novum has already made agreements with CM.com for this. 
• The Notify platform sends the notifications via the SMS API to CM.com, which sends them to the customers via SMS 
• This link is not part of Notify UK, a custom adapter will have to be developed for this. 

SMS Gateway API | Send and receive SMS messages worldwide: 

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

Advice: further investigation  It is desirable, when several government parties are connected to Notify NL, to find out which participating party has sent a notification. CM.com's API does not provide for this. The existing Notify UK implementation and the underlying platform used therein are also not entirely clear about this; it uses a content store developed elsewhere in MongoDB. This has not yet been provided for in the first version (MVP), but it is recommended to investigate this further or possibly add it in a later phase (after the MVP).

 

3.7 Deployment View 

Notify will land on the Logius Standard Platform (LSP). 

The components of Notify are deployed as containers on Kubernetes clusters of the LSP.

Notify's APIs are accessed via the Logius API Gateway. 

Notify has a link with standard Logius services such as DigiD and eHerkenning.

3.8 Federated Authorization 

Novum's proposal is to initially collect the user data itself, and later to connect it to the (still to be developed) availability service and/or Logius' means of authentication. Users of participating organizations can log in to the Notify front-end at a later stage using the government-wide login means eHerkenning or possibly DigiD. These are also services of Logius. In both cases, this concerns users who log in to the (notifications) clients of the system, ie to send messages and maintain templates, or to register accessibility (preferred channel, contact details / telephone number). 

DigiD and eHerkenning (and also eIDAS) are means of authentication prescribed by NORA. 

A SAML 2.0 connection is required for DigiD and eHerkenning. Logius currently does not yet support OAuth / OpenID Connect. This connection is not part of Notify UK. A custom adapter will have to be developed for this, which can be added later. 

Federated Authorization means that organizations that want to connect to Notify must be part of the Federation. They must support government-wide services such as DigiD or eHerkenning and use government-wide standards such as DigiKoppeling. To make that possible, another adapter must be developed and added. 

NB If Notify would like to use DigID as a login method in the future, Notify must first be subjected to a formal DigiD audit. 

3.9 Stakeholders and Parties 

Novum (client) 

SVB (launching customer) 

CGI (ICT service provider) 

CM.com (SMS service provider) 

Logius (Standard Platform provider) 

out of scope: email provider 

outside scope: letter post provider 

outside scope: providers other than SMS

 

3.10 Frameworks and guidelines 

The applicable frameworks and guidelines of the government (including BIO, AVG) and those of Logius (such as DigiKoppeling, Diginetwerk) have already been mentioned in chapter 2. In addition, the following guideline applies from SVB: 

Open source components are only allowed if they are supported by the supplier. 

The Logius Standard Platform also sets requirements for suppliers who want to run applications on it. To be able to develop an application that has to run on the SP, the following competences are required: 

Supplier has knowledge of “Cloud Native” application development. 

Supplier has experience as a developer with Kubernetes. 

The supplier has experience in creating Docker images, whereby the Docker containers fall under the orchestration of Kubernetes. 

Supplier has knowledge of and experience with the use of tools from the “CNCF Landscape”. Supplier has knowledge of and experience with the development of Open Source Software. Supplier has knowledge of and experience with Continuous Integration and Continuous Deployment. Supplier has knowledge of and experience with NORA, BIO and GDPR. 

Supplier works according to the principles of Security by Design and Security by Default Supplier has knowledge of and experience with PKI (Public Key Infrastructure. 

Source: https://www.logius.nl/diensten/standard-platform/standard-platform-documentation/requirements-for-suppliers 

The above is a list of requirements from the Logius Standard Platform. In order to be able to implement the Notify UK platform, a limited number of additional requirements may still need to be specified, which have not been further elaborated in the current version of this report. 

3.11 Mapping of the functional components on the Notify components 

This section discusses the various functional components and services of the functional architecture from Chapter 2, mapping the components of the Notify UK platform with which they can be delivered. 

Message warehouses 

This concerns the message warehouse of the central message box solution and the federated message warehouses of the affiliated government organisations. 

The Notify UK platform does not offer Message Warehouses. This function is also not required as part of the notification facility, because it is already provided in the federated messaging system (Logius FBS). 

Message List Service 

The Message List Service lists all messages sent to citizens and entrepreneurs. 

The Notify UK platform does not provide a Message List Service. This function is also not required as part of the notification facility, because it is already provided in the federated messaging system (Logius FBS). 

Single notification client 

This service offers the possibility to create and send single notification requests. 

The Notify UK platform does not offer a Single notification client. This feature is provided by the notification clients of the Notify UK platform. 

Bulk notification client 

This service offers the possibility to send a list of contact details to the Notification service in order to send a large number of messages at once. 

The Notify UK platform does not offer a specific bulk notification client. This feature is provided by the notification clients of the Notify UK platform. 

Template Services 

The function manages the message templates (templates) for the different notification messages. The Notify UK platform does not offer a separate Template Service. This feature is provided by the front-end of the Notify UK platform. 

API integration 

API integration ensures that participating government institutions can integrate with the notification service. 

This feature is provided by the Notify UK platform REST API. 

Central Notification component 

The Central notification service sends predefined notification messages to one, a few or a large number of recipients. 

The Notify UK platform does not offer a separate Central Notification component. Sending notifications is the core functionality of the Notify UK platform. Service for validation, planning and prioritization are not present. 

Notification Database 

The Notification Database will store all notification messages with their delivery time, status, etc. This feature is provided by the Content Store of the Notify UK platform. The Content Store is a MongoDB database. 

Event Priority Queues (Event Hub) 

The Event priority Ques forward the received validated high, medium and low priority notifications via the User Selection Service and the Outbound Handler to the Event Hub. The Notify UK platform does not offer an Event Hub. The MVP does not yet require / provide an Event Hub. 

User Selection Service 

The User Selection Service determines the personal preferences of the user on the basis of the personal data provided with a notification, the Digital Accessibility Profile Service and then forwards the notification to the Outbound Handler, which forwards the Notification to the Event hub. 

The Notify UK platform does not provide a User Selection Service. No Accessibility Profile is yet required / provided in the MVPi. 

Digital Accessibility Profile Service 

The Accessibility Profile is the function where a citizen can manage his accessibility and preferences in contact with the government. 

The Notify UK platform does not offer a Digital Accessibility Profile Service. The Digital Reachability Profile is a generic service that is provided in the architecture of the federated messaging system (FBS) and therefore need not be part of the notification facility. 

Outbound Handler Service 

This service will process notification messages that are ready in the Event Priority Ques by polling them based on their priority (highest to lowest). 

The Notify UK platform does not offer an Outbound Handler Service. In the MVP no Outbound Handler is yet required / provided.

event hub 

The Event hub sends the Notification to the different adapters. These adapters will be based on different channels. 

The Notify UK platform does not offer an Event Hub. An Event Hub is not yet required / provided in the MVPi. 

Notification Adapters 

These are the adapters that transform the notifications that the Event hub delivers, and deliver them to the external service providers according to their supported format. 

The MVP provides one Notification Adapter, for the SMS-Gateway (via CM.com). This is not yet provided in the Notify UK platform and must be developed as a custom solution. 

Notification Service Providers 

These are the external service providers, who take care of the actual notification 'transmission'. In the MVP, there is one Service Provider, CM.com for the SMS Gateway. 

Notification Analysis Service 

This service performs analyzes and provides reports with regard to the notifications sent. The Notify UK platform does not offer a separate Notification Analysis Service. This feature is provided by the Notify Admin Dashboard. 

Logging/Tracking Service 

This service continuously reads the priority Event Priority Ques and tracks all sent notifications. The Notify UK platform does not offer a Logging/Tracking Service. No Logging/Tracking Service is yet required / provided in the MVP. 

Authorization Component 

This component takes care of user authorization. 

The Notify UK platform does not offer a separate Authorization Component. This feature is provided as standard by the Notify UK platform. 

Two-factor authentication 

Although not explicitly mentioned in the functional architecture of Chapter 2, Notify uses two-factor authentication (2FA) to keep accounts secure. This feature is provided as standard by the Notify UK platform. 

Conclusion 

Notify UK provides the majority of the functionalities as described in the functional architecture (Chapter 2). Although the functionalities are not available as separate services, Notify UK offers enough foundation to be used as an MVP; this is further elaborated in chapter 5. When it is decided to let the MVP grow into a broader notification service, the additional functionalities that are not yet present in Notify UK can be added to the platform as customization. 

Notify UK has been developed in accordance with UK government guidelines; to determine whether Notify also complies with the standards and guidelines of the Dutch government, the similarities and differences between the Dutch and British guidelines must first be mapped out. This is not expected to be a major matter (see also chapter 3.2). Based on that analysis, Notify can then be further adjusted to comply with the standards and guidelines of the Dutch government. This will also require custom adjustments. 

Similarly, Notify can be adapted/expanded to fit into the landscape of Dutch government-wide building blocks. Consider, for example, the link with DigiD / eHerkenning and future expansions such as Logius FBS.

4 Technical Architecture 

The technical architecture describes the operation of the technical platform and how it is developed for Notify. 

4.1 Choices made with regard to the platform 

During the first phase of Notify (PoC/experiment version as realized by Novum in 2021), it was decided to choose an internal technical platform: a Novum/SVB server with open source products. A solid foundation must be used for the next phase of Notify, the MVP version. This means that the technical platform must be reliable, secure, available and manageable. 

Choice 1: Logius Standard Platform 

For the Notify MVP version, the choice was made to use the Logius Standard Platform (LSP). The LSP is a private cloud environment, set up by Logius (part of the Ministry of the Interior and Kingdom Relations). The aim of the LSP is to offer the government and all its divisions a cloud environment as a Platform as a Service. The LSP has broadly the same function as a Cloud Service Provider. This means that the platform is managed, secure and available according to agreements. 

Choice 2: Container infrastructure 

To be able to land on the LSP, Notify must be set up as an application using containers. A container landscape consists of small, isolated application environments that are easy to deploy and manage. The principle is shown in the figure below. In short, it means that Notify consists of different applications that together perform 1 complete service. The various applications use one container platform, one operating system and one infrastructure. Older / more traditional applications often span multiple VMs and OSes, which can cause inefficiency in terms of clarity, scalability and performance. 

Choice 3: Cloud-native application and infrastructure 

Another condition for using LPS is to set up Notify according to Cloud Native principles. Besides being a condition from Logius, it is also a choice that must be made separately 

 

 

of the technical platform. By building Notify as a Cloud Native application, it can in principle land on any other technical cloud platform. 

The image above shows the components of Cloud Native. The technical infrastructure provides the tooling for all 4 components. The Microservices and Containers parts are more visible, where CI/CD and DevOps are more the method of management. 

The LSP offers GitLab, Harbor and Nexus to run CI/CD and maintain a DevOps way of working. 

Choice 4: Microservice architecture 

This choice (microservice architecture) is closely intertwined with Choice 2 (Containers). Notify's application layer will consist of microservices. High-over means that one service (for example the attachment service) is programmed as one application. 

In a traditionally designed application, all services are often developed as one application. If a service is taken out, the entire application will no longer work. This is not the case with a Microservice architecture: the application will continue to work, even if a microservice has been removed. To build resilient microservices, development should be done according to the Twelve-Factor App methodology. For example, these principles prescribe to treat logging as streams and to keep the build, release and run of a microservice strictly separate and how to run them. 

All microservices land in containers within Docker and are orchestrated through Kubernetes. At high level, a Microservice architecture looks like this: 

4.2 Technical Platform & Tooling 

This section describes the various components that are part of the technical platform (LPS): 

Element	Description
Kubernetes	Kubernetes is a container orchestration platform. All services placed in containers can be managed through Kubernetes.
AWS S3	The cloud object storage solution, which makes the data available via the web.
load balancer	Virtual service for distributing the requests, ie the notification traffic, over the available resources.
Ingress	Ingress is an API that manages remote access of the services on the clusters.
Nexus	Artifact repository required to store and process the software in the build pipelines (GitLab).
Prometheus	Can receive and display tracing, metrics and logging. Prometheus has an integration with Grafana for dashboards.
Kafka	The microservice architecture is event driven. This means that all microservices can be a producer and/or consumer of events. To configure and manage these events, a cloud native event streaming platform is used. Kafka has 3 key capabilities:  publish and subscribe to streams. the microservices use the streams generated by Kafka.  saving the event streams.  processing event streams.
Kibana	Tooling for login, alerts can be added separately.
Git lab	The DevOps platform. All microservices are placed and managed on this.
Harbour	Harbor is used to package the applications for deployment.
Grafana	Dashboards for monitoring metrics, Grafana has a built-in alert module.
Security tooling	From a security point of view, all components are provided with a single type of security. However, it still needs to be considered which security tooling should be added to the platform. One can think of HashiCorp Vault, for example to create and manage secrets.

NB this list may still be amended / supplemented in response to the additional research points mentioned above. 

4.3 Functional elaboration of the tooling 

In the diagram below, the operation of the platform with regard to the functionality is shown globally. The various components of the platform are listed above in section 4.2. All tools are deployed in the enclosed DevOps section: from developing a microservice to the network traffic required to send the notification. 

4.4 Considerations / decisions to be taken 

This section describes some subjects on which decisions / choices still have to be made. The reason for this is that these were discussed during the design phase, but no statement can be made about them at this time. 

Management of the application on the technical infrastructure. The technical infrastructure is managed by Logius: they offer this infrastructure as a PaaS service. This means that Novum/SVB remains responsible for the management of Notify and its technical maintenance. When purchasing a PaaS, for example, a server and the operating system are under the management of Logius. The only thing that is not managed by the PaaS supplier in a PaaS service is the application. In this case it concerns Notify as an application. The image below shows the division between what Logius can manage (orange) and what an application manager manages (blue). 

It is still unknown how this will be implemented. We advise you to make a choice in this at an early stage during the realization of the first version (MVP). If the implementation is realized according to DevOps principles, the development team is not separated from the management / operations team. To make a choice here, the phase to which Notify is moving must be taken into account: 

In case Notify is used directly as a government-wide notification service, it seems logical to have Notify become part of the generic services of Logius. The management of the application would also be the responsibility of Logius. 

If Notify is not initially used as a government-wide notification service, but, for example, only for SVB or a limited number of participating parties, it seems logical to entrust the application management to SVB (or another designated party). In this scenario, it can still be investigated whether Notify can still be invested with Logius in the future. 

Additional security tooling. Despite the fact that various security aspects are covered by the various products and standards used, additional security measures may be desirable. One can think of secrets management (certificates) or the implementation of a specific authorization and authentication structure. 

Advice 

The Logius Standard Platform offers the necessary services and tooling to allow Notify to land on it, based on modern container technology. It is relatively easy to use the Standard Platform; an application to Logius for the use of the PaaS service, or the Logius Standard Platform, is sufficient. See also the conditions that must be met as stated in paragraph 3.10. 

5 Notify NL: Minimum Viable Product 

5.1 What is a Minimum Viable Product? 

“A Minimum Viable Product (MVP) is the first version of a product or service that is rolled out to the customer as early as possible. The goal is to get feedback as quickly as possible. This feedback is important to be able to take the most important next steps.” (source: Agile Scrum Group) 

An MVP is therefore not the same as a Proof of Concept (PoC): a PoC aims to prove that the solution works, but is not rolled out to the customer. The Notify PoC performed by Novum in 2021 is therefore not necessarily suitable for use as an MVP. In this chapter a proposal is made for an MVP version of Notify NL. 

5.2 Overview MVP 

The image below presents a basic overview of the Notify NL architecture, which is based on the Notify UK architecture. The parts shaded in blue are included in the first release (Minimum Viable Product – MVP) of Notify NL. The gray items are options that require further exploration. 

5.3 Scope of the MVP 

The Notify UK platform currently does not contain all the functionalities as recognized in the functional architecture for a government-wide notification facility (Chapter 2). However, Notify does offer enough functionality for a valuable MVP aimed at exploring / validating a government-wide notification facility with informal notifications. Several government parties can then be connected to it as users of the MVP. This MVP can be realized on the basis of the available code from Notify UK, whereby the application lands on the Logius standard platform and CM.com is set up as a service provider for the SMS messages. 

The following components are in scope of the MVP to be realized in this way: 

Components of Notify UK: 

Notify Frontend (web interface for managing templates, sending messages via HTTPS) 

Notify API (REST API for managing templates, sending messages, via REST API) 

Notify Admin (Status overview dashboard, via HTTPS) 

Service Provider for SMS (CM.com)

Collect the user data in the MVP itself, and later connect it to Logius' means of authentication or to the digital accessibility service. 

Have Notify land on the Standard Platform (SP) of Logius. 

The components of Notify are deployed as containers on Kubernetes clusters of the SP. Notify's APIs are accessed via the Logius API Gateway. 

Develop service adapter for connection to service provider CM.com. Develop authentication adapter for connection to DigiD / eHerkenning. 

Explanation: Notify provides the functionalities that are part of the following functional components / services, as described in chapter 2. However, the functionalities are positioned differently in the application architecture. 

• Single notification client 
• Bulk notification client 
• Template Services 
• API integration 
• Central Notification component (with the exception of the validation, prioritization and planning service) o Notification Database 
• Outbound Handler Service 
• Authorization Component 
• Notification Adapter (not provided in Notify, but must be realized in MVP in order to provide communication with CM.com) 
• Two-factor authentication 

5.4 Outside the scope of the MVP 

The following parts are outside the scope of the MVP: 

Notification Adapters / Service Providers other than SMS (email, letter post, Whatsapp, Telegram, push notifications, etc.) 

Federated Authorization (with DigiD and eHerkenning) 

Integration with Message Box 

Various functional components and services from the functional architecture of chapter 2: o Message warehouses * 

Message List Service * 

Event Hub ** 

Event Priority Queues** 

User Selection Service ** 

Digital Accessibility Profile Service * 

Notification Analysis Service ** 

Logging/Tracking Service ** 

* is not provided in Notify-based MVP (and probably not needed for MVP); the relevant components/services are part of the future architecture of the Logius FBS and are recognized as independent services. 

** not provided in Notify UK based MVP (probably not needed for MVP either), but may be added at a later stage.

 

5.5 Difference between the already performed PoC and the MVP 

A comparison between the PoC performed by Novum in 2021 and the MVP mentioned above yields the following differences between PoC and MVP version. The following additions / adjustments are provided in the MVP version: 

Have Notify “land” on the Logius Standard Platform (including compliance with the preconditions set by the LSP, such as containers that are deployed on Kubernetes clusters) Comply with government-wide standards (BIO and AVG) 

Connect to service provider CM.com 

5.6 Conclusion and advice 

The current version of Notify offers a good basis, both functionally and non-functionally, for realizing an MVP aimed at a first version of a government-wide notification service on the Logius Standard Platform. This MVP must then be aimed at notifications about informal messages to citizens from the government. 

However, Notify currently does not yet offer all the functionality that we foresee in a future government-wide notification facility as described in Chapter 2. This means that Notify will have to be expanded further in the future, after the MVP. The most important additional functionalities that are currently being provided are: 

Functionality to connect to the (future) e-government building blocks, such as the federative message box, the digital accessibility profile and means of authentication (such as DigiD); Adapters to connect to other channels (service providers); 

Functionality to make Notify richer and more robust, such as validation, planning and prioritization functionality; 

Functionality for analysis and logging, partly in the context of security and possibly the ability to provide a financial settlement mechanism with participating administrative bodies; 

Functionality for reporting undelivered messages. 

Functionality to serve businesses as well as citizens. 

It has not yet been fully investigated to what extent Notify's current code complies with all applicable guidelines and standards as elaborated in chapter 2. Adjustments to Notify may also have to be made in this context in the future. 

The advice is to draw up an implementation plan for the MVP as a next step. In this implementation plan, the objective of the MVP is further refined (what is the minimum that Novum wants to achieve with the MVP?) and determines whether additional functionality is required in addition to the current functionality. Subsequently, the scope of the work, the planning and a budget indication are determined on the basis of this. 

Although the MVP based on Notify can land on the Logius Standard Platform, and Logius also supports it, it has not (yet) been determined to what extent this application of Notify fits within the planning of Logius and whether it fits in with the functional and architecture (principles) that Logius wants to use. The advice is to investigate this further with Logius. In addition, the advice is to involve Logius closely in the follow-up process.

6 Risks

Risk (description)	Opportunity  (K/M/G)	Impact  (K/M/G)	Measure ter  prevention	Action measure
Logius makes different choices for the development of a government-wide  notification feature.	Medium	Big	Follow-up process  match with  Logic before  it is decided to realize an MVP.	Investigate whether an MVP with Notify might still be useful to gain experience and  possibly temporary as  government-wide facility.  Investigate whether an MVP with notify only for informal notifications in addition to a  notification facility  formal messages may exist
Logius focuses on the development of a notification facility for formal messages.	Big	Middle	Match with  Logic for it  follow-up process  start.	Investigate whether an MVP with notify only for informal notifications in addition to a  notification facility  formal messages may exist
Notify doesn't seem to work  close to yet to be developed government-wide services, such as the  availability service and the services of the  federated messaging system.	Big	Big	Close follow-up  collaboration with Logius.	Adjust Notify if necessary, so that you can connect.
CM.com's contract does not allow notifications for organizations that do not  belong to the  central government.	Big	Big	Investigate if  contract CM it  permits and if not an additional one  conclude a contract	No participants who do not  belong to the national government.
Insufficient knowledge of (the components of) it  Logius Standard Platform available in  development/management team	Medium	Big	Well before the start of development employees with the necessary knowledge and experience  Supplier  select who has that knowledge of	Knowledge anyway  building/attracting to the team members of the development/management team.
Unavailability of the Logius Standard Platform	Small	Big	Agree SLA with Logius	Action by Logius
Unavailability of CM.com	Small	Big	Agree SLA with CM.com	Action by CM.com
Unavailability  notification feature	Small	Big	Ensure  a management team	Action by Solve Group