ArchiMate defines a fixed set of relationship types (serving, realization, assignment, access, triggering, flow, among others) with precise semantics rather than letting modelers draw generic arrows. Explain the difference between 'serving' and 'realization', and give an example of when using the wrong one would mislead a reader.

## A fixed palette, not free-text arrows ArchiMate deliberately restricts modelers to a fixed palette of relationship types, each with formally defined semantics, rather than allowing free-text or generic arrows the way informal box-and-line diagrams do. This is one of the language's core design bets: a small, well-defined relationship vocabulary is what turns a picture into a model that software can query and reason about. The relationships fall into a few families: | Family | The relationship types in it | |---|---| | structural | composition, aggregation, assignment, realization | | dependency | serving, access, influence | | dynamic | triggering, flow | | other | specialization, association, junction | Mixing them up is the most common source of models that look right to a human but return wrong answers to automated queries. ## Realization — the concrete version of an abstraction **Realization** models a strong 'implements the abstraction of' relationship: element A realizes element B when A is a more concrete manifestation of the same underlying thing B represents more abstractly. The canonical example is a service realized by the internal behavior or structure that provides it: - an **Application Component** realizes an **Application Service** (the component is the concrete software; the service is what it exposes to the outside) - a **Business Process** realizes a **Business Service** (the internal steps are the concrete work; the service is the value delivered externally) Realization is also used between a data object and the business object it represents. The defining test for realization: can you say 'A is how B actually gets done' or 'A is the concrete version of abstract B'? If yes, it's realization. ## Serving — support for a separate goal **Serving** models a different kind of link: element A serves element B when A makes itself available to, or provides functionality that supports, B's separate goals - crucially, A and B are not two levels of abstraction of the same thing, they are genuinely different elements where one helps the other. A payment-processing application service serves the checkout business process (the service supports the process's goal, but the service is not 'the same thing, more concretely' as the process). One business process can serve another (e.g. an 'Identity Verification' process serving an 'Account Opening' process). The defining test for serving: can you say 'A provides support/value that B relies on to do its own separate job'? If yes, it's serving, not realization. ## Why the distinction matters The practical distinction matters because these two relationships answer different architectural questions and tooling treats them differently: - if you ask a model 'what implements this service' (relevant to deciding what to test or redeploy during a service change), the tool walks realization relationships - if you ask 'what does this process depend on to function' (relevant to impact analysis when planning an outage), the tool walks serving relationships Confusing them makes the model return incomplete or wrong answers to whichever query type actually matters for a given decision, because the tool is querying by relationship semantics, not by arrow shape alone. ## The cost of that precision Why does the language bother with this much precision instead of one generic 'relates to' arrow? Because the entire value proposition of ArchiMate over informal diagramming is that a model with formally typed relationships can be validated, queried, and used to automate impact analysis, gap analysis, and consistency checking. A generic arrow can't be programmatically distinguished from any other generic arrow, so a tool can't tell 'this arrow means implementation' from 'this arrow means dependency'. The cost of this precision is a real learning curve: new ArchiMate modelers routinely misuse relationships, and unlike a syntax error in code, a semantically wrong-but-syntactically-valid relationship doesn't get flagged by tooling - it silently sits in the model looking plausible. ## Where the confusion bites A concrete failure mode in production practice: an architecture team migrating a monolith to microservices models the new services with 'serving' relationships to the business processes they support, but retroactively also draws 'serving' (instead of 'realization') from each new microservice to the application service it's meant to replace. 1. When leadership later runs a 'what implements our checkout service' query to plan a phased cutover, the query - correctly walking realization relationships - returns only the old monolith, because the new microservices were never actually marked as realizing anything. 2. The migration plan built on that query is wrong. 3. The team only discovers the gap when the old monolith is decommissioned and the checkout service technically has no realizer left in the model. ## Getting it right A real-world usage that gets this right: a telco modeling its OSS/BSS layer marks every microservice with a `realization` arrow to the exact application service it provides, and `serving` arrows to every business process that consumes that service, letting architects run automated 'what realizes X' and 'what depends on X' queries side by side to plan safe decommissions without manual spreadsheet cross-referencing.