Which best design practices do you recommend to connect BPMN models to one another?

Hello Gaelle,

interesting topic with a lot of different aspects to discuss. First of all my question: Which model type are you using? I think you customized an existing model type? Because considering the standard BPMN 2.0 notation (e.g. Enterprise BPMN collaboration diagram) what you are doing is not allowed. If you want to stay within the standard you have to use pools where the sub-process "Plan deliveries phase" and "Complete phase X" are embedded. Then message flows from the sub-process to the start event or from the end events are possible. This is a very common way to solve your use case based on standard BPMN.

Do not mix the "technical" possibility of ARIS to create assignments from each object to another model with the described functionality in BPMN. BPMN only knows sub-processes and call activities to create a hierarchy of processes (sub-process) or to use reusable processes (call activities). So another common way is to model top down starting with a "big picture" as model containing only connected sub-processes and then modeling the details in lower steps of the hierarchy. In your case you would have in the big picture three sub-processes  "Plan deliveries phase", (the process in the middle also as sub-process) and "Complete Phase x" linked to three detailed models.

If you do not want to use BPMN on higher levels, you can use any other model type like "value-added chain diagram" to present an overview about you process landscape and branch to BPMN models in the lower levels for details. 

These are some ideas.

Regards

Klemens

Hi,

The approach you've sowed on the first picture is absolutely doable. If client wants to use BPMN, then interfaces are required. We practiced these approach many times for many projects and it works well

However, there is nothing perfect, so there are things you have to know about this approach.

1. We prefer to use a standard ARIS Interface symbol for this purpose (just in respect to ARIS traditions)
2. The Enterprise BPMN Collaboration diagram should be used.
3. I recommend deriving the Task symbol for this purpose, never a sub-process (just best practice).
4. You must also create derived symbols from the intermediate event for start/end events.
5. Assignments should be used only for the interface, never events. Also, it is crucial not to create assignments from interface to another diagram, but to reuse (copy as occurrence) this object from your architecture model, and only after that change the symbol for the copied object.

The approach works very well. It allows you, for example, to check E2E integration with custom reports, analyze E2E flow, etc. But there are few things you have to know also:

1. BPMN Export works well, but all these custom objects will be exported as tasks. IMO, this is absolutely not a problem.
2. BPMN Collaboration diagram behaves weirdly when, for example, one user has opened a model (in edit mode) with an already used interface, and another user cannot change the symbol for the Task for the same object. This issue happens only with this kind of diagram, but I will not say it is a bug. You just need to know about this behaviour. 

@Alexander: But it is NO BPMN standard und does only work with the ARIS tool.

I am an ARIS fan, but I always try to find solutions that are conform with the BPMN 2.0 Standard. For sure this is a customer decision to be tool independent or not.

Regards

Klemens

Enterprise BPMN collaboration diagram is also NOT a standard. So if you extend something non-standard, it becomes a little more non-standard )

But as I mentioned, the model itself still complies with the standard, because you can export it and then import it to BPMS (e.g., we used ARIS as EA storage, and exported some models to Bizagi BPMS). Again, in the case of BPMS, you have to delete those interfaces after import, but I do not see any issue with this.