Time for another — this time very short — educational quiz post. Look at the following diagram (in the Mastering ArchiMate colour scheme). Is this OK?
[Completed post (from this point on) revealed on 21/Sep/2016]
First, let’s look at why this is possible. As some noted in the comments, a Contract is a Specialisation of Business Object in the meta-model. That means it inherits all the possible relations that a Business Object can have in a real model, one of which is “Business Object Specialises Business Object in an actual model“. As Business Object can Specialise a Business Object in an actual model, Contract — which is also a Business Object — can also Specialise a Business Object in an actual model. As a result: the above is not wrong and the answer is: “Nothing.”
I can even dream up a realistic scenario:
Suppose we have use for some analytics/statistics on our contracts? But law demands of us that such analytics is one on anonymised data? Well, we could model that in ArchiMate by creating a Business Object that is a Specialisation of Contract, like this:
This, I think, is how ArchiMate intends the use of Specialisation in an actual model.
What one must take from this is that ArchiMate has two quite distinct forms of Specialisation, that confusingly are called the same and use the same visualisation (the arrow with the white closed arrowhead): one that is used in the meta-model and one that is used in a real model.
The one in the meta-model looks like Stereotypes of UML: the child inherits the capabilities of the parent, that is in the meta-model: all its relations. It is explained in Section 15.2 of the standard and not in Section 5.4.1. You are not using this Specialisation while modelling, you can only do that while extending the meta-model (which nobody ever does, I suspect, and which tools do not really support properly).
The one in an actual model behaves differently: the child does not inherit the actual relationships the parent has in the actual model. In UML, such inheritance does happen in Class Diagrams. ArchiMate’s Specialisation is quite different.
Personally, I would have put that in the allowed relationship table as two different Specialisations, one with a uppercase ‘S’ (15.2) and one with a lowercase ‘s’ (5.4.1), with different visualisations.
Business Object and Contract behave relatively benignly in this situation. But all the meta-model-Specialisations of Node, for instance, do produce a plethora of possible model-Specialisations: all the meta-model-Specialisations of Node (Equipment, Facility, Device, System Software) can model-Specialise occurrences of all others. E.g. Facility can be modeled in an actual model as a Specialisation of System Software:
Which is plain silly. ArchiMate doesn’t stop you to model silly things, but in this case, some constraints might have been useful,
See also my first ever ‘Open Letter to The Open Group‘ — a series I wrote when ArchiMate 3 development was going on (without me, I’m an outsider) — which also explained the problem with this part of the standard and discussed some more options.
R&A IT Strategy & Architecture 
OK, so here we have a Business Object as a specialization of a Contract. It is also possible to do it the other way around…
LikeLike
The spec metamodel shows that a Contract is a specialization of a Business Object.
LikeLike
And…?
LikeLike
…we end up in an infinite loop?
LikeLike
Let’s quote the definition of the standard:”The specialization relationship indicates that an element is a particular kind of another element.”, and it continues to say that it is “inspired by the generalization relationship in UML class diagrams”. Now, in OO/ADT/class, specialisation means “subtype”. E.g. Ball is a kind of Toy, and it doesn’t follow that Toy is a kind of Ball (in fact, if the reverse is true you must have identity: Ball is a kind of Ball) and loops are out of the question anyway. No such loops exist in ArchiMate’s meta-model. But, this is not UML’s generalisation, it is only ‘inspired by it’. Contract is a type of Business Object, but in the meta-model Business Object is not a kind of Contract. So, something curious is going on here, as we are in fact allowed to model a Business Object as a kind of Contract. The question is: why? And giving a hint: it does say something about ArchiMate’s Specialisation relation that is not clear from its definition.
LikeLike
Education you say? Well education is best done by making mistakes … So here goes.
Hypothesis 1:
Isn’t this back to the idea that we do not really have multiple inheritance in ArchiMate? There’s no skip jumping levels the hierarchy either (which this kind of is since we already said Contract was a subclass of Business Object). If you’re a subclass of Contract, you only get stuff from Business Object *through* the specification of the Contract class and you cannot sneak it in by multiple specializations from the same child.
Hypothesis 2:
It may be just the graphic symbols that are making trouble here. What you might intend by the model above is just that there is an object class which we want to declare as a subclass of Contract. Unfortunately we have to simple “object” represented in a the graphical model, so we pick the thing which seems to be the closest to that part of the hierarchy, in this case Business Object. Arguably, the least confusing thing to do would be to pick the Contract symbol for the subtype. However, I’ve run into cases where it is extremely difficult to describe hierarchical contract models from the real world, particularly where there are “things” I need to define which are less contract-y than others but clearly seem to belong there “beneath” the contract. My favorite problem here is that there needs to be a product which exists only within the context of a contract. Sure you can define that as an instance and link it as data (both in the business and app layers) but what if you want a type of thing to be a Contract-Catalog because the terms and service level agreements of products are part of their definition and vice versa in the contract.
Hypothesis 3:
ArchiMate include 3 typing systems (actually more) corresponding to business, app, and tech. Each has its own definition of a base class. When we use the symbol for that base class without any inheritance hierarchy, it just means what the standard says. When we use that symbol to create a subclass, we are overloading its meaning. We need to do this because there is no unadorned symbol just “class” in ArchiMate. There is a presumed typing imposed by the symbol right out of the gate.
Now you’ve made me think about this more (again)! I need to return to my pet project of trying to define some hierarchical corporate contracting patterns using ArchiMate.
LikeLike
Hypothesis 1: No, this hasn’t anything to do with multiple inheritance. ArchiMate doesn’t stop you modelling multiple inheritance in models, even if there is no multiple inheritance in the metamodel. See Section 2.3 of the book (part of the free syntax download, see the book’s home page)
Hypothesis 2: No, this is not about graphical symbols. The diagram shows something from a real model. Hence, what you see is not just graphics, but it is actual ArchiMate element types. We have modelled a Business Object that is a Specialisation of a Contract, while the language’s metamodel shows it the other way around
Hypothese 3: No again, I’m sorry. We are not overloading a Business Object to mean Contract. There is no such thing in ArchiMate. What you see here is what you get. The Business Object is just a Business Object, not a Contract in disguise.
I’ll give a hint. What you need to look into is why ArchiMate allows this (because it is not wrong, it is valid ArchiMate).
LikeLike
I think it all depends on how you interpret the vague definition of “specialization” (and “instance of”) )that is in the spec. It says “The specialization relationship can relate any instance of a concept with another instance of the same concept.”
Now, according to the ArchiMate meta-model, Contract is a specialization of Business Object (BO). Therefore, Contract is a sub-type or derived from BO, which means a Contracts “is a” BO (i.e. a Contract shares all the properties and functionality of a BO).
As a result, we can specialize BO from Contract because a Contract is also a BO. So, the example is specializing a BO from a BO, which is valid according to vague definition of ArchiMate specialization.
LikeLike
Hi Gerben, it’s tricky, but it’s OK. And you have already told it. It’s an specialization of a Contract, Transitively is also a specialization of a (meta) BusinessObject. As ArchiMate specs tells us: http://pubs.opengroup.org/architecture/archimate3-doc/chap05.html#_Toc451757965
“The specialization relationship can relate any instance of a concept with another instance of the same concept.”. And in http://pubs.opengroup.org/architecture/archimate3-doc/chap08.html#_Toc451758019: ” A contract is a specialization of a business object.”
LikeLike
Artur and Gustavo both point out the important point. I’ve revealed the rest of the post.
LikeLike
You explain that actual-model-specialisation is different by stating what it is not, but don’t tell us what it is. That would make your point more clear.
I also doubt whether the specialisation in your example is valid. After all, an anonimised contract is not a contract anymore, it’s just a collection of data. You may model that with a business object, but an association relationship would be a better choice here.
Nevertheless, I endorse your clarification of the specialisation relationship as this is insufficiently explained in the ArchiMate specification.
LikeLike
The Specialisation in my example is valid ArchiMate. It’s just that ArchiMate’s model-specialisation doesn’t play by the rules of ‘software engineering’ specialisation (while th meta-model-specialisation does that a bit more). Model-specialisation is far more ‘human’ in a way. Human’s don’t have issues with this kind of a specialisation. We are fine with calling a big rock and 4 small rocks around it ‘table and chairs’. We are more governed by analogies than logic (even if we can do a bit of the latter). If someone says “Uncle Ludwig”, I won’t blame them…
LikeLike