Architecture Blueprint and Non-Functional Requirements

Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

Page: 2, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

Note: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD","SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in thisdocument are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and onlywhen, they appear in all capitals, as shown here.

1. Introduction1.1 Considerations for low-resource settings1.2 User-centered design1.3 SDG digital framework criteria1.4 What are building blocks?1.5 How do building blocks work together?

1.5.1 Federation and data exchange requirements1.5.2 Organizational model1.5.3 Technical architecture1.5.4 Support for rooms

2. Building Block Design Principles2.1 Citizen-Centric2.2 Open2.3 Sustainable2.4 Secure2.5 Accessible2.6 Flexible2.7 Robust

3. Cross-cutting requirements3.1 Synchronous APIs MUST return an API response within3.2 MUST follow TM Forum Specification REST API Design Guidelines Part 13.3 SHOULD follow TM Forum Specification REST API Design Guidelines Parts 2-73.4 EOL MUST be at least 5 years3.5MUST only use TIOBE top 25 languages3.6 MUST use API-only based decoupling3.7 SHOULD follow the Amazon API Mandate:3.8 APIs MUST be idempotent3.9 Stateless APIs SHOULD be used wherever possible to enhance scalability3.10 Regular security and code quality audits MUST be run3.11 MUST include integration test coverage3.12 MUST include support for a log sink3.13 Data models MUST include version numbers

Page: 3, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.14 APIs MUST be versioned3.15 API calls MUST include transaction/trace/correlation IDs3.16 MUST use semantic versioning3.17 No configuration in code, only through the environment3.18 MUST Include clearly defined key rotation policies3.19 Documentation MUST be generated from code and/or checked in alongside sourcecode3.20 MUST not use shared database/filesystem/memory3.21 Databases MUST not include business logic3.22 MUST enforce transport security3.23 MUST only use Unicode for text3.24 MUST use ISO8601/UTC for timestamps3.25 MUST follow REST design principles3.26 MUST be asynchronous first3.27 MUST support both SAAS and do-it-yourself3.28 MUST be autonomous3.29 MUST be open-source only with no vendor lock-in3.30 MUST be Cloud native3.31 MUST closely model the organization/roles being automated3.32 MUST use standardized configuration3.33 MUST use standardized data formats for interchange3.34 MUST use existing standards for data interchange, where available3.35 I/O sanitization MUST be used3.36 MUST include machine-readable API descriptions3.37 MUST provide a compliance test kit3.38 MUST use web hooks for callbacks3.39 MUST be internationalizable3.40 MUST follow best practices for public code

3.40.1 Code in the open3.40.2 Bundle policy and source code3.40.3 Create reusable and portable code3.40.4 Welcome contributions3.40.5 Maintain version control3.40.6 Require review of contributions3.40.7 Document your objectives3.40.8 Document your code3.40.9 Use plain English3.40.10 Use open standards3.40.11 Use continuous integration

Page: 4, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.40.12 Publish with an open license3.40.13 Use a coherent style3.40.14 Pay attention to codebase maturity

4. Standards4.1 Unicode4.2 ISO8601/UTC4.3 JSON4.4 JSON Schema4.5 REST4.6 OpenAPI (AKA swagger)4.7 Docker

5. Terminology

6. Recommendations

7. To Do

8. Key Decision Log

Page: 5, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

1. IntroductionGovStack aims to provide a reference architecture for digital governance software tosupport sustainable development goals.

This will accelerate the collaborative development of best-of-breed digital public goods,enhancing efficiency and transparency across the world - especially in low-resourcesettings.

Once an initial reference architecture is available, it can be deployed in a sandboxenvironment to demonstrate its utility.

1.1 Considerations for low-resource settingsLow-resource settings have unique constraints that must be considered.

Here is a list of indicators with high-level descriptions:Indicator Description

ICT Governance Poor or non-existent National ICT governance structure that makesdecisions and ensures accountability framework to encouragedesirable behavior in the use of ICT in the country. However, this maybe described in documents but the implementation is suboptimal ornot enforced.

Government ICT policy orFramework

No strategic policy framework for the acquisition and use of IT forsocial and economic growth in the country. The policy might be at thedevelopment stage and where the policy exists, the policyimplementation is lagging or non-existent.

ICT infrastructure The development of IT infrastructure in the country is lagging behindor sub optimal because of poor policies and insufficient investments inthe ICT sector. Low coverage of power or the national grid and littlepenetration of alternative sources of energy especially in the rural.

Financial Resources andInvestments in ICT

Limited funding for ICT projects and initiatives. ICT intervention maynot be prioritized. No institutionalized or routinized support for ICTprojects/ interventions by the government.

ICT projects/ Initiatives ICT projects and intervention are implemented in a silo, none standardapproaches and most of the ICT interventions are proprietary and highcost ventures from private institutions. No national standardarchitecture for interoperability/ integration of systems

Capacity developmentand social instruments

Low ICT literacy level among user, None or little research anddevelopment done by the national institutions/ academia on the useand scale up ICT in the country. Very few ICT professionals to supportlarge scale ICT projects at national level

Connectivity/ Internetaccess

Lack of or minimum network coverage by GSM and or broadbandtechnologies. Low cellular subscribers per capita and very lowinternet subscribers per capita. The percentage fibre connectivity inthe country is low. A greater percentage of the population do not havecomputers, laptops or smart phones.

Page: 6, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional RequirementsAccess to information Number of household with internet connectivity is concentrated in the

urban areas as opposed to rural areas.Cost competitiveness Technologies, which are not always ready-for market, are often more

expensive than incumbent technologies, without the necessarysupportive infrastructure. Competition from existing technologies,including unsustainable technologies

Knowledge and skills New technologies require specialized knowledge and skills, which areoften lacking in host countries where education levels in science,engineering and technology can be low, and emerging areas. ICTspecialists is low

Social Legitimacy New technologies treated with suspicion in local communitiesespecially if prior experience of job losses or unintended socialconsequences

Cultural barriers New technologies are seen as a challenge to cultural traditions andcommunal activities. Technology can also face barriers such aslanguage, role of women in the society, lack of entrepreneurs ordependencies created by decades of development aid

https://docs.google.com/document/d/1r-rKhtFfCVE7MLNhbK6TdmtJT71NaPdo/edit

Additionally, the Principles for Digital Development are especially relevant when designingfor low resource setting: https://digitalprinciples.org/

We’ve seen the many benefits digitalization of governance can bring. We believe thedemocratization of key technologies can help accelerate this process around the world.

Given these constraints, how can we best reach Sustainable Development Goals?

1.2 User-centered designThe best tools evolve from empathizing, understanding and designing for the needs ofend-users. Accordingly, we’ve identified a series of use cases and user journeys here:InfoMed - RFIMPL_Use Case Journeys.docx

Each use case is composed of a collection of modules, or building blocks. As you can see, arelatively small set of these building blocks can be readily applied to a wide variety ofapplications in low-resource settings.

1.3 SDG digital framework criteriaThe SDG digital framework has formally defined criteria. Building blocks MUST meet thefollowing criteria:

● Reusable software components● Licensed as open source, proprietary, or freely available with Open Access to data● Facilitates one or more generic Workflows

Page: 7, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements● Applicable to multiple SDG Use Cases across multiple sectors● Interoperable with other ICT Building Blocks● Designed for Scalability● Designed for Extensibility● Standards Based Conformance or Compliance

Seehttps://drive.google.com/file/d/1Ix2A3W_vpvaRvKyek524kCuB5MKcRFd3/view?usp=sharing for details, including a checklist.

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

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

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

A block is composed of domain-driven microservices, modeled as closely as possible onexisting human roles and processes. This helps ensure each block is as useful as possible inthe real world, per Conway’s law.

Page: 8, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

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

Building blocks should meet the criteria of the Digital Square Global Goods maturity modelfor Global Utility, Community and Software Quality. Seehttps://www.google.com/url?q=https://wiki.digitalsquare.io/index.php/Global_Goods_Maturity&sa=D&source=editors&ust=1614177377366000&usg=AOvVaw3rKLBBw5qDajPOetkDdmTvfor details.

1.5 How do building blocks work together?A building block is only so useful on its own. In practice, building blocks MUST beconnected together in a secure, robust, trusted manner that facilitates distributeddeployments and communications with existing services.

1.5.1 Federation and data exchange requirementsEach building block deployment MUST use a security server to federate and communicatewith other data consumers and providers. This ensures the confidentiality, integrity, andinteroperability between data exchange parties. A security server MUST provide thefollowing 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 handling● monitoring and alerting

1.5.2 Organizational modelSome policies and processes need to be applied to support this methodology.

First, a central operator needs to be created. This organization will be responsible for theoverall operation of the system, including operations and onboarding new members.Policies and contractual agreements for onboarding need to be created.Page: 9, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

Trust services need to be set up internally or procured from third parties, includingtimestamp and certificate authorities. This provides the necessary infrastructure to supportdistributed deployments.

Finally, members can be onboarded and provided with access to the security server.

Once agreements are in place, members can deploy new services in a decentralized,distributed manner. Before deploying a new service, the central operator must be notified ofany changes to access-rights, including organization and machine-level authenticationbefore it can publish or consume data.

1.5.3 Technical architectureA Central Operator is responsible for maintaining a registry of members, the security policiesfor building blocks and other member instances, a list of trusted certification authorities anda list of trusted time-stamping authorities. The member registry and security policies MUSTbe exposed to security servers over HTTP.

Certificate authorities are responsible for issuing and revoking certificates used for securingand ensuring the integrity of federated information systems. Certificate authorities MUSTsupport the Online Certificate Status Protocol (OCSP) so security servers can checkcertificate validity.

Time-stamping authorities securely facilitate time stamping of messages. Time stampingauthorities MUST support batched time stamping.

Security servers MUST be used by members to publish or consume data and services.Building blocks and existing information services that use REST MUST work seamlessly withthe security server.

1.5.4 Support for roomsIdeally, publish/subscribe SHOULD allow blocks to be connected together in rooms tocollaboratively solve problems. Once available, blocks should support rooms, e.g.

● everything is connected through a room● requests are made in the room● blocks process data● answer(s) are posted to the room

Page: 10, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

2. Building Block Design Principles

2.1 Citizen-CentricRight to be forgotten: everything must be deletable

2.2 OpenBased on open standards

Based on Digital Development Principles, see https://digitalprinciples.org/ andhttps://digitalinvestmentprinciples.org/

Built on open-source software (where possible)

Supports open development, see https://standard.publiccode.net/

No vendor lock-in

Cloud native (Docker and Kubernetes)

Code is openly developed and available to anyone, via Github or Gitlab

2.3 SustainableStewardship is critical, see https://publiccode.net/codebase-stewardship/

Continuous funding for maintenance, development and evolution

Attractive to ICT industry and individual developers in deployment environment (incentivesmust be aligned)

Lower cost than commercial solutions due to shared development costs

Uses microservices-based architecture instead of monolithic.

This increases interoperability, development and deployment speed and reliability.

From Wikipedia: a variant of the service-oriented architecture (SOA) structural style –arranges an application as a collection of loosely coupled services. In a microservicesarchitecture, services are fine-grained and the protocols are lightweight.

Page: 11, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements2.4 Secure

Blocks are audited and certified before being made available

Development processes and standards enforce quality and security

Different certification levels reflect level of standards-compliance

Regular security scanning and auditing

Public ratings and reviews

Comprehensive logging and exception handling

2.5 AccessibleMeets users where they are: web, mobile, SMS and/or voice

SSO allows for signing in once for multiple services

Shared ownership of code

Deployment and development processes and standards are open to contributors

Community-driven development tools for documentation and support

Blueprints, templates and documentation

2.6 FlexibleBlocks can be reused in multiple contexts

Each block is autonomousBlocks are interoperableEasy to set up

Standardized configuration and communications protocols connecting blocks

Blocks can be provided as a service (ICT opportunity)

2.7 RobustOperates in low-resource environments:

Page: 12, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional RequirementsOccasional power

Low bandwidth

Low-reliability connectivity

Easily scalable for high availability and reliability

API-only based decouplingAsynchronous communications pattern decoupled through rooms is idealEventual consistency for data

3. Cross-cutting requirements

3.1 Synchronous APIs MUST return an API response within

3.2 MUST follow TM Forum Specification REST API DesignGuidelines Part 1

https://drive.google.com/file/d/1lpl1IzLGzvbXALW4jqDxLAKqfwuJyeXy/view?usp=sharing

3.3 SHOULD follow TM Forum Specification REST APIDesign Guidelines Parts 2-7

https://drive.google.com/drive/u/2/folders/1eS20wt_PP7CoJEOvzagYDTTMCfmv3y6l

3.4 EOL MUST be at least 5 yearsNothing SHALL be used in a block that has an EOL of less than 5 years.

3.5MUST only use TIOBE top 25 languagesSee https://www.tiobe.com/tiobe-index/

Page: 13, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.6 MUST use API-only based decoupling

3.7 SHOULD follow the Amazon API Mandate:https://api-university.com/blog/the-api-mandate/1) All teams will henceforth expose their data and functionality through service

interfaces.2) Teams must communicate with each other through these interfaces.3) There will be no other form of interprocess communication allowed: no direct

linking, no direct reads of another team’s data store, no shared-memory model, noback-doors whatsoever. The only communication allowed is via service interface calls overthe network.

4) It doesn’t matter what technology is used [ed: internally]. HTTP, Corba, Pubsub,custom protocols — doesn’t matter.

5) All service interfaces, without exception, must be designed from the ground up tobe externalizable. That is to say, the team must plan and design to be able to expose theinterface to developers in the outside world. No exceptions.

6) Anyone who doesn’t do this will be fired.

3.8 APIs MUST be idempotent

3.9 Stateless APIs SHOULD be used wherever possible toenhance scalability

3.10 Regular security and code quality audits MUST be runacross the code base and dependencies, e.g. https://www.sonarqube.org/ and/or

https://snyk.io/

Page: 14, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.11 MUST include integration test coverage

3.12 MUST include support for a log sink

3.13 Data models MUST include version numbers

3.14 APIs MUST be versionede.g. /api/v1 and /api/v2

3.15 API calls MUST include transaction/trace/correlationIDs

3.16 MUST use semantic versioningSee https://semver.org/

3.17 No configuration in code, only through theenvironment

e.g. environment variables only

3.18 MUST Include clearly defined key rotation policiesSome blocks may require the use of security keys. Those that do must have

clearly defined key rotation policies to enhance security.

3.19 Documentation MUST be generated from codeand/or checked in alongside source code

3.20 MUST not use shared database/filesystem/memoryinterconnection uses APIs only

3.21 Databases MUST not include business logicThis means no triggers/stored procedures shall be used.

Page: 15, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.22 MUST enforce transport security

HTTPS with TLS 1.3 and insecure cyphers disabled

3.23 MUST only use Unicode for text

3.24 MUST use ISO8601/UTC for timestamps

3.25 MUST follow REST design principlesMUST not include PII/session keys in URLs - use POST or other methods for

thisMUST support caching/retries

Resource identification in requestsIndividual resources are identified in requests, for example using URIsin RESTful Web services. The resources themselves are conceptuallyseparate from the representations that are returned to the client. Forexample, the server could send data from its database as HTML, XMLor as JSON—none of which are the server's internal representation.

Resource manipulation through representationsWhen a client holds a representation of a resource, including anymetadata attached, it has enough information to modify or delete theresource's state.

Self-descriptive messagesEach message includes enough information to describe how toprocess the message. For example, which parser to invoke can bespecified by a media type.[3]

See https://en.wikipedia.org/wiki/Representational_state_transfer for more

3.26 MUST be asynchronous firstSupports occasional connectivity/low bandwidth

3.27 MUST support both SAAS and do-it-yourselfMany new governments prefer cloud-based deploymentsSAAS is preferred to make it easy for companies to provide new servicesAnyone should be able to test/deploy building blocks by themselves

Page: 16, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.28 MUST be autonomous

Each block must be capable of running independently

3.29 MUST be open-source only with no vendor lock-inEach block must be composed of open-source software unless there are no

alternatives

3.30 MUST be Cloud nativeEach block MUST be ready to be deployed as independent Docker images, with

complete source code and build instructions committed to GitHubA block may be composed with Kubernetes or docker compose. All build files must

be included alongside the source code.

3.31 MUST closely model the organization/roles beingautomated

See https://en.wikipedia.org/wiki/Conway%27s_law

3.32 MUST use standardized configurationConfiguration MUST only happen through environment variables or secretsAllows visual construction of blocks, perhaps with domain modeling tools

3.33 MUST use standardized data formats for interchangeJSON is used for data models/services.https://www.json.org/json-en.html

3.34 MUST use existing standards for data interchange,where available

If an existing standard is available, it should be used, e.g. DICOM/Hl7 forhealthcare. TMForum has a large library of standardized APIs and data models that can beused.

Page: 17, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.35 I/O sanitization MUST be used

e.g. https://json-schema.org/ for JSON data.Follows Postel’s law: be liberal in what you consume but strict in what you emit

3.36 MUST include machine-readable API descriptionsEach block’s service APIs are defined using a standardized machine-readable

language. External APIs are described using the OpenAPI 3.0 specification for APIshttps://swagger.io/docs/specification/about/

3.37 MUST provide a compliance test kitMust provide a runnable https://www.postman.com/ to ensure compliance toPart of building block design

3.38 MUST use web hooks for callbacks

3.39 MUST be internationalizable

3.40 MUST follow best practices for public codeSee https://standard.publiccode.net/

Page: 18, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements3.40.1 Code in the open

3.40.2 Bundle policy and source code

3.40.3 Create reusable and portable code

3.40.4 Welcome contributions

3.40.5 Maintain version control

3.40.6 Require review of contributions

3.40.7 Document your objectives

3.40.8 Document your code

3.40.9 Use plain English

3.40.10 Use open standards

3.40.11 Use continuous integration

3.40.12 Publish with an open license

3.40.13 Use a coherent style

3.40.14 Pay attention to codebase maturity

4. Standards

4.1 UnicodeUsed for encoding texthttps://en.wikipedia.org/wiki/Unicode

Page: 19, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements4.2 ISO8601/UTC

Used for dates and timestampshttps://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_(UTC)

4.3 JSONUsed for exchanging datahttps://www.json.org/json-en.html

4.4 JSON SchemaUsed for specifying data models. Note that OpenAPI 3.1 has full support for JSON

Schemahttp://json-schema.org/

4.5 RESTUsed for implementing APIshttps://en.wikipedia.org/wiki/Representational_state_transfer

4.6 OpenAPI (AKA swagger)Used for specifying and documenting APIs.https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.1.0.

mdNote that OpenAPI 3.1 supports inline JSONSchema for model definitions

4.7 DockerUsed for packaging building block components for deploymenthttps://en.wikipedia.org/wiki/Docker_(software)https://www.docker.com/resources/what-container

5. Terminology

Page: 20, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia

Architecture Blueprint and Nonfunctional Requirements

6. RecommendationsSingle source of truth/once onlyDefense in depthMark as deleted instead of actual deletion/transaction logging

7. To DoDesign UX blocksDesign log sink blockDesign community driven development blocksDesign block marketplace/repository (the hive)Design event/streaming API designProvide building block templates

Ideally, we can provide a starter template block developers can build onShow how it can be used based on where governments are today vs. tomorrow

8. Key Decision Log

1. 2021-09-23: Added Key Decision Log, published version 1.0.1

Page: 21, Version 1.0.1, Dated: 23th September 2021Developed by: Max Carlson, Kristo Vaher, Steve Conrad and Dr. RamkumarPermachanahalli in cooperation with GIZ, ITU DIAL, and the Government of Estonia