ArchiMate Communication Paths

1,076 views
Skip to first unread message

nick.h...@silvercode.co.nz

unread,
Jul 16, 2017, 8:42:24 PM7/16/17
to ArchiMate
Hi All,

I suspect I may be trying to force ArchiMate to do something it wasn't intended for - but hopefully someone can provide some guidance as to whether this is valid. 

One of the viewpoints I often have to provide is the communication paths that are required to connect two (or more applications) as part of a wider solution.  This would generally be provided as a high level view to the infrastructure/network teams to as part of an early solution proposal in order to give a view of the communication requirements within a solution.  

What I've settled on recently is something like the following.  I find this works well to present the viewpoint - but I'm keen to hear if a) I'm technically not using either the Communication Path or Communication Network elements correctly, and b) whether there is a better way to demonstrate this concept while still keeping the viewpoint simple?  

Thanks, and Kind Regards,


Nick Hoggard


nick.h...@silvercode.co.nz

unread,
Jul 16, 2017, 10:29:46 PM7/16/17
to ArchiMate
Hi All, 

Having done a bit more reading on this, I think I've got the relationship between a Communication Network and a Communication Path a bit backwards.   Reading the spec again it appears that the intent is for the Communication Network to realise a Communication Path, as opposed to being a source/destination in it's own right.  

I assume the way this is supposed to be depicted would be similar to the following;

In this diagram;

  • The source/destination for the Communication Path is now a Device (realizing Node), rather than a Communication Network
  • Each device is associated with a Communication Network, to indicate the network the device is connected to.
  • Each communication path (shown as a relationship) is realised by a Communication Network.
Simplifying this view a little to remove the network devices devices (proxy etc), would it be more correct for the diagram in my original post to be something like the following?



Is this interpretation more inline with the standard?

Thanks, and Kind Regards,

Nick Hoggard

Jean-Baptiste Sarrodie

unread,
Jul 17, 2017, 2:01:59 AM7/17/17
to ArchiMate
Hi,

I have several remarks, but the most important one is that for your need you don't have to use a Path: just use a Flow relationship. A Path should be use when there is some logic inside the Path itself, and that logic doesn't really depend on devices/nodes that are connected to him, but instead depends on the devices/nodes that are aggregated inside, in addition of communication networks that realize it.

For this reason I would consider your latest diagram the best, with the following changes:
  • "HTTPS" is a Flow relationship
  • Association between Devices and Application Components should be either a Realization (if the Application is deployed on the Device) or a Serving (if the Device provide some Technology Service used by Application)
Regards,

JB

nick.h...@silvercode.co.nz

unread,
Jul 17, 2017, 2:35:41 AM7/17/17
to ArchiMate
Hi Jean-Baptiste,

Thanks for the quick response and guidance!  I hadn't considered using a flow in this case as (incorrectly) in my mind that was more related to a data flow than traffic flow.    I've updated my diagram based on your feedback.


I realise it's a digression from my original question, but I'm a little interested by your description of the relationship between Device and Application Component - how does the 'realize' relationship get derived?  

Thanks!

Nick Hoggard

Jean-Baptiste Sarrodie

unread,
Jul 17, 2017, 4:40:44 AM7/17/17
to ArchiMate
Hi,

I realise it's a digression from my original question, but I'm a little interested by your description of the relationship between Device and Application Component - how does the 'realize' relationship get derived? 

Device AssignedTo Artifact Realizes ApplicationComponent

Regards,

JB

Nick Hoggard

unread,
Jul 17, 2017, 5:19:31 AM7/17/17
to ArchiMate
Thank you, that helps a lot.

Mastering ArchiMate

unread,
Jul 17, 2017, 5:23:32 PM7/17/17
to Jean-Baptiste Sarrodie, ArchiMate
I agree with JB. In ArchiMate 3 a Flow (with Associated data for instance) is much more handy that the Communication and Path elements (which IMO are rather useless for networking). I’v been working on developing pattern for this.

G

--
You received this message because you are subscribed to the Google Groups "ArchiMate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-archimate-f...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-archimate-forum/a61b8f38-5b6f-4479-a8d9-290fdcf0b5e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Peter Kelley

unread,
Aug 3, 2017, 2:42:19 AM8/3/17
to ArchiMate
The way I look at it is that paths connect nodes and networks connect devices. If you are happy to work at the node level then use paths. If you want to model which network segment a device connects to then use a network. This gets complicated by the fact that people refer to a network when in Archimate what they mean is a path. XYZNet may be a domain and a "network" to non-modellers but it is really a collection of connections between devices.

I may be wrong but this seems to be working for our team so far. 
Reply all
Reply to author
Forward
0 new messages