Performance management dashboards graph metrics versus their target values, with drill-down analytics via OLAP queries. They also provide real-time alerts and automated escalation procedures when KPIs (key performance indicators) go off track, a capability of the BAM (business activity monitoring) component often bundled with a BPM suite. Actual performance data can be fed back to refine process models and begin a new cycle of incremental process improvement.
Tally all that functionality, and you end up with quite a stack: software for business modeling, simulation analysis, human workflow, application integration, data mapping, business rules, performance analytics, BAM, and Web portals. All of these originated as independent tools from specialized vendors.
But today, within the BPM world, the trend is toward wrapping all these components inside the BPM suite, whether through mergers and acquisitions, OEM, or integration partnerships. This shift has created conflicts between BPM suite vendors and suppliers of modeling tools, BAM, and integration middleware, each of which tends to describe BPM in its own way.
Perhaps the greatest source of confusion, however, has derived from the two competing technical architectures for BPM. The one that has gotten the most media attention is based on the BPEL (Business Process Execution Language) standard, which implements processes by orchestrating Web services within an SOA environment. This is where the large infrastructure vendors play, including IBM, Microsoft, Oracle, and SAP.
On the other hand, most pure-play BPM suite vendors -- such as Fuego, FileNet, Pegasystems, and Savvion -- use an architecture that evolved from the workflow systems of the 1990s, one better suited to incorporating human tasks in the process model. In these offerings, SOA and BPEL play a more limited role and focus on application integration, rather than describing the end-to-end process.
The bottom line is fairly simple. The big-vendor solutions that emphasize BPEL work best for composing Web services into applications that involve little human workflow -- that is, without multistage handoffs to various users in various roles in an organization. Pure-plays have long emphasized implementation without programming, so their BPM solutions tend to provide the straightest line to a practical BPM deployment. The downside is that, as opposed to their big-vendor competitors, pure-plays' offerings can be more difficult to integrate into an existing application environment.
Whether from a big vendor or a pure-play, modeling tools have one main purpose: to describe business processes in terms of their elemental activities and tasks, the resources required to perform each task, and the business rules interconnecting them -- all using a graphical notation understandable to business users.