5 Cross-Cutting Requirements
Building blocks are responsible for meeting all cross-cutting requirements or specifying why specific requirements do not apply. Govstack compliance and certification processes will validate these requirements.
Nothing SHALL be used in a block that has an EOL of less than 5 years.
- 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, no back-doors whatsoever. The only communication allowed is via service interface calls over the 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 to be externalizable. That is to say, the team must plan and design to be able to expose the interface to developers in the outside world. No exceptions.
- 6.Anyone who doesn’t do this will be fired. Is this enforcable?
Paraphrased from Wikipedia: APIs can be called multiple times without changing the result beyond the initial application.
Thse should be run across the code base and dependencies, e.g. https://www.sonarqube.org/ and/or https://snyk.io/ .
As shown here: e.g. /api/v1 and /api/v2
No configuration in code, use environment variables wherever possible
Some blocks may require the use of security keys. Those that do must have clearly defined key rotation policies to enhance security
interconnection uses APIs only
This means no triggers/stored procedures shall be used.
HTTPS with TLS 1.3 and insecure cyphers disabled.
MUST not include PII/session keys in URLs - use POST or other methods for this
MUST support caching/retries
- Resource identification in requests Individual resources are identified in requests, for example using URIs in RESTful Web services. The resources themselves are conceptually separate from the representations that are returned to the client. For example, the server could send data from its database as HTML, XML or as JSON—none of which are the server's internal representation.
- Resource manipulation through representations When a client holds a representation of a resource, including any metadata attached, it has enough information to modify or delete the resource's state.
- Self-descriptive messages Each message includes enough information to describe how to process the message. For example, which parser to invoke can be specified by a media type.
- When entities change, they publish events, allowing loosely-coupled solutions to be assembled without changing existing APIs. Supports occasional connectivity/low bandwidth
- Many new governments prefer cloud-based deployments
- SAAS is preferred to make it easy for companies to provide new services
- Anyone should be able to test/deploy building blocks by themselves
Each block must be capable of running independently.
Each block must be composed of open-source software unless there are no alternatives.
- Each block MUST be ready to be deployed as independent Docker images, with complete source code and build instructions committed to GitHub.
- A block may be composed with Kubernetes or docker compose. All build files must be included alongside the source code.
- Configuration MUST only happen through environment variables or secrets
- Allows visual construction of blocks, perhaps with domain modeling tools
If an existing standard is available, it should be used, e.g. DICOM/Hl7/FHIR for healthcare. TMForum has a large library of standardized APIs and data models that can be used.
- Follows Postel’s law: be liberal in what you consume but strict in what you emit
- Each block’s service APIs are defined using a standardized machine-readable language. External APIs are described using the OpenAPI 3.0 specification for APIs: https://swagger.io/docs/specification/about/
Part of building block design
- Each block MUST be ready to be deployed as independent Docker images, with complete source code and build instructions committed to GitHub
- A block may be composed with Kubernetes or docker compose. All build files must be included alongside the source code.
In addition to Docker Compose for more efficient and scalable deployments. This will make individual components of the building block independently scalable and make building blocks less monolithic and more efficient,
Include the right to be forgotten account deletion), privacy requirements to protect the rights of individuals, etc. Note that these requirements may vary by region.
Building blocks and building block solutions MUST leverage existing standards, especially those listed in the Standards section below.
Last modified 9mo ago