Choosing the Right Relationship: Assignment, Realization, or Serving?
A logistics company is documenting its warehouse automation. The modeler has produced the following statements and is unsure which ArchiMate relationship each requires:
- The 'Pick Robot' (a technology node) carries out the 'Automated Picking' technology function.
- The 'Warehouse Management System' (application component) fulfills the 'Inventory Accuracy' business service.
- The 'Order Fulfillment' business process depends on the 'Inventory Service' application service to complete.
- The 'Inventory Service' is the concrete thing that makes real the abstract 'Stock Visibility' capability.
A junior modeler wants to draw all four as plain association lines 'because the arrow direction is confusing.' The review is tomorrow and the team must produce a metamodel-correct diagram.
1. For each of the four statements, name the correct ArchiMate relationship (assignment, realization, serving, or other) and state the direction of the arrow.
Read the worked answer
Assignment. A node assigns active structure to behavior it performs. Arrow:
Pick Robot --> Automated Picking(structure to behavior). Assignment is the structure→behavior relationship; do not use 'serving' here.Realization. A component realizes a service it provides. Arrow:
WMS --> Inventory Accuracy (business service). Note the layer crossing is legitimate only because realization of a service is exactly how layers connect. (If the modeler meant the WMS uses the business service, that would be serving in the opposite direction - but 'fulfills' signals realization.)Serving. A higher-layer element is served by a lower-layer service. Arrow:
Inventory Service --> Order Fulfillment(service serves the process). The modeler's phrasing 'depends on' tempts a flow or association; serving is the correct structural dependency.Realization. A capability is realized by concrete elements. Arrow:
Inventory Service --> Stock Visibility(realizing element to realized element).
Rule of thumb to give the junior modeler: assignment = who/what performs behavior; realization = concrete makes abstract real; serving = a service is consumed by a higher-layer element. All three point from the more concrete/provider side toward the more abstract/consumer side.
2. The junior modeler argues that 'association' is safe because it is never wrong. Explain why replacing these four with associations would degrade the model even though association is a legal relationship.
Read the worked answer
Association is legal but semantically empty - it asserts only that two elements are related, not how. The four relationships each encode a distinct metamodel constraint, and collapsing them loses exactly the information the metamodel exists to carry:
- Assignment encodes the structure→behavior constraint that lets you ask 'what performs this function?' and validate that every function has a performer.
- Realization encodes the abstraction ladder (concrete→abstract) and is the only sanctioned way to cross layers via services; losing it breaks layer traceability.
- Serving encodes the consumer/provider contract and dependency direction; losing it hides impact analysis (if Inventory Service fails, which processes are affected?).
With associations, a tool cannot run consistency checks (e.g., 'behavior without an assigned structure'), cannot generate impact analysis, and cannot distinguish a provider from a consumer. Exam judgement: 'legal' ≠ 'appropriate.' The exam rewards choosing the most specific relationship that is true; association is a last resort when no typed relationship fits.