Business Process Management: A Survey
Wil M.P. van der Aalst1 , Arthur H.M. ter Hofstede2 , and Mathias Weske3
1

Department of Technology Management
Eindhoven University of Technology, The Netherlands
w.m.p.v.d.aalst@tm.tue.nl
2
Centre for Information Technology Innovation
Queensland University of Technology, Australia
a.terhofstede@qut.edu.au
3
Hasso Plattner Institute for Software Systems Engineering
University of Potsdam, Potsdam, Germany
mathias.weske@hpi.uni-potsdam.de
Abstract. Business Process Management (BPM) includes methods,
techniques, and tools to support the design, enactment, management,
and analysis of operational business processes. It can be considered as
an extension of classical Workﬂow Management (WFM) systems andapproaches. Although the practical relevance of BPM is undisputed, aclear deﬁnition of BPM and related acronyms such as BAM, BPA, and
STP are missing. Moreover, a clear scientiﬁc foundation is missing. In
this paper, we try to demystify the acronyms in this domain, describe
the state-of-the-art technology, and argue that BPM could beneﬁt fromformal methods/languages (cf. Petri nets, process algebras, etc.).
Keywords: Business Process Management, Workﬂow Management, Formal Methods.

1

Introduction

This volume of Springer Lecture Notes in Computer Science is devoted to the“Conference on Business Process Management: On the Application of Formal
Methods to Process-Aware Information Systems” taking place in Eindhoven(The Netherlands) in June 2003. To put the contributions to this conference
into perspective, we discuss the ideas, technology, and foundations hidden behind acronyms like WFM, BPM, BAM, BPA, STP, etc. The goal of this paper
is to provide an overview of the scientiﬁc and practical issues in the context ofbusiness process management systems. This way we hope to trigger researchersand practitioners to address the challenges in this domain. The deﬁnition of abusiness process management system used throughout this paper is: a genericsoftware system that is driven by explicit process designs to enact and manage
operational business processes. The system should be process-aware and genericin the sense that it is possible to modify the processes it supports. The process
designs are often graphical and the focus is on structured processes that need tohandle many cases.
W.M.P. van der Aalst et al. (Eds.): BPM 2003, LNCS 2678, pp. 1–12, 2003.
c Springer-Verlag Berlin Heidelberg 2003


2

W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske

To show the relevance of business process management systems, it is interesting to put them in a historical perspective. Consider Figure 1, which showssome of the ongoing trends in information systems [3]. This ﬁgure shows thattoday’s information systems consist of a number of layers. The center is formedby the operating system, i.e., the software that makes the hardware work. The
second layer consists of generic applications that can be used in a wide range
of enterprises. Moreover, these applications are typically used within multiple
departments within the same enterprise. Examples of such generic applications
are a database management system, a text editor, and a spreadsheet program.
The third layer consists of domain speciﬁc applications. These applications are
only used within speciﬁc types of enterprises and departments. Examples aredecision support systems for vehicle routing, call center software, and humanresource management software. The fourth layer consists of tailor-made applications. These applications are developed for speciﬁc organizations.

Trends in
information
systems

operatingsystemgeneric
applications

domainspecific
applications

tailor-madeapplications

1. From programming toassembling.
2. From data orientation toprocess orientation.
3. From design to redesignand organic growth.
Fig. 1. Trends relevant for business process management [3].

In the sixties the second and third layer were missing. Information systems
were built on top of a small operating system with limited functionality. Since
no generic nor domain speciﬁc software was available, these systems mainly
consisted of tailor-made applications. Since then, the second and third layer havedeveloped and the ongoing trend is that the four circles are increasing in size,i.e., they are moving to the outside while absorbing new functionality. Today’s

Business Process Management: A Survey

3

operating systems oﬀer much more functionality. Database management systems
that reside in the second layer oﬀer functionality which used to be in tailor-madeapplications. As a result of this trend, the emphasis shifted from programming
to assembling of complex software systems. The challenge no longer is the codingof individual modules but orchestrating and gluing together pieces of softwarefrom each of the four layers.
Another trend is the shift from data to processes. The seventies and eighties
were dominated by data-driven approaches. The focus of information technology was on storing and retrieving information and as a result data modeling was
the starting point for building an information system. The modeling of businessprocesses was often neglected and processes had to adapt to information technology. Management trends such as business process reengineering illustrate theincreased emphasis on processes. As a result, system engineers are resorting toa more process driven approach.
The last trend we would like to mention is the shift from carefully planned
designs to redesign and organic growth. Due to the omnipresence of the Internet and its standards, information systems change on-the-ﬂy. As a result, fewer
systems are built from scratch. In many cases existing applications are partly
used in the new system. Although component-based software development still
has its problems, the goal is clear and it is easy to see that software development
has become more dynamic.
The trends shown in Figure 1 provide a historical context for business process
management systems. Business process management systems are either separate
applications residing in the second layer or are integrated components in the domain speciﬁc applications, i.e., the third layer. Notable examples of business process management systems residing in the second layer are workﬂow management
systems [6,19,22,23,24] such as Staﬀware, MQSeries, and COSA, and case handling systems such as FLOWer. Note that leading enterprise resource planningsystems populating the third layer also oﬀer a workﬂow management module.
The workﬂow engines of SAP, Baan, PeopleSoft, Oracle, and JD Edwards canbe considered as integrated business process management systems. The idea toisolate the management of business processes in a separate component is consistent with the three trends identiﬁed. Business process management systems canbe used to avoid hard-coding the work processes into tailor-made applications
and thus support the shift from programming to assembling. Moreover, process
orientation, redesign, and organic growth are supported. For example, today’s
workﬂow management systems can be used to integrate existing applications
and support process change by merely changing the workﬂow diagram. Isolating
the management of business processes in a separate component is also consistent
with recent developments in the domain of web services: Web services composition languages such as BPEL4WS, BPML, WSCI, XLANG, and WSFL can beused to glue services deﬁned using WSDL together.
An interesting starting point from a scientiﬁc perspective is the early workon oﬃce information systems. In the seventies, people like Skip Ellis [13], Anatol
Holt [17], and Michael Zisman [28] already worked on so-called oﬃce informa-

4

W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske

tion systems, which were driven by explicit process models. It is interesting to
see that the three pioneers in this area independently used Petri-net variants tomodel oﬃce procedures. During the seventies and eighties there was great optimism about the applicability of oﬃce information systems. Unfortunately, few
applications succeeded. As a result of these experiences, both the application ofthis technology and research almost stopped for a decade. Consequently, hardly
any advances were made in the eighties. In the nineties, there again was a hugeinterest in these systems. The number of workﬂow management systems developed in the past decade and the many papers on workﬂow technology illustrate
the revival of oﬃce information systems. Today workﬂow management systems
are readily available [22]. However, their application is still limited to speciﬁc
industries such as banking and insurance. As was indicated by Skip Ellis it isimportant to learn from these ups and downs [14]. The failures in the eighties
can be explained by both technical and conceptual problems. In the eighties,
networks were slow or not present at all, there were no suitable graphical interfaces, and proper development software was missing. However, there were also
more fundamental problems: a uniﬁed way of modeling processes was missing
and the systems were too rigid to be used by people in the workplace. Most of thetechnical problems have been resolved by now. However, the more conceptual
problems remain. Good standards for business process modeling are still missing
and even today’s workﬂow management systems enforce unnecessary constraints
on the process logic (e.g., processes are made more sequential).

2

Business Process Management Demystiﬁed

Many people consider Business Process Management (BPM) to be the “nextstep” after the workﬂow wave of the nineties. Therefore, we use workﬂow terminology to deﬁne BPM. The Workﬂow Management Coalition (WfMC) deﬁnes
workﬂow as: “The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant toanother for action, according to a set of procedural rules.” [22]. A Workﬂow
Management System (WFMS) is deﬁned as: “A system that deﬁnes, creates andmanages the execution of workﬂows through the use of software, running on
one or more workﬂow engines, which is able to interpret the process deﬁnition,interact with workﬂow participants and, where required, invoke the use of IT
tools and applications.” [22]. Note that both deﬁnitions emphasize the focus onenactment, i.e., the use of software to support the execution of operational processes. In the last couple of years, many researchers and practitioners started torealize that the traditional focus on enactment is too restrictive. As a result newterms like BPM have been coined. There exist many deﬁnitions of BPM but inmost cases it clearly includes Workﬂow Management (WFM). We deﬁne BPM as
follows: Supporting business processes using methods, techniques, and software
to design, enact, control, and analyze operational processes involving humans,organizations, applications, documents and other sources of information. Notethat this deﬁnition restricts BPM to operational processes, i.e., processes at theBusiness Process Management: A Survey

5

strategic level or processes that cannot be made explicit are excluded. Note thatsystems supporting BPM need to be “process aware”, i.e., without information
about the operational processes at hand little support is possible.

diagnosis

process
enactment

processdesignWorkflow
Management

Business
Process
Management

systemconfiguration
Fig. 2. The BPM lifecyle to compare Workﬂow Management and Business Process
Management.

Figure 2 shows the relationship between WFM and BPM using the BPM
lifecyle. The BPM lifecyle describes the various phases in support of operational
business processes. In the design phase, the processes are (re)designed. In the
conﬁguration phase, designs are implemented by conﬁguring a process aware
information system (e.g., a WFMS). After conﬁguration, the enactment phasestarts where the operational business processes are executed using the system
conﬁgured. In the diagnosis phase, the operational processes are analyzed to
identify problems and to ﬁnd things that can be improved. The focus of traditional workﬂow management (systems) is on the lower half of the BPM lifecyle.
As a result there is little support for the diagnosis phase. Moreover, support in
the design phase is limited to providing an editor and analysis and real design
support are missing. It is remarkable that few WFM systems support simulation, veriﬁcation, and validation of process designs. It is also remarkable that few
systems support the collection and interpretation of real-time data. Note thatmost WFM systems log data on cases and tasks executed. However, no tools to
support any form of diagnosis are oﬀered by the traditional systems.
Currently, many workﬂow vendors are positioning their systems as BPM
systems. Gartner expects the BPM market to grow and also identiﬁes Business
Process Analysis (BPA) as an important aspect [16]. It is expected that the
BPA market will continue to grow. Note that BPA covers aspects neglected bytraditional workﬂow products (e.g., diagnosis, simulation, etc.). Business Activity
Monitoring (BAM) is one of the emerging areas in BPA. The goal of BAM tools
is to use data logged by the information system to diagnose the operational
processes. An example is the ARIS Process Performance Manager (PPM) of IDS
Scheer [18]. ARIS PPM extracts information from audit trails (i.e., information
logged during the execution of cases) and displays this information in a graphicalway (e.g., ﬂow times, bottlenecks, utilization, etc.). BAM also includes process

6

W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske

mining, i.e., extracting process models from logs [10]. BAM creates a number ofscientiﬁc and practical challenges (e.g., which processes can be discovered andhow much data is needed to provide useful information).
When it comes to redesigning operational processes two trends can be identiﬁed: Straight Through Processing (STP) and Case Handling (CH). STP refers
to the complete automation of a business process, i.e., handling cases without
human involvement. STP is often only possible if the process is redesigned. Moreover, STP is often only possible for a selected set of cases. The latter means thatcases are split into two groups: (1) cases that can be handled automatically (inDutch these cases are called “Gladde gevallen”) and (2) cases that require human involvement. By separating both groups it is often possible to reduce ﬂow
time and cut costs. While STP strives for more automation, CH addresses the
problem that many processes are much too variable or too complex to capture
in a process diagram [4]. In CH the normal route of a case is modeled but at
the same time other routes are allowed if not explicitly excluded. One way to
do this is to make workﬂows data-driven rather than process-driven and allow
for authorizations to skip or undo activities. Also the focus is on the case as awhole rather than on individual work-items distributed over work-lists.
To summarize: BPM extends the traditional WFM approach by support forthe diagnosis phase (cf. BPA and BAM software) and allowing for new ways tosupport operational processes (cf. CH and STP). In the remainder, we focus on
the scientiﬁc foundations and current technology.

3

On the Interplay between Business Process
Management and Formal Methods

Business Process Models should have a formal foundation. Well-known reasons(see e.g. [1]) include: 1) formal models do not leave any scope for ambiguity, and2) formal models increase the potential for analysis (see also e.g. [26]).
It is desirable that a Business Process Model can be understood by the various
stakeholders involved in an as straightforward manner as possible. This could
e.g. be achieved through the use of graphical representations. At the same time,these stakeholders should assign the same meaning to such a model, there should
not be any scope for alternative interpretations. Business Process Models canbe quite complex and the use of a formal language for their speciﬁcation is the
only sure way to guarantee that alternative interpretations are ruled out. After
consensus among the stakeholders has been reached, a business process model
can be deployed and if a formal language was used, its behavior can be explainedin terms of the formal semantics of that speciﬁcation language. As remarkedin [21], the lack of a formal semantics has resulted in diﬀerent interpretations
by vendors of even basic control ﬂow constructs, deﬁnitions in natural language
such as provided by the Workﬂow Management Coalition are not precise enough.
As always, it is preferable to identify any problems in software before it isactually deployed. In the case of Business Process Models this is especially important as they may involve core business and/or complex business transactions.

Business Process Management: A Survey

7

To reduce the risk of costly corrections, a thorough analysis of a Business Process Model can be beneﬁcial. Analysis of Business Process Models can also be
used to investigate ways of improving processes (e.g. reducing their cost). Formal
languages may have associated analysis techniques which can be used for investigating properties of speciﬁcations. These techniques can then be relied upon
to provide insight into the behavior and characteristics of a Business Process
Model speciﬁed in such a language.
In [1] three reasons are stated arguing the beneﬁts of the use of Petri nets
for the speciﬁcation of workﬂows. The reasons brought forward are the fact that
Petri nets are formal, have associated analysis techniques, and are state-based
rather than event-based. The development of Woﬂan (see e.g. [25]) demonstrates
that workﬂows speciﬁed as workﬂow nets [2], a subclass of Petri nets, can beanalyzed in order to determine whether they are e.g. deadlock free. In the context
of UML activity diagrams, tool support for veriﬁcation is discussed in [15].
Through the notion of place, Petri nets provide natural support for modelingthe stages in between processing. State-based patterns such as deferred choice,interleaved paralled routing, and milestone can therefore be speciﬁed straightforwardly. A description of these patterns can be found in [9]. Petri nets though also
have some deﬁciencies when it comes to the speciﬁcation of certain control ﬂow
dependencies (see [7]). This observation has led to the development of YAWL [8](Yet Another Workﬂow Language) of which the formal semantics is speciﬁed asa transition system.
It is interesting to observe that a concept such as the deferred choice, while
easily captured in terms of Petri nets, is not often supported in languages of“classical” workﬂow management systems (see [9]). Two recently proposed standards for web service composition, BPEL4WS and BPML, however, provide
direct support for this construct (see [27]) and [5] resp.). In web services composition it is important to capture the interactions between the various services anda formalism such as the π-calculus seems to be a natural candidate to provide
a formal foundation for such interactions. While it is sometimes claimed that
BPML is based on the π-calculus, there does not seem to be a precise deﬁnitionof this relation (note that in [12], it is stated that “there is currently no evidence
that BPEL4WS is based on a formal semantics”). We believe that it is importantthat such relations are fully formalized.
Formally deﬁned Business Process Modeling Languages can be compared interms of their expressive power. For some classes of workﬂow modeling languages,
abstractions of some existing approaches, comparative expressiveness has beenstudied in [21,20]. These results are in the context of a speciﬁc notion of equivalence, addressing the issue of when two workﬂow models can be considered
expressing the same workﬂow. Expressiveness results give insight into what canand cannot be expressed in some approaches and more research is needed in thisarea as it could provide more guidance for language development.

8

W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske

4

Available Technology and Emerging Standards

Based on the deﬁnition of Business Process Management proposed in Section 2,
a characterization of its main concepts is provided, and the technology currently
available or on the horizon is discussed. Some of the key aspects of businessprocess management already mentioned in Sections 1 and 2 are re-visited, andthe current state of available technology and emerging standards are discussed.
One of the main aspects and certainly an activity typically carried out in earlyphases of business process management projects is the design of business processes. There is a close relationship between business process design and businessprocess modeling, where the former refers to the overall design process involving
multiple steps and the latter refers to the actual representation of the businessprocess in terms of a business process model using a process language. To thisend, the term business process modeling is used to characterize the identiﬁcation and (typically rather informal) speciﬁcation of the business processes athand. This phase includes modeling of activities and their causal and temporal
relationships as well as speciﬁc business rules that process executions have tocomply with.
Business process modeling has a decade long tradition, and a variety of products are commercially available to support this phase, based on diﬀerent process
languages. Given this situation, it is not surprising that the selection of a particular product is an important step in many BPM projects, and, consequently,
appropriate selection criteria have been studied extensively. Besides organizational, economical, and aspects related to the overall IT infrastructure of theenterprise at hand, the expressive power of the process language as well as interfaces to related software systems are important criteria, most prominently interfaces to process enactment systems (such as workﬂow management systems) andto software responsible for modeling personnel and organizational structures ofthe enterprise. Not only the expressive power but also a well-deﬁned semanticsof the process language deserves a central role during product selection. However, this aspect is considered only in a small number of recent business process
management projects.
Business process analysis aims at investigating properties of business processes that are neither obvious nor trivial. To this end, the term analysis is usedwith a rather broad meaning, including for example simulation and diagnosis,
veriﬁcation and performance analysis. Process simulation facilitates process diagnosis in the sense that by simulating real-world cases, domain experts canacknowledge correct modeling or propose modiﬁcations of the original processmodel. If business process models are expressed in process languages with a clear
semantics, their structural properties can be analyzed. If, for example, certain
parts of processes can never be reached, an obvious modeling mistake occurredthat should be ﬁxed. While basic structural properties of process models havebeen studied for some time, it is remarkable that few software products actually
support them. However structural analysis of process models requires a clear formal semantics of the underlying process language, which might not be present.
In some products, a pragmatic approach to process modeling is preferred to a

Business Process Management: A Survey

9

formal one; especially if the main goal of process modeling is discussion withdomain experts rather than process analysis or process enactment. However, we
mention that formal semantics of process languages and intuitiveness and easeof use are no contradicting goals, and recent approaches seem to support thisobservation.
The next aspect of BPM and traditionally a very strong one is process enactment. However, before process enactment is discussed, we provide a coarse
classiﬁcation of business processes that paves the way for a discussion of different types of process enactment systems. In the early days of BPM when in
the application side business process modeling and in the IT enactment side
workﬂow management were the only options, processes with a static structure
were focused. The main reason behind this obvious limitation was as follows:
Modeling a process and providing infrastructure for its enactment incurs considerable eﬀort. To provide satisfactory return on investment, a large number ofindividual cases have to beneﬁt from this new technology. This type of straightthrough-process is also called production workﬂow [23]. While there are successful workﬂow projects on this type of straight-through processes, this restrictionof workﬂow technology proved fatal for applications in more dynamic environments. In some cases where traditional workﬂow technology was used in theseadvanced settings, new workﬂow solutions were partly circumvented or even neglected. As a response to this situation, considerable work in ad-hoc, ﬂexible
and case-based workﬂow was (and is being) conducted, both in academia andin industry. Recently, case handling is studied in depth as a new paradigm forsupporting knowledge-intensive business processes with loose structuring. Basedon the brief characterization of case handling provided above, we mention that in
the case handling paradigm knowledge workers enjoy a great degree of freedom
in organizing and performing their work which they are knowledgeable about.
Some of the concepts of case handling are already present in commercial casehandling systems.
Standardization has a long history in workﬂow management. Fueled by information system heterogeneity that also includes workﬂow management systems,
organizations started to form interest groups aiming at standardizing interfaces
between workﬂow management systems and components, with the goal of enhancing interoperability and fostering the workﬂow market. The most prominentorganization in this context is the Workﬂow Management Coalition (WfMC) thatwas formed in 1993 and today has over 300 member organizations, including all
major workﬂow vendors as well as workﬂow users and interested academia [22].
The basis of WfMC activities is the so called WfMC Reference Architecture thatdeﬁnes standard workﬂow system components interfaces. Despite the fact that
all major vendors are organized in WfMC and a number of important contributions on practical workﬂow aspects have been made, many people feel that
WfMC’s ambitious goals have yet to be reached.
A more recent standardization eﬀort in the BPM context is related to the current momentum of XML and Web services technology. Web services is a promising technology to foster interoperability between information system based –10

W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske

conceptually – on the service oriented architecture paradigm [11] and – technologically – on open standards and light-weight protocols and systems. While
Web services technology has not yet reached maturity level, there is considerable
eﬀort under way by literally all major software vendors. The need for standardization is clearly acknowledged in this context, and important contributions havebeen made. However, as sketched in Section 2, recently a trend of new standards
proposals as well as merging of proposals can be experienced in the Web services context. Besides these recent developments, Web services are seen as animportant infrastructure to foster business processes by composing individual
Web services to represent complex processes, which can even span multiple organizations. While Web services composition is a young discipline and a numberof proposals are being discussed, we currently experience what seems to be aslow consolidation of recent standardization eﬀort around Web services composition, based on the BPEL4WS and associated proposals. However, at this pointindustry seems more involved in standardization than in systems design anddevelopment. While there is some controversy on these upcoming standards, it
seems that at least industry goes with the ﬂow. In any case, Web services ingeneral and Web services composition in particular can be expected to play animportant role in future business process systems technology. This will include
both processes within organizations and, more strongly, between organizations.

5

Conclusion

This paper provides an overview of Business Process Management (BPM) andserves as an introduction to this volume of Springer Lecture Notes in Computer
Science devoted to the “Conference on Business Process Management: On the
Application of Formal Methods to Process-Aware Information Systems”. The
goal is to put the contributions to this conference into perspective. Section 1
puts BPM in its historical perspective going back to the late seventies. Section 2
deﬁnes BPM and compares it with workﬂow management. Based on this thepaper zooms into the formal foundations of BPM on the one hand (Section 3)
and technology and emerging standards for BPM on the other hand (Section 4).
This way, the paper reﬂects the objective of this conference: Bringing together(computer) scientists and practitioners to work on advancing BPM methods,
techniques, and tools.

References
1. W.M.P. van der Aalst. Three Good Reasons for Using a Petri-net-based Workﬂow
Management System. In S. Navathe and T. Wakayama, editors, Proceedings ofthe International Working Conference on Information and Process Integration inEnterprises (IPIC’96), pages 179–201, Cambridge, Massachusetts, Nov 1996.
2. W.M.P. van der Aalst. The Application of Petri Nets to Workﬂow Management.
The Journal of Circuits, Systems and Computers, 8(1):21–66, 1998.

Business Process Management: A Survey

11

3. W.M.P. van der Aalst. Making Work Flow: On the Application of Petri nets toBusiness Process Management. In J. Esparza and C. Lakos, editors, Application
and Theory of Petri Nets 2002, volume 2360 of Lecture Notes in Computer Science,
pages 1–22. Springer-Verlag, Berlin, 2002.
4. W.M.P. van der Aalst and P.J.S. Berens. Beyond Workﬂow Management: ProductDriven Case Handling. In S. Ellis, T. Rodden, and I. Zigurs, editors, International
ACM SIGGROUP Conference on Supporting Group Work (GROUP 2001), pages
42–51. ACM Press, New York, 2001.
5. W.M.P. van der Aalst, M. Dumas, A.H.M. ter Hofstede, and P. Wohed. PatternBased Analysis of BPML (and WSCI). QUT Technical report, FIT-TR-2002-05,
Queensland University of Technology, Brisbane, 2002.
6. W.M.P. van der Aalst and K.M. van Hee. Workﬂow Management: Models, Methods,
and Systems. MIT press, Cambridge, MA, 2002.
7. W.M.P. van der Aalst and A.H.M. ter Hofstede. Workﬂow Patterns: On the Expressive Power of (Petri-net-based) Workﬂow Languages. In K. Jensen, editor,
Proceedings of the Fourth Workshop on the Practical Use of Coloured Petri Nets
and CPN Tools (CPN 2002), volume 560 of DAIMI, pages 1–20, Aarhus, Denmark,August 2002. University of Aarhus.
8. W.M.P. van der Aalst and A.H.M. ter Hofstede. YAWL: Yet Another Workﬂow Language. QUT Technical report, FIT-TR-2002-06, Queensland University ofTechnology, Brisbane, 2002.
9. W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros.
Workﬂow Patterns. QUT Technical report, FIT-TR-2002-02, Queensland University of Technology, Brisbane, 2002. (Also see
http://www.tm.tue.nl/it/research/patterns.) To appear in Distributed and Parallel
Databases.
10. W.M.P. van der Aalst, B.F. van Dongen, J. Herbst, L. Maruster, G. Schimm, and
A.J.M.M. Weijters. Workﬂow Mining: A Survey of Issues and Approaches. Data
and Knowledge Engineering, 2003 (to appear).
11. S. Burbeck. The Tao of e-Business Services. IBM Corporation, http://www4.ibm.com/software/developer/library/ws-tao/index.html, 2000.
12. DAML-S and Related Technologies.
www.daml.org/services/daml-s/0.7/survey.pdf, 2003.
13. C.A. Ellis. Information Control Nets: A Mathematical Model of Oﬃce Information
Flow. In Proceedings of the Conference on Simulation, Measurement and Modelingof Computer Systems, pages 225–240, Boulder, Colorado, 1979. ACM Press.
14. C.A. Ellis and G. Nutt. Workﬂow: The Process Spectrum. In A. Sheth, editor,
Proceedings of the NSF Workshop on Workﬂow and Process Automation in Information Systems, pages 140–145, Athens, Georgia, May 1996.
15. H. Eshuis. Semantics and Veriﬁcation of UML Activity Diagrams for Workﬂow
Modelling. PhD thesis, University of Twente, Enschede, The Netherlands, 2002.
16. Gartner. Gartner’s Application Development and Maintenance Research Note M16-8153, The BPA Market Cathes another Major Updraft.
http://www.gartner.com, 2002.
17. A. W. Holt. Coordination Technology and Petri Nets. In G. Rozenberg, editor,
Advances in Petri Nets 1985, volume 222 of Lecture Notes in Computer Science,
pages 278–296. Springer-Verlag, Berlin, 1985.
18. IDS Scheer. ARIS Process Performance Manager (ARIS PPM). http://www.idsscheer.com, 2002.

12

W.M.P. van der Aalst, A.H.M. ter Hofstede, and M. Weske

19. S. Jablonski and C. Bussler. Workﬂow Management: Modeling Concepts, Architecture, and Implementation. International Thomson Computer Press, London, UK,
1996.
20. B. Kiepuszewski. Expressiveness and Suitability of Languages for Control Flow
Modelling in Workﬂows. PhD thesis, Queensland University of Technology, Brisbane, Australia, 2003. Available via http://www.tm.tue.nl/it/research/patterns.
21. B. Kiepuszewski, A.H.M. ter Hofstede, and W.M.P. van der Aalst. Fundamentals of Control Flow in Workﬂows (Revised version). QUT Technical report,
FIT-TR-2002-03, Queensland University of Technology, Brisbane, 2002. (Also see
http://www.tm.tue.nl/it/research/patterns.) To appear in Acta Informatica.
22. P. Lawrence, editor. Workﬂow Handbook 1997, Workﬂow Management Coalition.
John Wiley and Sons, New York, 1997.
23. F. Leymann and D. Roller. Production Workﬂow: Concepts and Techniques.
Prentice-Hall PTR, Upper Saddle River, New Jersey, USA, 1999.
24. D.C. Marinescu. Internet-Based Workﬂow Management: Towards a Semantic
Web, volume 40 of Wiley Series on Parallel and Distributed Computing. WileyInterscience, New York, 2002.
25. H.M.W. Verbeek, T. Basten, and W.M.P. van der Aalst. Diagnosing Workﬂow
Processes using Woﬂan. The Computer Journal, 44(4):246–279, 2001.
26. Dirk Wodtke and Gerhard Weikum. A formal foundation for distributed workﬂow
execution based on state charts. In Foto N. Afrati and Phokion G. Kolaitis, editors,
Proceedings of the 6th International Conference on Database Theory – ICDT ’97,
Delphi, Greece, January 8–10, 1997, volume 1186 of Lecture Notes in Computer
Science, pages 230–246. Springer, 1997.
27. P. Wohed, W.M.P. van der Aalst, M. Dumas, and A.H.M. ter Hofstede. PatternBased Analysis of BPEL4WS. QUT Technical report, FIT-TR-2002-04, Queensland University of Technology, Brisbane, 2002.
28. M.D. Zisman. Representation, Speciﬁcation and Automation of Oﬃce Procedures.
PhD thesis, University of Pennsylvania, Warton School of Business, 1977.