ArchiMate 3 Practitioner common mistakes
ArchiMate 3 Practitioner · Understand the traps and how to avoid them.
Treating ArchiMate as a diagram notation and choosing element types by which icon looks right on the canvas, rather than by what the element means in the architecture.
Candidates come from Visio or UML backgrounds where the picture is primary; ArchiMate is a semantic language, and the same symbol can only be used for one meaning, so visual habit leads to systematically wrong element choices.
What to do instead
Before placing any element, state its definition in one sentence ('this is a behaviour performed by a role' vs 'this is a structural element that executes behaviour') and only then pick the concept; practise by classifying a list of plain-English statements into element types with no diagram at all.
Confusing the core layers and assigning an element to the wrong layer - e.g. modelling a business process as an Application-layer service, or putting an infrastructure node in the Technology layer when the intent was a physical device.
Layers are defined by the kind of entity, not by the project or team that owns it, and many real-world items (a payment 'service', a 'platform') can legitimately appear in more than one layer depending on abstraction, so candidates default to the vocabulary of their own job role.
What to do instead
Learn the layer test questions: is it performed by a person or organisational unit (Business), does it represent software behaviour or data (Application), does it represent infrastructure or physical equipment (Technology)? Re-classify a set of ambiguous terms and justify each choice against the layer definition.
Using a composition or aggregation relationship where a realization, serving, or assignment relationship is meant - for example drawing an application component composed of the business process it supports.
Structural relationships feel intuitive and visually tidy, and candidates conflate 'is part of' with 'is responsible for' or 'supports'; the relationship set is large and the distinctions are subtle.
What to do instead
Memorise the relationship decision order (structure first: composition/aggregation/realization; then dependency: serving/access/assignment/influence/triggering/flow) and, for every relationship drawn, write the sentence it encodes aloud ('component A is assigned to behaviour B') to check it reads correctly.
Mixing abstraction levels within a single view - placing a business actor next to a database table, or a capability next to a technology node - and then trying to connect them directly.
Candidates model everything they know in one canvas because the tool allows it, without deciding the view's purpose and audience first; cross-layer links then become forced and meaningless.
What to do instead
Write the view's purpose and primary stakeholder in one line before starting, choose the abstraction level that serves it, and push detail into a separate view linked by a derived relationship; if two elements are more than one layer apart, question whether the connection belongs in this view.
Drawing cross-layer relationships in the wrong direction - e.g. a business service realizing an application component, or a technology node serving an application component instead of the component being assigned to the node.
English lets you say 'the service is supported by the application' in either order, and the arrow direction is easy to reverse when reading a diagram left-to-right by business-first convention.
What to do instead
Anchor on the canonical direction of realization and serving (the more concrete/lower layer realizes or serves the more abstract/upper layer) and re-read every arrow as a full sentence with subject and object; practise by correcting deliberately reversed diagrams.
Treating the motivation and strategy elements as decoration - omitting drivers, goals, and requirements from a view, or attaching them arbitrarily to any element rather than to the element they actually motivate or constrain.
Candidates focus on the 'boxes and lines' core and treat motivation as optional annotation, and the exam's stakeholder-communication items reward knowing which motivation element justifies which structural element.
What to do instead
Learn the motivation chain (stakeholder → driver → assessment → goal → outcome → requirement → constraint) and the strategy elements (capability, resource, course of action, value stream), then for each view ask 'what justifies this element being here?' and attach the corresponding motivation element explicitly.
Performing derivation as a redraw: creating a target model that is not traceable to the source, adding elements with no source counterpart, or silently dropping elements without recording why.
Candidates treat transformation as a fresh modelling exercise, and the exam tests whether they understand derivation as a constrained, traceable mapping with explicit rules rather than free creation.
What to do instead
For every target element, be able to name its source element(s) and the transformation rule applied; record deliberate omissions and additions as explicit decisions with rationale, and check the target against the source for completeness before declaring the derivation done.
Assuming derivation preserves everything - expecting a derived view to carry the same relationships, attributes, or level of detail as the source, and being unable to say what is legitimately lost.
Candidates conflate 'derived from' with 'copy of', but derivation changes abstraction, purpose, or notation, so some information is intentionally abstracted away; the exam probes whether the candidate can distinguish intended abstraction from error.
What to do instead
Before deriving, state the target's purpose and the abstraction rule (e.g. 'only elements realizing a requirement are carried forward'); afterwards, list what was intentionally abstracted and confirm each loss is consistent with the rule rather than accidental.
Producing a view that is technically valid ArchiMate but unusable by its audience - full element and relationship detail shown to executives, or a conceptual sketch shown to implementers who need specifics.
Candidates optimise for completeness and correctness of the model rather than for the stakeholder's decision, and they do not ask who will read the view or what question it must answer.
What to do instead
For each view, record the stakeholder, their concern, and the decision it supports; then select viewpoint, abstraction, and notation accordingly (capability/value views for executives, detailed structural views for architects and implementers) and remove any element that does not serve that concern.
Using ArchiMate's own terminology with business stakeholders in a view - labelling boxes 'Business Actor', 'Application Component', 'Serving Relationship' - or omitting a legend and reading guide.
Candidates learn the metamodel and then expose it, forgetting that the language is a modelling formalism, not a communication vocabulary for non-architects.
What to do instead
Rename elements in domain language while keeping the underlying type correct, and always supply a short legend plus a one-paragraph reading guide stating the view's purpose, scope, and the meaning of each colour and arrow; test the view on a non-architect colleague before finalising.