Process Is The Main Thing

@ Anatoly Belaychuk’s BPM Blog

Interprocess Communications Via Data

Here is a test for my readers.

Question: What BPMN elements may be used to model interprocess communications (mark all correct options) -

  1. sequence flow
  2. message flow
  3. signal event
  4. conditional event
  5. association

Answer: click to see the answer

Comments to the answer:

Control flows can only connect objects within a same pool, so option А is wrong. Messages, by contrast, connect objects in different pools and/or pools themselves (starting or ending at the pool boundary), so option B is the “most correct”, so to say. Option C is also correct, see my signal usage examples.

An example of interprocess communication via conditional event:

The purchasing process checks whether a budget for the given period is approved and if not awaits for the approval. When the budget is approved the purchase is made or not depending on whether it’s secured in the budget. The budget approval is a separate process: when the budget is approved, the process sets the appropriate attribute to “true”, and this same attribute is checked by the purchasing process. In this example two processes interact via conditional event hence option D is correct, too.

Please note that “Budget Approved” trigger fires only when the boolean expresion defined for it changes its value from false to true. It means the following scheme will not work:

If the purchasing in the above diagram happens when the budget is already approved, the process will wait for the trigger forever.

One instance of the budget approval process has an impact on multiple instances of the purchasing processes awaiting the event in this example. BPMN signal works in a similar manner so let’s try to use it for the task:

But it won’t work either. The point is that we are interested not in some abstract budget approval but in a budget for the period defined in the particular purchasing process instance attributes. It’s possible to write a boolean expression for the conditional event that will do the job but in a case of a signal we should define it at design time so we can’t tie the signal to a specific budget item.

Anyway both signals and conditional events support by BPMS vendors is very limited so better not count on them if you are interested in process execution.

Now let’s consider the final option E: do you think interprocess communications may be modeled with associations? My answer - not just may be but should be! To be precise, the value comes not from associations themselves but from data objects connected to the process activities by associations.

Here is an example:

It’s a typical pattern of interaction between customer order process, production scheduling and production. The key point: production has its own rhythm, it does not rush immediately to fulfill a customer’s order. Instead, customers order are converted into production orders, the latter are stored in the database for some time, and then at some regular intervals (e.g. daily) the production planning process starts which calculates a production schedule for given production orders. As soon as the schedule is fulfilled instances of the customer’s order process receive messages that the order is produced and theу proceed to delivery. Two methods of interprocess communication are involved in this case: via data objects and messages.

Generally speaking, these two methods are the most essential. But unfortunately, interprocess communication via data is often neglected.

According to my observations, most business analysts are interested only in the sequence of tasks within a single process (orchestration). If they ever use BPMN data objects they do it to show the data flows between process tasks. Yet data objects are more valuable for modeling interprocess communication.

I strongly recommend starting a process work from a process architecture, hiding processes internals within collapsed pools. Only collapsed pools connected by data objects and messages - here the previous diagram:

It makes no sense to get into the orchestration until you’ve got a clear picture of processes interconnections by data flows and messages.

In BPMN 2.0 a new Data Store element was introduced which is more suitable for interprocess communication modeling:

But I personally don’t have much need for it: If you are within BPMN 1.x then use a good old Data Object and just label it with say, “Production Orders Database”:

11/12/10 | Articles | , , ,    

Comments (9)

  1. AS 11/13/10 01:06 PM

    About the diagram for the option E - may be add a version with two start events or one event-based gateway (as in the CPP pattern) in “Production Scheduling” process and compare pros/cons for the both versions.


  2. Anatoly Belychook 11/13/10 03:31 PM


    Sorry, don’t get your idea: what two start events are good for in this example?


  3. AS 11/20/10 01:17 PM

    Sorry Analoty for not being explicit enough - I referred to the Collect and Periodically Process – CPP pattern from my book 11.9.7. See -


  4. Anatoly Belychook 11/20/10 08:14 PM


    Thanks for the clarification.

    Yes it’s similar but you follow very “intalish” style of modeling that associates pools with performers. For me (and some well-known BPMN specialists) pools are processes or external instances, see


  5. AS 11/21/10 10:17 PM

    In many illustrations from the book, pools are used to make the coordination explicit. So, it is important to show to each participant his/her/its contribution in (or the view at) the coordination. Similar to that each member of a ballet dance has to learn his/her own “partie”.


  6. Виталий 11/22/10 06:31 PM

    А как на Ваш взгляд наилучшим образом отобразить исполнителя на диаграмме процесса. Может с помощью Lane?

  7. Anatoly Belychook 11/23/10 12:18 AM

    Конечно, они именно для этого предназначены.

  8. Bruce Silver 11/25/10 03:04 AM

    I agree with your main point about communicating via shared data — in BPMN 2.0 must be dataStore not dataObject — but I think clarification needed when you say it is “often neglected.” It is often neglected in BPMN diagrams; in actuality, it is far and away the most common way processes communicate with each other. BPMN has a rich visual language for sending messages, waiting for messages, interrupting on messages etc, but nothing equivalent for common data read or write operations. So in that sense the notation “favors” messages over data, even though data sharing is more prevalent.

  9. Anatoly Belychook 11/25/10 09:44 AM


    Exactly! If explicit process is the target then we must diagram communications via data. Yet people use data objects mostly to decorate orchestration (in many cases excessively for my taste) but very rare if ever to show communications between processes.


Comments are closed

Copyright © 2008-2017 Anatoly Belychook. Thanks to Wordpress and Yahoo.  Content  Comments