BPEL Unmasked

Here is an initial BLOG I wrote and never posted. It was written 1 year ago today and even at internet speed, it is still relevant.

During discussions with a few integration consultants in the Calgary office, we started to brainstorm the usefulness of BPEL to the market/clients/businesses. That is, what value proposition does it bring, other than the Middleware vendors having a marketing line on their brochure that says BLEP Compliant?

This is not a story of what BPEL is, you can look that up yourself, but it seems the proposition of having process flow definition represented in XML was supposed to allow interoperability with design/modeling tools so that the Business Process models created by the Business Analysts could be imported into the Middleware Process Repository/Toolset. Big hairy deal. In fact, the process of creating these flows from scratch is truly the simplest part of the Integration Solution development challenge (most demo’d I'm afraid) that this provides no or little time savings.
What BPEL does provide is the establishment of a STANDARD to limit each process modeling tool (technical implementation) so that the models created in the tool can be read/interpreted by HUMANS as meaning the same things. That is, limit the UML plethora of models and notational references (icons) into something that can be easily understood by the business and implemented within BPEL aware tools. This is the power and the value proposition, not the technical importation of models or the representation of them as XML, on or off of the multi-part message itinerary, since it matters not.

Stay real!
The SOA Integration Ninja