While working on something else, I ran into something funny. I would like you to tell me which relation type exists between two elements in the following setup.
The situation is like this. We have a very large system that consists of many subsystems. Some of these are orchestration-like, other just provide some calculations. The basic pattern is like this:
Now, my simple questions are:
- what is the (derived) relation between the main [System] (Application Component) and [System] Calculation (Application InternalInterface)?
- what is the problem with that answer?
Maybe this is too simple a problem, but I am curious how fast you practitioners hone in on the answer. The previous puzzle took 39 hours for people to come up with the answer, but that one was more complex. This is one that should not be above any beginner who has studied the ArchiMate Standard well.
[Update Jan 14: Hint 1]
Take into account that Nesting is optional, so the fact if something is Nested or not should not influence the meaning (other than that un-Nesting makes matters more clear). So, as a first step, we un-Nest the most internal Nesting.
Now we try to answer the questions again.
[Update Jan 15: Mouzoune Abdessamad mentioned the key insight, here is the solution]
When we want to un-Nest the previous diagram, we need to choose which relation the Nesting stands for. For the Application SubComponents this is obvious: Composition. This also gives us a derived Composite relation between [System] (Application Component) and [System] Calculation (Application Interface). This is a relation we are allowed to Nest, so if we take that as the relation, we get the following diagram on un-Nesting:
The orange and red Composition relations derive the blue Composition relation. And, as Mouzoune noticed: this technically gives us two Composite parents of [System] Calculation (Application Interface), and that is not allowed in ArchiMate (ArchiMate does not exclude derivation from this constraint). Therefore, the only allowed relation between [System] (Application Component) and [System] Calculation (Application Interface) is Aggregation, which is thus the answer to question 1. Note that while the derived Composite still exists according to ArchiMate, it is also forbidden according to ArchiMate. ArchiMate is such a real language that you can even create paradoxes in it 😉
(Aside: according to August Stern’s Matrix Logic, a paradox is like an oscillator which continuously flip-flops between two states, as in saying “this statement is false” which implies it is true which implies it is false ad infinitum. But I digress)
To prevent the derived Composition from [System] (Application Component) to [System] Calculation (Application Interface), we need to make the relation to the Application SubComponents Aggregates instead of Composites:
Now, the paradox is gone. But we are confronted with another problem: our overall [System] (Application Component) no longer ‘owns’ its own sub-components and this is not what we wanted to model.
I find this amusing (so I must be a geek).