Relationships are the most frequently misused part of ArchiMate practice. The elements are relatively easy to learn; the relationships are where precision breaks down. ArchiMate 3.0 defines 12 relationship types, grouped into structural, dependency, dynamic, and other categories. Each has a specific meaning, specific valid source and target element types, and specific contexts where it is the right choice. The most common mistake in ArchiMate practice is using Association as a catch-all when a more precise relationship type exists — particularly for Serving (support relationships) and Realization (fulfillment relationships). The second most common mistake is confusing Triggering (causal activation) with Flow (material or information transfer). This guide covers all 12 relationship types with examples, and provides a decision framework for the choices practitioners face most often.
Key Takeaways
- ArchiMate defines 12 relationship types — not all are appropriate for every element pair
- Association is the weakest relationship — use it only when no more precise type fits
- Serving is the correct type for support relationships (the source provides functionality that the target needs)
- Realization is the correct type for fulfillment relationships (the source gives concrete form to what the target represents abstractly)
- Triggering is causal and temporal (A causes B to start); Flow is transfer (material or information moves from A to B)
- Using the wrong relationship type does not just create a semantic error — it makes the model unparseable by governance processes and AI tools
The 12 ArchiMate Relationship Types
Structural Relationships
Structural relationships describe how elements are composed, contained, or bound together.
1. Composition
What it means: The source element consists of one or more target elements. The target element cannot exist independently of the source — it is a part that belongs to the whole.
Direction: Source composes target (target is a part of source)
Examples:
- An Application Component composes Application Interfaces and Application Functions
- A Business Role composes Business Functions assigned to that role
- A Node composes System Software running on it
When to use it: When an element contains sub-elements that are intrinsic to it and cannot meaningfully exist independently. In Sparx EA, Composition is the right connector for representing the internal structure of an element — its constituent parts.
Common mistake: Using Aggregation when Composition is correct. The test: can the part exist independently of the whole? If no, use Composition. If yes, use Aggregation.
2. Aggregation
What it means: The source element aggregates the target elements — they are grouped by the source but can exist independently.
Direction: Source aggregates target (source groups target)
Examples:
- A Business Service aggregates multiple Business Processes that collectively deliver it
- An Application Package aggregates multiple Application Components
- A Capability aggregates multiple Business Functions that contribute to it
When to use it: When grouping elements that have an independent existence but are meaningfully associated as part of a whole. Aggregation is looser than Composition — the parts can exist without the whole.
3. Assignment
What it means: Links an active structure element (Actor, Role, Node) to a behaviour (Process, Function, Service) or passive structure (Artifact). It represents the allocation of responsibility or the deployment of a resource.
Direction: Active structure element is assigned to behaviour or passive structure
Examples:
- Business Actor assigned to Business Role (who holds which role)
- Business Role assigned to Business Process (who performs which process)
- Node assigned to Application Component (which infrastructure hosts which application)
When to use it: Assignment is the primary connector for linking who does it to what is done, and where it runs to what runs there. It is one of the most commonly used connectors in ArchiMate.
4. Realization
What it means: The source element gives concrete form to the more abstract specification represented by the target element. The source implements or fulfills the target.
Direction: Source realizes target (source gives concrete form to what target specifies)
Examples:
- Business Process realizes Business Service (the process is how the service is delivered)
- Application Component realizes Business Service (technology enables what the business delivers)
- Application Component realizes Capability (the application enables the organizational ability)
- Technology Service realizes Application Service (infrastructure provides the technical foundation for the app service)
When to use it: When a lower-abstraction or more concrete element fulfills the intent of a higher-abstraction element. Realization is the primary cross-layer connector that creates vertical traceability.
Common mistake: Using Association when Realization is correct. If an Application Component fulfills a Business Service, the relationship is Realization, not Association. The semantic difference matters for governance: Realization expresses fulfillment; Association merely expresses relatedness.
Dependency Relationships
Dependency relationships describe how elements use, support, or influence each other.
5. Serving
What it means: The source element provides functionality that the target element requires — the source supports the target. This is the primary support relationship in ArchiMate.
Direction: Source serves target (source supports target)
Examples:
- Application Service serves Business Process (the application supports the business operation)
- Application Component serves Application Component (one system supports another — a dependency)
- Technology Service serves Application Component (infrastructure supports the application)
- Business Service serves another Business Role (cross-unit support)
When to use it: When one element provides a service or functionality that another element depends on. Serving is the correct relationship for integration dependencies, service consumption, and support relationships.
Common mistake: Using Association when Serving is correct. If System A is called by System B to perform a function, that is a Serving relationship (A serves B), not an Association. This distinction is critical for dependency analysis — Association does not carry the directionality of support that Serving provides.
6. Access
What it means: An active element accesses a passive element — the source reads, writes, or uses the target (a passive structure element like a Data Object, Business Object, or Artifact).
Direction: Active element accesses passive element
Access modes:
- Read: Source reads the passive element (no modification)
- Write: Source creates or modifies the passive element
- Read/Write: Source both reads and modifies
Examples:
- Business Process accesses Business Object (the process uses or creates the data)
- Application Function accesses Data Object (the application reads or writes the data)
- Technology Process accesses Artifact (the deployment process produces or uses the artifact)
When to use it: Whenever a behaviour or active structure element interacts with a passive structure element. Access is required to model data flows accurately — which processes create which data, which processes read which data.
7. Influence
What it means: The source element has an effect on the behavior or implementation of the target element, but does not fully determine it.
Direction: Source influences target
Examples:
- Driver influences Assessment (the external force shapes but does not determine the analysis)
- Goal influences Capability (the strategic goal shapes but does not mandate specific capability development)
- Principle influences Architecture Decision Record (principles guide but do not prescribe specific decisions)
When to use it: For motivation layer connections — when one element shapes or constrains another without fully determining it. Also useful in risk architecture where risks influence but do not mechanistically cause problems.
8. Association
What it means: The most generic relationship in ArchiMate — expresses an unspecified relationship between elements. Association has no prescribed meaning beyond “there is a relationship.”
Direction: Can be directed or undirected
When to use it: Only when none of the more specific relationship types applies. Association should be the relationship of last resort, not the default choice.
The key discipline: Before drawing an Association connector, ask which more specific type is actually appropriate. In most cases, one of Serving, Realization, Access, or Influence is more semantically precise.
Dynamic Relationships
Dynamic relationships describe the flow of behavior and information over time.
9. Triggering
What it means: The source element causes the target element to begin. Triggering is a causal, temporal relationship — the source event or process activates the target.
Direction: Source triggers target (source causes target to start)
Examples:
- Business Event triggers Business Process (“Order Received” triggers “Order Fulfillment Process”)
- Business Process triggers Application Process (“Loan Approval” triggers “Disbursement Process”)
- Technology Event triggers Technology Process (“Backup Schedule Event” triggers “Backup Process”)
When to use it: When the source element causes the target to begin execution — causal activation.
Critical distinction from Flow: Triggering is about causation — A starts B. Flow is about transfer — something moves from A to B. If a process step causes the next step to begin, use Triggering. If information or material moves from one element to another, use Flow.
10. Flow
What it means: Transfer of information, goods, money, or material from one element to another. Flow is about what moves, not about causation.
Direction: Source flows to target (something moves from source to target)
Examples:
- Business Process flows Business Object to another Business Process (information passes between process steps)
- Application Component flows Data Object to another Application Component (data is transferred between systems)
- Distribution Network flows Material to Equipment (physical goods move through the supply chain)
When to use it: When the primary concern is what is transferred between elements — information flows, data exchanges, material movements. Flow is the correct choice for data flow diagrams, message passing architectures, and supply chain models.
Common mistake: Using Triggering when Flow is correct. If the point is that data passes from Step A to Step B, use Flow. If the point is that Step A causes Step B to begin, use Triggering. In a business process with both causal and data-transfer semantics, both connectors may be appropriate.
Other Relationship Types
11. Specialisation
What it means: The source element is a more specific version of the target element. Specialisation is the ArchiMate equivalent of generalization/inheritance.
Direction: Source specialises target (source is a specific type of target)
Examples:
- “Retail Loan Product” specialises “Loan Product”
- “Mobile Application Component” specialises “Application Component” (in a custom stereotype hierarchy)
- “Emergency Response Process” specialises “Business Process”
When to use it: For taxonomy and classification modeling — when you need to represent type hierarchies in your architecture. Used in custom MDG profile design and in domain-specific metamodel extensions.
12. Junction
What it means: A Junction is not a relationship per se — it is a connector that allows multiple relationships to split or merge into a single connection. ArchiMate provides AND Junction (all relationships active simultaneously) and OR Junction (at least one is active).
When to use it: In dynamic behavior models where processes or events need to be combined (AND: all must complete before proceeding) or split (OR: any one can proceed). Junctions clean up complex dynamic diagrams where multiple triggering or flow relationships converge or diverge.
Decision Framework: Which Relationship Type for This Situation?
The following decision tree covers the most common choices practitioners face:
Is this about what is transferred (information, data, material)? → Use Flow
Is this about one element causing another to start? → Use Triggering
Is this about an active element using a passive element (reading, writing data)? → Use Access (with direction: read, write, or read/write)
Is this about one element fulfilling or implementing what another specifies? → Use Realization (concrete element realizes abstract specification)
Is this about one element supporting another — providing functionality another needs? → Use Serving (source provides to target)
Is this about role/resource allocation or deployment (who does it, where it runs)? → Use Assignment
Is this about ownership (the target is a part of the source)? → Can the part exist independently? If no: Composition. If yes: Aggregation
Is this about one thing being a specific type of another? → Use Specialisation
Is this about one element shaping but not determining another? → Use Influence
None of the above apply? → Use Association — but reconsider whether one of the above might be more appropriate
The Most Common Mistakes
Using Association when Serving is correct. If Application Component A provides a service that Application Component B depends on, the relationship is Serving (A serves B). Using Association loses the directionality and the support semantics. Governance tools and AI queries that analyze dependencies cannot use an Association relationship — they need Serving.
Using Triggering when Flow is correct. Triggering is about causation; Flow is about transfer. In an integration architecture where data flows from System A to System B, the relationship is Flow. If System A completing causes System B to begin, that is Triggering. Often both are present — model them separately.
Reversing the direction of Serving. Serving goes from the supporting element to the supported element: the source provides to the target. If Application Service X supports Business Process Y, the connector goes from Application Service X to Business Process Y. Getting this backwards inverts the dependency map, causing incorrect impact analysis.
Reversing the direction of Realization. Realization goes from the concrete element to the abstract specification: the source implements the target. Business Process realizes Business Service (not the other way around). Application Component realizes Capability. The concrete implements the abstract.
Using Access for active-to-active relationships. Access is specifically for active structure or behaviour accessing passive structure (Data Objects, Business Objects, Artifacts). An Application Component accessing a Data Object is an Access relationship. An Application Component providing functionality to another Application Component is a Serving relationship, not an Access relationship.
FAQ
What is the difference between Serving and Association in ArchiMate? Serving is a directed support relationship — the source element provides functionality that the target element requires. Association is an undirected or weakly directed generic relationship expressing mere relatedness. When one element provides a service or capability that another depends on, use Serving. Association is the relationship of last resort — use it only when no more specific type applies. Using Association where Serving is correct loses the support directionality and breaks dependency analysis.
What is the difference between Triggering and Flow in ArchiMate? Triggering is causal — the source element causes the target element to begin. Flow is a transfer — information, data, or material moves from the source to the target. These are distinct phenomena. An event triggering a process is Triggering. Data passing between process steps is Flow. In process modeling, both often coexist: one process step triggers the next (Triggering) and passes data to it (Flow).
Which way does the Realization connector point in ArchiMate? Realization points from the concrete fulfilling element to the abstract specified element. The concrete realizes the abstract. Business Process realizes Business Service. Application Component realizes Capability. The arrow points in the direction: “this concrete thing fulfills what that abstract thing specifies.” The common mistake is reversing this direction.
Which way does the Serving connector point in ArchiMate? Serving points from the supporting element to the supported element. The source provides to the target. Application Service serves Business Process (the application supports the business operation). Technology Service serves Application Component (infrastructure supports the application). The arrow points from the provider to the consumer. Think of it as “the source serves the target.”
What is the Composition connector used for in ArchiMate? Composition represents containment — the source element consists of target elements that cannot independently exist. Use Composition for the internal structure of an element: an Application Component composes its Application Interfaces; a Business Service composes its constituent Business Processes. The test: if the whole is removed, can the part still exist? If no, use Composition. If yes, use Aggregation.
How do I model data access in ArchiMate? Use the Access connector, from an active element (Application Function, Business Process, Application Component) to a passive element (Data Object, Business Object). Specify the access mode: read (the active element retrieves the passive element), write (the active element creates or modifies it), or read/write. Access connectors make data flow patterns explicit and enable data governance analysis — which systems create which data, which systems read it.
When should I use Association in ArchiMate? Use Association when none of the more specific relationship types accurately describes the connection. In the motivation layer, Association is appropriate for expressing relatedness between Drivers, Goals, and Stakeholders when the relationship is meaningful but does not constitute Serving, Realization, or Influence. In general practice: if you are defaulting to Association because it is the easiest connector to draw, stop and consider whether Serving, Realization, or Access better describes the actual relationship.
Does using the wrong relationship type matter if the diagram still looks right? Yes, significantly. The diagram may look the same to a human reader regardless of connector type. But the semantic model is different. Governance tools that query the repository for dependencies, AI tools that traverse relationships via EA GraphLink, and reporting frameworks that analyze architecture quality all operate on the typed relationship data — not the visual appearance. A Serving connector carries support-direction semantics. An Association carries none. Using the wrong type makes the model unsearchable and unanalyzable at scale.
Build ArchiMate Practice That Gets the Details Right
Relationship type discipline is the difference between an ArchiMate model that is architecturally useful and one that is visually presentable but analytically empty. The practitioners who get this right have usually been through a structured review process that catches the common mistakes early and builds the habit.
Sparx Services’ Amplify program includes ArchiMate relationship governance as a core component — working with your EA team to review existing models, establish relationship discipline standards, and build the MDG configuration that helps practitioners make the right choices at diagram creation time.
