Keith Swenson starts his new article by evaluating BPEL’s usage in today’s BPM products:
It seems that conventional wisdom has been for a while that "Business Process Execution Language" or "WS-BPEL4WS" is the standard for execution in the BPM space. At the same time, the majority of BPM and workflow products on the market today work successfully without using BPEL. Some say that those products that don't implement BPEL are simply dragging their feet in the mud. Others say it is not possible to do what their product does in BPEL. Whom are we to believe?... Recently an article was written on InfoQ which took a particular process scenario drawn in Business Process Modeling Notation (BPMN), and investigated in detail why it can not be implemented using BPEL. That process can, however, be run on a system that directly executes BPMN... Since you can execute the BPMN directly, it begs the question: why translate to BPEL at all?
According to Keith, there are plenty of vendors and publications promoting BPEL "as the one-and-only-true-way to support BPM". In reality, there are plenty of successful BPM products that are based on other technologies. As a result, potential users should be asking the question "Is BPEL appropriate for what I want to do?"
Keith attributes popularity of BPEL to the following assumptions, often made by its proponents:
- The people making the processes are programmers
- The activities in a process only need to send, receive, or transform XML data.
- Any standard will be better than no standard.
Analyzing those, Keith states that the first two assumptions are:
...valid in some situations; the product category that we call EAI is in fact configured primarily by programmers, and need only to send, receive, and manipulate bytes of data. So for EAI, BPEL might be a reasonable choice. But many BPM products are designed to be configured by non-programmers; by the business people themselves (and that is indeed why we call them business processes in the first place). Non-BPEL approach exist that allow non-programmers to draw up and execute processes, safely and reliably. Those processes are qualitatively different from the processes a programmer might draw up, and many people familiar with EAI-style "BPM" are incredulous, but that basically circular reasoning based on the assumption that the process designer is a programmer. To be fair, some believe that business people will draw up initial process diagrams, that will then be fixed up by programmers. But there are other situations where there is a no programmer at all, and that in those situations BPEL would be a poor choice.
As for the last assumption, Keith considers it more "marketware" then reality:
people think that since there is overwhelming "magazine" evidence that BPEL is the right standard, then anyone not supporting BPEL is simply too lazy or trying to disrupt the marketplace. Unfortunately for these people, the process world is inherently more complex than they realize; the variations among approaches are not simply the randomness of vendor whim, but in fact an appropriates response to the variations in the needs for process support. People should keep in mind real requirements: if BPEL meets the need, then fine, but don’t blindly assume that one size will necessarily fit all.
Keith suggests replacing BPEL with the direct execution of BPMN-based process definition and shows how Fujitsu BPM Studio allows to do this. He finishes his article by stating:
Why again do analysts recommend BPEL? It seems to me... to be nothing but a limitation.
The confusion about BPEL and BPM in general seems to keep growing in the industry. There is still no agreement on the most basic BPM issues:
- Is BPM a business Discipline or software engineering?
- Whose responsibility is it to implement (automate) a business process?
- Should we aim to move from design to deployment with no programming?
- Whose responsibility is it to maintain a business process?
Only by getting agreement on these issues will allow us to frame BPEL discussion and the whole BPMN/BPEL relationship discussion correctly.