4.4 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 provide a framework for the development of digital building blocks oriented toward this goal.
4.4.1 Criteria for Building Blocks
The following provides criteria and definitions for Building Blocks.
The criterias were originally based on 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. This system follows one or a mix of multiple architectural patterns.
Can be used to facilitate the delivery of digital public services via functions, may include registration, scheduling, ID authentication, authorization, payment, data administration, messaging and many others.
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:
While the following are an abstract summary of what the further cross-functional requirements aim to achieve when applied to Building Blocks:
Autonomous: building blocks provide a standalone, reusable service or set of services, they may be composed of many components/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.
To be considered a building block, solutions must be compliant against GovStack Cross-Functional Requirements.
4.4.2 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 can be composed of other technical components (including modern domain-driven microservices), modeled as closely as possible on the existing roles and processes (to reduce friction from Conway's Law). This helps ensure each building block is as useful as possible in the real world.
Conway's law describes the link between communication structure of organizations and the systems they design:
"Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations."
It is named after the computer scientist and programmer Melvin Conway.
Data Exchange and Information Mediator
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.
Based on Architecture Patterns above, GovStack advocates a sustainable use of Semi-Decentralized Service Oriented Architecture and Fully Decentralized Event Driven Microservice Architecture. This means that the architecture is decentalized and data exchange interoperability is achieved over the use of an Information Mediator (Building Block).
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.
The following diagram illustrates the data exchange interoperability based on the mature digital government ecosystem example of Estonia (pattern of Semi-Decentralized Service Oriented Architecture), transferred to GovStack context:
4.4.3 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.4.4 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.
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.
Domain Agnostic
The following components are not dependent on a specific domain. They are generic across multiple government services.
Digital Service System. A single purpose system providing digital government service consisting of one or multiple application, Building Blocks, microservice or other components.
Building Block Software.
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.
Adaptor. The optional 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.
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.4.5 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.
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 optional 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.
Last updated
Was this helpful?