On Process Portability
July 26th, 2006
When you’re deep in a hole of your own creation, the usual advice is to stop digging. But Assaf Arkin is not a slave to such conventional wisdom. He took a sound hammering on the comment thread to his original IT|Redux post where he states that BPMN should just be the diagram for BPEL 2.0, but he continues to dig in hard and reaffirms that process portability demands a common execution language, BPEL 2.0. But he doesn’t really defend the assertion with arguments that the undecided can understand.
Today Ismael tries to bail him out, making the valid point that the only process definitions that are close to portable today are those based on BPEL. I would agree with that, and it’s why I’ve never been a “BPEL-hater”. But my own migration to the BPEL-doesn’t-matter camp has been based on the vision of a new higher-level design portability standard: BPMN. Now that may or may not be OMG’s view of what BPMN should be — Fred Cummins’ comments on Assaf’s original post lead me to think not — and I’ve already committed the heresy of saying if that is not included in OMG’s vision for BPMN, the BPMS vendors should just get together and create “BPMN-P” (portable) themselves.
So let’s get to the real point: What does design portability mean? Assaf’s version, which I interpret to mean that two “implementations” of the same diagram should result in the same BPEL 2.0, is too narrow. Let’s face it, each BPMS is going to have its own bells and whistles that “add value” on top of any standard. So the challenge is to draw a line — the portability threshold — separating semantics that must be standardized to conform with a reasonable process owner’s understanding of portability from value-add features that do not. Those value-add features may figure decisively in the process owner’s choice to go with BPMS A instead of X, Y, or Z. But portability also guarantees that if BPMS A turns out not to perform as advertised, another BPMS can be swapped in with relatively little redesign.
The BPMN 1.0 spec is silent on this issue, and it’s not clear that BPDM addresses it, either. To most vendors today, showing activities as rounded rectangles, splits and branches as diamond shapes, and swimlanes is enough to claim BPMN conformance. Yes, I agree that is ridiculous. I also agree that an intermediate event attached to an activity or subprocess boundary is a valuable design concept that should be preserved in BPMN-P… even though leading non-BPEL “BPMN-compliant” tools (e.g., Savvion, BEA) don’t support it today. But some do: Lombardi, Cordys… Compensation seems to be an important thing to Assaf, but the business requirement is very different for human-centric and straight-through processes, and fault and compensation handling is all over the map. Is compensation above or below the portability threshold? It’s worth having the discussion.
Right now the real debate is on hold while we wait to see what BPDM looks like. Unlike the BPEL TC, where issues and interim drafts are open for view, the BPDM process is completely opaque. I hear rumblings about September, so maybe we’ll know soon.
Entry Filed under: BPM
2 Comments Add your own
1. Assaf | July 26th, 2006 at 4:40 pm
Doing a visual notation for BPEL is easy, but I don’t care for that. I’m much more interested in BPMN. It’s high level, it’s simpler, the process model looks like what you’re trying to accomplish, not how the engine executes it. So BPMN is interesting.
But how do we get BPMN to generate processes that you can execute and manage, if there’s no path to implementation?
Based on the BPMN specification alone, how can you say “take the billing information I received in this order and send it to accounting using this activity?”. How do you say “do this credit check activity because the order value is over some pre-defined limit?”
I need help, because I can’t find that in the spec.
There’s a lot more that goes into the process definition than goals and objectives. How you manage orders depends on what inventory can do, or how accounting runs. Your business process in practical terms is the back-ends, and the data you store and more around, and the services you call, and the UIs you provide. You can model anything, but the only thing worth modeling is something that actually routes an order through all these systems, involves actual employees, delivers actual products.
And you need a way to express that. Enter service definitions, data and message types, conditions and transformations, UI forms and tasks, and so forth. How useful is a process definition that can’t capture that?
From there on, my post suggest four ways to solve the problem. Ignore it exists. But then there’s customers and their business reality. Do only BPEL, but I happen to think BPMN is much more interesting to our target audience. Re-invent all these solutions again in BPMN. Or find a path to execution and make sure one steps lead to each other.
I see BPEL as a means to an end, as a path from BPMN to actual execution that we can use right now. Why re-invent if you can reuse?
2. BPMS Watch » The Po&hellip | July 28th, 2006 at 9:11 pm
[...] After I posted re the piling-on Assaf Arkin was taking over his assertion on IT|Redux that BPMN belonged to BPEL, the man himself posted a thoughtful response on BPMS Watch. I was waist-deep in real work at the time and didn’t have time to think through an appropriate continuation of the thread, so I dashed off a quick response by email. That began an interesting out-of-band conversation that, if nothing else, narrowed the gap between the BPEL-si and BPEL-no positions, and shifted the debate from lofty analogies and name-calling to things reasonable people can at least discuss. [...]
Leave a Comment
You must be logged in to post a comment.
Trackback this post | Subscribe to the comments via RSS Feed