Architecture principles are the shared rules that guide design decisions across an organisation. Written well, they make hundreds of small decisions easier; written badly, they're wall art nobody reads.
An architecture principle is a standing decision. It resolves a class of design questions in advance so they do not have to be argued individually every time.
That definition sets a bar most published principles fail. "We value quality" resolves nothing — no design decision goes differently because of it. "Buy before build; configure before customise" resolves a great deal, because it tells a project what it must justify. If a principle cannot cause someone to lose an argument, it is a value statement, not a principle.
Each principle needs four elements. The first two are usually present; the last two are what make it usable.
Single source of truth. Statement: Each data entity has one authoritative source; all other copies are derived and read-only. Rationale: Multiple masters produce reconciliation cost and conflicting reporting that erodes trust in every downstream number. Implications: Projects must identify the master for each entity they consume; writing back to a non-master is a deviation requiring an exception; integration patterns must support derivation rather than duplication.
Buy before build; configure before customise. Statement: Prefer commercial or existing solutions over new development, and configuration over code. Rationale: Custom code carries a lifetime maintenance and knowledge-concentration cost that is rarely in the original business case. Implications: Projects must document the market options considered and why they were rejected; customisation of packaged software requires justification and an upgrade-impact assessment.
Control technical diversity. Statement: New technology is introduced only where an existing approved technology cannot meet the requirement. Rationale: Every additional technology multiplies support, security patching and recruitment cost across its whole lifetime. Implications: Projects must check the technology standards list first; introducing something new requires design authority approval and a named owner for its ongoing support.
Note what these have in common: each one tells a project something concrete it must do or stop doing.
Somewhere between twelve and twenty-five. Below twelve you have not covered the recurring arguments; above twenty-five nobody can hold them in mind, and principles nobody remembers do not influence decisions.
Write them from the arguments you actually keep having. The most effective way to produce a first draft is to list the last twenty architecture disputes and ask what standing decision would have resolved each. That produces principles fitted to your organisation, rather than a generic list adopted wholesale and quietly ignored.
Use your own vocabulary. If the business says "book of business" rather than "portfolio", say that. Recognition drives adoption more than precision does.
Principles fail in a predictable way: they are published, admired, and never referenced again. Three practices prevent it.
Reference them by ID in reviews. Every architecture review should assess the solution against the principles explicitly, and the record should cite which ones were engaged. A principle cited in a decision is a principle that is alive.
Route deviations through a formal exception. If a project cannot comply, that should be a recorded, time-boxed exception rather than a silent choice. Exceptions are not principle failures; undocumented deviation is.
Review annually and delete. A principle that has never been cited in twelve months is either unnecessary or badly written. Remove it. A shorter list that carries real weight beats a comprehensive one that carries none.
Getting agreement matters as much as drafting. Principles adopted by an architecture team are architecture team opinions; principles ratified by a design authority with executive endorsement are organisational rules.
The Architecture Practice Setup Kit includes an architecture principles catalogue and a principles assessment, so you can adopt and measure adherence from day one.
