Architecture Principles Catalogue: [Organisation or domain]

Catalogue of the architecture principles that guide technology and design decisions in [Organisation]. Each principle has a statement, a rationale, implications and an exceptions process, followed by a compliance assessment and a waiver register. The example principles are written for this collection; adapt or replace them to fit your strategy.

1. How to use this catalogue

Architects and engineering teams apply these principles when they propose solutions, write design documents and record architecture decisions. Reviewers use section 4 to assess compliance. Principles are ordered by domain, not by importance; when two principles conflict, the decision record must name both, explain the balance chosen, and, if a principle is set aside, reference a waiver from section 5.

2. Principle template

3. Principles

3.1 Business principles

BP-01 Customer outcomes drive investment

• Statement: Technology investments are prioritised by measurable customer or business outcomes, not by technology preference.
• Rationale: Limited budget must go where it creates the most value; outcome measures make trade-offs transparent.
• Implications: Every initiative states its target outcome and metric; projects without one are not funded past concept stage.
• Exceptions: Mandatory regulatory or security work, approved by the investment committee.

BP-02 Reuse before buy before build

• Statement: Use existing enterprise capabilities first, buy commercial or open-source products for non-differentiating needs, and build only what differentiates us.
• Rationale: Reduces cost, time to market and the long-term maintenance burden; focuses engineers on what customers value.
• Implications: Solution proposals show a reuse and market scan; custom builds need a differentiation argument.
• Exceptions: Architecture review board, where no product meets mandatory requirements.

3.2 Data principles

DP-01 Data has one accountable owner and one master source

• Statement: Each data entity has a named business owner and exactly one system of record.
• Rationale: Prevents inconsistent copies and unclear accountability for quality and privacy.
• Implications: Other systems consume master data through published interfaces or events; local copies are read-only caches.
• Exceptions: Temporary dual mastering during migrations, with an end date in the waiver register.

DP-02 Data is classified and protected by its class

• Statement: All data is classified at creation and handled according to the controls defined for its class.
• Rationale: Proportionate protection; compliance with data protection law and contracts.
• Implications: Designs list the classes of data they process; storage and transfer controls follow the classification standard.
• Exceptions: None for Restricted data; others by the information security officer.

DP-03 Collect only the personal data that is needed

• Statement: Systems collect and retain personal data only for a defined purpose and only as long as needed.
• Rationale: Lower breach impact, legal compliance, customer trust.
• Implications: Each personal data field has a documented purpose and retention period; deletion is automated.
• Exceptions: Data protection officer, documented in the record of processing.

3.3 Application principles

AP-01 Integrate through published interfaces

• Statement: Applications exchange data only through versioned, documented APIs or events, never through each other's databases.
• Rationale: Allows systems to change independently; makes dependencies visible.
• Implications: Interface contracts are owned, versioned and tested; shared-database integrations are retired.
• Exceptions: Reporting replicas approved by the data owner.

AP-02 Design for independent change

• Statement: Structure applications so that a team can change and release its part without coordinating releases with other teams.
• Rationale: Faster delivery and smaller blast radius of failures.
• Implications: Clear module or service boundaries aligned with team ownership; backward-compatible interface changes.
• Exceptions: Tightly regulated components, by the review board.

3.4 Technology principles

TP-01 Prefer managed services on approved platforms

• Statement: Run workloads on the approved platforms and use managed services where they meet requirements.
• Rationale: Reduces operational load and improves security patching and resilience.
• Implications: Self-hosted infrastructure needs a cost and capability argument; platform team publishes the approved service list.
• Exceptions: Platform architecture lead.

TP-02 Automate build, test and deployment

• Statement: Every deployable component is built, tested and deployed by an automated pipeline from version control.
• Rationale: Repeatability, auditability and faster recovery.
• Implications: No manual production changes outside documented break-glass procedures; infrastructure is defined as code.
• Exceptions: Legacy systems listed in the waiver register with a migration plan.

TP-03 Make systems observable

• Statement: Systems emit structured logs, metrics and traces that let operators detect and diagnose problems without code changes.
• Rationale: Shorter incident detection and resolution times.
• Implications: Every service defines service level indicators and alerts before go-live.
• Exceptions: None for customer-facing services.

3.5 Security principles

SP-01 Secure by default, least privilege always

• Statement: Systems ship with secure defaults and grant users and services only the access they need.
• Rationale: Limits the impact of compromised accounts and misconfiguration.
• Implications: Access is role-based and reviewed quarterly; default credentials and open ports are prohibited.
• Exceptions: Information security officer, time-limited.

SP-02 Verify every request

• Statement: Authenticate and authorise every request between users, services and data, regardless of network location.
• Rationale: Internal networks are not a trust boundary; attackers move laterally.
• Implications: Service identities, mutual TLS or signed tokens between services; no reliance on network position for access.
• Exceptions: Legacy protocols in isolated segments, with a waiver.

4. Compliance assessment

Solution assessed: [Solution name, document reference, review date]

5. Waiver register

6. Change log of principles

Standard and licence note

Based on common industry practice for enterprise architecture principles (name, statement, rationale and implications). The principles and text are original to this collection and reproduce no text from TOGAF or any other framework. Template licence: MIT.