Comments on: BEA Jumps into BPMS http://itredux.com/2006/03/01/bea-jumps-into-bpms/ New Rules for a New IT World Mon, 08 Mar 2010 01:42:55 -0500 http://wordpress.org/?v=2.8 hourly 1 By: Bruce Silver http://itredux.com/2006/03/01/bea-jumps-into-bpms/comment-page-1/#comment-469 Bruce Silver Mon, 06 Mar 2006 15:53:24 +0000 http://itredux.com/blog/2006/03/01/bea-jumps-into-bpms/#comment-469 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 <a href="http://www.bpminstitute.org/bpmsreport.html" rel="nofollow">2006 BPMS Report</a>, 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? 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?

]]> By: Howard Smith http://itredux.com/2006/03/01/bea-jumps-into-bpms/comment-page-1/#comment-461 Howard Smith Mon, 06 Mar 2006 12:54:09 +0000 http://itredux.com/blog/2006/03/01/bea-jumps-into-bpms/#comment-461 If Fuego is a BPMS, what's the definition of a BPMS Bruce? If Fuego is a BPMS, what’s the definition of a BPMS Bruce?

]]> By: Sandy Kemsley http://itredux.com/2006/03/01/bea-jumps-into-bpms/comment-page-1/#comment-445 Sandy Kemsley Fri, 03 Mar 2006 14:55:03 +0000 http://itredux.com/blog/2006/03/01/bea-jumps-into-bpms/#comment-445 BEA also needed some "street cred" to play in the BPM world, and the Fuego acquisition gives them that. BEA also needed some “street cred” to play in the BPM world, and the Fuego acquisition gives them that.

]]> By: Neil Ward-Dutton http://itredux.com/2006/03/01/bea-jumps-into-bpms/comment-page-1/#comment-444 Neil Ward-Dutton Fri, 03 Mar 2006 10:18:22 +0000 http://itredux.com/blog/2006/03/01/bea-jumps-into-bpms/#comment-444 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 <a href="http://www.mwdadvisors.com/articles/index.php?m=T" rel="nofollow">here</a>. 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.

]]>