Some of my wishes have been granted with ArchiMate 3 so I have removed them. Some make no more sense in current ArchiMate 3. This page still needs to get fully updated. It will be after the release of Mastering ArchiMate Edition III.
ArchiMate is powerful and useful, but as with anything you master in detail, you will find issues. In ArchiMate, these issues are almost by by definition a matter of opinion. The ArchiMate specification is a ‘yardstick’, a definition. Disagreeing with a yardstick is like using a meter-stick to argue that a yard-stick is wrong. Choosing between one and the other is a matter of taste. Of course, even in matters of taste, there is a shared perceived difference of quality. Few will argue against the superiority of Rembrandt’s paintings over a drawing by an average 10-year old done in art class in school. And art critics have a language to describe quality.
One can like wise argue about the quality of a modelling language. We have it easier than most art critics. When the painter masterfully plays with areas that are detailed and areas that are not so as to influence what we experience, we can discuss that. When a painting doesn’t get perspective right, they might objectively point at that. But they also have to contend with artists who think that a correct perspective is not important or who purposely play with perspective or realism in general (see on the right). When discussing modelling language, being able to model reliably, completely, correctly, etc. are aspects that can at least partly be discussed objectively. But much of what we discuss about what we like and dislike about a language remains a matter of taste. Having said that, (and though I think ArchiMate works pretty well for most of what I want to do), here is my current (unordered) list of wishes for changes in ArchiMate:
- Improve the coherence between Core ArchiMate and Motivation and Implementation&Migration. E.g. make Role a Specialisation of Stakeholder. E.g. why is Assessment not a Business Object (there will be a Business Process that writes it, right?). Why is Work Package not a (Specialisation of) Business Process? Here we have a process that produces a change, but we cannot model its own use of IT support. The extensions are not bad, but they have been taken from concepts in TOGAF and have been haphazardly added to ArchiMate instead of integrated intelligently.
- Allow multi-parent Composition.
- Clean up the Assignment between Device and System Software leftover from ArchiMate 1, where System Software was behaviour (a combined element that was both Node and its function).
- Make direction of a relation more dynamic in the case of Access, a read Access has the opposite direction of a write access and a read/write access is bidirectional Make sure direction always clearly shows.
- Related to the previous point. Do something about the whole Derivation concept. The idea that clear meaning could come from a syntactical operation was nice but naive. In practice, derivation is weak, semantically, and allows wrong conclusions and forbids correct ones.
- Part of the previous one: make Assignment weaker than Realization. Realization as is stands for both a string and a weak concept. Do something about that too.
- Redefine the intern/extern split in ArchiMate as all/visible-part. Looking at Service/Interface as not part of the behaviour (but separately realised by it in some abstract sense) is either contradictory (e.g. the ‘external behaviour’ of a Business Process is part of that process, as it is performed by the one Assigned to it) or it overlaps with what happens in the Motivation Extension.
I like ArchiMate, really I do. I love my children as well. That doesn’t mean I’m without criticism or that I don’t want them to grow up well. The same holds for ArchiMate, somewhat. 😉