21.2 Architecture Principles & Decision Framework

Principle 1 — Business meaning is an architectural asset

Technical tables without agreed semantics create duplicated logic downstream.

Principle 2 — Reuse before duplication

Share governed data across spaces when ownership and security permit. Do not copy data simply because another team needs access.

Principle 3 — Persist intentionally

Choose federation, replication or transformation-based persistence from latency, source impact, reliability, volume and cost.

Principle 4 — Separate ownership from consumption

The team that consumes a metric does not automatically own its definition.

Principle 5 — Security follows data sensitivity

Do not rely only on space boundaries. Apply the appropriate object, role and data access controls.

Principle 6 — Design for change

Source systems, consumers and organizational ownership change. Prefer stable contracts and explicit versioning.

Decision matrix

Dimension	Question
Business	What outcome improves?
Technical	What capability is required?
Data	What is the grain and ownership?
Security	Who can see which data?
Operations	How is it monitored and recovered?
Cost	What scales with volume or runtime?
Alternatives	What was rejected and why?

Architecture record

Every important decision should have a short ADR-style record with context, decision, alternatives and consequences.