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).
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.
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
This is interesting. Working mostly with Sparx EA and its UML representation of Archimate I hadn’t realized that other tools couldn’t represent the CP relationship. I just gave it a go in Archi and I see what you mean.
I like the CP relationship for design documents Node 1 – communication path – Node 2 perfectly describes a needed firewall rule. If a project asks for rules not reflected by the CP relations in their views it demonstrates the incompleteness of the views and provides a point to intervene and get complete designs.
This is because, in ArchiMate 2.1, CP is not a relationship. As Gerben points out, CP is an element that can only be connected to other ArchiMate elements via an Association relationship. Thus, to implement this alternative representation of a CP as a (bogus) connection/relationship, the “connection” at the model level would have to consist of a composite of a CP element plus two Association relationships. Does Sparx do this, or does it use a bogus relationship?
BTW – I’m not actually convinced that Sparx is a proper implementation of ArchiMate at all. Like some other “tools”, they seem to have jumped on the ArchiMate bandwagon, throwing out “yet another metamodel” without any thought and effort.
I’m not sure why you think Sparx’s implementation of Archimate is a metamodel, I’m not sure there is anything meta to it at all. It’s also unfair to accuse them of putting in no thought or effort. I’ve dug into the Archimate MDG and there’s been quite a bit in it.
The problem is as I originally stated, it’s Archimate rendered in UML. And there is often posts on the Sparx forums where someone says asks how they can make the Archimate MDG more UML-like because they are used to the other UML based notations.
Gerben – just to reply to your comment regarding the alternative representation of a Communication Path where you say: “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.”
Yes and no.
Given the example of a CP connected to two Nodes via two Association relationships, at the model/semantic level the CP plus its two (Association) relationships are persisted in the exchange format unequivocally. When it comes to a diagram (“View”), the visual representation of the element and its relationships is persisted on a one-to-one basis – a box (referencing the CP element) and two connections (referencing the relationships). However, it should be possible for a tool to interpret this triad and display the CP alternate figure. The exchange format packages and ships the raw ingredients, and then the tool has the liberty to display those in a sensible or alternate manner.
Good point, Phil. I wonder then how one would visually represent in ‘relation-form’ a Communication Path element that is Associated with 3 different Nodes. With all three paths. Now turn this around. Have a model where you have modelled two different CP paths (relation form) between 3 Nodes. a) how do you know this is the same CP? b) is the 3rd implicit? It remains messy as hell.
Yes, it gets messy. And what about the case where a CP element realises a Goal (CP connects to Goal via Realization relationship)? In this case the CP has only one relationship and looks odd when rendered as a double arrow. (I know this example is not realistic, but it is allowed.)
So, what are we saying?
Should CP be re-classed as a relationship, or is the alternate double-arrow figure simply confusing things? I suspect that it was well-intentioned, but no-one thought about the implications. 🙂
What would the practical application of modeling a CP between three different nodes?
Messaging between Node A and Node B, as well as between Node A and Node C?
A -> B and A -> C are two different relationships and are easy for a tool to spit out something that articulates the requirement for firewall rules or network layer ACLS. A -> B&C seems to me to be very easy to confuse for A -> [B|C].
My reaction to this was – OK so it’s not just me after all. Thanks for that.
Really I struggle with Archimate generally – and these idiosyncratic characteristics underscore why.
When I work with it I can never really settle in my mind whether I am creating a purely functional (abstract) architecture, or representing material structures (blueprints if you like). It always seems to hover – annoyingly – between the two: Bolted onto specific implementation choices and requirements, but with insufficient fidelity to do the job.