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, modelling 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:

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

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

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

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

Conclusion

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.