Section 1.3. The Morass of BPM

1.3. The Morass of BPM

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

• Processes, like object-oriented applications, have recurring design patterns. A good BPM application exhibits, or explicitly uses, industry standard patterns. Chapter 4 describes the 20 standard process patterns conceived by the Process Four group.

The following sections survey the leading standards and vendors of BPM, as well as the dominant contributions to process theory.

1.3.1. Standards

BPM does not lack standards or standards bodies. Some of the most important of these include the OASIS group 's BPEL standard , BPMI's BPML and BPMN standards, the various W3C choreography standards, the WfMC's reference model, the OMG's MDA specifications, and the OASIS BPSS language. This section introduces these players and standards.

First, the OASIS group's Business Process Execution Language for Web Services (BPEL4WS), sometimes shortened to BPEL (rhymes with "people"), is the BPM specification with the strongest backing (IBM, Microsoft, Oracle, BEA) and the greatest chance to win the standards war. A BPEL process is a web service with an associated process definition defined in an XML-based language. The behavior of a BPEL process is to act on, and be acted on by, other processes; put differently, a BPEL process can invoke another web service or be invoked as a web service. As illustrated in Figure 1-5, a travel agent process exposes a web service method called sendItinerary, which, when invoked, calls the requestTickets method in the airline's web service, as its process flow specifies. The airline service, another BPEL process, is programmed to respond to a ticket request by invoking the sendTickets method of the calling process. BPEL for Java (BPELJ) is a BPEL extension that supports Java code embedded in a process definition. Chapter 5 contains a detailed discussion of BPEL.

Figure 1-5. BPEL travel interactions

BPEL descends from two very different process languages: Microsoft's XLANG and IBM's Web Services Flow Language (WSFL). These languages, as well as BPEL's curious mixed-breed nature, are explored in Chapter 9.

The second standard is the Business Process Modeling Language (BPML), from the Business Process Modeling Initiative (BPMI) organization, which is an XML-based process definition language similar to BPEL. Business Process Modeling Notation (BPMN), another specification from BPMI, is a sophisticated graphical notation language for processes. Significantly, the BPMN specification includes a mapping to BPML-rival BPEL, which facilitates the execution of BPMN-designed processes on BPEL enginesa potent combination that will be explored in detail throughout this book. BPML, BPMN, and the BPEL mapping are explored in Chapter 6.

The third standard, the web services choreography , is a major topic of investigation for the World Wide Web Consortium (W3C). Choreography describes, from a global point of view, how web services are arranged in a control view spanning multiple participants. Choreography's global view is contrasted with the local view of process orchestration in languages such as BPEL; a BPEL process is the process of a single participant, and a choreography is the interaction model for a group of participants. Web Services Choreography Description Language (WS-CDL) is the W3C's recommended choreography standard; Chapter 8 covers the WS-CDL specification, as well as two previous approaches to choreography: Web Services Choreography Interface (WSCI) and Web Services Conversation Language (WSCL).

Fourth, the Workflow Management Coalition (WfMC) has published a BPM reference model, as well as a set of interfaces for various parts of the BPM architecture. In the reference model,^[*] shown in Figure 1-6, a central enactment service executes processes designed in a process design tool. Though WfMC does not specify a standard graphical process notation, it does provide an exportable XML format called XML Process Definition Language (XPDL); processes built in an XPDL-compliant design tool can run on a WfMC enactment engine. The workflow API (WAPI) interface, specified by the WfMC in C code and CORBA IDL, serves three purposes: administration and monitoring of running processes; integration with external applications; and client interaction, including human activity processing. The workflow XML (WfXML) interface enables enactment services to communicate in order to split processes across one another. The WfMC model and interfaces are explored in detail in Chapter 7.

^[*] D. Hollingsworth, "Workflow Management Coalition: The Workflow Reference Model ," January 1995,http://www.wfmc.org.

Figure 1-6. WfMC reference model

The goal of the fifth standard, a contribution of the Object Management Group (OMG) is not to build new process languages or interfaces but to build abstract BPM models conforming to its Model-Driven Architecture (MDA). The OMG's requests for proposals for Business Process Definition Meta Model (BPDM) and Business Process Runtime Interface (BPRI) specifications are discussed in Chapter 9.

The final standard in this list is a process language from OASIS called Business Process Specification System (BPSS), which is somewhat of a choreography language, but is built for business-to-business collaborations. In a typical exchange between a buyer and seller, for example, the buyer sends a request to the seller, to which the seller responds immediately with consecutive acknowledgements of receipt and acceptance. When the seller has finished processing the request, it sends an indication of this to the buyer, and the buyer in turn sends an acknowledgement of the indication to the seller. BPSS (discussed in Chapter 9) is designed to model this and similar collaborations precisely and succinctly.

To the casual reader, BPEL is the only standard worth considering; the others are either dead or stillborn. But this view is simplistic; each components has a role to play. For example:

• The OMG's model-driven architecture, when applied to BPM, is to BPEL what UML-based design and architecture is to Java programming. MDA will help architects conceive good BPM solutions abstractly, without having to consider the particular control structures of BPEL.

• WS-CDL, as the leading choreography language, solves a slightly different problem than BPEL. WS-CDL, in fact, complements BPEL; BPEL helps build the local view of a single participant, and WS-CDL defines the overall interparticipant exchange. BPSS can be positioned much the same way against BPEL.

• BPMN provides a graphical notation language from which BPEL code can be derived or generated. Today, many BPEL-enabled systems use proprietary design notations. BPMN can help standardize that piece.

Not long ago, WfMC and BPML were considered the leading BPM approaches. Why did they fall so quickly? What are their merits that can help us moving forward?

1.3.2. Vendors

Leading BPM vendors include the major application server vendors (IBM with WebSphere Business Integration, BEA with WebLogic Integration, Microsoft with BizTalk Server 2004, and Oracle with Oracle Business Integration ) and several BPM specialists (including Fuego, SeeBeyond with ICAN, webMethods, FileNet, Staffware, Vitria). A full-featured BPM solution includes a process design tool, a runtime engine, administration and monitoring, and support for current integration technologies (for example, XML, web services, J2EE or .NET, and B2B).

Figure 1-7 illustrates how these components are related in BEA's WebLogic solution. The BPM engine (shaded) runs on a web services container and a J2EE application server platform; the portal layer supports BPM and non-BPM user interfaces alike. BEA's design tool, WebLogic Workshop, is used to create processes, as well as portals, web services, Enterprise JavaBeans? (EJBs), and adapters written to the Java Connector Architecture (JCA, also known as J2C) specification. The solution also includes a set of administrative consoles to manage and monitor system activity.

Figure 1-8 shows the design view of a process in WebLogic Workshop; the rightmost menu showcases the rich set of technologies that can be integrated with a process, including EJB, file, email, HTTP, database, MQ/Series, and "application view," which represents an adapter to potentially any application, including ERP (e.g., SAP, PeopleSoft) and CRM (e.g., Siebel, Clarify).

Figure 1-7. BEA's Weblogic stack

Figure 1-8. BEA's WebLogic Workshop process design editor

Some vendors , such as ITpearls and IDS Scheer , focus on the design editor piece. IDS Scheer's ARIS is a standalone editor whose processes can run on BEA's WebLogic Integration . ITpearls provides a Microsoft Visio BPMN stencil, as shown in Figure 1-9.

1.3.3. BPM Theory

The ideas behind BPM were not concocted by hurried developers pressured by considerations of time to market. On the contrary, process modeling is a hot topic in the community of computer scientists, and current BPM standards and products are founded onor at least claim to be founded onacademic findings. In particular, the design of interprocess communication and choreography borrows heavily from Robin Milner's Communicating and Mobile Systems: the Pi-Calculus (Cambridge University Press 1999), and the process control flow semantics are modeled on the Petri net, a beautiful abstraction

Figure 1-9. ITpearls' stencils for Microsoft Visio

fashioned by Carl Adam Petri. These theoreticians from the ivory tower are arguably the guiding lights of BPM.

Reading Milner and Petri, however, presupposes an appetite for mathematical rigor that most BPM onlookers lack. Fortunately, understanding BPM today for use in the design of actual applications does not require knowing the science of BPM; it is sufficient to understand the open specificationssuch as BPEL and BPMNthat are derived from the science. Milner and Petri are required reading for those who want to understand BPM and its future deeply. Chapter 3 is a casual tour of process theory for the average reader.

Why a chapter on theory in an essentials book intended for practitioners? BPM is an emerging discipline with too many standard and vendor-specific approaches to process modeling. Looking at one process editor after another, each with a distinct set of symbols and associated semantics similar to the others but subtly different, makes one yearn for rigor and precision. Many vendors pitch their solution as being "easy" and "simpler than programming," but fail to promote the strength of the underlying process model or language. Theory helps cut through the morass not only by providing a good original model for the flow and interaction of processes, but also by helping to evaluate the quality of other approaches. Petri nets, for example, have been used not only to build new workflow languages but also to model the most complicated control flow semantics of BPEL, BPMN, WSFL, UML activity diagrams, and event-driven process chains. BPM is young and still needs to hear the voice of wisdomtheory.