CODEWITHSUNDEEP
bpmnbusiness-process-managementcamunda
Keval Doshi
Keval Doshi

Reputation: 748

Parallel Tasks vs Multiple Processes

I am trying to design systems to implement my complex business process. I am trying to decide which approach would be better considering the below scenario.

The are multiple parallel tasks that are a part of the process. Is it better to have them as parallel tasks in BPMN, as described in the first image or have multiple processes that are interacting with each other as described in the second image?

The systems being de-coupled in the second diagram gives me the freedom to change things w/o worrying too much about the consequences to the entire process. Something like Microservices.

I am not limited by the system but as of now I am planning to use a combination of Camunda and custom APIs which generates triggers based on business logic.

Single Process Single Process

Multiple Processess

Multiple Processes

Upvotes: 1

Views: 3352

Answers (2)

khalito
khalito

Reputation: 1149

I understood that your objective is to communicate a business process to users of a system. If so, then the first diagramme is in every way "better", i.e. it is

  • closer to the BPMN standard : The three processes in the 2nd diagramme are not communicating with each other. How does the second process know that the payment has been accepted ? You would have to add either a signal or put the three processes into separate pools and make them exchange messages.

  • more desirable. The three processes will be started at the same time in your 2nd diagramme. That means the task "Select payment method" could start (or worse finish) before you have even placed an order, which would not make any sense. As a business user (i.e. your assumed target audience) I would understand the 1st diagramme whereas the 2nd would give me riddles. The first diagramme makes the business logic more explicit and readable, which is exactly what BPMN has been developed for:

"The primary goal of BPMN is to provide a notation that is readily understandable by all business users..." (BPMN 2.0 Specification, page 1)

From your description, it seems as if your goal is actually to model a system and you are trying to adapt the business process design to reflect your system design (for example, you say that you prefer the second diagramme because the systems are de-coupled, which makes changes easier. But neither of the two diagrammes depict systems or system behaviour. The first diagramme could be implemented by using 12 systems while the second could be implemented with a single one.

If you really had to then you could use a pool for each of your three system and send messages back and forth as suggested above. But I would rather keep the 1st BPMN model (maybe with some minor corrections like the one MuffinMICHI has suggested) and use a separate UML sequence or component diagramme, where you explicitly model systems and their behaviour.

Upvotes: 2

MuffinMICHI
MuffinMICHI

Reputation: 490

If it is one process, you should model it as one process. So your first solution is definetely the better one. If you want to decouple things a bit: Instead of creating separate processes have a look at the concept of the call activity or subprocesses. With these elements you can encapsulate certain aspects of the logic and still model one whole process.

(BTW: in your first picture, I would replace the inclusive gateway with a parallel one because you also split the flow with a parallel gateway.)

Upvotes: 3

Related Questions