June 22, I posted another ArchiMate quiz question: ArchiMate Quiz: A Common Cause. It’s been a while, but here is the discussion of the ‘solution’.
The quiz started with the following two ArchiMate snippets (in Mastering ArchiMate colours, where ‘deep’ is technology and ‘light’ is business, and blue is active, yellow is behaviour and green is passive, as it was originally used in ArchiMate):
Both snippets show an Assignment. The question was: “These are not core relations, so they are derived relations. What derivation gives you these results and what is the common theme behind these derivations?”
The answer to the quiz question about why certain relations are possible was correctly given by Raquel Soria. There is a common reason why both relations are possible is the same: the specific position that Node plays in the ArchiMate metamodel and the specific way in which ArchiMate says relations may be derived.
Aside: If you are new to ArchiMate: this discussion is pretty language-technical. To understand what is going on, you need at least to understand the language and the derivation mechanism. This you can get from the Free Syntax Excerpt of the book Mastering ArchiMate, available here.
Take the first Assignment. This one is allowed because a Device is a Specialisation of Node and because the ArchiMate standard says:
- (Quoting section 5.1.1) A composition relationship is always allowed between two instances of the same element type
- (Quoting Appendix B) For two elements a and b, where b has a metamodel specialization to a (e.g., a is Node and b is Facility), all relationships that are allowed from a to a are also allowed from a to b, from b to a, and from b to b; also, given b and c, two different elements which have a metamodel specialization to a (e.g., b is Facility and c is System Software), then all relationships allowed from a to a are also allowed from b to c and from c to b.
The first one of these two is not that surprising. But the second one has some strange consequences. In our first example, we can have a Device that is Assigned-To System Software which — following both rules above — can Compose a Device. The result is a chain of Device – Assigned-To System Software – Composes Device, of which the derived result is Device Assigned-To Device, as Assignment is weaker than Composition.
While we can think of a meaningful use for the end result (e.g. for virtual machines, though somewhat breaking the formal definition of Device), part of that derivation chain is the fact that System Software may Compose a Device. Let this sink in for a moment and try to imagine in what that could mean. How could a Device (hardware, according to ArchiMate) be a composite part of System Software (software)? It is of course impossible. Our derivation contains a meaningless step.
It becomes even sillier if we apply this impossible construct twice. Because we could have System Software that Composes a Device, which is Assigned-To System Software which again Composes a Device. Here it is:
The result: System Software Assigned-To Device instead of the other way around (which is a core relation from the official metamodel).
The ArchiMate standard doesn’t clean up these silly situations following from meaningless relations when calculating its full metamodel relationship table. Using blindly what is allowed grammatically doesn’t give you meaningful models (ArchiMate doesn’t differ from natural language here, not everything grammatically correct is meaningful. Uncle Ludwig, anyone?), and even if they are meaningful, they might mean something different that you intended; see for instance the first ‘beginner pitfall’ mentioned in (the Free Syntax Excerpt of) the book.
The second example illustrates another of such derivations. A Communications Network can Aggregate directly either a Device or System Software, which means in ArchiMate that the Device or System Software is what makes the Network happen (“routers, switches, and firewalls”). As I’ve written elsewhere, the support for low level infrastructure modelling, especially communications, in ArchiMate is rather poor and so is this particular choice. By the way, as far as I’m concerned the Communication Network type is clearly an abstraction of the underlying low level data center hardware (so the lofty software and business architects need not bother with boiler room details), and as such a Realisation from the parts that make it happen would have been more appropriate, but I digress.
Anyway, because Device and System Software are Specialisations of Node, they can Compose any Specialisation of Node, including Facility. So, the route becomes Communication Network Assigned-To System Software Composes Facility Assigned-To Business Actor.
This too contains a questionable step in the derivation chain. It says that System Software can be composed of Facilities.
It is clear that the role of ArchiMate’s Node in the metamodel is having some effects in the silliness department.
Silly structures
What is going on here?
Let’s start with the question: “What is a Specialisation, anyway?” It is sub-typing. What this says is that if you have a sub-type, the sub-type should support (all, in the case of conforming to LSP) the behaviour of the parent type. E.g. if your type is a ‘toy’ and your sub-type is a ‘volleyball’ then the behaviour of ‘toy’ (play with) should be fulfilled by ‘volleyball’ as well. And it is as I can play volleyball with a volleyball but I can also just ‘play with’ (the toy-version) the volleyball. Another example: I cannot make a subtype ‘house’ from a type ‘car’ because you cannot drive a ‘house’. You can drive a ‘camper’, so ‘camper’ could be a subtype of ‘car’. (As well as a subtype of ‘house’, and so we end up in the hopelessly confusing world of multiple inheritance, but I digress. Again.)
When describing extensions of the metamodel, the standard says (quoting 15.2):
Specialized elements inherit the properties of their generalized elements (including the relationships that are allowed for the element)
Nothing wrong with that statement. But Node is the parent of wildly different types (e.g. System Software and Facility). And it is that diversity, in combination with ‘inheritance of allowed relations’, and — especially — ArchiMate’s ‘relation derivation’ that brings about the mess. In for instance software engineering, when I would have only Specialisation and not derivation, the fact that Facility can be Assigned-To a Business Role would not affect System Software at all. Because the fact that Facility may be Assigned-To Business Role doesn’t reverse-inherit upwards to Node. Node, still cannot be Assigned-To Business Role. Inheritance goes ‘down’ only. But derivation adds it anyway, thus effectively breaking inheritance by effectuating inheritance in the opposite — ‘up’ — direction. As if the fact that a camper is a house means you can drive a house.
Solving that requires some hard thinking about specialisation and derivation by the ArchiMate designers. In the meantime, we should probably not use any derivation where any of the steps doesn’t make sense, or any relation in the metamodel that is the result of such a derivation.
R&A IT Strategy & Architecture 