OGA-032 ArchiMate 3 Part 2: Practitioner Scenario Reasoning and Model Application

OGA-032 is the ArchiMate 3 Part 2 examination for the ArchiMate 3 Practitioner certification. It is the applied level of The Open Group’s current ArchiMate program and is aligned to the ArchiMate Specification, Version 3.2. The exam contains eight complex scenario questions, allows 90 minutes, is open book, and uses gradient scoring. The best answer earns five points, the next best three, the third one, and the weakest answer zero; the passing score is 26 points out of 40, or 65 percent.

The exam assumes the foundational language knowledge represented by OGA-031. Practitioner candidates must do more than recognize elements and relationships: they need to apply the language to realistic architecture situations, interpret models, select appropriate concepts, and reason about how different parts of the language work together. That difference changes how preparation should be organized.

Open-book access is useful, but it does not remove the need for fluency. A candidate has roughly eleven minutes per scenario on average, including reading, comparing four plausible answers, and consulting the reference when necessary. The most effective preparation combines model-building practice, disciplined scenario analysis, and fast navigation of the ArchiMate 3.2 Specification.

Practitioner questions reward the best architectural choice, not a merely possible one

Gradient scoring exists because scenario options can differ in quality rather than simply being true or false. Two responses might use valid ArchiMate concepts, yet one may represent the stakeholder concern more directly, preserve clearer semantics, or use relationships that fit the scenario better. Candidates should therefore ask which choice is most precise and useful under the stated conditions.

When reviewing practice scenarios, do not stop after finding a defensible answer. Rank all four options and explain the weaknesses of the alternatives. One may mix layers improperly, another may use an element at the wrong abstraction, and another may be technically possible but communicate the concern poorly. This comparative process mirrors the exam’s scoring model and trains the judgment the Practitioner level is intended to validate.

Cross-layer reasoning is central to useful architecture models

Real enterprise questions cross organizational and technical boundaries. A business capability may depend on business processes and services, which rely on application services, components, data objects, and technology services. A Practitioner should be able to trace that chain without collapsing distinct concepts into one generic dependency.

Practice by taking a business outcome and following it through several layers. Identify the business behavior that produces value, the application behavior that supports it, and the technology that enables execution. Then inspect whether each relationship expresses the intended dependency. Cross-layer work exposes semantic errors that are easy to miss when each layer is studied separately.

Relationships must be chosen for meaning rather than visual convenience

At Practitioner level, a line on a diagram is not enough. Assignment, realization, serving, access, triggering, flow, composition, aggregation, specialization, and influence express different architectural statements. Selecting the wrong relationship can change the meaning of the model even if the connected elements themselves are correct.

A useful exercise is to redraw a small model several times with different candidate relationships and describe how the meaning changes. Ask whether behavior is being performed, exposed, realized, triggered, or merely associated. The goal is to make relationship semantics automatic enough that scenario analysis can focus on the architecture problem instead of basic notation recall.

Viewpoint selection is an exercise in stakeholder communication

Practitioner work requires deciding not only what is true about the architecture but what a particular audience needs to see. A view for executives can emphasize motivation, outcomes, capabilities, and high-level dependencies, while a view for application architects may expose services, components, interfaces, and data movement. Both can be derived from the same underlying model.

Scenario questions often become clearer when the candidate identifies the stakeholder before examining the notation. Ask what concern must be answered, what level of detail is appropriate, and which elements would distract from the decision. This prevents over-modeling and reflects the practical purpose of viewpoints: using one architecture model to support multiple conversations without losing semantic consistency.

Customization mechanisms should be used deliberately

ArchiMate provides mechanisms for specialization and other forms of tailoring so organizations can adapt the language to specific domains while preserving recognizable semantics. Practitioner candidates should understand when customization clarifies a model and when it creates unnecessary local notation that weakens shared understanding.

In practice, the safest approach is to use standard concepts whenever they adequately express the architecture and customize only when a real modeling need exists. A scenario that introduces domain-specific roles, resources, or technology may invite specialization, but the resulting model should still make the underlying ArchiMate meaning visible. Customization should extend communication, not replace the common language with organization-specific shorthand.

The open book is a precision tool, not a substitute for preparation

The ArchiMate 3.2 Specification is available through the exam interface, which is valuable when a scenario turns on an exact definition, relationship rule, or specialized concept. However, repeatedly searching broad terms can consume the limited time. Candidates should know the structure of the specification well enough to navigate directly to the relevant part.

Build a reference habit during study. When a practice question is uncertain, first state what you think the rule is, then locate the authoritative section, and finally record the wording difference that changed your answer. Over time, frequently consulted areas become familiar and the reference shifts from primary memory to verification. That is the same way architecture professionals use standards in real work.

Gradient scoring changes time and risk decisions

Because the best, second-best, and third-best answers receive different credit, a difficult question should not trigger panic if two options remain plausible. The candidate’s task is to identify the stronger choice, not prove that every distractor is absurd. Eliminating the weakest response, comparing the remaining options against the scenario, and selecting the one with the strongest semantic fit can still produce a good result.

Time discipline matters. Spending twenty minutes attempting to make one scenario perfectly certain can damage the rest of the exam. A better approach is to identify the scenario’s core concern, rank the options, consult the reference for the decisive rule, choose, and move on. Leave enough time to revisit genuinely close questions if the testing interface permits review.

The current path deliberately separates Foundation and Practitioner

The Open Group states that ArchiMate 3 has no combined Part 1 and Part 2 exam. Candidates must earn the required results through the separate examinations. That is different from the older ArchiMate 2 era, when a combined option such as OG0-023 existed. The distinction matters because old training material may describe a booking route that is no longer part of the current program.

For a new candidate, the clean sequence is to master the 3.2 Foundation body of knowledge, then shift into applied modeling practice for Part 2. Someone maintaining old models can still learn from ArchiMate 2 examples, but certification preparation should not mix legacy examination mechanics with the current Practitioner requirements.

Practitioner readiness is visible in the quality of model explanations

A strong candidate can look at a model and explain why its elements, relationships, and viewpoint are appropriate for the architectural question. That explanation should connect strategy and motivation to business behavior, applications, technology, and change where relevant. The model is not judged by visual complexity; it is judged by whether it communicates a coherent and semantically valid architecture story.

Before scheduling, verify the current rules through The Open Group, then test yourself with unfamiliar scenarios. If you can justify modeling choices, find exact rules quickly in the specification, and compare plausible alternatives without reverting to icon memorization, you are preparing for the applied level the exam is intended to measure.

One of the best Practitioner drills is a modeling workshop in miniature. Choose a transformation such as introducing self-service, consolidating applications, moving a workload to a new platform, or redesigning a customer journey. Identify drivers and goals, the capabilities or business behavior affected, the application services involved, the technology support, and the implementation work required. Then create two different stakeholder views from the same model. Finally, explain which relationships are essential and which are only decorative. This exercise forces strategy, core layers, motivation, viewpoints, and implementation concepts to operate together, which is much closer to Practitioner reasoning than studying each chapter separately.

ArchiMate also becomes more useful when candidates understand its relationship to architecture methods without conflating them. A method such as TOGAF can structure how architecture work is performed, while ArchiMate provides a language for expressing architecture content. A project can use both: the method guides activities and governance, while ArchiMate models communicate selected states, dependencies, motivations, and transitions. This distinction helps in scenario questions because it prevents the candidate from expecting the modeling language itself to supply project sequencing or governance decisions that belong elsewhere. The Practitioner skill is choosing the right language concepts for the architecture information that must be communicated.

Practitioner candidates should also practice detecting over-modeling. A scenario may tempt the architect to include every known system, role, motivation, and implementation detail, yet the best view may require only a small subset. Evaluate each element by asking whether it contributes to the stakeholder concern and whether its omission would change the decision. This produces clearer models and often helps distinguish the strongest exam option from an answer that is technically elaborate but poorly focused. Enterprise architecture communication is not improved by maximizing notation density; it is improved by choosing enough structure to make the relevant relationships understandable and defensible.