We were surprised to learn that IBM has decided to use the name “Business Events” for their event processing server after TIBCO has been using “BusinessEvents” for the same general software category for nearly three years. Is it a safe bet that TIBCO’s legal team is reviewing their options at this point in time?
Frankly speaking, the CEP market is now saturated with hype about all the great things CEP can do, detecting opportunities and threats in real time and supporting the decision cycle. However, in my opinion, it is time for the software vendors and analysts to move beyond the marketing hype and demonstrate real operational value with strong end user success, something seriously lacking today.
I have advocated this evolution for two years, including the notion of expanding CEP capabilities with proven techniques for event processing that have worked well long before current “Not yet CEP but called CEP” software hit the marketplace and airwaves.
For example, in my first CEP/EP presentation in New York in 1Q 2006, I presented Processing Patterns for Predictive Business and talked about how the US military has implemented high performance detection-oriented systems for many years (in the art-and-science of multisensor data fusion, MSDF), and how every day, when we sit at home (or at work or in transit), we are comforted to know we are safe from missile attacks because of what I would also call “complex event processing.” There is a very rich history of “CEP but not called CEP” behind the scenes keeping people safe and warm. (The same thing can be said with many similar examples of complex event processing in use today, but not called “CEP” by CEP software vendors.)
This is one reason, when I read the “CEP history lessons,” I am amused at how, at times, the lessons appear self-serving, not end user serving. There is so much rich event processing history and proven architectures in “CEP but not called CEP” (CEP that actually works, in practice everyday, long before it was called CEP). It continues to puzzle me that a few people the CEP/EP community continue to take the “we invented EP” view. Quite frankly, the history we read is missing most, if not all, of the history and practice of MSDF.
When we take the current CEP COTS software offerings and apply it to these working “CEP but not called CEP” applications, the folks with real operational “CEP but not called CEP” detection-oriented experience quickly cut through the hype because they are, based on their state-of-the-practice, now seeking self-learning, self-healing “real CEP type” systems. They are not so excited about first generation technologies full of promises from software vendors with only a few years of experience in solving detection-oriented problems and very few real success stories.
The same is true for advanced fraud detection and other state-of-the-art detection-oriented processing of “complex events” and situations. The state-of-the-art of complex event processing, in practice, is far beyond the first generation CEP engines on the market today.
This is one of the reasons I have agreed with the IBM folks who are calling these first generation “CEP orchestration engines” BEP engines, because that view is closer to fact than fiction. Frankly speaking again, process orchestration is much easier than complex detection with high situation detection confidence and also low false alarms.
Customers who are detection-savvy also know this, and I have blogged about a few of these meetings and customer concerns. For example, please read my blog entry about a banker who was very sceptical in a recent wealth management conference in Bangkok. I see this reaction all the time, in practice.
Complex problems are not new and they still cry out for solutions. Furthermore, many current-generation event processing solutions are already more advanced that the first generation CEP engines on the “call it CEP” market today. This is a very real inhibitor, in my opinion, to growth in the “call it CEP” software space today – and credibility may ultimately be “at risk.” Caution is advised.
Candidly speaking again, there are too many red-herring CEP-related discussions and not enough solid results given the time software vendors have been promoting CEP/EP (again, this is simply my opinion). The market is in danger of eventually losing credibility, at least in the circles I travel and complex problems I enjoy solving, because the capabilities of the (so called) CEP technologies by software vendors in the (so called) CEP space have been over sold; and, frankly speaking, I have yet to see tangible proof of “real CEP capabilities” in the road maps and plans of the current CEP software vendors. This is dissappointing.
This pill is bitter and difficult to swallow, but most of my life’s work has been advising, formulating and architecting real-time solutions for the end user (the C-level executives and the operational experts with the complex problems to solve). CEP software must evolve and there needs to be more tangible results, not more marketing hype.
I was wondering when IBM would actually jump into the event processing market.
Well, it was announced today that IBM will acquire Aptsoft, adding an event processing platform to the IBM WebSphere porfolio. IBM will also gain AptSoft’s event processing reference customers. This was a smart move by IBM.
However, AptSoft has a more advanced user interface and graphical design-time environment when compared to the Oracle/BEA/Esper platform,; so the IBM/WebSphere/AptSoft offering will propel IBM to the top of the event processing market.
Now, it’s TIBCO’s turn to acquire an event stream (time series) processing platform to compliment their process-driven event processing offering.
We all know that Oracle just bought BEA.
Personally, I would have recommended Oracle to buy TIBCO instead of BEA. TIBCO has great technology and their software stack is richer and more diverse that BEA’s. TIBCO spends a lot of development resources on their graphical user interfaces and design-time and modelling environment to make business integration very easy. TIBCO’s stockholders, like most great companies with a long history of the same executive management and management style, would greatly benefit from the acquisition.
Citigroup’s John Reilly Walsh upgraded TIBCO (TIBX) shares to Buy from Hold based on Oracle’s purchase of BEA. John thinks TIBCO, the last real middleplayer on the block, will also be purchased, and names IBM as the most likely candidate, “but adds that SAP, Hewlett-Packard (HPQ), Oracle (ORCL), Sun Microsystems (JAVA), EMC and Cisco (CSCO) all could potentially be interested.”
If Oracle bought TIBCO, a very interesting idea, that would leave Oracle the King of Integration (KOI). I don’t think HP, EMC or Cisco would want to purchase a company that is so fundamentally different than their core business.
This begs the question, should Sun buy TIBCO and challenge Oracle, now that Sun has purchased MySQL?
So the three most likely scenarios are:
- IBM buys TIBCO
- Sun buys TIBCO
- Oracle buys TIBCO
In my opinion, the most interesting scenario would be Sun following their purchase of MySQL with a purchase of TIBCO. This could create a strong competitor to Oracle.
On the other hand, Oracle would benefit from the purchase, if only a defensive mechanism against a Sun/MySQL/TIBCO triple-threat, and they would get great technology at the same time.
I would be surprised if IBM buys TIBCO, but if they do, this would also keep things interesting!
From a cultural perspective, the TIBCO culture and the Sun culture are the best match. I don’t think that the SAP or IBM cultures are very suitable for TIBCO employess. So, if you toss in the cultural perspective, Sun, cash rich and in acquisition mode, seems the most likely candidate to buy TIBCO.