VOSibilities

Bruce Silver saw my previous post on the simplicity of BPMN vs. BPEL for execution and wondered: “Are we still debating this?”

Still?

The BPMN 2.0 spec just went to beta in August and no vendor yet has an implementation of the new BPMN 2.0 execution language. So at this point the debate is just getting started. We can only compare what exists (BPMN 2.0 with BPEL execution) with the theoretical idea of a product that will someday implement the new BPMN 2.0 execution language.

At that point we will be able to get a real side-by-side comparison. Until that time, we have to guard against “shiny-new-thing syndrome,” where the newly envisioned technology gets to paint a wonderful picture looking toward the horizon, while actual working technology has to compete against that vision bearing the stains that come from living where the rubber meets the road.  Although, in this case, even the horizon envisioned by the BPMN 2.0 execution language is tainted by some pretty scary-looking smoke.

Bruce dismissed my assertion that BPMN 2.0 on top of BPEL is simpler than the new BPMN 2.0 execution language with the following:

Simpler for whom?  When you sort it all out, he’s actually saying BPEL is simpler for an engine vendor because it doesn’t have overlapping or alternative constructs like BPMN does.  No one would argue with that, but who cares?  No engine vendor is going to support every possible BPMN 2.0 element and attribute called out in the metamodel.  And I’m not saying just in the first release.  Not ever.  In that sense, BPMN 2.0 is not a self-contained execution language like BPEL is.

We disagree. Because we’ve actually built an execution engine, we know that it is actually pretty easy to implement alternative overlapping language constructs. This debate about simplicity isn’t about what a vendor can build — it’s about what the ultimate impact of that engine technology is on the user who designs and deploys processes on that engine.

My concern is for the poor person who is trying to figure out what is going wrong with a process that occasionally gets stuck. Forward progress for a process that uses the BPMN 2.0 execution language depends on a complex interplay between a huge number of constructs: event handlers, correlation mechanisms, data-flow with optional and required data, and token-based control flow that has to account for multiple tokens flowing simultaneously on a single sequence flow.

The problem with a language that is large and complex is that it is hard to have any confidence that what you’ve created will always work the way that you expect it to in production, especially when you can only test a small subset of the exponential number of possible execution scenarios.

Bruce’s admission that “BPMN is not a self-contained execution language” is noteworthy and I hope people pay close attention to it. Why do people care about standards for the languages that they use for their software? The answer is portability – primarily portability of skills but also portability of code and interoperability of tools. Basically, they are looking for an ecosystem around the language.

I love the fact that portability of skills will be enhanced by the standardization of BPMN as a notation, but for all of the constructs that are necessary to get the thing to actually execute, it seems like there are two choices: use BPEL, which is (despite assertions to the contrary) quite portable, or use some vendor’s subset/interpretation of the new BPMN 2.0 execution language. By “interpretation” I mean that even strict conformance to BPMN 2.0 admits incredible levels of freedom that are counterproductive to the creation of a language ecosystem. The most egregious example of this is the fact that the type system is pluggable. Few things are more important in a language than the type system, and yet BPMN 2.0 allows vendors to choose their own.

Bruce’s attack on the use of BPEL with BPMN rests on the assumption that: “BPEL is inherently block oriented, like a computer program, while BPMN is inherently graph oriented, like a flowchart.” Actually, BPEL supports both styles (although with some caveats). Here is a process built using ActiveVOS that is standard BPEL:

Doesn’t this look like a flow chart to you?

The one caveat that BPEL put on this style is that the loops have to be nested. This is where I agree with Bruce – without any extensions, BPEL does have an issue with “interleaved loops.” From my experience, interleaved loops are not the most common case, but if you do have a process where interleaved loops are the most natural way to represent it, what do you do? You have two choices: 1) with the use of variables, you can always rework the graph so that the loops aren’t interleaved; or, 2) you can use an extension to BPEL that removes the looping links restriction. This is an extension that is supported by both Active Endpoints and IBM and does away this nagging issue in the mapping between BPMN and BPEL. And it does this without thowing the entire language out the window and starting from scratch to make a bigger, more complex language.

Yeah, baby! Ain’t nuthin’ like a good blog war-o-words. And a juicy one has just broken out between two influential voices: Nick Malik and Bruce Silver. And I suspect we haven’t seen the last of it. (At least I hope we haven’t. July is a slow month; we could use some American Gladiators-style trash talkin’ right about now.)

Apparently, Nick found the top dead center of the button you shouldn’t push in Bruce’s mind: he says BPM is never going to live up to expectations that non-developers will create applications.

In reply, Bruce — slappin’ Nick right upside the head – replies that Nick has to “prove” his assertion by showing that someone — anyone — in the “BPM community” has made a claim that modeling leads directly to completed applications.

While I hope the histrionics continue, this is really nothing more than two purists trying to keep their rivers from converging.  (I gotta admit that I find these near-screaming matches to be more educational than so-called “polite debate” for the very simple reason that they strip out the fluff in favor of direct frontal attacks everyone can understand.)

We all know from long, bitter experience that the “third rail” in the Microsoft world (touch it and die) is developers. MSFT will do what it takes to keep developers tied to the Windows API. Anything that could loosen that death-grip is a danger, and that includes end users working in standards-based tools that could care less about the underlying OS.

And from what I’ve read about the “BPM community” there’s a fair bit of wishful thinking there, too. Bruce is probably correct that no responsible entity has claimed what he believes Nick is claiming. Yet, you don’t have to say the “E” (execution) word outright to lead people to the conclusion that your BPMS does it directly from pretty pictures. Go ahead, spend five minutes on Lombardi’s site and tell me you don’t see it there.

What do we care? Well, let me be the first to pre-announce our upcoming ActiveVOS release, scheduled for mid-August, in which we actually converge the rivers. We will have the most complete BPMN modeling capabilities and, of course, we have the world’s best and most complete BPEL deployment, execution and management system.

ActiveVOS will make it possible for business users to come very, very close to execution via BPMN. And we believe that developers will take that non-executable model and “finish” it in a 100%-standards-based environment that frees them and their businesses from .NetJail.

Forgive me the nested platitude, but the issue boils down to that old saw that says, “Get the right tool for the job.” Developers need modern, standards-based languages that execute on the metal; business analysts need modern, standards-based ways to describe what systems have to accomplish. Being doctrinaire about which is the “correct” way to serve business and IT is beside the point.

So, while it’s fun to see the purists bloody each other, we intend to deliver an implementable, cost-effective and complete way to achieve what neither side really seems to want. And that, dear readers, is what a visual orchestration system is all about.