Overview
Supporting the ADM Work is the largest syllabus area, with 19 learning outcomes, almost all at the Understanding level. It collects the techniques, content structures and reference material that architects use inside the ADM phases.
The outcomes fall into four groups. Reference and techniques: The Open Group TOGAF Library, business scenarios, compliance assessments, migration planning techniques for gap analysis results, Business Architecture techniques, gap analysis itself, the Implementation Factor Catalog and risk assessment. Repository and landscape: how to structure the repository, what a well-run Architecture Repository looks like, and how Architecture Levels organize the Architecture Landscape. Scope and detail: the levels of architecture in an organization and how to judge the right level of detail for an architecture. Content: Architecture Building Blocks, iteration, the need for an enterprise metamodel and its link to the Architecture Content Framework, how the content framework is populated across ADM cycles, the TOGAF Enterprise Metamodel and the use of a taxonomy.
How it's tested
Techniques appear as tools within options. The question is usually whether an option uses the appropriate technique for the problem and phase. Best answers apply business scenarios for unclear requirements, gap analysis for baseline and target comparisons, risk assessment for uncertainty, and repository and metamodel structure for consistency problems.
-
Right tool for the problem
Options propose different techniques. The best one matches the problem: business scenarios for vague needs, gap analysis for change scope, Business Value Assessment for priorities.
-
Right level of detail
The organization produces either too much detail or too little. Strong answers use architecture levels and partitioning to set breadth, depth and time horizon.
-
Consistency through structure
Teams produce incompatible models. Higher-scoring options introduce a shared metamodel, taxonomy and repository structure rather than more documents.
A government agency's teams each describe applications differently, and nobody can trace services to capabilities. Commissioning another inventory repeats the problem. The best option adopts the TOGAF Enterprise Metamodel, tailored to the agency, with a shared taxonomy and repository structure, then migrates existing descriptions into it so relationships can be traced across ADM cycles.
Learning outcomes 19
Official learning outcomes from the The Open Group outline, in outline order.
8.1 Understand how to use The Open Group TOGAF LibraryBloom level 2. Finding reference material beyond the Fundamental Content.
- What it means
- The TOGAF Library is The Open Group's collection of reference material that supports the TOGAF Standard, including Series Guides, white papers, reference models, case studies and templates. It is organized so architects can find guidance relevant to their situation.
- What to understand
- The Fundamental Content is stable and universal; the Library and Series Guides provide situation-specific guidance that can change more often. Practitioners use the Library to adapt the method, for example for Agile delivery, security or digital transformation, rather than inventing guidance from scratch.
- How it shows up
- Options that draw on relevant Series Guides or Library material to tailor the approach can outscore options that invent bespoke methods.
- Common confusion
- Treating Library guidance as mandatory parts of the TOGAF Standard.
8.2 Understand the business scenario techniqueBloom level 2. Discovering and documenting business requirements.
- What it means
- A business scenario describes a business problem, the environment, the objectives, the human and computer actors, their roles and responsibilities, and the desired outcome. It helps discover requirements and link them to business value, and is often used in Phase A and Phase B.
- What to understand
- The technique is iterative: identify, document and refine the scenario with stakeholders. Objectives should be SMART. A good business scenario is owned by the business, not invented by architects, and becomes a reference for later validation.
- How it shows up
- When requirements are vague or disputed, an option using a business scenario with stakeholders is often best.
- Common confusion
- Writing business scenarios as technical use cases without business objectives.
8.3 Understand the purpose of compliance assessmentsBloom level 2. Why reviews are carried out.
- What it means
- Compliance assessments check whether projects and solutions conform to the architecture. They catch errors early, take advantage of reuse, identify where the architecture itself needs updating and give the Architecture Board evidence for decisions.
- What to understand
- Reviews also help spread architectural knowledge to project teams and confirm that business objectives are being met. They are planned at points in the project lifecycle and use checklists tailored to the domain. Results may lead to dispensations or architecture change.
- How it shows up
- Options that use compliance assessments as a learning and improvement tool, not just a gate, tend to score higher.
- Common confusion
- Seeing compliance assessments purely as policing.
8.4 Understand migration planning techniques for gap analysis resultsBloom level 2. Turning gaps into a migration plan.
- What it means
- Migration planning techniques include the Implementation Factor Catalog, the Consolidated Gaps, Solutions and Dependencies Matrix, the Architecture Definition Increments Table, the Transition Architecture State Evolution Table and the Business Value Assessment technique.
- What to understand
- These techniques take gaps found in Phases B to D and help decide how to group, sequence and value them. They are used mainly in Phases E and F. Together they connect architecture gaps to a realistic, value-based migration path.
- How it shows up
- A scenario may ask which technique helps with a specific planning question; match the technique to its purpose.
- Common confusion
- Mixing up which technique handles dependencies and which handles value.
8.5 Describe how to structure a repositoryBloom level 1. The classes of information in an Architecture Repository.
- What it means
- The Architecture Repository holds the Architecture Metamodel, the Architecture Capability, the Architecture Landscape, the Standards Library, the Reference Library, the Governance Log, the Architecture Requirements Repository and the Solutions Landscape.
- What to understand
- Each area has a purpose: the landscape holds architectures by level and state, the reference library holds reusable models and patterns, the standards area holds standards to comply with, and the governance log records decisions. A clear structure lets content be found, reused and governed.
- How it shows up
- Questions may ask where a type of content belongs; know each repository area's purpose.
- Common confusion
- Putting governance decisions in the reference library or standards in the landscape.
8.6 Understand what a well-run Architecture Repository looks likeBloom level 2. Repository practice, not just structure.
- What it means
- A well-run repository is current, trusted and used. Content has owners, is classified consistently, is linked through a metamodel, is version controlled and is governed so that approved, draft and retired content are clear.
- What to understand
- Repository management includes access, quality checks, lifecycle status and tooling. It supports reuse and impact analysis across projects. A repository full of outdated or unowned content undermines confidence and leads teams to bypass it.
- How it shows up
- Scenarios with ignored or stale repositories reward options that add ownership, governance and lifecycle management.
- Common confusion
- Assuming buying a tool creates a well-run repository.
8.7 Understand how Architecture Levels organize the Architecture LandscapeBloom level 2. Organizing architectures by breadth, depth and time.
- What it means
- The Architecture Landscape is organized into levels such as strategic, segment and capability architectures. Each level has a different scope, level of detail and planning horizon, and the levels are linked so that detailed architectures fit within broader ones.
- What to understand
- Organizing by level lets many architectures coexist and be governed consistently. Higher levels set direction and constraints; lower levels give detail for delivery. This helps manage multiple architecture states and coordinate parallel ADM cycles.
- How it shows up
- Options that place new work at the appropriate level and link it to existing levels tend to score best.
- Common confusion
- Treating levels as fixed organizational layers rather than architecture scope.
8.8 Understand the levels of architecture in an organizationBloom level 2. Strategic, segment and capability architecture.
- What it means
- Organizations typically need architecture at strategic level for long-term direction, segment level for portfolios or business areas, and capability level for specific change initiatives. Each serves different stakeholders and decisions.
- What to understand
- The level determines who the audience is and what level of approval applies. Strategic architectures support executives and planning; segment architectures support portfolio and programme managers; capability architectures support delivery teams and solution design.
- How it shows up
- When a scenario describes an audience or decision, choose the level that serves it.
- Common confusion
- Assuming capability architecture means business capability modelling.
8.9 Understand how to determine the level and detail of a given architectureBloom level 2. Setting breadth, depth and time period.
- What it means
- The right level of detail is set by the purpose of the architecture, its stakeholders and the decisions it must support. Scope dimensions include breadth, depth, time period and domains, and are agreed with the sponsor.
- What to understand
- Too little detail leaves delivery teams without guidance; too much wastes effort and goes stale. The decision is revisited through iterations. Agile delivery often needs high-level direction early and capability detail just before work starts.
- How it shows up
- Options that tie level of detail to purpose and stakeholders usually outrank those that default to maximum detail.
- Common confusion
- Equating more detail with better architecture.
8.10 Understand the role and use of Architecture Building BlocksBloom level 2. Reusable architecture components.
- What it means
- Architecture Building Blocks (ABBs) describe required capability and shape the specification of Solution Building Blocks (SBBs). ABBs capture requirements and constraints in a technology-aware but product-neutral way; SBBs are concrete components that implement them.
- What to understand
- Building blocks support reuse, interoperability and clear scope for procurement and design. ABBs are defined during Phases B to D; SBBs are identified mainly in Phase E and later. Good building blocks have defined boundaries and interfaces.
- How it shows up
- Questions may test that ABBs are product-neutral and guide SBB selection.
- Common confusion
- Swapping Architecture Building Blocks and Solution Building Blocks.
8.11 Understand the Business Architecture phase techniquesBloom level 2. Techniques used to develop the Business Architecture.
- What it means
- Business Architecture techniques include business capability mapping, value stream mapping, organization mapping, information mapping and business models, along with business scenarios and modelling of processes, functions and services.
- What to understand
- Capabilities describe what the business does, value streams how value is delivered, organization maps who does it and information maps what information is used. Combined, they let architects find gaps and plan change in business terms before turning to systems.
- How it shows up
- When a Phase B scenario lacks a clear view of what the business does, capability mapping is a strong option.
- Common confusion
- Treating capability maps and process models as interchangeable.
8.12 Understand the gap analysis technique and where to apply itBloom level 2. Comparing baseline and target.
- What it means
- Gap analysis compares baseline and target architectures, typically in a matrix with baseline elements on one axis and target elements on the other. It identifies elements to keep, elements to retire and new elements to add.
- What to understand
- Gaps can be intentional or accidental omissions, both of which must be resolved. It is applied in Phases B, C and D and its results are consolidated in Phase E. Gaps also cover people, skills, processes and data, not just systems.
- How it shows up
- Look for options that analyse gaps systematically and check for accidental omissions, not only planned changes.
- Common confusion
- Treating elements missing from the target as automatically intentional retirements.
8.13 Understand iteration in architecture practiceBloom level 2. How the ADM is cycled and repeated.
- What it means
- The ADM supports iteration within phases, between phases and across whole cycles. Iteration cycles include Architecture Context, Architecture Definition, Transition Planning and Architecture Governance.
- What to understand
- Iteration lets architects refine work as understanding improves, run several ADM cycles at different levels and adapt to change. Iteration has to be planned and governed so it improves results rather than producing endless rework.
- How it shows up
- Options that iterate back to an earlier phase for a real reason can outscore options that push forward on bad assumptions.
- Common confusion
- Thinking the ADM must be followed once, strictly in sequence.
8.14 Describe how to use the Implementation Factor CatalogBloom level 1. Recording factors that shape implementation.
- What it means
- The Implementation Factor Catalog lists factors affecting the implementation, such as risks, issues, assumptions, dependencies and actions, with a description of each and the deduction drawn from it.
- What to understand
- It is used in Phase E to inform the Implementation and Migration Strategy. Documenting factors and their deductions makes strategy decisions traceable and helps communicate why particular approaches were chosen.
- How it shows up
- A question may ask which artifact captures implementation factors and deductions.
- Common confusion
- Confusing it with the Consolidated Gaps, Solutions and Dependencies Matrix.
8.15 Understand the need for an enterprise metamodel and its link to the Architecture Content FrameworkBloom level 2. Why content needs a shared model.
- What it means
- An enterprise metamodel defines the types of architecture entities and the relationships between them. The Architecture Content Framework defines the deliverables, artifacts and building blocks produced by the ADM, and the metamodel underpins that content so it is consistent.
- What to understand
- Without a metamodel, teams describe things differently and content cannot be linked or analysed. With one, catalogs, matrices and diagrams become views of the same underlying data, enabling traceability from drivers to technology.
- How it shows up
- Consistency problems across teams are usually best addressed by a shared metamodel tied to the content framework.
- Common confusion
- Treating the metamodel as a diagram notation.
8.16 Understand how the Architecture Content Framework is populated across ADM cyclesBloom level 2. Content grows progressively.
- What it means
- Content is not created all at once. Each ADM phase adds or refines artifacts and deliverables, and repeated cycles at different levels enrich the repository over time.
- What to understand
- Early cycles may populate only strategic content; later cycles add segment and capability detail. Reusing content from earlier cycles saves effort. The organization tailors which artifacts it needs, so not every possible artifact is produced.
- How it shows up
- Options expecting a complete content set before any decisions tend to score lower.
- Common confusion
- Believing every TOGAF artifact must be produced in every cycle.
8.17 Describe how to use the TOGAF Enterprise MetamodelBloom level 1. The core entities and relationships.
- What it means
- The TOGAF Enterprise Metamodel defines core entities such as actor, role, organization unit, business capability, business service, process, data entity, application component and technology component, and the relationships between them.
- What to understand
- Organizations tailor it, adding or removing entities to fit their needs. It underpins catalogs, matrices and diagrams, so analysis such as impact of retiring an application component can follow relationships through the model.
- How it shows up
- Scenarios about traceability or tool configuration reward options that tailor and adopt the Enterprise Metamodel.
- Common confusion
- Using the metamodel unchanged when the organization has clear different needs.
8.18 Understand the use of a taxonomyBloom level 2. Consistent classification of architecture content.
- What it means
- A taxonomy is a classification scheme that gives architecture content consistent names and categories, so content can be organized, searched and related across teams and cycles.
- What to understand
- Taxonomies support the repository and metamodel by agreeing terms, for example for capabilities or application types. They reduce duplication and confusion and make reuse possible. They need governance so they stay consistent as the enterprise changes.
- How it shows up
- When teams use conflicting names for the same things, a shared governed taxonomy is a strong option.
- Common confusion
- Treating a taxonomy as the same thing as a metamodel.
8.19 Understand how risk assessment is usedBloom level 2. Identifying, classifying and mitigating risks.
- What it means
- Risk management in the ADM classifies risks, identifies them, assesses initial risk, applies mitigation, assesses residual risk and monitors it. Risks are rated by effect, such as catastrophic, critical, marginal or negligible, and frequency, from frequent to unlikely.
- What to understand
- Initial risk is assessed before mitigation; residual risk after it. Risk assessment is used in Phase A for transformation risks, in Phases E and F for migration risks, and in Phase G for monitoring. Residual risks must be accepted explicitly by the right authority.
- How it shows up
- Options that compare initial and residual risk and seek explicit acceptance are typically stronger.
- Common confusion
- Treating residual risk as zero once a mitigation is planned.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
TOGAF Library
The Open Group collection of Series Guides, white papers, reference models and templates.
- Remember
- Situation-specific guidance outside the Fundamental Content.
- Tested as
- Tailoring options.
- Trap
- Treating it as mandatory.
-
Business scenario
Problem, environment, objectives, actors, roles and outcome documented with the business.
- Remember
- Objectives should be SMART.
- Tested as
- Vague requirement scenarios.
- Trap
- Writing it as a system use case.
-
Gap analysis matrix
Baseline versus target elements to show kept, eliminated and new items.
- Remember
- Check for accidental omissions.
- Tested as
- Scoping change.
- Trap
- Assuming all missing items are intended.
-
Architecture Repository areas
Metamodel, Capability, Landscape, Standards Library, Reference Library, Governance Log, Requirements Repository, Solutions Landscape.
- Remember
- Each has a distinct purpose.
- Tested as
- Where content belongs.
- Trap
- Mixing governance records with reference models.
-
ABB vs. SBB
Architecture Building Blocks specify required capability; Solution Building Blocks implement it.
- Remember
- ABBs are product-neutral.
- Tested as
- Building block questions.
- Trap
- Naming products as ABBs.
-
Architecture levels
Strategic, segment and capability architectures organize the landscape.
- Remember
- Each serves different stakeholders and horizons.
- Tested as
- Right level of detail.
- Trap
- Detailing everything at once.
-
Iteration cycles
Architecture Context, Architecture Definition, Transition Planning, Architecture Governance.
- Remember
- Iteration is planned, not ad hoc.
- Tested as
- Iterate-back options.
- Trap
- Strict one-pass sequencing.
-
Enterprise metamodel
Defines entities and relationships underlying architecture content.
- Remember
- Links to the Architecture Content Framework.
- Tested as
- Consistency scenarios.
- Trap
- Confusing it with notation.
-
Taxonomy
Governed classification scheme for naming and categorizing content.
- Remember
- Complements the metamodel.
- Tested as
- Duplicate naming scenarios.
- Trap
- Treating it as optional decoration.
-
Initial vs. residual risk
Risk before mitigation versus risk remaining after it.
- Remember
- Residual risk needs explicit acceptance.
- Tested as
- Risk-based ranking.
- Trap
- Assuming mitigation removes risk.
-
Implementation Factor Catalog
Factors, descriptions and deductions affecting implementation.
- Remember
- Used in Phase E.
- Tested as
- Technique identification.
- Trap
- Using it to record gaps.
-
Business capability
A particular ability the business possesses to achieve an outcome.
- Remember
- Stable compared with processes and organization.
- Tested as
- Business Architecture technique choice.
- Trap
- Equating it with a department.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Architecture Building Block vs. Solution Building Block
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Architecture Building Block | Defines required capability, constraints and interfaces | Product-neutral; defined in Phases B to D | Naming a vendor product as an ABB |
| Solution Building Block | Concrete component that implements an ABB | Product or custom build; identified from Phase E | Selecting SBBs before ABBs exist |
Metamodel vs. taxonomy vs. repository
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Enterprise metamodel | Entity types and their relationships | Structure of content | Treating it as a diagram style |
| Taxonomy | Agreed classification and naming | Vocabulary for content | Confusing it with the metamodel |
| Architecture Repository | Store of architecture content and governance records | Where content lives | Assuming a tool equals a well-run repository |
Initial risk vs. residual risk
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Initial risk | Risk assessed before mitigation | Drives choice of mitigation | Skipping straight to mitigations |
| Residual risk | Risk remaining after mitigation | Must be accepted explicitly | Assuming it is zero |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
More inventory
- What candidates pick
- Commission a new enterprise-wide application inventory to fix inconsistent models.
- Why it looks right
- Data seems to be the problem.
- Why it's wrong
- Without a shared metamodel and taxonomy, a new inventory will be as inconsistent as the old ones.
Clue to watch for Teams describe the same things differently.
-
Maximum detail
- What candidates pick
- Model the whole enterprise at capability architecture level before planning.
- Why it looks right
- Detail seems thorough.
- Why it's wrong
- The level of detail should match purpose and stakeholders; strategic or segment views may be enough.
Clue to watch for Executives need direction quickly.
-
Product as ABB
- What candidates pick
- Define the preferred vendor's CRM suite as the Architecture Building Block.
- Why it looks right
- It is concrete and familiar.
- Why it's wrong
- ABBs describe required capability in product-neutral terms; products are Solution Building Blocks.
Clue to watch for The question is set in Phase B or C.
-
Mitigated equals safe
- What candidates pick
- Proceed because a mitigation plan exists for every risk.
- Why it looks right
- Risks appear addressed.
- Why it's wrong
- Residual risk must still be assessed and accepted by the right authority.
Clue to watch for High-impact risks with partial mitigation.
-
Architects write the scenario
- What candidates pick
- The architecture team drafts business scenarios alone to save stakeholder time.
- Why it looks right
- It is faster.
- Why it's wrong
- Business scenarios need business ownership and iterative refinement with stakeholders to be valid.
Clue to watch for Stakeholders disagree about what they need.
-
Gaps are only systems
- What candidates pick
- Limit gap analysis to applications and infrastructure.
- Why it looks right
- Systems are easiest to list.
- Why it's wrong
- Gaps also exist in people, skills, processes and data, which affect migration planning.
Clue to watch for Training, roles or process changes are mentioned.
Answer framework
Use these steps to judge whether an option uses supporting techniques and structures correctly.
- Name the underlying problem in the scenario: unclear requirements, unknown change scope, inconsistent content, wrong level of detail, uncertain priorities or unmanaged risk.
- Match the technique to the problem: business scenarios, gap analysis, metamodel and taxonomy, architecture levels, value assessment or risk assessment.
- Check the technique is used in the right phase and by the right people, such as business-owned scenarios or Board-accepted residual risk.
- Prefer options that build reusable structure, such as repository areas, building blocks and a tailored metamodel, over one-off documents.
- Confirm the option keeps detail proportionate and allows iteration, so the architecture can be refined in later cycles.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 15
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
With 19 outcomes, this area needs a plan. Group the outcomes into four clusters and study one cluster per session.
First, techniques: business scenarios, gap analysis, Business Architecture techniques, compliance assessments, migration planning techniques, the Implementation Factor Catalog and risk assessment. For each, write one line on the problem it solves and the phase where it is mainly used.
Second, repository and levels: learn the repository areas, what a well-run repository looks like, and the strategic, segment and capability levels. Sketch the Architecture Landscape with three levels and note who uses each.
Third, content structure: building blocks, the enterprise metamodel, the Architecture Content Framework, the TOGAF Enterprise Metamodel and taxonomy. Draw a small model linking a capability, a business service, an application component and a technology component to see how traceability works.
Fourth, iteration and the TOGAF Library: learn the four iteration cycles and how Series Guides tailor the method.
Because the exam is open book, note where each technique sits in the standard. Then practise scenarios by naming the underlying problem first and the technique second. That two-step habit is the fastest way to rank options correctly.
FAQ
How much of the exam is Supporting the ADM Work?
The Open Group publishes no weight for Supporting the ADM Work. It is one of eight syllabus areas for the 8 scenarios, and its techniques usually appear as the tool inside the best option of scenarios about other phases.
Do I need to memorize every technique in detail?
Most outcomes are at the Understanding level, so focus on what each technique is for and when to use it. The open book can confirm details.
What is the difference between an ABB and an SBB?
An Architecture Building Block defines required capability in product-neutral terms; a Solution Building Block is the concrete component, product or build, that implements it.
What are the ADM iteration cycles?
Architecture Context, Architecture Definition, Transition Planning and Architecture Governance. They group phases that are commonly iterated together.
Why does TOGAF need both a metamodel and a taxonomy?
The metamodel defines entity types and relationships; the taxonomy agrees names and classifications. Together they make content consistent and traceable.
How are risks rated in TOGAF risk assessment?
By effect, such as catastrophic, critical, marginal or negligible, and by frequency, from frequent to unlikely. Initial and residual risk are both assessed.
What is the TOGAF Library?
The Open Group's collection of supporting material, including Series Guides, that helps tailor and apply the TOGAF Standard to specific situations.
Other Enterprise Architecture & IT Governance certifications
Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.
Test your Domain 8 knowledge
You have covered the techniques, repository, levels and content structures that support the ADM. Test whether you can spot the right tool for each scenario problem.
Keep going
- Training Training Built on your Weak areas
- Practice test Questions by domain, with explanations
- Mock exam Full length, timed like the real exam
- Readiness test Find your weakest domain in minutes
- Cheat sheet Key terms and formulas on one page
- Ask the TOGAF Practitioner AI tutor Get any concept explained your way