• What is BPM?


• Can I see a quick example?


• What does BPM provide that other enterprise applications do not?


• How does BPM fit in with legacy, ERP and other enterprise systems?


• What kinds of processes are typically the best candidates for BPM?


• It seems like everyone is selling BPM—what does the BPM vendor landscape look like?


• How is BPM related to service-oriented architecture (SOA)?


• Are there any standards being developed for BPM?


• What does BPM cost? What are the hidden costs?


• What is involved in implementing BPM?


• How do companies organize their BPM projects? Who should own a BPM initiative, business or IT?


• How do I build a business case for BPM?


• How do I measure and actually get ROI from a BPM project?

How is BPM related to service-oriented architecture (SOA)?

An SOA provides access to other applications. BPM uses SOA to include information from those applications into an improved process. If an SOA provides roads to your information, then BPM is the car that leverages that infrastructure to accomplish something useful.

In a nutshell, service-oriented architecture enables services that support business processes to be recombined for greater business agility. In more technical terms, SOA is an integration and architecture framework that supports loosely coupled services and enables interoperability among new and legacy systems. It allows those systems to expose part of their functionality to other applications in a standard way. (For more, see "ABC: An Introduction to SOA.") For example, an accounts payable system could expose an interface to allow other applications to add a debit item. BPM provides the ability to combine these exposed services from different applications into a new process.

Sometimes BPM initiatives serve as a driver to jump-start an SOA strategy. In a world where business executives are looking for direct value out of their IT investments, SOA by itself can be a hard sell since it can be difficult to explain the value in concrete, understandable terms, and thus makes it difficult to convey its value. One strategy to overcome this is to sell SOA as an enabler of BPM, since BPM is more concrete—it's easy to convey its value in enabling specific (and critical) business processes. By association, SOA does as well.

Still, one of the things to be concerned about is the quality of service that can be supplied by the applications providing the SOA service. This is of special concern when the providers of these services are in other organizations or even other companies. Applications using such interfaces need to be designed to degrade gracefully when those services are unavailable. Management should be sure to develop quality-of-service agreements with their SOA partners. These should include agreements on when and how interfaces are upgraded. The point to be made here is that if you use SOA as an integration strategy for BPM, you'll end up with critical business processes reliant on those services. If those services fail, then your BPM-managed business process will fail. So be sure you know, or can control, the quality level of any services upon which your BPM solution is based.

Are there any standards being developed for BPM?

Yes, proponents of BPM are attempting to follow the success of other technologies and establish a solid foundation of industry standards that will support continued growth and customer acceptance.

Customers are interested in standards because they may make it easier to move their applications to other BPM vendors, find developers, manage interactions with other BPM systems and external partners, and drive down costs. Unfortunately, the broad capabilities represented by a typical BPMS and myriad interest groups have resulted in standards emerging for only sections of the typical process management lifecycle (that is, design, execute, manage).

Today, the most important standards are:

• BPMN (business process modeling notation)—focuses on the graphical modeling of business processes.

• BPEL (business process execution language)—an evolving standard that focuses on process execution and system-to-system communication.

• BPML (business process modeling language)—an XML-based execution language standard based upon Pi-Calculus and Web services.

• BPQL (business process query language)—focuses on the administrative and monitoring aspects.

Most notable is that each of these (and the many others not listed) focuses on one small aspect of what is typically addressed by a BPM product. The challenge will be to integrate these standards into a lifecycle of continual process improvement with BPM.

Are there any developed or developing standards that would allow portability of total BPM applications to different vendors? No, not even close. Standards might allow development of some adjunct products (such as reporting and analysis) to make use of some BPM data in the future, but for now, standards are not really playing a significant role (other than marketing) in BPM products.

The more significant standards at this point are those in areas of importance to BPM, such as SOA, XML documentation standards, and so on.