Is the BPMN/BPEL Debate a Dead Horse?

Bruce Silver’s latest post “Reframing the BPMN vs BPEL Debate” calls to question whether it is worth continued discussion of the definition of BPM. Like most of Bruce’s posts, it is insightful and well worth reading. This is in response to a post by Boris Lublinsky on “BPEL: Who Needs It Anyway?”

I am a little surprised by Bruce’s response,  knowing how Bruce has struggled with educating people on BPM technology. He seems almost dispirited when he responds that “We will never get agreement” on the issues of who designs a process and how it is developed and deployed. Yet I agree with his point: I believe that there are such a wide ranging requirements, that there exists no single best approach for all situations. The different approaches that today are all called “BPM” are much more varied than most people think. The field of business process support is far too young to be choosing a single best approach at this time.

Indeed, that was the point of my original post on ” BPM is not Software Engineering“. So many people see BPM as a kind of programming limited to Service Orchestration that I feel we must continue this debate so that people can see the real potential. I envision a possible technology that non-programmers can use to help them coordinate their business processes. I am not alone with this vision. It will be better than email, which is what these people are using now to coordinate their business processes. When I speak about the potential, there are “BPM Experts” who tell me that this sort of technology is impossible. This is because they limit their thinking to the kinds of BPM technology they have experience with, and miss many of the other approaches available. We don’t know exactly what this technology will look like, but one thing I am pretty sure is that it will not look like a software engineering system. In fact, it might not be very friendly to programmers at all because this technology is not made for programmers. We should not assume that software engineering approaches are necessarily going to lead to this technology.

Bruce goes on to a hypothetical standard that combines BPMN and BPEL. (I prefer “BPMNEL”.) He is correct that this would address one main concern. Some existing products allow for a “Model Preserving Strategy”. This is an approach that allows a business person to draw a model, it allows a programmer to extend the model with integration code without changing the form of the model, and it allows the execution without changing the form of the model. I have called this WYDIWYE in an earlier post. A product based on BPMNEL would be able to retain the same form throughout the entire BPM lifecycle, and that would be much better than BPMN transformed to BPEL as it is today.

While that addresses one very important concern, I would still have concerns with the BPMNEL approach. For example, in human processes that last many months, one must be able to be modify a process while it is running. I have seen no evidence of any BPEL system that allows migration of running processes to a new process definition. My research turned up academic papers on the topic, but no evidence of shipping implementations. (Please make a comment if you have such evidence.) Understand that not all business processes need run-time modification. For example, processes that last no more than a few minutes have no such need. Is process migration important for BPM? Sometimes it is, sometimes it is not. See, this horse is not dead.

It is almost unfair to talk about this, because BPEL was never design for run-time modification of processes. The ability to migrate a set of running process instances to a new definition was simply never a consideration in the goals of BPEL. It is not theoretically impossible to migrate a running BPEL process to a new definition, but it is very very difficult. BPEL is pretty much like any other third generation programming language offering nested scopes, block structures, and exceptions. Because of the nested scope, it is nearly impossible to determine how the stack should be transformed in order to account for an arbitrary modification of the program. Traditional programs do not have the need to be altered while they are running. The expectations of what BPM could do had been reduced to something that could be accomplished with a rather normal programming language.

Run-time modification of a process is not something you can add to a language through an extension: it must be designed to support this from the beginning. Most of the research around runtime BPEL modification is around allowing the web service addresses be modified for different instances of the process, but never is there a serious discussion of a change to the actual process.

I can understand being suspicious of motives. I work for a vendor that has a stake in the game. One might easily suspect that I argue against BPEL simply to increase sales, or simply too lazy to implement a standard. Skepticism is good, but it should not blind us. BPEL is very good for web service orchestration, but there is so much more to BPM than that. That is why the debate continues.

True agile support of human work is still a largely unsolved challenge. We must be careful not to oversimplify or to assume that a simple solution will generalize to every situation. We must not assume that “any standard will do, just pick one”. The human condition is so rich and varied that we should not assume that one approach will handle all situations. The full promise of “Management of Business Processes” involves thinking beyond the rather limited scope of today’s systems — and here is the point: the solution may not look like a traditional programming language, and may not make sense to those experienced in “normal” systems as they have been in the past.