VOSibilities

…we wanted to respond to Bruce’s post with what we believe is important to understand about the differences between BPMN and BPEL and why they are both important.

Bruce believes that BPMN a process model doesn’t have to be just a “business requirements” sketch but – with implementation attributes added by IT — a diagrammatic representation of the executable solution.

That’s great. The issue has to do with those pesky little “implementation attributes”. Bruce seems to imply that they are just little jots and tiddles that are easy to create in the first place, so it would be no big deal if a business had to create something completely different for a different vendor’s runtime. The problem is that implementation details aren’t that simple. They are the details that a machine needs to run a process…and they can’t be fuzzy or imprecise.  Yet BPMN does not standardize the way that data is modeled, declared, accessed and manipulated.

Any collection of files that can be executed is a program. Having some of it represented graphically, doesn’t change that. But a large chunk of the work of that program is not represented graphically. That means that BPMN used for the purposes of executable processes is a programming language, but it is a programming language that doesn’t bother to describe how to declare variables, write assignment statements, evaluate conditionals, or any other work that has to do with data. The only thing that is standardized is the control flow. But if you look at most programs, the control flow is a minority of the work of the program. The rest is data manipulation.

In the world of long-running business processes another important detail that has to be worked out is how to pull appropriate correlation data out of messages in order to route them to the right process, or location within a process. Getting this right is significant work.

Do people really want to have to do all that work, work that is absolutely necessary to get the process to be executable, in a proprietary language? Of course, the answer is no. One of the values of standards is portability — skills portability and actual portability. Portability is never perfect, but if only a fraction of the information necessary to get a process to execute is standardized, then only a fraction of the work reaps the benefits of standardization.

Even for control flow, the transformation into BPEL can be helpful. If you can’t generate BPEL, there is a good chance that you goofed on your process model. I have seen several BPMN process models that clearly don’t do what their authors intended (based on a knowledge of what they were trying to do). In BPMN it is fairly easy to create models with merge conditions that can never be met, or that result in multiple tokens (execution) along a path that the user clearly only intended to be executed once. Generating working BPEL can help to ferret out these problems.

Readers might be interested to listen to a podcast I recently recorded on the relationship between BPEL and BPMN. It’s time we stopped trying to favor one over the other and realized that both are needed, and dependent on each other for success.

This entry was posted on Friday, November 7th, 2008 at 10:41 am and is filed under SOA. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.