Thanks to Jean-Baptiste Sarrodie, the ArchiMate Forum Chair, at the close of yet another interesting year, I present you with a new ArchiMate Quiz question.
The image — presented here in Mastering ArchiMate colours — is shown here:
And the question is: “This Trigger relation is allowed in ArchiMate 3.0.1. But it is not a core relation. So it has been derived. The question is: How?”
The most entertaining or insightful answers, presented below in the comments section below, have a chance of winning a free PDF copy of my books.
Enjoy.
R&A IT Strategy & Architecture 
Here’s my potentially flawed (overly complicated) solution:
To solve this puzzle I went through the Location element because you can’t directly span layers with Triggering because Realize and Serving are weaker relationships than Assignment and you can only derive Triggering relationships through Assignment:
First constructing the business side:
* Location(L) Aggregates a Business Actor(A) assigned to Business Function(BF) that is Triggered by the Business Process(BP)
* Location(L) Assigned to the Business Function(BF) – a[L] aggregates b[A] assigned to c[BF] => a[L] assigned to c[BF] – weakest structural/dependency relationship
* Business Process(BP) Triggers Location(L) – a[BP] triggering b[BF] and d[L] assigned to b[BF] => a[BP] triggers d[L]
Next constructing the application side, which is identical to above with the only difference being the direction of the Triggering between the behavioural elements:
* Location(L) Aggregates an Application Component(C) that is Assigned to the Application Function(AF) that Triggers the Application Process (AP)
* Location(L) Assigned to Application Function(AF) – a[L] aggregates b[C] assigned to c[AF] => a[L] assigned to c[AF] – weakest structural/dependency relationship
* Location(L) Triggers Application Process(AP) – a[AF] triggers b[AP] and c[L] assigned to a[AF] => c[L] triggers b[AP]
This leaves us with Business Process(BP) Triggering Location(L) Triggering Application Process(AP) so finally:
* Business Process(BP) Triggers Application Process(AP) – a[BP] triggers b[L] triggers c[AP] => a[BP] triggers c[AP] – Triggering is transitive
LikeLike
Here’s a graphical view of the above: https://photos.app.goo.gl/jqi9Z35kYjmAnB757
LikeLike
I was sorely tempted to say that triggering could be derived from flows, like this,
Business Process —flow–> Business Event —flow–> Application Process
But there is no causal relationship to be had that way.
So, I’ll go instead with Access. The Access relation “indicates that a process, function, interaction, service, or event ‘does something’ with a passive structure element”.
Business Process –write–> Business Object –read–> Application Process
Here, the AP actively reads the BO which implies that something occurs in the AP.
We could associate the Business Object to an Event for clarity if needed because when I think of triggers, I think of events.
LikeLike
We’re not talking about triggering in a natural language sense, but in the formal ArchiMate grammar sense, thus the formal use of ArchiMate’s Trigger relation.
LikeLike
Good thing I already own a PDF copy of your book :-).
The formal model of ArchiMate is a bit sketchy and I don’t have time right now to learn ORM in order to do a proof. Talking about execution in ArchiMate is difficult, but triggering requires causality and therefore some kind of precondition to an execution.
I think this is how it might progress.
Using temporal logic, I would assume that it is possible to show that any number of more complex patterns arrangements of ArchiMate models imply that BP (eventually) leads to AP. If we assume that the triggering relation means P leads-to Q, then a proof should be possible where any number of other relationships spanning many intervening concepts causes P leads-to Q to be true. There would need to be some expression of execution and I think that would rely on ArchiMate functions in BP and AP (above).
Assume there exists a function BPf in BP that introduces some external concept (via an interface or other means, perhaps as simple as something on a flow). For example BPf might write to a business object or we could say it raises an event (but that would require us to use triggering). Assume there is a function APf in AP that can detect that external concept (e.g., perhaps the occurrence of an instance of a business object or an object with very specific attributes filled in) and executes in AP to initiate AP’s internal behavior as the first function in a chain of functions that make up whatever AP does. Assume that BPf can occur in some “normal” execution of BP – that is BPf is reachable so under some execution it can actually cause all this to start.
LikeLike
“If we assume that the triggering relation means P leads-to Q, then a proof should be possible where any number of other relationships spanning many intervening concepts causes P leads-to Q to be true.” Certainly, but that is a private (even if it is logical) interpretation of ArchiMate that is not supported by the formal ArchiMate standard. It might be interesting input for a discussion of the standard by the ArchiMate Forum (deriving Triggers from other relations, such as dependency relations). But it is outside the scope of ArchiMate, the standard, and this out of the scope of this quiz question.
LikeLike
just came across this… and didn’t see an answer…. so here goes
‘business process a’ triggers ‘business process b’
‘app function a’ triffers ‘app function b’
‘app function a’ realizes ‘business process a’
‘app function b’ realizes ‘business process b’
dynamic relationships can cascade backwards through structural or dependency relationships.
so
‘business process a’ triggers ‘app function b’
LikeLike
just realized your question was using app process and not app function… that’s a 1 for one switch ‘app function a’ replace with ‘ app process a’ and ‘app function b’ with ‘app proces b’ DOH!
LikeLike
For a short while I though “how did I overlook this?”. Then I did not when checking in section 9.2 of Mastering ArchiMate. Then I did again. And then finally I did not. Long story short: for Triggering, you may only move up an endpoint along an Assignment, not along a Realisation.
You can read the full answer here: https://ea.rna.nl/2019/01/15/two-celebrations-and-the-new-years-eve-archimate-quiz-answer/
LikeLike
Thnax for the reply this has been a fun exercise in thinking through derived relationships (something i hadn’t really ever done)…
But that poses the question Would you mind supporting your assertion that “you may only move up an endpoint along an Assignment, not along a Realisation”? i trust your correctness i’m merely looking to extend my knowledge of the standard. 🙂
LikeLike
Section 5.6.2 “This rule also applies for a triggering relationship, but only in combination with an assignment relationship (not with other structural relationships)”
LikeLike