ArchiMate Relationship Types Explained with Modeling Examples

⏱ 23 min read

ArchiMate Relationship Types Explained with Modeling Examples ArchiMate training

Learn ArchiMate relationship types with clear explanations and practical modeling examples. Explore structural, dependency, dynamic, and other core relationships used in enterprise architecture diagrams. ArchiMate tutorial for enterprise architects

ArchiMate relationship types, ArchiMate relationships, ArchiMate modeling examples, ArchiMate tutorial, enterprise architecture, ArchiMate structural relationships, ArchiMate dependency relationships, ArchiMate dynamic relationships, ArchiMate notation, ArchiMate examples ArchiMate layers explained

Introduction

ArchiMate relationships are what turn an architecture diagram from a set of labeled boxes into a usable model. Business actors, application components, data objects, and technology nodes tell you what exists. Relationships tell you how those elements connect: what is part of what, who performs which behavior, which services support which processes, what data is used, what triggers an activity, and what implements an abstract concept. Without those connections, a model has limited analytical value. ArchiMate modeling best practices

In practice, relationship quality often matters more than element count. Two diagrams can contain the same elements and still communicate very different meanings depending on how those elements are linked. An application component may realize an application service, while that service serves a business process. Replace either relationship with a generic association and the model becomes less precise. That is not a cosmetic issue. It changes how stakeholders read ownership, dependency, accountability, and change impact.

This is why relationship modeling matters well beyond notation compliance. Enterprise architects use relationships to trace strategy into execution, connect business needs to digital solutions, and expose dependencies that shape planning. A capability may be enabled by a process, supported by an application service, realized by an application component, and hosted on a technology platform. Chains like that make alignment visible. They also help answer practical questions: Which applications support a critical capability? Which processes depend on a shared service? Where will a platform change ripple outward? Which data objects are read, updated, or exchanged across systems?

Relationships also help manage abstraction. The same real-world situation can be modeled differently depending on audience and purpose. An executive view may focus on high-level serving relationships between capabilities and services. A solution view may need realization, assignment, access, and flow to show implementation and operating detail. Good modeling requires judgment: enough precision to preserve meaning, but not so much detail that the view becomes difficult to read.

This article explains the main ArchiMate relationship types in a practical sequence. It starts with why relationships matter, then moves through structural, dependency, dynamic, and other core relationships, and closes with guidance on choosing the right one in common modeling situations. Throughout, the emphasis stays on relationships as a disciplined vocabulary for enterprise analysis, governance, and transformation design. ArchiMate viewpoints

1. Why Relationships Matter in ArchiMate Modeling

In ArchiMate, elements define what exists; relationships define what those elements mean in relation to one another. That distinction is fundamental to enterprise architecture because stakeholders rarely care about isolated objects. They care about support, dependency, accountability, implementation, and impact.

Relationships preserve intent. A link between an application component and a business process can mean very different things depending on whether it is modeled as serving, assignment, or realization. Those choices shape interpretation. If the semantics are wrong, the model may still look plausible while conveying the wrong design message.

They also create traceability across layers. One of ArchiMate’s practical strengths is its ability to connect strategic and operational concerns: goals, capabilities, processes, applications, data, and technology. Relationship chains make those connections explicit. A business capability, for example, may be enabled by a business process, supported by an application service, realized by an application component, and hosted on infrastructure. Each relationship contributes a different part of that story.

Relationships are equally important for impact analysis. When a system is replaced or a platform retired, the first question is rarely what the element is called. The real question is what depends on it. Relationships reveal downstream consumers, upstream providers, data usage, and operational sequencing. In large enterprises, that visibility is essential for migration planning and governance.

They also improve model discipline. Choosing between access, flow, serving, and association forces the architect to state what the connection actually means. That precision often surfaces hidden assumptions and gaps in understanding. In that sense, selecting a relationship is not just a diagramming step; it is part of the analysis.

This is where governance becomes concrete. An architecture board reviewing a new CRM platform, for example, needs more than a product name and a box on a slide. It needs to see which capabilities the platform supports, which processes it serves, which data it accesses, and what technology services it depends on. Relationship quality directly influences decision quality.

A small micro-example makes the point. Suppose a retailer wants to modernize returns processing. If the model shows only that Returns Portal is “connected” to Returns Process, little can be inferred. If the model shows that the application service Returns Validation Service serves the business process Assess Return Request, and that the application component Returns Platform realizes that service, the model becomes useful for planning, sourcing, and impact analysis.

The rest of this article follows the same principle: establish what each relationship means, then show how it supports traceability, impact analysis, and clearer communication.

2. Structural Relationships: Composition, Aggregation, Assignment, and Realization

Structural relationships describe how the architecture is put together. They show containment, grouping, responsibility, and implementation. They matter most when the model needs to support decomposition, ownership, or traceability from abstract concepts to concrete solutions.

Composition

Composition is a strong whole-part relationship. If element A is composed of element B, then B is an integral part of A in that context. The part is not merely related to the whole or grouped with it; it is a constituent of the whole.

A familiar example is a business process composed of subprocesses. Customer Onboarding may be composed of Identity Verification, Risk Screening, and Account Setup. In application architecture, a component might be composed of internal modules when those modules are treated as meaningful parts of the larger component.

Use composition when the whole-part meaning is strong and intentional. If the whole disappears, the parts usually lose meaning in that specific modeling context.

Aggregation

Aggregation is also a whole-part relationship, but it is weaker than composition. The parts can still exist independently of the whole. That makes aggregation useful for grouping related elements without claiming strict containment.

A product, for example, may aggregate multiple business services, or a business collaboration may aggregate several business roles. Those roles or services still make sense outside that particular grouping. Aggregation gives the model coherence without implying the stronger dependency that composition does.

A simple test helps: if the whole disappears, do the parts still stand on their own? If yes, aggregation is often the better fit.

Assignment

Assignment links an active structure element to behavior. It expresses responsibility, performance, or allocation. A business role assigned to a business process indicates who performs that process. An application component assigned to an application function shows that the component performs that function.

This is one of the most useful relationships in operating model and solution design because it makes accountability visible. It helps answer questions such as:

• Which role performs this process?
• Which application component executes this function?
• Where does operational responsibility sit?

In IAM modernization, for example, the business role Identity Operations Team may be assigned to the process Provision Workforce Access, while the application component Identity Governance Platform is assigned to the function Access Certification. That makes it clear who performs the work and which platform automates it.

Realization

Realization expresses implementation: one element makes another concrete. It connects a more abstract or externally visible concept to the element that delivers it.

Typical examples include:

• A business process realizing a business service
• An application component realizing an application service
• An artifact realizing a data object or specification

Realization is especially important for traceability. It allows stakeholders to move from “what is offered” to “what actually implements it.”

This is often central to architecture board decisions. A board may approve a target-state principle such as centralized authentication service, but the model still needs to show which application component realizes that service and which technology platform hosts it.

Example: Customer Onboarding

Consider a simplified onboarding model:

• The business process Customer Onboarding is composed of Identity Verification and Account Setup.
• The business role Onboarding Specialist is assigned to Customer Onboarding.
• The product Premium Account Package aggregates services such as Identity Check Service and Account Activation Service.
• The application component Customer Platform realizes the application service Digital Onboarding Service.

Taken together, these relationships show decomposition, grouping, responsibility, and implementation. In many enterprise models, that combination forms the structural backbone.

Micro-example: Finance Close Platform

A useful contrast comes from finance architecture:

• The business process Month-End Close is composed of Reconcile Accounts, Post Adjustments, and Publish Financial Statements.
• The business role Corporate Controller is assigned to Publish Financial Statements.
• The application component Finance Consolidation Platform realizes the application service Group Consolidation Service.

This kind of model is common in transformation programs because it separates process structure, role accountability, and application implementation without overloading a single relationship type.

3. Dependency Relationships: Serving, Access, and Influence

If structural relationships show how the architecture is organized, dependency relationships show how elements rely on one another. They are central to support mapping, data usage analysis, and strategic reasoning.

Serving

Serving expresses a provider-consumer relationship. If element A serves element B, then A provides functionality or value used by B.

Examples include:

• An application service serving a business process
• A technology service serving an application component
• A business actor serving a customer

Serving is one of the most common ArchiMate relationships because it communicates enablement clearly. It answers a simple question: what helps this element do its job? That makes it especially useful for capability enablement analysis and service portfolio modeling.

It is also important to distinguish serving from realization. A component may realize a service, but that service serves a consumer. One relationship expresses implementation; the other expresses use.

In an IAM program, the application service Authentication Service may serve the process Customer Login, while the technology service Directory Service serves the identity platform. That view quickly shows both business enablement and technical dependency.

Access

Access shows that behavior uses a passive structure element such as a business object, data object, or artifact. It applies when a process, function, or interaction reads, writes, or otherwise uses information or material.

Examples include:

• A business process accessing a Loan Application
• An application function accessing a Customer Record
• A reporting function accessing a Transaction History artifact

Access is especially valuable in information architecture because it shows where data is created, consumed, or updated. When qualified as read, write, or read/write, it becomes even more useful for identifying systems of record, data ownership, and integration dependencies.

As a practical rule, use access when the concern is data or object usage, not just general relevance.

Technology lifecycle governance often depends on this distinction. If a legacy database is marked for retirement, the critical question is not simply which applications are associated with it, but which functions still read or write the underlying data objects.

Influence

Influence belongs mainly to the motivation domain. It expresses that one element affects another in a directional or qualitative way. It is commonly used with goals, outcomes, requirements, constraints, and assessments.

Examples include:

• A requirement Multi-Factor Authentication positively influencing the goal Improve Security
• The same requirement negatively influencing the goal Reduce Customer Friction
• An assessment Legacy Integration Risk influencing a requirement for modernization

Influence is useful when the relationship is real but not operational in the same sense as serving or access. It helps architects model trade-offs and design pressures.

This is particularly useful in governance forums. For example, an assessment Kafka skills shortage may negatively influence the requirement Adopt enterprise event streaming by Q4, while the requirement still positively influences the goal Reduce batch integration latency.

Example: Digital Lending

Consider a lending scenario:

• The business process Approve Loan Application is served by the application service Credit Assessment Service.
• The same process accesses the business object Loan Application and the data object Customer Financial Profile.
• The requirement Decision within 5 Minutes influences the goal Improve Customer Experience.

This compact model shows three different forms of dependency:

1. operational support through serving,
2. information use through access,
3. strategic direction through influence.

That distinction is exactly why relationship precision matters.

Micro-example: Hospital Scheduling

A healthcare example illustrates the same point:

• The business process Schedule Outpatient Appointment is served by the application service Scheduling Service.
• The process accesses the business object Referral Request and the data object Clinician Availability.
• The constraint Maximum wait time under 7 days influences the goal Improve Patient Access.

Nothing in that example is structurally complex, but the relationships make the operating dependency clear enough to support redesign or system selection.

4. Dynamic Relationships: Triggering and Flow

Dynamic relationships show how behavior unfolds over time. Structural relationships explain how the architecture is organized. Dependency relationships explain support and usage. Dynamic relationships explain progression and transfer. They are especially useful for scenario modeling, process coordination, and integration analysis.

Triggering

Triggering expresses temporal or causal initiation. One event or behavior element starts another.

Examples include:

• A business event Customer Application Submitted triggering the process Review Application
• An application function Validate Identity triggering Create Customer Account
• A monitoring event triggering an incident response workflow

Triggering is useful when sequence matters but full process notation would be unnecessary or excessive. It shows that one step acts as the catalyst or precondition for the next.

Flow

Flow expresses transfer between behavior elements. Unlike triggering, which focuses on initiation, flow focuses on what moves: information, value, or material.

Examples include:

• A process flowing approved request details to a fulfillment process
• An application function flowing transaction data to a reporting function
• A customer service interaction flowing status information to a notification process

Flow is especially useful in integration and value stream views because it reveals handoffs. In practice, those handoffs are often where delay, duplication, or risk appear.

A useful distinction is straightforward:

• Use triggering when you want to show that one thing causes the next.
• Use flow when you want to show what is passed between them.

Many models need both.

Example: Event-Driven Fulfillment with Kafka

In an event-driven commerce scenario:

• The business event Order Submitted triggers the application function Validate Payment.
• Validate Payment triggers Create Fulfillment Request.
• The event Payment Confirmed flows to Fulfillment Orchestration through the application service Event Streaming Service.
• The application component Kafka Platform realizes that event streaming service.
• Fulfillment Orchestration accesses the Order Record.

This model is compact but realistic. It shows causal sequence, event transfer, service consumption, and the platform that implements the event backbone.

Micro-example: Incident Response Automation

A second example from operations architecture:

• The technology event CPU Threshold Exceeded triggers the application function Create Incident Ticket.
• Create Incident Ticket triggers Notify Support Team.
• Diagnostic details flow from monitoring to the incident management function.
• The application service Alerting Service serves the support workflow.

Here the distinction between initiation and transfer is essential. The alert starts the process; the diagnostic payload is what moves through it.

5. Other Core Relationships: Association, Specialization, and Junction

Not every valid connection fits neatly into the structural, dependency, or dynamic categories. ArchiMate includes a small set of additional core relationships that add flexibility without abandoning discipline. Used carefully, they clarify a model. Used casually, they weaken it.

Association

Association is the most generic relationship type. It simply indicates that two elements are related, without defining a more precise semantic meaning.

That flexibility makes association useful in two situations:

1. when a meaningful connection exists but no more specific relationship is appropriate,
2. when the architect is still working out the exact semantics and wants to capture a provisional link.

An architect, for example, may associate a business actor with a contract, or an assessment with a capability, when the model needs to show relevance without implying execution, support, or implementation.

Still, association should be used sparingly. Relationship precision is what makes a model analytically useful. Overusing association strips away that precision and makes the model harder to interpret. In mature models, many associations should eventually be revisited and refined into stronger relationship types.

Specialization

Specialization expresses that one element is a more specific kind of another. It is useful for taxonomies, reference architectures, and reusable patterns.

Examples include:

• Retail Customer Data Service specializing Customer Data Service
• Regional CRM Platform specializing CRM Platform
• High-Value Claims Process specializing a generic Claims Process

Specialization helps large organizations balance standardization with local variation. An enterprise may define standard capabilities, services, or technology building blocks, then allow business units to create specialized variants. This supports governance because local implementations remain traceable to enterprise standards.

Technology lifecycle governance often uses specialization this way. A standard Managed Database Platform may have specialized variants such as Managed PostgreSQL Service and Managed Oracle Service, each with different lifecycle status and retirement dates.

Junction

Junction represents a logical combination of relationships, typically using AND or OR semantics. It is used when multiple relationship paths need to be grouped explicitly.

Examples include:

• A process triggered only when both Customer Request and Compliance Approval occur
• A service request initiated through either a mobile app or a call center
• A requirement influenced by multiple assessments combined through a junction

Junctions are useful for simplifying complex views and making conditional logic visible. They are particularly helpful in operational and motivation models where multiple conditions or alternatives matter.

Used well, these three relationship types provide controlled flexibility:

• association for valid but generic links,
• specialization for inheritance-like variation,
• junction for explicit logic.

6. Modeling Examples and Practical Guidance for Choosing the Right Relationship

Knowing the definitions is only the beginning. The more important skill is choosing the relationship that best expresses architectural intent in context. This is where modeling moves from notation knowledge to architectural judgment.

Start with the Question the Model Must Answer

A reliable way to choose the right relationship is to ask what statement the model is actually making.

• If the statement is about structure, start with composition, aggregation, assignment, or realization.
• If it is about operational support or information use, consider serving or access.
• If it is about sequence or transfer, use triggering or flow.
• If it is about motivation or trade-off, use influence.
• If the relationship is valid but not yet precise, use association temporarily.

That approach also supports a basic modeling principle: use enough precision to preserve meaning, but not more than the audience and purpose require.

Example 1: Capability-Based Planning

Suppose an architect wants to show how the capability Customer Retention is enabled.

A weak model might connect the capability directly to an application component with serving, simply because the application “supports” retention. That is often too compressed to be useful.

A stronger model introduces intermediate layers:

• The business process Manage Retention Campaign enables or realizes the capability.
• The application service Campaign Management Service serves that process.
• The application component Marketing Platform realizes that application service.

This version is better for analysis because it separates business enablement from technical implementation. If retention performance is poor, the model helps show whether the issue lies in process design, service quality, or component capability.

Example 2: Application Portfolio Rationalization

Assume several applications use a shared Customer Master Data object.

If the architect uses association between each application and the data object, the model shows relevance but not significance. A better approach is to use access and qualify the usage where possible:

• CRM System writes customer master data
• Billing System reads customer master data
• Marketing Platform reads and updates selected attributes

Those distinctions matter because portfolio decisions depend on them. During migration or decommissioning, stakeholders need to know which systems create or update data, not simply which ones are connected to it.

Example 3: Operating Model Design

Consider the business role Claims Handler and the business process Assess Claim.

If the relationship is modeled as serving, it suggests support. If the intent is to show who performs the work, assignment is the correct choice. If the same process consumes a Fraud Detection Service, then serving is appropriate for that separate relationship.

This illustrates an important principle: the same element can participate in different relationship types depending on the question being asked. The issue is not the element itself, but the meaning of the connection.

Example 4: Architecture Board Decision

Suppose an architecture board is reviewing a proposal to introduce a new IAM suite.

A useful model would show:

• The application service Authentication Service serves Customer Login and Workforce Access processes.
• The application component IAM Suite realizes Authentication Service and Access Certification Service.
• The technology service Directory Service serves the IAM suite.
• The requirement Retire legacy LDAP by 2026 influences the target-state decision.
• The legacy platform remains linked through access to identity data objects that must be migrated.

This gives the board a much stronger basis for approval than a simple product comparison because it shows support, implementation, migration dependency, and risk.

Example 5: Event-Driven Integration

Suppose a digital commerce platform receives an order, performs payment validation, and sends fulfillment instructions.

A useful model might show:

• Order Submitted triggers Validate Payment
• Validate Payment triggers Create Fulfillment Request
• Payment confirmation flows to fulfillment through an event stream
• The application component Kafka Cluster realizes the application service Enterprise Event Backbone
• The fulfillment process accesses the Order Record
• The fulfillment application service serves the warehouse process

This combines dynamic, dependency, and structural reasoning in one coherent chain. Because each relationship plays a distinct role, the model can support both operational discussion and solution impact analysis.

Example 6: Technology Lifecycle Governance

Consider a decision to retire an on-premises integration platform.

A useful lifecycle view might show:

• The technology node Legacy ESB Platform serves several integration components.
• Those components realize application services still consumed by core business processes.
• A replacement Cloud Integration Platform specializes the enterprise standard for integration services.
• The assessment Vendor support ends in 12 months influences the requirement Migrate critical interfaces by Q3.

This is the kind of relationship chain needed for lifecycle governance: what is being retired, what depends on it, what standard replaces it, and what deadline drives the change.

Example 7: HR Self-Service Modernization

A smaller but realistic example comes from HR transformation:

• The business process Update Employee Details is served by the application service Employee Self-Service.
• The application component HR Portal realizes that service.
• The process accesses the data object Employee Master Record.
• The event Employee Change Submitted triggers Validate Payroll Impact.

This gives enough detail to discuss user experience, data ownership, and downstream integration without turning the view into a full process model.

Practical Heuristics

The following heuristics help in everyday modeling:

• Choose the most specific defensible relationship.
• Do not use association as a permanent substitute for analysis.
• Use realization for implementation, serving for consumption.
• Use assignment for responsibility, not generic support.
• Use access when passive objects are used by behavior.
• Use triggering for initiation and flow for handoff.
• Prefer aggregation over composition unless strict containment is intended.
• Revisit relationship choices as the model matures.

Think Ahead to Analysis

A strong test for relationship quality is to imagine what analysis the repository should support later.

• For accountability analysis, assignment is critical.
• For service dependency analysis, serving is critical.
• For implementation traceability, realization is critical.
• For data lineage and governance, access and flow are critical.
• For strategic trade-off analysis, influence is critical.
• For lifecycle and obsolescence planning, serving, realization, and access are often the key combination.

If the relationship choice would prevent those questions from being answered, it is probably too vague.

Avoid False Precision

Precision is useful only when it reflects reality. Architects sometimes choose a very specific relationship too early because it makes the model look more complete. That can create false confidence. A temporary association may be better than an incorrect realization or serving relationship. The objective is not maximum specificity; it is accurate and useful semantics.

Ultimately, good relationship modeling is an exercise in judgment. The best diagrams are not the ones with the most connectors, but the ones where each connector carries deliberate meaning.

Conclusion

ArchiMate relationship types are what make architecture models operationally meaningful. Elements describe the enterprise; relationships explain structure, responsibility, support, data usage, progression, and implementation. When those semantics are chosen carefully, the model becomes useful for traceability, impact analysis, governance, and transformation planning.

Each core relationship family serves a distinct purpose. Structural relationships such as composition, aggregation, assignment, and realization explain how the architecture is organized. Dependency relationships such as serving, access, and influence show support, information use, and strategic effect. Dynamic relationships such as triggering and flow explain movement and progression. Association, specialization, and junction provide flexibility where generic linkage, variation, or logic must be expressed.

The real value lies not in memorizing definitions but in selecting the relationship that best matches the architectural question. A service may serve a process, a component may realize that service, a role may be assigned to the process, and the process may access data and be triggered by an event. Those distinctions are what allow the same repository to support communication, analysis, and decision-making.

In mature enterprise architecture practice, relationship quality is often a sign of model maturity. Early models may rely on broader links while understanding is still emerging. Over time, those links should be refined so the architecture can support planning, compliance, rationalization, and change execution with greater confidence.

Used with discipline, ArchiMate relationships are not just notation rules. They are the semantic framework that lets architects connect strategy to execution and describe the enterprise in a way that is both accurate and actionable.

Frequently Asked Questions

What are the main ArchiMate relationship types?

ArchiMate defines structural relationships (Composition, Aggregation, Assignment, Realisation), dependency relationships (Serving, Access, Influence, Association), dynamic relationships (Triggering, Flow), and other relationships (Specialisation, Junction). Each type has a specific semantic meaning in the model.

What is the difference between Serving and Realisation in ArchiMate?

Serving means one element provides a service to another (e.g. an application serves a business process). Realisation means one element implements or fulfils another (e.g. a business process realises a business service, or an application component realises an application service).

When should I use Association vs Influence in ArchiMate?

Use Association for a general, undirected relationship when no more specific type applies. Use Influence to show that one element affects the properties of another — typically used in the Motivation layer to show how drivers, goals, and principles influence each other.