Should We Redefine BPM?

Now that we have determined that BPM is not Dead, discussion has turned in a big way to whether BPM should be redefined.  Steve Towers hosted a very long discussion of this on his BP Group on Linked In, with over a hundred comments.  A lively discussion, all over the map.  Peter Shooff at eBizQ todays asks the question, how would you redefined it.

Every time I get to the point that I think I have figured out the life’s answers, they change the questions.

Now that people are getting a fairly concrete understanding of BPM, why would one want to go and redefine it?  Isn’t the whole point of these discussions to come to agreement on the meaning of high-tech jargon, so that we can use it to describe new inventions?  If we keep redefining the terms, it impedes our ability to hold discussions!

Do we really have a definition of BPM?

On of the biggest problem with the term BPM is the large variety of different meaning people hold, and confusing ways they use the term.  It is not well defined.  I have argued int he past that BPM is not Software Engineering.  Programmers already have many choices for for programming languages, and the whole raison d’être of BPM is that  and something other than a traditional software engineering  language is needed to engage and allow direct participation of business people who are not software engineers or system designers.

I feel this battle is lost.  The OMG is steadily trying to integrate BPM and SOA. This deserves further reflection.  SOA is a technical system design trend, precisely like the trend to “Object Orientation” was in the 80’s.  Before that, there were many non-object languages, which have all largely disappeared, and have been replaced by OO languages, or OO extensions to those non-OO language.  This is something that is of interest to software engineers and system designers.  Same with SOA: it is an approach that system architects use to break a large system into smaller, reusable components.  BPM should be the goal of technology, not the means.  Imagine I said were were going to “integrate BPM with Object Orientation”.  Wouldn’t that sound a little rediculous?  OO is an important design principle, but really BPM has nothing to do with it.  Same with SOA: an important design principle.  All BPM systems should be designed with SOA in mind, but there is no particular inherent connection between them.

All that argumentation is based on my understanding of BPM being a practice of business management — but unfortunately the reality is that the folks at OMG, IBM, SAP have been successfully spreading the word that BPM is just another programming language.  It is just another way to develop systems.  Look at the development of BPMN: it is being tied to BPEL (a programming language) and you have to understand how BPEL works, in order to draw a successful BPMN 2.0 diagram.  This will be great for system designers and application developers, but what does this have to do with Business Process Management by managers?  Business Architecture is NOT the same thing as System Architecture — although experience convinces me that that systems engineers often are confused between these.

What is the popular understanding of the term?

I believe that the definition of BPM has “collapsed” to being nothing more tha web service orchestration, because that is what BPEL does, and the majority of the public believes that is what BPM is supposed to do.

Many of you who read this will violently disagree, stating that BPM has loftier goals than simply service orchestration, but to you I say: where is your voice when people say that a BPEL engine is a required part of a BPMS?  Why do you not complain when BPEL4People is described as the right way to involve people in a process?  Why do you not object when Oracle states that all processes can be exchanged using BPEL?  Why have you not spoken out against IBM and their work to enforce BPEL semantics in the new BPMN 2.0 spec?  Why do you not object when vendors conclude that a BPMN diagram must be transformed into BPEL for execution?  There is no noticeable uproar in these cases.  So don’t complain to me, we have all had our chance, but there are not enough of us to change things, and the term BPM has resolved to what it means.

BPM is a term that have been around almost 10 years, and in such a time the meaning of a term gets relatively fixed.  If you want to talk about things beyond this, I believe a different term is needed.

7 thoughts on “Should We Redefine BPM?

  1. Regarding your last point about speaking out, I believe there are a few notable people who have done just what you asked:
    – bruce silver
    – phil gilbert
    – myself
    – theo priestley
    And I’m sure I’m leaving out others.

  2. Pingback: Redefining BPM? Who wants that? « Welcome to the Real (IT) World!

  3. Scott: absolutely right. Those people and also Robert Shapiro, Michael zur Muehlen, Jon Pyke, and many many others. We just are not numerous enough, or vocal enough.

  4. Yup, ten years of my BPM bickering is still not paying off. It really makes me laugh. Forrester is saying that BPM is now going through the disillusionment phase in the hype cycle, so in two or three years it should come into proper use. Ha.

    In terms of the large vendors making the most ridiculous claims by spending billions in advertizing, what sense does it make for a few to speak out against it. And then there are the analysts who simply follow the money trail. (Sorry for the generalization – there are better ones too.)

    I want to comment also on ‘linking BPM with Object Orientation’ and that sounding ridiculous. I think that an OO design perspective on the entities that make up the process is a very good approach. If there is a way to express ‘real things’ in IT concepts, OO is the way to go. And that applies to BPM as well. Anyway, we have done it so I am not just theorizing.

    BPM is after all a management concept first. There is however a sensible design principle behind looking at applications in terms of the process you want to express. Therefore process orientation in application design in terms of an expanded USE-CASE is not a bad approach either. If the outcome of the process orientation is however a hard-coded construct, why bother with BPM, just stick with UML.

    Using an object model and letting actors express processes in terms of assembling (and continuously changing) those objects in the desired way is a very powerful way of creating applications. Is it an application? Is it a BPM process? Is it a Mashup? Who cares? The technical questions have to be asked at some point in time, but at first one needs to check with the business if they can get the functionality they need ASAP, and if they can adapt it any time they want.

    We are discussing the ‘Emperor’s New Clothes’ here, I’m afraid. Let’s go and do something productive.

  5. Pingback: Process for the Enterprise » Blog Archive » Move Along People, There’s Nothing to See Here

  6. Pingback: BPM Quotes of the week « Adam Deane

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s