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 , 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 . 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. In addition, these works investigate the role of patterns in the process of designing behavioral models:
- Using patterns in the design of inter-organisational systems - an experience report  focuses on using patterns to ease the implementation of business processes in a service oriented architecture,
- Activity diagram patterns for modeling quality constraints in business processes investigates how patterns can be used to capture nonfunctional aspects in process models such as domain-specific quality constraints.
- Workflow Management: Models, Methods, and Systems discusses the correctness and well-formedness of business process models viewed from the perspective of Petri net theory.
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”.
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 , Adonis , or MID Innovator  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) , Event-Driven Process Chains (EPC) , or the recent Business Process Modeling Notation (BPMN) .
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.
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
Let’s look at the process in Figure 1 in detail:
- The process begins with a start node depicted as a green bullet.
- 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.
- 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.
- 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.
- The parallel branches are joined again in a join, which ends the parallel execution.
- 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, . 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.
- The inclusive branches are merged again by a merge.
- The join and merge elements connect to another merge, which matches the initial exclusive decision.
- 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. 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. 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 Modeler||Element in UML 2.0 Activity Diagrams|
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. 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.
- The process beginning is indicated with a start event, while the process end is marked with an end event.
- Control-flow behavior of a process is modeled using gateways.
- Alternative branching is modeled with the exclusive (XOR) gateway visualized as a diamond, optionally marked with an ’X’.
- Inclusive branching is modeled with the inclusive (OR) gateway and visualized with a diamond containing a circle.
- 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 . 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
Again, we’ll look at the details of the diagram in Figure 4:
- 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.
- Tasks are represented as functions.
- A subprocess is captured with a process interface, which is a function that can be further refined by another EPC model.
- 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.
- 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
C, and three different outputs: one control-flow output and two outputs of type
Figure 5. 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.,
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.
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
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
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.
- 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
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
Band provides outputs
B, while Task 2 receives inputs
Cand provides outputs
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
A second deadlock occurs between Task 3 and Task 4 in the example. Task 3 produces
B as two alternative outputs in two disjoint output criteria, i.e., it behaves like an exclusive decision. Task 4 requires both
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
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
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.
An inclusive decision captures an n-out-of-m choice  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
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
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
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
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
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.
- 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
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.
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
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
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
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
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
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
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.
- 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.
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.
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.
-  Wikipedia: Anti-pattern, 2007.
-  J. Becker, M. Rosemann, and C. von Uthmann. Guidelines of business process modeling. In W. Aalst, J. Desel, and A. Oberweis, editors, Business Process Management: Models, Techniques, and Empirical Studies, volume 1806 of LNCS, pages 30–49. Springer, 2000.
-  Business Process Modeling Notation Specification, 2006. Version 1.0 dtc/06-02-01.
-  T. Erl. Service-Oriented Architecture: Concept, Technology, and Design. Prentice Hall, 2005.
-  A. Foerster, G. Engels, and T. Schattkowsky. Activity diagram patterns for modeling quality constraints in business processes. In Proceedings of the MoDELS Conference, volume 3713 of LNCS, pages 2–16. Springer, 2005.
-  MID GmbH. MID Innovator, 2007.
-  A. Selcuk Guceglioglu and O. Demirors. A process based model for measuring process quality attributes. In 12th European Conference on Software Process Improvement (EuroSPI), volume 3792 of LNCS, pages 118–129. Springer, 2005.
-  A. Selcuk Guceglioglu and O. Demirors. Using software quality characteristics to measure process quality. In 3rd International Conference on Business Process Management, volume 3649 of LNCS, pages 374–379. Springer, 2005.
-  IBM Rational Software Architect. IBM, 2005.
-  J. Koehler, R. Hauser, J. Küster, K. Ryndina, J. Vanhatalo, and M. Wahler. The role of visual modeling and model transformations in business-driven development. In Proceedings of the 5th International Workshop on Graph Transformation and Visual Modeling Techniques, pages 1–12. Elsevier, 2006.
-  J. Koehler, R. Hauser, S. Sendall, and M.Wahler. Declarative techniques for model-driven business process integration. IBM Systems Journal, 44(1):47–65, 2005.
-  C. Lange, B. Dubois, M. Chaudron, and S. Demeyer. An experimental investigation of UML modeling conventions. In Proceedings of the MoDELS Conference, volume 4199 of LNCS, pages 24–41. Springer, 2006.
-  F. Leymann and D. Roller. Production Workflow: Concepts and Techniques. Prentice Hall, 1999.
-  T. Mitra. Business-driven development. IBM developerWorks article, IBM, 2005.
-  J. Novatnack and J. Koehler. Using patterns in the design of inter-organisational systems - an experience report. In Proceedings of the Workshop on Modeling Inter-Organisational Systems, volume 3292 of LNCS, pages 444–455. Springer, 2004.
-  Object Management Group (OMG). Unified Modeling Language: Superstructure, 2005. Version 2.0 formal/05-07-04.
-  M. Rosemann. Komplexitätsmanagement in Prozessmodellen. Gabler, 1996.
-  W. Sadiq andM. Orlowska. Applying graph reduction techniques for identifying structural conflicts in process models. In Proceedings of the 11th International Conference on Advanced Information Systems Engineering (CAiSE ’99), volume 1626 of LNCS, pages 195–209. Springer, 1999.
-  SAP Research. Maestro Business Process Modeling Tool. 2006.
-  A. W. Scheer, F. Abolhassan, W. Jost, and M. Kirchner. Business Process Excellence - ARIS in Practice. Springer, 2002.
-  IDS Scheer. Aris Business Architect, 2007.
-  BOC Information Systems. ADONIS Business Process Management, 2007.
-  W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow patterns. Distributed and Parallel Databases, 14(1):5–51, 2003.
-  W.M.P. van der Aalst and K. van Hee. Workflow Management: Models, Methods, and Systems. MIT Press, 2004.
- developerWorks WebSphere development tools
- developerWorks Websphere business integration
Get products and technologies
Dig deeper into Business process management on developerWorks
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.