Link: http://masteringarchimate.com/2015/07/30/open-letter-to-tog-1/
From Mastering ArchiMate
Dear TOG,
I hope this letter finds you well.
As the shepherd of the ArchiMate standard, you are currently working on its next iteration. As I am not part of the ArchiMate Forum, I am going to send you a few open letters with suggestions for improvement of the language and what to do an not to do. I will be voicing some stern/harsh criticisms on ArchiMate in these letters, please don’t take it personal, I’m only interested in strengthening the language which I already find useful as it is. And I apologise beforehand for my language here and there.
This is the first of such a letter.
Today, I want to write to you about the Specialisation relation in ArchiMate.
ArchiMate has a Specialisation relation. The standard tells us (in section 2.4) that it has taken Specialisation from UML 2.0, which is interesting as UML 2.0 does not have a Specialisation concept. UML 2.0 has a Generalisation concept which is sort of the opposite of Specialisation, but it is far more subtle and rich than what is in ArchiMate. The actual definition of Specialisation in ArchiMate (Section 7.3.3) is:
The specialization relationship indicates that an object is a specialization of another object.
I don’t know about you, but that doesn’t tell us much, does it? Luckily, ArchiMate explains more:
The specialization relationship has been inspired by the generalization/specialization relationship in UML class diagrams, but is applicable to specialize a wider range of concepts. The specialization relationship can relate any instance of a concept with another instance of the same concept.
It’s ‘inspired by’ generalisation in UML’s Class Diagrams. That makes matters more clear, doesn’t it? It then unnecessarily repeats the last sentence by stating:
Specialization is always possible between two instances of the same concept.
So far for the official definition. We are told it is like (inverse) generalisation in UML. The example given in the standard is like this one:
Personally, I don’t think the ArchiMate founders were thinking about multiple instances of a process (class) and they were just modelling ‘the process’. But we can get away with it in this example, after all, in the organisation we will have many instances of those processes of the example running side by side. In that interpretation we have (as we would do in UML) created a ‘class diagram’.
ArchiMate itself is class/instance agnostic, so you can also use it to model specific situations, such as this one where instances are modelled:
Here the servers are actual instances, e.g. modelled as part of a project architecture or as the documentation of your current state. If people want to show that all these three specific servers are of a company-standard linux variant, you might see this in models:
Here, we are clearly not in a class diagram anymore, but in a combination of classes and instances. This is an example of the freedom and flexibility we have in ArchiMate because it is in places not very precise (not as precise as UML for instance).
In fact, the Specialisations of Nodes above are used as Instantiations. This operator is not specifically available in ArchiMate and I personally prefer to use Aggregation in a situation like this:
In short: I model ‘the set of linux servers’ and not ‘the type of linux servers’ and stay away from Specialisation here. But (as written elsewhere) I would like to have an Instantiation relation in ArchiMate so I can be clear about it if I want/need to.
There is more about Specialisation in the standard. In chapter 9 on extending the language there is more about the use of Specialisation:
Specialization is a simple and powerful way to define new concepts based on the existing ones. Specialized concepts inherit the properties of their “parent” concepts, but additional restrictions with respect to their use may apply. For example, some of the relationships that apply to the “parent” concept need not be allowed for the specialization.
[…]A specialized concept […] strongly resembles a stereotype as it is used in UML. Specialization of concepts and relationships provides extra flexibility, as it allows organizations or individual users to customize the language to their own preferences and needs, while the underlying precise definition of the concepts is conserved.
Within the standard metamodel, we find Specialisation to be used like this five times:
- A Contract is a Specialisation of a Business Object
- A Business Collaboration is a Specialisation of a Business Role
- An Application Collaboration is a Specialisation of an Application Component
- Both a Device and System Software are Specialisations of Node
Here, ArchiMate’s Specialisation is not used for class inheritance or instantiation, it is used to extend the metamodel (as UML can do with ‘Stereotypes‘). UML Stereotypes are not so much part of models you create in UML, but they are extensions of the UML language itself (after which you can create models in that extended-UML). This is fundamentally different from Generalisation/Specialisation in UML class diagrams for instance and there is also a different relation for it, like Specialisation but with a filled arrow head. In Mock-ArchiMate:
In UML, a Stereotype is a special Class that extends a UML MetaClass. As it is a Class, it can also be part of its own class hierarchy:
Don’t forget, these are changes to UML itself, not to a model created in (that extended) UML. I can make this story even more complex but I’d like to stop here. In the 710 pages of the very complex and dense UML standard, stereotypes is one of the deep-down complex and difficult to grasp elements of UML and I suspect most practitioners never bother to go beyond simple hierarchies in class diagrams.
As the ArchiMate standards says “Resembles a stereotype in UML” is therefore not really a clear definition of Specialisation in ArchiMate, let alone that it differs fundamentally from the other reference to UML earlier in the ArchiMate standard.
Summing up: Specialisation in ArchiMate is defined in two fundamentally different ways:
- subclassing of model elements (agnostic of these being classes or instances)
- stereotyping of the metamodel elements
and it is used also in a third way in real models:
- instantiation
From all of this, I suspect there will be interesting discussions in the group that is trying to create a formal definition of ArchiMate written in UML…
Finally, my pet peeve about Specialisation in the ArchiMate standard is its appearance in Viewpoint definitions. Take the Organisation Viewpoint (Section 8.4.2), shown here in the Mastering ArchiMate colouring scheme:
What interests me here is the appearance of the Specialisation relation. Let’s take a segment of this viewpoint and show an example from a potential real model:
We have modelled a public-private partnership for the development of Estate X of Oxbridge City. You might notice the absence of Specialisation. It is never used to model such a Collaboration in a real ArchiMate model. The Specialisation relation in the viewpoint definition is in fact the Stereotype from the metamodel, and that relation is a metamodel relation (a relation part of the language) and not a model relation. Try to add it to the model (in red, below) and you’ll immediately see how silly it is:
No, Estate X Developer is not a Specialisation of both(!) City Law Maker and Real Estate Developer. I would not expect this Specialisation relation in any real model and thus also not in any real view.
Shall I be frank? The fact that these Specialisation relations appear in a number of viewpoint definitions shows either a lack of attention (as one just copied parts of the metamodel) and/or a lack of real-world modelling expertise and/or a lack of fundamental understanding.
Suggestions
Ending this letter I’d like to give you a few suggestions:
- Remove all Specialisation relations from the viewpoint definitions.
- Turn the Specialisation used for extending the metamodel into an Extension relation conform UML (with the filled arrow head, as in UML), only to be used to change the metamodel, not to be used in ordinary modelling (and thus, leave it out of the allowed relation table). Then, remove Specialisation entirely from the allowed relationship table as Specialisation in real models will only be allowed between elements of the same metamodel-type anyway.
- Add the Instantiation relation. UML has this as a stereotyped dependency, but its arrow looks like the Access relation in ArchiMate. Maybe the double-arrowhead notation as I’ve suggested elsewhere?
I will not advocate that the hideous complexity of UML finds its way into ArchiMate, which after all is meant for simpler and less formal uses. But it is good to remember that saying from Sidney J. Harris:
In every field of inquiry, it is true that all things should be made as simple as possible — but no simpler. (And for every problem that is muddled by over-complexity, a dozen are muddled by over-simplifying).
Simple is good and we architects have this deeply ingrained in our psyche because essential and avoidable complexity are important aspects of our work. Oversimplification, however, is damaging, and we architects are often less aware of this, focused as we are on simplification.
Yours truly,
Gerben Wierda
– Former Lead Architect of APG Asset Management and of the Dutch Judiciary
– Team Coordinator Architecture & Design at the All Pension Group (APG)
– Author of Mastering ArchiMate and Chess and the Art of Enterprise Architecture
