Essential Business Process Modeling

Content preview·Buy reprint rights for this chapter

IN THE WORLD OF SOFTWARE, THE WORD "PROCESS" HAS SEVERAL DENOTATIONS. The verb means to handle, as in processing an error, or processing a message. The noun sometimes refers to a program running in an operating system, and sometimes to a procedure, or a set of procedures, for accomplishing a goal. In each case, the connotations of the term are movement, work, and time; a process performs actions over some interval of time in order to achieve, or to progress to, some objective. This book addresses the concept of a business process, which we all intuitively understand as the step-by-step rules specific to the resolution of some business problem. As mentioned in the Preface, business process modeling (BPM), sometimes called business process management, refers to the design and execution of business processes. This book explores BPM's foundations, standards and typical uses.

This chapter examines an example problem, a travel reservation application, that models the nature of a business process and its core concepts. Stated informally in English, the process for this application is the following:

Get the customer's itinerary.
For each item on the itinerary, attempt to book with the target company. Specifically, book a flight with the airline, a room with the hotel, and a car with the car rental agency. These bookings can be made in parallel.
If all the bookings succeed, get payment from the customer and send the customer a confirmation. Process completes normally!
If at least one booking fails, cancel the successful bookings and report the problem to the customer.
If the user does not wish to continue, stop the process . Otherwise, return to Step 1.

For a software developer, this listing reads like an algorithm: it is a sequence of steps, with conditions, loops and—to complicate matters a little—parallelism. Indeed, a carefully conceived process is algorithmic and is often sketched, either extemporaneously on a meeting room whiteboard or deliberately and rigorously with drawing software, as a flowchart, such as the one shown in Figure 1-1.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

An organization's decision to build a BPM solution is made by its business architects , CIO, CTO, or CEO. Possible motivations for choosing BPM include the following:

Formalize existing process and spot needed improvements: Adopting BPM forces a business to think through and formalize its understanding of current processes. Along the way, those running the business invariably spot potential improvements, such as the removal of steps, automation of manual steps, or the reengineering of a part or the whole of the flow.
Facilitate automated, efficient process flow: Given that a process spans multiple activities, the less time spent between activities, the better. When BPM software drives the process flow, downtime between activities is almost zero, unless the software itself is down. Even better, BPM supports process parallelism, so that independent sequences of work can be performed concurrently in isolation of each other, with their results merged and synchronized later in the flow. A process controlled by some other means—for example, by phone calls, emails, or inter-office mail exchange—is bound to be significantly slower and prone to getting lost or stuck.
Increase productivity and decrease head count: Get work done faster with fewer people! Actual BPM case studies provide some interesting results: a financial services was able to reduce staff from 613 to 406 while decreasing processing time and increasing customer satisfaction; an insurance company trimmed off 40% of its staff and increased its rate of claims handling.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Irrational exuberance about BPM might compel a vendor or customer to believe that BPM is the solution to all enterprise application problems. After all, BPM empowers the business analyst, who knows the application requirements best, to create a design or flowchart for the high-level logic. And after all, what is an enterprise application but a set of logic? The flaw in this argument is that the logic of a process is not its procedural implementation but its declarative dynamic behavior, or its change in state over time as events occur.

Many BPM vendors provide a graphical process editor that lets the end user design a process by dragging boxes and arrows onto a canvas. The drawing that the user creates looks like a program, but it is really a kind of state diagram for the process. A good BPM product makes it relatively easy to turn the diagram into an executable application; it is a matter of filling in the blanks. But this ease does not make the product the right choice to build all executable applications.

BPM is suited only for applications with an essential sense of state or process—that is, applications that are process-oriented . An application passes the BPM acid test if it is legitimately process-oriented. The travel agency application, for example, passes the test because it is best understood in terms of the state of the itinerary and is defined at all times by how far the itinerary has gotten. Other typical characteristics of a process-oriented application include the following:

Long-running: From start to finish, the process spans hours, days, weeks, months, or more.
Persisted state: Because the process is long-lived, its state is persisted to a database so that it outlasts the server hosting it.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

BPM is one of the most fashionable three-letter acronyms in software today. The field is known for having many competing vendors and standards, unusually named academic underpinnings, and a diverse set of potential users, from techies to business analysts, business architects, CIOs, CTOs, and CEOs.

The topic of BPM is profoundly simple to the beginner: the business analyst designs the process, the process is run by an engine, and the engine has EAI and human interaction capabilities. In practice, a morass of concepts, terminology, standards , vendors, and philosophies confounds the intermediate-level student of BPM who knows the basics but is lost in detail—and is also responsible for building a BPM-based solution. Which product to choose? Or is the right solution the combination of several products, such as a design tool product and an execution engine product? Which standard to build on? Which version of which standard? Are the standards too immature? Are the products themselves immature?

The goal of this book is to discover through the morass a system of thought that, like all good systems, depends on a small number of concepts. The medieval philosopher William of Ockham argued:

Entia non sunt multiplicanda praeter necessitatem.

(Entities ought not to be multiplied without necessity.)

Known as Ockham's Razor , this aphorism implies that a good system is fundamentally simple. Reducing BPM to its essentials yields the following basic criteria:

A good BPM architecture, as described in Chapter 2, is as elegant an enterprise architecture as can be. Many applications fail because they lack an intelligible initial design; BPM can prevent this.
Some BPM standards are better than others. A good BPM solution is achieved by choosing the best pieces. The adoption of BPEL and BPMN is a recipe for success.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Not long ago—exactly how long is hard to estimate—everyone used the term "workflow " to refer to the subject that is now called BPM . Already confounded by hype and an excess of ideas, somewhere along the way, the process world suffered an identity crisis. But is this transition from workflow to BPM merely nomenclatural or is it tied to a genuine change in meaning? Many contemporary observers think BPM and workflow have subtly different meanings, that BPM is superior to workflow management, and, in fact, has made it obsolescent.

The landmark survey of enterprise client/server technologies, Client/Server Survival Guide, positions workflow as a groupware technology that complements email, imaging document management, and calendar features. Workflow is the flow of work, encompassing the exchange and enrichment of information:

The classical workflow paradigm is a river that carries the flow of work from port to port and along the way value gets added. Workflow defines the operations that must be visited along the way and what needs to be done when exceptions occur.

In the past, workflow meant passing paper from person to person. Workflow technology improved things not only by managing the flow of work but also by digitizing the information, thereby making the process as automated and paperless as possible. Figure 1-10 illustrates a typical workflow scenario.

Figure 1-10: Workflow process based on scanned image

And though this approach helped speed up processes limited to a small workgroup, such as insurance claim handling, the perception of workflow by many observers, as argued by Staffware CEO Jon Pyke, is that it lacked integration capabilities. In the contemporary world of BPM, document imaging is a marginal technology; a process is expected to speak the modern dialects of XML, B2B, EAI, and web services.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

If you are new to BPM, the sheer number of terms, standards , standards bodies, and other ideas introduced in this chapter may seem overwhelming. Table 1-1 is a quick reference list of BPM standards; it also points out the chapter in which each is discussed.

Table 1-1: BPM standards roadmap
Standard	Body	Chapter	Description
Business Process Execution Language (BPEL)	OASIS	5	BPM's most popular language; represents a process as XML with web services bindings
Business Process Modeling Language (BPML)	Business Process Modeling Initiative (BPMI)	6	An XML process language similar to BPEL
Business Process Modeling Notation (BPMN)	BPMI	6	Graphical language with a mapping to BPEL
Workflow Reference Model	Workflow Management Coalition (WfMC)	7	A basic architectural approach to workflow/BPM

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The main points of this chapter include the following:

A business process is the step-by-step algorithm to achieve a business objective. The best visualization of a business process is a flowchart. A process can actually be executed by a process engine, provided its logic is defined precisely and unambiguously. When a process definition is input to an engine, the engine can run instances of the process. The steps of the process are called activities. Business process modeling (BPM) is the study of the design and execution of processes.
BPM is concerned only with process-oriented applications. Not all enterprise applications qualify. The process-oriented acid test of an application is whether it is long-lived and defined at a given time by its state. The example travel agency application passes the test because of it manages itinerary state. OLTP applications, such as ATMs, fail because they lack longevity and state.
BPM, because of various competing standards (BPEL4WS, BPML, and BPMN; WSCI, WfMC specifications), vendors (IBM, BEA, Microsoft, Staffware, See Beyond, Vitria, and others), and even computer science underpinnings (pi-calculus, Petri nets), is a maze that confounds many onlookers. This book attempts to discover, through the confusion, an elegant, process-oriented application architecture.
Among the benefits of BPM are the formalization of current processes and the occasion for reengineering, greater efficiency, increased productivity and decreased head count, the ability to add people to a process to resolve hard problems, and the traceability of compliance processes.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Y. Goland, "The Race to Create Standards: The Road To Maturity," WebLogic Developer's Journal, unpublished (date TBD).
M. Havey, "Workflow and State Machines: The Process-Oriented Application," WebLogic Developer's Journal, January 2004.
P. L. Crosman, "What's the Difference Between Workflow and BPM?" Transform Magazine, December 2003, http://www.transformmag.com/showArticle.jhtml?articleID=16400140.
IBM, "Business Processes: Understanding BPEL4WS," August 2002, http://www.ibm.com.
W. M. P. van der Aalst, J. Desel, and A. Oberweis (editors), Business Process Management: Models, Techniques, and Empirical Studies, Volume 1,806 of Lecture Notes in Computer Science, Springer-Verlag, Berlin, 2000.
W. M. P. van der Aalst and K. M. van Hee, Workflow Management: Models, Methods, and Systems, MIT Press, Cambridge, MA, 2002.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

BPM STANDARDS ABOUND, EACH WITH A DISTINCT DESIGN AND FEATURE SET. This chapter scavenges these approaches in search of a general BPM application architecture that is conceptually comprehensible and meets real-world requirements. A good architecture uses the technique of divide-and-conquer to reduce a difficult problem to smaller, more manageable parts, and where possible, it solves each part not by inventing new technology but by reusing an existing approach. Applying this technique, we ask: in a BPM architecture, what is the problem to be solved, what are its parts, and which standards, if any, solve them?

The architecture presented here is intended as a reference model—with similarities to the WfMC's model (see Chapter 7) and the proposed stack of the BPMI (see Chapter 6)—targeted at product and services architects alike. The appeal for product architects is obvious: the model, though lacking the level of detail for a micro design, has the same form as a BPM product, and can help guide the overall construction. Services architects, who typically advocate buying a good vendor solution and customizing it rather than building the entire solution from scratch, need to comprehend the essential nature of the base product. Rather than treating it as a black box, these architects should have a sense of curiosity analogous to that of a driver who lifts the hood of a car and seeks to grasp the basic mechanics of all those belts and gears. There are a number of reasons why:

BPM is an emerging subject, and in the current morass of vendors, standards, hype, and theory, having a crystal-clear notion of a good solution (whether built or bought) gives an architect a competitive advantage over the many who are still learning.
Customers know the essential architecture of some of their IT products and technologies (e.g., database, operating system, network router), but they probably have a fuzzier notion of BPM, and they expect the services architect to help explain it to them and guide them through adoption.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

To design a good BPM solution, you must first step back and examine the project's environment: understanding the problem, noting the local and larger-scale perspectives, and only then creating a design and testing your solution.

To understand what a good solution looks like, you must first understand the scope of the problem to solve. The main requirement of a BPM application is the ability to design, run, and monitor and administer business processes that incorporate human and system interactions, described as follows:

Design: The design of a business process is intuitively a flowchart that outlines the steps performed over time in the resolution of a business problem. Unlike most object-oriented designs, whose audience is the technical team of a project, a process design is crafted and comprehended by both business and technical analysts . Business analysts are involved because they understand the business aspects of the process best; the design is simply a rigorous expression of what they frequently draw on paper or on a whiteboard. The level of rigor, plus the anticipation of implementing a software solution to the design, draws in technical analysts. Thus, business and technical designers require a common design notation that is at once business-oriented and amenable to computer processing. They also require a graphical editor in which to sketch their design.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Having glimpsed the BPM architecture "from 30,000 feet," we now descend to a lower altitude to get a closer look at each of its major components. This section examines the requirements and proposes designs for the notations and graphical tool, the runtime engine, the human and system interaction interfaces, the administration and monitoring facilities, and the CDL toolkit.

The need for a graphical process modeling language is often overlooked in the BPM standards race. Most BPM languages are XML-based and can be relatively difficult to compose or read. Design is best communicated with diagrams. Scan through a typical object-oriented component design document, for example, and you will discover that a single UML class diagram can convey most of the intended meaning, making many of the surrounding words redundant. If a picture is sufficiently rich, it is worth more than a thousand words! Standardization adds even more value. A diagram that is drawn to a standard specification is familiar to a wide audience, and its semantics are also clearly understood. Readers get the gist of a haphazardly drawn assemblage of boxes and arrows, but the lack of precision in representation makes it less intelligible.

BPM has two good graphical modeling notations—BPMN (Chapter 6) and the UML activity diagram (Chapter 3)—but BPMN is the preferred choice for our architecture because it is more expressive (it supports most of the "P4" patterns described in Chapter 4) and has a mapping to BPEL.

ITpearls' Process Modeler tool, for example, is a BPMN drawing tool with BPEL export capabilities. As Figure 2-4 shows, ITpearls provides a set of stencils that are imported into Microsoft Visio.

A BPMN diagram is drawn by dragging shapes from one of the stencils onto a canvas sheet. The ITpearls tool also embeds a Process menu in the Visio menu bar. As shown in the figure, the designer can export the diagram to a file; at the time of writing, this function was planned for BPEL and BPML formats but was not yet available.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Table 2-6 lists the major BPM standards and where they fall within our model architecture .

Table 2-6: BPM standards: where they fit
Name	Organization	Type	Chapter
Workflow Reference Model	WfMC	Architectural model	Chapter 7
Business Process Modeling Notation (BPMN)	BPMI	Notation language	Chapter 6
UML Activity Diagram

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The main points of this chapter include the following:

BPM is replete with competing standards, but a sound architectural approach divides a BPM application into the right parts and selects the correct standard for each.
The requirement of a BPM application is the ability to design, run, administer, and monitor processes that incorporate system and human interactions.
Two types of architects benefit from this discussion. Product architects learn, at a high level, a good approach to developing a BPM product. Services architects learn the essential nature of a BPM product platform, enabling them to build good solutions on it and to educate their customers about this emerging technology.
Design, the modeling of processes by business and technical analysts, requires a graphical notation language and a graphical design tool, such as ITpearls' Process Modeler. BPMN is the best standard notation language.
To run a process requires a runtime engine that can load designs and manage the execution of instances. However, there is no way to run a notational drawing; it is just a design artifact. A runtime engine requires an executable language, just as a computer processor requires programs that use the processor's instruction set. To bridge this gap, a mapping from notational to executable language is needed. The design tool should offer an export option that uses the mapping to generate executable code. With respect to standards, BPEL is the best and most widely adopted executable language, and our chosen notational language, BPMN, includes as part of its specification a detailed mapping to BPEL.
Administration and monitoring is crucial for the success of a production application. An administrative console, along with a sufficient data model and a standard system management interface language, helps administrators track and change the managed objects of the runtime engine, including process definitions, processes, activities, manual tasks (worklist items), and users and roles.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Oracle, "BPEL Tutorial 6: Working with the TaskManager Service," http://otn.oracle.com/bpel.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

In most software topics, the boundary between theory and practice in software is clearly drawn: theory is for academics who seldom descend from the ivory tower, and practice is for industry professionals who have long forgotten the concepts and application of theory. In concurrency, for example, most developers either know or have programmed semaphores, but few remember the conceptual underpinnings devised by Dijkstra.

But BPM belongs to a rarer category, in which theory informs practical design and theoretical jargon is part of the hype with customers. Somehow the abstruse terms "pi-calculus" and "Petri net"—as impressive to the ear as database management's "relational calculus" or capacity planning's "Erlang formulae"—have permeated the consciousness of the BPM community. Many BPM onlookers are familiar with and interested in pi and Petri, but have at best a vague understanding of them, and prefer an executive summary or beginner's treatment; the pedantic details are best left to graduate students.

Process theory is practically important for several reasons:

It is mentioned frequently in connection with BPM, even in nonacademic material. Countless presentations, for example, state without explanation that BPEL is influenced by the pi-calculus and Petri nets. For the many practitioners who are intimidated by the pedantic name-dropping but are curious to uncover its meaning (asking questions such as: What is the pi-calculus ? What are Petri nets? Which parts of each theory are used in BPEL? Why is BPEL based on two theories rather than one?). This chapter helps explain the nature of the connection.
BPM is relatively immature and benefits from the ideas and rigor of theory. Control flow, for example, is often treated too casually by vendors, who are more likely to emphasize ease of programming rather than semantic precision. Regrettably, as several papers on process-design patterns have demonstrated, most vendors—and even most standards—struggle to support certain common control flow scenarios (e.g., the "multiple instances without runtime knowledge" and "interleaved parallel routing" patterns, described in Chapter 4). To build successful solutions, practitioners should insist on knowing exactly how a given process will run. To accomplish this, they should choose a good language and understand how it works. Judged on the basis of control flow, the strongest languages are those that are based on the Petri net, including BPEL and BPMN. And, arguably, understanding the nuances of these languages—e.g., dead path elimination in BPEL—requires an appreciation of the Petri net.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Pi-calculus and the Petri net (or some combination of the two) provide the theoretical underpinnings for most of the major BPM standards. Four of the major contemporary standards betray pi-calculus influence:

WS-CDL
WSCI
BPML
XLANG

Three other major standards derive from the Petri net:

BPMN
YAWL
WSFL

Finally, BPEL is a blend, inheriting traits of pi and Petri from its parent languages XLANG and WSFL, respectively. Figure 3-1 illustrates these relationships.

Figure 3-1: Theory family tree for BPM standards

In Figure 3-1, boxes represent standards, circles theories, and arrows dependencies. The level of dependency is extremely variable. Petri, for example, is woven into the fabric of YAWL, whereas BPMN and WSFL seem to merely draw inspiration from it. Pi's connection to each of its children is inspiration at best and mere hype at worst.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Developed by Scottish mathematician Robin Milner in the 1990s, the pi-calculus is a formal language for defining concurrent, communicating processes, including, but not restricted to, business processes. In its detail, the pi-calculus is a rather advanced algebraic system requiring a senior level of mathematical training. Milner's presentation of the subject is written in the mathematical idiom of definitions, theorems, and lemmas, inaccessible to most BPM onlookers. Few business analysts or software developers could survive if required to compose their business processes as lines of pi-calculus code.

But somehow, despite its academic roots and its inherent complexity, the pi-calculus has become one of BPM's most attention-getting cocktail party terms. Popular BPM literature states boldly that major languages such as XLANG, WSCI, BPML, BPEL, and WS-CDL are based on the pi-calculus. This stunning level of influence, charges leading BPM commentator Wil van der Aalst, is dubious, and surely nothing but hype:

Let the people that advocate BPEL4WS, BPMN, ... and WSCI show the precise relation between the language and some formal foundation. People that cannot do this but still claim strong relationships between their language and e.g., pi-calculus, only cause confusion.

Whether or not it is hype, the pi-calculus-BPM connection merits a serious look. What, in a nutshell, is the pi-calculus, how does it apply to BPM, and what is the extent and nature of its influence on contemporary popular languages like XLANG and WS-CDL?

Robin Milner visited Petri net creator Carl Adam Petri in Bonn in the 1980s to learn more about concurrent systems.

As mentioned earlier, the pi-calculus is a language that defines concurrent processes that interact with one another dynamically. Each process consists of one or more

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The Petri network (or Petri net ), a notion devised in 1962 by the mathematician Carl Adam Petri, is a formal graphical process modeling language that can design systems as diverse as train track switches and business processes. With respect to the latter, Petri nets help describe—and indeed, can be used to implement—the semantics of process control flow, including basic branch and join rules, as well as more complicated synchronization scenarios; notably, dead path elimination , a core topic in the languages WSFL and BPEL. Petri net theory saturates the literature on process patterns, a topic introduced in Chapter 4. The keen analysis of this work, undertaken by a group of pro-Petri authors referred to in this book as the P4, injects much-needed rigor into an historically ambiguous and haphazard subject. Though among BPM champions it lacks the renown of the pi-calculus, the Petri net is a valuable abstraction and merits the attention it has been paid.

The Petri net's characteristic appearance is that of an unusual assembly of circles, rectangles, arrows, and black dots. The beginner might at first mistake it for a state-transition diagram, reasoning that the circles and rectangles are states, the arrows transitions, and the dots some other curious artifact specific to the model. But although the Petri net shares with the state machine a preoccupation with the notion of state, to compare the two is like comparing apples and oranges.

In Petri's original conception, referred to as the classical net, the symbols are the following:

Place: Drawn as a circle, a place is a stopping point in a process, representing (in many cases) the attainment of a milestone.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

With its proud history and redoubtable theoretical credentials, the state machine (like the pi-calculus and the Petri net) is a guiding light to the practice of process design. As you will see, the representation of a process as a state diagram is markedly different from its more intuitive flow-chart implementation, and—being based on a more rigorous, more expressive system—is often clearer and more compact

State diagrams have a rich history. Alan Turing, the father of computer science, used the concept to build a model of computability. (See the sidebar "A Noble History...") State machine theorists Mealy, Moore, and Harel expanded the subject. Mealy and Moore built similar models whose essential differences—Mealy held that actions are performed in transitions, Moore that they are performed in states—were reconciled in Harel's later work on state charts. Harel allowed actions in both states and transitions, and enhanced the previously flat models with nested states and concurrent states. The UML state diagram, one of the leading contemporary approaches, is heavily influenced by Harel. The UML activity diagram (whose Version 2.0 specification, interestingly, uses Petri net token semantics), though essentially a flow charting technique, is in some respects a special case of the UML state diagram approach. Figure 3-13 depicts these historical milestones.

Figure 3-13: State machine family tree

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The main points of this chapter include:

Theory matters in BPM more than it does in most practical software fields. Theoreticians and practitioners tend to ignore each other's work, but in BPM, practitioners are keenly interested in—and indeed, actively hype—academic conceptions such as the pi-calculus, the Petri net, and, to a lesser extent, the state machine.
The pi-calculus, developed by Scottish mathematician Robin Milner in the 1990s, is an algebraic system for building processes that communicate with each other on channels. Each process has a control flow that supports sequential, conditional, or concurrent control flow.
Pi-calculus processes are written as sets of equations using a particular syntax. The examples developed in this chapter capture the most common elements.
According to pi-calculus convention, when one process sends information to another, it includes the name of the channel to be used for the other process to respond. This name is variable; it can change in response to changing conditions. Channel change is referred to as mobility.
The pi-calculus is thought to be an underpinning of process languages XLANG, BPML, WSCI, and WS-CDL, though leading BPM commentator van der Aalst thinks the connection is mostly hype.
The classical Petri net was developed by the mathematician Carl Adam Petri in the 1960s. A Petri net is a process; its main constructs are places (stopping points in the process, but NOT states), transitions (events that drive process movement), tokens, and arcs (connecting transition to place or place to transition).
Understanding the flow of control in a Petri net requires tracing the movement of tokens through the net. The rules of the classical net are simple: a transition can fire only if each of its input places (places that link to it) has at least one token; and when a transition fires, a token from each input place is moved to each output place (place that is linked to from the transition).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

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 A. H. M. ter Hofstede, "YAWL: Yet Another Workflow Language,"Information Systems, 30(4):245-275, 2005.
P. Wohed, W. M. P. van der Aalst, M. Dumas, A. H. M. ter Hofstede, and N. Russell, "Pattern-based Analysis of UML Activity Diagrams," BETA Working Paper Series, WP 129, Eindhoven University of Technology, Eindhoven, 2004.
R. Milner, A Calculus of Communicating Systems, Secaucus, NJ, Springer, 1980.
R. Milner, Communicating and Mobile Systems: The Pi-Calculus, Cambridge University Press, Cambridge, 1999.
P. Gardner, "Models of Concurrent Computation" (course notes), http://www.doc.ic.ac.uk/~pg/Concurrency/course.html
>L. Wischik, "Pi Calculus: Automata, State, Actions, and Interactions," http://www.ebpml.org/pi-calculus.htm.
G. T. Leavens,"Overview of the Pi-Calculus," http://www.cs.iastate.edu/~leavens/FoCBS/henderson-node5.html
W. M. P. van der Aalst and K. M. van Hee, Workflow Management: Models, Methods, and Systems, MIT Press, Cambridge, MA, 2004.
W. M. P. van der Aalst and A. H. M. ter Hofstede, "Workflow Patterns: On the Expressive Power of (Petri-net-based) Workflow Language," 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, University of Aarhus, Denmark, August 2002.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

GOOD SOFTWARE USES, AND IN SOME CASES INVENTS, REUSABLE SOLUTIONS TO RECURRING PROBLEMS. Expert developers never begin a new project from scratch, but harvest tried-and-true ideas, selecting and morphing existing code snippets. Junior developers, in a similar position, borrow snippets from the experts, or, if they are unusually precocious, originate their own strategies. In BPM, a design pattern is a formalization of these prosaic snippets, consisting of a publishable specification of a problem-solving strategy or recipe, of sorts, for consumption and reuse by the larger development community.

Though BPM is known for its practicality (offers business benefits to its customers and an easy sell for its vendors), it cannot succeed without good, careful, deliberate design practices. Too many processes are designed too quickly, high on the hype that business requirements can be realized in executable digital form rapidly with drag-and-drop flowchart editors. Such processes are created without a strong foundation of previous experience. This chapter examines the use of design patterns in BPM as such a foundation to aid in the construction of better processes.

Few ideas in software design have been as influential as that of the design pattern. The book Design Patterns: Elements of Reusable Object-Oriented Software (Addison Wesley, 1995) by Gamma, Helm, Johnson, and Vlissides—a group popularly known as the "Gang of Four," or GoF—sits on numerous developers' desks and has permeated the design sense of the entire object-oriented development community.

The GoF's book is a catalog of 23 patterns related to the creation of objects (for example, the Abstract Factory Pattern), the structural relationships of objects (for example, the Façade Pattern), and the behavior of objects (for example, the Chain of Responsibility Pattern ). Each pattern is documented according to a standard template, with sections such as Intent, Motivation, and Known Uses. The specification of a pattern describes the nature of the pattern, why it is important, and how it is implemented.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Few ideas in software design have been as influential as that of the design pattern. The book Design Patterns: Elements of Reusable Object-Oriented Software (Addison Wesley, 1995) by Gamma, Helm, Johnson, and Vlissides—a group popularly known as the "Gang of Four," or GoF—sits on numerous developers' desks and has permeated the design sense of the entire object-oriented development community.

The GoF's book is a catalog of 23 patterns related to the creation of objects (for example, the Abstract Factory Pattern), the structural relationships of objects (for example, the Façade Pattern), and the behavior of objects (for example, the Chain of Responsibility Pattern ). Each pattern is documented according to a standard template, with sections such as Intent, Motivation, and Known Uses. The specification of a pattern describes the nature of the pattern, why it is important, and how it is implemented.

The Façade pattern , for example, defines a simplifying interface to a system. Its benefits include reduced complexity and weaker system coupling, and it is useful in the design of client-side interfaces. The implementation of Façade is normally an object (such as a Compiler) whose public interface is simpler than, and hides of the use of, the set of objects (such as Scanner, Parser, or CodeGenerator) belonging to the system behind the scenes.

Prior to the GoF's book, most software developers had at best a vague awareness of the concept of façade, and their ability to design a good client-side interface was a matter of good intuition. Subsequent to the book, design intuition gave way to name-dropping: developers proudly proclaimed that their interfaces were GoF façades! Good object-oriented design ideas had infiltrated the design community.

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

The process community has taken a similar approach by identifying and codifying its own set of common problems. The article "Workflow Patterns" by van der Aalst, ter Hofstede, Kiepuszewski, and Barrios—a group referred to in this chapter as the "Process Four," or P4—lists and describes 20 patterns specific to processes. The P4 catalog is a comprehensive account of patterns for process control flow. The benefit of control flow patterns is to help the process designer determine different ways to assemble activities (for example, how to implement conditional logic based on a deferred choice).

Whereas GoF patterns are documented as object models and code recipes, P4 patterns are inherently spatial and visual: a process pattern is a cluster, or constellation, of process activities arranged in just the right way to solve a difficult problem. The process patterns read like a wish list for a process notational language. Some are obvious (such as support for a sequence of activities); others are exotic (for example, multiple instances of an activity where the number of instances is not known even at runtime).

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As part of their work on patterns, the P4 rated 15 vendor offerings (including Staffware, SAP/R3, MQ Workflow, and Lotus Domino Workflow), determining whether each vendor's product directly supports each pattern, indirectly supports each pattern with sufficient coding, or lacks support for a pattern completely. The results were disheartening: every vendor has spotty pattern coverage, most failing to support (even indirectly) half of the patterns. Even worse, among the vendors there is no conceptual consistency; every product has its own notation and execution semantics.

Motivated by dismal industry support and the absence of a universal theory of workflow, P4 authors van der Aalst and ter Hofstede created a graphical process language called Yet Another Workflow Language, or YAWL, that is rigged to support all 20 P4 patterns. A YAWL process is a Petri net extended with symbols supporting AND, OR, and XOR splits and joins, as well as multiple activity instances. The symbols are shown in Figure 4-30.

Figure 4-31 depicts the YAWL solution to two multiple instance patterns. In this example, some number of witnesses, at least one but no more than 10, are interviewed for the processing of an insurance claim.

In Case (a) in Figure 4-31, the number is not known until runtime; in Case (b), the number is not known even at runtime, and in certain cases, might need to be greater than 10! The notation [1,10,inf,fixed] in process_witness_statements in Case (a) means that between 1 and 10 instances of that activity are required and that the number is fixed at runtime; in Case (b), [1,10,inf,var] means between 1 and 10 instance are required and that this number is variable (var).

Figure 4-30: YAWL symbols

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

As discussed previously, the P4 patterns are oriented towards control flow. Control flow is only one aspect of process design; the designer can also benefit from patterns describing how to communicate with external partners (communication patterns), and how to manage recurring human workflow scenarios (human workflow patterns).

Figure 4-32 illustrates a variety of common communication scenarios in a process.

Figure 4-32: Various communication patterns

The diagram reveals a number of common patterns:

Receive Request: A process triggered by an inbound service request, as indicated by A in the figure. In BPEL, the pattern is implemented with the receive activity. If the caller expects a synchronous response, use the reply activity.
Call Partner Service: A process sends a message to the partner's service. In BPEL, the pattern is implemented in with the invoke activity. Synchronous and asynchronous variants are supported, as in the two steps labeled B in the diagram.
Wait for Response: A process explicitly waits for a specific event or set of events, as in the step labeled C in the diagram. In BPEL, implement using an intermediate receive or pick.
Unsolicited Event

Additional content appearing in this section has been removed.
Purchase this book now or read it online at Safari to get the whole thing!

Content preview·Buy reprint rights for this chapter

Process design , whether practiced by a business analyst or a developer, requires the same high standards of code quality as programming. The following guidelines can help boost quality and maintainability:

For readability and comprehensibility, ensure that a process diagram fits on both a graphical editor screen (with no scrolling or zooming out required) and a letter-sized printed page. If it does not fit, break it into smaller subprocesses. This rule is reminiscent of the style convention in programming to keep source files to fewer than 1,000 lines, with each line restricted to 80 or fewer characters. Many development shops conduct code reviews to check for style compliance; this sense of discipline also belongs in process modeling.
Keep the process flow coarse-grained. Process design is "programming in the large"; the boxes in a process diagram are meant to represent the major steps of the process, not detailed processing instructions (e.g., parsing

Table of Contents