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. They will mostly be 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.

Microservices gaan overwaaien, want het past niet bij hoe tegenwoordige organisaties werken.

Source: cio.nl

Een wat chargerende titel die de lading van het artikel niet helemaal dekt. De schrijver is namelijk helemaal geen tegenstander van het principe, misschien zelfs integendeel. Hij signaleert alleen heel terecht dat het invoeren van deze architectuurstijl niet alleen maar beperkt kan blijven tot een technische architectuurkeuze.

De Wet van Conway is belangrijker dan ooit, namelijk de noodzaak de organisatie zodanig ingericht te hebben dat het af te beelden is op de architectuurstijlen (zowel aan business als techniek zijde!) waarvoor gekozen wordt. Ik noem dit ook wel "fractale architectuur": de structuur herhaalt zich op verschillende aggregatieniveaus.

Het is niet voor niets dat ik ook "slecht nieuws" heb voor organisaties die voor SOA hebben gekozen, maar niet een interne structuur (een dienstgerichte indeling) hebben die hiermee resoneert: jullie zullen ook  die interne structuur aan moeten passen, met een governance proces dat hierop afgestemd is.

Door dit af te stemmen op kantel-initiatieven die in heel veel organisaties al speelt, kunnen soms meerdere vliegen in één klap worden geslagen!