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).
R&A IT Strategy & Architecture 
Two derived relations are possible:
1) A composition or aggregation relation (we can’t tell from the diagram) via the [System] Calculation (Application SubComponent)
2) A used by relation via the [System] Orchestration (Application SubComponent)
In the second instance it means that the system is using itself. which apparently is not true. Or is it? Because there is something in that main System that does use that interface.
LikeLike
This is not the answer to the puzzle.
BTW, I do not think your second (actually third) is possible. You are creating a derived relation from two relations that have an opposite direction (which is not how you make derived relations).
LikeLike
1. Assuming composition relations, the derived relation is also composition, as all intermediate relations are compositions and in the same direction
2. The conclusion that you could draw (I guess) is that the main component “exposes” an internal interface. I personally don’t have a problem with that, though, because the fact that the main application has this (derived) interface does not mean that the interface can be used by any client, or that it gives access to the whole of the main application. There is still a contract to the interface, it’s just no longer visually apparent what that is, So, the derived relation it’s not something I would prefer, but I wouldn’t argue it is wrong.
LikeLike
A step in the right direction…
LikeLike
There is no behavior shown in this model, but it is implied via the used-by relation:
1. The Application Interface is assigned to a Business Service;
2. That Business Service is used-by a Business Process;
3. That Business Process has the Orchestration Application Component assigned.
The assignments indicate automated execution of the Business Service and the Business Process. Although syntactically correct ArchiMate, the question is whether the model author intended to imply the Application Interface to represent a Business Service that would normally be used to model its added value to the outer world. Alternative modeling approaches could be to
a. include application-level behaviour to show how application functions call each other via application services;
b. include business process aggregations or compositions, whereby each business process has its own assignment to an application component.
LikeLike
That is not it.
There is nothing needed outside what I have modeled and ArchiMate knowledge to answer my questions. The Application Interface modeled is only used by the Application Component modeled, it is an internal structure. Modelling such a structure may be useful when you are dealing with large monolithic in-house developed systems.
Shall I give another hint (there are already two)?
LikeLike
I guess you already gave it away with these hints. The interface that was supposed to be internal, get’s ‘external’ by derivation.
LikeLike
No, this is not the problem. The fact that a derived Composite relation from the overall Application Component to the internal Application Interface can be mistaken for a direct Composite (which means ‘overall application exposing that internal interface’) is indeed problematic, I grant you that.
There is, however (see hint above) another problem.
LikeLike
‘Can’t say better better than Seghers…Waiting for the answer, thanks to gctwnl!
LikeLike
I told someone the solution today and he told me that after this one, nobody would try to answer a puzzle anymore as it is not simple at all. Hmm.
OK. I’m going to give a hint. I’ll do that in an update in the story above (and mark it as Hint 1).
LikeLike
If you convert nesting to agregations and apply derrived relationships leaving only two elements of our interest then [System] Application Compnent is used by Calculation Interface and at the same time composes it. The meaning of such model is then ambiguous.
LikeLike
Is it really ambiguous or does it just state the the overall application uses (part of) itself and is that not just a consequence of the two levels of detail you are connecting?
We’re close, though.
LikeLike
I am sorry, don’t see how “component being used by interface” can be derived from the diagram, unless the hidden relation is that the calculation subcomponent uses the main component. Even though not impossible, the “sub” in the name of the subcomponent contradicts that assumption though.
LikeLike
[System] (Application Component)
Composites[System] Calculation (Application Component)Composites[System] Calculation (Application InternalInterface) isUsed-By[System] Orchestration (Application Component) gives [System] (Application Component) isUsed-By[System] Orchestration (Application Component).It is technically a valid derivation and if you want to give it meaning that you can say that the system uses itself internally. It is indeed slightly different than what Habte Wolde wrote, but what I think he intended to write (replace the interface with the orchestration element in his reply).
It has nothing to do with the puzzle, though
LikeLike
Sorry, the hint wasn’t helpfull :-), as unnesting is the first thing I do. The problem of course is to know what the hidden relations are. Composition would be the obvious choice, but for me that poses no problem, as I mentioned earlier. OTOH if the hidden relations are aggregation (I am assuming the nesting of the internal interface does not imply a direct relation with the main component), then the derived relation is also aggregation, so the derivation is that main component aggregates an interface. This for me would be a weird notion. Aggregation implies sharing, so two applications sharing an interface implies that through the interface you have access to both applications, whereas the reality is that both applications only share a common sub component and the interface is the (internal) access to that one. Leaving out the sub-components does not convey that same message.
LikeLike
Indeed, aggregation is known as shared association while composition is about a real ownership of the whole over its parts… I’m waiting for the answer to be around composition choice
LikeLike
I’ll give another hint: there is only one possible relation between [System] (Application Component) and [System] Calculation (Application InternalInterface). So the answer to the first of my questions is not ambiguous.
LikeLike
Since “[System] (Application Component) Composites [System] Calculation (Application Component) Composites [System] Calculation (Application InternalInterface) …”
One would deduce “[System] (Application Component) Composites [System] Calculation (Application InternalInterface) ” by transitivity! .. yet that would violate eventual single-owner rule ?
LikeLike
Bingo!
I’ll finish the story now, above.
LikeLike
I collected the following statements from Archimate spec:
“… In contrast to the aggregation relationship, an object can be part of only one composition.” (7.1.1 Composition Relationship)
“… In contrast to the composition relationship, an object can be part of more than one aggregation.” (7.1.2 Aggregation Relationship)
“… Several of these relationships have been adopted from corresponding relationship concepts that occur in existing standards; e.g., relationships such as composition, aggregation, association, and specialization are taken from UML 2.0…” (2.4 Relationships)
The paradox seems to be “inherited” from UML where some modelers, trying to overcome it, talk about “weak” and “strong” compositions while others just consider composition as a particular kind of aggregation… (Languages create paradoxes trying to solve others!)
Thanks a lot gctwnl: The puzzle, the hints, the answer with needed explanations as well as all the above valuable discussion were very helpful and very instructive. In deed, thanks to all and best wishes for the starting 2014…
LikeLike
The ‘strong’ concept of composition (versus aggregation) in UML comes from the fact that both memory leaks and references to freed memory come from memory sharing which the UML composition tries to prevent by making ownership clear.
When UML was developed, these memory problems were some of the most important and pressing problems in much of software engineering, leading to the most bugs. Nowadays, with smarter runtimes/environment with garbage collection and such, these concepts have become slightly less important in the minds of many developers. The system does it for them.
It remains a question if such a forbidding of ‘sharing’ or ‘multiple ownership’ is valid in Enterprise Architecture. Memory sharing might be a bad thing in software engineering (in most cases, that is unless explicitly desired), sharing is real in the real world that EA tries to model. So, one can wonder if ArchiMate should fully copy this software engineering viewpoint to EA.
LikeLike
Mmmm, I beg to differ. The specs don’t *explicitly* not exclude derived relations in the one-owner rule either, as far as I can see. If they would, then composite relations can *never* be part of derivations, whereas section 7.4 explictly includes them. Reasoning ad absurdium, it follows that derived relations *have to* be excluded from the one-owner rule.
And it seems logical to me to do so. The derived relation does not imply actual ownership after all, but derived ownership. Without this, my (modeling) life would seriously be more complicated, so I think I will stick to them… 🙂
LikeLike
Of course we still use the useful derived relations (for me: especially when designing patterns). And I agree that it is pretty logical to exclude derived relations from the one-owner rule (or drop the one-owner rule and allow true ‘sharing’).
It is not so that composite parts can never be part of derivations. The only problems are with derivation that consist of composite relations *only*. Every other relation ‘downgrades’ the derived relation to something else. If you build a large tree of business objects compositing other business objects, you get the same effect, for instance.
But as literally stated in the standard now, the contradiction is there.
LikeLike
“The orange and red Composition relations derive the blue Composition relation. 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). ”
So according to this interpretation of the standard you cannot have more than one level of composition in ArchiMate: If A is composed of B then B cannot be composed of C, otherwise A would be composed of C by derivation and C would have two composite parents A and B. Was this really intended when writing the specs? I cannot see why imposing such a limitation. Real complex systems have mutiple nesting levels.
I would then want to exclude derivations from the “no 2 parents” rule and just guess that this is something the standard has just missed to specify.
Am I missing something here?
PS: slowly making my way into ArchiMate and found this excelent blog where I can finally start making sense on how to use this language (as opposed to the dictionary/grammar book like content of the specs). Just ordered the book too :). Great job!
LikeLike
You missed nothing. This is the answer for many.
Btw, at the end of the book you’ll find that I would just drop the ‘no multiple parents’ rule for composition altogether from ArchiMate. Arguments can be found there.
LikeLike
A derived relation is not a “direct” relation. Say that [System] Calculation (Application InternalInterface) is “indirectly” composed by [System] (Application Component) is true, because if you delete [System] (Application Component) then [System] Calculation (Application SubComponent) is deleted and then [System] Calculation (Application InternalInterface) is deleted.
LikeLike