Chapter 10. Creating parallel processes 247
Wholesaler A and Wholesaler B are contacted at the same time. The scenario is
The order clerk places an order for a part number and a quantity.
Wholesaler A is contacted for its delivery date.
At the same time, Wholesaler B is contacted for its delivery date.
Once both wholesalers respond, the system can determine who the best
wholesaler is (that is, which wholesaler can deliver the most quickly).
The order is placed with the best wholesaler.
After the order is successfully placed, the best wholesaler, confirmation
number and the deliver days are returned to the order clerk via the application
that was used to start the process.
10.3 General design guidelines
All of the design considerations listed in the previous scenario chapter apply to
the Parallel Process scenario as well. By getting the delivery dates from the two
wholesalers in parallel, we are potentially shortening the time it takes to complete
When the defined business process allows it, having the process manager split
the process into two or more paths of parallel processing is often desirable. For
long-running processes, cycle time reduction is in constant focus for business
executives. Since business processes should support a customer in some way,
shorter cycle time in processes usually equates to an organization being more
responsive to its customer.
10.3.1 Design overview
This scenario is an implementation of the Process-focused Application
Integration::Parallel Process pattern.
For information about the Parallel Process Application pattern, see:
3.4.8, “Parallel Process Application pattern” on page 61
For information about the Parallel Process Runtime pattern, see:
5.1.3, “Parallel Process Runtime pattern” on page 88
For information about the Product mappings of the Parallel Process Runtime
5.2.3, “Parallel Process Product mappings” on page 98
248 Patterns: Serial and Parallel Processes
This scenario is an implementation of Stage One of the ITSO Electronics
integration project. For information about the use case and actors used in Stage
6.2.1, “Stage One: Internal ordering on demand” on page 110
10.3.2 Design considerations
The following design decisions need to be made when considering whether to
use the Serial or Parallel Process pattern.
How much parallelism?
In our scenario, when the decision to contact the two wholesalers in parallel was
made, it was relatively easy to implement. Splitting the workflow into two parallel
paths is quite common and does not introduce much complexity.
However, consider a scenario that the logical model (that is, the to-be business
process) dictates that the process can run in, say, 10 parallel paths. Should the
implementation of the process support the 10 parallel paths?
Similar to a data model, there should be some level of
normalization of the
process that needs to occur for both performance and complexity reasons. In an
automated system process (either a short or long-running process), if there is no
urgency to have the process complete as quickly as possible, the process should
be normalized into some serial and some parallel processing paths. This is easy
to accomplish when there isn’t an urgency to complete the process as quickly as
If there is an urgency to complete the process quickly, then consideration for the
performance and complexity of implementing a process this way needs to be
From a performance point of view, the modeler must understand what resources
are required when the parallel processing occurs. You should ask yourself the
If more than one of the activities executing in parallel are requesting the same
resource, have we just created a bottle-neck in the process?
Can the requested resource handle all of the requests from this process at
What if there are more than one of these process instances running at the
same time? Have we overloaded the resources we are calling with too many