Enterprise Architecture

Architecture Standards Framework

This is an example of how I approach structuring enterprise architecture governance. It's a layered framework of principles, standards, and reusable patterns, designed to give architecture review boards, domain teams, and delivery squads a shared, traceable system for making and evaluating technology decisions.

The content is aligned to TOGAF 10 and draws from real-world experience governing technology decisions in regulated industries. You can browse the full framework interactively in the Standards Hub.

What problem does this solve?

Most organizations don't have a structured way to govern architecture decisions. Teams choose technologies in isolation, security reviews happen late in the lifecycle, and compliance is reactive rather than systemic. Standards exist as scattered documents that are hard to find, harder to enforce, and disconnected from the principles they're meant to implement.

This framework addresses that by creating a clear chain of traceability: foundational principles establish the “why”, measurable standards establish the “what”, and reusable patterns establish the “how.” Every standard traces back to the principles that justify it. Every pattern maps to the specific standards it satisfies. Teams that adopt an approved pattern know exactly which standards they've already met, and can move through governance faster.

How the framework is structured

Principles20 across 5 domains

High-level beliefs and values that guide architecture decisions. Principles answer “why” by establishing the non-negotiable direction for things like business alignment, simplicity, security posture, data ownership, and operational readiness. They're intentionally stable and don't change often.

Standards94 across 8 domains

Specific, measurable requirements derived from principles. Each standard has a severity (HIGH / MEDIUM / LOW), a governance phase, and in many cases required evidence. Some are fast-path gates—evaluated during initial intake to determine whether a change can proceed without full Architecture Review Board involvement.

Patterns7 reusable blueprints

Reusable implementation blueprints that pre-satisfy multiple standards at once. Patterns cover integration (API, event streaming, batch file transfer), platform service provisioning, operational-to-analytical data pipelines, vendor risk assessment, and operational readiness. Each pattern includes architecture diagrams, implementation steps, verification rules, and templates where applicable.

Principle domains

The five foundational areas that all 20 principles fall under.

BSA

Business & Strategy Alignment

Technology decisions tied to business objectives and long-term direction.

SRC

Simplicity, Reuse & Consistency

Favor simple, reusable, and consistent designs to reduce risk and cost.

SRD

Security & Risk by Design

Security and risk as core design concerns, not afterthoughts.

DEA

Data as an Enterprise Asset

Data as a shared, governed resource that must be trusted and reusable.

SRO

Scalability, Resilience & Operability

Solutions that scale, recover, and are operable within real constraints.

Standard domains

94 standards organized across 8 TOGAF-aligned architecture domains.

DATA

Data Architecture

11 standards
APP

Application Architecture

10 standards
INT

Integration & Interface

12 standards
OPS

Operability & Lifecycle

12 standards
PLAT

Platform & Hosting

12 standards
SEC

Security & Risk

13 standards
VEND

Vendor & External

12 standards
GOV

Governance / Risk

12 standards

Why I built it this way

I've seen architecture governance done many ways: as spreadsheets nobody updates, as wiki pages that drift out of date, as review boards that become bottlenecks because nobody knows what “compliant” means until they're in the room. The common thread is that governance fails when the rules aren't structured, traceable, or easy to act on.

This framework is designed around a few ideas I keep coming back to:

  • Traceability over documentation. Every standard should trace to a principle, and every pattern to the standards it satisfies. If you can't follow the chain, you can't govern it.
  • Fast paths for compliant teams. Governance shouldn't penalize teams that do the right thing. If a team adopts an approved pattern and meets the gating standards, they should be able to move without waiting for a review board.
  • Severity as a prioritization tool. Not all standards are equally important. Classifying by severity and phase lets organizations adopt the framework incrementally rather than all at once.
  • Patterns as the bridge to implementation. Principles and standards describe what good looks like. Patterns describe how to get there. That bridge is where most frameworks fall short.

Browse the full framework

20 principles, 94 standards, 7 patterns — all navigable and cross-linked.

Open Standards Hub