IBM WebSphere Developer Technical Journal : Process anti-patterns: How to avoid the common traps of business process modeling, Part 1

Modeling control flow

This article describes typical modeling errors extracted from hundreds of actual process models created in different tools, including WebSphere Business Modeler. These anti-patterns cover six common process modeling scenarios. Part 1 of this article focuses on two scenarios around the modeling of control flow. We discuss anti-patterns that occur when you need to describe branching and iterative behavior in a business process model. We introduce an example illustrating typical errors, which we generalize into an anti-pattern. We then present one or several patterns that show a correct solution to the modeling scenario, and summarize our recommendation.

Jana Koehler (koe@zurich.ibm.com), Research Staff Manager, Zurich Research Laboratory, IBM

Author photo: JanaJana Koehler is a Research Staff Member and manager at the IBM Zurich Research Laboratory. She works on technologies for business process management and distributed systems, and leads the Business Integration Technologies team at the lab. Jana has contributed to the conceptual design of the patterns, refactoring, and transformation operations, and has authored the technical documentation. You can reach Jana at koe@zurich.ibm.com.



Jussi Vanhatalo (juv@zurich.ibm.com), Research Staff, IBM Zurich Research Laboratory, IBM

Author photo: JussiJussi Vanhatalo is a member of the Business Integration Technologies group at the IBM Zurich Research Laboratory. He currently works on business process management including quality assurance of process models. You can reach Jussi at juv@zurich.ibm.com.



28 February 2007

Also available in Chinese

From the IBM WebSphere Developer Technical Journal.

Introduction

As more and more people get involved with business process modeling projects, business process modeling is gaining importance in the software development community. Also more and more people with different professional backgrounds are involved with business process modeling projects. Business processes are one of the most important assets of an organization. As many enterprises begin to base their IT on a Service-Oriented Architecture [4], business processes become first-class citizens in the supporting IT systems. Business process modeling is no longer a modeling exercise for documentation and discussion purposes, but the process models become a direct input into business-driven development [10, 14]. Consequently, the process models have an increased impact on the IT systems and the operational efficiency of an enterprise, which increases the associated economic risk of using badly designed process models [2, 7, 8].

Unfortunately, no good way has been developed to measure the quality of business process models. The underlying processes themselves are usually measured with economic key performance indicators such as cost and profit. State-of-the-art modeling tools provide analytical capabilities to gather insights into these economic aspects of processes. However, most analytical tools do not address quality requirements. Sometimes, an analytical result can even be incorrect because of hidden errors in the model that remained undetected.

Review of current literature

When exploring related work in the scientific literature, we found very few papers that address the measurement of quality for process models. Guidelines of business process modeling and Komplexitätsmanagement in Prozessmodellen[2, 17] formulate six guidelines (principles) to modeling: correctness, relevance, economic efficiency, clarity, comparability, and systematic design. However, they give no quantifiable criteria that would allow a tool to directly measure the quality of a process model in an objective manner.

In Guceglioglu and Demirors’s research,[7, 8], they adopt the ISO/IEC 9126 Software Product Quality Model and measure the quality of process models based on the criteria of functionality, reliability, usability, and maintainability. Currently a human expert must use subject evaluations to estimate these measures, by, for example, assessing whether an activity in a process model is functionally adequate for the process.

An experimental investigation of UML modeling conventions describes an experimental study that measures the degree of user misinterpretations caused by inconsistencies between sequence diagrams and class diagrams [12]. It introduces several types of defects, which focus on static and syntactic aspects of models, but are not applicable to behavioral, i.e., process models.

Patterns play a very important role in the workflow community, mostly due to the pioneering work on workflow patterns as a basis for the comparison of workflow engines detailed in Workflow patterns[23]. In addition, these works investigate the role of patterns in the process of designing behavioral models:

About this article

In this article, we introduce anti-patterns for process models that let us measure an important aspect of the quality of process models in an objective way. Anti-patterns capture typical design errors in a process model, which make the process model incorrect. Wikipedia defines them as “classes of commonly reinvented bad solutions to problems[1].

By correctness we mean how well the execution traces of the process model correspond to the user’s expected behavior of the process under consideration. Incorrect models thus show unexpected and incorrect behaviors, which increase the economic risk associated with the models. Incorrect models often also exhibit a non-systematic design, their functionality is usually inadequate, and they lead to reliability problems in the implementing software. Needless to say, usability, clarity, comparability, and maintainability are also affected by incorrect models. Thus, you need to detect and correct anti-patterns in process models to improve the quality of process models and reduce their associated economic risk.

This article captures the lessons learned from reviewing hundreds of process models created in IBM® WebSphere® Business Modeler (hereafter called Business Modeler) and other modeling tools such as Aris [21], Adonis [22], or MID Innovator [6] between 2004 and 2006. The models resulted from real-world projects across various industries such as banking, insurance, retail, the pharmaceutical industry, and telecommunications.

When reviewing draft versions of these models, we noticed recurring modeling errors that we abstracted into anti-patterns. We describe each anti-pattern in this article, explain why the model fragment in this anti-pattern is wrong and show a corrected model. At the end of each section the recommendation summarizes the main insights in a compact form. We have redrawn and made all models in Business Modeler anonymous, i.e. we only show abstract names, and do not provide information about the origin of our examples or the original modeling tool. In many cases, we also explain why users unknowingly modeled their processes incorrectly, and we point to support in Business Modeler that can help you spot these errors.

This article is for users with some experience in business process modeling, in particular in modeling with IBM WebSphere Business Modeler. It assumes that you are familiar with the basics of Business Modeler as taught in the official product tutorials or courses. Most of our anti-patterns are completely independent of Business Modeler and have correspondences in other modeling languages for behavioral models such as UML2 Activity Diagrams (UML2-AD) [16], Event-Driven Process Chains (EPC) [20], or the recent Business Process Modeling Notation (BPMN) [3].

The article is organized as follows:

  • Background introduces the main modeling elements for business process modeling in Business Modeler, draws relationships to corresponding elements in UML2-AD, EPC, and BPMN, and provides the background for the subsequent sections addressing the various modeling scenarios.
  • Scenario 1: Modeling branching behavior discusses the branching and joining of parallel and alternative flows.
  • Scenario 2: Modeling cyclic behavior focuses on the modeling of iterative behaviors.

The anti-patterns and recommendations given in these sections could also be of interest to users of other modeling notations.


Background

This section reviews the main modeling elements for business process modeling in Business Modeler, and draws relationships to corresponding elements in UML2 Activity Diagrams, Event-Driven Process Chains, and the recent Business Process Modeling Notation. We then address the variability in the Business Modeler modeling language and introduce two forms of process models: models using gateway form and models using activity form, which we use as a basis to describe solutions to modeling challenges occurring in the various modeling scenarios. We also introduce our notation for anti-patterns and patterns.

Basic modeling elements for control flow

This section reviews the main modeling elements for business process modeling in Business Modeler, and draws relationships to corresponding elements in other modeling notations. We then address the variability in the Business Modeler modeling language.

Figure 1. A sample process model in IBM WebSphere Business Modeler
A sample process model in IBM WebSphere Business Modeler

Let’s look at the process in Figure 1 in detail:

  1. The process begins with a start node depicted as a green bullet.
  2. This node is connected to Task 1, symbolized by a yellow rectangle with rounded corners. A task in Business Modeler is an atomic (cannot be further refined) activity of the process.
  3. Task 1 is followed by a decision leading to two subsequent branches. When the process executes, exactly one of the decision branches is chosen, i.e., we have an exclusive choice modeled here. The upper Yes branch leads to a fork, which captures a parallel branching in the process flow. All branches following a fork get executed, i.e., Subprocess 1 and Task 2 in this model.
  4. You can further refine a subprocess in Business Modeler by using another process model. Subprocesses and tasks are the two kinds of activities that are available in Business Modeler.
  5. The parallel branches are joined again in a join, which ends the parallel execution.
  6. The lower No branch of the decision leads to an inclusive decision. An inclusive decision models the n-out-of-m choice from the well-known workflow patterns described in Workflow patterns, [23]. This means that one or more subsequent branches can be chosen for execution. In our case, either Task 3 alone, Task 4 alone, or both Tasks 3 and 4, can execute. For the first two choices, a single sequential execution path results, while the choice of Task 3 and Task 4 results in both branches executing in parallel.
  7. The inclusive branches are merged again by a merge.
  8. The join and merge elements connect to another merge, which matches the initial exclusive decision.
  9. An end node terminates the process model.

You can use the simulation capabilities of Business Modeler to visualize and analyze the possible execution traces of a process, which show how control branches in a decision, and how it leads to parallel executions after a fork.

Figure 2 shows the same process modeled as a UML2 Activity Diagram (UML2-AD) [16] using IBM® Rational® Software Architect [9].

Figure 2. The same sample process modeled as a UML2 Activity Diagram
The same sample process modeled as a UML2 Activity Diagram

Seamless integration between Business Modeler and Rational Software Architect enables software architects to visualize business process models in UML2 notation using the UML 2.0 Profile for Business Modeling[9]. This profile provides interchange semantics between business process models and existing or new UML2 models. Based on these semantics, we list the corresponding elements in Table 1.

Table 1. Mapping between elements in Business Modeler and UML2-AD notations.
Element in Business ModelerElement in UML 2.0 Activity Diagrams
Start Initial
End Flow final
Task Call behavior
Subprocess Structured activity
Fork Fork
Join Join
(Exclusive) decision Decision
Merge Merge
Inclusive decision (Decision)

Activity diagrams modeled directly by a user often also model an action instead of a call behavior and replace the structured activity by a call behavior. The inclusive decision does not exist in UML2-AD and it is mapped to the UML2 decision, which is exclusive. Thus, we explicitly added the situation to the model when Task 3 and Task 4 execute in parallel. We used a fork and join and placed additional copies of the tasks between them.

Figure 3 shows our sample process modeled in the tool Maestro [19], which implements the Business Process Modeling Notation (BPMN), a recent standard notation by the OMG [3].

Figure 3. The sample process model in BPMN
The sample process model in BPMN

Let’s look at this in detail. Similar to the previous modeling approaches, BPMN distinguishes tasks and subprocesses in the diagram, the latter being indicated by a ’+’ symbol in the rounded-corner rectangle.

  1. The process beginning is indicated with a start event, while the process end is marked with an end event.
  2. Control-flow behavior of a process is modeled using gateways.
  3. Alternative branching is modeled with the exclusive (XOR) gateway visualized as a diamond, optionally marked with an ’X’.
  4. Inclusive branching is modeled with the inclusive (OR) gateway and visualized with a diamond containing a circle.
  5. Parallel branching is modeled with the parallel (AND) gateway and visualized with a diamond containing a ’+’. BPMN does not provide any separate modeling elements to join or merge several branches in a process model. Instead, it uses the same symbols for branching and joining or merging of flows.

Finally, we modeled the sample process as an Event-Driven Process Chain (EPC) using Aris Business Architect [21]. In contrast to the previous approaches, EPC models are more commonly drawn in a top-down manner.

Figure 4. The control flow of the sample process modeled as an Event-Driven Process Chain
The control flow of the sample process modeled as an Event-Driven Process Chain

Again, we’ll look at the details of the diagram in Figure 4:

  1. The process begins with a Start event and ends with an event, which we named Process End Event. EPCs do not distinguish specific types of end events and let the user decide how to end the process.
  2. Tasks are represented as functions.
  3. A subprocess is captured with a process interface, which is a function that can be further refined by another EPC model.
  4. We did not introduce any additional events into the model following each function. Although this would be common for the EPC approach, events are represented quite differently in the other approaches.
  5. The fork corresponds to the AND Rule, the inclusive decision corresponds to the OR Rule, and the decision corresponds to the XOR Rule. Similar to BPMN, EPCs use the same rule symbols to open and close branches in the process flow.

We can see that although the graphical notations differ, the main elements for modeling control flow are very similar across the different modeling approaches. Therefore many of the following anti-patterns are also useful for users of other modeling approaches. In the following sections we focus on IBM WebSphere Business Modeler.

Gateway form vs. activity form of process models

In the previous section, we modeled the same process using different modeling approaches. Each of these models made use of control nodes (Business Modeler and UML2-AD), rules (EPC), or gateways (BPMN) to capture the control flow. Since the BPMN standard uses the term gateways, we call them gateways throughout this article when we refer to the decision, fork, merge, and join modeling elements in Business Modeler.

In addition to gateways, several of these modeling languages (we will only look at Business Modeler) offer an alternative approach to model control and data flow. This modeling alternative is based on the inputs and outputs of the activities, i.e., of the tasks and subprocesses. The inputs and outputs can be pure control-flow links as in the models in the previous section, or can be data flow links as shown in Figure 5.

In Business Modeler, you change a control flow into a data flow by associating a so-called business item with the flow. A business item captures a type of information or a data object that flows through the process. Users can freely choose the names of these business items and further refine their description by adding attributes. The type of business item cannot change when it is sent from one task to another, i.e., the output, the input, and the connection between them always have the same business item attached.

Figure 5 shows Task 1 with three different inputs of type A, B, and C, and three different outputs: one control-flow output and two outputs of type B and C.

Figure 5. Input and output criteria of a task
Input and output criteria of a task

For the inputs, we defined three different input criteria, and two different output criteria. The criteria specify the alternative input and output sets of Task 1. It can execute if it either receives all three inputs at once, i.e., A, B, C, or if it receives only B combined with C or only A combined with C. As output, it either provides B combined with C or only control output. Similar to gateways, these criteria thus describe branching and joining behavior.

By default, each task or subprocess has at least one input and at least one output criterion, because any input must belong to at least one input criterion and any output must belong to at least one output criterion.

You need to work in the advanced editing mode of Business Modeler to correctly define the required input and output criteria. This editing mode provides Input Logic and Output Logic tabs in the Attributes view. The blue boxed screenshots in Figure 5 are extracted from these tabs. In the diagram, the gray and black backward/forward arrows below the inputs and outputs of Task 1 indicate that we defined several input and output criteria for the task. If you define only one input and output criterion, no arrows are shown and we usually do not show the blue boxed tabs in our figures. The basic editing mode hides all these details, including the arrows.

An activity can execute if it receives all required inputs of at least one input criterion, otherwise it waits for these inputs to arrive. When an activity executes, it produces all outputs of exactly one output criterion. The output criterion it chooses can depend on which input criterion activated the activity. You can model this dependency in Business Modeler by associating an output criterion with an input criterion. If you do not model the associations explicitly, the activity can produce one of the output criteria in a nondeterministic way.

We say that a process model is in gateway form when it is only using gateways (called control nodes or rules in other modeling languages), but only has a single input and output criterion for a task or subprocess. A process model that makes use of several input and output criteria in the activities, but does not use gateways is denoted as being in activity form.

Figure 6 shows a process model in gateway form. Gateway form makes the branching and joining points in the model more explicit. We can also more easily assign explicit decision conditions to a decision node by editing its output logic.

Figure 6. A process model showing control flow using gateway form
A process model showing control flow using gateway form

The same control flow is captured in Figure 7 using activity form. In activity form, you capture the decision conditions as post-conditions of the output criteria. Activity form has the advantage that it makes the models more compact, and reduces the modeling elements to only the functional activities in the process. However, it makes capturing the flow logic more complex, because using and defining input/output criteria is more difficult than using gateways.

Figure 7. The same process modeled using activity form
The same process modeled using activity form

In Figure 7, Task 1 acts as a decision, while Task 4 acts as a combined merge and fork. Decision and merge are always mapped to several input and output criteria—one for each branch, while fork and join correspond to a single output and input criterion, respectively.

For models that show control flow only, both forms can be used interchangeably and the models will preserve their execution semantics. However, this only holds for control flow. Data flow contains important semantic differences that we will discuss in detail in Part 2 of this series.

Recommendations

  • Try to adopt one of the two possible forms for your models to reduce the number of used model elements. This technique leads to a more homogeneous modeling style:
    • Gateway form using decision, fork, merge, and joins is often more readable for models that only model control flow.
    • Activity form using input and output criteria, but no gateways, is more suitable for simplifying visualization of the process model by hiding the branching logic in the input and output criteria.
  • In Business Modeler, use advanced editing mode for models that use activity form to see the details of the branching flows, which remain hidden in the basic editing mode.
  • Try to minimize mixing forms in a single diagram. While you might need a mixed approach for data-flow models, it is never necessary for control-flow models.

Notation for patterns and anti-patterns

When describing the various modeling scenarios, we begin with an example exhibiting the error, which we then generalize into an anti-pattern. We also show a correction to the anti-pattern in the form of a pattern. To describe the patterns and anti-patterns we use process fragments as shown in Figure 8:

Figure 8. Process fragment notation
Process fragment notation

This figure shows our two forms of notation:

  • If the data or control flow in and out of activities is relevant to understand the cause of the modeling error, we use the notation in the upper half of the figure. In this process fragment, Task 1 receives inputs A and B and provides outputs A and B, while Task 2 receives inputs A and C and provides outputs A and D. Task 1 precedes Task 2 in the flow, but between both tasks, an arbitrary process fragment can be modeled. This arbitrary process fragment is denoted with the dotted box.
  • If data attached to the flow is irrelevant, we use blue arrows to just denote the flow direction. An example of this notation is shown in the lower half of the figure involving Task 3 and Task 4.

You can find errors in a specific process model by comparing a fragment of the process model to the process fragment shown in an anti-pattern. You can use the provided patterns to correct the matching process fragment. Anti-patterns are always marked with a big red cross in the upper left corner, whereas patterns are marked with a green check-off sign. In addition, we use red dotted circles to highlight a usage of modeling elements that is causing the error, and orange dotted circles to highlight a usage of modeling elements that is not recommended.


Scenario 1: Modeling branching behavior

Many business process models need to show how control and data flows branch and join within the process. Business Modeler offers the decision, inclusive decision, and fork gateways to describe alternative and parallel (concurrent) branching, and the merge and join gateways to describe alternative and parallel joining in a process. In principle, you can freely combine these gateways in a process model. However, some of these combinations lead to execution problems when the process model is simulated. In the following sections we systematically review the various pairings of gateways.

Deadlocks through decision-join pairs

Figure 9 shows two typical forms of decision-join pairing that we found frequently in process models. Immediately following the start node, a decision represents three alternative branches in the process flow that eventually lead to a join preceding Task 5. This structure leads to a deadlock in the process, because the decision only emits an output on one of its branches, while the join waits for input on all of its branches. This input can never come and thus the join will wait forever for the missing input and will not execute—an obvious deadlock situation. A deadlock is always a modeling error: some of the desired process behaviors are missing due to non-executable activities in the model. You can easily detect this incorrect behavior using the simulation capabilities of Business Modeler, which would show that Task 5 never executes.

Figure 9. Deadlocks caused by a decision followed by a join or by an inappropriate pairing of input and output criteria in activities
Deadlocks caused by a decision followed by a join or by an inappropriate pairing of input and output criteria in activities

A second deadlock occurs between Task 3 and Task 4 in the example. Task 3 produces A or B as two alternative outputs in two disjoint output criteria, i.e., it behaves like an exclusive decision. Task 4 requires both A and B as inputs in a single input criterion. In any execution of the process, both inputs will never be produced and thus, Task 4 cannot execute. Again, we have a deadlock situation that you can detect during a simulation of the process, when the decision selects the lower branch for execution.

The combination of a decision with a subsequent join is one of the most frequent anti-patterns that we found in business process models. Apparently, many users are not fully aware of the semantics of these gateways and of the behaviors that result from this incorrect combination. In the above example, the deadlock is relatively easy to spot. However in large examples, the branching logic can be very complicated and comprise many different activities and gateways, which makes it much harder for a user to notice these problems. You should always organize process models in a structured manner and pick either an activity form or gateway form as we described in the previous section.

The anti-pattern in Figure 10 shows a generalization of the incorrect decision-join pairing that results in a deadlock.

Figure 10. Anti-pattern: Incorrect combination of decision and join that results in a deadlock
Anti-pattern: Incorrect combination of decision and join that results in a deadlock

The two outgoing branches of the decision with all their connections end as incoming branches in a join. Of course, the decision could also have more than two branches and a deadlock would also occur when only a subset of the branches leaving the decision is rejoined by a join. We show some data flow here to emphasize that the anti-pattern can occur in models with control flow and/or data flow, and to illustrate how the connections within the single branches connect the gateways involved in the anti-pattern. A variant of this anti-pattern using activity form is straightforward and thus not shown.

Lack of synchronization through fork-merge pairs

The fork-merge pairing, shown in Figure 11, exhibits the opposite behavior of the decision-join anti-pattern.

Figure 11. Lack of synchronization caused by a fork followed by a merge
Lack of synchronization caused by a fork followed by a merge

A fork-merge pair causes too many instances of all tasks and subprocesses following the merge to execute, because the fork emits output on all of its outgoing branches, while the merge waits for input on only one of its incoming branches. This means, for each branch of the fork, the merge executes and triggers the activities further downstream in the process model. In the workflow literature, this anti-pattern is often called lack of synchronization [18, 24], because for a single execution of a process fragment preceding the merge, we obtain several executions of the process fragments following the merge. Sometimes you might want this behavior, but in most cases it is unconsciously introduced into the model. A lack of synchronization can be a modeling error if more than the desired process behaviors occur, but it’s not always an error (unlike a deadlock).

We find three pairs that cause a lack of synchronization in Figure 11. The inclusive decision following Task 1 leads to the merge preceding Task 4. The fork following the start node leads to the merge preceding Task 7. The single output criterion of Task 5 connects to two disjoint input criteria of Task 6. This means, for a single execution of the process fragment comprising Tasks 1, 2, 3, 4, 5, 6, we obtain at least two executions of Task 7. For a single parallel execution of Task 2 and Task 3, we obtain two executions of Task 4. Finally, for a single execution of Task 5, we obtain two executions of Task 6.

A comprehensive treatment of an n-out-of-m choice requires techniques such as dead-path elimination [13], which prunes non-triggered branches of an inclusive decision, guaranteeing that the matching fork will not wait for input from any non-triggered branches.

An inclusive decision captures an n-out-of-m choice [23] at an abstract level, i.e., the inclusive decision can trigger any subset of the two branches in this example. If both branches are triggered, the inclusive decision leads to a parallel execution of Task 2 and Task 3 in the same way as a fork. Task 7 following the corresponding merge would therefore execute twice—once for each triggered branch. The official recommendation in the Business Modeler help pages is to pair an inclusive decision always with a merge. Using the merge leads to a lack of synchronization because the merge will always be triggered once for each incoming branch, and all tasks following the merge execute multiple times. Using a join does not solve the problem because the join always waits for all incoming connections. It blocks any simulation run in which only a subset of the branches is chosen by the inclusive decision, i.e., a deadlock occurs.

The anti-pattern in Figure 12 captures the incorrect fork-merge pairing that is responsible for a lack of synchronization.

Figure 12. Anti-pattern: Incorrect combination of fork and merge that results in a lack of synchronizatio
Anti-pattern: Incorrect combination of fork and merge that results in a lack of synchronizatio

Each outgoing branch of the fork with all its connections ends as an incoming branch of the merge. Again, even if only a subset of at least two branches ends in the merge, a lack of synchronization occurs. This anti-pattern is also one of the most frequent modeling errors. Spotting such combinations can be very difficult in larger process models, in particular when they occur in a more indirect way by using inclusive decisions or input and output criteria with activities.

Correct branching through decision-merge and fork-join pairs

The following patterns show the correct pairings of the gateways you can use to build more well-formed process models, which are less likely to contain problems like deadlock or lack of synchronization. The two patterns represent the correct pairings of decision with merge and fork with join. Note how the two similar graphical shapes of the correctly matching gateways make it easier for you to select the correct pairing. The pattern in Figure 13 presents the correct way to model alternative branching by using a matching decision-merge pair.

Figure 13. Pattern: Pairing decision with merge is the correct way to model alternative branching
Pattern: Pairing decision with merge is the correct way to model alternative branching

The pattern in Figure 14 presents the correct way to model parallel branching by using a matching fork-join pair.

Figure 14. Pattern: Pairing a fork with a join is the correct way to model parallel branching and joining
Pairing a fork with a join is the correct way to model parallel branching and joining

Note that the decision is paired with a matching merge independent of the process fragment that is located between these two gateways. The same holds for the fork and join. There is also one matching input criterion in the merge for each output criterion in the decision, such that all the connections starting in one output criterion end in the same input criterion. Similarly, the same requirement applies to the connections between the fork and the join. All inputs of the decision and the merge, as well as of the fork and join, must be connected.

We recommend you always use gateways in their corresponding pairs. This means that every decision should eventually be followed by a matching merge, which combines all the paths starting from the decision. Similarly, every fork should eventually be followed by a matching join, which combines all the paths starting from the fork. These patterns lead to a well-formed structure for the models, which avoids many modeling errors that otherwise occur when gateways are used in an arbitrary way. Sometimes, this technique can lead to many matching pairs, which adds unnecessary redundancy to the process model by several merges or joins succeeding each other.

In such a situation, closing several decisions with a single merge and closing several forks with a single join leads to a correct model. Figure 15 shows a typical process model that has adopted such a “short-hand” modeling notation. In this example, a single merge is used instead of having three successive merges added to the model. However, such a solution should be used with care in models that contain both types of branching, i.e., forks and decisions, to avoid suddenly closing a fork with a merge or a decision with a join.

Figure 15. All branches correctly closed with a single matching merge
All branches correctly closed with a single matching merge

Redundant branches

We conclude this section with a closer look at the problem of redundant branches in a process. Figure 16 shows a process model with a decision of four branches that are closed by two succeeding merges.

Figure 16. Redundant “do-the-same” branches leading to the same subsequent task execution, in contrast to a “do-nothing” branch
Redundant “do-the-same” branches leading to the same subsequent task execution, in contrast to a “do-nothing” branch

The second and third branches both lead to Task 2 and do not involve any activity between the decision and the first merge. It’s not clear why they were distinguished from each other unless the modeler intended to separate the decision conditions, which might be required in an application that uses process monitoring. If not, this distinction appears to be redundant, because exactly the same behavior is modeled twice, i.e., the single Task 2 is executed as a result of taking any of these two decision branches. The lowest branch represents the “do nothing” case, which can occur in a meaningful way in a decision process. In contrast to this, “do-the-same” branches may point to redundancy in the model or indicate that the modeling project is not yet complete.

Recommendations

  • Never pair a decision with a join.
  • Never combine a fork with a merge, except when you want to introduce a lack of synchronization.
  • Use the decision-merge and fork-join pairs always as matching pairs and make your model as well-formed as possible.
  • When the inclusive decision is paired with a merge it can lead to a lack of synchronization when several branches execute in parallel. A safe solution is to avoid the inclusive decision and to explicitly model all possible combinations of branches using decisions and forks. If this is not possible, the inclusive decision should be used with care and the model should receive specific attention when being implemented to make sure that the control-flow logic is correctly captured in the refined IT-level model.
  • Control or data flow connections in a process model that only connect gateways to each other without involving any activities or leading to exactly the same activity executions should be examined for redundancy.

Scenario 2: Modeling cyclic behavior

In this modeling scenario we discuss the representation of cyclic (iterative) behavior in a process model. In a realistic process, you often need to repeat a previous activity based on some decision outcome. This leads to process fragments that execute several times, often until a certain exit condition is satisfied. Some process models even have to represent behaviors that execute infinitely. Cyclic behavior can be captured in Business Modeler in several different ways, as shown in Figure 17.

Figure 17. Modeling elements to capture cyclic behavior in a process model
Modeling elements to capture cyclic behavior in a process mode

The upper half of this figure shows the three modeling elements to represent a while loop, a do-while loop, and a for loop. The repeated process fragment must be placed inside these loop modeling elements. These elements are very technical and not really suited to business users. Instead, business users usually draw backward connections that direct a flow back to an activity further upstream as it is shown in the lower half of the figure.

When exporting to BPEL, a process model in Business Modeler must currently use only the while-loop modeling element. You can often replace unstructured cycles with loops by applying control-flow normalization techniques from compiler theory [11]. Business Modeler has some prototyped plug-ins that implement such a normalization. Interested readers should contact the authors.

This process model contains one backward connection that starts at Task 1 and leads back to the same task, causing it to self-loop, and a second backward connection that starts at Task 3 and leads back to Task 2, causing a cyclic process fragment comprising these two tasks. These backward connections are very intuitive to use and often lead to overlapping cycles in the model, e.g., the cycle from Task 1 to Task 3 and back to Task 2 overlaps with the cycle involving Task 2 and Task 3 only.

Typical errors occur when such unstructured cycles are added to the process model. The noticeable problems relate to the correct branching and merging of the cyclic flows. Interestingly, we can easily describe these modeling errors by continuing to discuss gateways as in the preceding section. We can just change the order of these gateway pairs. In the preceding section, where we discussed pairs to describe alternative and parallel flows, a decision or fork always came before a merge or a join. Cycles are created by reversing this order, i.e., by combining a merge or join with a decision or fork. Only one of these combinations works out well, the other three lead to anti-patterns.

Cyclic deadlocks through join-fork and join-decision pairs

Figure 18 shows a process with three cycles.

Figure 18. Deadlocks caused by backward connections ending in join-like modeling elements
Deadlocks caused by backward connections ending in join-like modeling elements

The first cycle involves a backward connection that starts in the decision and leads back to the join following the start node. It comprises Task 1. A second cycle is the self-loop of Task 2, which uses activity form. Task 2 has a single input criterion, in which two connections end, acting as an implicit join. It has a single output criterion, in which two connections begin, acting as an implicit fork. As we already know from our discussion in Section 2, Task 2 will wait for all inputs in this single input criterion. However, these two inputs cannot possibly both arrive at the same time, because one of them is produced as an output of Task 2.

The third cycle starts in the fork preceding the end node, and leads back to the join following the decision. It also comprises Task 2. The join waits for input on all of its branches. However, one of its incoming branches can only receive the input after the join executes, because its input originates from a modeling element further downstream in the model. This cyclic dependency between the join and the decision, and the join and the fork (where the join must be executed before the decision or fork and vice versa) is the reason why a deadlock occurs. These incorrectly modeled cycles are made explicit in the following two anti-patterns.

The anti-pattern in Figure 19 represents a join-decision pair that deadlocks.

Figure 19. Anti-pattern: Incorrect combination of a join followed by a decision resulting in a cyclic deadlock
Anti-pattern: Incorrect combination of a join followed by a decision resulting in a cyclic deadlock

The cycle includes a join preceding a decision. At least one incoming branch of the join connects to an outgoing branch of the decision. A branch can involve several connections.

The anti-pattern in Figure 20 is similar to the previous anti-pattern except that it contains a fork instead of the decision. It has exactly the same kind of cyclic dependency as the anti-pattern in Figure 19, now between the join and the fork.

Figure 20. Anti-pattern: An incorrect join-fork pairing that always results in a cyclic deadlock
Anti-pattern: An incorrect join-fork pairing that always results in a cyclic deadlock

Variants of these anti-patterns for process models using activity form are straightforward and thus not shown. If you’re working in the basic editing mode of Business Modeler, watch for cycles such as in Figure 17, where Task 1 and Task 2 cannot execute, because the tasks join the two incoming connections in a single input criterion, which behaves like a join. The required alternative input criteria cannot be defined in the basic editing mode, so most backward connections drawn in basic editing mode add a deadlock to the model. Deadlocking cycles can be very hard to find in a larger process model. In particular, when process models contain alternative and parallel branches combined with cycles, the risk of having modeled a deadlock is very high. In our opinion, models that combine iterative with branching behavior are the most complex—they are not easy to draw or understand. A well-formed nesting of cyclic and branching process fragments is a good approach to reduce the possibility of modeling errors.

Cyclic lack of synchronization through merge-fork pairs

Lack of synchronization occurs in cyclic models when branches contain backward connections that are executed in parallel, and are not synchronized by a join before adding the backward connection to the process model. In this situation, each of the backward connections results from the same fork or output criterion of an activity and ends in a merge or different input criterion of an activity further upstream in the model. Figure 21 shows an inclusive decision where two of the branches connect back to an upstream merge, i.e., each of these branches causes an independent cycle in the process as the merge executes separately for each incoming branch.

Figure 21. Backward connections beginning in an inclusive decision or fork cause several unsynchronized cycles
Backward connections beginning in an inclusive decision or fork cause several unsynchronized cycles

This mistake can lead to an explosion of uncontrolled iterations of the process—in the example for Task 1—which can sometimes be detected by using Business Modeler simulation. Business Modeler will detect this problem if the simulation chooses more than one outgoing branch of the inclusive decision for execution, and parallel cycles become visible. The upper branch of the inclusive decision connects to a third cyclic process fragment with a merge preceding a fork.

The uncontrolled iteration of Task 4 and Task 5 becomes evident during a simulation, because for each execution of the fork with its two outgoing branches, the corresponding merge executes twice. The cyclic process fragment comprising Task 4 and Task 5 runs infinitely in parallel with the cycles involving Tasks 1, 2, 3.

The anti-pattern in Figure 22 explicitly defines the lack of synchronization through unsynchronized cycles by pairing a fork with a merge.

Figure 22. Anti-pattern: Cyclic lack of synchronization caused by a fork connecting back to a merge
Anti-pattern: Cyclic lack of synchronization caused by a fork connecting back to a merge

In the first process run, it triggers the fork, which leads to two outgoing parallel branches. One branch leads to some arbitrary process fragment that is not shown. The other branch causes a cycle between the fork and the merge. When this backward branch enters the merge, the merge executes and triggers the fork again, which in turn activates its two outgoing branches. One of these branches leads to another iteration of the cycle. By replacing the fork with an inclusive decision or an activity with several outgoing connections that originate from the same output criterion, you can define two related variants of this anti-pattern. The difference between the behavior of the fork and the inclusive decision lies in the number of unsynchronized cycles that are triggered when the fork and the inclusive decision execute. The inclusive decision only leads to a lack of synchronization if it activates more than one of its outgoing branches.

Correct cycles with merge-decision pairs

To correctly model a cycle, use a merge followed by a decision as shown in the pattern in Figure 23.

Figure 23. Pattern: A correct way to model iterative behavior using backward connections
Pattern: A correct way to model iterative behavior using backward connections

In this pattern, the merge and its matching decision can enclose any arbitrary process fragment that is located between these two gateways. At least one of the incoming branches of the merge must come from outside the cyclic process fragment, or this process fragment could not be reached from other activities. At least one of the outgoing branches of the decision must lead to a process fragment outside the cyclic process fragment, or the cycle would infinitely loop—when not intended, this causes a so-called livelock error. All backward connections into one branch of the merge should originate from the same branch of the decision to avoid implicit deadlocks or a lack of synchronization. A variant of this pattern in activity form could use an activity with several disjoint input and output criteria—one for each branch of the gateways.

Recommendations

  • To correctly capture cyclic processes, add backward connections to the process model that connect to an upstream activity. The backward connection should begin in a decision and lead back to a merge. Only this gateway pairing can lead to a correct cycle.
  • Alternatively, a cycle can begin in a separate output criterion of an activity and end in a separate input criterion of this or another activity.

Conclusion

In this article, we discuss typical modeling errors that we extracted from hundreds of real-world process models created in different tools. The modeling errors are grouped into common modeling scenarios. Part 1 of this article deals with two scenarios that address the modeling of branching and iterative behavior in business processes. We describe solutions based on gateway pairs that are built with the decision, merge, fork, and join modeling elements. We show that out of the eight possible combinations only three lead to correct models. The five erroneous combinations of the gateways are generalized into five anti-patterns that help users systematically review and improve the quality of their models.

In Part 2 of this article we will discuss four additional scenarios. They address modeling of data flow, representation of events and triggers, correct termination of a process, and reuse of activities in hierarchical process models.


Acknowledgments

We would like to thank our colleagues Thomas Gschwind, Jochen Küster, Cesare Pautasso, Ksenia Ryndina, Michael Wahler, Olaf Zimmermann, and IBM practitioners for their valuable comments on draft versions of this article. We also want to thank the numerous colleagues who sent their models to us that we analyzed for this work.

Resources

Learn

Get products and technologies

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, Architecture
ArticleID=197965
ArticleTitle= IBM WebSphere Developer Technical Journal : Process anti-patterns: How to avoid the common traps of business process modeling, Part 1
publish-date=02282007