ArchiMate Relationships

ArchiMate defines 11 core relationships organized into four categories. Understanding proper relationship usage is critical for model quality and analysis.

Relationship Categories

Structural Relationships (Static Construction)

Relationship	Notation	Usage
Composition	Solid line + filled diamond	Strong whole-part; parts cannot exist independently
Aggregation	Solid line + hollow diamond	Weak whole-part; parts may belong to multiple aggregations
Assignment	Solid line + circle at source	Who/what performs behavior; links actors to roles, components to functions
Realization	Dashed line + hollow triangle	Logical-to-physical mapping; cross-layer implementation

Dependency Relationships (Support/Usage)

Relationship	Notation	Usage
Serving	Solid line + open arrowhead	Service delivery; arrow points toward consumer
Access	Dotted line + optional arrowhead	Data access; use mode indicators (r, w, rw)
Influence	Dashed line + open arrowhead	Affects motivation elements; can include +/- strength
Association	Solid line (undirected/directed)	Generic relationship; use when no specific type applies

Dynamic Relationships (Temporal/Flow)

Relationship	Notation	Usage
Triggering	Solid line + filled arrowhead	Temporal/causal precedence between behaviors
Flow	Dashed line + filled arrowhead	Transfer of objects between behaviors; label what flows

Other

Relationship	Notation	Usage
Specialization	Solid line + hollow triangle	Type hierarchies; same-type elements only

Key Direction Principle

ArchiMate relationships consistently point toward enterprise goals and results:

• From Technology → Application → Business
• From Active Structure → Behavior → Passive Structure

Cross-Layer Relationship Patterns

Business ↔ Application

Supporting:

[Application Service] → [serves] → [Business Process/Function]
[Application Interface] → [serves] → [Business Role]

Realizing:

[Application Process/Function] → [realizes] → [Business Process/Function]
[Data Object] → [realizes] → [Business Object]

Application ↔ Technology

Supporting:

[Technology Service] → [serves] → [Application Component/Function]

Realizing:

[Artifact] → [realizes] → [Application Component]
[Artifact] → [realizes] → [Data Object]

Service-Driven Architecture Pattern

The canonical layered view shows service chains connecting layers:

[Business Actor: Customer]
    ↓ served by
[Business Service]
    ↓ realized by
[Business Process]
    ↓ served by
[Application Service]
    ↓ realized by
[Application Component]
    ↓ served by
[Technology Service]
    ↓ realized by
[Node: Device + System Software]

Common Relationship Patterns

Actor-Role-Function Pattern

[Business Actor] → [assignment] → [Business Role] → [assignment] → [Business Process/Function]

Service Realization Pattern

[Business Role] → [assignment] → [Business Process] → [realization] → [Business Service]
[Business Interface] → [assignment] → [Business Service]

Deployment Pattern

[Application Component] ← [realized by] ← [Artifact] → [assigned to] → [Node/System Software]

Relationship Selection Guide

Want to show...	Use
What performs behavior	Assignment
What implements/realizes something	Realization
What provides service to whom	Serving
What reads/writes data	Access (with r/w/rw)
What causes what to happen	Triggering
What passes between behaviors	Flow (label it)
Part-whole (dependent)	Composition
Part-whole (independent)	Aggregation
Type hierarchy	Specialization
Motivation impact	Influence (+/-)
Generic connection	Association (last resort)

Output Format for Relationships

Notation Format

[Source Element] → [relationship type] → [Target Element]

With Access Modes

[Application Function: Process Order] → [access (rw)] → [Data Object: Order Record]

With Flow Labels

[Business Process: Receive Order] → [flow: Order Data] → [Business Process: Validate Order]

Additional Resources

Reference Files

For detailed relationship patterns and advanced cross-layer guidance:

• references/relationship-patterns.md - Complete relationship pattern catalog with examples