ArchiMate 3 Foundation common mistakes
ArchiMate 3 Foundation · Understand the traps and how to avoid them.
Classifying a concept by what it represents in the business rather than by which ArchiMate layer/aspect it belongs to (e.g., labelling a business service as a technology service because it is delivered by IT).
Candidates reason from real-world IT intuition instead of the metamodel's layer definitions, and the exam deliberately uses cross-layer service examples to test this.
What to do instead
For every element, ask two questions in order: which layer does the model owner consider this behaviour to belong to (Business/Application/Technology), and is it structural or behavioural? Classify from the metamodel definition, not from who operates it.
Treating an ArchiMate relationship as a generic 'association' when the question hinges on a specific relationship type, or using a relationship the metamodel does not permit between two element types.
Candidates memorize element names but not the relationship table, so they default to the weakest relationship or pick one that reads naturally in English.
What to do instead
Learn the permitted relationship matrix by element pair. Practise deriving relationships: 'serves/realizes' for behaviour-to-behaviour, 'assignment' for active structure to behaviour, 'realization' for behaviour to capability/requirement, 'composition/aggregation' for whole-part. Reject options that violate the matrix even if they sound plausible.
Confusing similar-looking concepts, particularly business service vs. business function vs. business process, or application component vs. application service, and picking the option that matches the everyday meaning of the word.
The exam uses near-synonyms whose ArchiMate definitions differ subtly (external-facing behaviour vs. internal behaviour vs. grouping of behaviour), and candidates rely on general English usage.
What to do instead
Build a contrast table of confusable pairs with the single distinguishing criterion (e.g., service = externally visible behaviour exposed via an interface; function = internal behaviour grouped by required resources; process = behaviour sequenced to produce a defined outcome). Answer by matching the criterion, not the label.
Misreading a question that asks what an element may be connected to or what it may contain, and answering with what it is typically connected to in practice.
Candidates answer from modelling habit and common patterns instead of the metamodel's allowed structural rules.
What to do instead
Underline the modal words in the stem ('may', 'must', 'can be composed of', 'is a specialization of'). If the question is about permission, verify against the metamodel rather than typical practice; if about practice, check the stem does not say 'per the metamodel'.
Mixing up the layers of the framework when placing motivation, strategy, implementation and migration, or physical elements, e.g., placing a capability in the business layer or a deliverable in the implementation layer's behaviour.
Candidates learn the three core layers well but treat the supplementary layers as afterthoughts and guess their boundaries.
What to do instead
Memorize the full layer/aspect grid including Motivation, Strategy, Implementation & Migration, and Physical, and for each note its characteristic element types and what it is used for. Drill placement questions specifically for the supplementary layers.
Using composition and aggregation interchangeably, or using them where a different relationship (realization, serving, access) is required, when the question tests whole-part semantics.
Both are structural whole-part relationships and candidates do not recall that composition implies strong ownership with parts existing only as part of the whole, while aggregation permits parts to exist independently.
What to do instead
Apply a single test: if the part can exist without the whole and be shared, use aggregation; if it is existentially dependent on the whole, use composition. Then check that the relationship is structural at all before choosing between them.
Selecting a viewpoint by its name or by what looks visually familiar rather than by the stakeholder concern the question describes.
Candidates memorize viewpoint names without their intended audience and purpose, and the exam frames viewpoint questions as stakeholder concerns.
What to do instead
Learn each viewpoint as a triple: audience, concern, and the layer/aspect coverage it implies. Practise mapping a stated concern (e.g., impact of change, service realization, application usage) to the viewpoint whose purpose matches, ignoring the name's surface appeal.
Producing or judging a view that is technically valid but does not answer the stated stakeholder question, or omitting the elements needed to make the view meaningful (e.g., showing a service with no realizing behaviour).
Candidates focus on syntactic correctness and element counts rather than on the communicative purpose of the view.
What to do instead
Before evaluating a view, restate the stakeholder's question in one sentence and check that the view contains the elements needed to answer it (the concern, the relevant layer, and the realizing/serving chain). Treat irrelevant detail as a defect, not a bonus.
Assuming ArchiMate is a method or a process for doing architecture, or that a single model must be complete and fully detailed for all purposes.
Candidates conflate the language with architecture frameworks and methods, and carry over a 'complete model' mindset from other disciplines.
What to do instead
Anchor the distinction: ArchiMate is a modelling language with a metamodel and viewpoints, not a method or framework, and it is designed to be used selectively per purpose. For application questions, choose answers that treat models as purpose-driven and language-agnostic about process.
Ignoring specialization and abstraction when interpreting a model, treating every element as concrete and failing to recognize that a specialized element inherits the properties and relationships of its generalization.
Candidates read diagrams literally and do not apply the specialization relationship's inheritance semantics, so they miss valid implied relationships or wrongly mark a model inconsistent.
What to do instead
When a model shows specialization, propagate the parent's allowed relationships to the child before judging validity. Conversely, do not invent inheritance where no specialization is shown. Practise questions where the correct answer depends on an inherited relationship.