Another difference is that workflow-based BPM suites support the notion of a subprocess, a reusable process fragment that shares context data and state management with the calling parent. BPEL provides no such concept. A subprocess is another BPEL process; data sharing and state synchronization must be explicitly defined in the process logic. To address these real-world limitations, IBM and SAP last summer outlined optional extensions to the BPEL standard, but the specs are not yet complete. In the end, regardless of architecture and coding differences, BPM suites tend to accomplish the same set of core functions.

Rolling out process-driven apps

The completed process design is then deployed to the process engine. As each instance of the process is triggered, the engine routes it through the defined sequence of activities, integrating external applications, routing workflow tasks to human participants, and managing deadlines and exceptions throughout the process. In offerings from app server vendors such as IBM, Microsoft, Oracle, or SAP, the process engine leverages unique capabilities of the app server and its associated middleware. Offerings from BPM pure-plays tend to run on the user's choice of app server platforms.

The process engine also reports snapshots of instance data and state, usually in the form of events, for the purposes of performance management. The performance management component of the BPM suite collects those events and uses them to update KPIs and other performance metrics defined in the modeling phase. Typically, metrics are aggregated in OLAP cubes, which can be charted and queried by users in management dashboards. OLAP-based performance management provides historical and "near-real-time" reporting and drill-down analytics, as updates are performed on demand by re-crunching the collected data set. Some BPM suites, including those offered by Adobe, FileNet, IBM, Intalio, and Savvion, support true BAM, providing real-time update of selected KPIs with rule-triggered alerts and escalation actions.

Metrics computed from running processes can be used to refine the model parameters used to generate expected values of those metrics, making the effect of process changes more predictable and stimulating additional rounds of process improvement.

The BPM choice

Picking the right BPM suite is a real challenge. Although virtually all the vendors promote the same list of capabilities in their brochures and Web sites, each offering is actually tuned to the requirements of a fairly narrow set of process types or use cases.

For example, a BPM suite designed for transactional, "straight-through" processes involving complex application integration but little human interaction might not be the best choice for collaborative, human-centric processes with minimal integration. Document-centric processes and production workflow processes where pools of users draw tasks from shared queues at high speed have their own unique requirements addressed by some, but not all, BPM suites.

Such complications aside, BPM is offering real return on investment to users today. When presented as an architectural stack, it can sound like a tangled mess. But the new generation of integrated BPM suites is untangling BPM and providing a new middle ground for business-IT collaboration.