Quick Navigation
- Start here — What standards are
- Types of standards
- What reference architectures are
- Creating standards that get adopted
- Governing standards
- Reference architecture examples
- Consistency vs autonomy
- Reference architecture adoption
- Putting it all together
- Cheat sheet
Before we start — the one thing to hold onto
Without standards, every team solves the same problem differently. One team picks Kafka, another picks RabbitMQ, a third builds their own message broker. One team uses REST, another uses gRPC, a third uses SOAP. None of them are wrong individually — but collectively they create a fragmented, expensive, and hard-to-operate landscape. I've seen organisations with 47 distinct technologies across 12 teams. Hiring was difficult. Integration was painful. Security review was overwhelmed.
Standards and reference architectures are the agreed patterns, principles, and structures that create consistency across an organisation — reducing duplication, accelerating delivery, and managing risk at scale.
Standards settle common questions once, so teams don't have to re-debate them every sprint. Reference architectures give teams a starting point — not a straitjacket — so they don't have to design from scratch.
Keep it in mind.
1. What standards are — And what they're not
People hear "standards" and think "rules imposed from above that slow us down." That's not what good standards are.
Standards are pre-made decisions — the common choices that every team would otherwise make independently. They're not restrictions on creativity. They're restrictions on re-solving solved problems.
What standards are: Pre-decided choices — "We use PostgreSQL for relational data" so teams don't re-debate the database every project. Guardrails — "All APIs must be versioned" so integrations don't break unpredictably. Enablers — settling the common so teams can focus on the novel.
What standards are not: A straitjacket — teams can request exceptions for valid reasons. A technology mandate — standards include patterns and principles, not just products. A one-time decision — standards must evolve as the context changes. A document — standards must be adopted, consumed, and enforced, not just written.
flowchart TD
STD["Standards"] --> ARE["✅ What They Are"]
STD --> NOT["❌ What They Are Not"]
ARE --> A1["Pre-decided choices\nSettle common questions once"]
ARE --> A2["Guardrails\nPrevent predictable failures"]
ARE --> A3["Enablers\nFree teams to focus on novel problems"]
NOT --> N1["Straitjacket\nExceptions are allowed"]
NOT --> N2["Technology mandate\nPatterns and principles, not just products"]
NOT --> N3["One-time decision\nMust evolve with context"]
NOT --> N4["Just a document\nMust be adopted and enforced"]
Why standards matter:
| Without standards | With standards |
|---|---|
| Every team re-debates common choices | Common choices settled once |
| Inconsistent integrations | Predictable, compatible systems |
| Hard to hire — every team uses different tech | Easier hiring — common technology stack |
| Hard to operate — every system is unique | Easier operations — common patterns |
| Security gaps — inconsistent controls | Better security — common baseline |
The spectrum of standards: Principles — guiding values. "API-first," "Data owned by domains." High flexibility — interpreted per context. Patterns — structural approaches. Event-driven integration, CQRS. Medium flexibility — apply with judgement. Technology choices — specific products. PostgreSQL, Kafka, Kubernetes. Low flexibility — use unless exception granted. Guardrails — hard constraints. "All data encrypted at rest," "All APIs versioned." None — must comply.
Standards are pre-made decisions that free teams to focus on what's novel — not rules that slow them down.
Try it yourself — The standards check
What common decisions does every team in your organisation re-debate?
| Decision | Currently | Could it be standardised? |
|---|---|---|
| Database choice | ||
| API style | ||
| Logging format | ||
| Authentication |
If teams are re-debating these every project, you don't have standards. You have decision fatigue.
2. Types of standards — Principles, patterns, technology choices, and guardrails
"Standards" is too broad a term. Without categorisation, teams don't know what's flexible and what's mandatory.
Standards come in four types, each with different flexibility and enforcement:
flowchart TD
TYPES["Types of Standards"] --> PRIN["📏 Principles\nBroad guiding values\nFlexible, interpreted per context"]
TYPES --> PAT["📐 Patterns\nReusable structural designs\nApplied with judgement"]
TYPES --> TECH["⚙️ Technology Choices\nSpecific product selections\nUse unless exception granted"]
TYPES --> GUARD["🛡️ Guardrails\nNon-negotiable constraints\nMust comply — no exceptions"]
PRIN --> EX1["'API-first'\n'Data owned by domains'\n'Cloud-native by default'"]
PAT --> EX2["Event-driven integration\nCQRS for read-heavy\nCircuit breaker for resilience"]
TECH --> EX3["PostgreSQL for relational\nKafka for messaging\nReact for frontend"]
GUARD --> EX4["All data encrypted at rest\nAll APIs versioned and documented\nNo direct database access from frontend"]
How to write each type:
Principles — use the format: "We [value X] because [reason Y]. This means [implication Z]." Example: "We prefer open standards because they reduce vendor lock-in. This means we choose open-source or standards-based technologies unless there's a compelling reason not to."
Technology choices — use the format: "For [use case], we use [technology]. Alternatives are permitted with an approved exception." Example: "For relational databases, we use PostgreSQL. Alternatives are permitted with an approved exception from the architecture board."
Guardrails — use the format: "[Constraint]. No exceptions without [authority]." Example: "All customer data must be encrypted at rest. No exceptions without CISO approval."
The standards register:
| ID | Type | Standard | Scope | Flexibility | Exception Authority |
|---|---|---|---|---|---|
| P-01 | Principle | API-first design | All services | Interpret per context | — |
| P-02 | Principle | Data owned by domains | All data | Interpret per context | — |
| PAT-01 | Pattern | Event-driven for cross-domain integration | Cross-domain | Apply with judgement | Domain architect |
| T-01 | Technology | PostgreSQL for relational data | All projects | Exception required | Architecture board |
| G-01 | Guardrail | All data encrypted at rest | All systems | No exception | CISO |
| G-02 | Guardrail | All APIs versioned and documented | All APIs | No exception | Lead architect |
Exception process: Team needs exception → Submit request (justify why standard doesn't fit) → Review (architecture board or delegated authority) → Approved (document rationale and conditions) or Denied (use the standard or redesign approach) → Log in register (track exception for future review).
Four types — principles, patterns, technology, guardrails — each with decreasing flexibility and increasing enforcement.
Try it yourself — The register check
Do you have a standards register?
| Type | How many? | Exception process? |
|---|---|---|
| Principles | ||
| Patterns | ||
| Technology choices | ||
| Guardrails |
If you don't have a register, your standards are suggestions.
3. What reference architectures are — Reusable structural templates for common problems
Teams facing common problems — "build an integration platform," "set up a cloud landing zone," "design a data platform" — shouldn't start from scratch every time.
A reference architecture is a reusable structural template — a pre-designed solution for a common problem, with known trade-offs and implementation guidance. It gives teams a starting point they can adapt, not a finished design they must copy.
Examples:
| Problem | Reference Architecture |
|---|---|
| "We need a cloud landing zone" | Cloud landing zone reference — networking, security, IAM, logging |
| "We need an integration platform" | Integration platform reference — API gateway, event broker, message queue |
| "We need a data platform" | Data platform reference — ingestion, storage, processing, serving layers |
| "We need a microservices foundation" | Microservices reference — service mesh, observability, deployment pipeline |
flowchart TD
PROB["Common Problem\nFaced by many teams"] --> REF["📐 Reference Architecture\nPre-designed structure\nKnown trade-offs\nImplementation guidance"]
REF --> ADAPT["🔄 Team Adapts\nCustomise for context\nNot a copy-paste"]
ADAPT --> DELIVER["🚀 Faster Delivery\nStart at 70%, not 0%\nFocus on what is unique"]
What a reference architecture includes: Structure — the components and how they connect. Patterns — the design patterns used and why. Technology choices — recommended technologies with rationale. Trade-offs — what this approach sacrifices and when it's not appropriate. Implementation guidance — how to build it — not what to build. Variations — different configurations for different contexts.
Reference architecture vs related concepts: Standard — a reference architecture implements and references standards. Pattern — a reference architecture combines multiple patterns into a coherent structure. Platform — a reference architecture can become a platform when implemented and shared. Blueprint — often used interchangeably — blueprint implies more specificity.
Reference architectures = reusable designs for common problems — start at 70%, focus on what's unique.
Try it yourself — The reference check
What common problems do your teams face repeatedly?
| Problem | Reference architecture exists? | If not, should there be one? |
|---|---|---|
If teams are designing from scratch for recurring problems, you're wasting effort.
4. How to create standards that get adopted — Not just written
Most organisations have standards that nobody follows. They're written once, published in a wiki, and ignored.
Standards get adopted when three conditions are met: They solve a real problem — teams understand why the standard exists. They're easy to follow — clear, accessible, with examples. They're enforced consistently — there are consequences for ignoring them.
flowchart TD
ADOPT["Standards Get Adopted"] --> WHY["Teams Understand Why\nSolves a real problem\nNot arbitrary rules"]
ADOPT --> EASY["Easy to Follow\nClear, accessible,\nwith examples"]
ADOPT --> ENFORCE["Enforced Consistently\nConsequences for ignoring\nRewards for following"]
WHY --> SUCCESS["✅ Adoption"]
EASY --> SUCCESS
ENFORCE --> SUCCESS
FAIL["Standards Nobody Follows"] --> NO_WHY["Don't understand why\nFeels arbitrary"]
FAIL --> HARD["Hard to find\nBuried in a wiki"]
FAIL --> NO_ENFORCE["Not enforced\nNo consequences"]
NO_WHY --> FAIL2["❌ Adoption Failure"]
HARD --> FAIL2
NO_ENFORCE --> FAIL2
Practical adoption tactics: Co-create with teams — standards written with teams get adopted; standards imposed on teams get resisted. Start with pain — standardise the things that are already hurting — teams welcome relief. Provide examples — "Here's how to follow this standard in your code" — not just the rule. Make it findable — in the repo README, not buried in a wiki. Integrate into tooling — linting, CI/CD checks, architecture fitness functions. Celebrate compliance — recognise teams that follow standards — not just punish those who don't.
The adoption lifecycle: Identify need (common problem facing multiple teams) → Draft standard (with affected teams, not imposed) → Pilot (1-2 teams adopt first, refine based on feedback) → Publish (clear, accessible, with examples) → Integrate (tooling, CI/CD, onboarding) → Measure (adoption rate, compliance rate) → Evolve (review and update as context changes).
Measuring adoption: Awareness — do teams know the standard exists? Target: 100% of affected teams. Understanding — do teams understand what the standard requires? Target: >80%. Adoption — are teams following the standard? Target: >70% within 6 months. Compliance — are there exceptions or violations? Target: <10% exception rate. **Satisfaction** — do teams find the standard helpful? Target: >60% positive.
Standards get adopted when they solve a problem, are easy to follow, and are enforced — co-create with teams, start with pain.
Try it yourself — The adoption check
For your current standards:
| Tactic | In place? | Evidence |
|---|---|---|
| Co-created with teams | ||
| Started with pain | ||
| Examples provided | ||
| Findable (not buried in wiki) | ||
| Integrated into tooling | ||
| Compliance celebrated |
If fewer than four are in place, your standards aren't being adopted — they're being ignored.
5. Governing standards — How they're maintained, updated, and retired
Standards that never change become obsolete. Standards that change without process become chaotic.
Standards governance is the discipline of reviewing, updating, and retiring standards — keeping them relevant without creating chaos.
The lifecycle:
| Stage | What happens |
|---|---|
| Proposed | A new standard is drafted and under review |
| Active | The standard is in force — teams must follow it |
| Under review | The standard is being evaluated — context may have changed |
| Updated | A new version is published — teams transition |
| Deprecated | The standard is no longer recommended — migrate away |
| Retired | The standard is removed — no longer applies |
flowchart LR
PROP["Proposed\nDrafted, under review"] --> ACTIVE["Active\nIn force — follow it"]
ACTIVE --> REVIEW["Under Review\nContext may have changed"]
REVIEW --> UPDATE["Updated\nNew version published"]
REVIEW --> DEPRECATE["Deprecated\nNo longer recommended"]
UPDATE --> ACTIVE
DEPRECATE --> RETIRE["Retired\nRemoved"]
Governance rules: Review annually — context changes — standards must keep up. Change with process — no silent changes — teams need to know what changed. Deprecate before retiring — give teams time to migrate away. Log all changes — history of what changed and why — like ADRs for standards. Communicate broadly — standards changes affect many teams — notify everyone.
The review cycle: Quarterly — new proposed standards, exceptions log. Architecture board. Annually — full standards register — relevance, adoption, compliance. Architecture board + domain architects. Event-triggered — major technology changes, security incidents, vendor EOL. Architecture board.
Standards change management: Standards change needed → What triggered it? (Technology shift, security, feedback) → Draft updated standard (new version with rationale) → Architecture board review (challenge and approve) → Communicate change (all affected teams notified) → Transition period (teams migrate to new standard) → New standard active, old version deprecated.
Standards governance = review, update, deprecate, retire — keep them relevant without creating chaos.
Try it yourself — The governance check
When was your last standards review?
| Question | Your answer |
|---|---|
| When were standards last reviewed? | |
| Are there deprecated standards still in use? | |
| Is there an exception log? | |
| Are teams notified when standards change? |
If you can't answer the first question, your standards are stale.
6. Reference architecture examples — Cloud landing zone, integration platform, data platform
Reference architectures are abstract until you see concrete examples.
Three reference architectures are relevant to almost every organisation:
1. Cloud Landing Zone — The foundational structure for deploying workloads in the cloud — networking, security, identity, logging, cost management. Components: Network topology (VPCs, subnets, peering), Identity & access management (IAM, federation), Security baseline (encryption, firewall, WAF), Logging & monitoring (centralised, cross-account), Cost management (budgets, alerts, tagging), Deployment pipeline (IaC, CI/CD).
2. Integration Platform — The shared infrastructure for connecting systems — APIs, events, messaging, transformation. Components: API gateway (rate limiting, auth, versioning), Event broker (async, durable, ordered), Message queue (task distribution, retry), Transformation layer (schema mapping, enrichment), Service registry (discovery, health), Observability (tracing, logging, metrics).
3. Data Platform — The shared infrastructure for managing, processing, and serving data — ingestion, storage, processing, serving. Components: Ingestion (batch + streaming connectors), Storage (data lake + warehouse), Processing (ETL/ELT, transformation), Serving (APIs, BI connectors, ML feature store), Governance (catalogue, lineage, access control), Quality (validation, monitoring, alerting).
flowchart TD
subgraph CLOUD["☁️ Cloud Landing Zone"]
direction LR
NET["Networking"] --> IAM["Identity"]
IAM --> SEC["Security"]
SEC --> LOG["Logging"]
LOG --> COST["Cost"]
end
subgraph INTEG["🔗 Integration Platform"]
direction LR
API["API Gateway"] --> BROKER["Event Broker"]
BROKER --> QUEUE["Queue"]
QUEUE --> TRANS["Transform"]
end
subgraph DATA["📊 Data Platform"]
direction LR
INGEST["Ingestion"] --> STORE["Storage"]
STORE --> PROC["Processing"]
PROC --> SERVE["Serving"]
end
Additional reference architectures worth considering: Microservices foundation — service mesh, observability, deployment pipeline. DevSecOps pipeline — CI/CD with security scanning, compliance gates. Identity platform — authentication, authorisation, federation, SSO. Observability platform — logs, metrics, traces, alerting, dashboards. AI/ML platform — model training, serving, feature store, monitoring. Multi-cloud governance — consistent policies across cloud providers.
Every organisation needs at least three reference architectures — cloud landing zone, integration platform, data platform.
Try it yourself — The reference library
Which reference architectures does your organisation have?
| Reference Architecture | Exists? | Operationalised beyond document? |
|---|---|---|
| Cloud landing zone | ||
| Integration platform | ||
| Data platform | ||
| Microservices foundation | ||
| Observability platform |
If you have documents but no starter kits or platforms, your references aren't being adopted.
7. The balance between consistency and autonomy — When to standardise, when not to
Too much standardisation kills innovation and team ownership. Too little creates chaos and duplication.
The right balance depends on the context — standardise the commodity, leave the differentiating work to teams.
The principle: Commodity work → Standardise → "Use the agreed approach." Differentiating work → Autonomy → "Choose what fits your context."
| Work type | Standardise? | Example |
|---|---|---|
| Commodity | Yes — everyone does it the same way | Logging, authentication, CI/CD, encryption |
| Common | Provide reference — teams adapt | Integration patterns, data pipelines, API design |
| Differentiating | No — teams choose what creates advantage | Algorithm design, UX, domain-specific tooling |
flowchart TD
WORK["Work Type"] --> COM["🔧 Commodity\nSame for everyone\nStandardise"]
WORK --> COMMON["📐 Common\nSimilar problems\nReference architecture"]
WORK --> DIFF["✨ Differentiating\nCreates advantage\nFull autonomy"]
COM --> EX1["Logging, auth, CI/CD\nEncryption, networking"]
COMMON --> EX2["Integration, data pipelines\nAPI design, deployment"]
DIFF --> EX3["Algorithms, UX\nDomain-specific tools"]
COM --> FLEX["Low flexibility\nUse the standard"]
COMMON --> FLEX2["Medium flexibility\nAdapt the reference"]
DIFF --> FLEX3["High flexibility\nTeam decides"]
The test: "Would every team benefit from doing this the same way?" → Standardise. "Would every team benefit from a starting point?" → Reference architecture. "Is this where our competitive advantage lives?" → Autonomy.
The three-tier model: Tier 1: Platform (must standardise) — cloud provider, CI/CD pipeline, logging & monitoring, identity & access. Governance: enforce. Exceptions require board approval. Tier 2: Guided (reference provided) — integration patterns, API design, data pipeline patterns, deployment patterns. Governance: guide. Teams adapt from reference. Tier 3: Autonomous (team decides) — algorithm design, frontend UX, domain-specific tools, internal code structure. Governance: none. Teams own the decision.
This framework prevents over-standardisation — which kills team ownership and innovation. It prevents under-standardisation — which creates duplication and inconsistency. Platform teams own Tier 1; domain teams own Tier 3. The SA role advocates for autonomy in differentiating work; the EA role enforces standardisation in commodity work.
Standardise the commodity, provide references for the common, give autonomy for the differentiating.
Try it yourself — The tier check
Where does your team's work fall?
| Work | Tier | Current governance | Should it be? |
|---|---|---|---|
If commodity work is in Tier 3, you have inconsistency. If differentiating work is in Tier 1, you have rigidity.
8. Reference architecture adoption — How to operationalise so teams actually use them
A reference architecture that lives in a document isn't a reference architecture — it's an aspiration. Adoption requires making it real — implemented, accessible, and supported.
Reference architectures become useful when they're operationalised — turned into implemented platforms, starter kits, or templates that teams can consume directly.
Levels of operationalisation:
| Level | What it means | Example |
|---|---|---|
| Document | The reference exists as a diagram and guide | "Here's how to design an integration platform" |
| Starter kit | Pre-built templates and code teams can copy | Terraform modules for cloud landing zone |
| Implemented platform | A shared service teams can consume directly | Centralised API gateway, managed Kafka cluster |
| Self-service platform | Teams provision and configure without central support | Internal developer platform with golden paths |
flowchart LR
DOC["📄 Document\nDiagram + guide\nTeams implement from scratch"]
DOC --> KIT["📦 Starter Kit\nTemplates + code\nTeams copy and adapt"]
KIT --> IMPL["🏗️ Implemented Platform\nShared service\nTeams consume directly"]
IMPL --> SELF["🚀 Self-Service Platform\nGolden paths\nTeams provision themselves"]
The adoption test: If teams have to build it from a document → low adoption. If teams can copy a template → medium adoption. If teams can consume a service → high adoption. If teams can self-serve → highest adoption.
What makes teams adopt a reference: It saves time — teams adopt what makes them faster. It reduces risk — teams adopt what prevents known failures. It's easy to consume — teams adopt what requires minimal effort. It's well-supported — teams adopt what has someone to call when it breaks. It's not mandated — teams adopt what they choose, not what's forced.
The operationalisation path: Document only — low investment, low adoption. Best for early-stage, small org. Document + examples — low-medium investment, low-medium adoption. Best for orgs with strong engineering culture. Starter kits — medium investment, medium adoption. Best for orgs with multiple teams building similar things. Implemented platform — high investment, high adoption. Best for orgs with scale — many teams, many services. Self-service platform — very high investment, very high adoption. Best for large orgs with platform teams.
Operationalise references from documents → starter kits → platforms → self-service — the further along, the higher the adoption.
Try it yourself — The operationalisation check
Where are your reference architectures?
| Reference | Level | Adoption rate |
|---|---|---|
If everything is at "document" level, your references aren't being used.
Putting it all together
Here's the complete picture in one diagram. This is the mental model worth internalising.
flowchart TD
PROB["Common Problems\nEvery team faces them\nEvery team solves them differently"]
PROB --> STD["📐 Standards\nSettle common decisions once\nPrinciples · Patterns · Technology · Guardrails"]
PROB --> REF["🏗️ Reference Architectures\nReusable templates for common problems\nCloud · Integration · Data · More"]
STD --> GOV["🔧 Governance\nReview, update, deprecate\nKeep standards relevant"]
STD --> ADOPT["🎯 Adoption\nCo-create, start with pain,\nmake easy to follow"]
REF --> OPER["🚀 Operationalise\nDocuments → Starter kits\nPlatforms → Self-service"]
GOV --> BAL["⚖️ Balance\nStandardise commodity\nAutonomy for differentiating"]
ADOPT --> BAL
OPER --> BAL
BAL --> VALUE["✅ Value\nConsistency without rigidity\nSpeed without duplication\nRisk management without bureaucracy"]
The foundation:
Standards settle common decisions once — so teams don't re-debate them every sprint. Without standards, every team solves the same problem differently. Reference architectures are reusable starting points, not straitjackets. They accelerate delivery by letting teams start at 70% instead of 0%. Adoption is a product problem — co-create with teams, make standards easy to follow, and operationalise references into platforms. Standards nobody follows are architecture theatre. Standardise the commodity. Reference the common. Autonomy for the differentiating.
Cheat Sheet — All the key terms
| Concept | One-Line Memory | Key Action |
|---|---|---|
| Standards | Pre-made decisions for common problems | Principles, patterns, technology choices, guardrails |
| Reference architectures | Reusable templates for common problems | Cloud, integration, data, microservices |
| Standards types | Four levels of flexibility | Principles > Patterns > Technology > Guardrails |
| Adoption | Co-create, start with pain, make easy | Solve a real problem, provide examples, enforce consistently |
| Governance | Review, update, deprecate, retire | Annual review, change process, communicate broadly |
| Consistency vs autonomy | Standardise commodity, autonomy for differentiating | Commodity → standard, common → reference, differentiating → team decides |
| Operationalisation | Documents → platforms → self-service | The further along, the higher the adoption |
How to know if this landed
You'll know this has landed when someone stops re-debating common choices every sprint and starts asking "is there a standard for this?" Has a standards register with at least principles, key technology choices, and guardrails. Can explain the difference between a standard and a reference architecture. Has at least 2 reference architectures that teams actually use. Standards are reviewed at least annually — stale standards have been deprecated. Exception process exists — teams can request deviations with justification. Can articulate when to standardise vs when to give autonomy. And reference architectures are operationalised beyond documents — starter kits or platforms.
What changes when the mental model clicks
I've run this session with a multi-team financial services platform where 12 teams were building services independently — every team chose different databases, messaging systems, and API styles. Integration between teams was painful. Hiring was difficult. Security review was overwhelmed. Teams complained about "architecture slowing us down" — but the real problem was lack of standards. The gap at the start is usually not about understanding standards — it's about not having any that teams follow.
What changes after this session:
Teams stop re-debating common choices and start asking "is there a standard for this?" The co-creation exercise — "what pain points should we standardise first?" — is always the moment things click. People stop treating standards as impositions and start treating them as enablers. Their results get better. They stop building incompatible integrations when the real problem was that nobody had settled the common questions.
The operationalisation exercise tends to immediately change how teams think about their reference architectures. They start moving from documents to starter kits to platforms. Their adoption rates go up. They stop documenting references nobody uses when the real problem was that they hadn't made them consumable.
Book a Workshop
Ready to create standards that teams actually follow and reference architectures that accelerate delivery?
or
1-day workshop includes standards register creation with your team leads — starting with real pain points, reference architecture design for your most common problems, adoption strategy — co-creation, tooling integration, measurement, governance process — review cycle, change management, exception handling, consistency vs autonomy framework — where to standardise, where not to, and reference architecture library starter + standards register + architecture principles catalogue.