Phil Gilbert’s post last week exposes the Emperor’s clothes for what they are: BPEL is just another implementation language:
It’s simply a new way to write code. It has nothing to do with the management of business processes. I don’t love it or hate it; other than that it is a distraction. BPEL isn’t necessary to achieve the benefits promised by business process management – and therefore it’s an impediment in the market conversations that are occurring with respect to business process management.
Yes, BPEL can make writing code to implement BPM easier, but don’t confuse that with anything to do with managing business, or with anything that allows the control of business processes to be moved into the hands of the business.
Sandy
If you drink the coolaid… BPEL is a language that has been developed, more or less, in parallel with BPMN http://www.bpmn.org/. The ambition of BPMN is to permit you to build applications in a code-free environment. Certainally the diagrams get very complex, yet, for me there is not much point in writing and maintaing BPEL without diagramming tools.
The other aspect of BPEL that it is transactional. If would are living in a world where integration is performed in a SOA with multiple application servers, then I make the argument that BPEL 2.0 is unique in eliminating point-to-point integration.
In BPEL 1.0 compensations and exceptions were only notional.
BPEL is a technology layer. BPMN simplifies process implementation and adds agility to to business.
Tom
I have more comments as a A follow discussion
Tom
Tom, I appreciate your comments and your follow-up post, but what I’m saying (and what I think that Phil is saying) is that selling BPEL to the business side of an organization as a BPM solution is misleading and irrelevant. Many BPM solutions — think Fuego before the BEA acquisition — did code-free implementations without using BPEL. It’s necessary to have some sort of process implementation language as the underpinnings to zero-code implementation, and BPEL is just one of the possibilities. The business shouldn’t care what the underlying language is, only that there is something there to provide the functionality.