Reusable Infrastructure Modelling Patterns (2)

In the previous post, Reusable Infrastructure Modelling Patterns, I discussed the creation of reusable patterns to more effectively model large homogenous parts of the infrastructure landscape, or in other words: if you have 1000 identical RHEL servers, dbmodelling the structure of each of these individually is not what you would like. The post contained a quiz with two questions. The answers and my proposed reusable pattern solution is given in this post. Warning: like the previous post this is not ‘beginner ArchiMate’. So if you’re new to the language, don’t get scared away by this complex story.

Let’s recap the questions. First, have a look at:

FinalSolutionStep2The question was: “The derived Realisation relation above is unproblematic. But the Used-By to the encapsulating Node is problematic. Can you see why?” Paul Goes gave the correct answer first: The orange Used-By from [winsv099] XYZ License Distribution (Infrastructure Service) to the [winsv002] SAS Execution (Node) leads not only to the correct derived relation from  [winsv099] XYZ License Distribution (Infrastructure Service) to [winsv002] XYZ License Manager (System Software), but also to all the other composite parts of the Node, such as the [winsv002] .Net Framework 4.5 (System Software), which plainly is absurd. It is a nice example of the problems with derivation.

The second question was about a possible solution. In the expanded view:

FinalSolutionStep6The question was: “There are a few problems lurking here with a common cause. Which ones?” Jean-Baptiste Sarrodie and again Paul Goes answered in the right direction. They pointed out, correctly, that by using [StandardImage] Win2k8R2 Server (Node) in all these specific Nodes, there will be senseless derivations, e.g. A Used-By from a (not shown) [winsv001] x86 (Device) to [winsv002] SAS Runtime (Infrastructure Service).

I called that ‘a step in the right direction’ because it is not the entire story. The fact that we can make these derivation does not mean that we have to. We have enough information in the model to exclude that senseless derivation: there is no Aggregation between [winsv001] x86 (Device) and [winsv002] SAS Runtime (System Software). So, we can use the Aggregation between Device and System Software to exclude all the senseless ones. Take the following pictures:


The first picture shows in red the relation that we want. The second picture shows the red route that we do not want. And we can use the fact that we do not have  an Aggregation from [winsv002] x86 (Device) to [winsv001] WebServer Runtime (System Software) to exclude the ‘false’ derived relation.

In fact, in  the model as shown in the view above, we do not need to go via the standard image at all, we can just use the Aggregation (but then the result is not Used-By but Realises).

There are other problems as well. For instance, suppose our Standard Image also Realises a service? In our example, that could be for instance [StandardImage] WinServer Program Execution (Infrastructure Service):


And suppose that service is actually used by Application Functions. Then we do get those senseless (and now unavoidable) derivations between many Devices and many applications:


And a third problem: not all servers that have the (installed by default) XYZ License Manager also use the [winsv099] XYZ License Distribution (Infrastructure Service).

The common cause is: we are mixing class and instance in a single model in a way that does not make it clear which is which. The problem of an Infrastructure Service that is Used-By the class can of course be solved by adding yet another Used-By to our model, but only for every instance that actually uses the license manager (in red):ASolutionForMixing1

(I’ve added the standard program execution Infrastructure Service, and a multiple-path Realisation, in orange, as well). Sadly, though, the added orange Realisation does not solve the problem of the applications being related to the wrong Devices or Nodes:

ASolutionForMixing2The red Used-By and the orange Realisation together create a route that is syntactically OK for derivation but is not true. And in this case we have no way to exclude it by using other relations in the model.

No price awarded this time, as a complete answer on both questions was not given.

Anyway, the essential choice of my ‘solution’ was already present in that previous post. Instead of directly using the class-like element directly as Composite/Aggregate child of a Node, we can instead explicitly model class and instance differences. As ArchiMate does not have a relation for that, we use Aggregation (which is not completely daft, as many modern object-oriented environments have classes that are objects themselves). I personally think that using Specialisation for instantiation is a worse solution, aesthetically (who knows, some day someone may say “Uncle Gerben wouldn’t like that” and if not dead already I would probably die laughing, but, I digress).

An example with a single ‘class’ (the reusable pattern for the Win2k8R2 image) and a single instance based (in part) on that image then becomes:


(I will discuss the optional coloured Used-By’s below). Just a quick calculation: if we model 1000 servers that are based on a single image like this, we lose ±2000 elements out of ±8000 and ±3000 relations out of 17000 (in this case). Depending on the complexity of the re-used pattern, this might be more. Note:

  • I’ve added an Aggregation between the class/instance Infrastructure Services as a mirror of the class/instance Aggregation between the System Softwares. I assume by now it is clear why;
  • As the .Net Framework and the XYZ License Manager are both part of the the Standard Image (the class), they are not modelled separately in the instance (winsv002);
  • As a consequence, suppose the SAS Runtime would use the XYZ License Manager, we cannot see that relation anymore, because XYZ License Manager does not have a representation at instance level;
  • We have no way to model actual use of the [winsv088] XYZ License Distribution (Infrastructure Service) by an instance like winsv002. We only can deduce potential use (via the Aggregation and the orange Used-By, in a more roundabout way by going via the internal structure of the standard image and the black Used-By. If we want to be able to deduce from our model if an instance like winsv002 uses XYZ License Distribution or not, we have two options. Either we add the red Used-By for every instance that uses XYZ License Distribution, but then we still do not have the option to make specific what on the inside is using XYZ License Distribution. Or we decide that XYZ License Manager must be outside the reusable pattern, because we want to be specific about its use. Then we get this:



Re-use and still being able to do proper analysis of a model is not that easy. As always, as soon as we abstract, we lose something. And thus we must be very explicit about our intended use, because abstraction is ‘consciously leaving out detail’ (instead of just ‘ignoring detail’. For more on this see Chess and the Art of Enterprise Architecture). Which means that I cannot really present a ‘pattern’, but only a ‘pattern for a pattern’. You must decide what you want to be able to be specific about.

It would be best if we had tools where the layout of a certain fixed pattern could also be created in a standard way. That way, we could for instance load a CMDB into an ArchiMate model in a certain way and automatically have proper visualisations next to analysis, without a truck load of layout work for the poor architect. But in that sort of high level usability, no tool currently offers a solution as far as I know. There are more ways that I can think of for tools to improve for the modelling of large landscapes (instead of the usual toy-sized examples that are given). But that is maybe a subject for another time.



  1. Hi,
    I was wondering how to model a BI suite in archimate.

    My customer has implemented various BO universe accessed either through webI or Rich client.

    My aim is to realize an applicative cartography. I’m fine with every application except BI (Business Object & SAS).

    Should I :
    – consider each Universe as an application (an instance of BO meant to deliver reporting services) that deliver reporting & analysis services through 2 interfaces (1 web for webI & the other for rich client) that collaborates with my App ?
    – Consider BO XI to deliver infrastructure services (reporting & analysis) used by My App ?

    Thanks in advance for your help.


    1. This is slightly off topic for this post as it is about the question when software should be modelled as application and when as platform (system software). This is one of the more difficult issues when modelling in ArchiMate.

      For me, it always depends where the business-specific IT-logic is. If a ‘Universe’ contains specific IT-logic for your business, it is an application for me. I never use Collaborations, but if I understand your situation will then I would expect these to be applications that are used by other applications. That doesn’t mean BO cannot also deliver infrastructure services. In the book there is a section on complex application stacks (such as SAS) that contain both applications and platforms in a single package.

      Frankly, the BO Universe (as far as I know) is a virtual data object that under water is created by actual logic (i.e. SQL). So, you could model the logic that creates the Universe as an Application Function that Accesses (writes) the Universe (Data Object) and the user of that Universe is an Application Function that also Accesses (read) the Universe (Data Object). You can do that with or without modelling a service that represents what the Universe does for the end-user application. I am not a BI expert and not familiar with BO, so I might understand the situation incorrectly.


  2. Hi, in the previous/lead-up article you wrote “If ArchiMate 3 will allow Assignment from System Software to System Software… ” and boom here is 2018 knocking on your front door 😉

    I was wondering what your insights on this subject currently are, specially with Archimate 3’s new possibilities. Working on a SOA model, and looking for the best way to implement the repeating middleware technology services.
    Best regards,


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 )

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: