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.
[Update 12/Mar/14]
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.
R&A IT Strategy & Architecture 
Hi Gerben,
Speaking of a cow handle, you might enjoy the site http://nengels.tumblr.com, which explores how dutch and flemish people are being creative with the English language. Come that against! 🙂
Regarding your diagrams, it seems to me that the assignment relation between the Virtualization Software and the Virtual Nodes goes the wrong way. As depicted the virtual node ‘executes’ the virtualization software, whereas in reality it is the opposite of course: the virtual node is an ’emergent property’ of executing the virtualization, so one could say that the virtualization software executes the virtual node, but that relation is not allowed. Or one could say the virtualization software realizes the virtual node, but that relation is not allowed either. So it seems the only reasonable relation between the two would be used-by: the virtual node uses the virtualization software.
Also, for me a device would be a physical thing, so not to be used to represent something virtual. We have the node for that.
Greets,
Carl
LikeLike
There is something in that area, but it is worse 😉 and there is more, also in the other diagram.
LikeLike
Hi Gerben,
For the first one I can’t say anything, but the 2nd is new to me, can I play ?
LikeLike
Sure.
LikeLike
So I would just say that:
* (funny) The infrastructure Interface is not assigned to “Application Virtualization” Infrastructure Service, making it impossible to conclude that the business role use it.
* (bad) there’s no relation between Application and Role so if the idea was to say that the virtualized application is used by someone, that’s wrong.
* (worse) here the used by between interface and role is a derived relation. The only reasonnable meaning is: Infra Interface assigned to Infra Svc (not “Application Virtualization” as said before) used by App Func Realizes App Svc (both not related at all to “System X”) used by Process used by Role. So what the view says is that the role that use the process also use the interface but I guess the goal was to say that role that is assigned to the process was using the virtualized application in the context of the process… not exactly the same message.
LikeLike
Well spotted.
You touch on a couple of the issues of the second diagram. For your third point, your analysis of the derived relation is not what I should do. You can stay entirely in the ‘active structure’ column. And you definitely want the role to be assigned to a business process (which requires the application), not using it which adds an undefined an unnecessary role.
LikeLike
“What is wrong with these pictures?”
Isn’t it obvious? They were not produced in Archi.
🙂
LikeLike
Since Archi doesn’t implement A.1 Core Concepts and Relationships of the spec. connecting a Infrastructure Node with a Application Interface by Magic Connector and get this particular relationship is impossible. You need to either connect it to a infrastructure interface, and both relabel and colour them all blue, or use Viseo/Omnigraffle. The added benefit of a tool like Archi is relation verification, and that benefit is lost here.
And yes, I do understand your answer was a rhetorical, tong in cheek reply. 🙂
LikeLike
Dear Gerben,
some proposal concerning what I think is wrong.
1- in the first picture, the relationship typing between the elements are weak, only association, when compostion relationships should be used in many cases. E.g. if you “destroy” a virtual machine, the OS installed and running on it will not exist anymore.
2- in the first picture, typing of nodes is also weak – not clear if we are describing virtual machines for the virtual nodes A and B. In addition, heterogeneous ways are used to describe what seems to be the same at right size and left size (i.e. a machine, an OS and a link to a virtualization system)
3- in the firt picture, usage of containment make the semantic of the relationship unclear and implicit if using drawing tool.
Globally, for first picture, a lot of implicit and no precise modeling.
Concerning the second picture, also a lot of implicit and imprecision.
1- “Virtualization application” when dealing with solutions like Citrix is about virtualization of physical devices, i.e. machines – and not about applications which results from a software device deployed on running and parameterized physical devices (which can be virtualized) and software systems, including OS and eventually other software systems such as Java/.Net virtual machines, application servers, interpreters, etc. Consequently the realisation of the application component can’t be realized standalone by an artifact.
2- The virtualization system should not be shown in the second picture, as the principle of virtualisation is to hide physical aspect, with decoupling between logic and physic. It allows physical changes not to impact the logical view. So relating Citrix as a service for an applicative component should not be done, except if “System X” is an OS and the business role something like a network administrator.
3- a containment is used on the ICT layer between the application virtual node and Citrix software system, without having a clear idea of the described relationship – which is not OK when using drawing with ArchiMate.
So globally a lot of implicit and a not really useable viewpoint – as machines and application virtualization principles are not reflected at all in the pattern.
Best regards.
Nicolas Figay
LikeLike
Hello Nicolas,
On diagram 1:
1 – these are Assignment relations, not Association relations
2 – Well spotted, there is some sort of symmetry from the left and the right towards the Virtualization Software, which should be some sort of one-way. But that is not all.
3 – Nesting always hides the exact relation (unless only one is possible)and that is always potentially a problem. But that is not what I had in mind (or my problem with the diagram would be that one should never use Nesting, and that is not what I think). We can assume that the Nestings stand for Compositions or Aggregations.
On diagram 2:
1 – Your idea of Citrix as ‘virtualisation of Devices’ is, I think, very appropriate. But your consequence, I do not follow. However, the issue is related to what I have in mind as problem.
2 – I don’t agree with this point. As the virtualisation is needed for the user to actually use the application, it is part of the infrastructure that is required for the application to run. It is not so much the question if it should be shown (that is a matter of taste more than anything else), but how it should be modeled if you want it to be shown.
3 – It is safe to assume Composition or Aggregation when Nesting is used between Nodes and Devices, Nodes or System Software. The fact that Nesting hides a real relation, is not important, as far as I’m concerned (see 3 above).
End of lunch. Back to work 🙂
LikeLike
Hi all,
I am a real novice of ArchiMate so I expect to be completely wrong in my interpretation. Nonetheless, I’m going to go out on a limb…
Diagram 1:
1. I’m not sure what you are trying to say by having two instances of “Operating System A” in the diagram. I would have only one because there would be only one in my model and I don’t like to duplicate items in a diagram. Maybe just a style thing. Maybe I’m missing something.
2. The “Virtualization Software” will running on “machine001” and “machine002” so, for completeness, I would add an assignment relation between the two devices and the “Virtualization Software”.
3. If you were to build a full model (using Infrastructure Interfaces, Functions and Services) you would see that “Operating System A” would have a composite relationship with an Infrastructure Interface which would be used by “Virtualization Software”. So, the derived relationship between “Operating System A” and “Virtualization Software” is used-by not assigned because used-by is weaker than composite.
4. In ArchiMate, devices and software are just specializations of Nodes… so, that means we can replace the “Virtual Node A” and “B” with virtual devices. Doing this means that it is easier for the reader to see that the nodes represent a computational resource. The ArchiMate spec refers to devices as “…physical computational resource…” and in reality, these are no really physical. So, is my suggestion correct? Maybe not but, I think its a reasonable compromise to make the diagram easier to read. Also, I think that it would make sense to have these as devices when you consider that they could be referenced in other diagrams / views where the virtual-ness of them is immaterial.
5. Lastly… and this this is where I think I’ll show my limited knowledge… I would remove the assignment relationships between “Virtualization Software” and “Operating System B” / “Operating System C” and replace them with a composite relationship (or nest them in the “Virtualization Software” node). My reasoning is simple… virtualization software provides a “universe in the sky” where devices can exist. It is not in itself a device but more a place where devices live. If you’re a fan of Terry Pratchett, you’ll be thinking of L-Space (or in our case V-Space). So, it is like a node where devices live so a composite relationship fits.
As for diagram 2… still thinking about that one. There is never enough time in a day 😉
Best regards
Grant
LikeLike
Diagram 1:
1. Duplicating items yes or no is a question of abstraction. In a class like model, you definitely don’t have duplicates. In an object like model, you might use abstractions like having one OS for both devices, but then you mix object and class and that may lead to several problems. This is not a problem I was thinking of, but there is something else in that area.
2. The Assignment you add is a derived relation of those that are between the Device and the Virtualization Software.
3. Bingo! There is a problem with the relations between Operating System A and Virtualization Software. A Used-By is possible, but I think the modeller had another concept at Infrastructure Level in mind: deployment. There is an even bigger problem here with this relation, though. Do you know which one?
4. I’m afraid you have the consequence of specialisation reversed. A specialised concept must be able to do everything that the parent concept can and potentially more/different, but not the other way around. If Ball is a specialisation of Toy, Ball must conform to all the specifications of Toy (e.g. ‘be played with’) but Toy does not need to conform to all the specifications of Ball (i.e. not all Toys ‘are round’). Not every Node is a Device, so replacing Nodes with Devices is not by definition allowed or the right thing to do. One thing you mention yourself: a Device is a physical resource.
5. There currently is no Assignment between Virtualization Software and Operating System B and Operating System C but your suggestion of using Composition is an improvement, so I would say “Bingo, again!” for spotting a trouble spot and providing a possible way out. The same ‘bigger problem’ mentioned above is here too, by the way.
You’re not doing badly as a novice, if you ask me.
Now, where is my cow? 🙂
LikeLike
Regarding the second diagram, If I stay in the ‘active structure’ column, then the derived relation says that the “X interface” is used by an application component (not “System X”, lets call it “System Y”) used by the role. So if you consider that the role is assigned to a business process which requires an application, then either this application is “System X” but then the role uses “System Y” ‘s interface, or this application is “System Y” but then there no more links with “System X” which is the virtualized application all this is about…
LikeLike
Bingo! Here is a problem. But it is not as bad as you think. No need for “System Y”, really.
LikeLike
“Taking the bull by horns” might be a more pleasant way of ‘handling’ the animal.
LikeLike
Reblogged this on Mastering ArchiMate.
LikeLike