Institutional Vision & Architecture Mandate

1.1 Purpose of institutional architecture

Institutional architecture explains how an organization fulfils its mandate through capabilities, responsibilities, information, services and relationships. Its subject is the institution’s ability to act coherently. Applications and infrastructure are important implementations, but neither the presence of software nor the number of platforms establishes that coherence. This chapter establishes the foundation for the ZAF library. It defines the decisions that precede engineering architecture and the evidence needed to carry them into Book II. It is a working draft for review. It does not assert that the whole ZAF collection is complete, externally reviewed or adopted by an institution. The question is not “what system should we buy?” The question is “what must this institution be able to do, under whose authority, with which information, and with what accountability when the normal process fails?”

1.2 The architecture mandate

An architecture mandate authorizes a defined scope of analysis and decision support. It names the sponsor, institutional boundary, decision rights, access constraints and expected work products. It must distinguish recommendation from authority: an architect may recommend a delegation model without possessing the legal or organizational power to grant that delegation.

An architecture mandate is not a permission to perform intrusive testing, copy every database or publish institutional material. Discovery and publication require their own authorized boundaries. Where authority is unclear, record the open question and the decision it prevents.

1.3 Institutional promise and measurable outcomes

The institutional promise states what stakeholders should be able to rely on. It should be understandable without naming a product. In an operational approval service, the promise may be that an accepted request has an identifiable origin, an authorized decision, an explainable state and a route for correction or recovery. Translate that promise into observable outcomes. Separate the citizen or staff outcome from the technical service measure. A two-second interface response does not prove that an application was resolved fairly or within the institution’s decision period. Equally, a policy delay should not be hidden inside a software availability metric.

The owner decides acceptable targets after impact, cost and operating capability are examined. Do not attach impressive percentages to an institution that has not measured a baseline.

1.4 Institution, ecosystem and boundary

The institution is not identical to its application estate. It includes people, policies, funding, delegated powers, information ownership, partners and manual work. A process that depends on a telephone confirmation or a paper register belongs in the assessment even when it has no API. Identify the system of interest at the appropriate scale. A single department, an institution-wide platform and a national ecosystem require different decision rights. Extending a local design into a multi-institution platform introduces authority and agreement questions that capacity planning alone cannot answer.

The view distinguishes the institutional mandate from domain responsibilities and enabling engineering. It is conceptual: it does not prescribe separate services, teams or physical infrastructure. Its value is to make the responsibility boundary visible before products are selected.

1.5 Stakeholders, concerns and authority

A stakeholder register is useful when it connects a person or role to a concern and an actual decision. “Management” is too broad when several authorities disagree. Record who uses the service, who owns its rules, who operates it, who is affected by its failure and who may challenge the outcome.

The register does not imply that one person must fill each role. Small teams may combine duties, while still making conflicts and critical independent checks explicit. A blank responsibility is an unresolved risk, not an implicit assignment to a supplier.

1.6 Capabilities, services and value streams

A capability describes what the institution must be able to do. A service presents a usable outcome to a stakeholder. A value stream connects activities that deliver that outcome. Keeping these concepts distinct avoids naming every screen as a capability or treating an organizational chart as the architecture. For an approval journey, capabilities may include receiving requests, evaluating eligibility, authorizing action, executing it and reconciling the result. The service is the complete experience of obtaining and understanding a decision. Shared identity or notification supports that service but does not own its policy. Document the successful path, rejection, withdrawal, amendment and interruption. A beautiful diagram of the happy path can hide the situations where institutional trust is actually tested.

1.7 Ownership and the operating model

Institutional architecture assigns authority over facts and decisions. If two systems can independently declare the same request approved, the issue is not merely duplication of storage: the institution has competing authorities. Name the owner of the authoritative fact and define how copies, projections and corrections relate to it. The operating model explains how responsibilities cooperate. Shared capabilities should reduce repeated effort without taking over every domain decision. Domain autonomy should support change without allowing incompatible meanings or unaccountable exceptions.

1.8 Evidence, assumptions and institutional assessment

Separate observation, testimony, assumption and recommendation. A user complaint is evidence of an experienced problem; it is not automatically proof of its technical cause. A sampled contradiction is a finding within that sample; it is not a measured institution-wide failure rate. Maintain an evidence register with source, date or period, access boundary, interpretation and uncertainty. Preserve only the material required for the agreed purpose. Redacted traces and approved samples may be enough; large uncontrolled exports increase risk without necessarily improving the decision. A proposed future state should explain which finding or goal it addresses. If a component cannot be linked to a responsibility, concern or scenario, challenge its inclusion.

1.9 Institutional principles

Principles should constrain decisions rather than praise every possible solution. Each principle needs a rationale, an implementation consequence and an exception route.

These are draft ZAF principles for examination, not universal rules imposed on every organization. An adopting institution must decide their applicability and approval mechanism.

1.10 Worked institutional example

Consider a fictional regional institution with a headquarters, six offices and a small engineering team. Its operational requests move through spreadsheets, email approval and manual reporting. The illustrative problem is the inability to connect fulfilment confidently to the exact authorized request version. The institutional recommendation is to establish authoritative approval, ownership of execution facts and agreed reporting definitions. It is not yet a recommendation to deploy Kubernetes or Kafka. Those decisions belong to Book II after the operating constraints and architectural needs are established.

The example demonstrates reasoning, not client delivery. No actual institution, efficiency gain, fraud reduction or operating result is claimed.

1.11 Institutional risks and unresolved decisions

Important uncertainties should be visible before engineering begins. Data placement, retention, delegated authority, interruption tolerance, supplier responsibility and funding for operation may materially change the feasible solution. A risk register links cause, consequence, evidence, treatment and acceptance authority. Prioritization should consider harm and uncertainty. A high-risk unknown can justify a discovery task before a large implementation commitment. Do not accept a risk on behalf of the institution merely because an implementation is technically possible. The architect records consequences and alternatives; the authorized owner accepts the residual exposure.

1.12 The institutional architecture artifact package

These identifiers support later cross-references. A project may tailor the package, but it should record why an artifact is unnecessary rather than silently omitting the responsibility it represents.

1.13 Handoff to Book II — Engineering Architecture

Book II consumes the accepted institutional decisions and translates them into reference architectures, technology standards, platform contracts and engineering responsibilities. It does not replace the institutional mandate or invent missing policy.

A technology chapter can be conditional. The dedicated Kubernetes architecture section belongs in Book II, while its applicability must follow an approved adoption decision. The existence of the chapter does not mandate Kubernetes for every engagement.

1.14 Review checklist for this draft

• The institution and assessment boundary are explicit.
• Mandate, recommendation and approval authority are distinguished.
• Stakeholder concerns connect to decisions rather than generic role lists.
• Capabilities and information have accountable owners.
• Rejected, amended and interrupted journeys are included.
• Findings distinguish evidence from assumptions.
• Technology selection does not precede institutional decisions.
• Unresolved risks have owners and required next evidence.
• Artifacts have stable identifiers and review responsibility.
• Book II receives explicit institutional inputs.

This is a review checklist, not evidence that a particular institution has passed it. Review results should identify the version examined, reviewer, scope, findings and disposition.

1.15 Decisions required before advancing

The editor and adopting organization should resolve the scope of the institutional model, confirm the next section’s concerns and review this draft’s terminology. A draft becomes accepted only through the library’s documented review process; publishing it on the website does not constitute approval. The next Book I section is Institutional Context & Stakeholder Concerns. It should extend the mandate into a documented context model, concern register, viewpoints and a discovery plan. Engineering implementation remains outside this first section’s acceptance claim.