BEA Jumps into BPMS
[Originally posted on IT|Redux]
BEA’s acquisition of Fuego this week is a welcome validation of the BPMS market, but what a surprising way to go about it! Probably the strangest BPM acquisition since TIBCO spent big bucks on a workflow engine that couldn’t even receive a JMS message.
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? – and you could argue it’s not even service orchestration, at least in the way most in the BPMS community understand it. 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. What’s even stranger is that BEA already has what looks to be a fine BPEL engine and tool in WebLogic Integration 8.1. OK, that’s strictly J2EE, and AquaLogic is supposedly “platform-independent” (can that be right?), but still… I’ve heard (but don’t actually know) that the AquaLogic ESB is really WLI.
If BEA was anxious for a quick entry into the BPMS magic quadrant, this was probably a cheaper and faster way to check off all the features than building out WLI. 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.
4 comments March 1st, 2006
