Business Process Management

Introduction

Business Process Management (BPM) is topical but can be a confusing subject since it covers a broad context.

The purpose of this paper is to discuss some of the Use Cases to which BPM is applied, the applicable standards, various architectures, and candidate technologies, to help with a deeper understanding of the subject.

Benefits of BPM

This paper does not focus on the benefits of BPM. At a high level though, a key benefit of BPM is as a tool to help build more adaptable applications that can evolve as business demands change, and to be able to monitor the performance of business processes in real time.

Use Cases

Business Process Management (BPM) appears to be applied to two primary use cases:

· Enterprise Application Integration (EAI)

· Workflow

Workflow, in turn, is often applied at two levels:

· Long running business transaction, often involving more than one system/service;

· Page flow within an application.

EAI is about orchestrating two or more systems/services into a broader process context. (Processes may encompass human input or review, which gets into workflow territory.)

Workflow is about externalising the business processing rules within an application into (typically) a generic state machine representation, so that the rules can be reconfigured over time with minimal disruption to the application. (Workflows may encompass more than one existing application, which gets into EAI territory, or be embedded within an application. The application may be a node in a process orchestration.)

The responsibility for managing workflow typically resides in the Services Tier since this is where transactions are usually managed, interacting with one or more resources including a database.

Page flow is concerned with the logic flow from one screen to the next; as classic example being an on-line purchase “wizard”: review shopping basket, checkout, enter billing details, enter shipping details, enter credit card details, and finally confirm order before processing. The responsibility for managing page flow typically resides in the Presentation Tier.

In each use case, however, there if a ‘flowchart-like’ sequence of activities with if-then-else branches, loops, and exceptions. BPM is in essence defining and managing this flow in such as way that it is not deeply embedded in code and cannot be easily changed. BPM and a Rules Engine often go hand-in-hand since rules govern routing decision within the process flow. (A Rules Engine can also manage other types of business rules and therefore is useful apart from BPM.)

The choice of appropriate standard and tools depend on which use case is primary.

The confusion arises from the fact that the use cases, and associated standards such as BPEL and XPDL, are complementary, and partially overlapping. For a given situation, one or other standard and associated tools may be more appropriate, or both may coexist within an implementation.

Architectural Models

Modern applications have a generic conceptual structure, divided into tiers.

A “workflow” tool can be useful within the following contexts:

The protocols used to invoke process components vary depending on context.

Web Services has become a de facto standard for invoking services in an enterprise process context due to their interoperability and tool support. Web Services encompass standards for message exchange (SOAP), contract (WSDL), and binding (HTTP/S).

The temptation is to use Web Services for all service invocations, even within an application workflow context. Web Services are remote calls in nature, and involve marshalling data into XML; both of which add performance overhead.

Indeed, even within an enterprise process context, within an homogenous network environment, the benefits of using Web Services: standards based, common infrastructure; must be weighed against simplicity, performance, and guaranteed delivery of alternative messaging mechanisms, which are proprietary in nature.

For business-to-business (B2B) integration, Web Services usually makes perfect sense since an organisation usually has little control over the IT environment of a customer/partner organisation.

Page flows operate at the Application Programming Interface (API) level and are specific to the presentation technology and framework used, such as Java Server Faces vs. Struts.

The standardisation efforts have been focused on the enterprise process and application workflow contexts. It is within these two contexts that context boundaries can become confused: a primary application invoking external application services as part of its workflow, versus an enterprise hub which controls the process.

An architectural model sometimes raised in the context of BPM is where the “workflow is the application.”

Web Forms submit an XML message directly to the process engine to be processed. (The form controller code may be within the form as in AJAX (Asynchronous Javascript And XML) or handled by a Forms Presentation Server.)

This architectural model may work for simple human inputs. Larger applications have more complex screen navigation (page flow) and transaction management requirements that are best handled within the more typical application structures on the previous page.

Not every application problem is addressed by a workflow solution. However, workflow solutions, pragmatically applied, can create more adaptable applications.

Standards

The two main standards discussed below are BPEL and XPDL. The two standards are not necessarily competing but apply to different contexts.

BPEL

Business Process Execution Language (or BPEL, pronounced 'bipple', or 'bee-pell'), is a business process modelling language that is executable. It is serialized in XML as an orchestration language over a component set of web services.

BPEL provides a standard for orchestrating nodes in an EAI scenario, assuming that every node has a Web Service interface. Traditional EAI products made no such assumption and provided various adaptors for messaging, database, and packaged nodes. The downside was that the process language was tool-specific.

The problem with BPEL 1.1 within the BPM environment is that, as a standard, it was written with the orchestration of web services in mind. This means that there are some major limitations in the specification when it comes to handling human intensive interactions with the process (workflow tasks and sub-processes to name two). What this means is that the vendors who are relying only upon BPEL as a standard for their BPM tools are coding extensive (and proprietary) modifications to the standard to simply make their processes work. If those extensions are going to be supported in the future (and their potential impact upon interoperability and reusability) should be questions for all companies looking to go down that path. Their extensions certainly mean that you lock yourself in with them as a vendor.

As a language for Service Orchestration BPEL is good and thus is well suited for use within an Enterprise Service Bus (enterprise process context).

XPDL

XPDL is another standard developed by the Workflow Management Coalition (WfMC – http://www.wfmc.org/), which has been designed to support human intensive interactions, sub-processes, task management and all of the other things that the BPEL only vendors have to write extensions for. It was specifically designed to interchange Business Process definitions between different workflow products like modelling tools and workflow engines.

XPDL defines a XML schema for specifying the declarative part of workflow.

XPDL is designed to exchange the process design, both the graphics and the semantics of a workflow business process.

BPEL vs. XPDL (Executional processes versus a Workflow Management System (WFMS))

*** taken from Tom Baeyens (http://www.jboss.com/products/jbpm/stateofworkflow)

A recent trend in the BPM community is the convergence of specifications about executional business processes. The approach promoted by XLANG, WSFL and BPML converged into BPEL. BPEL is based on interactions (message exchanges). BPEL is defined in the context of a service-oriented architecture. One of the prerequisites is that the services to be addressed are described in a WSDL declaration. BPEL then specifies an XML grammar that can be seen as a programming language to combine control flow with calls to the services defined in WSDL.

I see three main differences between the approach taken in executional business processes and state based workflow management systems:

· State based versus message oriented: state based WFMSs are centred on the notion of state (or activity). The workflow engine maintains the state and calculates the transitions from one state to the next. On the other hand, executional business processes as BPEL are centred on the definition of reactions upon incoming message. A set of those reactions, along with some other bells and whistles, can be seen as a business process. That explains why BPEL is somewhat complementary to state based WFMSs. A BPEL onMessage event handler, which is a reaction upon an incoming message, could be executed e.g. on transitions between states.

· Process instance id versus message correlation: One of the complexities that are introduced with executional business processes is message correlation. Part of the process description must specify how the BPEL engine can detect the process instance identification from the incoming message. It has to be based on a data item in the message. On the other hand, state based WFMSs generate ids for each process instance that is created. The client can use this id in subsequent calls to the engine API.

· Central workflow engine API versus an abstract service endpoint: state based WFMSs have a central API, meaning that the client talks to one central API to manage executions of all process instances. In executional business processes, each process is exposed as a service. This means a different access point for every process definition.

Workflow is a subject from which you get easily distracted. The distraction occurs when workflow related concepts get mixed up with complementary technologies or concepts. To give a very concrete example: workflow is completely complementary to web-services. You could expose the interface to access a WFMS as a web-service, but it’s definitely a bad idea to presume that a WFMS *always* has to be accessed through a web-service interface. Some specifications make this presumption. Apart from web-services, other often occurring distractions include email, inter-business communication, web-applications & organisational structure.

The first standardisation effort in workflow was the Workflow Management Coalition (WfMC). The WfMC started in 1993. A very interesting publication of the WfMC is the reference model. It defines the interfaces between a workflow management system and other actors. Another piece of work is the XPDL specification. XPDL defines an XML schema for specifying the declarative part of a workflow. In my opinion, the reference model and XPDL are the best specifications.

BPEL is orientated around service orchestration, and expects every service to be exposed as a Web Service. Forms are supported; basically as XML inputs to a Web Service. These are more easily supported as trigger points to a process, but since there is no overarching state machine, defining conditional input, timed events, task allocation, etc. is not possible or must be embedded within a service (which begs the question of how to define these embedded interactions in a reconfigurable way).

XPDL is orientated around human workflow and includes features such as role-based task assignments, which BPEL 1.1 does not support. Service end points do not need to be a Web Service. XPDL or similar WFMS specification has a convenient mechanism for creating forms for tasks.

Process Context	Primary Standard
Enterprise Process (Enterprise Service Bus)	BPEL
Workflow	XPDL or similar WFMS language
Page flow	Currently proprietary format

Target Use Case	Primary Standard
Enterprise Application Integration (EAI)	BPEL
B2B Process Integration	BPEL
Service Orchestration	BPEL
Management of people-related tasks	XPDL or similar WFMS language

The standards are seen as complementary:

· XPDL as a standard used to represent the process within a visual design tool – a design-time language;

· BPEL as an output of the design tool – a run-time execution language.

Since there is no notation in BPEL to describe timers, roles, etc.

This view is consistent with the following explanation taken from http://www.wfmc.org/standards/xpdl.htm.

BPEL and XPDL are entirely different yet complimentary standards. BPEL is an "execution language" designed to provide a definition of web services orchestration, specifically the underlying sequence of interactions, the flow of data from point-to-point. For this reason, it is best suited for straight-through processing or data-flows vis-à-vis application integration.

The goal of XPDL is to store and exchange the process diagram, to allow one tool to model a process diagram, and another to read the diagram and edit, another to "run" the process model on an XPDL-compliant BPM engine, and so on. For this reason, XPDL is described not an executable programming language like BPEL, but specifically a process design format that literally represents the "drawing" of the process definition. To wit, it has ‘XY' or vector coordinates, including lines and points that define process flows. This allows an XPDL to store a one-to-one representation of a BPM process diagram. For this reason, XPDL is effectively the file format or "serialization" of BPM, as well as any non-BPM design method or process model which use in their underlying definition the XPDL meta-model (there are presently about 50 tools which use XPDL for storing process models.)

Business Process Modelling Language (BPML)

BPML is the workflow modelling language adopted by Microsoft, and .NET based products such as K2. It is superseded XLANG – an earlier workflow modelling language pioneered by Microsoft. It is from another standards body – “Business Process Management Initiative”, which is part of the Object Management Group (OMG).

BPML is a superset of BPEL; adding syntax for the workflow context.

BPML vs. XPDL

BPML focuses on issues important in defining web services. This is reflected in several ways:

· Activity types specifically for message interchange, event handling, compensation (in case of failure), and delay.

· Attributes to support instance correlation, extraction of parts of messages, locating service instances.

· Support for transactions, utilizing the block structure context, exception handling and compensation.

XPDL focuses on issues relevant to the distribution of work.

· Activity attribute specifies the resource(s) required to perform an activity. This is an expression, evaluated at execution time, which determines the resource required.

· Activity attribute specifies the application(s) required to implement an activity.

· These concepts together support the notion of a resource (e.g. participant), in conjunction with an application, performing the activity. The implementation of work list handlers to achieve this lies outside the domain of the process definitions.

Other Process Languages

Workflow specifications have been in a state of development. Some tools have implemented their own language in order to provide a pragmatic feature set. For example, JBoss BPM uses jPDL. jPDL is a process language with a clean interface to Java and very sophisticated task management capabilities. JBoss apparently has plans to support XPDL.

Approach

Regardless of the specific standard or implementation deemed appropriate, process definition starts with a description of the business process. An Activity Diagram, perhaps supplemented with a State Diagram, is a useful means of expressing the business process.

It is useful to have a conceptual understanding of the process before layering on the existing systems that participate in the physical view of that process.

The nature of the key business processes in terms of human involvement, existing systems, and events will provide input to tool selection. Other IT input then includes features, support, vendor “lock in”, price, etc.

Technologies

*** These are my high-level observations; not a detailed assessment.

All major vendors now have (mostly through acquisition) a Business Process Management (BPM) Product. BPM is typically at the high-end of their product range. The more progressive vendors are working out how BPM fits into a broader Service Orientated Architecture (SOA) suite. Alas, SOA marketing hype is creating more confusion than clarity.

Technology	Perceived Pros	Perceived Cons
JBoss BPM	Good integration to the presentation layer through JBoss Seam Framework and Java Server Faces (JSF). Good business rules integration. No upfront license costs.	More appropriate to the Workflow Use Case than the EAI Use Case. Uses its own workflow definition language jPDL.
Oracle BPEL	Oracle as the Number 3 Commercial Application Server Vendor, behind IBM WebSphere and BEA WebLogic, has been working hard to add support for the latest standards as a competitive tactic. There is a perception that the Oracle development environment is productive and that Oracle has learned from past mistakes in keeping its latest tools standards compliant.	The ability to build Workflow style applications needs more investigation. Oracle has in the past gone its own way leading to some dead-end technologies. Price.
TIBCO	Acquisition of the Staffware product provides a good Workflow product. BusinessWorks product has BPEL support and targeted more at EAI. Application Server agnostic.	Price.
BEA AquaLogic BPM	Sophisticated Business Modelling Tool (acquired from Feugo) targeted at business analysts and including simulation capabilities. Supports both BPEL (to import) and XPDL (preferred “from scratch” language).	Price.
IBM WebSphere BPM Suite	Comprehensive suite. A similar sophisticated modelling tool as BEA.	IBM can lag in support of the latest standards. A combination of products, which can make installation a pain. Price.
K2.NET	Suitable for Microsoft.NET environment. New version leverages Microsoft Windows Workflow Foundation. Business-friendly visual designer. Good reporting.	Not necessarily a con depending on the customer’s environment, but K2 is necessarily restricted to a Windows Server environment. Less suitable for EAI Use Cases; lacking integration patterns such as “Publish-Subscribe”.
Active Endpoints (Active BPEL Open Source Engine)	Open source – low upfront licence costs.
Spring Webflow (A Page Flow technology)	Works with various web application frameworks. Naturally integrated with the rest of the Spring Framework.
JBoss Seam (A Page Flow technology)	Great integration with JSF. Integrates with JBoss BPM and JBoss Rules to enable a consistent technology and representation for both page flow and workflow concerns.	Limited to Java Server Faces (JSF).
Others: Sun, Intalio, etc.