Essential Business Process Modeling

Chapter One. Introduction to Business Process Modeling

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:

1. Get the customer’s itinerary.

2. 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.

3. If all the bookings succeed, get payment from the customer and send the customer a confirmation. Process completes normally!

4. If at least one booking fails, cancel the successful bookings and report the problem to the customer.

5. 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.

Figure 1-1. Travel reservation process (diagram created with ITpearls’ Process Modeler for Microsoft Visio, v. 1.1)

Being algorithmic, a process can potentially be run by some sort of process engine. As long as the process can be expressed in a form that is syntactically and semantically unambiguous—that is, in a programming language or other interpretable form—the engine can accept it as input, set it in motion, and drive its flow of control. To be precise, the engine creates and runs instances of a given process definition. The steps of the process are called activities or tasks.

The following list summarizes the most important process modeling terms and their relationships to each other:

Process definition

The basic algorithm or behavior of the process.

Process instance

An occurrence of a process for specific input. Each instance of the travel reservation process, for example, is tied to a specific customer’s itinerary.

Activity or task

A step in a process, such as sending a flight request to the airline.

Automated activity or automated task

A step in a process that is performed directly by the execution engine.

Manual activity or manual task

A step in a process that is meant to be performed by a human process participant.

The distinction between manual and automated activities is extremely important. At one time, before the reign of software, a business process was completely manual and paper-driven: paper was passed from person to person, and was often misplaced or delayed along the way. Now, much of the process runs on autopilot.

Even so, some steps—typically managerial approvals or business exception handling—remain manual. In the case of the travel agency, when at least one itinerary booking fails, the process assigns to an agent the task of contacting the customer to adjust the itinerary. Figure 1-2 shows a page in the travel agency’s portal web application that displays a list of itineraries requiring a manual fix because of a failed booking.

Figure 1-2. Travel reservation worklist portal

As the figure indicates, the user Bill Smith, who is an agent and a supervisor at the agency (ACME Travel), is logged into the portal. The options on the left menu include a link to create an itinerary (used when a customer calls in with a new request), as well as links to three manual activity queues : Resolve Error (which has 12 current activities), Escalations (5 activities), and Approvals (1 activity). The main frame on the right side shows a summary list of Resolve Error activities, displaying the ID, priority, submission time, and status of each activity.

A queue is a list of activities of a particular type assigned to a particular user or group of users. The Resolve Error queue is a list of activities, shared by all agents, to fix itineraries; any agent logged into the portal can claim an activity from the queue whose status is “open”; once claimed, the status changes to “in progress”; the activity is removed from the queue once the agent successfully handles it.

When the agent selects a task from the queue (e.g., ID 1421-12), the resultant page (shown in Figure 1-3) displays information about the customer (Paul Chang), the original itinerary (under Itinerary Details), and the reason for the booking failure (Exception), and prompts for itinerary changes (the edits Flight Change, Hotel Change, and Car Change are submitted with the Submit Change link). The page, also enables the agent to perform a manual fix to a problem in a mostly automated process.

Figure 1-3. Travel reservation task page

Automated activities generally fall into two categories:

• Interactions with external systems: e.g., sending a booking request to an airline

• Arbitrary programmatic logic: e.g., calculating the priority of a manual task

The external system interface requires the process runtime engine to have significant enterprise application integration (EAI ) capabilities, such as XML, B2B, web services, MOM, .NET, and J2EE interfaces. Indeed, no contemporary business process lives in isolation: it acts upon, and is triggered by, other applications, whether internal or external to the enterprise.

Arbitrary programming logic requires that the process either support embedded code or provide the ability to call code. The logic of a process is necessarily coarse-grained; the fine-grained programming is best performed in a lower-level language such as Java.