Overview
The ADM says what to do in each phase; the ADM Techniques explain how to do key tasks. This unit starts with that relationship and then covers the techniques the Foundation syllabus names. Architecture Principles get the most attention: why they exist, the recommended template of Name, Statement, Rationale and Implications, and the five qualities of a good principle. Business scenarios are the technique for discovering business requirements and grounding the Architecture Vision.
The remaining techniques support planning and delivery. Gap analysis validates an architecture by exposing differences between baseline and target. Interoperability defines how information and services must be shared, at business, information and technical levels. Business Transformation Readiness Assessment judges whether the organization can absorb the change. Architecture risk management identifies, classifies and mitigates risks and is applied at specific points of the ADM. For each technique, know what it is for and which phases use it.
How it's tested
Questions in this unit are short recall and application items. Typical stems quote a fragment of a principle and ask which template section it belongs in, list qualities and ask which makes a principle good, or describe an activity such as rating readiness factors and ask which technique or phase it belongs to.
-
Template section match
A sentence from a principle is given and you place it in Name, Statement, Rationale or Implications. Business benefit points to Rationale; required actions and consequences point to Implications.
-
List membership
Which item is a quality of a good principle, a readiness factor, or a step of risk management. Distractors are plausible-sounding words not on the official list, such as 'measurable' for principles.
-
Technique to phase
A technique is named and you choose where it is mainly used, for example business scenarios in Phase A or readiness assessment in Phase A and again in E and F.
A stem gives two draft principles: one says data must be shared across business units; the other says data must be held only by the unit that created it. Which quality of a good principle is missing? Completeness and robustness are tempting, but the problem is that the two principles contradict each other. Principles must work together, so the missing quality is consistency. Spot the contradiction and the answer follows.
Learning outcomes 9
Official learning outcomes from the The Open Group outline, in outline order.
4.1 Describe how the ADM and Supporting Guidelines and Techniques relateThe ADM is the method; guidelines adapt it, techniques support its tasks.
- What it means
- The ADM defines the phases and their objectives. Guidelines explain how to adapt the ADM to a context, such as iteration or different architecture levels, and techniques are reusable ways of carrying out specific tasks within phases.
- What to understand
- Techniques do not replace the ADM; they plug into it. Architecture Principles, business scenarios, gap analysis, interoperability analysis, readiness assessment and risk management are each used in particular phases, and an organization can choose which to apply.
- How it shows up
- A stem asks which statement best describes the relationship: techniques support specific ADM tasks and can be used as needed, rather than forming a separate method.
- Common confusion
- Treating the techniques as extra mandatory phases of the ADM.
4.2 Explain the purpose of Architecture PrinciplesEnduring rules that guide architecture decisions.
- What it means
- Principles are general rules and guidelines, intended to be enduring and seldom amended, that inform and support the way an organization fulfils its mission. Architecture Principles apply this to architecture work, guiding the development, maintenance and use of the EA.
- What to understand
- Architecture Principles sit beneath enterprise principles and must align with them. They provide a basis for decisions, for evaluating alternatives and for assessing compliance. They are defined in the Preliminary Phase and confirmed in Phase A.
- How it shows up
- A stem asks what Architecture Principles provide; the answer is a stable basis for architecture decision-making, not detailed design instructions.
- Common confusion
- Thinking principles are project-specific rules that change with every effort.
4.3 Explain the recommended template for Architecture PrinciplesName, Statement, Rationale, Implications.
- What it means
- The TOGAF Standard recommends four parts: Name (a short, memorable label that says the essence of the rule), Statement (the rule itself, stated clearly), Rationale (the business benefits of following it) and Implications (the requirements, costs and tasks of carrying it out).
- What to understand
- Rationale answers 'why is this worth doing' in business terms; Implications answers 'what does this mean for us in practice'. The Name should not refer to specific technology platforms.
- How it shows up
- A stem quotes 'this requires all units to retire local customer databases' and asks which section it belongs in: Implications.
- Common confusion
- Putting business benefits in Implications, or required actions in Rationale.
4.4 Explain what makes a good Architecture PrincipleUnderstandable, robust, complete, consistent, stable.
- What it means
- The TOGAF Standard lists five criteria: Understandable (anyone can grasp it without ambiguity), Robust (precise enough to support consistent decisions in complex situations), Complete (covers every situation perceived as important), Consistent (principles do not contradict each other) and Stable (enduring, yet able to accommodate change through an amendment process).
- What to understand
- Consistency allows for balanced interpretation between principles, but they should not directly conflict. A small set of well-chosen principles is better than many overlapping ones.
- How it shows up
- A stem describes two principles that contradict each other and asks which quality is violated: consistency.
- Common confusion
- Adding qualities that sound right but are not on the list, such as measurable or technology-specific.
4.5 Briefly explain business scenariosA technique for discovering and documenting business requirements.
- What it means
- A business scenario describes a business problem, its environment, the people and systems involved and the desired outcome, so that business requirements can be derived and the architecture's value can be shown. A good scenario is SMART: Specific, Measurable, Actionable, Realistic and Time-bound.
- What to understand
- Developing one means identifying the problem, environment and objectives, then the human actors, computer actors and their roles and responsibilities, and refining with stakeholders. Business scenarios are used mainly in Phase A to build the Architecture Vision, and also in Phase B and in requirements work.
- How it shows up
- A stem asks which technique helps identify and articulate business requirements and the Architecture Vision: business scenarios.
- Common confusion
- Treating business scenarios as test cases or as a description of the IT solution.
4.6 Explain the purpose of gap analysisValidate the architecture by exposing shortfalls between baseline and target.
- What it means
- The purpose of gap analysis is to validate an architecture under development by highlighting the shortfalls between the baseline and target architectures, so that items deliberately or accidentally omitted are made visible and new items are identified.
- What to understand
- Gaps can involve business functions, data, applications, technology, people and skills. A baseline item missing from the target must be confirmed as a deliberate elimination or corrected. Gap analysis is applied in Phases B, C and D and consolidated in Phase E.
- How it shows up
- A stem asks the main purpose of gap analysis; 'to validate the architecture by highlighting shortfalls between baseline and target' fits.
- Common confusion
- Thinking gap analysis is mainly for budgeting or for comparing vendor products.
4.7 Briefly explain interoperability and how it is usedDefining how information and services are shared.
- What it means
- Interoperability is the ability to share information and services between systems and organizations. The TOGAF Standard describes business (operational) interoperability, information interoperability and technical interoperability, and degrees of information interoperability from unstructured data exchange up to seamless sharing of information.
- What to understand
- Interoperability requirements are identified early (Phase A sets the nature and security of information and service exchanges), developed in Phases B to D and consolidated in Phase E, where they help shape solutions and work packages.
- How it shows up
- A stem asks what interoperability means in TOGAF; 'the ability to share information and services' is the answer.
- Common confusion
- Treating interoperability as purely a technical networking concern.
4.8 Explain Business Transformation Readiness Assessment and where it is usedCan the organization absorb this change, and what must improve first?
- What it means
- Business Transformation Readiness Assessment evaluates and quantifies an organization's readiness to undergo change. It determines readiness factors (such as vision, desire and resolve, need, business case, funding, sponsorship and leadership, governance, and capacity to execute), presents them, rates them, assesses the risks for each and identifies improvement actions.
- What to understand
- It is first carried out in Phase A, where it shapes the scope and the Statement of Architecture Work, and its results are used in Phases E and F to plan the migration. Findings feed the Implementation and Migration Plan.
- How it shows up
- A stem describes rating the organization's funding, sponsorship and capacity to execute before committing to a transformation and asks which technique this is.
- Common confusion
- Thinking readiness assessment checks technical capability only, or that it happens only once at the end of planning.
4.9 Briefly explain architecture risk management and where it is used in the ADMInitial and residual risk, classification, and the phases that use them.
- What it means
- Architecture risk management identifies, classifies and mitigates risks to the transformation. Risks are classified by effect (catastrophic, critical, marginal, negligible) and frequency (frequent, likely, occasional, seldom, unlikely), giving an impact level, and are assessed before (initial) and after (residual) mitigation.
- What to understand
- Risks are identified in Phase A, mitigation is built into the Implementation and Migration Plan in Phases E and F, and risks are monitored in Phase G. Risk management is a continuous activity rather than a one-time step.
- How it shows up
- A stem asks in which phase risks are first identified and initially assessed for an architecture effort: Phase A.
- Common confusion
- Placing risk management only in Phase G, or believing mitigation should remove all risk.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Principle template
The recommended format for a principle has four parts: Name, Statement, Rationale and Implications.
- Remember
- Rationale gives the business benefit; Implications gives the consequences, costs and actions.
- Tested as
- The most frequently tested item in this unit.
- Trap
- Swapping Rationale and Implications.
-
Qualities of a good principle
A good set of principles is understandable, robust, complete, consistent and stable.
- Remember
- Consistent means principles do not contradict each other; stable means they endure but can be amended by a defined process.
- Tested as
- List-membership and 'which quality is violated' questions.
- Trap
- Choosing 'measurable', which belongs to SMART business scenarios.
-
Enterprise vs. architecture principles
Enterprise principles guide the whole organization; architecture principles apply them to architecture work and must align with them.
- Remember
- Architecture Principles are defined in the Preliminary Phase and confirmed in Phase A.
- Tested as
- Placement and hierarchy questions.
- Trap
- Thinking architecture principles can override enterprise principles.
-
Business scenario
A description of a business problem, its environment, actors and desired outcome, used to derive business requirements and support the Architecture Vision.
- Remember
- A good scenario is SMART, and it is used mainly in Phase A.
- Tested as
- Technique identification questions.
- Trap
- Treating it as a technical use case or test script.
-
SMART
Specific, Measurable, Actionable, Realistic and Time-bound: the TOGAF test for a good business scenario's objectives.
- Remember
- SMART applies to business scenarios, not to Architecture Principles.
- Tested as
- Distractor source in principle questions.
- Trap
- Mixing SMART with the five qualities of a good principle.
-
Gap analysis purpose
Validating an architecture by exposing shortfalls between baseline and target, including items eliminated deliberately or accidentally.
- Remember
- Applied in Phases B to D and consolidated in Phase E.
- Tested as
- Outcome 4.6 asks for the purpose directly.
- Trap
- Describing it as a cost comparison.
-
Interoperability categories
Business (operational), information and technical interoperability describe what is shared: processes, information or technical services.
- Remember
- Interoperability is 'the ability to share information and services'.
- Tested as
- Definition and usage questions.
- Trap
- Limiting it to network connectivity.
-
Degrees of information interoperability
Four degrees: unstructured data exchange, structured data exchange, seamless sharing of data, and seamless sharing of information.
- Remember
- Higher degrees mean shared meaning, not just shared bytes.
- Tested as
- Occasional recall item.
- Trap
- Reversing the order of the degrees.
-
Business Transformation Readiness Assessment
A technique that determines, rates and assesses risks for readiness factors so the organization's ability to change is understood before committing.
- Remember
- First used in Phase A, then in Phases E and F; actions go into the Implementation and Migration Plan.
- Tested as
- Technique-to-phase questions.
- Trap
- Thinking it measures only IT readiness.
-
Risk classification
Risks are rated by effect (catastrophic, critical, marginal, negligible) and frequency (frequent, likely, occasional, seldom, unlikely) to give an impact level.
- Remember
- Initial risk is before mitigation; residual risk is after.
- Tested as
- Characteristics of architecture risk management.
- Trap
- Expecting residual risk to be zero.
-
Risk across the ADM
Risks are identified in Phase A, mitigation is planned in Phases E and F, and risks are monitored in Phase G.
- Remember
- Risk management is continuous across the cycle.
- Tested as
- 'Where is it used' outcome 4.9.
- Trap
- Assigning risk management to a single phase only.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Statement vs. Rationale vs. Implications
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Statement | The rule itself, stated clearly and unambiguously | Says what must be done | Loading it with justification or consequences |
| Rationale | The business benefits of adhering to the principle | Says why, in business terms | Listing required actions here |
| Implications | Requirements, costs, tasks and consequences of following it | Says what it means in practice | Repeating benefits here |
Qualities of a good principle vs. SMART business scenarios
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Good principle qualities | Understandable, robust, complete, consistent, stable | Judge enduring decision rules | Adding measurable or time-bound |
| SMART | Specific, measurable, actionable, realistic, time-bound | Judge the objectives of a business scenario | Applying SMART to principles |
Gap analysis vs. readiness assessment vs. risk management
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Gap analysis | Compare baseline and target architectures | Finds what must change in the architecture | Using it to judge organizational willingness |
| Business Transformation Readiness Assessment | Rate the organization's readiness factors for change | Finds whether the organization can absorb change | Treating it as an IT capacity check only |
| Risk management | Identify, classify, mitigate and monitor risks | Finds what could go wrong and how severe it is | Expecting mitigation to remove all risk |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Benefits in Implications
- What candidates pick
- Implications for a sentence describing how a principle reduces cost or improves service.
- Why it looks right
- Benefits feel like consequences of the principle.
- Why it's wrong
- Business benefits belong in Rationale; Implications lists what must be done, changed or paid for.
Clue to watch for If the sentence says why the business gains, it is Rationale; if it says what the organization must do, it is Implications.
-
SMART principles
- What candidates pick
- 'Measurable' or 'time-bound' as a quality of a good principle.
- Why it looks right
- SMART is a well-known quality test and appears in the same unit.
- Why it's wrong
- The five qualities are understandable, robust, complete, consistent and stable; SMART applies to business scenarios.
Clue to watch for Principles are enduring, so any time-bound quality does not fit them.
-
Technology-specific principle names
- What candidates pick
- A principle named after a specific product or platform as a good example.
- Why it looks right
- Concrete names seem clear.
- Why it's wrong
- The template advises names that capture the essence of the rule without referring to specific technology, so principles stay stable.
Clue to watch for A vendor or product name in a principle name signals a poor principle.
-
Readiness equals technical readiness
- What candidates pick
- An answer that limits readiness assessment to IT capacity.
- Why it looks right
- Architecture work is often seen as technical.
- Why it's wrong
- Readiness factors include vision, desire, need, business case, funding, sponsorship, governance and departmental capacity, not only IT.
Clue to watch for Words such as sponsorship, funding or willingness point to readiness assessment.
-
Risk in one phase
- What candidates pick
- Phase G as the only phase where risk management happens.
- Why it looks right
- Monitoring risks during implementation is the most visible activity.
- Why it's wrong
- Risks are identified in Phase A, mitigated through planning in E and F and monitored in G.
Clue to watch for 'First identified' points to Phase A; 'monitored' points to Phase G.
-
Techniques as mandatory phases
- What candidates pick
- A statement that every technique must be applied in every ADM cycle.
- Why it looks right
- The techniques appear in the standard alongside the ADM.
- Why it's wrong
- Techniques support ADM tasks and are selected and tailored as needed; the standard is meant to be adapted.
Clue to watch for 'Must always' wording about techniques usually signals a distractor.
Answer framework
Use these steps when a question asks which technique applies, or how a technique should be used.
- Identify what the stem is trying to find out: a rule, a business requirement, a difference between states, a sharing need, the organization's ability to change, or a threat.
- Map that need to its technique: principles, business scenarios, gap analysis, interoperability, readiness assessment or risk management.
- For principles, sort the quoted text into Name, Statement, Rationale or Implications by asking whether it states the rule, the benefit or the consequence.
- Check where the technique is used in the ADM, such as Phase A for business scenarios and initial readiness and risk.
- Reject options that make a technique mandatory everywhere or swap the official list items with similar-sounding words.
Practice question
Want more like this? The TOGAF EA Foundation practice test has questions for every domain.
Checklist
0 of 13
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Start with Architecture Principles, because they carry the most testable lists in the unit. Learn the four template sections by writing one principle of your own, then move sentences between Rationale and Implications until the distinction is automatic. Then learn the five qualities with a one-line example of a principle that fails each one.
Next, take business scenarios and SMART together, so you never mix SMART into the principle qualities. Follow with gap analysis, which you already met in Concepts; here the focus is its purpose and the phases that use it.
The commonly underestimated areas are Business Transformation Readiness Assessment and interoperability. Both look like side topics but produce clean recall questions. For readiness, learn the steps and several factors, and remember it starts in Phase A and is used again in E and F. For interoperability, learn the definition and the business, information and technical categories.
Finish with risk management: the effect and frequency scales, initial versus residual risk, and the phases where risks are identified, mitigated and monitored. Then drill mixed questions that name a technique and ask for its phase, since that links this unit back to the ADM.
FAQ
How many questions come from ADM Techniques?
The official OGEA-101 exam plan allocates 6 of the 40 questions to this unit, which is 15% of the paper.
What is the recommended template for an Architecture Principle?
Name, Statement, Rationale and Implications. Rationale explains the business benefit; Implications describes the requirements, costs and actions that follow from the principle.
What makes a good set of principles?
They should be understandable, robust, complete, consistent and stable. A contradiction between two principles is a failure of consistency.
Where are business scenarios used?
Mainly in Phase A to identify business requirements and support the Architecture Vision, and also in Phase B and wherever requirements need to be clarified.
Is gap analysis in Concepts or in this unit?
Both. Concepts asks you to explain what gap analysis is; this unit asks for its purpose, which is to validate an architecture by exposing shortfalls between baseline and target.
When is Business Transformation Readiness Assessment done?
It is first carried out in Phase A and used again in Phases E and F, where the improvement actions it identifies are built into the Implementation and Migration Plan.
Do I need to memorize every readiness factor?
You should recognize the main factors, such as vision, desire and resolve, need, business case, funding, sponsorship, governance and capacity to execute, so you can tell a real factor from a distractor.
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 3 knowledge
You have just worked through the principle template, the qualities of good principles and where each technique fits in the ADM. Check that you can sort a sentence into Rationale or Implications without hesitating.
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 EA Foundation AI tutor Get any concept explained your way