Kiran Garimella's BPM Blog« Inaugural Post | Main | Inbox Zero »
March 14, 2006Am I a BPEL hater?
In a recent article, Bruce Silver asserts that "The world of BPMS is divided into BPEL-lovers and BPEL-haters". I certainly understand what he means. It seems that the BPM community is splitting on whether BPEL can be saved. On one side, the purists know that BPEL is the best chance for a standard that will be portable across vendors. On the other side, the vendors know that there will be a huge chasm to cross between BPEL4WS 1.1 and WS-BPEL 2.0, and that even WS-BPEL 2.0 is only a tiny subset of what a BPM vendor needs to include in their product. Frankly, I believe that it's largely a moot issue. BPEL support is a technical implementation detail in an technology solution that is supposed to be aimed at business users.
As such, I guess you'd have to classify me as a BPEL-hater. BPEL is woefully inadequate for modeling real life BPM applications. This has been validated by both the marketplace, with rampant vendor extensions, as well as the standards body, who have shaped BPEL 2.0 to be very different and very incompatible with BPEL 1.1. Meanwhile the specification is so loose that real portability between vendors isn't possible anyway. Bruce himself has written about the huge problems that remain for the standard in his article about BPEL4People.
But I hate to characterize myself this way. BPEL is our best hope as an industry for standards based solutions. I really want to love BPEL. But BPEL doesn't even have the concept of roles or human activities. Until BPEL vastly improves, BPEL is only one tiny, tiny piece of BPM.
Since Bruce clearly understands the good, bad, and ugly about BPEL, I was very surprised to read his comments about the the Fuego/BEA merger. In part, he writes:
"FuegoBPM appears to have already morphed lock, stock, and barrel into BEA’s AquaLogic BPMS. Not that FuegoBPM isn’t a fine BPMS, but it’s not based on BPEL wasn’t BEA a “founder” of that standard? ... For example, process activities in Fuego are not SOAP calls to remote services, but user-defined “methods” of the activity implementation written using Fuego’s VB-like FBL script. Architecturally, that puts it closer to a workflow engine than to a BPEL engine. . .
Companies like IBM, Oracle, and Intalio have shown that you can build a complete BPMS with human workflow, business rules, BAM, and the rest on top of a unified service orchestration stack, so why would BEA want to go back to the old dual architecture approach workflow for the end-to-end process and BPEL just for system-to-system integration? That makes sense for a pureplay like Fuego, but not for a core platform provider like BEA.
First, let me straighten out a couple of technical inaccuracies. A process activity in FuegoBPM can have any number of implementations. In might be a FBL script, as Bruce describes. Or it might be a form. Or a series of forms organized into a screenflow. Or a web service. Or a call into an external system. Or an Business Activity Monitoring Dashboard. Or any number of other things. A BPM tool that only could only implement process steps as web services would be a very poor tool indeed.
Second, FuegoBPM does support BPEL. You can define a BPEL process, implementing all of the activities as SOAP calls to remote services, if you like. I'd assert that architectually FuegoBPM includes both a workflow engine and a BPEL engine, as well as a lot of other other things. BPM is the convergence of a lot of technologies and BPEL is only one extremely tiny part of what makes a BPM product.
The companies the Bruce lists as good examples of BPEL based servers is very telling. None are considered, at least by Forrester, as strong players in human focused BPM. They are all classified as "integration focused BPM" players. (Interestingly, Forrester says that FuegoBPM uniquely can work as both a human focused BPM solution or an integration focused BPM solution. Perhaps because of FuegoBPM's dual support of XPDL and BPEL.) I'd assert that the BPEL focus of the vendors Bruce mentions is is holding them back. That if FuegoBPM had been a BPEL-only solution that it wouldn't have been nearly as capable of fulfilling the AquaLogic stack.
Posted by davidogren at 12:46 AM in
BPM
| 
Digg This | 
Add to del.icio.us
Trackback Pings
TrackBack URL for this entry:
http://www.ebizq.net/mt/mt-tb.cgi/116
Listed below are links to weblogs that reference Am I a BPEL hater?:
» Proprietary SOA versus Open Standards from Business Integration Architecture & Technology
The title of the blog sounds like an oxymoron, but you really cannot get away from proprietary components in your SOA. Legacy integration and integration to packaged applications, such as SAP, are obvious examples, but there is more subtlety than that... [Read More]
Tracked on March 14, 2006 12:11 PM
CommentsI agree. BPEL 2.0 is over-rated. Its an artificial attempt by standards bodies to make a grand entrance in the BPMS space. The fact that BPEL 2.0 is almost 100% incompatible with BPEL 1.1 speaks to the fact that these guys are essentially re-inventing the wheel every couple of years.
On another note, what do people think of Pure Play BPMS vendors ? My employer recently licensed Selcian BPMS software from a company called Selcian. One of the new entrants in this space, but seems to have a compelling product vision and good architecture. Their customer service can take some improvement though. Any one has any experience with them ?
Posted by: Ravi at March 19, 2006 01:34 PM
I agree, recently i hear about an organization requiring vendors of bpm products to support bpel for their absolutely human oriented process! in their terms of convocatory. Maybe other typical case of non well informed managers and supporting just on IT criteria, however the reason could be insufficient efforts to educate potential bpm clients about what to know when evaluating bpm products, so its common that IT knows more about BPM than other units, (of course not the rule), and when only IT knows about what a BPM product its supossed to do, the decision on which vendor to choose depends on pure technical matters. The other side (IT knowing nothing about BPM) is equally dangerous too.
Posted by: Hugo Fernando Zapata at May 7, 2006 03:39 AM
Post a comment
