The last quiz was quite a while ago I am sorry to say. But today I am offering a new one. My quizzes in the past often where there to illustrate some weirdness in ArchiMate or something that could trip you up. This time, to answer it correctly you need at least to understand ArchiMate 3.1 pretty well as the questions are somewhat cryptic. In case you are not very experienced, wait for the solution as it will explain matters in detail.
[Update 23/7: I accidentally used the wrong images, being sloppy. Thanks for spotting it Jean-Baptiste.]
The quiz is about the following two diagrams, this one:
and this one:
The quiz consists of the following questions:
- ‘What’ do these diagrams illustrate about the ArchiMate language? (One point)
- How many of these ‘whats’ are there? (One point for a good answer, one bonus point for the number of additional ‘whats’ that makes it complete)
- What analytical observation can be made about frameworks in general and ArchiMate in particular related to the above and what is the cause of this? (Open question, points awarded by the jury (me) based on cleverness, wit, meaningfulness)
Answers to be given in the comment section below (answers elsewhere do not count). Prize awarded when there is at least a valid answer that covers 1 and 2.
Winners [Update 6 Aug 2020]
The official answers are in the follow-up post: The Answer to the July 2020 ArchiMate Quiz.
Nobody gave a valid answer for 1 and 2 as requested (I think Jean-Baptiste, who was of course correct on #1, simply forgot to answer #2). But not giving a prize is a downer, so I will be awarding two coupon codes for a free download of either or both of my books (if the winner already has my books, the coupon code can be given to a colleague, friend, lover, boss, framed and hung on a wall, you get the idea). So the winners are:
- Jean-Baptiste Sarrodie for answering #1 correctly
- Hans Bosma for giving the best (succinct, but best) answer to #3
Coupon codes coming up. Congrats.
R&A IT Strategy & Architecture 
1) Both diagrams show a wood stack composed of planks, plus a contract for the sale of one of them. Colour has no inherent meaning in ArchiMate, but other answers indicate that the red and orange directional associations are to be interpreted as derived relations. Assuming this is so: Diagram A shows a directed association between contract and plank, but from this you cannot derive the red directed association between contract and woodstack, as the direction of the composition is left-to-right. Thus, even while a contract is associated with a plank, the diagram cannot be used to conclude that the whole stack can be sold. In diagram B, the orange directed association _can_ be derived, meaning that if one means to sell stacks of wood, then ArchiMate could be interpreted to mean that individual planks could also be bought.
2) I see one major issue with the language, and some connected minor ones:
– major: deriving a relation if you’re not the modeller can lead to incorrect or absurd interpretations
– minor: as a modeller, it can be hard to precisely express what you mean/want. How do you express the precise scope of delivery?
– there’s the Sorites paradox: how many planks constitute a stack? ArchiMate cannot handle vague predicates like heap and stack.
– Also the plank here is one example of what I regularly encounter: is a model concept meant as a singular concrete instance, or does it stand as representative of a group (of either discrete or unknown size).
4) On perhaps a different note, I’d have preferred aggregation instead of composition, as a plank can exist independent of the wood stack, and a plank that’s part of the stack will remain a plank even if we dismantle the stack (of course assuming that my interpretation of the labels is correct). Or maybe that’s your point, that “the stack is the plank”? Then the composition is a really subtle clarification, and very very few model consumers will get it :-O.
LikeLike
Hint: It’s not about Composition versus Aggregation. Hint 2: if you answer number 1 correctly, question number 2 will be a clear question. Hint 3: 1 and 2 are not about Sorites, but the answer to number 3 could mention it.
Everybody is free to answer multiple times or it would be unfair to those that go first.
LikeLike
Thanks for another fascinating deconstruction of modelling logic, Gerben but having read the answer I’m still stuck with the feeling that a large part of the inconsistencies that you identify result from the initial decision to model the Woodstack and Plank as a composition of resources – as pointed out by Jan but not fully addressed.
The ArchiMate specification mirrors UML in distinguishing composition from aggregation on the criterion of “existential dependency”. This can be determined from questions such as “Can the elements exist independent of each other?”, “Does the destruction of one cause the destruction of the other?” …
So for me composition would be applicable to describe the relationship between an egg and an omelette – but since a Plank can have an existence independent of the Woodstack, it’s not the reality here.
The other issue is that the Woodstack is a collective concept rather than a thing representing more than the sum of its parts. (Is it a Woodstack of n Planks or n Woodstacks each with a single Plank? Does the Contract specify a Woodstack or the purchase of n Planks?)
In summary, I’m not sure that modelling the Woodstack is necessary at all – but if so, would be better modelled as a Grouping.
So back to the quiz ….
When you say that
“Our ArchiMate-valid derivation right tells us that if a plank is sold, the woodstack is sold — but we cannot know that! ” – I’d argue that this is a logical consequence of existential dependency, stemming from the choice of composition.
And that “when the woodstack is sold, we are not certain that each plank of it has been sold” — again; yes we are because the existential dependency of composition requires this to be so.
Again – thanks again for your insights. Rest assured that you’re not alone in trying to make sense of derivation rules and your 2200 words are valued & worthwhile 🙂
Just need to be sure that we are staring from the best possible examples so that the flaws are truly part of the language and not due to sub-optimal design choices.
LikeLike
On composition: for me, it doesn’t mean ‘no independence existence’ per se. Even a leaf when taken from a tree has an ‘independent existence’ (it is still that material object, even if it will now behave differently). Composition is about ‘who owns’. The rule is: if the destruction of the parent means destruction of the child, then it is a composition. E.g a wheel has ‘independent existence’, but when it is attached to the body of the car it becomes a composite part of it. This is in line with ownership in (OO) software engineering. If I destroy a ‘car’ object, the wheels are destroyed too. If I build a car object, I also build 4 wheels and make the car object the parent of the wheels. These are compositions. If they were aggregations, destroying the car would leave the wheels ‘dangling’. Burn the woodstack and the plank is burned, so composition is OK. But the whole example would have worked with Aggregation as well (same derivation). So the Composition versus Aggregation is not what this (IMO clearly) is about.
Secondly, we should not make matters more complicated then necessary. The example was meant to show a ‘sale of a woodstack’ versus a ‘sale of a plank that is part of a woodstack’ and that you can derive the latter (plank is sold) from the former (woodstack is sold) and not vice versa, while the derivation rules of ArchiMate says differently.
I stand by the conclusion that the whole issue is irrelevant for modelling. We should not get ‘bewitched by logic’.
LikeLike
Assuming the colouring of the associations imply derivedness?
LikeLike
Bingo. But that is not the answer. It is where the answer is.
LikeLike
I won’t try to answer yet (might be unfair maybe) but just to be sure: did you take B.4 into account for your quizz ?
LikeLike
Oops. I used the wrong images and I was sloppy. Corrected. Thanks for spotting it.
LikeLike
1. The diagrams seem to illustrate derived relationships in the same way they are illustrated in the sections B.2 and B.3 of the specification. More specifically derivation between structural and dependency relationships, but it might be derivation in general.
2. There is one derived relationship in both diagrams.
3. Naturally one can make multiple analytical observations. As always, it is somewhat hard to guess the exact observation the jury has in their mind. Perhaps something related to deductive reasoning.
LikeLike
1) The “what” concerns Archimates ability to model explicit and implicit knowledge, and abstract and more “specific” elements of a business (“plank”). If “Plank” were Embedded into “Woodstack” the serving relation to “Stack” is implied.
2) how many ‘whats’.
– the use of derived relations to show hidden connectedness
– colours play no role in the language
– Archimate adopts a number of UML principles (aggregation and composition and ‘uses’)
– level of detail is as specific or broad as required
– the ability to link different architectural “layers” with each other thereby creating traceability
– the order of elements in a diagram plays no role; read the diagram from any starting element
3) observations about frameworks.
Well no framework can cover Specifics of a business domain or industry AND bee generic to cover other domains. Yes there are frameworks such as BIAN, but you’d certainly not use that to model a watering system for your two new Poochies you bought for your daughter and thought “ah! This would be an excellent opportunity to teach her about Archimate! Oooh we gonna have soo much fun modelling the water system and automatic food dispenser!” Nay! You’d more than likely look for a framework that has the SPECIFICS semantics you require for “hose”, “poochie paw activation button” and “dry feed dispenser”.
For that reason, Archimate can only present GENERICS found commonly across business domains and industries, yet provides flexibility to extend the framework to represent those elements fundamental to the Pooch Feeding Trough.
Frameworks serve as a starting point but must provide ways for extension. Think “UML Profiles”. Think “.net software framework”, “java” etc. These are mere frameworks to BUILD (“model”) something they were not designed to from the start. In this way, developers use the framework to build new things not inherently “supported” by the framework.
Another point is that frameworks must be easily understandable to a wide audience lest they run the risk of being esoteric in presentation or knowledge. The more closely a framework is to accepted “norms” or “expectations”, the easier it is for a wider adoption. In Archimates case, the visuals are not that different from accepted norm, UML. Given that large numbers of business people and developers will have touched UML in their careers, implies an easier adoption and lower barrier to entry regarding reading Archimate architectures.
LikeLike
Woodstack = collection of one or more planks.
Plank = an item in woodstack.
1. a) Each plank has associated sales contract which are collectively part of Woodstock sales contract. b) each Woodstack has sales contract which can be drilled down to each plank in it.
diagrams show how association (or any other relations) can be propagated between levels / depths of elements.
2. Two, material woodstack and a sales contract.
3. Diagrams shows beauty of Archimate when it comes to deal with abstractions, also Breaks common IT myth of layers, here physical layer element is directly involved in business.
LikeLike
First about the concepts. A Plank is a type of material, so there is not much confusion in that. A Woodstack is different. A woodstack is a collection of Planks, which maybe would be better modelled by a Grouping relation.
Let’s start with the assumption that the red association in Diagram A is a derived relationship. Then, the diagram says that a Sale contract is associated with a Plank. It does not say how much Plank’s can be in that Sale contract – one or more. It could be the case that there is a restriction that a Contract always con-cerns one Plank, which is rather silly but one does not know. A Woodstack is Composed of Plank’s. If there is an Association between a Plank and a Contract, one can not derive (according to Rule PDR 5) that there is also an association between a Sales Contract and a Woodstack. The modeller decided that also Wood-stacks can be sold, but it is not a valid derived relationship in this case. So Diagram A is wrong in my opin-ion.
Suppose the orange relationship is also a derived relationship. Then there is a Contract for Woodstacks. One may derive that having a contract for a Woodstack, one also has a Contract for a Plank. But, one may have a discussion about it because it may be that Sales contracts never refer to Plank’s.
Then again. Colour has no meaning in ArchiMate. So automatically one can not deduce that the colour means anything. And then, diagram A and B are both valid models.
1. ‘What’ do these diagrams illustrate? I think that there is meaning in the models to be deduced from the user, that is not really specified in the model itself.
2. How many ‘whats’ are there? Numerous?
3. That we try to model the world in a clear, unambiguous way but always will fail.
LikeLike
Ok, my turn to try 😉
I think thee two diagrams illustrate (at least) two aspects of ArchiMate 3.1:
1. The difference between valid (diagram A) and potential (diagram B) derived relationships
2. The impact of association being now a dependency relationship re derivation rules
Re #1, in short, ArchiMate says that any dependency or dynamic relationship starting or ending at an element which is part of a whole, can be derived to start or end at this whole with a very high confidence (e.g. traveling/flowing from Amsterdam to Paris also means travelling from Amsterdam to France, because Paris is part of France). On the other hand, if any dependency or dynamic relationship starting or ending at an element (whole) which can be further decomposed, can be derived to start or end at any of the sub-elements of this “whole”, with a low confidence (e.g. traveling/flowing from Amsterdam to France might mean that you’re traveling/flowing from Amsterdam to Paris, but it could well be Amsterdam to Lyon, or…).
In these diagrams, I assume (even if I know that color as no meaning in ArchiMate) that the black association is the “direct” one, and the other is derived. Of course, association, as no real meaning/semantic in ArchiMate, so my personal interpretation of diagram A is that a sale is done on a plank. Association now being a dependency relationship, ArchiMate tells me that in this case, I can derive a valid association from the same “Sale” contract to the whole wood stack. This is of course not a very valid relationship IMHO, because buying one Plank doesn’t make you the owner of the whole wood stack.
My interpretation of diagram B is that a sale is done on a wood stack. ArchiMate tells me that in this case I might (low confidence) derived an association from the same “Sale” contract to a plank. This of course is in fact a very valid assumption because buying the whole wood stack does make you the own of any plank in it.
So we (seem to) end up here with a very good example of ArchiMate derivation rules being misleading…
Or not, because all this demonstration is based on a human interpretation of an association relationship (letting aside color), while there is no meaning provided by the standard, so nobody can argue anything based on a contract being associated with a material.
FWIW, This demonstration could be done again, but using one of the few cases where association does have a (sort of) meaning. For example, a Device associated with a Communication Network means a Device which is interconnected through this network. In this case, if I have a Technology Collaboration (e.g a cluster) which aggregates the Device (off topic: did you notice that a collaboration only aggregates in 3.1 while it can also compose in 3.0.x) then this Collaboration is obviously also interconnected through the same network, so this is really a valid derived relationship…
My personal opinion on all this: any diagram, in any language can’t be automatically interpreted and used to compute (or reason). Even if ArchiMate states that some derived relationships are valid, they are just more likely to be true, but not necessary true. Modelling is mostly done for communication, and communication is not a science: you can’t know for sure how people will understand something (like color, or meaning of association). That’s one of the reason why you should have a “frame” set. And this can be through a legend, additional text, shared conventions…
But I do think that ArchiMate helps a lot by providing a very good language to start with 😉
LikeLike
The winners have been added to the main text above.
LikeLike
FWIW, thinking about it a bit more. I think the main issue here is thefact that association can mean whatever we want, but is still classified as a dependency relationship. In your example, association is not really used as a dependency, but more (IMHO) as a structural relationship, which might be another reason for the rule to fail. But anyway, I’m sure there is some other example where it would fail, even with a “pure” dependency relationship.
LikeLike
It is the ‘hidden’ second aspect of the quiz, the volatile positioning of Association. The example might be used to argue that Association is not a dependency relation, after all. It will be hard, I think, to create an example with another dependency relation.
LikeLike