Process Execution

The process engine that runs on the BPMS vendor's server is responsible for executing the process model exported for execution and activities programmed. A typical run-time environment also needs other low-level services, such as security, transaction and concurrency management. These services are either provided by the same vendor or the vendor relies on another technology, such as applications or servers. If the transactions involve multiple business partners, the challenge of managing those transactions gets more complex.

To control the execution of process activities, there are basically two approaches: orchestration and choreography. The distinction lies in the point of view on "who is the process owner" of an internal corporate process, an external public process (peer-to-peer/B2B) or combinations of both.

The orchestration approach mainly assumes that the process owner is always a single-entity that has total control of all message exchanges between activities. An example is a workflow application for an in-house loan-approval process.

The choreography approach, on the other hand, implies that the process is owned "jointly" by all participants, and the sequence of multiple message exchanges among participants are driven by mutually agreed "contracts." Examples of this include the fulfillment processes of a purchase order in a B2B environment.

Among process execution languages, BPEL more closely resembles the orchestration approach. Another standard, WS-CDL, mostly addresses the needs of the choreography approach. XPDL, on the other hand, is mostly seen in human-centric workflow tools/applications. In the future, expect BPEL to include similar capabilities from XPDL and WS-CDL.

Process Monitoring and Analysis

The ability to report business performance metrics is increasingly important and is a major differentiator among BPM suites. Given the large potential impact on process efficiency, BPM vendors are rushing to include this type of business activity monitoring (BAM) capability in their suite through acquisitions, partnerships or enhancements of existing tools.

Unfortunately, would-be customers are usually confused about how to best use BAM capabilities. Part of the reason for this confusion is that there are two types of BAM: real-time and historical. Yet the distinctions between the two are not clear to most.

Real-time BAM components are tightly integrated within the BPM solution to monitor metrics for work-in-progress (such as the number of process instances started, execution times of activities and so on). Advanced real-time systems can do such things as record an execution pattern signaling process failure so you can avoid them in the future. Real-time BAM also predicts work loads for better resource utilization. Filtering and reacting to business events is also a key feature. For example, based on a certain business condition (such as receiving an electronic order), the following actions can start: send e-mail to a user, automatically start another process instance and send alerts to dashboard/console.

Historical BAM components, in contrast, provide analysis reports to draw conclusions from purely historical execution of already completed processes. Process-specific key performance indicators (KPIs) and service level agreements (SLAs) can then be compared against this data. These tools can also integrate with existing data warehouses and may require a different server platform than the BPM server.

Collecting execution metrics also enables "closed loop" modeling in which process simulations can be adjusted to improve efficiency.