ArchiMate Modeling Techniques and Cross-Layer Relationships
Cross-layer links
Most practitioner questions test how layers connect. Key cross-layer relationships: serving (a lower-layer service serves a higher-layer behavior), realization (application service realizes business service), assignment (application component assigned to application function), and access (behavior reads/writes a data or business object). Remember the direction: the lower layer serves the higher layer, so the serving relationship points upward toward the consumer.
Derived and derived-from
Derived relationships are computed by the language from other relationships - for example, a serving relationship implied by realization plus use. Questions often ask whether a derived relationship must be modeled explicitly; the answer is no, it is inferred and typically shown with a dashed or annotated convention.
Views and viewpoints
A view is a model excerpt; a viewpoint is the convention governing it. Standard viewpoints include organization, business process cooperation, application cooperation, technology, layered, and service realization. Choose the viewpoint from the stakeholder's concern, not from the elements you happen to have drawn.
Traps
- Drawing a business actor serving an application component instead of the application service serving the business behavior.
- Modeling a data object as assigned to a component rather than accessed by behavior.
- Assuming every cross-layer hop needs an explicit relationship when derivation covers it.
- Confusing application cooperation (components and their interactions) with application usage (how applications support business).
Worked rule
To connect a business process to a database: process → access → data object; application component → realizes → application service; application service → serves → business process; node → hosts → artifact. If a question offers a direct process-to-node link, it is almost always wrong.