What is inside

1. How to use the Feynman Technique
2. What TOGAF is—and is not
3. The whole architecture journey
4. Every ADM phase in simple words
5. The four BDAT domains
6. Core terms and architecture content
7. Reuse, repositories, and governance
8. Practical techniques and modern delivery
9. A complete Sunny Toys example
10. Exam thinking and the SCOPE method
11. A one-page memory sheet and tiny glossary
12. Fifteen questions that prove understanding

How to use this book

Richard Feynman was famous for explaining hard ideas in simple words. His learning method is easy:

1. Learn one small idea.
2. Close the page.
3. Explain it as if you are teaching a child.
4. Notice where your explanation becomes fuzzy.
5. Study that small gap, then explain it again.

This book follows that pattern. Each section has:

• a plain explanation;
• one example;
• a memory hook; and
• a say it back challenge.

Do not try to memorize every sentence. Build the picture in your head.

Our one example: Sunny Toys

Sunny Toys has ten shops. It wants customers to:

• see which toys are available;
• buy online;
• collect from any shop; and
• receive the same good service everywhere.

Today, every shop works differently. Stock numbers are often wrong. There are three customer lists and five old applications. Sunny Toys needs coordinated change—not just a new website.

We will use Sunny Toys for the whole book.

1. What TOGAF is

Imagine a town wants to build homes, roads, schools, pipes, and parks.

If every builder works alone:

• one road may end at a wall;
• pipes may not reach the homes;
• two schools may be built where only one is needed; and
• the town may spend money without becoming a better place to live.

The town needs a shared plan. It also needs a way to create, check, and update that plan.

An enterprise has the same problem. Its “roads and buildings” are:

• people and teams;
• business capabilities and processes;
• information;
• applications;
• technology; and
• projects and products changing all of them.

Enterprise Architecture is the shared picture and decision discipline that keeps those parts moving toward the same outcomes.

TOGAF is a framework for doing Enterprise Architecture. It gives you:

• a repeatable method;
• a shared vocabulary;
• ways to describe architecture;
• analysis techniques;
• governance practices; and
• advice for building an architecture capability.

What TOGAF is not

TOGAF is not:

• a finished architecture you can copy;
• a software product;
• a diagramming language;
• a project management method;
• a command to create every possible document; or
• a rigid waterfall.

It is a method and toolbox. You choose the parts that help with the real decision.

Three words that sound bigger than they are

2. The whole TOGAF story

Every useful architecture journey answers the same questions:

For Sunny Toys:

1. Why? Customers leave because stock information is wrong.
2. Who? Customers, shop staff, managers, finance, security, and delivery teams all care about different things.
3. Now? Each shop has separate processes, data, and applications.
4. Future? One joined-up buying and collection experience.
5. Gap? Shared stock data, clearer ownership, connected applications, staff training, and reliable technology are missing.
6. Order? Clean stock data before promising real-time availability.
7. Build? Check each release against the agreed requirements.
8. Learn? Measure collection success, stock accuracy, customer happiness, cost, and new risks.

3. The ADM: TOGAF's main method

The Architecture Development Method, or ADM, is the heart of TOGAF.

It organizes architecture work into:

• a setup phase;
• eight lettered phases, A through H; and
• Requirements Management in the middle.

Use this mnemonic:

That gives you P-A-B-C-D-E-F-G-H.

Preliminary Phase — Prepare

Simple question: How will we do architecture here?

Before planning Sunny Toys, the organization agrees:

• who makes which decisions;
• which method and documents are useful;
• which principles guide choices;
• where architecture knowledge is stored; and
• how architects work with leaders and delivery teams.

Main result: a working architecture capability—not merely an architecture team.

Phase A — Agree the Architecture Vision

Simple question: Why are we doing this, for whom, and how big is the work?

Sunny Toys agrees:

• the desired customer outcome;
• the sponsor;
• stakeholders and concerns;
• what is inside and outside scope;
• high-level baseline and target;
• success measures and risks; and
• permission to continue.

Main results: the Architecture Vision and Statement of Architecture Work.

Phase B — Business Architecture

Simple question: How should the business work?

Sunny Toys designs:

• the buy-and-collect value stream;
• shop and online capabilities;
• staff responsibilities;
• customer service;
• business rules; and
• ownership of stock accuracy.

Main result: business baseline, target, and gaps.

Phase C — Information Systems Architectures

Phase C contains two domains.

Data Architecture

Simple question: What information do we need, and who looks after it?

Sunny Toys defines:

• one meaning for Product, Shop, Stock, Customer, Order, and Collection;
• an owner for each important kind of data;
• where trusted data comes from;
• how it moves; and
• privacy, quality, retention, and access rules.

Application Architecture

Simple question: What applications and services use that information?

Sunny Toys decides how the website, stock service, payment service, shop application, notification service, and reporting tools work together.

Main result: data and application baselines, targets, and gaps.

Phase D — Technology Architecture

Simple question: What technology lets the target work safely and reliably?

Sunny Toys chooses the needed:

• platforms and hosting;
• networks and shop connectivity;
• identity and access services;
• monitoring and backup;
• integration technology; and
• technology standards and lifecycle rules.

Main result: technology baseline, target, and gaps.

Phase E — Opportunities & Solutions

Simple question: How do we turn all the gaps into sensible pieces of work?

Sunny Toys groups changes into work packages:

1. create trusted stock data;
2. connect shop systems;
3. launch online ordering;
4. add collection notifications; and
5. improve reporting and operations.

It may define Transition Architectures—safe intermediate states on the way to the target.

Main result: work packages and candidate transition architectures.

Phase F — Migration Planning

Simple question: What should happen first, and can we really do it?

Sunny Toys compares:

• value;
• cost;
• risk;
• dependencies;
• people and skills;
• readiness; and
• time.

Main results: a prioritized Architecture Roadmap and an executable Implementation and Migration Plan.

Phase G — Implementation Governance

Simple question: Is delivery building what was agreed?

Sunny Toys:

• agrees responsibilities and review points;
• checks important requirements;
• reviews evidence;
• handles justified exceptions; and
• avoids turning governance into a slow approval queue.

Main results: Architecture Contracts or equivalent agreements, compliance evidence, decisions, and managed deviations.

Phase H — Architecture Change Management

Simple question: Has the world changed enough to update the architecture?

Sunny Toys watches:

• business outcomes;
• customer behavior;
• operating problems;
• new laws and risks;
• technology changes; and
• architecture debt.

A small change may update one decision. A big change may start a new ADM cycle.

Main result: a living architecture instead of an old document.

Requirements Management — the center

A requirement says what must be true.

Example: “A customer must only see stock that can be reserved.”

Requirements Management stays in the center because every phase:

• discovers requirements;
• uses requirements;
• tests requirements;
• changes requirements; or
• is changed by requirements.

4. The four architecture domains: BDAT

Use BDAT:

The domains are different, but they must fit together.

If the business promises one-hour collection, then:

• Data must show trustworthy stock.
• Applications must reserve the toy.
• Technology must keep the service available.
• People and processes must prepare the collection.

Security, risk, privacy, integration, customer experience, and sustainability cross all four domains. They are not decorations added at the end.

5. The core language

Stakeholder, concern, view, viewpoint

These four words form one chain:

1. A stakeholder is a person or group that cares.
2. A concern is what they care about.
3. A viewpoint is the rule for creating a useful picture.
4. A view is the actual picture made for this architecture.

Example:

• Stakeholder: shop manager
• Concern: “Will collection create long queues?”
• Viewpoint: show the customer and staff journey with timings
• View: Sunny Toys' actual collection journey diagram

Baseline, target, gap, transition, roadmap

Driver, goal, outcome, requirement, measure

Principle, constraint, assumption, risk

Example principle: Stock has one trusted owner.

Example constraint: The first release must use existing shop scanners.

Example assumption: Every shop has stable internet access.

Example risk: Old stock records may be too inaccurate for online promises.

6. What architects produce

TOGAF distinguishes three things.

Deliverable

A deliverable is a formally reviewed package of work.

Think: a school project handed to the teacher.

Examples:

• Architecture Vision;
• Architecture Definition Document;
• Architecture Requirements Specification;
• Architecture Roadmap; and
• Implementation and Migration Plan.

Artifact

An artifact is a representation of architecture information inside or alongside the work.

There are three simple forms:

Building block

A building block is a reusable unit of capability or solution.

• An Architecture Building Block (ABB) says what capability is needed.
• A Solution Building Block (SBB) says how it will be implemented.

Sunny Toys example:

• ABB: “Secure customer identity capability”
• SBB: “The selected identity platform and its configured services”

The minimum useful architecture pack

Do not create documents because a framework has a template. For many engagements, a small useful pack is:

1. outcome, scope, sponsor, and stakeholders;
2. principles, assumptions, constraints, and risks;
3. relevant baseline;
4. target choices across the necessary domains;
5. traceable requirements and decisions;
6. gaps, work packages, and roadmap;
7. governance and exception approach; and
8. measures of success.

7. Reuse and the Architecture Repository

Imagine a kitchen.

The Enterprise Continuum is the labeling idea that sorts recipes and ingredients from very general to very specific.

The Architecture Repository is the actual pantry, cookbook shelf, fridge, and list that store and control them.

The Continuum has two related sides:

• Architecture Continuum: reusable architecture ideas and descriptions.
• Solutions Continuum: products, services, and implemented solutions.

Common Repository areas are:

Good repository content has an owner, status, version, and review date.

8. Governance without becoming the architecture police

Governance means important decisions are:

• made by the right people;
• based on visible criteria and evidence;
• recorded;
• followed during delivery;
• allowed a controlled exception when justified; and
• improved using feedback.

It does not mean one central committee designs everything.

Think of road rules:

• rules make movement safer;
• signs make expectations visible;
• drivers still choose their route;
• unusual situations have an exception process; and
• accident evidence helps improve the rules.

The governance loop

1. Agree principles and standards.
2. Define decision rights.
3. Make and record decisions.
4. Agree implementation responsibilities.
5. Review evidence of conformance.
6. Approve, correct, or manage an exception.
7. Measure the outcome.
8. Improve the architecture and rules.

An Architecture Board is one governance body. It needs a clear mandate, authority, decision criteria, membership, and escalation rules. Low-risk decisions should stay close to delivery.

An Architecture Contract is an agreement about responsibilities, requirements, evidence, reviews, and exceptions. It does not have to be a giant legal document.

9. The small toolbox of techniques

Use a technique only when it helps answer a question.

A simple trade-off method

When Sunny Toys must choose a solution:

1. State the decision.
2. Name the stakeholders and concerns.
3. Define criteria and constraints.
4. Create more than one credible option, including “do nothing” where useful.
5. Gather enough evidence—not endless evidence.
6. Compare value, cost, risk, uncertainty, and reversibility.
7. Let the person with the decision right decide.
8. Record the choice, consequences, and revisit trigger.

10. TOGAF with Agile, products, DevOps, cloud, and security

TOGAF and modern delivery solve different parts of the problem.

• TOGAF helps decide the important direction and coordinate change.
• Product management keeps attention on persistent customer value.
• Agile creates short learning loops.
• DevOps makes delivery and operations fast and repeatable.
• Cloud provides on-demand technology services.
• Security and risk protect outcomes across every domain and phase.

They can work together.

Good modern architecture:

• works in small increments;
• gives teams clear guardrails and decision rights;
• records important decisions briefly;
• automates standards and evidence where possible;
• keeps architects close to products and delivery;
• uses operational data to update architecture; and
• escalates only choices with material risk or cross-enterprise impact.

Bad architecture creates a document mountain and arrives after all decisions have already been made.

11. How to start TOGAF in a real organization

Do not announce, “We will implement the whole framework.”

Start with a real business problem.

Days 1–30: establish the minimum

• Confirm the sponsor and outcome.
• Identify stakeholders and decision rights.
• Agree a small set of principles.
• Tailor the ADM and minimum content.
• Create a simple repository structure.
• Choose one valuable pilot.

Days 31–60: run the pilot

• Agree the vision and scope.
• Develop only the useful baseline and target.
• Trace requirements and decisions.
• Identify gaps and work packages.
• Build a practical roadmap.
• Work beside delivery teams.

Days 61–90: connect and improve

• Run proportionate governance and exception handling.
• Measure value, speed, risk, and conformance.
• Reuse patterns and lessons.
• Fix unclear decision rights.
• Expand only what has proved useful.

Common failure patterns

12. One full Sunny Toys walkthrough

Here is the entire method in one short story.

Prepare

Sunny Toys gives the transformation sponsor authority. A small Architecture Board handles only cross-shop decisions. Product teams keep local delivery choices within shared guardrails.

Agree

The vision is: “Customers can confidently buy online and collect from any shop within two hours.” Scope includes stock, ordering, payment, collection, staff workflow, and enabling technology. It excludes home delivery for now.

Understand the business

The target value stream is:

Find toy → reserve → pay → prepare → notify → collect → support

Shop staff own physical stock accuracy. Customer service owns collection support. Product leaders own the end-to-end outcome.

Design information and applications

Product, Shop, Stock, Customer, Order, Payment, and Collection get clear definitions and owners. A stock service becomes the trusted source. The website and shop application use the same order and stock services.

Design technology

The target uses secure identity, managed hosting, reliable shop connectivity, monitoring, backup, and standard integration. Privacy and security requirements apply throughout.

Package and plan

Sunny Toys creates three transition states:

1. accurate shared stock;
2. online reservation with payment at collection; and
3. full online payment and two-hour collection.

The roadmap follows data dependency and business readiness, not excitement about the website.

Govern and learn

Each release supplies automated test, security, reliability, and stock-accuracy evidence. Exceptions have an owner and expiry. Sunny Toys measures customer completion, stock accuracy, collection time, support calls, cost, and incidents.

Those results update the architecture.

13. The exam idea, simply

The current Enterprise Architecture learning path has two main levels:

Foundation

Foundation checks whether you understand:

• core concepts and vocabulary;
• the ADM structure and purpose of each phase;
• foundational techniques;
• applying the ADM;
• governance; and
• architecture content.

The Part 1 examination uses 40 multiple-choice questions in 60 minutes, with a 60% passing score.

Practitioner

Practitioner checks whether you can apply the framework to a situation.

The Part 2 examination uses eight scenario-based questions in 90 minutes. Each question has four choices scored 5, 3, 1, or 0. It is open book using the provided reference material.

Use SCOPE for scenarios

1. S — Stakeholders: Who cares and who decides?
2. C — Context: What phase, scope, evidence, and constraints exist?
3. O — Outcome: What result or decision is needed?
4. P — Proportion: What is the smallest sufficient response?
5. E — Evidence: Which choice preserves traceability, trade-offs, and feedback?

Prefer answers that clarify outcomes and authority, address concerns, tailor the work, maintain traceability, and enable governed delivery.

Be suspicious of answers that:

• create every artifact;
• skip straight to technology;
• centralize every choice;
• ignore stakeholder concerns; or
• treat the ADM as a fixed waterfall.

14. One-page memory sheet

TOGAF in one sentence

TOGAF helps an organization understand where it is, agree where it wants to go, plan the changes, govern delivery, and keep learning.

The journey

Why → Who → Now → Future → Gap → Order → Build → Learn

The ADM

The domains

BDAT = Business, Data, Application, Technology

The content

• Deliverable = reviewed package
• Artifact = catalog, matrix, or diagram
• ABB = required capability
• SBB = implementation

Reuse

• Continuum = classifies
• Repository = stores and controls

Governance

Decision rights → decision → agreement → evidence → compliance or exception → outcome → feedback

Scenario thinking

SCOPE = Stakeholders, Context, Outcome, Proportion, Evidence

15. Tiny glossary

16. Prove that you understand

Answer these aloud in simple words:

1. What problem does Enterprise Architecture solve?
2. What does TOGAF give you?
3. Why is the ADM not a waterfall?
4. What question does each ADM phase answer?
5. Why is Requirements Management in the center?
6. How do Business, Data, Application, and Technology fit together?
7. What is the difference between a view and a viewpoint?
8. What is the difference between baseline, target, gap, transition, and roadmap?
9. What is the difference between a deliverable, artifact, ABB, and SBB?
10. Why is the Enterprise Continuum not the Architecture Repository?
11. What makes governance useful instead of slow?
12. How can TOGAF work with Agile and DevOps?
13. How would you start TOGAF in an organization?
14. How does SCOPE help with a scenario?
15. Can you retell the Sunny Toys story from problem to learning?

If an answer needs lots of jargon, simplify it. If you cannot simplify it, find the small gap and study it again. That is the Feynman Technique.

Continue learning

• Read the full TOGAF Handbook for detail.
• Use the fast-learning mind map for recall.
• Open the editable draw.io workbook to redraw the relationships.
• Take the timed mock exam and review mistakes by concept.
• Use the comprehensive glossary whenever a word becomes fuzzy.

Official sources

This is an independent educational summary. It does not reproduce or replace the official standard.

• TOGAF overview
• TOGAF Standard publications catalog
• TOGAF Library
• TOGAF certification portfolio