The Open Group OGEA-103: ADM Scenario Reasoning

The OGEA-103 exam combines TOGAF Enterprise Architecture Part 1 and Part 2. The Part 1 section checks Foundation knowledge; Part 2 uses open-book, gradient-scored scenarios where several answer choices can contain valid TOGAF ideas but one best fits the situation.

Scenario reasoning improves when you identify the architecture decision before looking for framework terminology. Ask which ADM context you are in, what stakeholder concern is driving the work, which requirement changed, what artifact or technique is needed now, and whether the answer belongs to architecture, governance, project delivery, or service management.

Start by naming the ADM context

Is the organization establishing architecture capability, framing an Architecture Vision, developing business/data/application/technology architecture, planning migration, governing implementation, or responding to architecture change?

The same technique can be valid in several phases but more appropriate in one. Scenario questions often distinguish sequence rather than truth versus falsehood.

The OGEA-101 exam represents the Foundation boundary. Basic ADM purpose should already be available from memory so Part 2 time is spent on judgment.

Write the likely phase or activity beside each practice scenario before ranking answers.

Add scope to the phase decision. Enterprise-wide, segment, capability, and solution architecture can use the same ADM differently because the breadth and stakeholders change.

If the scenario describes a repeating architecture capability rather than one project, look for governance, repository, principles, and operating-model clues before forcing it into a single ADM phase.

Separate the stakeholder concern from the proposed solution

A finance stakeholder may care about investment and cost, operations about manageability, security about control, and product leadership about time to market. Those concerns shape which view and decision matter.

Do not assume the loudest stakeholder owns the architecture. Map influence, concern, decision authority, and relevant expertise.

A good answer often starts by clarifying or addressing the concern before committing to a detailed technical solution.

The architecture should communicate differently to different stakeholders without changing the underlying truth.

Create one scenario where two powerful stakeholders disagree and neither is simply wrong. The architect may need to surface the tradeoff, apply principles, and seek governance rather than choosing the loudest voice.

Architecture communication should reduce disagreement caused by different mental models. Sometimes the correct next action is a better view or clarification, not a technical design change.

Use requirements traceability to control change

When a new regulation, merger, business goal, or technical constraint appears, trace which architecture decisions and artifacts depend on it.

Requirements Management operates across the ADM, so the answer may involve revisiting earlier work rather than forcing the new requirement into the current phase mechanically.

Distinguish a local implementation detail from a requirement that changes target architecture. Not every delivery issue deserves a new architecture cycle.

The strongest answer preserves traceability so the organization understands why a later design changed.

Add assumption and constraint tracking beside requirements. A design decision can become invalid when an assumption changes even if the stated business requirement remains the same.

The best scenario answer preserves enough traceability that the organization can revisit the affected architecture deliberately instead of discovering the impact during implementation.

For gap-analysis scenarios, ask what decision the gap enables

A gap is the difference between baseline and target. It becomes useful when connected to work packages, transition architecture, dependencies, capability change, or migration priority.

Do not choose an answer that simply creates a larger list of gaps without helping the organization decide what to do next.

Several gaps may be addressed by one initiative, and one gap may require multiple coordinated changes.

Part 2 often rewards the option that uses the technique as input to architecture change rather than treating the technique as the end product.

Add one gap that the organization deliberately accepts for now because cost or dependency makes immediate remediation impractical. The architecture can still record the gap and include it in a later roadmap.

This helps distinguish target-state purity from realistic transition planning. Enterprise architecture often moves through intermediate states rather than jumping directly from baseline to final target.

For content questions, identify the audience and purpose

A catalog, matrix, diagram, view, viewpoint, building block, or deliverable is useful because it answers a particular architecture question.

If the scenario asks how to communicate concerns to an executive, a highly technical artifact may be correct but inappropriate. If the delivery team needs interface detail, a capability-level view may be too abstract.

Practice representing the same architecture with two views and explain why both are accurate. This prevents terminology from becoming a memorization exercise.

Choose the content form that supports the decision the stakeholder must make.

Use one scenario where an artifact contains technically correct detail that is simply inappropriate for the decision-maker. The best answer may be to create a different view rather than change the architecture itself.

Architecture communication is successful when it helps the stakeholder decide, not when it displays the maximum amount of architecture content.

For governance scenarios, distinguish conformance from project control

Architecture governance evaluates whether implementation conforms to agreed direction, principles, standards, building blocks, and risk decisions. Project management controls delivery commitments.

The PMP exam is a useful boundary. A project can be on time and still violate architecture; architecture governance should not try to replace schedule or procurement management.

When a delivery team proposes a deviation, decide whether to correct it, approve an exception, or revise the architecture based on new evidence.

The answer should preserve controlled decision authority rather than ignoring the deviation or forcing compliance without evaluating context.

Use gradient scoring to rank, not merely eliminate

Part 2 questions are designed so a second-best option may still contain legitimate TOGAF behavior. Rank choices by how directly they address the scenario now.

A valid technique performed too early can be weaker than a simpler action that clarifies stakeholders or requirements first.

Explain why the best choice is more appropriate, not only why the others are wrong. This habit prepares you for the actual scoring model.

Avoid selecting the answer with the most TOGAF vocabulary. Relevance and sequence matter more than terminology density.

Practice explaining why one answer is partially correct but weaker. It may use the right technique in the wrong phase, address one stakeholder but not the primary concern, or skip a necessary prerequisite decision.

This nuance is exactly why Part 2 rewards ranking rather than simple true/false recognition. The exam is testing architecture judgment under context.

After each practice question, identify what additional fact would make your second-best answer become the best one. This shows that you understand the context sensitivity of architecture decisions rather than treating one TOGAF technique as universally superior.

That habit is particularly valuable when two answer choices differ mainly in sequence, stakeholder involvement, or the amount of architecture work justified at the current stage.

Use open-book reference after reasoning

The electronic reference is most useful for confirming a nuanced point after you have interpreted the scenario. If you search before forming a hypothesis, you can spend time locating correct material that does not answer the question.

Practice navigating to ADM guidance, architecture content, governance, techniques, and Series Guides quickly. Know which topics belong in memory and which are reasonable lookup candidates.

The OGEA-102 Part 2 exam is the standalone Practitioner section, so its scenario logic is the same skill OGEA-103 candidates need in the combined route.

Time pressure becomes manageable when search is confirmation, not discovery.

Practice with a fixed lookup limit—perhaps one or two minutes. If you cannot find the concept quickly, make the best judgment and move on rather than sacrificing the rest of the section.

After practice, move repeatedly searched Foundation concepts into memory. The reference should be reserved for nuance, not routine terminology you can learn before exam day.

Keep service and delivery methods in their own lane

The ITIL Foundation Version 5 exam is a useful service-management boundary. ITIL can guide digital product/service value and continual improvement while TOGAF guides enterprise architecture development and governance.

Do not force a service-management answer into an architecture question simply because the scenario mentions operations, and do not use TOGAF to replace normal project management.

The TOGAF Enterprise Architecture Practitioner credential exists to validate application of architecture concepts in context.

The The Open Group exam inventory can help with exam-path navigation. OGEA-103 success comes from knowing which framework action is best now, for this stakeholder, in this architecture context.

Finish with one scenario that mentions Agile delivery, operational service concerns, and enterprise architecture at the same time. Identify which issue belongs to TOGAF and which belongs to project or service-management methods.

The strongest architect collaborates across those disciplines without claiming that one framework replaces the others. Role clarity improves both the scenario answer and real enterprise work.

Use one final cross-framework case and write three columns: architecture decision, project-delivery decision, and service-management decision. Assign each issue to the appropriate discipline before selecting the TOGAF action.

Clear boundaries do not reduce collaboration; they make collaboration stronger because each method is used for the problem it was designed to solve.

• Category: All Certifications Certifications