Open Letter to TOG #5

Dear TOG,

I hope this letter finds you well.

As shepherd of the ArchiMate standard, you are currently working on its next iteration. As I am not part of the ArchiMate Forum, I am going to send you a few open letters with suggestions for improvement of the language and what to do an not to do. I will be voicing some stern/harsh criticisms on ArchiMate in these letters, please don’t take it personal, I’m only interested in strengthening the language which I already find useful as it is. And I apologise beforehand for my language here and there.

This is the fifth of such a letter. The previous ones: fourth, third, second, and first.

Today, I want to write to you about Communication Path and Network.

ArchiMate’s infrastructure layer contains two specific elements that have to do with communication between computers: Network and Communication Path.

According to the specification, Network “represents the physical communication infrastructure”, e.g. a fixed or wireless network. What ‘physical’ is, is not 100% made clear, so maybe it is a good idea to extend the explanation with a reference to the layers normally recognised in networking circles, e.g. ‘layer 1’ for physical (wires, wireless), ‘layer 2’ for ethernet or other switched protocols, etc.

Again, according to the specification, Communication Path “is used to model the logical communication relations between nodes” and it is defined as a link that makes it possible for Nodes to exchange data. The example given is this (here represented in the Mastering ArchiMate colouring scheme):

Now, here is a first issue. A Communication Path is in fact an active element and not a relation. The above is an alternative display of the following:

The relation-form is one of the oddballs in ArchiMate. The oddest of them all, by the way, is Grouping, which according to the specification is a relation, but it does not connect any element to any other element in the model and it also looks like an element:

As you might be aware, I’ve advocated fixing this in ArchiMate. Make Grouping a real element in a new category (e.g. ‘collections’, as it is neither active, nor passive, nor behavioural and it can Aggregate all of them. The collections category of elements is also useful for modelling combinations such as Capability. But I digress.

Another oddball is Communication Path, which is an active structure element that can be displayed as a relation. I don’t know if there is any tool that actually can display the ‘relation-look’ of Communication Path (or Network, which has the same oddball form). None of the tools I use can do it. It seems to be unnecessary for a tool to be able to do this to get certified. It is also not part of the recently published ArchiMate Exchange Format, there is no way you can put the actual example from the specification in the official exchange format.

(Aside, you may read Modelling networking using the networking concepts of ArchiMate for some extra background.)

Now, there are two more ways to display the exchange of data between Nodes. The first is using the Flow relation:

There is a difference as in that Flow has a direction, whereas Communication Path has not.

One can wonder why these two ways of modelling data exchange between Nodes exist. For Flow, it is I think easy to explain. ArchiMate 1 (and pre-TOG ArchiMate) did not have Flow in the infrastructure layer. The reason is that Flow is defined as a flow of information between functions and ArchiMate 1 did not have Infrastructure Function. So, Communication Path was more or less needed in ArchiMate 1 to play the role that Flow plays in ArchiMate 2 and up. Not quite, of course, because Flow has a different semantics (dynamic) than Communication Path (structure). But the relation-form of Communication Path was nice to have, because otherwise there was no way to depict data exchange. ArchiMate 2 added Infrastructure Function and with it Flow but left Communication Path alone. My suspicion is that it is almost never used by anyone, so no big deal.

Which brings us to the last variant to model data exchange between Nodes, which uses the Access relation:

This pattern, by the way has a strong overlap with Flow. In fact, every time you model a Flow, you can model two Access relations and a passive structural element between them and vice versa. The only semantic difference with Flow is that you cannot model (only add in a label) what exactly is in that Flow. And the pattern with an Artefact and Access relations breaks all attempts to derive something later on because Access is always directed opposite (something that might be discussed as well).

Conclusion

The constructs for Network and Communication Path with the ‘relation-form of an element’ is problematic. I think it is not for nothing that tools do not support it, which says something about their use. No big protest will emerge when this duality is dropped, I think.

Communication Path was needed in ArchiMate 1 and before, for one because there was no alternative as ArchiMate 1’s infrastructure layer did not have function and thus not flow and drawing data exchange in a simple relation-form is nice to have. In the current situation it is however largely superfluous and it can probably safely be removed. If you want to model both the dynamic and the structural aspect of communication, you can do it as it can be done in the other layers: using Flow and Access.

Network can be a useful construct, but networking is far more complex than what can comfortably be modeled in ArchiMate. That already is a problem, because networking has become more and more a regular part of what the IT-side of EA is about. Think ‘cloud’ (which is transforming our snug and cosy data centers into a fragmented and distributed set which we only partly own), ‘security’, ‘software defined data centers’ etc., stuff that has become the talk of the boardroom. ArchiMate, however, is still stuck in a world where “the most basic network is a single link between two devices”.

I used to think of networks like that, but frankly, that was ignorance of developments since I last looked at it seriously. These days, networks are an ever more essential part of enterprise architecture and ArchiMate lags far behind.

What we need is a way to create models of our networking instead of the Visio pictures that reign everywhere. But for that, we need to be able to model switches, routers and such, all Nodes and probably we should let those Nodes realise the networking. It would be nice if we could do something in ArchiMate and make those Visio graphics obsolete as well as move to modelling instead of drawing our networks.

Yours truly,

Gerben Wierda
Former Lead Architect of APG Asset Management and of the Dutch Judiciary
Team Coordinator Architecture & Design at the All Pension Group (APG)
Author of Mastering ArchiMate and Chess and the Art of Enterprise Architecture