The death of BPM (it ain’t over until it’s really over)

by kirangarimella on March 26, 2007

At Gartner’s BPM Summit last month in San Diego, everything went fine until the last Gartner analyst left a lasting impression at the last session of the last day. Simon Hayward, VP and Gartner Fellow, who helped kick off the BPM Summit, has the dubious honor of also sounding its death knell. His bombshell?

The prediction that, to paraphrase, “By the year 2012, BPM will be subsumed into major applications.” I forget the exact probability he assigned to this scenario, but it was precisely between 0.7 and 0.8 (both inclusive).

Predictably (i.e., with probably 1.0), there was violent disagreement from the audience. Their cries of “No!” reverberated in the auditorium. There was applause for attendees who spoke in protest.

I am sure there was concern among the participants about the discipline of BPM itself vanishing (and with it, boondoggles to sunny climes), and among the vendors on the implied demise of their own companies.

If Simon’s intention was to end the conference on a vigorous and memorable note of controversy, he definitely succeeded.

Now, I can’t predict the future as accurately as Gartner. I don’t know if BPM functionality will indeed be subsumed under applications from the largest app vendors. What I do know is that if it does happen, it will happen only if one of the following conditions is met:

  • one, a major app vendor will take over all the applications and supply one huge ERP that covers all businesses end-to-end for all the companies (regardless of size) on the entire planet and the space station;
  • two, app vendors will package BPM-like functionality without truly understanding what it means, thereby fooling themselves and all of their customers all the time.

Your guess is as good as mine (or Gartner’s) on the likelihood of these scenarios happening.

Conceptually, though, suggesting that BPM functionality will reside in apps is like saying operating system algorithms will be subsumed by applications (i.e., that OS functionality like system resource management, job scheduling, load management, memory management, etc. will be built into each and every application).

Talk to your app vendor and ask them if they’d be willing to develop OS functionality (as in Unix and Windows) directly into their apps. Also, ask them if they’d be willing to create their own database engine rather than connect to an existing, independent DB engine. How about their own reporting solution?

BPM is to business processes what the OS is to IT programs: BPM is a process operating system. Just as an OS provides a ‘system process space’ context for pieces of running code, BPM provides a ‘business process space’ context for applications.

What are the elements of this business process space context? A comprehensive answer is too long for this post, but it should include process metrics, process design, business semantics, and process governance.

The analogy to the OS should be clear:

  • an OS collects and displays system metrics, such as memory utilization, resource handles, CPU utilization etc.;
  • for the design of applications, it provides an API to applications for accessing system level resources; it defines the system semantics through such APIs and through the use of semaphores, threads, handles, sockets, pipes, devices, etc.;
  • it ‘responsibly’ manages the use of system resources to eliminate contention, resolve deadlock, terminate hanging processes, implement prioritized scheduling, etc.)

Imagine an app vendor having to build this entire infrastructure (whether OS or BPM) into each application!

BPM provides the abstraction layer that is common to all applications that must function as responsible citizens in the corporate world, just as an OS provides an abstraction layer to all applications that must reside and play nicely together on a computer.

People attend BPM conferences because they see problems that are not (and cannot) be solved by their current stack of applications (CRM, ERP, G/L, etc.)  These apps are in a terrible mess in their own right today because they are not designed according to SOA principles (some would question if they were designed in any way at all).

App vendors have their work cut out in trying to fix application level problems. Why would anyone egg them on to take on functionality that is an order of magnitude more sophisticated and more abstract?

Let us hope that this is one Gartner prediction that will never come to pass.

[This blog post first appeared in ebizq]

Leave a Comment

Previous post:

Next post: