ArchiMate_Ontology

Lecture 029: Dependency Relationships – The Serving Relationship

In the evolution of an enterprise architecture meta-model, understanding how different elements interact and support one another is vital. While structural relationships model the static composition of an architecture, Dependency Relationships describe how elements are used by or support others.

This chapter focuses on the strongest of these dependencies: the Serving Relationship, its semantic definition in ArchiMate 3.2, and its practical implementation within an ontology-based framework.

• Lecture 029: Dependency Relationships – The Serving Relationship
  • 1. Overview of Dependency Relationships
  • 2. Deep Dive: The Serving Relationship
    • 2.1 Semantic Definition
    • 2.2 Evolution: “Used By” vs. “Serving”
  • 3. Practical Modeling Case: The Payment Process
  • 4. Ontology Integration (RDF/OWL)
  • 5. Key Takeaways for the Architect

1. Overview of Dependency Relationships

Relationship	Type	Strength	Notation
Serving	Control/Functional	Strongest	Solid line with arrow
Access	Data	Strong	Dotted line with arrow
Influence	Impact	Weak	Dashed line with arrow
Association	Generic	Weakest	Solid line (no arrow)

2. Deep Dive: The Serving Relationship

The Serving Relationship describes how the services or interfaces offered by a behavior or active structure element serve entities in their environment.

2.1 Semantic Definition

The serving relationship represents a functional dependency where an element provides its functionality to another. It is used to model the “external” view of a service or interface.

• Directionality: The source (e.g., a Service) serves the destination (e.g., a Process or Actor).
• Layer Agnostic: It can be applied within a single layer (Business Service serving a Business Process) or across layers (Application Service serving a Business Function).

2.2 Evolution: “Used By” vs. “Serving”

In versions of ArchiMate prior to 3.0, this relationship was primarily known as “Used By”. While the fundamental meaning remains the same, the standard now favors “Serving” for two reasons:

1. Active Verb Usage: “Serving” acts as an active verb, making the direction of the relationship (Source $\rightarrow$ Target) more intuitive.
2. Clarity: “Used By” often created confusion regarding which element was the provider and which was the consumer.

Note: The term “Used By” is officially deprecated. Architects should transition all models to the “Serving” nomenclature to ensure future compatibility with the standard.

3. Practical Modeling Case: The Payment Process

To illustrate the Serving relationship, let us examine a standard financial interaction within the Archi tool.

The Scenario

We are modeling a customer paying an invoice. This involves several layers of the architecture working in tandem:

• Business Actor: Customer.
• Business Process: Pay Invoice (Assigned to the Customer).
• Business Service: Payment Service (Serves the ‘Pay Invoice’ process).
• Business Interface: Payment Interface (Serves the Customer).

The Model Construction

1. Functional Serving: The Payment Service is linked to the Pay Invoice process via a Serving relationship. This indicates that without the service, the process cannot fulfill its behavioral requirement.
2. Structural Serving: The Payment Interface (the “how” or “where” of the service) serves the Customer actor directly, providing the point of entry for the interaction.

4. Ontology Integration (RDF/OWL)

When building an ontology-based meta-model, the Serving relationship must be defined as an Object Property.

• Property Name: serves
• Inverse Property: isServedBy
• Metadata: In the RDF triples, we define the source as the provider and the target as the user.

By defining this in tools like Protégé, we can later run reasoning queries to identify “orphaned” services (services that serve no process) or critical dependencies where a single service serves a high volume of business functions.

5. Key Takeaways for the Architect

• The Serving relationship is a “Control” dependency. It implies a high degree of necessity.
• Focus on the Direction. Always model from the provider to the consumer.
• Avoid Redundancy. While dynamic relationships (Triggering/Flow) exist, Serving should be used to describe the static functional support structure of the enterprise.

---

This concludes Lecture 029. In the next lecture, we will explore the Access Relationship and how to model data dependencies between behavioral and passive structural elements.

---

Last updated at 2026-04-13

This site is open source. Improve this page.