ArchiMate® 3.0 – Improvements in Relationships

In our previous blogs, we have mainly focused on the new layers and elements of the ArchiMate 3.0 language. Although these concepts are the first changes that catch the eye in ArchiMate 3.0, there are also several improvements in the use of relationships.

Relationship classes and derivation rules

In ArchiMate 2.1 and earlier, three classes of relationships were distinguished: structural, dynamic and other relationships. In ArchiMate 3.0, dependency relationships have been added. The class of structural relationships now only consists of composition, aggregation, assignment and realization. The serving, access and influence relationships are classified as dependency relationships, while the association relationship is moved to the class of other relationships, as it is neither a real structural relationship nor a dependency relationship. Grouping and junction are no longer classified as relationships, as will be explained below.

There are some minor changes in the derivation rules for relationships. The derivation rule for structural relationships now applies to both structural and dependency relationships, and the relative strength of the relationships has not changed. However, the rule no longer includes association, as this relationship is allowed between any pair of elements anyway. For the dynamic relationships, triggering and flow, there are a number of changes in the derivation rules. For a combination of structural and dynamic relationships, a new “inside-out” rule applies: informally, this means that the begin or end point of a flow relationship (and, with some restrictions, a triggering relationship) can be transferred ‘backward’ in a chain of structural relationships, or if this is denoted as nesting, to a ‘containing’ element. Also, triggering relationships are now transitive: if an element A triggers B, and B triggers C, A can be said to trigger C indirectly.

Notation and naming

The notations of some of the relationships have undergone some minor changes.

To the existing variants of the access relation, “read” or “write” (with an arrowhead on one side) or unspecified (without arrowhead), an additional variant has been added, “read/write”, with arrowheads on both sides. In Enterprise Studio, an arrowhead can now simply be added or removed by clicking on the endpoint of the relationship.

Although the assignment relationship was already directional – for the purpose of the derivation of relationships – this has now been made explicit in the notation, by changing the dot at the destination of the assignment to an arrowhead.

Finally, the arrowhead of the influence relationship has been changed from a ‘solid’ arrowhead to an ‘open’ arrowhead, for consistency with the other dependency relationships, serving and access.

Figure 1: Changed notations for relationships

The ‘used by’ relationship has been renamed to ‘serving’, in order to get rid of the clumsy passive tense. This will also help to avoid the common confusion that exists about the direction of this relationship.

Relationships between elements and relationships

It is now also possible, in a limited number of situations, to draw a relationship from another relationship to an element, or vice versa. There are two main cases in which this is allowed:

Any relationship may have an association relationship with any element. A typical use case of this is to associate a flow with a business or data object representing the information that is transferred. Figure 4 (left) shows an example of this.
In addition to arbitrary (Core) elements, the composite elements Grouping and Plateau may now also aggregate relationships. Figure 4 (right) gives an example of why this may be useful. Assuming that in a small sales company, the Sales department is also responsible for the Product marketing function, but as the company is growing, management has decided to set up a separate Marketing department. The Product marketing function and the Sales department are part of both the baseline and the target plateau, but the Marketing department is only part of the target plateau. But there is also a change in the relationships between these elements: in the baseline plateau, the Sales department is assigned to Product marketing, while in the target plateau, the Marketing department is assigned to this function. This can only be expressed with aggregation relationships from the plateaus to the assignment relationships.