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:

The role of Aggregation and Association in relation to a Network element

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:

Fragment of Example 30 of the ArchiMate 3.1 Standard in the Mastering ArchiMate colouring scheme

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?

Modelling a Network as just another a Node

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):

Modelling Path as a Flow relation that is using the LAN. NOTE: the red Serving relation is not valid ArchiMate 3.1

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):

Associating a Node to a Flow to signal it contributes to its existence. It is not clear if this is valid in ArchiMate 3.1.

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

Modelling Path as a Flow relation that is Realised by the LAN. NOTE: the red Realisation relation is not valid ArchiMate 3.1

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.


  1. Hi, some comments:

    Association from relationship to any kind of element is of course permitted as stated in 5.2.4 : “An association relationship is always allowed between two elements, or between a relationship and an element.”

    Communication Network can no more (directly) aggregates a Node because in 3.x Node can also be a physical element. That’s the “still to be cleaned up issue” with Node being both a “type” and a “super-type” at the same time.

    FWIW, I do use Communication Network and Path in my models. I can see several use-cases of the latest, one of them being to model Kafka topics (Kafka is then a System Software aggregated by the “topic” Path).



  2. As usual, there’s a lot in your post to dig into. I’ll add my two cents (or actually three). And I will also include a warning to any reader: you may find the content of my post controversial and it might impact your blood pressure. If so, I would suggest to post a juicy reply as therapy.

    1. Networking has become a commodity. Gone are the days we had to design bridges and hubs, we simply take the internet for granted. Sure, it is a complex network of cell towers, cables, repeaters, bridges, routers, what have you, but from an architectural point of view, this is hardly ever relevant. I compare it with transporting goods from a distribution center to a store by a truck. It doesn’t add much to include roads, bridges, and traffic lights in the logistics model.
In my own ArchiMate models I tend to tend to include the Internet, Intranet and DMZ as an infrastructural service on the background of my diagram. It encompasses the infrastructure and the services to provide it to its users. That’s easy to explain. And there is hardly ever a need to dig any deeper.
    It’s also semantically more elegant, I believe. The entire internet represented as a “Node” seems awkward, but a service is quite natural.

    2. With the cloud, and especially cloud native architectures, network services have become virtualized and defined from software. Software defined infrastructures are a great way to bridge the chasm between software and infrastructure (compute, networking, and storage). Basically, resources are no longer a constraint in creating great designs. And integrated CI/CD pipelines are making DevOps a reality. Actually, providing complex software systems with zero unplanned operational activity is already happening. I’ve said it before, software is eating the world of IT.

    I wholeheartedly agree that many enterprise architects seem to be by and large unaware of what’s happening in infrastructure and at least fail to think through the potential impact on the architectures they’re designing. Massively distributed architectures are easier to create than ever. Understanding the different communication and integration needs of software components is essential to create a viable distributed design. Understanding the constraints and possibilities of multi-regional distributions and distributions across multiple availability zones is equally essential. Multi cluster clouds are coming, and will open up a new business model for IT services.

    3. As ArchiMate community, we find ourselves stuck in old-school thinking (I did warn you, did i?). The world of IT is in the midst of a transition. Not only is the borderline between our “green” and the “blue” worlds disappearing rapidly. I at least find it hard to explain the difference between an “Artifact” and a “Data Object” in the “Buckets” of an object store such as Amazon S3. I would argue that, given the digital transformation that is taking place, the borderline between “blue” and “yellow” is equally fading away. Frequent software updates have become a unique selling point for Tesla cars. APIs have become the new language of doing business. Value streams are being digitized. And we have to discuss the fundamental difference between a “Data Object” and a “Business Object”?

    So, rather than discussing superficial changes to the ArchiMate meta model, I would be interested in a more fundamental rethink. Scratching the surface will not close the gap between the old-school thinking that gave us Service Oriented Architectures and ArchiMate, and the Cloud-Native designs we should be engaged in today. It’s either that, or wait for an outsider to come and disrupt us. After all, this modernization is already overdue.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: