What Is Business Process Modelingby Michael Havey, author of Essential Business Process Modeling07/20/2005 "The boxes and arrows of outrageous fortune ...." When a business analyst stands at a whiteboard, sketches the flowchart of a business process as a cluster of boxes linked by arrows (apologies to Shakespeare), and asks the software team to make it run, Business Process Modeling (BPM)--sometimes known as Business Process Management--comes to the rescue. BPM is a set of technologies and standards for the design, execution, administration, and monitoring of business processes. A business process is the flow or progression of activities (the "boxes")--each of which represents the work of a person, an internal system, or the process of a partner company--toward some business goal. Over the years, the scope of business processes and BPM has broadened. Less than a decade ago, BPM, known then as "workflow," was a groupware technology that helped manage and drive largely human-based, paper-driven processes within a corporate department. For example, to handle a claim, an insurance claims process, taking as input a scanned image of a paper claims form, would pass the form electronically from the mailbox (or worklist) of one claims specialist to that of another, mimicking the traditional movement of interoffice mail from desk to desk. BPM today is an enterprise integration technology complementing Service-Oriented Architecture (SOA), Enterprise Application Integration (EAI), and Enterprise Service Bus (ESB). The contemporary process orchestrates complex system interactions, and is itself a service capable of communicating and conversing with the processes of other companies according to well-defined technical contracts. A retailer's process to handle a purchase order, for example, is a service that uses XML messages to converse with the service-based processes of consumers and warehouses.
The Ideal BPM ArchitectureMy forthcoming book, Essential Business Process Modeling, explores the concepts, design, and standard specifications of BPM. BPM today is somewhat of a morass, my book argues, with far too many misunderstood, misapplied, and excessively hyped vendors and standards. In its survey of the landscape of BPM, my book emphasizes standards over vendors, because standards are a better source of concepts, and bring greater clarity to the subject. Granted, BPM's standards are ostensibly a murky alphabet soup (see Table 1), but when the best of them are combined properly, they form a surprisingly intelligible architecture, shown in Figure 1. Table 1. BPM standards
At the heart of the architecture is a runtime engine that executes processes whose source code is written in the XML-based BPEL language, the most famous and widely adopted BPM standard, and the best of the BPM execution languages. These processes are designed, by business and technical analysts, using a graphical editor that supports the visual flowchart language BPMN, the best of BPM's graphical languages. The editor includes an exporter that generates BPEL code (which is then deployed to the engine) from BPMN diagrams. (The BPMN-to-BPEL development cycle is analogous to that of UML-to-Java in many current Java development tools.) Human and computer interactions drive the execution of processes in the engine. Human participants view and execute pending manual work activities (in processes running on the engine) using a graphical worklist application. Internal IT systems, which reside on the company's network but are outside of the engine's address space, are accessed by integration technologies such as web services, J2EE, or COM, with XML as the probable message format; internal interactions can also be more lightweight inline code snippets, written in programming languages such as Java or C#. External interactions are typically web-service-based communications, governed by choreographies, such as those composed in the emerging XML language WS-CDL, the leading choreography language. Though a choreography describes the global, publicly observable view of a multi-participant process exchange (typically in business-to-business e-commerce), a choreography toolkit can be used to "generate" a basic BPMN model that captures the communications required by the process of a particular participant; the tool can also validate that a given process satisfies the choreography's contract. (WS-CDL literature suggests generating BPEL, rather than BPMN, from WS-CDL. But in this architecture, BPMN, as a design language, is a necessary layer of indirection.) BPM system administrators use a graphical administration and monitoring console to maintain and track the state of the engine's processes. The console uses a management language to interface with the engine. The runtime engine persists process state to a database; the console hits the database directly, rather than using the management language, to perform ad hoc process queries. The monitoring infrastructure can also support Business Activity Monitoring (BAM), or dashboard-style business monitoring. The development cycle on this platform is the following:
The overall shape of this architecture (inspired by the reference model of the WfMC, the most mature of the numerous BPM standards groups) resembles that of platforms offered by integration vendors such as IBM, BEA, Oracle, Tibco, SeeBeyond, and Vitria. What distinguishes this architecture is its choice of standards. BPEL, BPMN, and WS-CDL are included because they are the best approaches to execution, design, and choreography, respectively: three crucially important parts of BPM. (As Figure 2 shows, future possibilities include emerging standards BPQL (for monitoring), BPSM and BPDM (for metamodeling), BPRI (for a runtime interface), and BPXL (for BPEL extensions).) Indeed, many vendors support, or are currently building support for, BPEL. But BPMN support is rare (most vendors offer a proprietary equivalent), and WS-CDL support almost non-existent. BPEL is not enough! The architecture is ideal, waiting for actual implementations.
Make This Retailer Process RunThe architecture might be not have any current implementations, but, using the example of a retailer's handling of a purchase order, let's approximate its prescribed development cycle and build an actual process. We begin with choreography. A retailer process does not operate in isolation, but rather collaborates with consumer processes to receive orders and warehouse processes to have orders filled. The choreography can be described in plain English as follows:
The benefit of WS-CDL is that it can encode these steps formally in an XML language. The first two steps in the English description above are represented in WS-CDL by the code in Example 1. Example 1. WS-CDL consumer-retailer interaction This code describes an interaction with two exchanges: in the first exchange (lines 5-8) the consumer sends ( The first step in building the retailer process is to generate a BPMN diagram that satisfies the retailer's required role in the choreography. Today this step is necessarily manual; there is no current WS-CDL tool that can generate BPMN (www. presents a good source of information about the one or two current experimental WS-CDL implementations). The manual approach is to look at the choreography and draw a process that fits the role; Figure 3 shows the BPMN diagram representing the retailer as a participant in the choreography.
The logic of the process is straightforward. The process starts when it receives a purchase order (PO) message from the consumer ("PO From Consumer"). It then successively sends an acknowledgement of receipt to the consumer ("Send Receipt Ack to Consumer") and forwards the PO to the warehouse ("Send PO to Warehouse"), before waiting until it receives a response from the warehouse ("Wait Warehouse Response"). When the response arrives, the retailer process forwards it to the consumer ("Send Warehouse Response to Consumer"), and the process completes. The notation is clear and intuitive: the boxes perform "activities," the circles with enclosed letter symbols wait for "events," the empty circle marks the endpoint of the process. Figure 4 shows the process with the addition of private steps (i.e., steps not required by the choreography but driven by internal requirements). These steps are italicized: "Write PO to DB" persists the purchase order to an internal retailer database when it arrives from the consumer; "Update PO Status in DB" updates the database record with the status of the warehouse response (i.e., accept or reject); "Sales Followup" is a manual task, assigned to a sales representative to help the consumer resubmit the order in case it was rejected by the warehouse. (The diamonds in the figure are called XOR gateways. When combined, they form a conditional code structure that works like an
These diagrams were drawn with ITpearls' Process Modeler, which is a set of BPMN stencils for Microsoft Visio. Process Modeler is not a full-fledged process development tool, but merely a drawing application. It cannot, for example, generate BPEL code; this step, too, is manual. Regardless, the diagrams are valuable for design documentation; just as a UML drawing tool that cannot generate actual Java or C# code can still help software architects document the objects and components of an application, so Process Modeler helps business analysts or architects render process flows in a standard process representation. As it turns out, the mapping to BPEL is straightforward: the "events" of the BPMN process (e.g., "Wait Warehouse Response") are BPEL "receive" activities (or activities that wait for events to occur); the "activities" (e.g., "Send PO to Warehouse") are BPEL "invoke" activities (or activities that call services); the conditional structure enclosing "Sales Followup" is a BPEL "switch" activity; and the entire flow is a "sequence" activity. The BPEL code, each of whose eight steps derived from BPMN is indicated by a comment (e.g., line 12 indicates step 1), is provided in Example 2. Example 2. Retailer BPEL code In the BPEL code, "partner links" (marked by the
All three types of process interactions are represented: Unlike BPMN and WS-CDL, BPEL has an abundance of good tools, such as Oracle's BPEL Process Manager, which is put to use in the development of two substantial BPEL examples in Essential Business Process Modeling. Oracle's platform can be used to test the retailer process. ConclusionThe realization of those sketchy flowcharts drawn by business analysts on whiteboards requires an architecture built on the best of BPM's many standards: BPEL, BPMN, and WS-CDL. Alas, no actual vendor implementation of this architecture exists today, but, as our retailer process example shows, a useful approximation can be fashioned. Michael Havey is an architect of several major BPM applications and author of magazine articles on BPM and process-oriented applications.
|
|
|
