On The Open Group London 2013, I presented the link between BPMN and ArchiMate we have designed.
The draft version I have distributed has been removed as it will be replaced by the chapter of the upcoming Edition II of Mastering ArchiMate.
-
Follow
Following
Already have a WordPress.com account? Log in now.
R&A IT Strategy & Architecture 
Hello Gerben,
Thank you for elaborating on this challenge! Between the lines – of the draft – I read about the struggles. It’s clear to me that it’s hardly possible to talk about ‘the’ integration. It depends on choices one makes, for example which BPMN modelling level (see book Bruce Silver) is applied. So an extra challenge for tool vendors to support the integration!
Because I see what you present as ‘an’ integration, and a ‘Reply’ must not be too long, I will only touch some points.
I get the idea that you define the integration on the visual, this is the representational level. In my opinion an integration must be defined on the level of metamodels. It namely can happen that not every part of a metamodel can be visually expressed. As an example: page 146 of the BPMN specification (2.0, January 2011) tells us that the BPMN metamodel contains the concept ‘process’. So I would say – but I didn’t perform a narrow investigation – that this concept is the first candidate to map ArchiMate’s ‘Business Process’ to. I understand that from the practical way of working one might select ‘Pool’ instead. However for defining an integration that is future-proof, and hopefully supported by tool vendors, it’s better to look deeper than the visual layer. The pity is however that even BPMN itself in its metamodel doesn’t make a clear distinction between a model and its representation.
On page 131 you rightly indicate the difference between an ‘equivalence’ (let’s say an ‘is a/is a ‘-link) and other kinds of links. Equivalence means mapping concepts from the two metamodels to each other. As far as I am concerned you might have made a clearer distinction between those two kinds of links (for example in separate sub paragraphs). The distinction is relevant when you want to perform model transformations (from ArchiMate to BPMN and vice versa): only ‘equivalence’ links have then to be taken into consideration (for example linking ‘Lane’ to ‘Business Role’ – though Lane alas first must be given a meaning on the non-representational level). And I can imagine that for the ‘other’ links one has more freedom.
I totally agree with you that only having one Business Role/Actor as the performer of (assigned to) a Business Process is strange. Yes, applying aggregated roles/actors is unnatural. Does this mean you propose a change to the ArchiMate standard?
Enough so far, I think – at least to start with ;-).
Kind regards,
Jacob Vos
LikeLike
Never mind the length of replies. I like good discussions.
I do want a link where both grammars can be used in their visual sense (ArchiMate being fully visual, BPMN only in part) because I am interested in not just modeling executable processes, but documenting real business processes, for which (and I agree with Bruce Silver here) BPMN is not really perfect (but it’s the only open standard really used).
There is also an assumption in your reply that one might question. The fact that BPMN has a concept that is called ‘Process’ does not mean that it is a process in all ways one could define process (Uncle Ludwig would say: watch out for ‘bewitchment by language’). So, the choice for Pool is not driven by the fact that I want a visual representation, it has been driven by a deep analysis of the BPMN metamodel. In fact, I did start out with BPMN Process = ArchiMate Process and ran into serious problems making that work.
Multiple BPMN Pools/Participants may contain the same BPMN Process according to BPMN’s metamodel. If the Pool/Participant is the performer of the Process, than this is a way to signal that multiple participants perform a single process. But OTOH BPMN wants us to have Collaborations, so it becomes pretty unclear what two Pools/Participants, both containing the same Process means. See http://masteringarchimate.com/2013/03/29/mapping-bpmn-and-archimate-about-bpmns-pool/
And yes, I would like to see ArchiMate changed here. I think Interaction is superfluous in ArchiMate (you could use Business Process or Business Function) and Collaboration is nice from a theoretical point of view, but it does not scale well not is it easily understood in reality. The scaling problem is that every different combination of roles in your business that do something require a different named collaboration element in ArchiMate. Your business does not think like that (theoretical modellers do) for good reasons.
In fact, just assigning multiple roles to a process works fine to signal collaboration (though if the process has subprocesses, each performed by either role you get to broad derived relations, but, then again, the concept of derived relations might be revisited too, e.g. why cannot the derivation of “assigned follows composite (bidirectional)” be allowed while the derivation of “composite follows assigned” be forbidden because you can draw faulty conclusions? But then again, derived relations already have the problem of casting too wide a net sometimes). You cannot differentiate between “role A *and* role B perform process X *together*” and “role A or role B performs process X”, but that problem is all over ArchiMate (e.g. two Artifacts realising a single Data Object), which is why I propose to allow junctions (and more specifically specialised and/xor junctions) for all relations, not just flow and trigger.
LikeLike
Hi Gerben,
Good to read that you looked seriously to the metamodels. I remember now the ‘pool’ discussion.
Jacob
LikeLike
Hi gerben,
I think you have a minor typo in view 213 : “Administration department” should be a “business actor” not a “business role”
LikeLike
Wel spotted! Thank you.
LikeLike