4 Building Block Architecture

4.1 Architecture Scope

The GovStack Architecture Specification with its Cross-Functional Requirements and other sub-chapter are applicable to what is commonly referred to as system architecture. GovStack differentiates between:

• Government Architecture describes structure, behaviour, and views of the whole of government on governance, legal and digital layers. See more on GovStack's guide on government architecture

• System Architecture describes structure, behaviour, and views of the technology, data and application layer across multiple entities or within one entity of a government. In GovStack, this usually refers to the interaction between multiple Building Blocks, service applications, micro services or other components. The C4 system context diagram or C4 container diagram can be used for visualization.

• Component Architecture describes structure, behaviour, and views of one system component. In GovStack, this usually refers to the inner architecture of one Building Block, service application or micro service. The C4 component view can be used for visualization.

Visualized scope of architecture terms

4.2 Building Block Approach

GovStack aims to provide a reference architecture for digital governance software to support sustainable development goals. Rooted in a "Whole-of-Government" approach, the GovStack Framework provides a methodology for leveraging common technology components ("Building Blocks") and infrastructure to more easily create and deploy interoperable digital platforms which can address high-priority use cases across multiple sectors. The guidelines and requirements described in this document provide a framework for the development of digital building blocks oriented toward this goal.

4.3 Criteria for Building Blocks

The following provide criteria and definitions for Building Blocks, developed by organizations whose work is focused around achievement of the Sustainable Development Goals (SDGs). The criteria are drawn from the SDG Digital Investment Framework, developed by the International Telecommunication Union (ITU) and the Digital Impact Alliance (DIAL), as well as the definition of Building Blocks developed by the Digital Public Goods Alliance (DPGA):

A Building Block:

• Refers to software code, platforms, and applications that are interoperable, provide a basic digital service at scale, and can be reused for multiple use cases and contexts.

• Serves as a component of a larger system or stack, called Digital Service System.

• Can be used to facilitate the delivery of digital public services via functions, which may include registration, scheduling, ID authentication, authorization, payment, data administration, and messaging.

• Building blocks can be combined and adapted to be included as part of a stack of technologies to form a country’s Digital Public Infrastructure (DPI).

• Building blocks may be open source or proprietary and therefore are not always DPGs.

"Building blocks can be as simple as a common set of rules or protocols (for example email programs like Simple Mail Transfer Protocol - SMTP), or complex (for example an open-source health information system like the DPG, District Health Information Software - DHIS2)“

Characteristics of building blocks:

• Autonomous: building blocks provide a standalone, reusable service or set of services, they may be composed of many modules/microservices.

• Generic: building blocks are flexible across use cases and sectors.

• Interoperable: building blocks must be able to combine, connect, and interact with other building blocks.

• Iterative evolvability: building blocks can be improved even while being used as part of solutions.

Per the DPGA definition, to be considered a building block, solutions must meet the following technical requirements determined by the GovStack Initiative which includes:

1. Open API, Open API Specifications, Rest API

2. Packaged in a container

3. Include a information mediator where communication flows between services that are not co-located

4.4 Building Block Layers

Building blocks are software modules that can be deployed and combined in a standardized manner. Each building block is capable of working independently, but they can be combined to do much more:

Building blocks are composable, interoperable software modules that can be used across a variety of use cases. They are standards-based, open source and designed for scale.

Each Building Block represents, as much as possible, the minimum required functionality (MVP) to do its job. This ensures each Building Block is usable and useful on its own, and easily extensible to support a variety of use cases.

A Building Block is composed of domain-driven microservices, modeled as closely as possible on existing roles and processes. This helps ensure each building block is as useful as possible in the real world.

Building Blocks exchange data using lightweight, human-readable data that can easily be extended where needed. Data models and APIs are described in a lightweight manner that’s human-readable, allowing them to be easily and quickly understood and validated.

4.5 Cross-Building Block Communication

A building block is only so useful on its own. In practice, building blocks MUST be connected together in a secure, robust, trusted manner that facilitates distributed deployments and communications with existing services.

It is STRONGLY RECOMMENDED that a building block uses an information mediator (essentially a data exchange platform as described below and in the Information Mediator Building Block specification) for any communications across the internet. An Information Mediator is not required for communication between building blocks which are co-located. In this case, communication may occur using standard API calls.

5.5.1 Federation and Data Exchange Requirements

Each building block deployment SHOULD use an Information Mediator to federate and communicate with other data consumers and providers, particularly when communicating between services that are not co-located. This ensures the confidentiality, integrity, and interoperability between data exchange parties. An Information Mediator MUST provide the following capabilities:

• address management

• message routing

• access rights management

• organization-level authentication

• machine-level authentication

• transport-level encryption

• time-stamping

• digital signature of messages

• logging

• error reporting

• monitoring and alerting

• service registry and discovery

Refer to the full description of the Information Mediator Building Block for more information.

4.5.2 Organizational Model

In order to effectively deploy a software solution using the Information Mediator, several policies and processes will need to be applied. This section briefly describes that organizational processes that must be in place.

First, a central operator will be identified and created. This organization will be responsible for the overall operation of the instance of the GovStack ecosystem, including operations and onboarding new members. Policies and contractual agreements for onboarding need to be created.

Next, trust services need to be set up internally or procured from third parties, including timestamp and certificate authorities. This provides the necessary infrastructure to support distributed deployments.

Finally, members can be onboarded and provided with access to the Information Mediator and methods to register the services that they provide as well as discover services that are available.

Once agreements are in place, members can deploy new services in a decentralized, distributed manner.

4.5.3 Technical Architecture

This section provides an overview of the technical processes and architecture that must be implemented once the organizational model has been created.

1. A Central Operator is responsible for maintaining a registry of members, a list of trusted certification authorities and a list of trusted time-stamping authorities. The member registry MUST be exposed to the Information Mediator.

2. Certificate authorities are responsible for issuing and revoking certificates used for securing and ensuring the integrity of federated information systems. Certificate authorities MUST support the Online Certificate Status Protocol (OCSP) so that an Information Mediator can check certificate validity.

3. Time-stamping authorities securely facilitate time stamping of messages and logs. Time stamping authorities MUST support batched time stamping.

4. The Service Registry provides a mechanism for building blocks to register the services that they provide and for other building blocks to discover and consume those services. Any services provided or consumed by a Building Block that leverages the Information Mediator architecture MUST use this service registry functionality.

4.6 Architecture components

In the GovStack system architecture, there are several different types of components. This chapter provides a definition of these various components as well as detailing which components are domain-generic (may be used for multiple government e-services) and which are domain-specific to a particular government service.

Visualisation of common components in a GovStack system architecture

4.6.1 Domain Dependent

The following components are dependent on a specific domain (see also "domain-driven design") or a specific government service.

• Service Application Frontend. For a particular government service, a user interface will be implemented to provide necessary information to the user and collect any needed information from the user.

• Service Application Backend. For a particular government service, the application backend will manage the flow and business logic needed. The backend will access any local data and make calls to GovStack Building Blocks as needed.

• Repositories. An application may have a local repository that contains data that is specific for that use case.

• Building Block Emulator. This component might be used in prototyping or testing environment to emulate the behaviour of a Building Block. It is a simple/lightweight implementation of a Building Block to provide the needed functionality for a particular government e-service.

4.6.2 Domain Agnostic

The following components are not dependent on a specific domain. They are generic across multiple government services.

• Organisational Subsystem. A single purpose system providing digital government service consisting of one or multiple application, Building Blocks, microservice or other components.

• Building Block Software. See 4.2 Building Block Approach

• Non-Building Block Software. Any (legacy) software providing API-based functionalities. May be conformance with Cross-Functional Requirements but does not match the functional scope of a Building Block.

• Security Server. Component of Information Mediator, see Information Mediator Building Block

• Adaptor. The adaptor provides a mapping from an existing software platform’s API to the format that is specified by the GovStack BB spec for a particular Building Block, see 7.5 Onboarding Products

• Repositories. As noted, some repositories may contain use-case specific data. However, there may also be repositories that are needed by multiple applications or use cases.

4.7 Architecture example

The following diagram provides an example of a GovStack implementation

This digram shows an example of what a GovStack implementation may look like in practice. Several concepts that are important to GovStack are shown in this diagram:

• A GovStack implementation may consist of multiple ‘applications’, each serving a distinct purpose. The value that GovStack provides is that these applications do not have to be developed from scratch, but rather leverage core functionalities that are provided by various Building Blocks. And these Building Blocks may be used in multiple Digital Service Systems.

• Digital Service Systems may access outside services through the Information Mediator. Access to these services are configured within the Information Mediator per organization. One application may have permission to access data provided by a particular ministry that another application may not access.

• A GovStack application can be used by different types of users. The roles and permissions for various user groups must be managed by the application itself (using authorization services described here)

• Building Blocks may be based on existing applications or Digital Public Goods (DPGs). These DPGs may have an API that conforms with the GovStack API specification for that Building Block. If not, an adaptor can be used to map the existing API to the GovStack API

• The Service Application frontend and backend may use any mechanism to communicate (REST, GraphQL, etc). However, all GovStack API calls should be done using standard REST protocols.