ArchiMate Wish List

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 toPicassoGuernica 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. 😉

5 comments

  1. Derivation has always been a hot topic of mine for nearly three decades (since J.R. Abrial’s: Data Semantics article). I remember meeting James Rumbaugh (of “Three Amigos” fame) and escorting him around Sydney Australia for a day (as UML was forming).
    I said to him: “Of the three competing methodologies I am really impressed that yours tackles derivation – the others don’t!” He looked at me rather ruefully and said in a hushed tone: “Shush! We don’t talk about it, We haven’t thought it through at all”. A BIG let-down…
    Why is it so hard?

    Like

  2. Derivation has always been a hot topic of mine for nearly three decades (since J.R. Abrial’s: Data Semantics article). I remember meeting James Rumbaugh (of “Three Amigos” fame) and escorting him around Sydney Australia for a day (as UML was forming).
    I said to him: “Of the three competing methodologies I am really impressed that yours tackles derivation – the others don’t!” He looked at me rather ruefully and said in a hushed tone: “Shush! We don’t talk about it, We haven’t thought it through at all”. A BIG let-down…
    Why is it so hard?

    Like

    1. The short answer for me is: because derivation in such a setting is a purely syntactical operation, and there is a fundamental divide between syntax and meaning (see Uncle Ludwig). If you look at ArchiMate’s derivation, it works a bit like a ‘summary’. Now imagine in natural language to have a purely syntactical operation that can create a summary of a longer text. Hard to imagine. ArchiMate is much simpler than natural language, so syntactical operations will get you further, but not all the way.

      Like

      1. Is it just syntax? Using Abrial’s “AccessFuntions”, we can formalise GrandparentOf(x) = ParentOf(ParentOf(x)). However, that DOES rely on having a semantic name for the relationship.

        In my experience and in my work I’ve used either semantic names for Associations (including meronomies) or synthetic names for those other relationship types. I’ve always been careful to have semantically distinct relationships carefully documented (in the detail) and then the summary can contain the UNION relationship (derived) or the TRAVERSAL relationship (also derived) where necessary. Traversal derivations are those specified in ArchiMate. Union derivations are closely related to the use of junctions in the wishlist above.

        Like

Leave a comment