On The Use of Petri Nets for Business Process

Modeling
Eswar Sivaraman and Manjunath Kamath
School of Industrial Engineering & Management
Oklahoma State University
Stillwater, OK 74078

Abstract
We review the fundamentals of business process modeling, and the correctness issues that arise in the con-
ceptual specification of workflows to support workflow management systems (WfMS). WfMS’s automate the
control and coordination of distributed tasks, and also manage associated resource assignments within pre-
specified organizational contexts. The increased efficiency of automated control and coordination of business
processes is made possible by task control constructs that model behaviors like concurrency, asynchronism,
and choice. However, there is a real danger of introducing control flow anomalies and behavioral inconsis-
tencies like deadlock, livelock, imperfect termination, and multiple task repetitions. We illustrate the use
of Petri nets for formalizing business process specifications and the use of analytical techniques to support
verification studies, and conclude with a few issues that merit further research.

Keywords
Business Process Modeling, Workflow Management, Petri Nets, Verification

1 Introduction
The need for re-designing existing business processes, improving process efficiencies, coordinating technol-
ogy with distributed manpower and material resources, and enforcing rapid process development and design
makes it imperative to adequately represent, study, and automate business processes[6, 9]. Business processes
are market-centered descriptions of an organization’s activities, comprising both material processes (involv-
ing physical transformation, assembly, manufacture, etc.) and information processes (involving semi- or fully
automated tasks requiring information infrastructure and support)[9]. Business process modeling (BPM)
provides a conceptual basis for the specification of all business procedures. It aids the coordination and in-
tegration of distributed resources, tasks, and individuals, the effective management of all of which is critical
to sustaining organizational capabilities[5]. Workflow Management supports both business process specifi-
cation and automated execution of business procedures, and is a next-generation extension to BPM efforts
that emphasizes the increased role that information systems have come to play in today’s businesses[21].
Workflow Management involves two phases – (i) the modeling phase that abstracts from business procedures
and defines computer-implementable workflow specifications, and (ii) the execution phase that executes in-
stances of the workflows to meet business requirements, and both these phases are managed and coordinated
by a Workflow Management System (WfMS).

Essentially, a WfMS integrates and automates the execution of steps that comprise a business process [12],
and simultaneously manages resource (information, people, etc.) assignments. Figure 1 highlights the three
major functional areas that a WfMS provides support for, namely, workflow design & definition (the context
of this paper), workflow instantiation & control, and interaction with users & other applications[12, 20]. This
paper focuses on the modeling and analysis issues involved in establishing logical and syntactical correctness
of business process specifications before they are implemented. Other issues related to post-implementation
correctness, namely, data consistency and database integrity (i.e., transactional guarantees), and exception
(i.e., failure) handling required for run-time control[5, 14, 13] are beyond the scope of this paper.
 Workflow Instantiation Interaction with Users &
Workflow Design & Definition
& Control Application Tools

Human
Resources

Process
Changes Workflow
Process
Enactment
Definition
Service

Applications
Modeling and & IT Tools
Analysis Tools

Build-Time Run-Time

Figure 1: Workflow Management System - Reference Model

The complete specification of business processes includes (i) the control flow, i.e., the partial and total
ordering specifying the sequence of the various tasks, (ii) the data flow, i.e., the information requirements,
and the resource (people, machines, etc.) allocations for the execution of the various tasks. This is required
for identifying the input and output requirements for each task, and also to put together a skeletal outlay
of the process that is both conceptually and descriptively complete. There has been siginificant research in
developing process metamodels, namely, a representational language in which to express workflow models
amenable to automation – the reader is referred to [27, 15, 5] for an excellent review of the same. Additionally,
the Workflow Management Coalition (WfMC) has been working toward standardizing workflow specification
languages to enable interoperability between different vendors, and has evolved a process modeling language,
the syntax of which should be supported by all WfMSs – this is discussed further in Section 2. Stated simply,
the ability to represent behaviors like concurrency and choice increases the chances of defining logically
incorrect models with control flow errors, the execution of which could result in deadlock, livelock, etc. The
focus of this paper is to highlight the versatility of Petri nets as a technique for formalizing business process
models to analyze verification issues, and to support performance evaluation studies.

2 Process Modeling: The Essentials

The purpose of process modeling is to produce an abstraction of the process that serves as a basis for detailed
definition, study, and possible reengineering to eliminate non-value added activities. The process model
must allow for a clear and transparent understanding of the activities being undertaken, the dependencies
among the activities, and roles (people, machines, information, etc.) necessary for the process. We will
use an activity-centered modeling methodology for defining process models in that a process is viewed as a
sequence of inter-related tasks, the transfer of control between them being determined by logical operations;
the reader is referred to [16, 4, 5, 9] for an excellent review of other modeling methodologies.

Sequential Control

Concurrent Task Task Task

2 3 4 Asynchronous
Control
Completion

Task Task
1
AND Choice AND
7

Task
5

XOR XOR

Task
6

Figure 2: Process Modeling - An Example (showing control flow only)

For the remainder of our discussion, we will consider a business process model to be a collection of elements,
where an element is either a task, or a logical operand that serves to route the flow of control (parallel and/or
sequential) between the tasks – these are based on generic modeling concepts prescribed by the WfMC[26].
2.1 Analysis Issues in Business Process Modeling
The ease and flexibility of graphical modeling languages brings with it a possibility for introducing control
flow anomalies in process specifications. Table 1 illustrates a few of the major control flow verification issues,
i.e., checking for deadlock, livelock, multiple repetition, etc., and [18] presents a more elaborate presentation
on other issues that are further classified as simple and complex. Additionally, improving process efficiency,
performance evaluation, etc., requires that we have a definite framework within which to formulate questions
to study all aspects of processes – data and resource allocations, and task definitions.

Table 1: Verification Issues in Business Process Specifications

Verification Issues Example

T2
Deadlock: When control flow from one of
T1 XOR AND T4
several required merging paths is missing. T3

Multiple Repetition: When control T2

flow arrives from multiple sources, but T1 AND XOR T4

only one is necessary. T3

T2
Livelock: When control flow fails to exit
T1 XOR
out of a set of previously executed tasks. T3 T4

An incremental approach to formalizing and analyzing business process models is suggested, as follows:

Control Flow Correctness: Create a control-flow model specifying just the tasks, and the ordering re-
quired within, without the overhead of resource, data requirements - Petri nets have emerged as a very
popular technique for such abstractions[20, 1]. These models have been used to answer the following
questions: (i) the initiation problem is to determine if there is a sequence of task executions that will
lead to the execution of a particular task – this has been shown to be NP-complete[11], and (ii) the
termination problem is to determine if the control-flow specification will lead to a terminal state – this
has been shown to require exponential storage requirements[11].

Data Flow Correctness: Extend the control-flow model with the operational specifics of resource require-
ments, allocations, etc., thereby specifying the data flow as well. A few questions that could be posed
to this model are: (i) given a task that we need to execute, what other tasks must be executed before
we can fulfil the input requirements (resource and data) for the chosen task?, (ii) if a particular task
is disabled, what other tasks will be affected? and (iii) if a resource, or data element is disabled, will
the process be affected?, to state just a few. Metagraphs[3] appear very promising as an analytically
sound technique, with much visual appeal, to address these questions – this is a relatively new concept,
and research is still forthcoming.

Between the two, control-flow correctness ensures that the process, by design, is correct, independent of how
it is implemented or monitored, and for the remainder of our discussion, we will explore the use of Petri
nets for establishing the same.

3 Petri-Net Formalizations of Business Process Models

Intuitively, any process can be understood to be a collection of events, the conditions that enable these events
to occur, and the conditions that are satisfied following the completion of these events. A Petri net ideally
mirrors this intuition, and explicitly separates the conditions, and the events involved in a process, and
models state changes involved therein, through a simulated movement of tokens. A Petri net is a directed,
bi-partite graph with two kinds of nodes – places (represented as circles), where one or more tokens (black
dots) can reside, and transitions (represented as bars) that can be fired to move tokens from their input
places to their output places. The places model the conditions required to enable events, which are modeled
by the transitions – readers will no doubt note that the explicit delineation of conditions and events pertains
to the activity-based methodology discussed in Section 2. Figure 3 depicts the Petri net representation of
the process described in Figure 2, and Table 2 illustrates the Petri net mappings for basic routing constructs
required in process modeling.

Sequential Control

Asynchronous
Task 2
Completion
Task 3 Task 4

Concurrent
Choice
Control

Stop

Task 5
Task 7
Start

Task 1

Task 6

Figure 3: Petri Net Representation - An Example (control flow only)

Petri-nets offer the advantage of graphical appeal coupled with a rigorous formalism that has found tremen-
dous use in modeling systems and processes that exhibit asynchronism, concurrency, and determinism[17, 7].
Petri nets are especially attractive for formalizing and analyzing business processes for the following rea-
sons: (i) clear and unambiguous description of process logic, (ii) intuitive ease and feel of a self-documenting
graphical formalism that retains complete conceptual clarity, and (iii) extensive analysis capabilities that
vastly extend the power and usefulness of structured process description languages like IDEF3. The control
flow issues highlighted in section 2.1 are readily expressed in Petri-net theoretic terms, e.g., reachability,
deadlock, liveness, etc.[7]. Moreover, Petri nets allow for a study of both (i) structural properties pertaining
to the static aspects of the process’s definition, and (ii) behavioral properties pertaining to the dynamic
aspects of the process observed during its execution[7, 17], the latter being useful in deriving summary
measures (e.g., cycle time) for performance evaluation studies[25].

3.1 Current Research Approaches for Establishing Control Flow Correctness

There are two approaches to ensuring correct models – (i) build it correctly, or (ii) check it completely. The
former relies on strict grammatical rules that govern the composition of the various elements in the model,
and this is the basis of the model-theoretic event algebras designed by [22, 8], which may not be very suitable
for practical implementation in industry. The latter, on the contrary, is more appealing, both in allowing the
user tremendous flexibility in expressing process requirements, and in offering interesting analysis challenges
to the modeler. These are the considerations that have prompted the use of graph-theoretic techniques[19, 3],
and Petri nets [1, 23, 24] for verification studies – they do not inhibit the modeler, or the analyst. The
standard approach to establishing control-flow correctness in Petri net formalizations of business process
models is to establish the soundness property[2], or the simple control property[23], which is the initiation
problem and the termination problem both wrapped in one (refer Section 2.1). Stated simply, the idea
is to put a token in the place labeled Start (Figure 3), and to see if the execution of the Petri net will
produce a token in the place labeled Stop, without leaving any residual tokens elsewhere in the net. The
majority of business processes have been analyzed using acyclic (i.e., loop-free) free-choice nets, a special
class of Petri nets[7] that enjoys the added advantage that soundness can be verified in polynomial time[1].
Additionally, establishing soundness in a free-choice net implies that the net is free from deadlock, and is
also live, i.e., no dead tasks[2]. However, hurdles remain, in that the modeling of exceptions or precedence
partially destroys the free-choiceness of the equivalent Petri net mapping. Moreover, modeling iteration
necessitates the presence of loops in the control flow model, a problem which is yet to be satisfactorily
addressed.
 Table 2: Petri Net Mappings of Basic Routing Constructs

Logical Operand Graphical Construct Petri Net Mapping

Activity Activity 2
AND-Join: A point within 2

the process model where a Activity

AND
Activity
Activity 1 Activity 3
single thread of control splits 1 3

into two or more threads to Activity

4 Activity 4
be executed simultaneously.

Activity
Activity 1
AND-Join: A point within 1

the process model where two AND

Activity
Activity 3
or more different threads 3

of control merge asyn- Activity

Activity 2
2
chronously.

Activity
Activity 2
XOR-Split: A point within 2

the process model where the Activity

XOR Activity 1
thread of control selectively 1

chooses one of several possi- Activity

Activity 3
3
ble paths.

Activity Activity 1
XOR-Join: A point within 1

the process model where the Activity Activity 3

XOR
thread of control from one 3

of several different paths con- Activity

2 Activity 2
verges.

Iteration/Feedback Rout-
ing: A section within the Activity Activity
Activity 1 Activity 2
XOR XOR
process model that may re- 1 2

quire the repetitive execution Activity

3
of one or more activities un- Activity 3

til certain conditions are sat-

isfied.

4 Summary & Conclusions

Petri nets have emerged as the medium of choice for analyzing business process models to provide use-
ful diagnostic feedback to support process re-design, and effective resource, organization, and function
management[2, 20]. We have presented a self-contained overview of the opportunities available in the
emerging field of workflow management, the correctness issues involved therein, and some of the ideas be-
ing pursued in the author’s dissertation. The focus has been to illustrate the use of Petri nets to bridge
the gap between process modeling languages[4, 27], and process implementation & workflow automation
techniques[5, 13], so that logically correct process specifications created with the former are effectively im-
plemented in the latter.
The issues that merit future research are: (i) extend soundness results established for acyclic free-choice
constructions to business process models involving iteration, and potential non-free-choice constructions,
and (ii) establish results for verifying data-flow correctness that could find use in performance evaluation
studies, and other real-time transactional issues[14, 13]. A more interesting question that could very well
supersede all the efforts presented in this paper is “is the process definition really optimal?” – this is the
focus of the ideas initiated in [10], and there is much ground to be covered here.

Acknowledgments
This research was supported, in part, by NSF Grant #DMI-0075588 under the Scalable Enterprise Sys-
tems Initiative. We would also like to thank Dr. Nikunj Dalal, Dr. William Kolarik, Mr. Amit Chaugule,
Mr. Ramasamy ChinnanChetty, and Mr. Karthik Ayodhiramanujan for their support and comments.

References
[1] Aalst, W.M.P. “The Application of Petri Nets to Workflow Management”. The Journal of Circuits,
Systems, and Computers, 8(1):21–66, 1998.
[2] Aalst, W.M.P. “Workflow Verification: Finding Control-Flow Errors Using Petri-Net Based Tech-
niques”. In Aalst, W.M.P., Desel, J., and Oberweis, A., editors, Business Process Management –
Models, Techniques, and Empirical Studies, volume 1806 of Lecture Notes in Computer Science, pages
161–183. Springer-Verlag, 2000.
[3] Basu, A. and Blanning, R.W. “A Formal Approach to Workflow Analysis”. Information Systems
Research, 11(1):17–36, 2000.
[4] Chen, P. A Use Case Driven Object-Oriented Design Methodology for the Design of Multi-Level Work-
flow Schemas. PhD thesis, Department of Computer Science, Ill. Inst. of Tech., Chicago, IL, 2000.
[5] Cichocki, A., Helal, A., Rusinkiewicz, M., and Woelk, D. Workflow and Process Automation: Concepts
and Technology. Kluwer Academic Publishers, MA, 1998.
[6] Curtis, B., Kellner, M.I., and Over, J. “Process Modeling”. Comm. of the ACM, 35(9):75–90, 1992.
[7] Desel, J. and Esparza, J. Free Choice Petri Nets. Cambridge University Press, 1995.
[8] Fan, W. and Weinstein, S. “Specifying and Reasoning About Workflows with Path Constraints”.
In Proceedings of the 5th International Computer Science Conference(ICSC’99), HongKong, China,
volume 1749 of Lecture Notes in Computer Science. Springer, Dec. 13-15 1999.
[9] Georgakopoulos, D., Hornick, M., and Sheth, A. “An Overview of Workflow Management: From
Process Modeling to Workflow Automation Infrastructure”. Distributed and Parallel Databases, 3:119–
153, 1995.
[10] Hofacker, I. and Vetschera, R. “Algorithmical Approaches to Business Process Design”. Computers &
Operations Research, 28:1253–1275, 2001.
[11] Hofstede, A.H.M., Orlowska, M.E., and Rajapakse, J. “Verification Problems in Conceptual Workflow
Specifications”. Data & Knowledge Engineering, 24(3):239–256, 1998.
[12] Hollingsworth, D. “The Workflow Reference Model”. Technical Report WfMC-TC-1003, The Workflow
Management Coalition, http://www.wfmc.org/standards/docs.htm, 1995.
[13] Kamath, M.U. Improving Correctness and Failure Handling in Workflow Management Systems. PhD
thesis, Department of Computer Science, University of Massachusetts, Amherst, MA, 1998.
[14] Kamath, M.U. and Ramamritham, K. “Correctness Issues in Workflow Management”. Distributed
Systems Engineering Journal, 3(4):213–221, December 1996. Special Issue on Workflow Systems.
[15] Lei, Y. and Singh, M.P. “A Comparison of Workflow Metamodels”. Proceedings of the ER-97 Workshop
on Behavioral Modeling & Design Transformation Issues and Opportunities in Conceptual Modeling,
Los Angeles, CA, November 1997. http://osm7.cs.byu.edu/ER97/workshop4/ls.html.
[16] Mentzas, G., Halaris, C., and Kavadias, S. “Modelling Business Processes with Workflow Systems: An
Evaluation of Alternative Approaches”. Int. J. of Information Management, 21:123–135, 2001.
[17] Murata, T. “Petri Nets: Properties, Analysis, and Applications”. Proceedings of the IEEE, 77(4):541–
580, 1989.

[18] Sadiq, W. and Orlowska, M.E. “On Correctness Issues in Conceptual Modeling of Workflows”. Pro-
ceedings of the 5th European Conference on Information Systems (ECIS’97), Cork, Ireland, June 19–21,
1997. http://www.dtsc.edu.au/praxis/Publications/index.html.
[19] Sadiq, W. and Orlowska, M.E. “Analyzing Process Models using Graph Reduction Techniques”. In-
formation Systems, 25(2):117–134, 2000.
[20] Salimifard, K. and Wright, M. “Petri-Net based Modeling of Workflow Systems: An Overview”. Euro-
pean Journal of Operational Research, 134(3):218–230, 2001.
[21] Sheth, A., Aalst, W.M.P., and Arpinar, I. “Processes Driving the Networked Economy”. IEEE Con-
currency, 7(3):18–31, 1999.
[22] Singh, M.P. “Formal Semantics for Workflow Computations”. Technical Report TR-96-08, Department
of Computer Science, North Carolina State University, January 1996.
[23] Straub, P. and Hurtado, C.L. “The Simple Control Property of Business Process Models”. Pro-
ceedings of the XV Conference of the Chilean Computer Society, Arica, Chile, Oct. 30-Nov. 3, 1995.
ftp://ing.puc.cl/doc/techReports.

[24] Straub, P. and Hurtado, C.L. “Control in Multi-Threaded Information Systems”. Unpublished working
report, Computer Science Department, Catholic University of Chile, Santiago, Chile, 1997.

[25] Viswanadham, N. and Narahari, Y. Performance Modeling of Automated Manufacturing Systems.

Prentice-Hall, Inc., 1992.

[26] WfMC. “Terminology & Glossary”. Technical Report WfMC-TC-1011, The Workflow Management
Coalition, http://www.wfmc.org/standards/docs.htm, 1999.

[27] WfMC – Work Group 1. “Interface 1: Process Definition Interchange Process Model”. Technical Report
WfMC-TC-1016-P, The Workflow Management Coalition, http://www.wfmc.org/standards/docs.htm,
1999.