The Open Group Certification Exams
A multinational company wants to replace three overlapping customer platforms, consolidate its data estate and introduce new identity controls. Each department has a plausible plan. Finance prioritizes cost, security demands tighter access, operations wants fewer outages and product leaders need faster delivery. Without an enterprise view, the program may improve individual systems while making the organization harder to operate. The Open Group's certifications are relevant because they give architects a common method for turning competing objectives into defensible decisions.
Enterprise architecture is not simply the act of drawing complex diagrams. Its work is to explain how business capabilities, information, applications and technology support an intended outcome, what should change, and who must agree to the consequences. The Open Group maintains the TOGAF standard and several related certification paths. A candidate needs to distinguish knowledge of the method from the ability to apply it; an exam that tests fundamental terminology is different from one that asks how to respond to an ambiguous transformation scenario.
TOGAF Enterprise Architecture Foundation: learning the architecture language
The TOGAF Enterprise Architecture Part 1 exam, OGEA-101, supports the Foundation qualification. It addresses the core ideas behind enterprise architecture, the Architecture Development Method (ADM), governance, architecture content and techniques for managing change. Foundation competence matters because teams cannot have a productive debate about a target architecture if they do not agree on what a requirement, architecture view or building block means.
The ADM provides a structured way to develop, use and maintain an architecture. It is iterative rather than a rigid sequence of documents completed only once. An organization may begin with a high-level vision, investigate business capabilities, design data and application implications, evaluate technology choices and later revisit assumptions as implementation exposes new constraints. The method helps preserve traceability between stakeholder concerns and decisions even when the precise project plan changes.
Foundation candidates should understand architecture governance and the distinction between an artifact and its intended purpose. A catalog of applications can be useful, but only if it reveals ownership, critical dependencies or a genuine rationalization opportunity. A principles document is useful when its principles guide decisions, not because a template demands another deliverable. The candidate's task is to learn how the pieces relate before attempting to optimize a complex organization.
Practitioner: choosing among imperfect architecture options
The TOGAF Enterprise Architecture Practitioner qualification goes beyond recalling definitions. It emphasizes application and analysis: tailoring the ADM, assessing tradeoffs, managing stakeholders and choosing actions that support architecture work in a real organization. In the combined route, OGEA-103 assesses Foundation and Practitioner content together. The Open Group also allows a separate Part 2 route through OGEA-102 after Foundation; that is a different testing arrangement from the combined examination.
Consider a bank replacing its payments platform. A technology team proposes immediate migration because the current service is costly. The risk team rejects it because evidence for recovery objectives is incomplete. Operations fears that the new architecture will split incident ownership across vendors. A Practitioner-level response is not to announce that the architecture diagram is correct. It is to establish decision criteria, agree on risk ownership, use business and technology viewpoints to expose constraints, and create a transition plan whose assumptions can be tested.
A candidate preparing for scenario questions should examine why one action would be more suitable than another given limited evidence. A stakeholder objection may signal a missing requirement rather than resistance to change. A migration dependency may justify another architecture iteration rather than forcing the original sequence. The Practitioner assessment rewards an ability to place techniques inside the purpose of a decision rather than choosing a technique because its name appears in the question.
Architecture views must serve specific concerns
An enterprise has multiple legitimate pictures of itself. A chief financial officer may care about duplicated capabilities and operating cost. A security lead needs to know trust boundaries and sensitive data movement. A product executive asks which capabilities enable customer outcomes. An operations lead wants to see single points of failure and recovery dependencies. No one diagram adequately answers every question. The architect must select viewpoints that illuminate the concerns of the people who need to decide.
In the payments example, a capability map can reveal that several business units perform the same fraud-review process. An information flow view might expose where customer data crosses jurisdictional boundaries. An application integration diagram can reveal fragile dependencies. A deployment view may show that two supposedly redundant services share a single network component. These models are more valuable when they reveal conflicts than when they agree neatly with an existing proposal.
Business architecture is consequently not just a subset of server architecture. The Open Group also provides a TOGAF Business Architecture Foundation route for professionals focused on capabilities, value streams and business planning. It should be considered on its own terms. Candidates whose work is about product operating models and capability investment may be better served by business architecture studies before pursuing deep technology architecture.
Using the ADM without turning it into document production
ADM phases help architects organize inquiry and decision-making: identifying the vision and scope, elaborating business and information-system architectures, considering technology, assessing opportunities and migration planning, governing implementation, and managing change. Requirements management connects the phases. Their value is not the existence of a document at each milestone; it is that architecture decisions remain accountable to business outcomes and testable constraints.
Suppose a company wants to standardize identity for acquired subsidiaries. Before designing a single sign-on topology, architects need to understand workforce populations, regulatory obligations, legacy access models, trust boundaries and what happens during an outage. During planning, they can distinguish near-term integration from longer-term consolidation, select governance checkpoints and design a transition where services remain operable. During implementation, conformance reviews should test relevant principles without pretending that every change can be postponed until a perfect target state exists.
Architecture teams also need to tolerate uncertainty. A capability map might reveal missing ownership, and the target state may depend on a product strategy still being debated. A responsible architect can state alternatives, record assumptions and recommend what evidence would make the choice clearer. A premature claim of certainty is not a sign of expertise; it merely transfers risk into implementation.
Governance, risk and security require explicit decisions
Architecture governance defines who can approve deviations, how standards are interpreted and when changes need review. It is related to project governance but not identical. A project may be on schedule and within budget while violating the organization's security architecture or creating unsupportable integration patterns. Conversely, an architecture exception may be defensible when there is a clear business need, bounded risk and a planned review date.
Security architecture should be part of the method from the beginning. A new data-sharing design raises privacy, identity, resilience and audit questions, not just connection questions. Governance must preserve evidence of why a risk was accepted or a control was chosen. If the organization later experiences a breach or service outage, it needs to reconstruct decisions and understand where assumptions failed. A diagram without an accountable owner and a record of its constraints does little to support that investigation.
Architects should examine the cost of over-governance too. A review board that approves every small change can make teams work around the process. Mature governance is proportionate to impact and risk, and distinguishes standards that protect important outcomes from habits maintained only because they have always been required.
Current pathways, old qualifications and related standards
The TOGAF certification portfolio includes paths based on the TOGAF Standard, 10th Edition and historical paths tied to the Version 9.2 body of knowledge. The Open Group offers options for candidates already certified under TOGAF 9, including a bridge route where applicable. A certificate's title must not be casually renamed “TOGAF 10 Certified”; official credentials are called TOGAF Enterprise Architecture Foundation and Practitioner, with other portfolio options for business architecture and specific competencies.
The Open Group also maintains the ArchiMate modeling language. Learning ArchiMate can improve how an architect expresses relationships across business, application and technology layers, but it should not be conflated with passing a TOGAF exam. A notation helps communicate an architecture; the method helps plan and govern architecture work. They may complement each other without being the same qualification.
A professional reading older materials should confirm whether the exam refers to TOGAF 9 or the newer Enterprise Architecture portfolio, whether it is a Foundation, Practitioner, combined or bridge path, and whether any additional post-exam certification steps apply. The official syllabus and certification policy are more reliable than a course title that happens to include “latest.”
Studying through decisions rather than diagrams alone
Build a practice case around a company with an outdated product platform and conflicting stakeholder priorities. Identify the stakeholders, their concerns and the principles that govern plausible designs. Produce only the views required to support decisions, and note what evidence each would need. Then compare two migration strategies: a faster cutover with greater operational risk, and a staged transition with higher integration cost. Explain why one is preferable given the stated constraints.
For the Practitioner route, make the scenario harder by introducing a new regulation, an unexpected dependency and a department that changes its strategy. The OGEA-103 approach to ADM scenarios becomes useful where a candidate must choose what to do next rather than define a term. Understanding how Foundation knowledge becomes architecture judgment also helps prevent a common failure: treating the ADM as a memorized checklist rather than a way to navigate change.
The strongest preparation ends with an explainable architecture decision. Can stakeholders see the options, tradeoffs and reasons for the recommendation? Can implementers identify nonnegotiable constraints and areas where they may adapt? Can governance review an exception without restarting the entire program? An enterprise architect who can answer those questions has gained something more valuable than a collection of templates.
