The elephant in the BPM room is this: BPEL and BPMN won't provide seamless round-trip engineering; BPEL is a wrong-headed distraction.

"Please papa can I go
Down to Richmond to the traveling show
Please papa don't say I can't
i just want to see the elephant"

- James McMurtry, "See the Elephant"

One argument you hear is that only a language such as BPEL can be based on pi-calculus and petri-nets and that's a requirement for BPM. Poppycock! Or that you need to somehow go from the model to code to execution. Poppycock! Or that, magically, all these diverse standards (owned by disparate standards groups) are going to - poof! - work with one another. Poppycock!

As Bruce Silver points out, "without an integrated process design and runtime environment—a BPMS—you don’t get the benefits." He then says, in a subsequent post that "the need to export a diagram drawn by 'business users' to a valid (though not yet executable) BPEL program creates some obvious problems" because BPEL and BPMN are not in step with one another.

But beyond these pragmatic concerns about interoperability, there's an even more fundamental reason why BPEL is the wrong way to go: it not only offers no business value, it impedes business value. Business process management is, at its root, about agility. The paradigm of BPMN (model) to BPEL (code) to Execution is old school: it's the wrong answer to the question of agility.

Transformations should only occur when they add value. The transformation to BPEL adds no value.

My hope for BPM software is the hope for the future of programming, not the past; a future with less code, not more. With a fewer number of development process steps, not a greater number. A future where BPM software is actually as agile as the processes it purports to assist. In the words of IBM, a world where "the models are the primary artifact created and manipulated by developers."

This is the story of why we should move and how we can move toward that world...

(Full disclosure: Lombardi's product interoperates with BPEL like many BPMSs. We benchmark ourselves against Oracle's BPEL Manager and Microsoft Biztalk. We do this, primarily, for market reasons, but we do not believe this is the endgame. In fact, BPEL is part of the problem, not part of the solution.)

In the beginning...

OK, it was code to execution. A very efficient process, because all there was was code. You wrote code, compiled it, and ran it. You know, if this were the state of the art in software design in 2006, instead of 1976, BPEL's semantics would actually offer some benefits for process-oriented systems...

And then there was Xerox PARC plus two decades of programming advances...

I am stating the obvious but the movement in computing is toward more graphical representation, not less. This is true of every part of the computing community, including programmers. IBM came up with Model Driven Architecture and UML, and the notion of graphical models began to take root. (I am obviously skipping a lot and not crediting enough people, but I need to get on with the story...)

Programmers would model relationships graphically. However, because those early models weren't expressive enough, code was generated so that the programmer would have the control required to turn the model into a robust, enterprise application.

This was an improvement because a lot of tedious code was auto-generated. And at the time, each step in the process added value: The graphical model (say, UML) helped quickly define the [relatively coarse] model. The code refined the implementation. It got compiled and, of course, the system of execution (app server, mainframe, whatever) ran the machine-readable code.

But there were problems... you were only helping "version 1"...

While the auto-generated code was useful the first time around, if you messed with it, then it was very difficult (read: impossible) to go back to the graphical model when you were ready to make modifications (i.e. build version 2). Again IBM: "Consequently, without considerable discipline, the abstract models and the implementation models usually--and quickly--end up out of step."

To build "version 2" of an application or process, you had to either go straight to the code, or you had to re-tool the auto-generated code again.

Thus, we had progressed to the state where efficiencies were introduced into the development system for "version 1" of an application, but you weren't really helped for version n. That's OK, it was still better than where we were and, of course, the velocity of change in business was much less than it is now (a sort of chicken and egg situation, though: is a company less agile because its systems can't change? or do the systems not change because the company isn't agile?).

Ahh, the gay '90's...

Now since that time, there've been even more advances, primarily around the use of metadata-driven execution environments (the earliest of which were the rules engines of the 1980's that evaluated rules in real-time at run-time). Graphical development environments have grown richer, standard object model frameworks have come into being (e.g. MOF), and transformation standards have grown around XML. All of these mean we now have the technical capacity to richly represent complex systems as models, and go straight to execution.

We developed the technical capability to go from model to execution, without the intermediate step. Isn't that where all this is heading?

Meanwhile, back at the business...

Michael Hammer would take exception but the birth of modern notions of process come from GE and Wipro more than the BPR heyday of the late '80's. The combined impact of Welch's "digitization" and low-cost outsourcing led companies to either desire (in the case of digitization) or be required (in the case of outsourcing) to deal with increasing complexities in their business model. And they turned to the new networked technologies to drive costs out.

There were two aspects to this complexity: First, vertically integrated companies were broken up, increasing the complexity of getting anything to market, or touching customers with a "single face." Second, business change was happening faster and more often, and that rate of change increased the complexity of keeping systems up to date.

The combination of technological advances and business complexity gave rise to BPM...

So, yes, now we had a business requirement for the new capability: model to execution, without unnecessary transformations.

Different people came to it in different ways, but all of us got here at roughly the same time, in the late '90's. And the problem, at its heart, boiled down to three things:

• An explosion of new products and services meant you had to get version 1 of a process out the door faster.
• The velocity of business change meant you had to get version n out the door, faster.
• New, complex business forms meant that a single, shareable version of "the truth" was no longer a developer's desire, it became a business requirement

It was time to marry the new technology with the new business. It was time for a System of Process.

Could the old paradigm support these requirements?

No, the old waterfall approach to application and process development did not achieve any of these requirements! Only a faster, model-driven development process achieves all of the business requirements. Look again at the old school:

Not faster for version 1. Not able to round-trip in the real world. No assurance of a single "truth" except for the code!

Some people argue that the industry should "use BPMN for modeling, then generate BPEL code, then move to execution." Why? What value exists to an interpreted language if there is a 100% mapping to what can be modeled? And if there isn't a 100% mapping, we haven't addressed the business needs.

Requiring Code Presents A Logical Inconsistency

1) If I am using the graphical notation (say, BPMN) to simply generate a "starter set" of code (BPEL), then doesn't that implicitly mean that I am going to alter the native code? (If yes, then goto 2. If no, then goto 5.)

2) If I do need to alter the native code, then doesn't that mean that I have to do something that cannot be represented in the graphical modeling environment?

3) If I alter something in the native code that cannot be represented in the graphical modeling environment, then how will I "round trip" the changes back to the modeling environment for the next iteration?

4) If I cannot round-trip, then I am still stuck in the old days where only version 1 is advantaged!

5) If I don't need to alter the native code, then what value is this step?

6) If the step is adding no value then, um, why do I want it?

7) Eliminate the middle step. QED.

That inscrutable "BPEL Conundrum"

If you can round trip, you don't need BPEL. If you can't round trip, then you've got the wrong answer.

If you need the middle step, then you aren't agile in the real-world because you've now "broken" the picture and cannot easily change the existing process execution graphically. Some users can see the real process (those that read and write code) but others can't and, in fact, they'll be relying on pictures that do not reflect reality. Just like the good old days...

BUT, if you don't need the middle step, then you're adding cost to the system by even having it! (Isn't it ironic that process vendors are forcing you into a process that is inefficient?)

Companies that argue for a "BPMN to BPEL to Process Execution" world are arguing for an old world. I believe the world is moving to a very different picture; and I think it's the BPM industry that provides the business case to take us there.

The Endgame

The most direct path to execution and change, using the most efficient graphical paradigm.

Implications

There's always code. I am not advocating that there is zero code. But what needs to happen is that the graphical model - standard process objects and their metadata - needs to be the basis for execution. ONLY IN THIS WAY CAN YOU ACHIEVE THE GOALS OF BPM. It represents the lowest cost system available. Automated transformations can be put in place to transform the model to the execution engine - but the language of the engine itself is irrelevant so long as the engine faithfully reproduces the model.

Standards around the model need to evolve, quickly, to address:

• a defined, unified object model
• defined execution characteristics
• transaction and other run-time semantics

The single model - represented graphically - must reflect the entire system, or else the promise of BPM will not be met. (I am reminded here of a presentation I saw recently where a vendor actually said "the picture doesn't matter." I can assure you that to Elliot Spitzer and the people he's watching over, the picture - and it's consistent application - matters greatly).

What is required for this:

• A robust object model (built upon the MOF spec) upon which generalized process patterns can be represented. (BPMN or, possibly, a merged BPMN and UML. Both of these are much closer to being able to model real-world processes due to their inherent understanding of people and a lack of doctrine around how to integrate. Also the event support depicted in BPMN is more robust.)
• A standardized serialization mechanism so that process diagrams can be freely communicated and consumed. (the new BPDM, which may also form the basis for the generalized query interface, a to-be-developed BPRI)
• Defined execution characteristics of the model, as well as transaction and other run-time semantics
• A reference suite of tests to insure that execution engines are consistently executing identical models across vendors. (enter SpikeSource?)

Can't BPEL be the serialization mechanism? It is possible that representing BPEL code graphically would get you to the same place. But representing BPEL graphically is not the same thing as BPMN - either today or in the relevant future (<3 years). They are two very different specifications, owned by different standards bodies. BPMN inherently understands (and represents) objects, and has much broader (read: real world) view of the process space. It is already becoming more aligned with UML (because of movement in both specs) and, accordingly, the semantics required to be added to the BPMN spec are far fewer in number than what would be needed to overhaul the BPEL spec. For these reasons, I believe the value-add way forward is extending the work of OMG and pushing for a combined BPMN/UML - and also, in parallel on object and executable standards around the notation. Note: these executable standards would be metadata semantics, not an execution "language."

Some might also say that BPDM provides the "seamless mechanism" for holding all the graphical model's metadata and somehow magically syncing BPMN and BPEL. But that is a red herring... the fact that there is a single container for all the metadata does not insure that the process that is running is the process that is visible! I can easily create a file format that holds multiple pieces of metadata, but it doesn't mean they are in sync.

Again, transformations from anything to anything are always theoretically possible - we do it today - but that doesn't mean they add value or that they work in the real world. A reduction of transformations is the goal, not the proliferation of them. If there is a required transformation prior to execution, then there is a high probability that execution will end up "out of step." The run-time experience must, ultimately, be linked to the notation so that there is a 1-to-1 relationship between the graphical model and the execution experience.

There's an old saying "any sufficiently advanced technology is indistinguishable from magic." I have a new one: "any sufficiently hidden process step is indistinguishable from sleight-of-hand." More of this trickery we don't need. Not only does it present business problems, it inserts (or, more properly, keeps) complexity in the process development system.

Conclusion

We are moving away from hand-crafted code that is divorced from the graphical editing environment. We are moving toward standard execution of graphical models. How a "BPM Virtual Machine" works internally is irrelevant, as long as it consistently executes the model, and delivers results via standards-based interfaces.

Do you doubt that in the "long future" this is the development process of BPM? In a hundred years will we still be depicting process as code? Of course not. Well, we can get there more quickly if we lose BPEL and focus on the standards that matter: those around the diagram, diagram interoperability and "draw once, run anywhere" technology. No vendor has all of these, but only those focused on this issue have a chance of delivering you business value - even in the short run.

Technorati Tags: BPDM, BPEL, BPM, BPMN, OMG, BPM Virtual Machine, BPRI, UML