Architecture Principle

An architecture principle states a direction for recurring design decisions, with its rationale and scope. It can express a strategic approach or a continuing organizational concern such as protecting information. Teams need to know whether it is mandatory or advisory and who has authority to decide tradeoffs. A principle helps explain choices; it does not supply evidence that a particular product meets the requirements.

Making a principle usable

The UK government’s Cloud First policy makes its scope visible: the public-cloud default is mandatory for central government and recommended more broadly. Other hosting choices require evidence supporting the decision and its value. The Technology Code of Practice similarly distinguishes mandatory points from guidance to follow where practical. These distinctions matter when applying a principle: a compliance test suits a binding requirement, while an advisory direction calls for an explanation of the alternatives and tradeoffs.

For a local principle, state its scope, rationale, and implications for a design. Identify the decision authority and how unmet needs are reviewed. An approved exception should record its reason, responsible owner, approving authority, controls, and review or expiry date. Recording a departure does not authorize it, and a local exception cannot remove an obligation that the approver has no power to waive. An advisory preference such as simplicity can guide a decision when the team explains what complexity it avoids and what capability or resilience it gives up.

Principles, standards, and evidence

A technology standard specifies a supported choice within a defined scope. Several standards can serve one principle, but a control or contract can also justify a standard directly. Conversely, a principle can influence an individual architecture decision without producing a standard or reference architecture. Traceability should expose the actual reason and authority rather than require every choice to pass through the same document hierarchy.

For inventory, a principle might assign write authority by site and attribute while allowing read models and caches under an update contract. A second physical copy is not automatically a competing master. Its freshness, meaning, and permitted writes determine whether it creates a conflict. Extending this principle to customer data requires investigating that domain’s authority: a CDP consuming customer identities differs from one independently changing the same authoritative attributes.

A cluster of exceptions is a reason to investigate. Scope errors, implementation defects, migration work, or missing skills can produce similar patterns. Without an explicit route for unmet needs, teams may stall or diverge silently, but neither outcome is inevitable. Review the reasons and consequences before changing the principle. Forty-Seven Initiatives and No Strategy follows these decisions through sourcing and investment in a fictional retailer.

References

• GOV.UK, Government Cloud First policy (Open Government Licence v3.0, updated 19 June 2023).
• GOV.UK, The Technology Code of Practice (Open Government Licence v3.0, updated 7 July 2025).