Modelling Networking in ArchiMate 3.1

ArchiMate has three element types that specifically deal with transport. There is Communication Network which represents physical networking infrastructure for transport of data, there is Distribution Network that has the same function for physical transport, so physical network structure for transport of goods, and there is Path, a more abstract element the represents transport at a higher level. In one way or another, these have been part of ArchiMate from the start. They also have been ignored by almost anybody from the start, for a variety of reasons. In this article we look at these elements, and look also at an alternative way of modelling networking in ArchiMate 3.1, without these concepts at all. Networks? We don’t need networks!

Note, this article is not for ArchiMate absolute beginners. I am discussing ArchiMate here and assuming you are already understand it and are interested in arcane ArchiMate discussions. I am discussing a ‘problem area’ in ArchiMate and as such it is not really helpful for standard modelling work. However, after having made this warning, go ahead and read it, it might still add to your understanding. But to make sure you understand that this is not representative of how ‘hard’ ArchiMate can be, I use the dangerous bend image here at the left (kudos for who knows the origin of this image).

History of ArchiMate’s Networking Elements

The people that created ArchiMate around 2002–2004 were by academics and professionals from a few large Dutch administrative organisations, such as the national tax service, insurance companies and pension funds. The focus of the professionals was the administrative organisation and the applications that manage insurance-like data. It is not that strange that ArchiMate’s main example model was ‘ArchiSurance’ a model describing an Insurance company. Nor the professionals nor the students apparently found infrastructure particularly relevant, not were they really informed about it, so ArchiMate got saddled with a view on networking that is, let me be kind: somewhat lacking. It is not possible to use this for solution designs where the actual networking architecture is important. I’m also unaware that any tool actually implements it in full (e.g. the ‘relation-forms’ of the Network/Path elements). This did not change over the years. The definitions changed a bit, but the structure stayed as it had been since around 2004. The most substantial change was when ArchiMate 3 in 2016, which changed the infrastructure layer to a ‘technology and physical’ layer.

Before ArchiMate 3, the available concepts were:

• Network — an element representing physical network infrastructure, such as a LAN or WAN network
• Communication Path — a more abstract element representing communication between physical Nodes, such as message transfer between servers. A Communication Path could be Realised by one or more Networks.

In ArchiMate 3, the physical world was added to ArchiMate and the lower layer elements for transport became:

• Communication Network — an element representing physical network infrastructure, such as a LAN or WAN network (the old Network element, however it is connected (we will see how below) to Devices (digital gear) instead of Nodes.)
• Distribution Network — like Communication Network, but for physical transport, such as a system of rails and trains
• Path — a more abstract element to represent that can be Realised by one or more network elements and that models the exchange of data or physical stuff.

In addition, the Communication Network can Aggregate Nodes, which is meant to model the structure the Network is created from. The Nodes Aggregated in a Network element represent for instance switches, routers, firewalls (for Communication Network) or trains, trucks, and the like (for Distribution Network). We will illustrate this article with example from the digital world. A Communication Network Aggregates the parts it is made up of (Devices such as routers, switches) and it is Associated with Devices that are connected to it. An example — in the Mastering ArchiMate colour scheme — is shown here:

Shown is a simple Communication Network made up of a switch and a router and two servers are connected to it. We’ll get to the Path element below.

Some problems with the Networking Elements

That the authors of ArchiMate up to today have little interest for infrastructure shows up to today. This part of ArchiMate is even sloppy, here and there. It is also something that I have never seen used outside of the few examples in the standard itself or something of the same level of simplicity. It still shows a certain disdain for the world of infrastructure, or at least some form of ignorance (as in: ignoring what is really going on there). This can even be ironic if ignoring infrastructure comes from enterprise architects promoting cloud-visions and such, as cloud computing is in fact infrastructure and it is those infrastructure innovations driving businesses. Not understanding that — with the exception of SAAS — cloud is just another type of data center for your infrastructure (you still need to manage almost all of it yourself) is somewhat myopic. Most enterprise architects I encounter are blissfully unaware of what happens in infrastructure, and especially tend to ignore the huge complexity that is part and parcel of the infrastructure world. But I digress. As usual.

Anyway, let’s have a look at some of these problems first. Take a look at this diagram, which is a fragment of Example 30 from the ArchiMate 3.1 standard:

The first thing we notice in this example is that the relations between both Communication Network elements and are Associations, not Aggregations as they are supposed to be. In ArchiMate 2, it was only possible to Associate and there was no way to model the elements that actually make up the network unambiguously. Another things we could notice is that using a switch to connect the Data Center Network to the Wide Area Network is silly. Again: no real attention was paid to this in the standard, apparently.

The second thing we notice is that the Data Replication (Path) is Realised, but it is not connected to anything. According to the standard, it can be Associated with and it can Aggregate any Technology layer active structure element (so mainly any Node or subtype of Node). But the text does not explain what either means nor is an example given so we can figure it out. If we start guessing, then it would be the equivalent of what happens with the Network element, in which case Association means ‘connected to it in order to make use of it’ and Aggregation means ‘made up of it’. The Association (use) part is easy enough to use in modelling, but the Aggregation part is confusing. What am I going to Aggregate in a Path? I already have the Networking elements that Realise it and in natural language make it up. So, what is a Path made up of? I can imagine that the software on two servers make up a ‘data replication’, so is the Path made up of those software elements? Did nobody try to actually produce at least a single decent example during this ArchiMate development? Nah, probably not. Infrastructure is irrelevant, remember?

The third thing we notice is that if a Server uses a Network, we would like to use an Interface or service. As anyone acquainted with networking technology knows, these switches, routers, firewalls, and so forth, are just specialised computers often with specialised hardware, but sometimes not even that. And this shows in that we model the switch above as an ArchiMate Device. In fact, it is not that different from a server, so why not a Node (as it used to be)? And why not have that Device’s Interface and/or Service be used by the Devices/nodes that make use of it? In fact, do we need Network elements at all? Can we do without? Yes, we can!

There is a simple way

A network is just another part of your digital landscape that is made up of (specialised) computers with some special interfaces. So, what if we would ignore Network and Path elements and try to model networking using the other standard elements? How would we do it? Well, what about this?

The blue Serving relations show that the servers are attached to the switch (of course, in real networks, that switch would be a Node element called “ACI fabric” or something like that). You could also model the orange ones to show they are connected to the LAN. And incidentally, in ArchiMate 3.1, the orange Servings are reliable derivations of the blue ones. Of course you can now also do much more interesting things such as model the full function and service or interface elements. E.g. the interface o the switch may be ethernet or fiber. And it is easy to have these devices realise all kinds of interesting networking concepts as Nodes, such as security zones, VLANs, you name it. Note: all the Servings are in fact derivations, fully modeled could be done too with named Functions, Services, and Interfaces.

Who needs Communication Network? The network is a computer (with a nod to John Gage — who meant it quite differently) after all.

Now, it is time to get really creative and so I am upping the warning level. Because the next diagrams are showing setups that are not 100% valid ArchiMate. Having said that, what about that Path element type? Well, as it turns out, we don’t really need that one either in our example. Let me first show you what I would like to be able to do instead of using Path but aren’t. What I would like to do with Flows is not only be able to Associate something with it, but I would like to have a Flow use a Service (or derived a Function or an active element such as Node as shown here):

Of course, as long as I cannot use Serving, I might use Association to show the Flow makes use of it until The Powers that Be have decided to change ArchiMate. (Though I really hope not, new versions of the book are a lot of work). This is allowed in the standard (thanks for correcting me JB):

This seems to be valid. And another possibility (for those that would like to mimic the Path being an abstraction from a Network) is:

None of the two proposals (Serving or Realisation) are perfect fits in ArchiMate’s current setup, but either could be selected to play the more generic role of “makes possible”. My preferences is Serving and it then becomes a shorthand for Serving both ends of the Flow (which is what actually is the case), besides, I would prefer if Realisation would be a pure ‘identity abstraction’, i.e. both ends of a Realisation are the same thing, just more or less abstract.

And in an attempt at ultimate ArchiMate geekery, have a look at the last one:

Impromptu quiz question: what is going on here (compared to the earlier one that used the Serving relation)? Is that valid? Is it a smart move?

The answer is: I am using Section 15.2 of the standard and have defined a few of my own subtypes of Node, specifically to model a Switch, a Router, and a LAN. Pretty neat, but there are drawbacks. For one, which tools support this properly? For another, such extensions aren’t really supported by the ArchiMate Exchange Format (as far as I know), so even if your tool supports it, you’re painting yourself in a tool-corner. Having said that, if you except these, the actual choice in the example, where the subtype of Node is called ‘Network’ and it uses the Communication Path icon. That could be very confusing, but on the other hand, as nobody used these official network elements anyway, the damage will be limited.

So, who needs Communication Network or Path? Not I.

PS. In 2014, using ArchiMate 2, I wrote my first article about Modelling Networking in ArchiMate and there I used the ‘relation-form’ of the Networking element. It never satisfied me, if only I could not really model that way in my tool (the diagrams were faked by using Associations that were given a different appearance). Neither does the above fully (e.g. Flow is unidirectional (hint, hint…) and there should be some way to model a ‘bus’ (that would then be an element-form of the Flow relation’ you can Associate with). Whatever the change, a solution where we do not need Network and Path elements seems already perfectly doable, with the added bonus that Networking becomes a first class citizen in ArchiMate. In a fully networked world, that is probably a good idea.