This catalog consolidates the principles developed in Chapters 4, 22, and 25 into a single reference. It is a starting point, not a mandate. Each organization should adopt only the principles that will change real decisions, express them in its own language, and assign each an accountable owner.
For each principle, the catalog states the intent, the architectural implication, and the evidence that shows whether the principle is being applied.
| # | Principle | Intent | Architectural implication | Evidence |
|---|---|---|---|---|
| 1 | Start with business outcomes | Architecture exists to create organizational capability | Decisions are traceable to strategy, capabilities, or risk reduction | Capability maps, decision records |
| 2 | Data is an enterprise asset | Manage information beyond the boundary of one application | Ownership and lifecycle extend across systems | Ownership register |
| 3 | Business meaning precedes technical representation | Establish consistent enterprise semantics | Concepts are defined independently of physical storage | Glossary, conceptual models |
| 4 | Ownership is explicit | Establish accountability for meaning, quality, and use | Critical domains and products have named owners | Ownership metadata |
| 5 | Data is fit for purpose | Align quality with intended use | Quality requirements derive from consumer needs | Quality rules and objectives |
| 6 | Data is discoverable and understandable | Make information usable | Catalog, metadata, and lineage are required capabilities | Catalog coverage |
| 7 | Security and privacy are designed in | Protect information across its lifecycle | Classification drives access, masking, retention, and monitoring | Security model, privacy assessments |
| 8 | Reuse trusted capabilities | Reduce unnecessary duplication | Shared products and services are preferred where they create value | Reuse metrics |
| 9 | Interoperability is a design requirement | Enable controlled exchange across boundaries | APIs, events, contracts, and semantics are designed explicitly | Interface standards, contracts |
| 10 | Design for change | Enable controlled evolution | Loose coupling, versioning, and reversible decisions | Versioning strategy, ADRs |
| 11 | Trust is measurable | Make reliability visible | Quality, freshness, lineage, and incidents are measured | Trust dashboards |
| 12 | Architecture reflects business value | Balance value, risk, cost, and complexity | Options are compared on economics as well as capability | Business cases, FinOps data |
| 13 | AI is part of the data ecosystem | Govern AI as consumer and producer of information | AI uses governed interfaces; AI outputs carry provenance | AI source registers, evaluation records |
| 14 | Separate logical architecture from technology choices | Preserve durability as technology changes | Capability models are independent of product selection | Logical and technology reference models |
| 15 | Automate controls where possible | Make the safe path the easy path | Policies are expressed as code, metadata, and pipeline checks | Policy-as-code coverage |
| 16 | Preserve human accountability | Keep responsibility for consequential outcomes | Approval paths and decision rights are explicit | Approval records, RACI |
Using the catalog. For each adopted principle, record what it means in your organization, which standards support it, which patterns implement it, how compliance is measured, which exceptions are permitted, who owns it, and when it will be reviewed. A principle that would change no decision should be removed.