Standards. Acquisitions. Lunacy.
As seems often to be the case, a few vendors and analysts seem to be having issues understanding an acquisition strategy. This time it the controversy surrounds BEA and BPM vendor Fuego......
March 9, 2006
As seems often to be the case, a few vendors and analysts seem to be having issues understanding an acquisition strategy. This time it the controversy surrounds BEA and BPM vendor Fuego... Anne Mannes over at the Burton Group doesn't have a whole lot to say on the subject. Her most quotable quote on the acquisition seems to point out that she's confused by BEA's strategy in general and that the acquisition of Fuego just muddies the water for her.
Well let's see...ya think it might be because Fuego technology is already living under the covers of BEA's AquaLogic Interaction Process, BEA's BPM solution? BEA's strategy is simple; buy the OEM partner before someone else does and capitalize upon its already strong standards supporting technology by tightly integrating it into its own product until the lines between them are so blurred you can't tell where one ends and the other starts.
It's a fairly standard strategy to purchase an OEM partner to be able to fully exploit the technology and, perhaps, to gain its customer base.
Competitor Cape Clear would disagree on the point that Fuego is standards based and further blasted the acquisition in this blog entry by CEO Annrai O'Toole, saying, "the BPM market is founded on legacy, proprietary technologies".
Really? So BPEL isn't open standards based? Granted, it isn't a standard yet, but it's certainly headed that way. And UML, which Fuego supports, that isn't standards based? Quick, someone tell OMG, I'm sure they had no idea. And what about its support of XPDL?And I won't even remind Cape Clear (and others) that BPM provider Computer Associates presents its business rules solely as Web Services (the hallmark of a good SOA citizen) and Oracle's BPM solution is completely open standards based and also bares its wares through Web Services, not to mention the ability of nearly every BPM vendor in the market to consume Web services as part of its orchestration process.
Now what part of that isn't SOA or standards-based? Wait, let me guess. We're going to quibble over the use of the term "founded". Look, BPM is just as standards based as, say, an ESB. Same concept, higher layer in the stack. Same standards. And the foundations of ESBs were laid down by EAI and message-oriented middleware like MQ Series and TIBCO RV. Proprietary, non-standard integration and messaging technologies. If BPM is proprietary, then by that definition, so are ESBs.
You May Also Like