ArchiMate 3 Practitioner cheat sheet

Three structural layers (Business, Application, Technology) sit below a Strategy layer and above a Physical layer; Implementation & Migration and Motivation are cross-cutting aspects.

Each element has exactly one layer and one aspect: active structure (who), behavior (what), passive structure (what is acted on), and motivation.

Generic relationship set is fixed: composition, aggregation, assignment, realization, serving, access, influence, triggering, flow, specialization, association, junction, grouping.

Derivation rule: assignment connects an active structure to behavior or an active structure it performs; realization connects a concrete element to the more abstract element it realizes.

Serving is the weakest dependency (one element provides functionality to another); access covers read, write, read-write on passive structure; influence carries a +/- sign on motivation elements.

Composition implies exclusive ownership and a single parent per part; aggregation permits sharing and is used for grouping parts that outlive the whole.

Specialization is the only relationship that may connect elements of the same kind across layers and is the basis for type-level abstraction; association is undirected and used when no stronger semantic fits.

Junction elements (AND/OR) are required only where a relationship splits into multiple paths; a single incoming-to-multiple-outgoing split without a junction is an OR split by default.

A model must be internally consistent: every relationship must be permitted by the metamodel table; forbidden pairs (e.g., behavior composed of active structure) indicate a modeling error.

Cross-layer service orientation: a business service is realized by business process/function, which is served by application services, which are realized by application components, which are assigned to technology nodes.

A business process may be served by an application service; the application service is realized by an application component; the component is assigned to a technology node - this chain is the canonical vertical trace.

Business actors and roles are assigned to business services or processes; application components are assigned to application services; technology nodes are assigned to system software or infrastructure services.

Data object (business) may be realized by data object (application), which is realized by artifact (technology); access relationships attach behavior to the passive element it reads or writes.

Use a business interface to expose a service provided by a business role/actor; use an application interface to expose an application service; interfaces are access points, not behavior.

When modeling a process flow, use triggering between events and processes, flow between behaviors for value/message transfer, and access for data used; do not substitute association for these.

Grouping is a container with no semantics of its own and may span layers; use it to demarcate domains or boundaries, never to imply composition.

Capability (strategy layer) is realized by courses of action, which are realized by business processes/functions; a capability may also be realized directly by a business service for coarse-grained models.

Derivation direction: a more concrete model element realizes a more abstract one; the abstract element is the derived (target) view, the concrete element the source.

Viewpoint derivation rule: a view is a selection of a model; a viewpoint defines the selection criteria (elements, relationships, and allowed abstractions) used to produce that view.

Transformation pattern: aggregate detailed application components into a logical application component via composition, then realize the logical component by the detailed ones via realization.

Transformation pattern: collapse a business process into a business function when moving from process-level to capability-level views; the function realizes the capability.

When deriving an application view from a business view, keep serving relationships intact but replace business actors with application components assigned to the corresponding application services.

Plateau/state modeling uses implementation & migration elements: a plateau is a stable state; a gap is a missing element; work package delivers a deliverable that realizes a plateau.

Consistency check across derived views: every relationship in the derived view must trace to at least one relationship in the source model, or be explicitly justified as a new abstraction.

Specialization and realization are the two derivation mechanisms; composition/aggregation are structural decomposition, not derivation, and must not be used to replace realization.

Viewpoint selection is driven by stakeholder concern: e.g., management cares about capability and value, architects about cross-layer traceability, operations about technology and application usage.

A view must be readable by its stakeholder: limit elements per view, hide irrelevant layers, and use the viewpoint's allowed element set rather than the full language.

Layered viewpoint shows services per layer and their dependencies; it communicates cross-layer coherence but not internal process detail.

Application usage viewpoint shows how applications support business processes; it is the standard view for business-IT alignment discussions.

Implementation and migration viewpoint communicates plateaus, gaps, and work packages to program managers; it should not include motivation elements unless a goal-driven roadmap is required.

Motivation elements (goal, requirement, constraint, driver, assessment) are used to justify model choices in stakeholder reviews; they influence not structure, so they attach via influence or realization.

A model is a communication artifact: label relationships explicitly (serving, realization) so non-architect stakeholders can read intent without metamodel knowledge.

Traceability matrix derived from realization and serving relationships is the evidence base for impact analysis when a stakeholder requests change assessment.