Does BPEL matter? (part 1)

I always thought that BPEL or Business Process Execution Language (an XML format) was created so that process definitions should be interchangeable between BPM vendors. The truth is that any product (BPM or not) locks a customer in, one way or the other. The most successful vendors in doing this are IBM, Oracle, Microsoft and SAP.

There are over 200 other BPM vendors in all imaginable flavors. Less than ten percent of those vendors support BPEL and their implementations are not fully compatible. Therefore it is strange that some claim that BPEL is the ‘de-facto’ industry standard. Yes, it is the only thing that comes close to something that looks like a standard. Of all the languages that anyone would want to code, BPEL is (like any XML format) not something you want to write natively. Certainly not a business analyst. But the vision and claim is that BPEL resembles process code that can be taken from one BPM vendor to the other with little to no effort. That, I am sorry to say, is an illusion.

When you look at how various BPM environments are implemented then you will find each one to be utterly unique. The possible combinations of operating systems, Java server versions, database servers, business rules, content integration, GUI frontend functionality, browser and portal functionality, backend application service interfaces (SOA or not) and more (such as security interfaces) go into the several thousand. BPEL exists in multiple versions (1.0, 1.1, 2.0 are quite incompatible) and allows proprietary extensions most of which are in native Java code. So it is an illusion that you can take the BPEL code along and then simply run it in another BPM environment.

Let me take this further. As you do not want to maintain BPEL code, why would you even worry about it? What you want to maintain is your processes and these should be maintained in a graphical manner and if at all be saved in something like BPMN, which is another dreadful XML format but at elast represent a graphical notation. BPEL and Java means that you need to work in Eclipse, which is a programming tool (another so called ‘standard’) and nothing else. BPEL is a functional subset of BPMN and thus a true roundtrip is not possible.

BPEL does not solve any other issues of BPM like the necessary process monitoring. A customer service centered organization does not care how you execute a process as long as it meets the business goals. So what we need is to monitor business data that represent those goals. Some of them may be process related such as elapsed time for completion of a customer service task. Monitoring business data requires access to those data and they need to be defined. In what way BPEL would support standards-based tools for business monitoring has not been explained.

I am the founder and Chief Technology Officer of ISIS Papyrus Software, a medium size software company specializing in communications and process management. I wrote several books and hold a number of patents. My quest is to bring common sense to IT, mostly by focusing in human quality issues rather than cost saving, outsourcing and automation. I am also Chief Architect at VIPorbit software which provides mobile relationship management.

Tagged with: , ,
Posted in Business Architecture
3 comments on “Does BPEL matter? (part 1)
  1. […] closer to assuming the role of de facto standard? Not by Max Pucher’s estimates. Max took a hard look at the protocol, and found, in his opinion, industry-wide support to be lacking. “There are over […]

    Like

  2. Max, you speak the truth and do a very good job of it here. Nonetheless, your opening position needs to be re-calibrated:

    “BPEL . . .was created according to the vision that process definitions should be interchangeable between BPM vendors.”

    No it wasn’t and that is specifically the problem.

    Although there is a lot of context surrounding the creation of BPEL, and in fact process interchange was well-established vis-a-vis XPDL at the time.

    But if you were otherwise an XPDL skeptic and were looking for another means for process interchange, would you really start with XLANG and WSFL? Let’s hope not!

    BPEL was created to both rationalize the two aforementioned standards and head-off work in the WS-* community around services orchestration.

    There needs to standard execution semantics for passing messages and control flow through sets of services. That is what BPEL does. It does not allow and was not ever intended to support the execution of a business process, at least not by any common/reasonable definition of which constitutes a ‘business process’

    The biggest problem/limitation/issue with BPEL is the misunderstanding and misplaced expectations that surround it. BPEL does what it was designed to do and it doesn’t do what it wasn’t. It was never intended to enable run-time portability between BPMS environments. That is an unfortunate myth perpetuated by people who do not understand either BPM or BPEL.

    Your point is understood, correct, and well-taken. But I would rather you frame it around the BPEL myth and misunderstanding, rather than a BPEL shortcoming. As virtually all press and analysts fail to understand standards in general nonetheless BPEL specifically, this myth is perpetuated.

    Last week I had an otherwise enjoyable vendor briefing where I was shown a lot of cool stuff and told “… and we do all this in BPEL.”

    No you don’t, I explained. “Oh yes we do!” they replied, to which I explained the technical impossibility of doing virtually anything of what I was shown in BPEL and I finally got “Well I am just the Marketing Guy, so you need to talk to our R&D.”

    Indeed, I am sure that R&D would have a different take on things and not present BPEL as some kind of magic comprehensive language as marketing, press, and analysts have done.

    Is BPEL relevant, or as Max asked does it matter? Yes, of course it is and does. But it is not a process language and really does not matter to business process design, modeling or execution. Does “BPEL4People” matter? About as much as “MASM4People” were one ever invented.

    But the bottom line is that Max you are correct, you cannot take BPMS code today and execute in another environment. You can invoke one BPMS from another using Wf-XML and you can take one process definition from one to another using XPDL (design-time compatibility) but there is no such thing as run-time/execution-level compatibility.

    So at the risk of sounding crass, I would suggest that support BPEL matters about as much as wearing a ruby-encrusted lapel pin does to finding a cure for AIDS. Nobody wants to be told that their emphatic support is irrelevant, but at the end of the day, what has it accomplished?

    Albeit in the case of BPEL, it has meant that marketing has defined the standard’s role with little understanding of its purpose and limitations, nor with any concern or knowledge of how their products might actually use it.

    Like

    • Nathaniel, thanks for a great summary and clarification. You are right that my main disagreement is how BPEL is sold and not with what it is. I have these discussions every day as to why we are not this or that XML standard because others claim it makes them open. As you say, it doesn’t. Thank you for reading my blog and commenting. Much appreciated!

      Like

Leave a Reply

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

WordPress.com Logo

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

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

Max J. Pucher
© 2007-16
by Max J. Pucher. All rights reserved.
Real World Statistics
  • 200,855 readers

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 8,157 other followers

%d bloggers like this: