More on the acquisition of Apama by Software AG

One of the interesting questions about the acquisition of Apama by Software AG is what is the strategy of Software AG going forward in the event processing area, given that it has already acquired in the past an event processing technology from RTM which is named "WebMethods Business Events".

An article in COMPUTERWORLD attempts to shed light on this  issue, citing Stephen Ried from Forrester: "Apama and WebMethods Business Events complement each other; While the former RTM is really lightweight and can be embedded in many Software AG products to provide basic event communication capabilities, the Apama product is for those customers who like a dedicated business event management platform.".

According to this - there are two major use patterns.  Event processing as components embedded inside other products,  I have written before about the component approach to event processing, and indeed not every product needs all the event processing capabilities.  On the other hand, a full fledged event processing application require an event processing platform, optimized for performance metrics.

On "CEP and Big Data 2" - comments on Philip Howard's observations.

Philip Howard from Bloor Research has posted some observations on his Blog entitled "CEP and Big Data 2".   Here are some comments (actually nothing new - just summarizing things I have written about before).
Philip deals with three issues:

• whether the name CEP is appropriate or should be changed? 
• who should be credited as the pioneer of this area?   
• whether CEP implies real-time processing?  
•  who are the CEP big data platforms?

Here are summary of my views on each of this topics.

The name "Complex Event Processing"

Exactly four years ago I posted on this Blog an explanation about - "why I prefer to use the name event processing without any prefix, infix or suffix".   My particular dislike of the term "complex event processing" stems from the ambiguity in the name - some people (including David Luckham who coined this term) view it as processing of complex events, some interpret it as complex processing of events, and then debate of when something is complex enough, and what type of complexity is needed  to qualify as CEP.  Moreover some of the vendors use this term for products that are neither of the two options.   I think that two words is enough for the name of a discipline, examples: information retrieval, machine learning, image processing and much more....  Thus, from my point of view the term "event processing" subsumes all other terms like complex event processing, business event processing, event stream processing and more.

Who gets the pioneering credit

Philip as a good UK patriot wonders why the Wikipedia value about Wikipedia and other sources gives credit to David Luckham and forget the Apama work that came from Cambridge UK.    Looking at Wikipedia, it has one mention of David, as well as other references (like our EPIA book). It indeed does not mention Apama or any paper by John Bates, but being a Wikipedia, anybody can suggest additions.   

David Luckham had major influence on this area, since he was the first one who published a full book and exposed the young area to the general public.    An article in IEEE Computer, published in 2009,  made some investigation of the history of that area and determined that in the 1990-ies there were four parallel projects that can be classified as starting points in this area:  David Luckham's project in Stanford,  John Bates' project in Cambridge (UK, not Boston), Mani Chandy in Cal Tech,  and our Amit project in IBM Haifa Research Lab.    I share Philip's view that John Bates should have full credit as one of the pioneers, and still view David Luckham as the "elder statesman" of the community.

Is CEP necessarily associated with real-time?

I have written several times about this topic, last time in response to Chris Carlson, to whom Philip also responds.   There is some abuse of the term real-time in the industry, while its meaning is "within time constraints", many people interpret it as "with very low latency".   This is not the same,  anyway, event processing is a functionality with applications that require very low latency, applications which require to react within real-time constraints (which can be: 2 hours), some require both, and some require none.

Who are the CEP big data platforms?

I have taken upon myself the limitation not to state opinions on commercial products within this Blog  - leaving  it to analysts.   Thus will make one comment.  There is distinction between two types of software entities - 

which is sometimes confused in the language used by people.

• Event Processing Platform is a software that enables the creation of event processing network, handle the routing of events among agents, management, and other common infrastructure issues.
• Event Processing Engine is a software that enables the creation of the actual function - in the EPN term implementing agents.

This is similar to the difference between an application server and a single component (programming in the small vs. programming in the large).    Some of the available platforms for "event processing for big data" provide the first one -- it gives infrastructure, but not implementing any type of functionality, but enabling developers to create their own functionality, thus they don't do full-fledged event processing.   Seems that many people classify both under the same classification  (of course there are products that do both). 

On consolidation and pure play in the EP market

Marc Adler returned to the Blogland this week to claim, among other things that the fact that the list of pure-play event processing platform vendors is being reduced, is sad. The fact that there have been several acquisitions of "pure play" vendors recently is true, with the acquisition of Aleri by Sybase earlier this year, and the recent acquisition of RTM by Software AG. If you are interested in the genealogy, Paul Vincent is keep documenting it. I have traced some of the IBM acquisitions and realize that merges are sometimes tough from organizational culture point of view and sometimes there is a need to change direction in a not easy fashion, as shown in the picture above, so it might be sad for some individual people, but not necessarily bad from the industry point of view.

However, the fact that the pure play vendors are being acquired has another side to the coin, which means that the big or medium software vendors are buying them. This is a sign that event processing is getting to be part of the main stream of the enterprise computing, and is part of growing up of this area. This has also happened before in other areas, and was predicted several years ago by analysts to happen in the event processing area.

In fact, now most of the major players in enterprise software area : IBM, Microsoft, Oracle, TIBCO, Progress Software, Sybase and Software AG - have now an event processing platform as part of their enterprise computing offering.

This is an indication that all these vendors realize that event processing is required part of their enterprise applications, and that event processing is not really stand-alone but it is increasingly getting consumed as part of larger play, and getting to further areas and industries in addition to the early adopters of capital market trading applications.

There may still be a role for pure play event processing products, especially in various niches that are not being properly handled by the current products. Some of them may even develop event-driven enterprise computing platform, and join the medium companies, it happened before, but it is not easy.

While the bigger companies advance the projects at their own paste, the smaller companies as well as the research community sometimes have roles of catalysts to advance the area. We'll discuss the future of the event processing area in depth in the Dagstuhl seminar planned to start in 2 weeks. More about it - later.