ArchiMate Model Derivation and Transformation
What derivation means
Derivation produces a new model or view from an existing one by applying rules - filtering, abstraction, or relationship inference. Practitioners must distinguish model transformation (structural change, e.g., specialization to generalization) from view derivation (same model, different projection). A derived view must remain traceable to the source elements.
Common derivation patterns
- Aggregation/roll-up: collapse detailed processes into a higher-level business function for an executive view.
- Realization chains: follow realization and serving links to show how a capability is delivered end to end.
- Filtering by layer or concern: produce a technology-only view from a layered model.
- Gap and plateau: Implementation & Migration uses plateaus to represent states and gaps to represent differences between them.
Consistency rules
When deriving, preserve relationship semantics. If A realizes B in the source, the derived view cannot show A serving B without justification. Watch for cardinality changes - a derived aggregate may hide multiplicity that a stakeholder needs.
Traps
- Treating a plateau as a time period rather than a stable state of the architecture.
- Assuming a derived relationship overrides an explicitly modeled one; explicit wins.
- Losing traceability when abstracting detail - derived views should reference source elements.
- Confusing gap (difference between plateaus) with work package (unit of change).
Worked example
Given three business processes each realizing the same business service, a derived management view may show one business function realizing that service. The derivation is valid only if the roll-up preserves the realization semantics and the underlying processes remain traceable. If the question shows the function serving the service instead, reject it.