Two questions related to the pools.
1. A Pool (participant) can depict a Partner Entity (Org. unit) according to BPMN allocation diagram method. But it can't depics a System, Module or Block (Application System Type) or any other thing that a pool can represent. My question is:
(To SAG people) What was the reason for such limited implementation? And of no, is it in the pipeline?
(To the community) Any ideas of workaround?
2. Participants behave quite like a library object. An ARIS user would expect to have a participant definition with occurence in many collaboration diagrams. Well, not in cases when Participant represents a process but when it's clearly an organisational unit. However, this shouldn't be done. At least in the current BPMN implementation in ARIS. If occurrences are used, then a participant which is multiple in one collaboration will appear as such in all, including those that it is single in reality. The same applies for "process"-attributes that are maintained as poll attributes.
On the other hand having one and the same participant as definition copy in every collaboration limits many of the ARIS advantages. You can't even see in the relations and occurrences tab, what other things this Participant does in other situations.
That could be partially solved via BPMN allocation diagram and some nested queries. But I don't find it an elegant way. Other ideas, thoughts?
Ivo, the reason for 1 is easy - we implemented the spec. The partner entity and role are the only 2 cases that are mentioned in the specification. However I see your point in extending the Allocation Diagram (which is not a model type in the spec). The other use cases you mentioned (e.g. Systems) are mentioned for lanes in the spec if I remember it correctly and not for pools. So that is the reason why there is no mapping for it.
However, have you tried a matrix as a workaround?
The rest of your post gets a little blurry for me: if you like to reuse the partner entity, why don't you just use an occurrence copy of the pool again? The usage of pools for processes is something that is common (and as you know, I think it is a fair use for non-executable processes), but not part of the spec - a process is no participant and pools represent participants. Remember: the only purpose of the BPMN notation is to map a process for execution (chapter 7 of the spec). You -and most likely thousands of others around the world- try to do something with BPMN that is most likely out of scope of the specification.
Roland,
Thanx for the matrix tip.
And regarding the use of participant occurrence, I think I explained that:
If occurrences are used, then a participant which is multiple in one collaboration will appear as such in all, including those that it is single in reality.
Example. You have a participant which is multi-instance in one collaboration. You maintain one of the attributes the "Participant multiplicity attributes" group, say Multi-instance Participant = "True." Then this attribute will be "True" even in collaborations where the same participant is engaged as a single partner.
That's correct, since you are using an occurence. I never encountered that situation, so I don't have a "solution" for this. Is it possible that you change your model, so that you can avoid to repeat the occurrence?
This is, again, the beauty of BPMN since a BPMS does not "think" in reusable parts but is only concerned of *that* single process that shall be automated.
