# 4.5 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.5.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](https://dial.global/research/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](https://digitalpublicgoods.net/DPI-DPG-BB-Definitions.pdf) 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.5.2 Categories of Building Blocks
**Foundational building blocks** serve as universal dependencies for the rest of the digital government ecosystem. Digital identity, the information-mediator for data exchange, workflow orchestration are in this category, because almost every other component relies on them to authenticate users, move data, coordinate steps, or store authoritative records. Registry is also considered a foundational specification, albeit for different reasons: it is foundational as a lot of services would depend on registry building block specification based solutions.
Current foundational building blocks:
* **Digital Identity**
* **Information Mediator**
* **Workflow**
* **Registry** (not due to dependency, but potential for very high re-use and assuring visual and functional consistencies for data sources and management)
* *Cloud/infrastructure specification and UI/UX may be considered foundational for simnilar reasons, but are treated as Feature until their use increases.*
**Feature building blocks** provide stand-alone functions - payments, messaging gateways, geospatial services, document generation, and similar modules - that improve the stack without being prerequisites for all others. They integrate through the foundational layer but remain replaceable or optional, letting countries choose what fits their context without breaking overall interoperability.
> *In terms of content, all Building Blocks and specifications are equal, however some building blocks have a larger use or dependencies that affect interoperability of the whole ecosystem, thus they are treated differently in terms of governance and priorities.*
#### 4.5.3 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](https://govstack.gitbook.io/bb-information-mediation)) 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:
Building Block based Service data exchange interoperability model using Information Mediator BB
#### 4.5.4 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 ](https://govstack.gitbook.io/bb-information-mediation)for more information.
#### 4.5.5 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.
* **Building Blocks adapted for a domain context** (such as Registry turned into Population Registry)
**Domain Agnostic**
The following components are *not* dependent on a specific domain. They are generic across multiple government services.
* **Information Mediator Security Server(s) in front of Digital Service System.** Security Server is a component of Information Mediator BB through which access is provided to a single purpose system providing digital government service consisting of one or multiple applications, Building Blocks, microservice or other components.
* (Generic) **Building Block Software** that is not adapted to a specific domain or can be reused in multiple domains.
* **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.
* **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.
* **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.5.6 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.
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://specs.govstack.global/architecture/4-interoperability-architecture/4.5-building-block-approach.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.