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.
A solid argument indeed. Every practitioner hits the problem of process modification as soon as he/she goes beyond pure system-to-system processes. And you shouldn’t be shy for the fact that Interstage has one of the best implementations of on-the-fly process modification.
That is an interesting cnemmot. In many cases, standards in general are NOT in the interest of a dominant vendor, who would rather trap customer with vendor lock in. There is one thing that always tips the balance in favor of supporting standards: customers are not stupid. If as a vendor you are offering a product that has true value, then sometimes offering a an exit door is the best way to keep customers.In the case of process modelling there is something special going on. As more and more people with different levels of skill and different backgrounds get involved in process modelling, we are finding that there are a variety of different new and creative tools, and it is impossible for one vendor to offer them all. Having an open file format allows the process definition to be put into a repository, and available to all tools at once, or to be used in any order, without having to explicitely export/import before and after specific tasks. As a vendor, this makes it really easy for a third party to come in and add value to my process product. The third party benefits when support for a single format make them useful in a number of different vendor suites. Maybe ten years from now we will know exactly what should and should not be included in a process design tool so that all users can share a single tool, but we are not there yet.
Pingback: links for 2009-02-04 « steinarcarlsen
Please fix the links in the post 🙂 Thank you.
(OK, did, thanks for the reminder.)
Pingback: On-the-Fly Process Modification - Process Is The Main Thing
It is indeed increasingly difficult to trust any recommendation or position expressed by a vendor as I don’t know anyone that would express any opionion that explains that its product has some design flaw.
We have BPMN and BPEL and people have generally accomplished some results with these two standards which ever way they used it.
Have you ever considered articulating BPMN and BPEL? instead of opposing them? What I been by that is positioning them with respect to each other in a non-homothetic way (as in BPML must compile in BPEL).
What if BPEL was a programming language, as you say eloquantly, that could be used to efficiently model the lifecycle of resources participating in a business process?
Ironically, the two papers in which I first introduced these ideas are actually referenced in the BPMN spec itself. I am very honored by that, but what I fail to comprehend is that after now 10 years that we have been wrestling with these ideas BPMN (BPEL|BPML), we could think that it is a bit time to think outside the box?
Of course the idea that I am proposing would not fit any vendor (BPMN or BPEL) or any consultant for that matter, but how long are we going to have these insipid discussions until someone says enough?
Pingback: Newly Noted #19 | Patrick Verbruggen's Blog
The IBM Websphere Process Server does allow migration of running instances to a new template in the upcoming WPS 7.