05 — Library · 21 principles

Principles

Architecture principles a practice can hold itself to, each with its rationale and what following it obliges.

Search principlesSort

Principles

Showing 9 of 21 principles

PN-210
Automate Only What You Have Understood
Application
Automate a process, or hand it to an AI agent, only after it has been made explicit, measured and bounded; otherwise automation makes the mess faster.
Because · Scripting an unclear process fixes its current confusion in code, and an autonomous agent with vague limits will do confidently what nobody intended. Writing the process down, agreeing what good looks like and defining what the automation may not do turns automation into a controlled change rather than a gamble.
Implications
- A process is documented with its owner, inputs, decisions and exceptions before it is automated.
- Every automation and AI agent has a stated scope, a human escalation path and a log of what it did.
- AI systems that affect people or money are risk-assessed and monitored for drift, with the assessment reviewed on a schedule.
Guides · Process & Task Automation,AI Strategy & Governance,Generative AI & Agents,Process Documentation & Modeling
Guards against · Golden Hammer
Echoed in · NIST AI Risk Management Framework,ISO/IEC 42001
Terms · Business Process
Related · Data Is Owned, Named and Described,Observable by Default
PN-030
Buy Commodity, Build Differentiators
Application
Build software only where it creates an advantage customers notice; everywhere else, adopt a standard product and change the process to fit it.
Because · Payroll, expense claims and ticket queues are the same in every company, and products in those markets improve faster than an internal team can. Engineering effort is scarce; spending it on the few capabilities that set the company apart, and accepting a vendor's process for the rest, is how a small team keeps up with a large one.
Implications
- A build decision names the differentiating capability and the customer-visible advantage it protects.
- Customization of a commodity product is capped; the process bends to the product, not the reverse.
- Vendor evaluation starts from the capability model, so every product is assessed against the same list.
Guides · Application & Technology Architecture,Technology Vendor Strategy,Portfolio Planning & Investment
Guards against · Resume-Driven Design
Echoed in · Wardley Mapping
Terms · Application Portfolio,Application Rationalization
Related · One System of Record per Business Object,Data Is Owned, Named and Described
PN-010
Capabilities Outlive Applications
Business
Plan, fund and measure change in terms of business capabilities, never in terms of the applications that happen to implement them today.
Because · A capability such as Order Promising stays stable for decades while the systems behind it are replaced every few years. Anchoring strategy, investment and architecture to capabilities gives every conversation a vocabulary that survives reorganizations and vendor swaps, and makes application changes comparable across time.
Implications
- Every business application in the portfolio maps to at least one capability; an unmapped application is a question, not an exception.
- Roadmaps and investment cases name the capability they improve and the measure that will show it.
- Capability names describe what the business does, never a team, a system or a process step.
Guides · Business Architecture,Investment Prioritization & Funding,Technology Strategy & Operating Model
Guards against · Org-Chart Capability Map,Process Posing as a Capability,Application-Named Capabilities
Echoed in · BIZBOK Guide
Terms · Business Capability,Capability Map
Related · Decide From the Value Stream,Everything Has a Total Cost and a Retirement Date
PN-050
Data Is Owned, Named and Described
Information
Every shared data set has a named owner, a business definition and a quality standard before it is shared.
Because · Data without an owner degrades silently; nobody is accountable when a field changes meaning or a feed goes stale. Governance done up front, as part of making data available, costs far less than forensic clean-up after a report or a model has been built on it.
Implications
- A data set is published with its owner, definition, refresh cadence and known limits, in a catalog people can find.
- Quality rules are measured and visible; breaches are the owner's problem to fix, not the consumer's to work around.
- Analytics and AI work starts from governed data sets; ungoverned extracts are a documented exception with an expiry.
Guides · Data Governance & Stewardship,Business Intelligence & Reporting,AI Strategy & Governance
Guards against · Data Swamp,Spreadsheet System of Record
Applied by · Data Mesh
Echoed in · DAMA-DMBOK
Terms · Data Product,Data Lineage,Data Governance
Related · One System of Record per Business Object
PN-020
Decide From the Value Stream
Business
Judge an architecture choice by its effect on an end-to-end value stream, not on the local efficiency of one function or system.
Because · Most expensive mistakes optimize one stage while lengthening the whole flow: a faster quoting tool that creates rework in fulfillment, a cheaper warehouse system that hides stock from the order promise. Tracing the stream from trigger to outcome keeps the customer's result, cycle time and hand-offs in view when trade-offs are made.
Implications
- Solution designs that touch more than one function show the value stream and the stages they change.
- Cycle time, first-time-right rate and hand-off count are measured across the stream before and after a change.
- A local gain that worsens the stream's outcome is declined, however good its business case looks in isolation.
Guides · Value Stream Mapping,Process Architecture & Ownership,Benefits Realization
Guards against · Process Posing as a Capability
Echoed in · BIZBOK Guide,APQC Process Classification Framework
Terms · Value Stream,Value Stream Mapping,Business Outcome
Related · Capabilities Outlive Applications
PN-090
Design for Failure
Technology
Assume every dependency will fail, slow down or return nonsense, and make sure the service degrades on purpose rather than by accident.
Because · In a distributed estate something is always broken. A system that has decided in advance what to do when a downstream call times out (serve stale data, queue the work, refuse politely) keeps the value stream moving. A system that has not decided will either hang, retry itself into a storm or take its neighbors down with it.
Implications
- Every outbound call has a timeout, a retry policy with backoff and a defined fallback, reviewed in design.
- Failure modes are tested deliberately, in non-production first and then in production under control.
- Capacity limits are explicit; a service protects itself with rate limits and bulkheads before it protects its callers.
Guides · Solution Design,Infrastructure Automation & Observability,Continuity Planning
Guards against · Retry Storm,Chatty Services
Applied by · Circuit Breaker,Retry with Backoff,Bulkhead,Rate Limiting,Queue-Based Load Leveling
Related · Observable by Default,Infrastructure Is Code, Servers Are Cattle
PN-080
Draw Boundaries Around the Domain
Application
Decompose systems along business domain boundaries, where the language changes, not along technical layers or team charts.
Because · A boundary drawn where the words change (an "order" means something different to sales than to the warehouse) produces components that can be understood, owned and replaced on their own. A boundary drawn by technology or org chart produces pieces that must all change together, which is a monolith with network calls added.
Implications
- Each component has a single owning team and a model of its own; shared "common" models are treated with suspicion.
- Translation between domains is explicit, in an anti-corruption layer, rather than leaking one model into another.
- The size of a component follows the domain; a modular monolith is a legitimate end state, not a failure to decompose.
Guides · Solution Design,Reference Architecture
Guards against · Big Ball of Mud,Distributed Monolith,God Service,Anemic Domain Model
Applied by · Bounded Context,Anti-Corruption Layer,Modular Monolith,Aggregate
Terms · Domain-Driven Design,Bounded Context,Microservice,Monolith
Related · Prefer Events for Facts, Requests for Commands,Design for Failure
PN-200
Everything Has a Total Cost and a Retirement Date
Governance
Approve an application, platform or technology only with its full lifetime cost and the conditions under which it will be retired stated up front.
Because · The purchase price is the smallest number in a system's life; licenses, hosting, support, integration upkeep and the eventual migration dwarf it. Deciding at the start how the thing will be measured and when it will go prevents the portfolio from accreting systems that nobody owns and nobody dares switch off.
Implications
- Business cases show total cost of ownership over the expected life, including the cost of leaving.
- Every application has an owner, a lifecycle stage and a review date in the portfolio; "retire" is a normal outcome of that review.
- A system past its retirement condition is funded to leave, not quietly renewed.
Guides · Technology Financial Management,Application Portfolio Rationalization,Investment Prioritization & Funding
Guards against · Shelfware Architecture
Echoed in · TBM Taxonomy,FinOps Framework
Terms · Total Cost of Ownership,TIME Model,Application Portfolio
Related · Capabilities Outlive Applications,Standardize the Technology Portfolio
PN-180
Govern by Guardrails, Not Gates
Governance
Express architecture standards as automated checks and self-service paved roads, and reserve human review for the exceptions the checks cannot judge.
Because · A review board that every change must pass becomes the slowest part of delivery and is routed around. Encoding the standards as fitness functions in the pipeline and as templates teams reach for first makes compliance the easy path, scales governance with the number of teams and leaves architects time for the decisions that matter.
Implications
- Each standard has a check that can run without a person; a standard with no check is a suggestion, and is labeled as one.
- Golden paths (templates, platforms, reference implementations) are maintained as products with their own users and backlog.
- Review time is spent on novel designs, exceptions and cross-team conflicts, with a published turnaround.
Guides · Architecture Review,Exception Management,IT Policy & Decision Rights
Guards against · Ivory Tower Architecture,Shelfware Architecture
Applied by · Fitness Functions,Twelve-Factor App
Echoed in · COBIT
Terms · Architecture Review Board,Fitness Function,Platform Engineering
Related · Record Decisions Where the Work Is,Standardize the Technology Portfolio
PN-110
Infrastructure Is Code, Servers Are Cattle
Technology
Every environment is declared in version-controlled code and can be rebuilt from scratch; nothing is configured by hand and kept.
Because · A server that was tuned by hand over three years cannot be reproduced, audited or safely patched. Declaring infrastructure in code makes environments identical, reviews changes like any other code, and turns disaster recovery into a deployment. Replacing instances instead of repairing them removes drift at its source.
Implications
- Production changes go through the same pipeline as application code: pull request, review, automated apply.
- Manual changes are forbidden in production; break-glass access is logged and reverted by the next apply.
- Recovery is rehearsed by rebuilding an environment from code, not by restoring a snapshot of a hand-built one.
Guides · Infrastructure Automation & Observability,Cloud Platform Operations,Storage, Backup & Recovery
Guards against · Snowflake Servers
Applied by · Infrastructure as Code,Immutable Infrastructure,Twelve-Factor App
Echoed in · AWS Well-Architected Framework,Azure Well-Architected Framework,Google Cloud Well-Architected Framework
Terms · Infrastructure as Code,Landing Zone
Related · Design for Failure,Ship Small, Ship Often
PN-060
Integrate Through Contracts, Not Databases
Integration
Systems exchange data through published, versioned interfaces; no system reads or writes another system's database.
Because · A shared table couples two systems at their most fragile point: the moment one team changes a column, the other breaks without warning. A contract (an API, an event schema, a file specification) lets each side change behind it, states what is promised, and can be tested, monitored and deprecated on a schedule.
Implications
- Every integration has a contract that is version-controlled and discoverable, with an owner on each side.
- Breaking changes ship as a new version with a deprecation window; consumers are told, not surprised.
- Direct database links found in the estate are logged as technical debt with a retirement date.
Guides · Integration & API Delivery,Data Engineering & Pipelines
Guards against · Shared Database Integration,Point-to-Point Spaghetti
Applied by · API Gateway,Schema Registry,Publish-Subscribe
Echoed in · OpenAPI Specification,AsyncAPI
Terms · API,Integration Pattern
Related · One System of Record per Business Object,Prefer Events for Facts, Requests for Commands
PN-190
Keep the Model Current or Delete It
Governance
Maintain architecture and configuration records only where a process keeps them accurate; an unmaintained record is removed, not kept as decoration.
Because · A repository that is eighty percent right is trusted zero percent, because nobody knows which fifth is wrong. Every record kept needs a feed, an owner and a consumer who would notice if it went stale. Fewer records that people rely on beat a complete model that people have learned to ignore.
Implications
- Each class of record has a source of truth and a reconciliation that runs on a schedule, with discrepancies reported to an owner.
- A record with no consumer in the last review cycle is a candidate for deletion, not for a documentation sprint.
- The CMDB holds what service management and architecture actually use, related the way the data model says, and nothing else.
Guides · Repository Stewardship,Configuration Management & CMDB,Metadata & Taxonomy
Guards against · CMDB Dumping Ground,Shelfware Architecture
Echoed in · ServiceNow Common Service Data Model (CSDM),ITIL
Terms · Architecture Repository,CMDB,Configuration Item
Related · Record Decisions Where the Work Is,One System of Record per Business Object
PN-120
Never Trust the Network
Security
Authenticate and authorize every request on its own merits, wherever it comes from; location on the network grants nothing.
Because · Perimeter security assumes the inside is safe, which stopped being true with the first laptop, cloud service and contractor. Verifying identity, device and context on each request, and granting the least access the task needs, limits what an attacker can do after any single control fails.
Implications
- Every service-to-service and user-to-service call carries a verified identity; shared secrets and IP allow-lists are not a substitute.
- Access is granted per role and reviewed on a schedule; standing administrative rights are the exception, approved and time-boxed.
- Secrets live in a managed store, are rotated automatically and never appear in code, configuration files or tickets.
Guides · Identity & Access Management,Infrastructure & Endpoint Protection,Application & Data Security
Applied by · Zero Trust,Secrets Management,Federated Identity
Echoed in · NIST Cybersecurity Framework,ISO/IEC 27001
Terms · Zero Trust
Related · Security Is Designed In, Then Verified
PN-100
Observable by Default
Technology
A service is not finished until an operator can tell, from its own telemetry, whether it is meeting its objective and why not.
Because · Logs that only the author can read and dashboards built after the first outage are the expensive way to learn what a system does. Structured logs, traces that follow a request across services and a small number of objectives with error budgets turn incidents into questions that can be answered in minutes.
Implications
- Every service emits structured logs, metrics and traces with a shared correlation id from day one.
- Each service has a service level objective agreed with its consumers and an error budget that governs release pace.
- Alerts page on symptoms the user would notice; everything else is a dashboard, so pages stay rare and meaningful.
Guides · Infrastructure Automation & Observability,Service Level & Performance,Incident & Problem Management
Guards against · Alert Fatigue
Applied by · Distributed Tracing,Structured Logging,SLO and Error Budget
Echoed in · ITIL
Terms · Observability,Service Level Objective
Related · Design for Failure,Standardize the Technology Portfolio
PN-040
One System of Record per Business Object
Information
Every business object has exactly one authoritative source, and every other copy is a derived, labeled replica.
Because · When two systems both claim to own the customer, the dispute is settled by whoever shouts loudest, usually at month end. Naming one system of record per object, and treating the rest as read models that are allowed to lag, removes an entire class of reconciliation work and makes integration direction obvious.
Implications
- The data catalog names the system of record for each master and reference data object, with a steward.
- Writes go to the system of record; replicas are populated by integration and are never corrected by hand.
- A new application that wants to own an object already owned elsewhere must retire the old owner, not add a second.
Guides · Master & Reference Data,Data Governance & Stewardship,Configuration Management & CMDB
Guards against · Shared Database Integration,Spreadsheet System of Record
Applied by · Change Data Capture,Schema Registry
Echoed in · DAMA-DMBOK,ServiceNow Common Service Data Model (CSDM)
Terms · System of Record,Master Data
Related · Data Is Owned, Named and Described,Integrate Through Contracts, Not Databases
PN-070
Prefer Events for Facts, Requests for Commands
Integration
Publish business facts as events that any consumer may subscribe to; use direct requests only when the caller needs an answer now.
Because · An order being placed is a fact that finance, fulfillment and analytics all care about. Broadcasting it once removes the web of point-to-point calls that grows when each consumer is wired in separately, and lets new consumers join without touching the producer. Requests still have their place where a result is needed in the moment, such as a price check or an address validation.
Implications
- Domain events are named in business terms, carry enough to act on, and are published through a shared broker.
- Producers do not know their consumers; consumers are responsible for being idempotent and for catching up.
- Synchronous chains longer than two hops are reviewed; they usually hide a fact that should have been an event.
Guides · Integration & API Delivery,Solution Design
Guards against · Point-to-Point Spaghetti,Chatty Services,Distributed Monolith
Applied by · Domain Events,Publish-Subscribe,Idempotent Consumer,Transactional Outbox
Echoed in · AsyncAPI
Terms · Event-Driven Architecture
Related · Integrate Through Contracts, Not Databases,Draw Boundaries Around the Domain
PN-170
Record Decisions Where the Work Is
Governance
Write down every significant architecture decision, with its context and the options rejected, in the repository the affected team works in.
Because · Six months later nobody remembers why the queue was chosen over the database, and the next team either repeats the analysis or reverses a sound decision by accident. A short decision record, kept next to the code and reviewed like code, preserves the reasoning at the moment it is clearest and cheapest to capture.
Implications
- A decision that constrains more than one team, costs real money or is hard to reverse gets a record before it is acted on.
- Records are immutable once accepted; a change of mind is a new record that supersedes the old one.
- The architecture repository links to decision records rather than copying them, so there is one version of the truth.
Guides · Architecture Governance,Solution Design
Guards against · Ivory Tower Architecture,Shelfware Architecture
Applied by · Architecture Decision Records
Echoed in · ISO/IEC/IEEE 42010,arc42
Terms · Architecture Decision Record,Architecture Repository
Related · Govern by Guardrails, Not Gates,Keep the Model Current or Delete It
PN-130
Security Is Designed In, Then Verified
Security
Treat security requirements as design inputs and prove them with automated checks in the delivery pipeline, not with a review at the end.
Because · A vulnerability found in design costs a conversation; the same one found after release costs an incident, a patch and often a disclosure. Threat modeling while the design is still cheap to change, and scanning code, dependencies and configuration on every build, keeps the cost on the cheap side of that line.
Implications
- Designs that handle personal, financial or safety-related data carry a threat model before build starts.
- The pipeline fails on known vulnerable dependencies, exposed secrets and misconfigured infrastructure.
- Third-party software and services are assessed before adoption and re-assessed when their risk changes.
Guides · Application & Data Security,Quality Engineering & Testing,Third-Party & Supply Chain Security
Applied by · Secrets Management,Fitness Functions
Echoed in · NIST Cybersecurity Framework,ISO/IEC 27001
Related · Never Trust the Network,Ship Small, Ship Often
PN-150
Ship Small, Ship Often
Delivery
Deliver change in small, independently releasable increments behind controls that let it be switched on gradually and off instantly.
Because · Large releases concentrate risk: many changes land at once, the cause of any failure is hard to find and the rollback undoes good work with bad. Small changes released frequently, dark-launched behind flags and exposed to a fraction of traffic first, make each release boring and each failure cheap.
Implications
- A change that cannot be released on its own is split until it can; long-lived branches are a design smell.
- Releases are progressive: canary or blue-green by default, with automated rollback on objective breach.
- Deployment and exposure are separate decisions; a feature can be deployed for weeks before it is switched on.
Guides · Release & Deployment,Software Engineering,Change Enablement
Guards against · Big-Bang Rewrite
Applied by · Blue-Green Deployment,Canary Release,Feature Flags
Related · Infrastructure Is Code, Servers Are Cattle,Strangle, Do Not Rewrite
PN-140
Standardize the Technology Portfolio
Technology
For each technology category, run one approved standard and a documented path off everything else; new entries need a reason the standard cannot meet.
Because · Every additional database engine, framework or messaging product multiplies the skills, licenses, patches and security reviews an organization carries. A small, current set of standards, with lifecycle dates tracked and a plan to retire what is leaving support, keeps the estate learnable and keeps surprises out of the audit.
Implications
- The technology reference model names the standard per category and the lifecycle status of each technology in use.
- A technology approaching end of life has a funded replacement plan before the date, not after.
- An exception to a standard is granted for a stated reason, recorded, and reviewed when the reason expires.
Guides · Technology Standards & Lifecycle,IT Asset & License,Technology Vendor Strategy
Guards against · Golden Hammer,Resume-Driven Design,Snowflake Servers
Terms · Technology Reference Model,Technology Lifecycle,End of Life,Technology Standard
Related · Infrastructure Is Code, Servers Are Cattle,Govern by Guardrails, Not Gates
PN-160
Strangle, Do Not Rewrite
Delivery
Replace a legacy system by routing one capability at a time to its successor until nothing is left, rather than rebuilding it whole and cutting over once.
Because · Big-bang rewrites fail in a predictable way: the new system chases a moving target for years while the old one must still be maintained, and the single cut-over is the riskiest day in the program. Incremental replacement delivers value from the first slice, keeps the rollback trivial and lets the plan learn from each step.
Implications
- Modernization plans are ordered by capability, each slice with its own cut-over and its own measure of done.
- A facade in front of the legacy system routes traffic; the old and new run side by side until the slice is proven.
- The legacy system is decommissioned slice by slice, so the cost saving appears during the program, not after it.
Guides · Application Portfolio Rationalization,Application Maintenance,Transformation Program Leadership
Guards against · Big-Bang Rewrite,Boiling the Ocean
Applied by · Strangler Fig,Anti-Corruption Layer
Terms · Application Rationalization,TIME Model
Related · Ship Small, Ship Often,Buy Commodity, Build Differentiators

Principles

Principles

Automate Only What You Have Understood

Buy Commodity, Build Differentiators

Capabilities Outlive Applications

Data Is Owned, Named and Described

Decide From the Value Stream

Design for Failure

Draw Boundaries Around the Domain

Everything Has a Total Cost and a Retirement Date

Govern by Guardrails, Not Gates

Infrastructure Is Code, Servers Are Cattle

Integrate Through Contracts, Not Databases

Keep the Model Current or Delete It

Never Trust the Network

Observable by Default

One System of Record per Business Object

Prefer Events for Facts, Requests for Commands

Record Decisions Where the Work Is

Security Is Designed In, Then Verified

Ship Small, Ship Often

Standardize the Technology Portfolio

Strangle, Do Not Rewrite