Using Dynamic relationships in ArchiMate®

Dynamic relationships in ArchiMate

ArchiMate is especially powerful because of its rich set of relationship types. These relationships are grouped/classified in 4 sets:

1. Structural
2. Dependency
3. Dynamic
4. Other (called “Special” by me)

The basic pattern in ArchiMate modelling is:

1. You identify the main components in your architecture landscape. Those (as a rule) will be Active Structures (mostly Internal Active structures such as Business Actors or Devices, and networks, neither external or internal).
2. You detail these main components or nodes using structural relationships.
3. You identify the cohesion between these components by determining how they are connected using dependency relationships (mainly Serving).

If you have done this properly, the result should be a graph of Active Structures connected with each other through Services/Interfaces. This ensures the primary architecture principle of high cohesion-loose coupling. Great work!

However!

We also have dynamic relationships. They also create relationships between elements. An example:

The “Accept Claim” process is performed by a Role: Customer Service Representative. That process triggers (a dynamic relationship) the Assign Claim process.

However, that process is performed by a different internal active structure: High-Risk Claims Adjudication.

I have an issue with this model. What is it?

Well, the issue is the direct triggering of the behaviour of another entity, bypassing the entire premise of ArchiMate, namely the encapsulation of behaviour with an external layer.

As you may remember, the behaviour of an Active Structure in ArchiMate is Internal, that is: not available directly from outside (= other entities besides the one that performs this behaviour). If you want that internal behaviour of another entity to be of service to you, the honourable way to do that would be to utilise the published external behaviours, also called Services:

This is the honourable way to trigger a behaviour:

1. I need to do something: Accept Claim
2. When that is done, I would like someone else to “take over”: I request that by invoking a service called Assign Claim. Handover!
3. The assign claim service is realised by the Assign Claim business process of that other (internal active structure, so effectively invisible to me: loose coupling)

This is why I always explain that: no I do not have a fundamental issue with using dynamic relations, but please keep in mind that in a proper architecture those relations are best seen as a kind of shorthand:

The same applies to the Flow relationship: it is very impolite to directly flow into someone else’s (internal) behaviour, but it can be useful to show the shorthand notation.

Especially for implementers (solution architects or developers) working with these ArchiMate models as input, this is an important aspect to be aware of.