Some of my wishes have been granted with ArchiMate 3.0. This page still needs to get updated.
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 (several of which are part of the Discussing ArchiMate chapter of the book):
- Allow junctions for all relations. See linked post, See also Section 28.10 Allow Junctions for all relations in the book.
- Replace the Grouping ‘relation’ by a real Group element and create a fourth class of elements next to Active, Behaviour and Passive. See linked post for details. See also Section 28.8 A Group concept, a ‘Fourth Column’, Nesting in the book, which also proposes to extend Nesting to more relations than just Composition, Aggregation and Assignment.
- Add Capability as a specialisation of the newly proposed Group element (next to Product, and rebrand Location as a Specialisation of Group too). See Section 28.9 Capability and Product, Skills in the book as well.
- Improve the coherence between Core ArchiMate and the Extensions. E.g. make Role a Specialisation of Stakeholder. See also Section 28.16 The ArchiMate Extensions in the book as there is more coherence possible. 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.
- Drop Interaction (and Collaboration, maybe). See Section 28.6 Get rid of Interaction in the book. A detailed post might follow later.
- Allow cross-layer Triggers and Flows and make Event capable of Triggering behaviour in all layers. We do have infrastructure events which lead to business behaviour, don’t we? A detailed post might follow later. See also Section 28.12 Allow some direct relations between business layer and infrastructure layer in the book.
- Allow multi-parent Composition. See Section 28.5 Allow multiple parents in a Composition in the book. A detailed post might follow later.
- Allow Association between a passive element and a Flow relation. A detailed post to be written later.
- 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). See Section 27.3 Fuzzy Concepts in the book. A detailed post might follow later.
- Drop the pre-ArchiMate 2 idea of Required Interface and other mixes between solution and requirement. Since ArchiMate 2 we have the Motivation Extension with a clear Requirements element. See Section 27.4 The ‘Required’ Interface Concept in the book. A detailed post might follow later.
- 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. See Section 28.11 Make the Access relation bidirectional in the book. A detailed post might follow later.
- 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. A detailed post might follow later.
- 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. See also Section 28.1 Service as Composite Part of Function/Process in the book. A detailed post might follow later.
- Change the way automated business behaviour is modelled. Now it is an Assignment from Application Component to business behaviour to signify the automatic business behaviour. Instead: create the possibility to clearly model robots in the business layer, Realised by active IT elements. See Section 28.2 Automated Processes in the book. A detailed post might follow later.
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. 😉