The Open Group Certification Exams
The Open Group certification portfolio addresses a problem that is easy to underestimate: different teams often describe the same enterprise in incompatible ways. Business leaders discuss capabilities and outcomes, solution designers discuss applications and interfaces, platform engineers discuss deployments and infrastructure, and risk teams discuss control objectives. Enterprise architecture brings these views into a coherent decision process. Certification matters when it helps a practitioner explain trade-offs, produce usable architectural evidence, and govern change, not when it gives every diagram a formal-looking title.
The Open Group administers different standards and credential families, notably TOGAF enterprise architecture and ArchiMate modeling. TOGAF provides concepts, a method, and governance structures for architecture practice. ArchiMate is a language for expressing architectural relationships. They complement one another, but a model drawn with ArchiMate is not a substitute for running an architecture-development process, and being able to describe the TOGAF method does not prove the ability to create a clear model. Candidates should select a qualification based on the work they perform and the competence they need to demonstrate.
TOGAF separates architecture purpose from technology preference
Enterprise architecture begins with the reason change is needed. An organization might want to shorten onboarding time, reduce duplication across product teams, improve regulatory reporting, or modernize aging applications without interrupting vital services. Those objectives require understanding current capabilities, stakeholders, constraints, operating models, and the consequences of change. The architect's task is not simply to recommend the newest platform; it is to make important relationships and choices visible to decision-makers.
The TOGAF Standard, 10th Edition includes core content for the Architecture Development Method (ADM), techniques, application of the method, architecture content, and governance. The method provides a repeatable structure for examining business, data, application, and technology architectures, defining gaps, evaluating opportunities, and planning change.
That structure must still be tailored to organizational size and risk. A small digital product may not need the same document package as a regulated merger integration, even when both benefit from explicit architecture decisions.
Consider a hospital system integrating appointment scheduling after an acquisition. It may have two patient identifiers, incompatible consent mechanisms, and differing uptime requirements. Replacing the scheduling application without examining data ownership and clinical workflow may create a more modern technical stack while making service worse. Enterprise architecture clarifies which business processes and information objects are authoritative, who controls interfaces, and what transition steps avoid breaking ongoing care.
Foundation validates the vocabulary and structure of enterprise architecture
The TOGAF Enterprise Architecture Part 1 exam (OGEA-101) supports the Foundation qualification. It tests understanding of the core TOGAF concepts, the ADM, selected techniques, how the method is applied, architecture content, and governance. Foundation-level preparation should make each term operational. It is not enough to memorize ADM phase names if the candidate cannot explain why stakeholders need a shared architecture vision or how an architecture requirement influences later decisions.
Architecture principles describe enduring decision criteria, while requirements define specific needs that a solution must satisfy. A principle such as favoring reusable services can inform a design, but it does not itself specify authentication latency, legal data residency, or the acceptable recovery point. A business capability such as managing claims can persist even as the workflow, data stores, and applications supporting it change. Confusing these levels makes architectures brittle because every technology replacement seems to require rewriting the enterprise's purpose.
A helpful Foundation exercise is to describe one business change using a capability map, selected stakeholders, current and target constraints, and a small set of measurable outcomes. If the team proposes retiring a legacy interface, the architecture should show which dependent applications must move, how data continuity will be assured, and who has authority to accept a residual risk. The model need not be large to demonstrate the relationship among concepts.
Practitioner examinations ask candidates to apply judgment to scenarios
The TOGAF Enterprise Architecture Combined exam (OGEA-103) covers the Foundation and Practitioner assessments in one sitting for the relevant combined pathway. The Open Group also offers a route through Part 1 followed by the Part 2 Practitioner exam, and bridge options for certain existing qualification holders. These alternatives should not be represented as additional independent architecture specialties; they are different examination routes toward defined qualifications.
Practitioner work concerns application of the method to a scenario. A senior sponsor may demand a solution before agreeing on the business problem; a program may have conflicting stakeholders; an architecture decision may be technically desirable but unacceptable because of operational constraints. A practitioner has to select the next sensible activity, decide what evidence is missing, and explain how to progress under governance.
An answer justified only by "the next phase in the list" is often inadequate for a real architecture decision.
The Open Group's Part 2 exam supplies specified reference materials inside the exam environment. Open-book access changes the skill being tested: a candidate should know where concepts belong and how to use them, not spend all preparation time memorizing every sentence. The combined exam does not eliminate the need to understand the different expectations of Foundation knowledge and Practitioner judgment.
Governance makes architecture more than a one-time plan
Architecture work must survive delivery pressure, budget changes, and product ownership turnover. Governance identifies decision rights, compliance expectations, exceptions, and mechanisms for reviewing implementations against approved direction. A reference architecture may specify identity boundaries or service integration patterns, but a team still needs an accountable process for deciding whether an exception is justified and what compensating controls apply.
An architecture review that happens after a product is released may be too late to influence its data contracts or dependency structure. On the other hand, a board that must approve every minor interface adjustment can become a bottleneck that teams bypass. Effective governance defines which decisions are consequential, where delegated authority is appropriate, how deviation is documented, and when the risk requires escalation.
A practical exercise tracks one approved decision through implementation. Suppose the architecture requires audited access to sensitive customer records. The delivery team uses an integration account with broad privileges for convenience. The review should identify why the shortcut violates the design, what evidence would support a narrower identity model, and whether a temporary exception can be bounded by time and risk. Recording the exception without addressing it is not the same as governance.
ArchiMate expresses relationships without becoming the business itself
ArchiMate provides standardized notation for business, application, and technology elements and their relationships. It supports communication about which application serves which business process, where a data object moves, which technical service supports an application, and how a proposed change affects the system. A model can help identify dependencies obscured by separate team diagrams.
The Open Group's ArchiMate 3 program includes Foundation and Practitioner qualifications tied to the current program's specification. Foundation concerns understanding the language and notation; Practitioner assesses application to realistic modeling situations. Tool certification is a separate program for software implementing the specification; an individual earning an ArchiMate credential does not automatically certify the modeling tool used by their employer.
A useful model should communicate the necessary question, not maximize the number of shapes. To explain the impact of retiring a legacy customer database, it may be enough to show the owning business capability, consuming applications, relevant integration services, and the deployment systems affected.
A diagram with hundreds of unlabeled dependencies can technically use valid notation while failing as an architectural communication device.
Change roadmaps must manage intermediate states and risk
An architecture target does not deliver itself. A migration may require temporary duplication, data synchronization, training, and retiring old integrations in stages. These transition architectures should explain why an interim state exists and when it can be removed. Without explicit transition rules, temporary adapters and broad access exceptions can become permanent, increasing complexity and risk instead of reducing it.
A transition plan should identify measurable gates: verified data reconciliation, successful controlled failover, user acceptance of a changed workflow, or evidence that a dependent legacy consumer no longer uses an interface. Business timing matters. Replacing a reporting system at year-end close or during a regulated submission window may be more dangerous than postponing deployment, even when the technical implementation is ready.
Architecture decisions also have human consequences. Teams may disagree over ownership of shared services or fear losing autonomy. A practitioner needs to document those conflicts, distinguish legitimate local needs from incompatible standards, and provide options rather than declare that the framework itself has authority. The value of enterprise architecture comes from informed decisions made by accountable people.
Choose qualifications to match actual architecture responsibilities
Candidates new to enterprise architecture can start with TOGAF Foundation concepts, then move toward Practitioner when they have experience translating goals into decisions under uncertainty. Professionals who create many architecture diagrams may benefit from ArchiMate, but should not mistake diagram fluency for strategic architecture capability. Experienced practitioners may need both: a method for deciding what architecture work to perform and a language for communicating the resulting relationships.
Preparation is strongest when it uses a familiar organization, a real transformation objective, and a bounded architectural problem. Identify stakeholders, describe the baseline, define target capabilities, explain gaps and transition risks, then present a design decision with a reasoned exception policy. Revisit the same decision after a hypothetical regulatory change or service failure. If the architecture cannot adapt without starting from scratch, its assumptions may be too implicit.
Official TOGAF and ArchiMate exam catalogs remain the authority for qualification versions, combination routes, prerequisites, and any renewal rules. Neither OGEA-101 nor OGEA-103 represents the full TOGAF and ArchiMate qualification portfolio. Candidates should also understand the Part 2 and bridge routes, even if those editions are not covered by their chosen study materials. The enduring skill is to connect architecture evidence to decisions that stakeholders can understand, challenge, approve, and execute.
