# TOGAF Fast-Learning Mind Map

Use this document to build a mental model before memorizing details. Read the
map once, redraw it from memory, then use the linked handbook sections only
where your recall is weak.

For an editable visual workbook, open the
[three-page draw.io mind map](15-togaf-fast-learning-mindmap.drawio). A
[printable PDF version](15-togaf-fast-learning-mindmap.pdf) is also available.

## The whole framework on one map

```mermaid
mindmap
  root((TOGAF))
    Purpose
      Connect strategy to coordinated change
      Describe baseline and target
      Find gaps and sequence change
      Govern delivery and respond to change
    ADM
      Preliminary
        Establish the architecture capability
      A Architecture Vision
        Agree why scope value and authority
      B Business
        Capabilities value streams organization
      C Information Systems
        Data
        Applications
      D Technology
        Platforms infrastructure standards
      E Opportunities and Solutions
        Group gaps into work packages
        Define transition architectures
      F Migration Planning
        Prioritize and create the executable plan
      G Implementation Governance
        Govern conformance and exceptions
      H Change Management
        Monitor change and start new cycles
      Requirements Management
        Central and continuous
    Architecture Domains
      Business
      Data
      Application
      Technology
      Cross-cutting
        Security risk privacy integration
    Core Reasoning
      Drivers and goals
      Stakeholders and concerns
      Baseline
      Target
      Gaps
      Roadmap
      Delivery
      Outcomes and feedback
    Content
      Deliverables
        Formally reviewed work products
      Artifacts
        Catalogs
        Matrices
        Diagrams
      Building Blocks
        ABB required capability
        SBB implementation
    Reuse and Knowledge
      Enterprise Continuum
        Classifies generic to specific
      Architecture Repository
        Stores and governs assets
    Governance
      Principles and standards
      Decision rights
      Architecture Board
      Architecture Contract
      Compliance reviews
      Exceptions and feedback
    Ways of Working
      Tailor to context and risk
      Iterate instead of treating ADM as waterfall
      Integrate with product Agile DevOps and portfolio
      Produce only decision-useful content
```

## The one-sentence mental model

> TOGAF uses a tailored, iterative method to move from **why**, through
> **what**, to **how and when**, while requirements, stakeholders, governance,
> and learning keep the change coherent.

If you remember only one flow, remember this:

```mermaid
flowchart LR
    Why[Why change?] --> Who[Who cares and why?]
    Who --> Now[Baseline: where are we?]
    Now --> Future[Target: where are we going?]
    Future --> Gap[Gaps: what must change?]
    Gap --> Sequence[Roadmap: in what order?]
    Sequence --> Govern[Deliver and govern]
    Govern --> Learn[Measure and adapt]
    Learn --> Why
```

## ADM: remember the questions, not just the letters

Mnemonic for the phase sequence:

> **Prepare A Business; Connect Digital Execution For Governed Horizons.**

| Phase | Memory word | Question you must answer | Main result |
|---|---|---|---|
| Preliminary | Prepare | How will architecture be practiced? | Tailored method, roles, principles, governance, repository |
| A: Architecture Vision | Agree | Why are we changing, for whom, and within what scope? | Vision and authorized Statement of Architecture Work |
| B: Business Architecture | Business | How should the enterprise operate? | Business baseline, target, and gaps |
| C: Information Systems | Connect | What data and applications are needed? | Data and application baseline, target, and gaps |
| D: Technology Architecture | Digital | What technology enables the target? | Technology baseline, target, and gaps |
| E: Opportunities & Solutions | Execute | How should the gaps become coherent work packages? | Work packages and transition architectures |
| F: Migration Planning | Future plan | What sequence is valuable, feasible, and affordable? | Prioritized Implementation and Migration Plan |
| G: Implementation Governance | Govern | Is delivery realizing the agreed architecture? | Compliance evidence, managed deviations, and contracts |
| H: Architecture Change Management | Horizons | Has enough changed to evolve the architecture? | Change decisions and possible new ADM cycle |
| Requirements Management | Hub | What must be true, and what has changed? | Traced requirements and impact feedback across every phase |

The ADM is a thinking cycle, not a fixed waterfall. Phases may iterate, overlap,
or run at different enterprise, portfolio, product, and solution levels.

## The four domains: BDAT

Use **BDAT** to remember the domains and their dependency:

```mermaid
flowchart LR
    B[Business<br/>value capabilities and operating model]
    D[Data<br/>meaning ownership flow and lifecycle]
    A[Application<br/>services responsibilities and interactions]
    T[Technology<br/>platforms infrastructure and standards]

    B --> D
    B --> A
    D <--> A
    A --> T
    D --> T
```

| Domain | Fast diagnostic question |
|---|---|
| Business | What value, capability, people, process, and accountability must change? |
| Data | What information is needed, who owns it, and how is it governed? |
| Application | What application services provide the required behavior and interaction? |
| Technology | What platforms and infrastructure enable those services safely? |

Security, risk, privacy, integration, experience, and sustainability cut across
all four domains; they are not late additions.

## Content: do not confuse these three

```mermaid
flowchart TD
    D[Deliverable<br/>formally reviewed work product]
    A[Artifact<br/>representation of architecture information]
    C[Catalog<br/>lists]
    M[Matrix<br/>relationships]
    G[Diagram<br/>structure or behavior]
    BB[Building Block<br/>reusable capability or component]
    ABB[ABB<br/>required capability]
    SBB[SBB<br/>implementation realization]

    D -->|contains| A
    A --> C
    A --> M
    A --> G
    A -->|describes| BB
    BB --> ABB
    BB --> SBB
```

- A **deliverable** is the reviewed package.
- An **artifact** communicates architecture information.
- A **building block** is a potentially reusable unit of capability.
- An **ABB** says what capability is required; an **SBB** says how it is
  implemented.

## Reuse: continuum versus repository

| Concept | Think of it as | Fast distinction |
|---|---|---|
| Enterprise Continuum | A classification lens | Places architecture and solution assets from generic to organization-specific |
| Architecture Repository | A managed knowledge store | Holds landscapes, standards, reference assets, governance records, capability information, and metamodels |

Memory hook: **the Continuum classifies; the Repository contains and controls**.

## Governance: the decision loop

```mermaid
flowchart LR
    P[Principles and standards] --> DR[Decision rights]
    DR --> D[Decision]
    D --> C[Architecture Contract or agreement]
    C --> I[Implementation]
    I --> R[Compliance review]
    R -->|conformant| O[Outcome evidence]
    R -->|justified deviation| E[Exception with owner and expiry]
    E --> I
    O --> F[Feedback and learning]
    F --> P
```

Governance is not central approval of every design. Effective governance makes
decision authority, evidence, conformance, exceptions, and feedback explicit
and proportional to risk.

## The eight distinctions worth memorizing

| Often confused | Correct distinction |
|---|---|
| View / viewpoint | A **view** is the representation; a **viewpoint** defines how to construct and use it |
| Stakeholder / concern | A **stakeholder** has an interest; a **concern** is what matters to that stakeholder |
| Baseline / target | Relevant current state / intended future state |
| Gap / requirement | Difference between baseline and target / condition the architecture must satisfy |
| Transition architecture / roadmap | Coherent intermediate state / sequence of work and transitions |
| Deliverable / artifact | Reviewed package / representation within architecture work |
| ABB / SBB | Required capability / implementation realization |
| Continuum / repository | Classification mechanism / managed storage mechanism |

## How to reason through a TOGAF scenario

When a question or real situation feels complicated, use **SCOPE**:

1. **S — Stakeholders:** Who has concerns, influence, and decision rights?
2. **C — Context:** What phase, scope, constraints, and evidence are present?
3. **O — Outcome:** What business result or decision must the work enable?
4. **P — Proportion:** What is the smallest sufficient technique, artifact, or
   governance response?
5. **E — Evidence:** Which option preserves traceability, resolves trade-offs,
   and creates feedback?

Prefer answers that clarify outcomes and authority, address stakeholder
concerns, tailor the method, maintain traceability, and enable governed
delivery. Be suspicious of answers that create every artifact, skip directly
to technology, centralize every decision, or treat the ADM as a rigid
waterfall.

## Ninety-minute fast-learning route

| Time | Action | Proof that you learned it |
|---:|---|---|
| 0–10 min | Read the whole-framework map and one-sentence model | Explain TOGAF without looking |
| 10–30 min | Learn the ADM questions and mnemonic | Draw Preliminary through H with Requirements at the center |
| 30–40 min | Learn BDAT | Give one concern and target outcome for each domain |
| 40–55 min | Learn content, reuse, and governance | Explain all eight confused pairs aloud |
| 55–70 min | Apply SCOPE to the [worked example](10-worked-example.html) | Identify the phase and best next action at each step |
| 70–90 min | Complete practice questions in the [exam simulator](../exam/index.html) | Review every wrong answer by concept |

## Seven-day retention loop

Do not reread passively. Retrieve the model from memory:

- **Day 1:** redraw the main map and ADM without looking;
- **Day 2:** explain BDAT, content, governance, continuum, and repository aloud;
- **Day 3:** answer Foundation questions and record weak topics;
- **Day 5:** work Practitioner scenarios using SCOPE;
- **Day 7:** take a timed mock exam and redraw only what you missed.

For each mistake, write one flashcard with a question on the front and a
one-sentence distinction or phase purpose on the back.

## Self-test: close the document first

1. What problem does TOGAF solve?
2. What question does each ADM phase answer?
3. Why is Requirements Management central?
4. How do the four BDAT domains depend on one another?
5. What is the difference between an artifact and a deliverable?
6. What is the difference between an ABB and an SBB?
7. How does the Enterprise Continuum differ from the Architecture Repository?
8. Why is governance more than Architecture Board approval?
9. Why are transition architectures useful?
10. What makes tailoring responsible rather than incomplete?

If you can answer all ten clearly and apply SCOPE to a scenario, you have the
core TOGAF mental model. Continue with the
[ADM deep dive](02-adm.html), [quick reference](12-glossary-and-quick-reference.html),
and [mock exam](../exam/index.html).