In this chapter
1.1 What this dossier is for
An architecture dossier must help leaders decide what the organization is building, which responsibilities it must retain and what evidence would justify investment. A list of technologies cannot answer those questions. ZAF connects purpose, capabilities, operating constraints and engineering decisions in a record that can be challenged and revised. This public edition is a reference method with a fictional institutional example. It is not a client blueprint, a certification, an implementation claim or a substitute for the institution’s authority. The example is a regional service institution with a headquarters, six offices and an assumed two-person engineering team. Its first scope is operational requests and consolidated reporting; payments, national identity and nationwide deployment are excluded.
1.2 The promise to protect
For the selected workflow, an accepted request must have an identifiable origin, an authorized decision, a traceable version and a recoverable outcome. “Accepted” means acknowledged by the authoritative service, not merely stored on a disconnected device. The promise remains meaningful if the technology changes. A request may be delayed or rejected for a stated reason. It must not silently become two requests after a retry, inherit approval for changed content or vanish between application and reporting. These are candidate invariants for stakeholder approval, not properties already demonstrated by this example.
1.3 Executive assessment
The fictional organization can launch separate applications but cannot yet show consistent approval ownership, reporting definitions or a demonstrated restore. The strategic gap is the ability to repeat a trustworthy service across offices. The recommendation is to establish one authoritative journey and common supporting capabilities before multiplying services.
| Executive question | Recommended position | Decision authority |
|---|---|---|
| What is the first investment? | One approval journey with explainable reporting | Business sponsor |
| What remains institution-owned? | Rules, data definitions, access policy and acceptance evidence | Institutional owners |
| What can a supplier implement? | Agreed components and operational services under explicit contracts | Procurement and system owner |
| What is outside the first release? | Final offline approvals and additional regulated services | Sponsor and risk owner |
1.4 Reading the architecture as a city
Domains resemble buildings with different purposes. Shared identity, integration, delivery and observability resemble civic services. Governance defines the rules for using them; the platform team operates agreed common capabilities. This analogy explains responsibility and reuse. It does not mean every capability needs a separate service, database or team.
1.5 Required executive record
- A signed purpose statement and explicit exclusions.
- The institutional promise and measurable candidate acceptance scenarios.
- Named business, data, system and risk owners.
- A record of assumptions, unresolved decisions and authorized next work.
1.6 Decision gate
Proceed to discovery when the sponsor accepts the first journey and assigns accountable owners. Do not approve a technology procurement solely because the target diagram looks complete. The first management decision is scope and authority; detailed component selection follows evidence.