TOGAF Overview

TOGAF — The Open Group Architecture Framework — is an open, vendor-neutral framework and method for developing and governing enterprise architecture. First released in 1995 and now at version 10 (the "TOGAF Standard"), it is maintained by The Open Group and used by a majority of the Global 50.

The Six Parts of the TOGAF Standard

Who Uses It

Enterprise architects, solution architects, CIOs/CTOs, and transformation programs use TOGAF to standardize how architecture is done across teams. Certifications: TOGAF Foundation (Level 1) and TOGAF Certified (Level 2).

TOGAF Core Concepts

A handful of concepts recur throughout TOGAF. Getting these straight makes the rest of the framework click.

Baseline → Target → Transition

Architecture work is always about moving from where you are (Baseline) to where you want to be (Target), via one or more achievable steps (Transition architectures). The difference between baseline and target is found through Gap Analysis.

TOGAF Architecture Domains

TOGAF structures all architecture into four domains, often abbreviated BDAT. ADM Phases B, C, and D produce them.

Data + Application together are often called Information Systems Architecture (Phase C). The domains are layered: business drives information systems, which run on technology.

Architecture Development Method (ADM)

The ADM is the heart of TOGAF — a tested, iterative, step-by-step method for developing and managing the lifecycle of an enterprise architecture. It runs as a continuous cycle: a Preliminary phase to set up, then eight phases (A–H), all revolving around a central Requirements Management process that feeds and is fed by every phase.

The ADM Lifecycle — Visual

The Phases in One Line Each

Key Properties

• Iterative — across the whole cycle, between phases, and within a phase.
• Requirements-driven — Requirements Management sits in the center, touching every phase.
• Tailorable — adapt phases, depth, and artifacts to your organization (an "ADM iteration" model).
• Scoped by iteration — Baseline-first vs Target-first, breadth, depth, time period.

Preliminary Phase

The Preliminary Phase happens before the ADM cycle begins. It answers "how do we do architecture here?" — establishing the architecture capability rather than producing an architecture itself.

Key Activities

• Define the scope of the enterprise affected and the architecture footprint.
• Establish the architecture team & organization (and the ARB).
• Tailor TOGAF and select tools — define the Architecture Framework to use.
• Define and ratify the Architecture Principles.
• Set up the governance and repository.

Key Outputs

Tailored architecture framework, Architecture Principles, initial Architecture Repository, Request for Architecture Work (often the trigger into Phase A), and the governance model.

Architecture Vision (Phase A)

Phase A kicks off an architecture cycle. It takes the Request for Architecture Work and produces an agreed, high-level Architecture Vision — a compelling, aspirational summary of the target and the value it delivers — plus a Statement of Architecture Work that is formally approved before detailed work starts.

Phase A Flow — Visual

Key Activities

• Confirm scope, constraints, and assumptions; identify stakeholders & concerns.
• Confirm business goals, drivers, and KPIs.
• Evaluate business capabilities and assess readiness for transformation.
• Define scope and develop the high-level Architecture Vision (often with a Business Scenario).
• Identify risks and secure approval of the Statement of Architecture Work.

Key Deliverables

Architecture Vision document, approved Statement of Architecture Work, refined Architecture Principles, Communications Plan, and a Capability Assessment.

Business Architecture (Phase B)

Phase B develops the Business Architecture — describing how the enterprise operates to meet its goals. It is usually done first among the domain architectures because it demonstrates business value and underpins the Data, Application, and Technology work that follows.

What It Describes — Visual

Key Activities

• Develop the Baseline and Target Business Architecture.
• Model business capabilities, value streams, processes, organization, functions, and services.
• Perform Gap Analysis between baseline and target.
• Resolve impacts across the Architecture Landscape; update the requirements.

Common Artifacts

Data Architecture (Phase C)

Data Architecture is one half of Phase C (Information Systems Architecture). It defines the structure of the organization's logical and physical data assets and the data management resources — independent of any specific application or technology.

Layers of Data Architecture — Visual

Key Activities

• Develop Baseline & Target Data Architecture; build the logical data model and data entity catalog.
• Map data entities to business functions and to applications (which app is the system of record?).
• Address data governance, master data management, quality, security & classification.
• Run Gap Analysis; identify data migration needs.

Common Artifacts

Data Entity/Data Component catalog, Data Entity/Business Function matrix, Application/Data matrix (CRUD), Logical/Physical Data diagrams, Data Migration & Data Lifecycle diagrams.

Application Architecture (Phase C)

The other half of Phase C. Application Architecture defines the major application systems needed to process data and support the business — their interactions and relationships to core business processes. It describes applications as logical groups of capability, not products.

Application Landscape — Visual

Key Activities

• Develop Baseline & Target Application Architecture; build the application portfolio catalog.
• Map applications to business functions/services and to data entities (CRUD).
• Define application interactions, interfaces, and the integration approach.
• Identify candidates for retire / consolidate / replace; run Gap Analysis.

Common Artifacts

Application Portfolio catalog, Interface catalog, Application/Function & Application/Data matrices, Application Communication diagram, Application & User-Location diagram, Software Engineering / Distribution diagrams.

Technology Architecture (Phase D)

Phase D defines the technology infrastructure — the hardware, software platforms, networks, and runtime services — needed to support the application and data architectures. It turns logical applications into something deployable.

Technology Stack — Visual

Key Activities

• Develop Baseline & Target Technology Architecture; build the technology portfolio / standards catalog.
• Map technology components to the applications they host.
• Address platform decisions: on-prem vs cloud, containers, networking, NFRs (performance, availability, security).
• Run Gap Analysis; feed candidate solutions into Phase E.

Common Artifacts

Technology Standards & Technology Portfolio catalogs, Application/Technology matrix, Environments & Locations diagram, Platform Decomposition diagram, Network Computing/Hardware diagram, Processing diagram.

Opportunities & Solutions (Phase E)

Phase E is the first phase concerned with delivery. Having defined target architectures (B–D) and the gaps, it identifies how to deliver them — grouping gaps into work packages and defining the high-level migration approach and transition architectures.

Key Activities

• Consolidate the Gap Analysis results from Phases B, C, D.
• Determine the delivery approach (buy vs build, increments, big-bang vs phased).
• Group requirements/gaps into Work Packages.
• Identify Transition Architectures if the target can't be reached in one step.
• Produce the outline Implementation & Migration Strategy and an initial Architecture Roadmap.

Key Outputs

Work packages, candidate Solution Building Blocks, Transition Architectures, the consolidated gaps/solutions, and the initial Architecture Roadmap — all refined into a detailed plan in Phase F.

Migration Planning (Phase F)

Phase F finalizes how and when the architecture will be delivered. It turns the work packages and transition architectures from Phase E into a detailed, costed, risk-assessed, and sequenced Implementation & Migration Plan — agreed with the business and aligned to project/portfolio management.

From Gaps to a Sequenced Plan — Visual

Key Activities

• Confirm interactions with the enterprise's project & portfolio management.
• Assign business value to each work package; prioritize by value, cost, risk, and dependencies.
• Estimate resource requirements and timings; confirm Transition Architecture increments.
• Perform risk assessment and confirm readiness factors.
• Complete the Implementation & Migration Plan and finalize the Architecture Definition Document.

Key Deliverables

Implementation & Migration Plan, finalized Architecture Roadmap & Transition Architectures, Implementation Governance Model, and the completed Architecture Definition Document.

Implementation Governance (Phase G)

Phase G provides architectural oversight of the implementation. As projects build the solution, Phase G ensures they conform to the target architecture and its standards, handling deviations through governance.

Key Activities

• Confirm scope & priorities with delivery; guide solution development.
• Perform architecture compliance reviews on projects.
• Issue Architecture Contracts between the architecture function and implementers.
• Manage deviations and grant dispensations where justified.

Key Outputs

Architecture Contract (signed), Compliance Assessments, change requests for the architecture, and a compliant, deployed solution.

Architecture Change Management (Phase H)

Phase H ensures the architecture continues to be fit for purpose after it's deployed. It establishes the process for managing changes to the baseline — deciding whether a change is a simple update, an incremental change, or a trigger for a whole new ADM cycle.

Change Classification

Key Activities

• Monitor technology & business change; manage risks.
• Assess change requests against the architecture and its value.
• Decide the change path and govern the architecture lifecycle.

Requirements Management

Requirements Management sits at the center of the ADM — it's not a phase but a continuous process that every phase both feeds and draws from. Its job is to capture, store, validate, prioritize, and manage changes to architecture requirements throughout the entire lifecycle.

Why It's in the Center — Visual

Key Activities

• Identify & document requirements (often via Business Scenarios in Phase A).
• Baseline, prioritize, and store requirements in the repository.
• Assess impact of changing requirements on current and prior phases.
• Implement requirement changes and track status to closure.

What It Is Not

It does not dispose of requirements or make the architecture decisions — the individual phases do that. Requirements Management is the process and repository that keeps every phase working from the same agreed, current set of requirements.

Architecture Principles

Architecture Principles are general rules and guidelines, intended to be enduring, that inform and constrain how an organization sets about fulfilling its mission through architecture. They are established in the Preliminary Phase and govern every decision in the ADM.

The Four-Part Structure of a Principle — Visual

What Makes a Good Principle

TOGAF defines five quality criteria: Understandable, Robust, Complete, Consistent, Stable.

Typical Principle Categories

• Business — e.g. "Primacy of Principles", "Business Continuity", "Compliance with Law".
• Data — e.g. "Data is an Asset", "Data is Shared", "Common Vocabulary".
• Application — e.g. "Technology Independence", "Ease of Use".
• Technology — e.g. "Control Technical Diversity", "Interoperability".

Architecture Governance

Architecture Governance is the practice of managing and controlling architectures at an enterprise level. It ensures that what gets built actually conforms to the agreed architecture, principles, and standards — and that deviations are deliberate, justified, and recorded.

The Governance Framework — Visual

The Four Domains of Governance

TOGAF aligns architecture governance with corporate, technology, IT, and architecture governance. Good governance is characterized by: Discipline, Transparency, Independence, Accountability, Responsibility, Fairness.

Key Mechanisms

• Architecture Review Board (ARB) — the decision-making body.
• Architecture Compliance Reviews — formal checks of projects against the architecture.
• Architecture Contracts — agreements binding teams to the architecture.
• Dispensations — time-boxed, recorded exceptions when full compliance isn't feasible.

Architecture Review Board (ARB)

The Architecture Board (often called the Architecture Review Board) is the cross-organization body responsible for overseeing the implementation of the architecture governance strategy. It is the place where architecture decisions, exceptions, and conflicts are resolved with authority.

Where the ARB Sits — Visual

Responsibilities

• Provide the basis for all decision-making regarding the architecture.
• Consistency between sub-architectures; identify reusable components.
• Enforce architecture compliance; review and approve dispensations.
• Monitor and control architecture contracts; improve the architecture practice itself.
• Resolve conflicts/ambiguities and provide advice and guidance.

Composition & Cadence

Typically chaired by a lead/chief architect, with representation from business and IT stakeholders. It meets on a regular cadence plus on-demand for major decisions, and has a clear, documented operating model and authority.

Compliance Assessment

Architecture Compliance Assessment is the formal review of a project or solution against the target architecture, principles, and standards — usually conducted in Phase G and owned by the ARB.

Levels of Conformance

Risk Management

Risk management is an ADM-wide technique to identify, classify, and mitigate risks before and during transformation. It runs continuously, with formal touchpoints in Phases A (initial), E/F (planning), and G (governance).

The Risk Process

• Identify risks (business, technical, delivery, security).
• Classify by impact (Catastrophic→Negligible) and frequency → an Effect × Frequency matrix.
• Determine initial risk level, then apply mitigation to get a residual risk.
• Monitor residual risks via governance.

Two Risk States

Initial risk = before mitigation; residual risk = after mitigation. The gap shows the value of the mitigation. Risks that remain too high after mitigation must be escalated to the ARB / sponsors.

Architecture Repository

The Architecture Repository is where an enterprise stores and manages all architecture assets — models, patterns, standards, principles, and deliverables — so they can be governed and reused across the organization.

The Six Classes of Content

Enterprise Continuum

The Enterprise Continuum is a classification model and "view" of the repository that organizes reusable architecture assets along a spectrum from the most generic (applicable to any organization) to the most specific (built for your enterprise). It helps architects find and reuse assets rather than reinventing them.

The Continuum — Visual

The Two Continua

• Architecture Continuum — reusable architecture building blocks (ABBs): Foundation → Common Systems → Industry → Organization-Specific.
• Solutions Continuum — the matching reusable solution building blocks (SBBs) that realize each architecture level.

Architecture Content Framework

The Content Framework defines what the ADM produces — a structured model of all the work products, so outputs are consistent and well-defined regardless of who creates them.

Three Categories of Work Product

It is underpinned by the Architecture Metamodel, which defines the formal entities (actors, functions, data entities, application components…) and their relationships.

Architecture Artifacts

Artifacts are the granular architectural work products. TOGAF groups them into three types — Catalogs, Matrices, and Diagrams — and organizes them by ADM phase. They are the concrete things architects draw and tabulate.

The Three Artifact Types — Visual

Views & Viewpoints

Artifacts realize views — representations of the system from the perspective of related concerns. A viewpoint defines how to construct a view (the conventions/template); the view is what a specific stakeholder actually sees. This addresses ISO/IEC 42010 stakeholder concerns.

Examples by Domain

Architecture Deliverables

Deliverables are the formal, contractual work products of the ADM — reviewed, agreed, signed off, and stored in the repository. They are the milestones that move the architecture forward and bind stakeholders.

Key Deliverables Across the ADM

Architecture Building Blocks (ABB) — and ABB vs SBB

A Building Block is a reusable, replaceable package of functionality. TOGAF distinguishes two kinds: ABBs describe what capability is required (technology-agnostic, defined during architecture), while SBBs describe how it is implemented (concrete products, defined during the Solutions work).

ABB vs SBB — Visual

Comparison

Solution Building Blocks (SBB)

Solution Building Blocks are the concrete, implementable components that realize the Architecture Building Blocks. They are vendor- and product-aware and live in the Solutions Continuum. SBBs are what delivery teams actually procure, configure, and build.

Characteristics

• Define the specific products, custom components, or services used.
• Fulfil the functions and conform to the interfaces/standards specified by their ABB.
• Are organization- and project-specific; selected in Phase E (Opportunities & Solutions).
• Captured in the repository for reuse across projects.

How SBBs Relate to the ADM

Architecture Capability Framework

The Architecture Capability Framework describes how to establish and operate an architecture practice within an enterprise — the organization, roles, skills, processes, and governance needed to do architecture, as opposed to the architecture itself.

What It Covers

• Architecture Governance & the Architecture Board (ARB).
• Architecture Compliance process.
• Architecture Skills Framework — roles & competencies of architects.
• Architecture Maturity Models — assessing & improving the practice.
• Setting up the Architecture Repository & tools.

Stakeholder Management

Stakeholder Management is a key ADM technique for identifying the people who matter to an architecture, understanding their concerns, and tailoring communication so the architecture gains and keeps their support. Architecture fails politically far more often than technically — this is how you prevent that.

The Power / Interest Grid — Visual

The Process

1. Identify stakeholders (sponsors, users, operators, regulators, suppliers…).
2. Classify by power and interest (the grid above) to set engagement level.
3. Determine concerns — what each cares about (cost, risk, security, usability…).
4. Map concerns to viewpoints — choose the views/artifacts that answer them.
5. Tailor the Communications Plan for each group.

Concerns → Views → Viewpoints

A CFO's concern (cost) and a security officer's concern (risk) need different views of the same architecture. Stakeholder Management drives which artifacts you actually produce — you build the views your stakeholders need, not every possible diagram.

Business Capability Mapping

A Business Capability is what a business does (an ability), independent of how or who does it. Capability Mapping produces a stable, hierarchical map of these abilities — a foundational anchor model in modern Business Architecture.

Why Capabilities Are Powerful

• Stable — "Manage Customer Relationships" persists even as processes, org charts, and tools change.
• Heat-mappable — overlay strategy, cost, risk, or maturity to spotlight investment areas.
• Bridge to IT — map capabilities → applications → technology to see coverage & gaps.

Structure

Usually a 2–3 level decomposition (Level 1 broad domains → Level 2/3 sub-capabilities). Each is a noun phrase ("Order Management"), never a verb/process ("Process Orders").

Value Streams

A Value Stream is an end-to-end sequence of value-adding stages that an enterprise performs to deliver value to a stakeholder (usually a customer). It views the business from the perspective of value delivery, complementing the capability map.

Example — "Acquire Product"

Search → Select → Order → Pay → Receive. Each stage delivers incremental value and is enabled by capabilities.

Value Streams + Capabilities

• Value streams show flow (how value is created, left to right).
• Capabilities show ability (what's needed, as a stable inventory).
• Cross-mapping them reveals which capabilities are critical to which value — and where they're weak.

Gap Analysis

Gap Analysis is the core TOGAF technique for comparing the Baseline architecture with the Target architecture to identify what is missing, what must be removed, and what stays. It is performed in every domain phase (B, C, D) and the consolidated gaps drive Phases E and F.

The Gap Matrix — Visual

How to Read It

• List Baseline elements as rows, Target elements as columns, plus an "Eliminated" column and a "New" row.
• Diagonal matches = retained (no action).
• A baseline element with no target match → falls in Eliminated (decommission).
• A target element with no baseline match → a cell in the New row = a gap to fill.

Baseline Architecture

The Baseline Architecture (the "as-is") describes the existing state of the enterprise across the business, data, application, and technology domains — before any proposed change.

Why It Matters

• You can't plan a journey without knowing the starting point — it's one half of every Gap Analysis.
• Reveals duplication, technical debt, and reusable assets.
• Captured in each domain phase as a "Baseline ... Architecture" view.

Target Architecture

The Target Architecture (the "to-be") describes the desired future state across all four domains — what the enterprise wants to achieve to meet its goals, driven by the Architecture Vision and requirements.

Characteristics

• Aligned to strategy, principles, and the Architecture Vision.
• Defined per domain (Target Business / Data / Application / Technology Architecture).
• The other half of Gap Analysis; the destination the roadmap drives toward.

Transition Architecture

A Transition Architecture is a formal, deployable intermediate state between the Baseline and the Target. Because large targets can't be reached in one step, transitions break the journey into achievable, value-delivering increments — each one a coherent architecture in its own right.

Stepping Stones to the Target — Visual

Key Points

• Defined in Phase E, detailed and sequenced in Phase F.
• Each transition must be a working, value-delivering state — not an incomplete mess.
• Aligns architecture increments to the organization's appetite for change and funding cycles.
• Documented in the Architecture Definition Document and shown on the Architecture Roadmap.

Architecture Roadmaps

The Architecture Roadmap lists individual work packages and transition architectures on a timeline, showing how the enterprise moves from Baseline to Target. It is the bridge between architecture and delivery — the artifact executives and PMOs actually use to fund and schedule change.

A Roadmap on a Timeline — Visual

What's On It

• Work packages with start/end, dependencies, and the transition they belong to.
• Transition Architectures as milestones.
• Business value & priority (from Phase F), risks, and resource needs.

Lifecycle

An initial roadmap appears in Phase E, is finalized and costed in Phase F, governed in G, and updated in H as change requests arrive. It is a living artifact, not a one-time Gantt chart.

Work Packages

A Work Package is a logically grouped set of actions — a project or project increment — that delivers part of the architecture. Work packages are how gaps get organized into deliverable chunks of work.

Where They Come From

• Gaps (from Gap Analysis) are grouped into work packages in Phase E.
• Each work package implements specific Solution Building Blocks.
• Prioritized and sequenced into the roadmap & migration plan in Phase F.
• Handed to delivery teams and governed via Architecture Contracts in Phase G.

Reference Architectures

A Reference Architecture is a proven, reusable template for a class of solutions — a generic blueprint that organizations specialize for their own needs. They live in the Reference Library of the repository and sit on the generic end of the Enterprise Continuum.

TOGAF's Built-in Reference Models

• TRM (Technical Reference Model) — a taxonomy of generic platform services & their interfaces (the "foundation architecture").
• III-RM (Integrated Information Infrastructure Reference Model) — focuses on Boundaryless Information Flow.

Industry Examples

BIAN (banking), eTOM/Frameworx (telecom), ARTS (retail), cloud provider Well-Architected frameworks. You adopt one and specialize it rather than starting from a blank page.

Solution Blueprinting

Solution Blueprinting is the practice of producing a detailed, implementable design for a specific solution — translating architecture (ABBs) into concrete Solution Building Blocks, components, integrations, and deployment topology.

What a Blueprint Captures

• Selected products/components (SBBs) and how they fit together.
• Integration points, data flows, and interfaces.
• Deployment topology, environments, and NFRs (security, performance, availability).
• Compliance to enterprise principles & standards.

Architecture Patterns

An Architecture Pattern is a reusable solution to a recurring problem in a given context. Patterns capture proven design wisdom so architects don't re-solve the same problems — TOGAF treats them as reusable assets in the Reference Library.

Pattern Structure

Typically: Name · Problem/Context · Forces · Solution · Resulting Context · Examples (the classic pattern template).

Common Enterprise Patterns

• Integration — API Gateway, Publish/Subscribe, Event-Driven, ESB.
• Application — Layered, Microservices, CQRS, Saga.
• Resilience — Circuit Breaker, Bulkhead, Retry.
• Data — Master Data Management, Data Lake, Polyglot Persistence.

Security Architecture

Security Architecture is a cross-cutting concern woven through every ADM phase rather than a single phase. It ensures confidentiality, integrity, and availability are designed in — not bolted on. TOGAF integrates with frameworks like SABSA and O-ESA for depth.

Security Across the ADM

Core Concerns

• Identity & access management (authN/authZ), least privilege.
• Data protection — encryption in transit & at rest, classification.
• Defense in depth, zero-trust, and regulatory compliance (GDPR, PCI-DSS).

Integration Architecture

Integration Architecture defines how applications and systems connect and exchange data across the enterprise. As application portfolios grow, integration becomes the dominant source of complexity — a deliberate integration architecture prevents a tangle of point-to-point links.

Integration Styles

Principles

• Prefer loose coupling and well-defined contracts/interfaces.
• Standardize on enterprise API & event standards (governed in Phase D).
• Avoid point-to-point sprawl; use gateways/brokers as integration hubs.

Cloud Architecture using TOGAF

Migrating to the cloud is a textbook use of the ADM: it's a transformation spanning all four domains, needs governance, and benefits hugely from transition architectures. TOGAF provides the method; cloud Well-Architected frameworks provide the reference content.

Mapping Cloud Migration onto the ADM — Visual

The 7 R's of App Disposition (Phase C/E)

Rehost (lift & shift) · Replatform · Repurchase (SaaS) · Refactor (cloud-native) · Retire · Retain · Relocate. Each app gets a disposition, captured as a Solution Building Block decision.

Key TOGAF Touchpoints

• Principles — "cloud-first", "design for failure", "automate everything".
• ABB → SBB — "object storage capability" (ABB) → "Amazon S3" (SBB), keeping the architecture portable.
• Transition Architectures — migrate in waves; never big-bang an enterprise.
• Governance — a cloud landing zone + guardrails is Architecture Governance made executable.

Microservices Architecture using TOGAF

Microservices is an Application/Technology architecture style; TOGAF supplies the enterprise context that keeps a microservices estate aligned to business capabilities and governed instead of sprawling into chaos.

Capabilities → Services — Visual

TOGAF Adds Discipline

• Service boundaries from capabilities — Phase B business capabilities are the natural seams (bounded contexts), avoiding arbitrary splits.
• Data ownership — Data Architecture enforces each service owns its data (one system of record).
• Standards & patterns — Phase D mandates API/event standards, observability, resilience patterns (Circuit Breaker, Saga).
• Governance — the ARB prevents "every team a snowflake"; reusable SBBs (gateway, mesh) are shared.

Legacy Modernization using TOGAF

Modernizing legacy systems is a high-risk transformation where TOGAF's structured, incremental approach shines — establishing a clear baseline, a target, and safe transitions rather than a risky rip-and-replace.

Modernization Strategies (per app)

Why TOGAF Fits

• Baseline architecture surfaces hidden dependencies and risk.
• Strangler-fig via Transition Architectures — incrementally replace, delivering value each wave.
• Governance ensures new components meet current standards.

Digital Transformation using TOGAF

Digital transformation re-imagines business models, customer experiences, and operations using digital technology. As an enterprise-wide, strategy-driven change across all domains, it is exactly what the ADM is built to orchestrate.

How TOGAF Steers It

• Phase A — anchor transformation to business strategy & measurable outcomes; assess readiness.
• Phase B — re-map capabilities & value streams for the digital operating model.
• Phases C/D — target data/app/tech for cloud, data, AI, APIs.
• Phases E–H — sequence change into transitions; govern continuously.

TOGAF and Agile

TOGAF and Agile are complementary, not contradictory. EA sets the intentional direction and guardrails; Agile teams deliver within them with autonomy. The key is doing "just enough architecture" at the right altitude.

How They Combine

• Iterative ADM — run the ADM in increments; don't big-design-up-front.
• Architecture runway — EA provides just-in-time enabling architecture ahead of teams.
• Guardrails over gates — principles & standards let teams move fast safely.
• Lightweight artifacts — produce the minimum viable architecture that adds value.

Altitudes

Enterprise architecture (strategic, slow-changing) → Solution architecture (per initiative) → Team architecture (sprint-level). TOGAF governs the top; Agile owns the bottom; they meet at the runway.

TOGAF and DevOps

DevOps is an operating-model and technology concern that TOGAF addresses in Business (ways of working) and Technology (toolchain, platforms) architectures. EA ensures DevOps practices are adopted consistently and securely across teams.

TOGAF's Role

• Business Architecture — define the DevOps operating model, team topologies, and capabilities.
• Technology Architecture — standardize the CI/CD toolchain, platform engineering, IaC.
• Principles — "automate everything", "you build it, you run it", "shift-left security".
• Governance — policy-as-code & automated compliance checks in pipelines (governance made continuous).

Architecture Maturity Models

An Architecture Maturity Model assesses how capable and consistent an organization's architecture practice is, providing a baseline and a path for improvement. TOGAF references models like the ACMM (Architecture Capability Maturity Model).

The Five Maturity Levels (CMM-style)

Use

• Assess current maturity → set a realistic target → close gaps in the architecture capability.
• Part of the Architecture Capability Framework; often run periodically by the ARB.