[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.
Interesting points Bruce. On the announcement call with BEA and Fuego it was clear that BEA is looking to Fuego primarily to fill out human workflow capablities in its overall BPM proposition, with the existing BPEL engine focusing on integration logic automation as you surmise. So when you say ?actually, this puts [Fuego] closer to a workflow engine than a BPEL engine? â?? that?s explicitly recognised by BEA. Moreover note that the Fuego technology is positioned in the BEA stack as ?Business Service Interaction?. A not-particulary-snappy term, but it does kind-of indicate, again, that Fuego?s role is about interaction between people and automated processes.
I do think you make an interesting point re: BEA?s buy-rather-than-build approach to getting a BPMS stack together. My feeling is that it was partly a time-to-market decision; and also that it reflects BEA?s perspective on the world, which is much more focused on SOA than it is on BPM. BPEL orchestrations aggregate services, yes; but they also form the guts of higher-level ?business services? in BEA?s world view. Those higher level services are consumed by technology from Plumtree and now Fuego.
We?ve carried out an indepth assessment of Aqualogic (now a bit out of date of course
which you can see if you like here.
BEA also needed some ?street cred? to play in the BPM world, and the Fuego acquisition gives them that.
If Fuego is a BPMS, what?s the definition of a BPMS Bruce?
I expected some disagreement on this post, but not on the point that FuegoBPM is a BPMS, which I typically describe as an integrated suite of components that automate, integreate, and optimize a business process. You can see further elaboration of this in my 2006 BPMS Report, available for free from BPM Institute, as well as a detailed description of FuegoBPM. True, FuegoBPM is not BPEL-based, so it falls outside of Ismael?s ?XPDL exclusion zone? for BPM 2.0, but I have previously noted my discomfort with his BPEL requirement.
What part of Fuego suggests to you that it is not a BPMS?