The use of the term BPM (business process management) is becoming increasingly confused as former EAI vendors claim BPM capability and the lines between BPM + SOA and ESB applications are blurred. This article will differentiate what is unique and distinct about BPM compared to other technologies such as EAI (enterprise application integration) and ESB (enterprise service bus), and it will also attempt to characterize what exactly constitutes a Business Process as opposed to an Application Integration, Web Service Orchestration, or Data Translation problem. All the while we will be remembering and focusing on the fact that the "B" in BPM stands for Business.

Enterprise Application vendors who are keen to preserve the revenue-generating capabilities of their offerings and who are also keen to grow market share have historically recategorized themselves with emerging market segments and their associated three letter acronyms. For example, consider sales force automation (SFA) and contact management applications that overnight morphed into customer relationship management (CRM) applications, and application server vendors that became ESB platforms. It's not surprising then, given the dramatic growth being experienced and predicted for BPM applications (some at the expense of other market segments such as EAI) that we yet again see vendors of similar, but different technologies such as EAI and Workflow claim that these are BPM offerings. The unfortunate effect is buyer confusion as to just what a BPM tool is and what a BPM tool is not. To help buyers understand the distinction, let's start by clarifying the fact that true BPM technologies may have EAI and Workflow roots, though they were built from the "ground up" to close the gap in EAI and Workflow deficiencies. Since BPM technology is a relatively new software space, even the most mature BPM companies have only been around for eight years or fewer. These new players and independent thought leaders in the space can only hope to continue to try to educate the user community about the true characteristics of an application that will deliver the promise upon which the technology was predicated.

Let's examine what caused the BPM application category to emerge and how it is radically different from preceding technologies, even though vendors of those technologies claim to now be BPM applications. To understand where BPM came from you need to recognize that existing technologies were not filling a missing need in the growing digital workplace. The two major technologies to consider in this category are EAI and Workflow. EAI was borne from the fact that businesses were investing considerable sums in CRM, ERP, B2B, eCommerce, and other applications that addressed the needs of a narrow user community inside their enterprise, but each application was tied to its own data repository. To synchronize the data between these applications and external partner companies, EAI, with its catalog of application-specific adapters, emerged and filled the need. Given the emergence of Web services as a standard mechanism for interacting with applications, EAI applications have shed their dependence on adapters and have morphed into a new breed of application with a new acronym and an equally technical sounding name, so now we have ESB applications. I'm opening myself to endless debate I'm sure, but I would categorize applications from Microsoft (BizTalk), Tibco, and Vitria squarely in this category. Workflow, on the other hand, was focused not on system-to-system interaction, but rather on human-to-human interactions and the sequencing of work from one person to another. However Workflow didn't really attempt to automate any step of the process; its objective was quite simply to ensure that the right person was tasked with an activity at the right time in a well-defined sequence. When you consider what the focus was of each application category it is clear to see that EAI was focused on systems and data, and Workflow was focused solely on the human worker.

So what is the philosophy behind business process management? Well, first of all let's agree that BPM applications exist to support business performance. BPM focuses on process and rules as being the central and controlling entities. The human workers, data, and systems are supplemental entities that the process interacts with and orchestrates to accomplish the goals of the process. Second, business processes are inherently human-worker dominated. A recent Gartner survey revealed that 85 percent of BPM implementations were around human worker-centric processes. The systems and applications that the human workers interact with are merely vehicles by which the human workers get access to the data they need to perform their functions in an efficient manner. Let me just repeat this last sentence again in a different way so that this crucial point gets fully communicated. The systems and applications that your workers use are tools that merely provide data and enforce rules in a format that is relevant to their job functions. A BPM tool should not seek to supplant those systems and applications, it should instead empower the workers to continue to perform their tasks in the applications that are most relevant to their job functions. However it should eliminate nonproductive activities such as manual re-keying of data into those applications. So in this respect the third key characteristic of a BPM application sometimes causes it to be confused with EAI applications (or more likely cause EAI applications to be characterized as BPM). BPM applications should be able to move data between diverse systems, and not just enterprise applications like CRM and ERP, but also classic human worker productivity tools such as spreadsheet, word processing and collaboration applications.

I think the best way to differentiate BPM from EAI and Workflow is to examine an example of a process that could not be handled by EAI or Workflow alone, that exhibits all of the characteristics described above, and that has been successfully implemented using a pure-play BPM application.

Figure 1 is a conceptual diagram of the enterprise customer acquisition process that might be found in any company that sells configurable products or services at negotiable prices and under custom contract terms. This particular process starts at step 1 with a sales executive or sales engineer entering the characteristics of the opportunity such as customer details, product configuration, quoted pricing, and contract terms into a CRM application (the relevant and preexisting application for that user community). This starts the process inside of the BPM application that takes over the management of the process, tasking of workers, application of rules, and migration of data from system to system. In this example the engineering department (step 2) is tasked with the next set of activities that are relevant to the process and the data is populated into the relevant pre-existing application. Step 3 sees the process and associated data moving on to the financial analysts who have responsibility for ensuring the profitability of the opportunity. BPM eliminates the re-keying of data at this step by automatically creating and populating Excel spreadsheets that are derived from templates and applies rules based on the results of calculations within those spreadsheets to make a determination as to whether or not the financial analysts even need to review the opportunity for profitability. If the financial analysts need to review or approve the opportunity then the spreadsheets are e-mailed to them for review and approval. By way of the application of rules defined within the BPM application, step 4 ensures that the right levels of management are involved in approving the opportunity, and their interaction is facilitated through e-mail. Finally step 5 involves legal in a collaborative process around the creation and review of custom-contract language via a word processing program and collaboration portal. The end product of this process is the automated creation of contract documents that are populated with all of the data captured in the CRM application and each application used along the way, and because a BPM application manages the entire process, users and management gain real-time visibility into the state of any opportunity moving through it.

Could an EAI application achieve the same result? It is extremely unlikely: at best EAI applications could move the data between applications, but EAI would not task or notify users when they needed to perform some action on that data, nor would it provide the end-to-end visibility into the process and its human worker activities. What about Workflow? Certainly Workflow would be able to sequence the human workers within the process, but its inability to integrate systems and applications into the process would almost certainly mean that users would end up having to use UI elements and forms that are rendered by the Workflow application. Since Workflow applications also merely just sequence the activities but not the movement of data, no real audit trail or guaranteed data integrity will exist.

BPM on the other hand was successful in implementing this enterprise-wide process because it started with and focused on what the process and rules were, not on what the systems were. Most notably, BPM enables people to do their jobs in a way that comes naturally to the employee, rather than forcing them to change behavior and learn a new application. Automation is introduced where appropriate, such as the elimination of nonproductive activities like the rekeying of data, all the while allowing the human workers to interact with the process using common desktop tools that they already know how to use. Only BPM applications can solve or handle complex, highly manual, enterprise-wide business processes-like customer acquisition, demand planning, forecasting, and IT asset management. Only process management technologies that facilitate human worker interaction within the process using the preexisting and relevant applications those human workers already have is a true BPM application. It is this author's opinion that the best BPM application is one that is transparent to human workers in all respects other than that it should seek to eliminate nonproductive activities.

In summary I will digress slightly by highlighting a legitimate polarization that is occurring between true BPM applications. Of course polarization is occurring based on platform (J2EE vs. .NET), and to a lesser extent, on underlying architectural philosophy (SOA or not). The emerging difference that I want to highlight centers on the notion of who is doing the implementation work. Who designs the process, who defines the rules? Should this be put in the hands of IT professionals or the process owners (business analysts and subject matter experts)? BPM tools were created to optimize business performance and provide an agile infrastructure to keep up with the business as it evolves over time. BPM tools automate where appropriate and effectively interact with the human worker elsewhere. These characteristics represent the makeup of a legitimate BPM offering.