A short one today. I have a view taken from a certain book. The view contains an error, can you spot it? And when you have spotted it, go to the ArchiMate 2.1 Specification and can you tell me what is wrong with it with respect to the same subject? Click the image below for a PDF:
Maybe there are more errors then the one I have in mind. In that case the author can really die from shame 🙂
Update 18 June 2015: That was quick! The answers are in the comment section below. Now I can die from shame of making such an error. And those that maintain ArchiMate have some more food for thought about the failure of creating meaningful conclusions from a simple syntactical rule. ArchiMate 3 should overhaul the Derivation concept. Let’s just hope that they won’t “throw the baby away with the bath water” when creating ArchiMate 3. Making it even more formal (syntactical) will undermine that what makes ArchiMate so usable. And please: forget about backwards compatibility. It is overrated in this area.
R&A IT Strategy & Architecture 
Colors. Overuse of assignment relationship.
LikeLike
ArchiMate is colour-neutral so any use of colour cannot make a view ‘wrong’. It is a matter of taste (or experience with a certain style)
Can you expand on “Overuse of assignment relationship”?
LikeLike
Ah, thank you. Colors in this diagram are not used in clear way, which limits their utility. While it may not be specified, using color to denote ArchiMate layers is a common and effective technique. So I guess not technically “wrong”, but something that could be improved based on accepted practice.
I believe the comments below do a excellent job on expanding on “overuse of assignment relationship”!
LikeLike
I disagree with you on the clear/unclear way of using colours in the diagram. In my experience (and practice), the (here slightly adapted) original ArchiMate colour scheme in this example is superior to the one-colour-per-layer that is now often used. It tends to make it much easier for people to understand what the view says (in combination with a good labeling standard) and it is very easy to get used to.
In my opinion, the colour-per-layer approach was a quick fix for a problem that could have been solved better in another way.
LikeLike
It shows an assignment from Business Role to Business Collaboration (or the other way around, we can’t tell). That is no part of the specification. In fact, the matrix in Appendix B shows that Assignment between Business Role tot Business Collaboration is not allowed in either way.
LikeLike
Bingo! The Assignment should be an Aggregation relation from Collaboration to Role. But there is more in that corner. And there is a problem in the Specification as well.
LikeLike
Surely, this must have something to do with derivation, my favorite topic.
An aggregation and assignment in serial combine to assignment, as by definition of derivation.
Assume a model with Business Collaboration “Collab1”, Business Actor “Actor1” and Business Role “Role1”. Collab1 aggregates Actor1, Actor1 assigns to Role1. In that case I can derive that Collab1 assigns to Role1. But that isn’t allowed according to the specification in the Matrix of appendix B, as we saw before.
Well spotted, Gerben.
Now, did I win THE book?
LikeLike
Bingo again!
This is an unintended consequence of the fact that from ArchiMate 1 to ArchiMate 2 the Assignment relation became unidirectional. A few derivations that were meaningful became impossible and these were added ad hoc to the allowed core relations (such as a Used-By from Business Service to Business Role, which used to be a derivation from the route Business Service Used-By Business Process Assigned-To Business Role.
One such was Business Collaboration Aggregated Business Role is Assigned-To Business Actor. This made a derivation of Business Collaboration Aggregates Business Actor possible. As this derivation was not possible anymore, the relation was added to the core relations in an ad hoc fashion. But nobody noticed that a derived Assignment from Business Actor to Business Collaboration now had become possible and added it to the table in the appendix. And this also leads to an interesting question: which one is correct: Aggregating Actors in a Collaboration or Assigning several to a Collaborations (via invisible roles)? The last one is more correct, I think, but the first one was added because TOG wanted to keep backward compatibility. Being backward compatibility sometimes means being backward 🙂
It is why “Do something about the derivation concept” in in my ArchiMate Wish List.
Do you not have THE book already? Really? Oh well, I did not offer a prize this time, but I can hand out one anyway…
LikeLike
Your historical analysis is only part of the issues with derivation. And I know you touched on many of them in the past as well. I think the urge to stay backward compatible block many improvements that we all want very much.
There are more hidden caveats then such an important topic of the specification should have. I’ve documented a couple in the past as well. In my opinion the fact that association is a bidirectional structural relation is the most hilarious of them all. Association is not a structural relation and if it would be (by definition), it must be bidirectional. Derivation with Association leads to irrelevant results most of the times.
In my opinion it is very unfortunate that the matrix of appendix B is a result of recursivily applying the rules of derivation on the metamodel, but could not be created again with that same process. That is strange, it shows that derivation must have issues. And don’t get me started on derivation of dynamic relations. In my opinion this is an even more strange part of derivation.
But on the other hand, derivation is one of the most powerful topics of ArchiMate and, in my opinion, one of the foundations of it’s success. That shouldn’t be thrown away.
In my opinion derivation should be fixed. It should be fixed in three steps.
1) Reduction of structural relations. Structural means part of the same structure. Used by doesn’t indicate such a relation.
2) Redefine derivation of dynamic relations.
3) introduce a ‘strict mode’ for derivation, based on this new set of derivation rules. This will lead to new matrix with less options for the most part, but some new options as well.
The matrix of B could stay for backward compatibility mode, the strict mode should be used when doing analysis that must rely on the derived relations to be relevant. This I documented and donated to team members of TOG. I can only hope they will use my proposal and don’t lay it aside because of backward compatibility issues.
Again, compliments for spotting this.
LikeLike
While the standard is a bit vague on it the general interpretation is that the table in Appendix B in the standard specifies all the ‘direct’ and ‘derived’ relationships that are possible. The meta-model diagrams only specify the ‘direct’ ones (plus note that any type can have composition, aggregation and specialization with itself etc). So by deduction the letters in the table in Appendix B that aren’t on the diagrams are ‘derived’ relationships (and should be shown in red).
Looking at your example, Business Role to Business Collaboration only allows the ‘direct’ relationships of Aggregation and Specialization (as per figure 9 in the standard). Then from Appendix B you have ‘cfgostu’ which means additionally you ave the following ‘derived’ relationships; Composition, Flow, Association, Triggering and Used by.
LikeLike
What I was also thinking of is that, though Aggregation from Business Collaboration to Business Actor was added as a direct relation in Section 3.1 in Figure 9 on page 13, it has not been added to the definition of Business Collaboration in Section 3.2.3 on page 16-17.
Personally, I think the whole Collaboration and Interaction concepts could be left out altogether. Certainly Interaction, as it only creates weird problems when modelling. Collaboration could stay as some sort of an extra (like Contract) which is sometimes neat.
By the way, I think the specification is also often confused when using the Specialisation relation. The Specialisation of Business Role into Business Collaboration is a metamodel thing, adding that to Appendix B (or the Viewpoint definitions, as I have argued elsewhere) as ‘allowed relation’ in real models is a mistake.
LikeLike
My opinion is that ArchiMate should be more emphatic on when to use assignments.
For instance, the rule of thumb that I use is: assignments are only used between active and behaviour elements. Given this, many of the assignments in the metamodel are incorrect.
For instance, the assigned relation between device and system software would be much more appreciated with composition, i.e a device is composed of system software. I’ve read that this if possible in version 2.1 for backwards compatibility. But for me it’s nonse to represent that a device has a system behaviour, when it is actually composed of.
More over, how does one relate a business actor with its role, since both are active elements? Exceptions of the language? Permit by derivation? Answer: one could easily avoid such relation by aggregating/composing the role with an interface and then the actor uses the interface to perfome the role.
LikeLike
I agree with much of what you say. Assignment is used for three completely different purposes:
Link active element to behaviour (performs)
Link actor to role (fulfills)
Link Node to Artifact or Device to System Software (is deployed on)
In defence of the original ArchiMate team: they als had the goal to keep the number of types to a minimum. So, re-use of Assignment for a different meaning was OK and even a good thing.
LikeLike