Modelling Information Flow In ArchiMate

With regulation such as GDPR being in force to protect our users, properly understanding information flow becomes essential. This blog shows some of the ways we can model information flow.

An Overview

There are a couple of different ways we can represent information flow that I touch upon in this blog – I would suggest you use the technique that you prefer but be consistent with it. I don’t normally use more than one method in a model package, unless I have a specific reason to do so.

Using Flow Relationships

I will start with a layered view like have used on several other blogs – our web hosting service serves as a practical example.

Figure 1 – Layered View

The layered view contains both internal and external elements – we will look at them separately. Although Figure 1 shows a layered view I might use to communicate the big picture, as it stands it would need some more detailing before I can fully map information flow.

Mapping Service Flow

In order to properly understand the flow of information between services we need to establish the service interfaces. If my layered view doesn’t have interfaces on – I need to consider and add them. In the example above we have at already done that between the business and application levels – you can see that in figure 2:

Figure 2 – Services and Interfaces

The first thing I will do is look at anywhere the interfaces are serving another element:

Figure 3 – Focusing On Serving relationships.

These areas are effectively where external information flow is happening. I will be looking to replace these serving relationships with flow relationships. In this view i would possibly make an exception though. The service relationship between the HTTP interface and the website hosting interface tells me that there is a relationship between the two. I might normally look further into detailing out the web hosting service to determine how the HTTP interface is used, but in the case of the view above I have answered the question already – its serving the incident management process.

Some architects do not model interfaces against services all the time – myself included. Its dependent on a number of factors; I want to do “just enough architecture”. If we took the interfaces out of the equation we can still map information flows from services to other services.

Considering other relationships

I will also consider the realization relationships in the same way as I look at serving relationships – in this example though I have only an application interface realizing a business interface. the business web portal is only exposing the application layer functionality and there’s no actual data transfer between the layers to consider. Sometimes association relationships should also be looked at.

Putting the flows onto the diagram

Once I have identified the relationships i am interested in I then start to put the information flows onto the diagram. and thinking about information flows. I reorganized the view a little because I decided its not enough to understand which process has access – I want to also understand which role. I then removed the serving relationships from the view, but I didn’t delete them – they are still valid for other views.

The result was this view

Figure 4 – Flows in a layered view

I have labeled the flow arrows, but do not forget that each relationship can also have documentation – where you can further specify what that information means. When looking at application level interfaces, I might want to also think about specific ports we use – and I may either show it on the actual view or in the documentation for the relationship. I chose to not show ports on the view above because I don’t want to turn my ArchiMate views too technical; in some cases depending on who your stakeholder is you may want to do things differently and include the port numbers on the labels.

Breaking things down

I broke my initial diagram into two parts to make the blog a little bit less cluttered as I focus into part of it, and that’s ok. In the same way as I have now shown flow between business and application layers, I could do the same between the application and technology layers. To keep diagram complexity down sometimes we break things into smaller chunks. The initial layered view showed how they all fit together at the highest level.

Identifying issues

Doing this information flow exercise highlighted some design issues. The second I came to create a flow from website support to the HTTP interface I realized I should be using HTTPS. I could either change that element (which effects the whole model) or I could establish a second interface.

Because in this modelling exercise I am focusing on information flow between elements other issues come up too. For example – when I am looking at the website support role – I ask myself the question what if the HTTP interface into the website application service isnt enough to diagnose a problem? In the old days I might add an Remote desktop Interface – but if I am using third party cloud providers to provide the underlying service this might not be an option – instead I might define a separate special admin interface.

These questions came up just through looking at the information modelling on a layered view. Information flow could also be shown on a whole range of other views. When you actively focus on different component parts of the view and their relationships, thinking in terms of what kinds of relationships fit and why, we quite often see new things.

Associating Passive Objects

Figure 4 could have been written another way:

Figure 5 – Layered view with passive elements.

Here I created some passive objects – (Business objects & data objects). Doing this has an advantage over flow relationships – if I am reusing elements in different views then I can easily get an understanding for example where Admin Login Credentials are used throughout my model.

You may have noticed I have web pages as a business object and an data object. That’s because conceptually in the view they are at two different levels. at the business level web pages are a concept, but they are made more tangible at the application layer.

Another important thing to note is that some of these relationships do not denote the direction of information flow. For example – the HTTP interface is Serving Website Support – this does not mean that admin credentials are flowing from the HTTP interface to the website support role.

Information Location

I can easily add Locations to my view to make it a bit more complete from a GDPR perspective:

Figure 6 – Layered View With Locations

Normally those elements are orange, but for me that’s a complete aesthetic color clash so i changed it. There’s nothing in the ArchiMate rule book that says you cannot do that!

Modelling Internal Information Flows (and Application Cooperation)

In the same way as we can show information flows on a layered view we can do the same thing on many other views – such as service realization views, technology views and so on. Remember sometimes we might want to have two viewpoints showing the same things in different ways for different stakeholders. We might have a normal service realization view, and one for GDPR compliance work. We can use exactly the same approach as i showed on the layered views with most other views. I would take copy of the view and start removing relationships from the view (not the model) replacing them with flows.

With regards to application cooperation views, they can be done at different layers of detail dependent on need. the best application cooperation views include processes, events, interactions and services. They do not include interfaces and are internal views. As a bare minimum I would expect to see interaction between application components and the services – as an example:

Figure 7 – Basic Application cooperation view with information flows.

Figure 7 doesn’t really show the cooperation! I am focusing on data flow rather than any causal relationships and elements. This works as a starting point. I have seen some architects do variations on figure 7. Some people like to emphasize the more important information flows.

Other architects do not include what they consider to be less important flows, and produce more abstract views. For example the web page request – is a good example of low level communication that is essential to a low level view but may not be important if we are trying to provide stakeholders an overview.

Personally I like the level of detail in figure 7.

Using Access Relationship.

Where accesses relationships are possible within different views they should be used if those views are for presenting information flow. The access relationship is a data dependency relationship in ArchiMate. its indicating that a process, function, interaction, service or event does something with a passive object.

Using The Path

The Technology layer has an element for representing flow of information – the path. Take a look at figure 8:

Figure 8 – Web Data Transmission

You can see here I have represented the path information takes to get from the web server to the end user by creating a Web Data Transmission path. Note that the two end points are not considered to be part of the path. This is because the path denotes to path from end to end – when we reuse the Web Data Transmission element we are likely to want to use it to convey transmission from many different end points.

Summing it up…

Most views can be remodeled to include information flow, and going through the process of doing so will enhance your understanding of information flow and risk.

I focused mostly on business and application layer within this blog but the same practices apply when working with the technology layer

When doing High Level Design Work as a minimum I like to see either the basic information flows in the application cooperation views, or information flows in the layered view.

Having these information flows enables us to ensure compliance to different regulations and gives us the ability to do some very cool things with risk management.