Kiran Garimella's BPM Blog

Kiran Garimella

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

user-pic
Vote 0 Votes

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.

No TrackBacks

TrackBack URL: http://www.ebizq.net/MT4/mt-tb.cgi/12375

5 Comments

| Leave a comment
user-pic

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

While we all can wait and hope that this never actually turns out to be true, the biggest of ERP/SCM vendors still manage to sell their apps making use of the gap / disconnect between IT staff and business owners.

The "optional module for every business process" approach at the end of the still cannot cater to realistic problems at the floor and still affect the bottom line of the business.

Keeping these things in mind, it really does seem for a moment if the biggest app vendors will tend to incapsulate BPM into their apps, given the fact that SOA highly complements BPM and increases business readiness.

Well that is interesting. I am writting in 2009 and well I have yet to see any evidence of this happening. Although I have heard of some various products trying to workflow-ize or BPM-ize there existing solutions. Of course the don't really know what the terms mean and only understand it in relation to the smaller problem sets that their applications are trying to solve.

user-pic

I think Craig's exactly right. You're seeing other, more vertical applications attempt to adopt the core BPM principals. And, while on paper, this seems like a great idea - the reality is that it's the exact opposite of what BPM really espouses. BPM is about uniting the organization via a common process platform, not carving it into process-enabled silos.

user-pic

Attempts by app vendors to BPM-ize their apps is driven in part by an attempt to cash in on the newest fad (as they see it), and in part by fear of BPM. It's as if app vendors were threatened by an operating system and started writing their own device drivers and kernel software. Sounds ridiculous, right?

In reality, BPM does not encroach on apps, but only provides a 'process operating system.'

user-pic

I really havent seen a lot of evidence of this just yet. I also dont know that it's such a bad thing that vertical apps try to adopt BPM principles...this does not, inherently mean the demise of BPM - it just means that it's logically being extended. Not only can BPM be a horizontal tool to increase the value of applications, but it can also improve the value of those vertical applications that will simply never go away.

Leave a comment

Our Popular BPM Bloggers


ADVERTISEMENT