The Dutch are well known for their knack of speaking foreign languages. This seems to be obvious. Where in many countries, people just speak a single language, seventeen million Dutch, living in a small country (with two languages, even, the second being Frisian which is spoken by a couple of hundred thousand inhabitants), and engaging in trading a lot, need to speak their foreign languages very well to be able to function. This, however, is an urban legend. Most Dutch stumble around when trying to express themselves in another language and what most of them do is produce a hash of Dutch grammar and words that are ‘anglified’ or ‘germanified’ or just throw in foreign words in some sort of jumble. As friendly foreigners still understand what they try to say, the illusion remains. Yes, this post is about ArchiMate, bear with me…
I found it particularly funny a while back that someone in a meeting with Dutch and American participants kept talking about ‘cow handle’. What he meant was ‘bargaining’ or its close English alternative ‘horse trading’. In Dutch it is ‘koehandel’ (cow = koe, trading = handel). All the time I was wondering if the native English speakers had any idea what he was talking about and trying very hard not to imagine the ‘handle’ of a cow and what ‘handling’ of it would entail (especially in the loose, sex-neutral use of the word ‘cow’). But I digress.
The upcoming Edition II of Mastering ArchiMate will contain patterns and examples for Hardware Virtualisation (e.g. VMWare, Parallels) and Application Virtualisation (e.g. Citrix). After I had written these down, I ran into another way of modelling these. And I noticed they would make a nice next subject for another ‘what is wrong with this picture’ blog post. Here they are:
Hardware Virtualisation Pattern Proposal:
Application Virtualisation Pattern Proposal:
And the question of course is: “what is wrong with these pictures?”. There will be a prize, related to Mastering ArchiMate Edition II. I cannot tell exactly what prize yet, as the whole sales/download/etc. setup has not been finalised yet. The person who gave them to me is not allowed to participate.
PS. Agreed, I am too harsh on my fellow countrymen, stating they speak foreign languages hardly and badly. They are on average probably better at it than native English speakers, who never have to switch language. Native English speakers only have to live with others murdering their mother tongue 🙂 . Furthermore for the record: The Kingdom of The Netherlands has four languages that may be used officially, next to Dutch and Frisian (in the province of Friesland), English and Papiamento may be used officially in the Dutch Carribean islands.
Here are some hints: For the first diagram: what does Assignment mean? For the second diagram: what do the derived relations stand for?
[Update 23/Mar/14 – The Solution]
Let’s start with the hardware virtualisation pattern:
Most people look at Node as something that is ‘higher up the dependency tree’ in a model than System Software, mostly because the abstract Node element is often used to Composite System Software and Devices. As such, they tend to interpret the Assignments on the right hand side as running in the wrong direction and see that as the problem. But the truth is worse: ArchiMate actually does not allow the Assignment relation between two System Software elements and it also does not allow it between a Node and System Software. The Assignments on the right hand side are not just running in the wrong direction, they are illegal. In other words: problemo numero uno is that of the 6 relations actually shown in this pattern, the yellow 4 are illegal 🙂
If we suppose they would be allowed — say allow Assignment from System Software to System Software with a ‘runs on’ meaning — the direction of the Assignments would become ambiguous.
The second problem is that the modellers used two machines in the pattern. They thereby mixed up their virtualisation idea with a clustering/farming pattern. Most basically, the virtualisation pattern should show how we create multiple virtual devices on a single real device. But here, they have modelled two real devices. The pattern is, let us say, not very ‘pure’. Possibly as a result, they are not really coherent in their choice of object/class modelling (always a problem): why, for instance, is there only one Virtualization Software (System Software) and two Operating System A (System Software) elements? Operating System A runs on both Devices and is shown twice (an object approach), but Virtualization Software also runs on both Devices, somehow but is only shown once (a class approach).
There is an interesting story behind the mistake with the illegal relations, and it starts during the days of ArchiMate 1 (and even before that). The original ArchiMate differed in the metamodel for infrastructure. It looked (partly shown) like this:
I am using the original (and Mastering ArchiMate-style) colouring here to show the type of element: blue for active structure, yellow for behaviour, and green for passive structure. System Software. As you can see, originally, System Software was a behavioural element. The whole setup was however messy, e.g. having a behavioural element as Specialisation of an active structural element is quite ugly.
In ArchiMate 2 this was repaired and it became:
As you can see, the Infrastructure Function was introduced and System Software became an active structural element. What they did not do, however, is remove the Assignment relation between Device and Node. Now, in ArchiMate 1, this Assignment had a clear meaning: any Assignment between an active structural element and a behavioural element means performs. But what does this Assignment between Device and System Software mean in ArchiMate 2? The Standard just says that it is allowed, but — other than with other Assignments — it remains completely mum about its meaning.
(It was probably retained for backward compatibility. The difficult choice between forward innovation and backward compatibility is often encountered. As far as I am concerned, people in IT often underestimate the price paid for backward compatibility even if obvious problematic examples (DOS/Windows – Cough!) are well known. But I digress. As usual.)
Now, if you model a real object type of model, and you do not Composite Device and System Software in a Node, you get something like this:
System Software has become the active structural element that performs (A) the Infrastructure Function behaviour which Accesses (B) the passive structural Artifact. The original Access (C) from ArchiMate 1 remains as derived relation of A and B. The Artifact can be Assigned to both Device and System Software. In this example, I have modeled a file that resides on the Device and is Accessed (derived) by the System Software. We could have modelled an Artifact Assigned to System Software instead, which would result in the somewhat mixed-up situation that from System Software to Artifact run both Assignment and Access relations. There is more about this in the book, but personally, I think it would be good to remove the Assignment between Device and System Software from ArchiMate’s metamodel and use Composition for object-type models (if you destroy the Device, you also destroy the software on it) and use Aggregation for class-type models (if you remove a Device from your landscape, the software class still exists as it can be installed on other devices.
For my solution to the virtualisation pattern (and the farm pattern, for that matter) you need to wait for the second edition of Mastering ArchiMate which will be released any day now.
Moving on to the application virtualisation pattern, the problem I see is this: what does the Used By from the Infrastructure Interface to the Business Role stand for? It is obviously a derived relation (as always a reliable source of confusion if used indiscriminately), but a derived relation from what? The most direct route from Infrastructure Interface to Business Role is via Application Component and Application Interface. Which Application Component and Application Interface are we talking about here? Well, clearly, what we are modelling here is that the role uses our System X. What happens if you build from that knowledge and model without derived relations, you get:
This is not perfectly laid out (I have kept the original lay out as much as possible). A lot of complexity and detail (and we will get rid of this, below), but here we see how the application uses the Citrix environment to offer its service and interface to the business. The business uses the application, not the infrastructure. I have added as an extra the orange Used-By. This is a direct relation that is allowed in ArchiMate 2 to show that an active structural element uses a service, which is handy if you do not model the service and which allows deriving relations along that route. This used to be derived relations in ArchiMate 1, but ArchiMate 2 turned Assignment into a one-way relation. This removed some very silly derived relations, but it required retaining some of the more useful ones (such as this one) as explicit direct relations and these were added ad-hoc to the metamodel.
If I want to remain as close as possible to the original pattern and remove the problems, I get something like this:
The red Used-By is a direct relation of the ‘ad hoc metamodel addition’ type mentioned above. The orange is either a derived relation from Application Component via Application Interface (not shown) to Business Role, or it is derived from Application Component to Application Function to Application Service to (ad hoc, also) Business Role.
I wonder why the modellers sometimes want to show a service (infrastructure layer), and sometimes not (application layer). By showing both in the infrastructure layer but only showing active structure on the application layer, the routes come together as two Used-Bys to the Application Component representing the same dependency. If we clean that up we get:
Quite simple and correct in my view. Following my own patterns (I prefer the behavioural column over the active structural column for relations between layers — incidentally this intuitive choice has turned out really well now that I have connected BPMN models to ArchiMate models), you get something like this:
This was it. The winners:
- Carl Seghers for spotting problems with the Assignments on the right hand side of the virtualisation pattern;
- Jean-Baptiste Sarrodie for spotting the ‘missing’ Assignment between the infra service and the infra interface and the conclusion that it is difficult to conclude that the business uses the application;
- Nicolas Figay for his analysis of application virtualisation being a misnomer (it is the user interface hardware that is offered in a virtualised way to the application) and seeing that as the problem of the application virtualisation pattern;
- Grant Harmer for spotting the problems between the two Operating System A systems and Virtualization Software and for spotting the trouble spot of Assignments between Virtualization Software and their connected elements.
All four will receive a free electronic license for Mastering ArchiMate Edition II or a cash back of my compensation if they buy Edition II in print.