Overview
This syllabus area sets the scene for the whole Practitioner exam. It explains that the purpose of Enterprise Architecture is to guide effective change, and describes what a usable EA looks like: a set of descriptions at different levels and states, kept in a repository and used to make decisions. It covers the Architecture Capability that produces and maintains those descriptions, the role of the Enterprise Architect, and the governance and compliance mechanisms that make architecture count.
The unit then widens the frame. It asks you to explain how architecture keeps change aligned with objectives when delivery teams work in an Agile way, how multiple architecture states (baseline, transition and target) are managed side by side, and why security is treated as a cross-cutting concern with its own Enterprise Security Architecture. It closes with managing uncertainty in change and the architect's role across the four contexts of a digital enterprise described in the DPBoK Standard.
How it's tested
Context outcomes are at the Understanding level, so the exam does not ask you to recite them. Instead, a scenario paints an organization and the four options propose ways forward. The option that respects governance, keeps the architecture aligned to business objectives and treats security as part of the design usually scores best.
-
Capability before content
The organization lacks an Architecture Board, principles or a repository, and the best option establishes or repairs the Architecture Capability before producing more models.
-
Agile alignment
Delivery teams move fast without reference to the target architecture. Strong answers keep teams autonomous but tie their work to architecture guardrails, roadmaps and just-enough descriptions.
-
Security as a thread
Security appears late or as one team's problem. The higher-scoring options involve security stakeholders early and carry security concerns through every phase rather than adding a final review.
A retailer's product teams release weekly but keep building overlapping customer services. One option bans releases until a full target architecture is approved; another lets teams continue unchanged. Neither guides change effectively. The best option defines a target state and principles at the right level of detail, then uses governance checkpoints so teams can keep their pace while converging. Speed and alignment are both respected.
Learning outcomes 11
Official learning outcomes from the The Open Group outline, in outline order.
1.1 Explain why guiding effective change is the purpose of Enterprise ArchitectureBloom level 2. EA exists to steer change, not to document for its own sake.
- What it means
- The TOGAF Standard positions Enterprise Architecture as a way to guide an organization through change so that the change delivers the intended business outcomes. Architecture descriptions matter only because they inform decisions about what to change, in what order and with what constraints.
- What to understand
- Effective change means change that is aligned to strategy, coordinated across organizational units, and delivered with acceptable risk. EA supports this by defining a target, showing the gap from today, and governing the path. A large repository that nobody consults fails this purpose.
- How it shows up
- Options that produce exhaustive models with no decision attached usually score lower than options that use architecture to steer a concrete change.
- Common confusion
- Treating EA as an inventory or documentation exercise rather than a change-guidance discipline.
1.2 Explain what an Enterprise Architecture looks likeBloom level 2. Descriptions at several levels, states and domains, held in a repository.
- What it means
- An Enterprise Architecture is a collection of architecture descriptions covering business, data, application and technology domains, at different levels of breadth and detail, and for baseline, transition and target states. These descriptions sit in the Architecture Repository and are linked by a common metamodel.
- What to understand
- No single diagram is the EA. It is partitioned: strategic architectures give the long-term picture, segment architectures cover a portfolio or business area, and capability architectures detail how a specific capability will be delivered. Each partition answers the concerns of particular stakeholders.
- How it shows up
- A scenario may ask how to organize existing architecture work; partitioning by level and state is a strong signal of the best option.
- Common confusion
- Assuming the EA must be one complete, fully detailed model of the whole enterprise.
1.3 Explain what an Architecture Capability isBloom level 2. The people, processes, governance and tools that run EA as an ongoing practice.
- What it means
- An Architecture Capability is the organization's ability to perform architecture work over time. It combines an organizational model for EA, skilled roles, an agreed and tailored framework, architecture principles, a repository, tools and governance bodies. The Preliminary Phase establishes or adjusts it.
- What to understand
- The capability is itself operated like a business capability, with its own governance, maturity and sponsorship. Without it, individual architecture projects produce isolated outputs that are not reused or governed. The TOGAF Standard groups guidance on building it in its Architecture Capability and governance material.
- How it shows up
- When a scenario shows inconsistent outputs, unclear roles or no sponsor, the best answer often strengthens the Architecture Capability first.
- Common confusion
- Confusing the Architecture Capability with a single architecture project or with the architecture team alone.
1.4 Explain the role of Architecture Governance and of the Enterprise ArchitectBloom level 2. Who controls architecture decisions and who leads the work.
- What it means
- Architecture Governance is how the enterprise controls and monitors architecture work and its use, through bodies such as the Architecture Board, Architecture Contracts and compliance reviews. The Enterprise Architect leads the architecture effort, balances stakeholder concerns and turns strategy into actionable architecture.
- What to understand
- Governance gives decisions authority and traceability: dispensations, conflicts and changes go to the Architecture Board and are recorded. The architect advises and designs but does not overrule sponsors or the Board. Good governance is proportionate, not a bureaucratic gate on every change.
- How it shows up
- Look for options that route conflicts or exceptions to the Architecture Board and keep the architect in an advisory, facilitating role.
- Common confusion
- Picturing the Enterprise Architect as the final approver of all solution designs.
1.5 Explain Architecture Compliance, the levels of conformance and compliance reviewsBloom level 2. Checking that implementations follow the architecture.
- What it means
- Architecture Compliance checks whether projects and solutions follow the architecture. The TOGAF Standard defines graded conformance levels from Irrelevant through Consistent, Compliant, Conformant and Fully Conformant, plus Non-conformant, and a structured Architecture Compliance review process with checklists.
- What to understand
- Reviews should happen at defined points in a project, not only at the end, so problems are caught when they are cheap to fix. Review outcomes can lead to approval, required changes or a dispensation request to the Architecture Board. Findings feed the Governance Log and can trigger architecture change.
- How it shows up
- Scenarios with late surprises reward options that schedule compliance reviews earlier and use the formal review process.
- Common confusion
- Treating compliance as a single pass or fail checkpoint at go-live.
1.6 Explain how architecture enables alignment to objectives, using Agile development as an exampleBloom level 2. Architecture as guardrails for autonomous teams.
- What it means
- Architecture keeps many independent decisions pointed at shared enterprise objectives. With Agile teams, the architecture supplies direction (target states, principles, standards and roadmaps) at the level of detail teams need, while leaving solution choices within those guardrails to the teams.
- What to understand
- The TOGAF Standard supports Agile delivery by working iteratively and by producing architecture just in time and just enough. Strategic and segment architectures set the frame; capability-level detail is developed close to when teams need it. Architects work with teams rather than handing over large documents.
- How it shows up
- Options that halt Agile delivery until big up-front design is complete, or that drop architecture entirely, typically score lowest.
- Common confusion
- Believing TOGAF and Agile are incompatible because the ADM looks sequential.
1.7 Explain how to manage multiple architecture statesBloom level 2. Baseline, transition and target architectures existing at the same time.
- What it means
- At any moment an enterprise has a current baseline, one or more approved targets, and Transition Architectures that describe intermediate states. Several ADM cycles may be running, each producing descriptions for a different scope and time horizon. These states must be managed consistently.
- What to understand
- The Architecture Landscape in the repository holds these states, organized by level and time. Each Transition Architecture should deliver business value on its own. Changes to one state must be checked for impact on others, which is why Phase H and Requirements Management feed back into ongoing work.
- How it shows up
- A scenario with competing programmes may reward the option that maps work onto shared Transition Architectures in the Architecture Landscape.
- Common confusion
- Thinking there is only one baseline and one target for the whole enterprise at a time.
1.8 Explain what Enterprise Security Architecture isBloom level 2. Security described as part of the architecture, not bolted on.
- What it means
- Enterprise Security Architecture describes the security structures, controls, policies and services that protect the enterprise's assets, aligned with business risk and regulatory requirements. The TOGAF Standard addresses it through security-specific guidance in the ADM and a Series Guide on integrating risk and security.
- What to understand
- Security architecture starts from business risk appetite and asset value, then defines controls across business, data, application and technology layers. It has its own stakeholders, such as the security officer, risk manager and data protection lead, and its own artifacts like security policies and risk assessments.
- How it shows up
- Best options tie security requirements to business risk and regulation rather than only to technical tooling.
- Common confusion
- Equating Enterprise Security Architecture with a list of security products or firewall rules.
1.9 Explain security as a cross-cutting concernBloom level 2. Security considerations appear in every ADM phase.
- What it means
- Security is not confined to one phase or one domain. Every ADM phase has security-relevant inputs, steps and outputs, from identifying security stakeholders in Phase A through security controls in Phase D to monitoring security changes in Phase H.
- What to understand
- Treating security as cross-cutting means security architects participate throughout, security requirements enter the Architecture Requirements Specification early, and compliance reviews include security criteria. Adding security only at the end tends to produce expensive rework or accepted risks nobody chose.
- How it shows up
- When a scenario introduces security late, the best option brings security into the current phase and into requirements management, not into a separate later project.
- Common confusion
- Placing all security work in Phase D because controls are often technical.
1.10 Explain how to manage uncertainty in changeBloom level 2. Planning architecture when the future is not fixed.
- What it means
- Change happens with incomplete information about markets, technology and the organization's own capacity. Architecture manages this uncertainty by making assumptions explicit, keeping options open where decisions can wait, assessing risk, and using iteration so plans can be revisited as facts emerge.
- What to understand
- Useful tools include scenario thinking, risk assessment, Transition Architectures that each stand alone, and governance that allows planned review points. Committing early to detailed long-range designs increases the cost of being wrong; deferring every decision stalls change. The skill is choosing which decisions need to be fixed now.
- How it shows up
- Look for options that record assumptions and risks, keep near-term steps concrete and later steps flexible.
- Common confusion
- Thinking uncertainty means architecture work should wait until requirements are stable.
1.11 Explain the roles of the Enterprise Architect in a digital enterprise across the four DPBoK contextsBloom level 2. How the architect's focus changes as an organization scales.
- What it means
- The Open Group Digital Practitioner Body of Knowledge (DPBoK) describes four contexts of organizational evolution: the individual or founder, the team, the team of teams, and the enduring enterprise. The architect's role and the amount of formal architecture differ in each.
- What to understand
- In early contexts architecture is light and mostly implicit in product decisions. As the organization grows into a team of teams, coordination, shared platforms and standards matter more. In the enduring enterprise, formal governance, portfolio management and Enterprise Architecture become necessary to manage complexity, risk and compliance.
- How it shows up
- Scenarios about scaling start-ups or digital units reward options that match the weight of architecture to the organization's context.
- Common confusion
- Applying full enterprise-level governance to a small founding team, or none to a large regulated enterprise.
High-yield concepts
The terms, rules and formulas this domain turns into questions most often.
-
Purpose of EA
Guiding effective change toward business objectives.
- Remember
- Architecture is judged by the decisions and changes it enables.
- Tested as
- Underpins how you rank options in almost every scenario.
- Trap
- Rewarding completeness of documentation over usefulness.
-
Architecture Capability
The ongoing organizational ability to do architecture work: roles, framework, principles, repository, tools and governance.
- Remember
- Established and tailored in the Preliminary Phase.
- Tested as
- Weak-capability scenarios favour fixing the capability.
- Trap
- Equating it with one project team.
-
Architecture Board
Governance body that oversees architecture, resolves conflicts and grants dispensations.
- Remember
- Decisions are recorded so they are traceable.
- Tested as
- Correct escalation route for exceptions and disputes.
- Trap
- Routing exceptions to a project sponsor instead.
-
Conformance levels
Irrelevant, Consistent, Compliant, Conformant, Fully Conformant and Non-conformant.
- Remember
- Non-conformant means a specified feature is implemented incorrectly.
- Tested as
- Background for interpreting compliance review results in scenarios.
- Trap
- Swapping Compliant and Conformant.
-
Architecture partitioning
Strategic, segment and capability architectures with different scope, detail and time horizon.
- Remember
- Partitions are integrated through the Architecture Landscape.
- Tested as
- Helps choose the right level of detail for a request.
- Trap
- Trying to detail the whole enterprise at capability level.
-
Just enough, just in time
Producing architecture at the detail and moment it is needed.
- Remember
- Key to supporting Agile delivery with TOGAF.
- Tested as
- Distinguishes balanced options from big up-front design.
- Trap
- Reading it as permission to skip the target state.
-
Security as a cross-cutting concern
Security activities, stakeholders and requirements run through every ADM phase.
- Remember
- Security stakeholders are identified as early as Phase A.
- Tested as
- Late-security scenarios reward early integration.
- Trap
- Deferring security to a final review.
-
Managing uncertainty
Explicit assumptions, risk assessment, iteration and stand-alone transition steps.
- Remember
- Fix near-term decisions; keep later ones open where possible.
- Tested as
- Volatile-market scenarios.
- Trap
- Waiting for certainty before starting.
-
DPBoK four contexts
Individual or founder, team, team of teams, enduring enterprise.
- Remember
- Formal EA becomes essential in the enduring enterprise context.
- Tested as
- Scaling and digital transformation scenarios.
- Trap
- Prescribing the same governance weight for every context.
Side by side
Concepts candidates mix up, compared on the point that decides the answer.
Strategic vs. Segment vs. Capability architecture
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Strategic architecture | Long-term, enterprise-wide summary view used for direction setting | Broadest scope, least detail | Using it as a build specification |
| Segment architecture | Detailed view of a portfolio, programme or business area | Medium scope, links strategy to programmes | Confusing a segment with a single project |
| Capability architecture | Detailed description of how a specific capability will be realized | Narrow scope, most detail, shortest horizon | Producing it before the strategic frame exists |
Architecture Governance vs. Enterprise Architect role
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Architecture Governance | Control and monitoring of architecture through the Board, contracts and compliance | Holds decision authority and records decisions | Thinking governance means more paperwork only |
| Enterprise Architect | Leads architecture work, facilitates stakeholders and recommends | Advises and designs; does not overrule governance | Making the architect the sole approver |
Enterprise Security Architecture vs. security as a cross-cutting concern
| Concept | Meaning | Key difference | Common trap |
|---|---|---|---|
| Enterprise Security Architecture | The security structures, policies and controls described as part of the EA | A body of architecture content | Reducing it to products |
| Cross-cutting concern | Security work embedded in every ADM phase and domain | A way of working across the method | Confining it to Phase D |
Exam traps
Each trap is an answer that looks right. Learn the clue that should change your mind.
-
Big up-front design
- What candidates pick
- Pause all delivery until a full, detailed enterprise target architecture is approved.
- Why it looks right
- It looks thorough and risk-averse.
- Why it's wrong
- It ignores the purpose of guiding change at a sustainable pace and conflicts with iterative, just-enough architecture.
Clue to watch for Teams are already delivering value; the stem stresses speed or market pressure.
-
Architecture by the architect alone
- What candidates pick
- The lead architect decides the dispute and informs the teams.
- Why it looks right
- It resolves the issue quickly.
- Why it's wrong
- Conflicts and exceptions should go through Architecture Governance so decisions carry authority and are recorded.
Clue to watch for Words like dispute, exception or deviation from standards.
-
Security at the end
- What candidates pick
- Schedule a security assessment once the solution design is complete.
- Why it looks right
- It sounds like a sensible quality gate.
- Why it's wrong
- Security is cross-cutting; late assessment causes rework and unmanaged risk.
Clue to watch for Regulated data, privacy or a risk officer appears in the scenario.
-
Fix the models, not the capability
- What candidates pick
- Produce a fresh set of diagrams to replace inconsistent ones.
- Why it looks right
- It addresses the visible symptom.
- Why it's wrong
- Inconsistent outputs often come from a missing framework, repository or governance, so new diagrams repeat the problem.
Clue to watch for Different teams use different notations, principles are absent, no repository exists.
-
One size of governance
- What candidates pick
- Apply the full enterprise governance model to a small digital start-up unit.
- Why it looks right
- Consistency across the enterprise sounds safe.
- Why it's wrong
- The DPBoK contexts show governance should fit the unit's scale and maturity.
Clue to watch for A small, new or fast-scaling team is described.
Answer framework
Read the organizational context before judging any option in a Practitioner scenario.
- Identify the change the organization is trying to achieve and the business objective behind it, because the best option guides that specific change.
- Check whether an Architecture Capability exists: sponsor, principles, framework, repository and an Architecture Board. If not, favour options that establish the missing parts.
- Look at delivery style and scale; with Agile teams or a small digital unit, prefer options that give guardrails and just-enough architecture rather than heavy gates.
- Ask whether security, risk and compliance stakeholders are involved; downgrade options that defer them to a late review.
- Rank the remaining options by how well they handle uncertainty and multiple states: explicit assumptions, iteration and governed Transition Architectures score higher.
Practice question
Want more like this? The TOGAF Practitioner practice test has questions for every domain.
Checklist
0 of 12
Tick each one you can do without notes. Your ticks stay in this browser.
Study strategy
Study this area as a lens rather than a list. Start with the purpose of EA and the Architecture Capability, because they explain why the other outcomes exist. Then read the governance and compliance material, focusing on who decides what and when reviews take place.
Next, read the guidance on Agile and on managing multiple architecture states together. Sketch a simple picture with a baseline, two Transition Architectures and a target, then mark where Agile teams would take decisions within the guardrails. Do the same for security: write which security activity happens in each ADM phase so you see it as a thread rather than a step.
Because the exam is open book, invest in navigation. Learn where the Fundamental Content covers the capability and governance, and which Series Guides deal with risk and security, agility and the digital enterprise. You will not have time to read during the exam, only to confirm.
Finally, practise reading scenario stems for context clues: missing sponsor, no Board, teams diverging, regulator pressure, or a small fast-growing unit. Write one sentence describing the organization's situation before looking at the options. That habit makes the gradient-scored ranking much easier.
FAQ
How much of OGEA-102 is about The Context for Enterprise Architecture?
The Open Group does not publish a weight for The Context for Enterprise Architecture. It is one of eight syllabus areas behind the 8 scenario questions, and its ideas usually appear inside scenarios about other phases.
Is there an exam called TOGAF 10 Practitioner?
Not by that name. The credential is TOGAF Enterprise Architecture Practitioner, earned through the Part 2 exam OGEA-102 after Foundation, or the combined OGEA-103 exam, both based on the TOGAF Standard, 10th Edition.
Do I need to know the DPBoK Standard in depth?
No. The outcome asks you to explain the architect's role across the four contexts: individual or founder, team, team of teams and enduring enterprise. Know how architecture formality grows with scale.
Does the TOGAF Standard work with Agile delivery?
Yes. It supports iterative work and architecture produced at the right level of detail when needed. The syllabus uses Agile as its example of how architecture keeps teams aligned to objectives.
Why are compliance levels in a Practitioner context unit?
Because scenarios often describe review findings and expect you to know what they mean and what should happen next, such as rework, a dispensation request or architecture change.
Where does security fit in this area?
Two outcomes cover it: what Enterprise Security Architecture is, and why security is a cross-cutting concern handled throughout the ADM rather than in one phase.
How should I use the open book for this area?
Use it to confirm terms and lists you already understand, such as conformance levels or capability components. Reading unfamiliar chapters during a 90-minute exam with long scenarios is rarely possible.
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 1 knowledge
You have covered the purpose of EA, the Architecture Capability, governance, security and the digital enterprise. Check whether you can spot these context clues inside gradient-scored scenarios.
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