In this chapter
15.1 Preserve principles, revise implementations
Long-lived architecture does not predict a fixed technology stack decades ahead. It preserves purpose, authority, data meaning and decision history while making implementation choices revisable. An evolutionary trigger should identify the evidence that makes the present option inadequate. The initial modular target may remain appropriate for a long time. It may also need decomposition when ownership or isolation changes. Both outcomes are compatible with ZAF if the decision follows evidence.
15.2 Evolution triggers
| Trigger | Evidence | Candidate response | New responsibility |
|---|---|---|---|
| Independent domain delivery is blocked | Repeated measured coordination cost | Separate a stable boundary | Consumer compatibility and independent operations |
| Reporting affects transactional workload | Representative contention and workload analysis | Isolate analytical processing | Data movement, freshness and reconciliation |
| Branch continuity needs exceed online approval policy | Business impact and approved delegation rules | Controlled offline decision design | Conflict resolution and recovery of local state |
| Recovery target cannot be met | Timed exercise and cost comparison | Change backup or deployment design | New failure domains and operating duties |
| AI use has a defined institutional benefit | Permitted data, evaluation and error analysis | Bounded pilot with human oversight | Model monitoring and accountability |
No trigger automatically dictates a specific product. Re-evaluate simpler changes and the cost of added operating responsibility.
15.3 Executive decision package
The sponsor receives a concise decision brief linked to the full documentation. It states the institutional promise, observed gaps, recommended target, alternatives, costs to estimate, unresolved authority questions and the evidence needed for the next gate. For this example, management must decide data placement and retention, the approval delegation policy, acceptable network interruption, recovery objectives and the staff able to operate the service. Those decisions cannot be delegated to a diagram.
15.4 Required architecture artifacts
| Artifact | Purpose | Review owner |
|---|---|---|
| Context and capability model | Explain scope and responsibility | Business owner |
| Evidence and gap register | Make findings challengeable | Assessment and risk owners |
| Principles and quality scenarios | Constrain and verify design | Architecture owner |
| Domain, data and integration views | Preserve authority across boundaries | Domain and data owners |
| Security and continuity package | Define trust, access and recovery | System and risk owners |
| Decision records and economics | Explain selected and rejected options | Authorized decision-makers |
| Transition and acceptance evidence | Demonstrate safe progression | Sponsor and system owner |
15.5 How ZAF is used in consulting
A scoped review does not promise to complete every chapter for an entire institution in one short engagement. It identifies the decision boundary, required depth and available evidence, then agrees the relevant deliverables. A narrow workflow may need a compact dossier; an institutional platform may need multiple volumes and specialist review. The method’s purpose is a decision that can be explained, implemented and revisited. This public dossier demonstrates the structure and reasoning standard. Its fictional recommendations require adaptation, authority and validation before use in a real organization.
15.6 Closing review
- Can every recommendation be traced to a purpose, constraint or finding?
- Does each authoritative fact and critical service have an owner?
- Are alternatives, consequences and uncertainty explicit?
- Can the team verify, operate and recover the proposed design?
- Do leaders know which decision is theirs and what evidence comes next?
An architecture dossier is ready for decision when these questions have usable answers, not merely when every chapter has text.