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
R&A IT Strategy & Architecture 
Roger that!
LikeLike
Is there any statistics on the possible number of uses of Specialization in say any typical Architectural work. This can help us if this is very serious issue that needs to be addressed, or just a small one that can be overlooked? en_architect
LikeLike
I agree that what is shown in Archimate is not specialization in the UML generalization/specialization sense.
UML makes strong distinctions between model and metamodel, and between type (class) and instance (object). To me this makes sense when modelling software systems. Whether I am modelling something that is truly object-oriented, where the classes are types and the objects are instances, or data structures in a non-o-o language, the types define a structure with a set of attributes or slots that can hold values from particular domains, and the instances conform to those types with the slots filled with values.
The generalization/specialization relationship applies in UML between types and is used by ordinary users at the model level, for example to define a class such as BankAccount and two subclasses (specializations) such as CurrentAccount and SavingsAccount. It applies to other UML elements as well, so I can have a generic use case called ‘Check in’ and two specializations: ‘Check in on line’ and ‘Check in at airport counter’. The generalizations in both cases are likely to be abstract: there will be no instances of BankAccount or ‘Check in’, only of their specializations.
The use of specialization described in Section 7.3.3 of the Archimate Spec is very close to this. However, the Archimate Spec. notably says ‘The specialization relationship can relate any instance of a concept with another instance of the same concept.’ By instance here, it doesn’t mean instance (as opposed to type) in the UML sense, but (as far as I can tell) loosely a thing that is held in an Archimate model that is defined by a concept in the Archimate metamodel. In fact, the example it gives shows what are in effect types: the business process ‘Take out insurance’ and its two specializations: ‘Take out travel insurance’ and ‘Take out luggage insurance’.
The example that you have a problem with from Section 8.4.2 of the Spec. seems to me to be the result of the authors of the Spec. confusing metamodel and model. In the metamodel, Business Collaboration is shown as a specialization of Business Role, and this makes sense at the metamodel level. However, it is not necessarily the case that a collaboration at the model level is a specialization of one or more roles at the model level, in particular, those that are aggregated as part of the collaboration. In the UML metamodel, the various types of relationship are shown as metaclasses in their own right, and if a UML element can participate in that relationship type in the model, its metaclass will be shown as having association(s) in the metamodel to that relationship metaclass. (For example the metaclass Classifier has two associations to the metaclass Generalization in the UML metamodel, which means that subclasses of Classifier can participate in generalization/specialization relationships at the model level.) That is not the same as an element in the metamodel being a specialization of another element in the metamodel. The notation used in the Archimate metamodel confuses these two things.
To give a practical example, in a rowing club, the collaboration ‘coxless four’ aggregates the role ‘rower’ (in fact four rowers per coxless four). That does not mean that a ‘coxless four’ is a specialisation of ‘rower’. Clearly it is not a kind of rower. The collaboration ‘coxed four’ aggregates four ‘rower’ roles and one ‘cox’ role; and similarly, a ‘coxed four’ is not both a type of cox and a type of rower.
I think the other area where the use of specialization in Archimate breaks down is in its use as a kind of instance-of relationship, which you have covered in your section in instantiation relationships between different nodes. (As an aside, I think that if you are going to use aggregation and treat ‘Standard Linux Server’ as a set, you should consider giving it a plural name.)
However, I think that what architects do (and they do this in UML as well as in Archimate) is partially define nodes as a kind of generic node and then further define them as more specific nodes, usually not because they want to show every single server in the server farm, but because they want to illustrate some aspect of the infrastructure architecture.
In what follows, I am second-guessing what you are doing. Apologies if it’s not right. So, in specifying your Standard Linux Server, you have decided some attributes that you need to hold about that node and determined values for those attributes, for example ‘Operating System = SLES11’, ‘Service Pack = 4’, ‘RAM = 32Gb’, ‘Number of NICs = 2’. When you specify your individual servers, you are adding additional attributes, for example ‘Installed Software[] = {Apache 2.4.16, Tomcat 8.0.24}’, ‘Name = linsrv001’, ‘Disk Storage = 200Gb’. At this stage you may not specify the actual IP addresses, but might add a constraint that they should be on different subnets. The way you are using the ‘Standard Linux Server’ is as a kind of prototype for your actual servers.
Because Archimate doesn’t make the type-instance distinction that UML does, from a UML perspective it is like creating a shortcut, which is fine. Arguably, I could say you are implicitly creating a type called something like ‘Server’, which is a specialization of Node and has the attributes: Operating System, Service Pack, RAM, Number of NICs. You are then creating an instance of that called ‘Standard Linux Server’ and applying values to those attributes. You are implicitly creating specializations of ‘Server’ called ‘Web Server’ and ‘Load Balancer’ which inherit the attributes of ‘Server’ and extend them with the attributes Installed Software[], Name, Disk Storage. Maybe ‘Load Balancer’ also has the attribute ‘Number of Nodes’ to define how many nodes it is balancing across, and ‘Web Server’ also has the Boolean attribute ‘In DMZ’. You are then creating instances of these implicit types called ‘linsrv001’ etc., with specific values in the new attributes, and at the instance level you are ‘inheriting’ the values for inherited attributes from a specific instance of ‘Server’ – the one called ‘Standard Linux Server’, but bear in mind that there may be other instances of that type. (One of the advantages of the type-instance distinction is that I can re-use these types elsewhere in my model with different instance values.)
However, I think that the relationship between the instances ‘linsrv001’, ‘linsrv002’ and ‘linsrv003’ and ‘Standard Linux Server’ as you have them is what is called ‘prototypal inheritance’ as opposed to ‘class-based inheritance’. The instances ‘linsrv001’ etc. are ‘inheriting’ values from the prototype ‘Standard Linux Server’.
A question for the Open Group people is whether these two types of inheritance should be shown using the same notation in Archimate diagrams.
LikeLike
Reblogged this on Metadata Matters, by @MetadataJunkie and commented:
Interesting thoughts here on the often-confused distinction between a model and a meta-model
LikeLike