# 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.

<!--
Guidance: How to use this template
- Keep the catalogue short: 10 to 20 principles that people can remember.
  A principle nobody can quote does not guide decisions.
- Each principle must be able to say "no" to something. "We value
  quality" is not a principle; "Buy before build for non-differentiating
  capabilities" is.
- Rationale ties the principle to business goals; implications tell
  teams what it costs them. Both are mandatory.
- Review the catalogue yearly and after major strategy changes; retire
  principles that no longer drive decisions.
-->

| Field | Value |
|---|---|
| Document ID | [AP-CAT-001] |
| Scope | [Whole enterprise / business unit / product domain] |
| Version | [1.0] |
| Status | [Draft / Approved / Under review] |
| Owner | [@enterprise-architect] |
| Approved by | [Architecture review board, YYYY-MM-DD] |
| Next review | YYYY-MM-DD |

## 1. How to use this catalogue

<!-- Guidance: Explain who applies the principles, when, and how conflicts between principles are resolved. -->

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.

| When | Who | How principles are used |
|---|---|---|
| Solution concept | Solution architect | Shape options; exclude non-compliant ones early |
| Design review | Architecture review board | Assess compliance table (section 4) |
| Architecture decision | Decision owner | Cite principles in the ADR rationale |
| Procurement | Procurement and architecture | Include principles in vendor requirements |

## 2. Principle template

<!-- Guidance: Use these fields for every principle so they can be compared and assessed consistently. -->

| Field | Content |
|---|---|
| ID and name | Short, memorable name with domain prefix (BP, DP, AP, TP, SP) |
| Statement | One sentence stating the rule, in the imperative or present tense |
| Rationale | Business reasons and benefits; link to strategy or goals |
| Implications | What teams must do, stop doing or invest in; costs and consequences |
| Exceptions process | When an exception may be granted, by whom, and for how long |

## 3. Principles

<!-- Guidance: Group principles by domain. The examples below are realistic but generic; rewrite them for your organisation and delete those that do not apply. -->

### 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

<!-- Guidance: Use this table in design reviews. Assess every principle, not only the ones the solution meets; "Not applicable" needs a reason. -->

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

| Principle | Compliance | Evidence | Action or waiver |
|---|---|---|---|
| BP-01 | *Example:* Compliant | Outcome metric "onboarding under 1 day" in business case | None |
| BP-02 | *Example:* Compliant | Reuses CRM; buys verification service | None |
| DP-01 | *Example:* Partially compliant | Customer address mastered in CRM and core banking until migration | WVR-007 |
| DP-03 | *Example:* Compliant | Retention per field documented | None |
| AP-01 | *Example:* Non-compliant | Nightly file transfer to legacy billing | WVR-008, ends YYYY-MM-DD |
| TP-03 | *Example:* Compliant | SLIs and alerts defined in design section 6.3 | None |
| [ID] | [Compliant / Partially / Non-compliant / Not applicable] | [Evidence] | [Action or waiver ID] |

## 5. Waiver register

<!-- Guidance: Every non-compliance needs an entry with a justification, a compensating measure, an owner and an expiry date. Expired waivers are escalated, not silently extended. -->

| Waiver ID | Principle | Solution | Justification | Compensating measures | Owner | Approved by | Expiry | Status |
|---|---|---|---|---|---|---|---|---|
| WVR-007 | *Example:* DP-01 | Digital onboarding | Core banking migration in 2027 | Nightly reconciliation report | @data-owner | ARB YYYY-MM-DD | YYYY-MM-DD | Active |
| WVR-008 | *Example:* AP-01 | Digital onboarding | Legacy billing has no API | File encrypted, checksum validated | @solution-architect | ARB YYYY-MM-DD | YYYY-MM-DD | Active |
| [WVR-nnn] | [Principle] | [Solution] | [Justification] | [Measures] | [@owner] | [Body, date] | YYYY-MM-DD | [Active / Expired / Closed] |

## 6. Change log of principles

<!-- Guidance: Record when principles were added, changed or retired and why. -->

| Date | Principle | Change | Reason |
|---|---|---|---|
| YYYY-MM-DD | *Example:* TP-03 | Added | Incident review showed late detection of outages |
| YYYY-MM-DD | [ID] | [Added / Changed / Retired] | [Reason] |

## 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.