Did you ever wonder what a strange beast the Grouping Relation in the ArchiMate zoo of elements and relations is? According to the standard it is a ‘relation’. It is, however, one of the weirdest elements of ArchiMate. Officially it is a relation, but it looks like an element. Somehow, it stands for a relation between all the elements grouped, but modelling-wise, it does not relate to any other part of a model. It’s a bit reminiscent of the phrase ‘the sound of clapping with one hand’. The tool I generally use for ArchiMate modelling doesn’t even mention Grouping in the ArchiMate sections of elements and relations that can be added to a model. It is part of the section “Graphic shapes” (together with some other useful shapes that do not stand for anything that have to do with modelling; i.e. shapes to liven up your views such as a post-it note). And that, I’m afraid, is exactly what it in practice is. ArchiMate may call it a relation, but it is hard to see Grouping technically as a relation (as it does not actually relate anything element in the model to anything else). It is also not an element. It is just a shape. The tool can remember that it can graphically nest elements, but that has no effect on the model at all. It is like a Nested relation, but without the relation. The standard says:
Unlike the other language concepts, grouping has no formal semantics. It is only used to show graphically that model elements have something in common. Model elements may belong to multiple (overlapping) groups.
This has ‘shoehorned into the core idea of (elements and) relations’ written all over it.
Actually, there is another weird element if you think about it: Product. It is a passive element, but it can Aggregate behavioural elements, namely the services.
The Location element, added in ArchiMate 2, also has a bit of that ‘shoehorned in’ quality. It has been added to ArchiMate as an active element, normally meaning that it should be able to perform behaviour. The relation used to connect it to other elements is Assignment, too, but in the same kind of meaning as the Assignment between Node and Artifact, the ‘resides at’ meaning. More illogic: I can Assign an Artifact to a Node, but I cannot Assign a Data Object to an Application Component or a Business Object to an Actor. A bit strange. Why is this OK in the infrastructure layer and not the other layers?
I think that we could make a cleaner ArchiMate by dropping the almost meaningless Grouping ‘shape’ in ArchiMate and concluding that the world needs more than just Subject (active element), Verb (behavioural element) and Object (passive element) to be described. ArchiMate could at least do with one more base type in its metamodel.
I propose to add a new element class, next to active, behavioural and passive: aspect (or whatever name is better, maybe collection as I wrote in section 28.8 of the book). Aspects are the elements that contain extra information in the model that is neither active (has behaviour), behaviour (is behaviour) or passive (is accessed by behaviour). The new class contains a single generic master element type: Group. The available specialisations are Location, Product and Capability, as described in another earlier post: Missing from ArchiMate: (Business) Capability?. We might, in the light of capability-based thinking rename Product as a Result, but I am still a bit in two minds about that. From the perspective of the outside Product is better, but from the perspective of the inside, Result is more appropriate. The new part of the metamodel would look like this: 
A Group may Aggregate any core element. Result may Aggregate Business Object (and Contract), Artifact (an extension of what was proposed in that earlier post) and any service. Capability may Aggregate Actor, Application Component, Node, Process, any Function and Artifact. And of course: you may Nest in a Group element whatever is Aggregated by it. This way, what you are now trying to say with a grouping becomes structured information instead of just an unstructured graphical signal.
I wonder: if we would have had Group from the beginning, would the structural concept Location have been added in ArchiMate 2.0? Or would everyone that required structured information (model) about locations just have used the Group element? And suppose we have need of yet another concept to be used in a modelling sense, say Time, do we, just as happened with Location, add yet another concept to the metamodel? Or might we even be so bold as to drop the Location concept and tell people: just use Group? After all, in this brave new world of Cloud and all, what’s so special about that medieval-up-to-20th-century concept of a geographic place?
R&A IT Strategy & Architecture 
@Gerben: “I wonder: if we would have had Group from the beginning, would the structural concept Location have been added in ArchiMate 2.0? Or would everyone that required structured information (model) about locations just have used the Group element?”
Aaaarrrghhhh!!!! Gerben!!!!!! NO!!!!!! Waaaaaahhh!!!!
(Takes deep breath, reassembles sanity, sets out to explain in calmer tones…)
No, they’re fundamentally different. ‘Group’ is just a conceptual convenience, an indication of (arbitrary) (apparent) (self-selected) clustering of relations. ‘Location’ is an attribute (a ‘Where’) that may also be an element in its own right. Location was (correctly, to my mind) part of pre-v1.0 Archimate; it was dropped in v1.0, apparently for the same mistaken reasoning as you’ve just used, but was correctly reinstated in v2.0.
(I think Group may have been in pre-v1.0 too, but I’m not sure about that – you’d have to check with Marc Lankhorst et al.)
@Gerben: “Or might we even be so bold as to drop the Location concept and tell people: just use Group?”
No. Just ‘No’. They’re fundamentally different: don’t mix them up!
@Gerben: “After all, in this brave new world of Cloud and all, what’s so special about that medieval-up-to-20th-century concept of a geographic place?”
C’mon, Gerben, how on earth could you of all people drop an absolute howler like that? – we’ve talked in some depth about the dangers of misplaced IT-centrism, and that would be one of the most blatant examples I’ve seen in quite a long time….
Think about it: Cloud may be virtual from the application/data perspective, but it’s very much physical from the infrastructure perspective. As soon as it’s physical, it needs a geographic location – end of story there. You yourself may not need it for the specific aspects of Archimate that you do in your own work: but other people – anyone who deals with physical IT-infrastructure, for example – do need it for theirs. Don’t be so darned parochial! 🙂
And also, don’t place arbitrary constraints on Location – a Location could just as easily be virtual as physical. An IP-address is a location; a URL is a Location (it’s built right into the name, for heavens’ sake: Universal Resource Locator). Or it could be relational: a RACI mapping is a type of Location. And so on, and so on: Location is an attribute that may also usefully be described as an element, not merely because it occurs often enough that it might seem to be a type of Group, but because it needs attributes in its own right.
Waaaahhhh!!!! 🙂 🙂
LikeLike
The reference to Cloud was tongue-in-cheek, apparently not all too obvious (in the Cloud posting over on enterprisechess.com I actually argue the same way as you: nothing much changes architecturally) . For the rest, I’ll get back to ‘aspect (property?)’ versus ‘grouping’ as soon as I’m able.
LikeLike