Building Block Specs Value Proposition

Owned by Nico Lueck
Dec 12, 2024
2 min read

Value Propositions

Governments, the priority users of GovSpecs, shall be able to improve the following:

  1. Planing of a system architecture and its software components

  2. Scoping and gathering of functional requirements of software components

  3. Standardizing interface requirements to improve interoperability

These value propositions are especially true if scope of software component = scope of GovStack Building Block

For value proposition 1, GovStack offers in its specifications the “Architecture and Nonfunctional Requirements” for overall system architecture planning as well as for each Building Block a high-level “Description” to identify the software components which scope resembles GovStack Building Blocks.

For value proposition 2, GovStack offers in its specifications “Key Digital Functionalities”, “Functional Requirements”, “Data Structures” and individually additional chapters to define the functional scope of a Building Block in a planned system architecture.

For value proposition 3, GovStack offers in its specifications architectural “cross-cutting requirements” as well as “Service API” to improve technical interoperability between software components and Building Blocks.

Business Side in Value Generation (= in Specs Development)

The above mentioned value propositions are generated by the working groups who derive technical specifications from business requirements:

  1. Use Cases (e.g. use cases from partner countries or https://govstack.gitbook.io/use-cases )

  2. Common Practice Policies (e.g. EU or Indian ID Policies)

  3. https://www.un.org/en/about-us/universal-declaration-of-human-rights and https://www.dpi-safeguards.org/

The commonalities (or lowest common denominator) of these business dimensions shall be taken.

These common business requirements inform the 1) technical requirements and 2) its requirement status/priority:

  • REQUIRED = Minimum Viable Product (can serve citizens with the minimal functionalities)

  • RECOMMENDED = Recommended functional scope

  • OPTIONAL = (Packages of) requirements which are unique to specific business requirements (which a country might not strive to, e.g. for complying to eIDAS trust level 3)

To be added with agreements from architecture WG 11.11.2024

Software provider side in value generation (= in Specs Development)

The above mentioned value propositions are only valid with actual software applications fulfilling the functional scope of Building Blocks. In addition, the value propositions are improved by software applications not fulfilling the functional scope but by being ready for integration.

  1. Building Block Software

  2. Integration-ready software

The affiliation to one of the categories above is measured in GovStack as “compliance”. For definition of the term, see https://pubs.opengroup.org/togaf-standard/ea-capability-and-governance/chap06.html

For Building Block software, the compliance is measured against the individually listed requirements and its priority/status. The REQUIRED scope of a Building Block Specification MUST at least be fulfilled by 2 different software applications on the market.

For integration-ready software, the compliance is measured against the [to be defined] These are software components which are not matching the REQUIRED scope of Building Blocks. Often times, they are sector-specific (monolithic) software components for which the software providers would like to state a readiness to be integrated on the edges of a GovStack architecture.