Modelling Homogenous Landscapes in #ArchiMate (Classes and Instances)

This post is about two related things: modelling actual detailed architectures of large homogenous landscapes and the class versus instance issue in ArchiMate. Both are closely related. But before I start out, for those unacquainted with Object-Orientation, or Classes and Instances (the notions are strongly related but not perfectly identical) I will give a very short primer on the underlying concepts.

And if you are new to ArchiMate, please skip this post, it contains non-standard ideas for ArchiMate and it will probably only confuse you; the language is really not that confusing if you learn it first (e.g. by reading the book).

A short “Class/Instance” Primer

A Class is the name generally used in IT for `a type of thing’ as opposed to `a thing’, which in IT is called the Instance. In natural language, it is not always clear from words or syntax if a Class or an Instance is meant, though sometimes there are strong signs. The use of the pronoun ‘the’ is more often connected to `a thing’ while the pronoun `a’ is more often connected to a `type of thing’. Compare for instance “Give me the ball” versus “Give me a ball”. The first is almost always a specific ball (an Instance), the latter almost always any ball (a Class), but it may be also one Instance of a Set of Instances. Natural language is a bit fuzzy about these (and other) concepts, we should not be surprised.

But in IT and related disciplines, there is a clearer distinction. The Class Ball stands not for an existing Set of Balls, it stands for the — almost Platonic — idea of a Ball. Now, in IT we’re not as vague as Plato’s famous shadows on the wall (where the shadows stand for the instances of some ideal concept that throws them), we are pretty specific. A Ball, as a Class has properties and methods. Properties are aspects of the ball, such as size, material, colour, and methods are how the ball `behaves’, e.g. you may inflate or throw a ball, inflate and deflate being `methods’ of the ball (not the person in- or deflating it). These methods together form the balls Interface. A typical software engineering example is to have methods for checking if the ball is inflated (isInflated – returning TRUE or FALSE) and inflating or deflating the ball (inflate – using this method inflates the ball, deflate – using this method deflates the ball); the latter methods may change the size property of the ball.

Assuming only inflatable balls exist — and not, say, a cannon ball — we can illustrate the difference between Class and Instance. You can in- or deflate an actual ball — the Instance — but you cannot in- or deflate the concept, the idea, of a ball. Instances are real things, Classes are abstract things. You cannot play real football with the concept of a ball, you need a real ball, an Instance.

Now, to make matters a bit more complicated, we can make SubClasses. We can make hierarchies of classes, as in “a Ball is a Toy”. What we say here is that we have a Ball concept that inherits its properties and methods from the Toy concept. So, if a Toy has a method “playWith”, a Ball, being a type of Toy inherits the method “playWith”. You can play with a Toy and since a Ball is a Toy, you can play with a Ball. The other way around is not true, just because you can inflate a Ball, it does not follow that you can inflate any Toy.

Modelling Classes or Instance or Both

I’ve been known to promote modelling your current state architecture in a large ArchiMate model, it can be a rather powerful tool in the fight to handle Business-IT complexity. The question you then have to answer: do I make an instance model, a class model or a mix? Let me explain. If you build a full instance model, you have to model each and every server, each with his own contents like operating system and so forth. Do you have 200 Linux servers? You have to model all 200 independently. Now, 200 servers is not a big deal (really, in practice it isn’t), but if you have 1500 desktops do you want all of them individually in that current state architecture model? Do you want your current state model be a full CMDB, keyboards, screens and all? Nothing in ArchiMate stops you from doing that, but we all feel that that is really a bad idea. So in my practice, so far, we have modelled all servers individually so we can actually say in the end which process depends on what server et cetera, but for the client systems we have modeled a few configurations. We get away with that because we know these desktops of the same configuration are really completely identical and the conclusions we draw from the model remain trustworthy. These configurations in fact act as Classes in our landscape.

The real server landscape, however, may have a lot of variation. Another large organisation I know of, started out with configurations for servers as well. They found out after a while that there was so much variation, that the number of configurations was almost equal to the number of servers. Besides, at that level, it becomes important to know what instances there are, because even if your servers are identical, they are used by different applications. And without splitting the servers up in real instances, you effectively end up with a model of one big server that runs everything, and that is not the landscape you have, right? After all, there is no problem if two applications cannot run simultaneously on a single server, if you have two identical servers, one for each application. If your model reflects that, it becomes a more trustworthy tool for those kind of analyses.

Of course, you can model with classes only. It is a matter of choice. It is a matter of what you need the model for. Both have merit and ArchiMate doesn’t care, it can handle both. ArchiMate is rather quiet about the issue. You see models that partly employ a `class’ way of looking at things (more abstraction), but then in the same models you then see specific instances of applications. ArchiMate is not very strict about it (one of the reasons why marrying it to UML will be a challenge, I guess).

Anyway, ArchiMate has no specific way to show if an element is an Instance or a Class. You can do both and even mix both. I always advise people to be very careful with choosing between a Class or Instance approach to parts of the model. Mixing them is a prime source of sloppy models that allow for wrong conclusions to be drawn.

Homogenous Landscapes

But there are exceptions, as always. Suppose you run a very tight ship in your infrastructure. You have thousands of (virtualised) servers, but only a limited number of configurations and your infrastructure change and management processes see to it that this remains so. The question  then is: Isn’t there a smarter way to model so you get the benefits of an Instance model (actual conclusions about the real landscape – useful for change initiatives, reporting, et cetera) with the advantages of a more Class-like model, where the same configuration is not modelled a thousand times?

Let’s start with a simple example. Suppose we have a basic Linux server, a configuration that is the basis for all our different server uses (database server, web server, application server, file server, et cetera). We start with a basic pattern:

We use the Node as an encapsulation of our server (as per Sections 1.9 and 7 and the rest of Mastering ArchiMate – Edition II). The picture above shows a basic Linux Server and what it minimally offers is the possibility to run Linux applications. What it also always does is use the Backup service provided elsewhere in our landscape. Please note a few things:

• For ease of reading the models, I have added the words Class or Instance to the (Type) part of the labels.
• I immediately added a bit of complexity to the example: You see that the Node and it contents are Class elements and also the Infrastructure Service it Realises. But the Backup Infrastructure Service is an Instance. There is a single real server in the landscape that runs the Backups and this little model says that every standard Linux Server uses that specific server.
• I have modelled the Node as full encapsulation. While it is the RHEL System Software that uses the Backup Infrastructure Service, I have connected that Infrastructure Service to the outside Node. This makes using the Node as a basic building block later a lot easier as we will see.

Now, let’s introduce a second standard server, again a Class:

What this says is: we have a type of server, the Standard Linux NFS Server, that inherits all the properties and methods of the Standard Linux Server (through the Specialisation relation), but it adds that it Realises a NFS file server as well. Since Linux comes equipped standard with NFS, we do not need to add extra System Software for this, as we would have for — say — an Oracle database server running on Linux. Let’s add that application execution Infrastructure Server that the basic Linux server Realises to the picture:

Since the NFS server inherits all the methods and properties of the Basic Server, we know that an NFS server also is an Application Execution server; shown as the red Realisation relation in this picture:
Here we encounter a first `problem’: According to ArchiMate, you cannot use the blue Specialisation and Realisation relations to derive the red Realisation relation. Which is quite strange as it obviously makes perfect sense, but for now just one of the quirks of ArchiMate’s somewhat messy relation derivation algorithms. We might fix that if Specialisation would become part of the derivation algorithms, but let’s not decide too fast that that is a good idea.

If we add the Backup service Instance, we get:

Again, we know that the orange Used-By makes perfect sense based on the blue Specialisation and the green Used-By. If we would allow this derivation we would run into ArchiMate’s idea of a direction of relations. You are only allowed to make derivations if the route exists of relations all in the same direction, but what direction does Specialisation have? For the Realisation it needs to be from child Class to parent Class, but for the second the other way around. And making it bidirectional creates havoc: the standard Linux server starts to provide the NFS service. Clearly, the derivation mechanism of ArchiMate cannot cope with reality here.

There is, however, a simple solution. We can use the concept of inheritance that is after all a hallmark of the idea of Specialisation. We can say that Specialisation in ArchiMate means that the child Class element inherits all the relations of the parent Class element. This is perfectly OK with abstract data types and object-orientation. So, we could add a third derivation mechanism in ArchiMate:

Any endpoint of a relation at a parent of a Specialisation relation is assumed to exist at every Specialised child element

We could say it less strongly and say that you may move the endpoint of any relation from the parent in a Specialisation relation to its child, thus making it a true derivation. The exact wording can probably best be left to a committee.

Now that we have set up a structure for SubClassing, we have to look at the relation between these Classes and actual real Instances (models of the actual reality of the organisation). Let’s look at an attempt using only existing ArchiMate relations:

Here, I have instantiated two real NFS Servers Instances from the NFS Server Class. I have not used Specialisation because that is not what I am doing. I am not specialising the NFS Server Class, I am instantiating it. ArchiMate has no relation for that, and you sometimes see people using the Specialisation relation for this. I think that is a bad idea, those Instances are not Classes. It is closer to reality to say that the Class is a kind of Set, the Set of all Instances. And aggregating elements in a set is the job for the Aggregation relation. This solution also allows valid derivations, e.g. we can derive that the real Backup service is used by each real NFS Server.

Now we, as intelligent humans, know that the Class version of the NFS Infrastructure Service gets instantiated with the Node in its own Instances. In fact, this must hold true for each element that makes up the Class version of the Server, including for instance the Infrastructure Services being Realised. There can be no real support for this in ArchiMate itself, I suspect, but tooling could provide support for this.

But what if ArchiMate would have a true Instantiation relation? We could draw a model like this:

As you can see, I have invented an Instantiation relation for ArchiMate, the arrow that ends in a double arrow head. The blue relations (two Instantiations and one Realisation) and the red Instantiations could automatically provide the orange  Realisations. From the Instantiations we can infer that the Realisation relation in the Class pattern must be replicated for each Instance.

I’m ending this `thinking out loud‘ exercise by adding the Backup Infrastructure Service Instance to the picture. Since the Class version of the NFS Server uses this service, we can infer that each actual NFS Server that has been instantiated from the Class also uses the backup service.

What is the advantage of all this work? Well, suppose you have to model 500 identical copies of a standard Windows Server, and you know that changes to the setup will happen to all instances more or less simultaneously. Then, you only have to model one Windows Server in Full (maybe 4-5 elements in a Node) and for the rest use only an empty Node representing that same complexity. And if ArchiMate or tooling would allow the passing on of relations from Class to Instance patterns via an Instantiation relation, analysis would probably become rather easy, irrespective of the levels of SubClasses you have created. But that is fantasy for the moment.

A warning is required here: this is not a final proposal to model homogenous Instance landscapes, nor a final proposal to change ArchiMate. This is thought in progress. But fun to do.