This is the author version of an article published as:

Van Der Aalst, Wil M. and Ter Hofstede, Arthur H. and

Kiepuszewski, Bartosz and Barros, Alistair P. (2003) Workflow
Patterns . Distributed and Parallel Databases 14(1):pp. 5-51.

Copyright 2003 Springer

Accessed from http://eprints.qut.edu.au

 Work ow Patterns

W.M.P. van der Aalst ,

1∗ A.H.M. ter Hofstede
2† , 3†
B. Kiepuszewski , and A.P. Barros
4‡
1 Department of Technology Management, Eindhoven University of Technology
GPO Box 513, NL-5600 MB Eindhoven, The Netherlands, e-mail: [email protected];
2 School of Information Systems, Queensland University of Technology
GPO Box 2434, Brisbane Qld 4001, Australia, e-mail: [email protected];
3 Mincom Pty Ltd, GPO Box 1397, Brisbane Qld 4001, Australia, e-mail: [email protected];
4 Distributed Systems Technology Centre, The University of Queensland
Brisbane Qld 4072, Australia, e-mail: [email protected].

Abstract
Di erences in features supported by the various contemporary commercial work ow
management systems point to di erent insights of suitability and di erent levels of expres-
sive power. The challenge, which we undertake in this paper, is to systematically address
work ow requirements, from basic to complex. Many of the more complex requirements
identi ed, recur quite frequently in the analysis phases of work ow projects, however their
implementation is uncertain in current products. Requirements for work ow languages are
indicated through work ow patterns. In this context, patterns address business require-
ments in an imperative work ow style expression, but are removed from speci c work ow
languages. The paper describes a number of work ow patterns addressing what we believe
identify comprehensive work ow functionality. These patterns provide the basis for an in-
depth comparison of a number of commercially available work ow management systems. As
such, this paper can be seen as the academic response to evaluations made by prestigious
consulting companies. Typically, these evaluations hardly consider the work ow modeling
language and routing capabilities, and focus more on the purely technical and commercial
aspects.
∗
Part of this work was done at CTRG (University of Colorado, USA) during a sabbatical leave.
†
This research was partially supported by an ARC SPIRT grant \Component System Architecture for an
Open Distributed Enterprise Management System with Con gurable Work ow Support" between QUT and
Mincom.
‡
Part of this work was supported by CITEC, an agency within the Queensland State Government.

1
1 Introduction
Background

Work ow technology continues to be subjected to on-going development in its traditional

application areas of business process modeling and business process coordination, and now in
emergent areas of component frameworks and inter-work ow, business-to-business interaction.
Addressing this broad and rather ambitious reach, a large number of work ow products, mainly
work ow management systems (WFMS), are commercially available, which see a large variety
of languages and concepts based on di erent paradigms (see e.g. [Aal98a, AH02, EN93, GHS95,
JB96, Kou95, LR99, Law97, Sch96, WFM99, DKTS98]).
As current provisions are compared and as newer concepts and languages are embarked upon,
it is striking how little, other than standards glossaries, is available for central reference. One
of the reasons attributed to the lack of consensus of what constitutes a work ow speci ca-
tion is the variety of ways in which business processes are otherwise described. The absence
of a universal organizational \theory", and standard business process modeling concepts, it
is contended, explains and ultimately justi es the major di erences in work ow languages -
fostering up a \horses for courses" diversity in work ow languages. What is more, the compar-
ison of di erent work ow products winds up being more of a dissemination of products and
less of a critique of work ow language capabilities - \bigger picture" di erences of work ow
speci cations are highlighted, as are technology, typically platform dependent, issues.
Work ow speci cations can be understood, in a broad sense, from a number of di erent per-
spectives (see [AH02, JB96]). The control- ow perspective (or process) perspective describes
activities and their execution ordering through di erent constructors, which permit ow of
execution control, e.g. sequence, choice, parallelism and join synchronization. Activities in ele-
mentary form are atomic units of work, and in compound form modularize an execution order
of a set of activities. The data perspective layers business and processing data on the control
perspective. Business documents and other objects which ow between activities, and local
variables of the work ow, qualify in e ect pre- and post-conditions of activity execution. The
resource perspective provides an organizational structure anchor to the work ow in the form
of human and device roles responsible for executing activities. The operational perspective
describes the elementary actions executed by activities, where the actions map into underlying
applications. Typically, (references to) business and work ow data are passed into and out
of applications through activity-to-application interfaces, allowing manipulation of the data
within applications.
Clearly, the control ow perspective provides an essential insight into a work ow speci cation's
e ectiveness. The data ow perspective rests on it, while the organizational and operational
perspectives are ancillary. If work ow speci cations are to be extended to meet newer pro-
cessing requirements, control ow constructors require a fundamental insight and analysis.
Currently, most work ow languages support the basic constructs of sequence, iteration, splits

2
(AND and OR) and joins (AND and OR) - see [AH02, Law97]. However, the interpretation
of even these basic constructs is not uniform and it is often unclear how more complex re-
quirements could be supported. Indeed, vendors are a orded the opportunity to recommend
implementation level \hacks" such as database triggers and application event handling. The re-
sult is that neither the current capabilities of work ow languages nor insight into more complex
requirements of business processes is advanced.

Problem

Even without formal quali cation, the distinctive features of di erent work ow languages al-
lude to fundamentally di erent semantics. Some languages allow multiple instances of the
same activity type at the same time in the same work ow context while others do not. Some
languages structure loops with one entry point and one exit point, while in others loops are
allowed to have arbitrary entry and exit points. Some languages require explicit termination
activities for work ows and their compound activities while in others termination is implicit.
Such di erences point to di erent insights of suitability and di erent levels of expressive power.
The challenge, which we undertake in this paper, is to systematically address work ow re-
quirements, from basic to complex, in order to 1) identify useful routing constructs and 2) to
establish to what extent these requirements are addressed in the current state of the art. Many
of the basic requirements identify slight, but subtle di erences across work ow languages, while
many of the more complex requirements identi ed in this paper, in our experiences, recur quite
frequently in the analysis phases of work ow projects, and present grave uncertainties when
looking at current products. Given the fundamental di erences indicated above, it is tempting
to build extensions to one language, and therefore one semantic context. Such a strategy is
rigorous and its results would provide a detailed and unambiguous view into what the exten-
sions entail. Our strategy is more practical. We wish to draw a more broader insight into the
implementation consequences for the big and potentially big players. With the increasing ma-
turity of work ow technology, work ow language extensions, we feel, should be levered across
the board, rather than slip into \yet another technique" proposals.

Approach

We indicate requirements for work ow languages through work ow patterns. As described in

[RZ96], a pattern \is the abstraction from a concrete form which keeps recurring in speci c
nonarbitrary contexts". Gamma et al. [GHJV95] rst catalogued systematically some 23 design
patterns which describe the smallest recurring interactions in object-oriented systems. The
design patterns, as such, provided independence from the implementation technology and at
the same time independence from the essential requirements of the domain that they were
attempting to address (see also e.g. [Fow97]).

3
For our purpose, patterns address business requirements in an imperative work ow style ex-
pression, but are removed from speci c work ow languages. Thus they do not claim to be the
only way of addressing the business requirements. Nor are they \alienated" from the work ow
approach, thus allowing a potential mapping to be positioned closely to di erent languages
and implementation solutions. Along the lines of [GHJV95], patterns are described through:
conditions that should hold for the pattern to be applicable; examples of business situations;
problems, typically semantic problems, of realization in current languages; and implementation
solutions.
To demonstrate solutions for the patterns, our recourse is a mapping to existing work ow lan-
guage constructs. In some cases support from the work ow engine has been identi ed, and we
brie y sketch implementation level strategies. Among the contemporary work ow management
systems considered in this paper, none supports all the patterns. For those patterns that were
supported, some had a straightforward mapping while others were demonstrable in a minority
of tools.
It is important to note that the scope of our patterns is limited to static control ow, i.e.,
we do not consider patterns for resource allocation [KAV02], case handling [AB01], exception
handling [CCPP98, KDB00], and transaction management [SAA99, GHS95].

Related work

Many languages have been proposed for the design and speci cation of work ow processes.
Some of these languages are based on existing modeling techniques such as Petri nets and
State charts. Other languages are system speci c. Any attempt to give a complete overview of
these languages and the patterns they support is destined to fail. Throughout this paper we
will give pointers to concrete languages without striving for completeness. To our knowledge
no other attempts have been made to collect a structured set of work ow patterns. This paper
builds on [AHKB00a] where only four patterns are introduced. A previous version of this paper
(evaluating only 12 systems but addressing more patterns) is available as a technical report
[AHKB00b]. Moreover, the \Work ow Patterns Home Page" [AHKB] has been used to invite
researcher, developers, and users to generate feedback. As a result, several authors have used
our patterns to evaluate existing work ow management systems or newly designed work ow
languages, e.g., in [Lav00] the OmniFlow environment is evaluated using 10 of our patterns,
in [Hir01] our patterns are used to evaluate the CONDIS Work ow Management System, and
in [VO01, VO02] the frequency of each of our patterns in real-life situations is investigated.
Some of the patterns presented in this paper are related to the control- ow patterns described
in [JB96]. However, the goal of [JB96] is to develop a work ow management systems that
can be extended with new patterns rather than structuring and evaluating existing patterns.
Our work is also related to investigations into the expressive power of work ow languages, cf.
[BW99]. Other authors have coined the term work ow patterns but addressed di erent issues.
In [WAH00] a set of work ow patterns inspired by Language/Action theory and speci cally

4
aiming at virtual communities is introduced. Patterns at the level of work ow architectures
rather than control ow are given in [MB97].
The organization of this paper is as follows. First, we describe the work ow patterns, then
we present the comparison of contemporary work ow management systems using the patterns
(except the most elementary ones, as they are supported by all work ow management systems).
Finally, we conclude the paper and identify issues for further research.

2 Work ow Patterns
The design patterns range from fairly simple constructs present in any work ow language
to complex routing primitives not supported by today's generation of work ow management
systems. We will start with the more simple patterns. Since these patterns are available in
the current work ow products we will just give a (a) description, (b) synonyms, and (c) some
examples. In fact, for these rather basic constructs, the term \work ow pattern" is not very
appropriate. However, for the more advanced routing constructs we also identify (d) the problem
and (e) potential implementation strategies. The problem component of a pattern describes
why the construct is hard to realize in many of the work ow management systems available
today. The implementation component, also referred to as solutions, describes how, assuming
a set of basic routing primitives, the required behavior can be realized. For these more complex
routing constructs the term \pattern" is more justi ed since non-trivial solutions are given for
practical problems encountered when using today's work ow technology.
Before we present the patterns, we rst introduce some of the terms that will be used through-
out this paper. The primary task of a work ow management system is to enact case-driven
business processes by allowing work ow models to be speci ed, executed, and monitored.
Work ow process de nitions (work ow schemas) are de ned to specify which activities need
to be executed and in what order (i.e. the routing or control ow). An elementary activity is
an atomic piece of work. Work ow process de nitions are instantiated for speci c cases (i.e.
work ow instances). Examples of cases are: a request for a mortgage loan, an insurance claim,
a tax declaration, an order, or a request for information. Since a case is an instantiation of
a process de nition, it corresponds to the execution of concrete work according to the spec-
i ed routing. Activities are connected through transitions and we use the notion of a thread
of execution control for concurrent executions in a work ow context. Activities are under-
taken by roles which de ne organizational entities, such as humans and devices. Control data
are data introduced solely for work ow management purposes, e.g. variables introduced for
routing purposes. Production data are information objects (e.g. documents, forms, and tables)
whose existence does not depend on work ow management. Elementary actions are performed
by roles while executing an activity for a speci c case, and are executed using applications
(ranging from a text editor to custom built applications to perform complex calculations).
Each work ow language can be formally described by a set of primitive modeling constructs,
syntactical rules for composition, and the semantics of these constructs. In this paper, we will
5
not present a new modeling language. Instead, we focus on work ow patterns that originate
from business requirements. The semantics of these patterns are much less formal because
we cannot assume a (formal) language. Moreover, the patterns are context-oriented, i.e., a
work ow pattern typically describes certain business scenarios in a very speci c context. The
semantics of the pattern in this context is clear, while the semantics outside the context is
unde ned. Work ow patterns are typically realized in a speci c language using one or more
constructs available for this language. Please note the di erence between the semantics of the
pattern and the realization using a speci c language. Sometimes work ow constructs available
for a given language are not suÆcient to realize a given pattern and work ow implementers
have to resort to programming techniques such as event queuing, database triggers, etc to
circumvent the limitations of a given work ow tool.
Patterns should be interpreted in a given context, i.e., assumptions about the environment
which embeds the pattern are highly relevant. Consider for example the basic synchronization
pattern (Pattern 3) often referred to as AND-join. It is a simple and well-understood pattern
that describes a point in a work ow where multiple parallel subprocesses/activities converge
into one single thread of control, thus synchronizing multiple threads. It is important to un-
derstand though that this pattern is clear and well-de ned only in a very speci c context, i.e.
when we expect only one trigger from each of the incoming branches that we want to syn-
chronize. This context is indeed the most common one, however not the only one possible and
the simple synchronization pattern does not specify how synchronization should occur in a
di erent context. Realizing the simple synchronization pattern is straightforward and involves
usage of a language-speci c synchronization construct, for example synchronizer in Verve, ren-
dezvous in FileNet's Visual WorkFlo, join in MQSeries/Work ow, etc. However, each of these
language-speci c synchronization constructs behaves di erently if this assumption about the
context is dropped.

2.1 Basic Control Flow Patterns

In this section patterns capturing elementary aspects of process control are discussed. These
patterns closely match the de nitions of elementary control ow concepts provided by the
WfMC in [WFM99]. The rst pattern we consider is the sequence.
Pattern 1 (Sequence)
Description An activity in a work ow process is enabled after the completion of another
activity in the same process.
Synonyms Sequential routing, serial routing.
Examples
- Activity send bill is executed after the execution of activity send goods.
- An insurance claim is evaluated after the client's le is retrieved.

6
 - Activity add air miles is executed after the execution of activity book ight.

Implementation
- The sequence pattern is used to model consecutive steps in a work ow process and is
directly supported by each of the work ow management systems available. The typical
implementation involves linking two activities with an unconditional control ow arrow.
2
The next two patterns can be used to accommodate for parallel routing.
Pattern 2 (Parallel Split)
Description A point in the work ow process where a single thread of control splits into
multiple threads of control which can be executed in parallel, thus allowing activities to be
executed simultaneously or in any order.
Synonyms AND-split, parallel routing, fork.
Examples
- The execution of the activity payment enables the execution of the activities ship goods
and inform customer.
- After registering an insurance claim two parallel subprocesses are triggered: one for
checking the policy of the customer and one for assessing the actual damage.
Implementation
- All work ow engines known to us have constructs for the implementation of this pat-
tern. One can identify two basic approaches: explicit AND-splits and implicit AND-splits.
Work ow engines supporting the explicit AND-split construct (e.g. Visual WorkFlo) de-
ne a routing node with more than one outgoing transition which will be enabled as
soon as the routing node gets enabled. Work ow engines supporting implicit AND-splits
(e.g. MQSeries/Work ow) do not provide special routing constructs - each activity can
have more than one outgoing transition and each transition has associated conditions. To
achieve parallel execution the work ow designer has to make sure that multiple condi-
tions associated with outgoing transitions of the node evaluate to True (this is typically
achieved by leaving the conditions blank).
2
Pattern 3 (Synchronization)
Description A point in the work ow process where multiple parallel subprocesses/activities
converge into one single thread of control, thus synchronizing multiple threads. It is an as-
sumption of this pattern that each incoming branch of a synchronizer is executed only once (if
7
this is not the case, then see Patterns 13-15 (Multiple Instances Requiring Synchronization)).
Synonyms AND-join, rendezvous, synchronizer.
Examples
- Activity archive is enabled after the completion of both activity send tickets and activity
receive payment.
- Insurance claims are evaluated after the policy has been checked and the actual damage
has been assessed.
Implementation
- All work ow engines available support constructs for the implementation of this pattern.
Similarly to Pattern 2 one can identify two basic approaches: explicit AND-joins (e.g.
Rendez-vous construct in Visual WorkFlo or Synchronizer in Verve) and implicit joins
in an activity with more than one incoming transition (as in e.g. MQSeries/Work ow or
Forte Conductor).
2
The next two patterns are used to specify conditional routing. In contrast to parallel routing
only one selected thread of control is activated.
Pattern 4 (Exclusive Choice)
Description A point in the work ow process where, based on a decision or work ow control
data, one of several branches is chosen.
Synonyms XOR-split, conditional routing, switch, decision.
Examples
- Activity evaluate claim is followed by either pay damage or contact customer.
- Based on the workload, a processed tax declaration is either checked using a simple
administrative procedure or is thoroughly evaluated by a senior employee.
Implementation
- Similarly to Pattern 2 (Parallel split) there are a number of basic strategies. Some work-
ow engines provide an explicit construct for the implementation of the exclusive choice
pattern (e.g. Sta ware, Visual WorkFlo). In some work ow engines (MQSeries/Work ow,
Verve) the work ow designer has to emulate the exclusiveness of choice by specifying ex-
clusive transition conditions. In another work ow product, Eastman, a post-processing
rule list can be speci ed for an activity. After completion of the activity, the transition
associated with the rst rule in this list to evaluate to true is taken.
2
8
Pattern 5 (Simple Merge)
Description A point in the work ow process where two or more alternative branches come to-
gether without synchronization. It is an assumption of this pattern that none of the alternative
branches is ever executed in parallel (if this is not the case, then see Pattern 8 (Multi-merge)
or Pattern 9 (Discriminator)).
Synonyms XOR-join, asynchronous join, merge.
Examples
- Activity archive claim is enabled after either pay damage or contact customer is exe-
cuted.
- After the payment is received or the credit is granted the car is delivered to the customer.
Implementation
- Given that we are assuming that parallel execution of alternative threads does not
occur, this is a straightforward situation and all work ow engines support a construct
that can be used to implement the simple merge. It is interesting to note here that
some languages impose a certain level of structuredness to automatically guarantee that
not more than one alternative thread is running at any point in time. Visual WorkFlo
for example requires the merge construct to always be preceded by a corresponding
exclusive choice construct (combined with some other requirements this then yields the
desired behavior). In other languages work ow designers themselves are responsible for
the design not having the possibility of parallel execution of alternative threads.
2

2.2 Advanced Branching and Synchronization Patterns

In this section the focus will be on more advanced patterns for branching and synchronization.
As opposed to the patterns in the previous section, these patterns do not have straightforward
support in most work ow engines. Nevertheless, they are quite common in real-life business
scenarios.
Pattern 4 (Exclusive choice) assumes that exactly one of the alternatives is selected and exe-
cuted, i.e. it corresponds to an exclusive OR. Sometimes it is useful to deploy a construct which
can choose multiple alternatives from a given set of alternatives. Therefore, we introduce the
multi-choice.
Pattern 6 (Multi-choice)
Description A point in the work ow process where, based on a decision or work ow control
data, a number of branches are chosen.
Synonyms Conditional routing, selection, OR-split.
Examples
9