# TOGAF Executive Overview

## The short definition

TOGAF is a configurable framework for Enterprise Architecture. It supplies:

- a repeatable method for architecture work;
- common concepts and vocabulary;
- ways to describe architecture content;
- techniques for analyzing change;
- guidance for establishing an architecture capability; and
- governance practices that connect architecture decisions to implementation.

Its centerpiece is the **Architecture Development Method (ADM)**, an iterative
cycle that moves from motivation and scope through baseline and target
architectures, roadmap planning, implementation governance, and change
management.

## Why Enterprise Architecture exists

Organizations rarely suffer from a shortage of projects. They suffer from
projects pulling in different directions:

- strategy is unclear or changes faster than delivery;
- teams optimize local systems but damage end-to-end value streams;
- the same capability is built more than once;
- data has conflicting definitions and ownership;
- technology becomes expensive, fragile, or obsolete;
- major dependencies are found late; and
- investment decisions are made without a coherent view of the enterprise.

Enterprise Architecture addresses these problems by making important
relationships and choices explicit. It connects strategic intent to coordinated
change.

## The basic TOGAF journey

```mermaid
flowchart LR
    Drivers[Drivers and goals] --> Baseline[Where are we now?]
    Baseline --> Target[Where do we want to be?]
    Target --> Gaps[What must change?]
    Gaps --> Roadmap[In what sequence?]
    Roadmap --> Delivery[Implement and govern]
    Delivery --> Outcomes[Measure outcomes]
    Outcomes --> Change[Respond to change]
    Change --> Drivers
```

Every serious architecture engagement should answer:

1. **Why are we changing?**
2. **Who has concerns, influence, and decision rights?**
3. **What is in and out of scope?**
4. **What is the baseline state?**
5. **What target state will satisfy the goals and requirements?**
6. **What gaps separate baseline and target?**
7. **What work packages and transition states will close those gaps?**
8. **How will implementation remain conformant while allowing justified change?**
9. **How will value, risk, and architecture health be measured?**

## The ADM at a glance

| Phase | Main question | Typical outcome |
|---|---|---|
| Preliminary | How will we practice architecture? | Tailored method, principles, governance, repository |
| A: Architecture Vision | What outcome and scope are we agreeing to? | Vision, scope, stakeholders, approval to proceed |
| B: Business Architecture | How should the enterprise operate? | Business baseline, target, and gaps |
| C: Information Systems Architectures | What data and applications are needed? | Data and application baselines, targets, and gaps |
| D: Technology Architecture | What technology environment enables them? | Technology baseline, target, and gaps |
| E: Opportunities & Solutions | How can changes be packaged? | Work packages and candidate transition architectures |
| F: Migration Planning | What is the prioritized, viable roadmap? | Implementation and Migration Plan |
| G: Implementation Governance | Is delivery realizing the architecture? | Contracts, compliance reviews, managed deviations |
| H: Architecture Change Management | When must the architecture evolve? | Change decisions and new ADM cycles |
| Requirements Management | Are requirements traced and controlled? | Requirements repository and impact feedback |

The ADM graphic is often drawn as a circle, but it is not a rigid waterfall.
Work may iterate within a phase, revisit earlier phases, run at multiple levels,
or operate in parallel for different scopes.

## The four commonly used architecture domains

| Domain | Focus |
|---|---|
| Business | Strategy, capabilities, value streams, organization, services, processes |
| Data | Data concepts, structure, ownership, lifecycle, movement, and governance |
| Application | Application services, responsibilities, interactions, and portfolio |
| Technology | Platforms, infrastructure, networks, runtime, standards, and operations |

Security, risk, privacy, integration, experience, and sustainability are
cross-cutting concerns. Treating them as late add-ons is a common failure mode.

## What TOGAF gives you—and what it does not

TOGAF gives you a **method and a toolbox**. It does not prescribe:

- one organization structure;
- one modeling language;
- one repository product;
- a mandatory set of diagrams;
- a fixed delivery lifecycle;
- a specific cloud, vendor, or technology stack; or
- a guarantee that governance will work.

An organization must configure TOGAF to its size, culture, risk, decision speed,
and delivery model.

## When TOGAF is useful

TOGAF is especially useful when change:

- crosses business units, products, data domains, or platforms;
- requires a multi-year or multi-release roadmap;
- involves major modernization, merger, regulatory, or operating-model change;
- has many stakeholders with competing concerns;
- needs explicit standards and decision rights; or
- would benefit from reusable architecture knowledge.

For a small, isolated, reversible technical change, a lightweight architecture
decision record may be enough. Proportionality is part of good architecture.

## What success looks like

A successful TOGAF practice is not measured by the number of diagrams. It is
measured by outcomes such as:

- decisions made earlier and with better evidence;
- less duplication and avoidable complexity;
- clearer ownership and traceability;
- faster, safer delivery;
- reduced risk and technical debt;
- higher reuse of capabilities, data, services, and platforms; and
- investments that demonstrably support strategy.

[Next: Core concepts](01-core-concepts.html)