On CEP Maturity and the Gartner Hype Cycle
In reply to Mark Palmer’s rebuttal, What Does it Mean to be Mature?, the figure below illustrates the popular Gartner Hype Cycle. You can click on the illustration to get a clearer image.
In context to the Gartner Hype Cycle, CEP is closer to the “Technology Trigger” phase than anywhere else in the hype cycle. CEP has not yet reached the “Peak of Inflated Expectations”, but is inching closer and closer.
In addition, as a correlating reference point, if you look at a recent Gartner Hype Cycle that covers EDA, for example, you will find that EDA (Event Driven Architecture) is at a similar phase, the “Technology Trigger” phase.
Filed under: CEP News and Events, CEP Terminology, Complex Event Processing, Development and Evaluation, EDA, Event Processing, Event-Driven Architecture
Tim - CEP is not on the Gartner hype cycle (EDA is). Not clear on your point?
Hi Mark,
First of all, most would agree that CEP is even less mature than EDA, so if EDA is not mature, CEP is even less mature.\
Second, you are creating “Mark Palmer” metrics for CEP maturity.
We disagree with you, and I posted a recent Gartner Hype Cycle that shows EDA at the first stage of the market cycle, far from maturity.
Gartner considers CEP so immature, they don’t even put it on the charts so far!
If they did, CEP would still lag EDA!!
Cheers and Best Regards, Tim
I think it would be helpful to post the definition of Event Driven Architecture, and then explain exactly how Complex Event Processing expands on that.
Yes, that would be helpful, but I know the Gartner guys pretty well who created this, and the point I think they would make is that they view CEP as part of EDA, so I don’t think they would say that “CEP is less mature than EDA” - EDA is a broader concept than CEP to Gartner.
Hi Mark,
By your logic, CEP is a part of EDA and, by Gartner’s analysis, EDA is in the “Technology Trigger” phase of the Gartner Hype Cycle.
Therefore, it follows that CEP is also in the “Technology Trigger” phase as well.
There are only a small handful of people who will argue that stream processing engines that perform continue queries across sliding time windows of events represent the entire CEP space.
When overall functionality is simple and incomplete, many people call this “immature”.
Saying a subfunction of a technology domain “works as advertised” does not define maturity.
This is simply marketing hype. That is precisely why Gartner calls it a “Hype Cycle” … LOL
Yours faithfully, Tim
[...] review this post, On CEP Maturity and the Gartner Hype Cycle, and the various stages of the Gartner Hype Cycle and answer the following survey [...]
There is just one issue with this Hype Cycle form Gartner - most of the technologies and concepts do not enter it.
I’m not sure if this is true for CEP or EDA too but I am developing such a system for 3 years now and there are some signs that it may be.
I have seen implementations of EDA which takes it way beyond Technology trigger phase, but there may be only a few as it needs the proper infrastructure to be in place. It would be like having an airplane without the runway. Runways are little sparse at this point of time.
EDA as Mark pointed is a broader concept and for CEP to happen EDA should be in place. CEP success also depends on maturity of other technologies like BPM,BI/BRMS, which I think will help to properly align the needs to be CEP’d.
I particularly like this article which shows the relationships, between all these “acronyms”
http://pvhaley.wordpress.com/2008/02/29/cep-crossing-the-chasm-into-bpm-by-way-of-brms/
Anil
Hi Anil,
First of all, good comment. Thanks for visiting.
Second, CEP is not EDA and EDA is not CEP, we do not require one for the other, as Opher Etzion reminds us quite often.
Regarding BI, I agree that if CEP software used the same sophistication of complex analytics that most credible BI tools require, CEP would be much more mature.
The fact of the matter is that you can’t use any of the current self-describec rule-based CEP engines to replace the work of a mature BI product when it comes to statistical data mining.
BPM, on the otherhand, is generally rule-based workful, complimentary to detection-oriented CEP, because good detection leads to efficient BPM workflow process. We call this, SENSE and RESPOND. The detection is the SENSE and the BPM is the RESPONSE. The issues are not in the ability to manage workflow. The issues are in the ability to accurately detect meaningful situations, the core premise of CEP.
BRMS, on the other hand, is more about rules management and rules are only a small subset of the analytics required for CEP-ish detection.
There is a lot of good discussion going on here.
Thanks for your comments. Don’t forgot to vote in the current poll on CEP and the Gartner Hype Cycle.
Yours sincerely, Tim
EDA and CEP must be understood as 2 different areas. EDA is an architecture pattern for enterprise applications. The components are loosely coupled by the use of events. In its strict sense, this is more an architecture pattern than an algorithm.
CEP, on the other hand, targets at the event processing and pattern recognition level. For me, it’s the research for the right algorithm to use to recognize the situations. Pattern recognition, event correlation are all good characterizations for CEP. Back 15 years ago, the alarm correlation in the telecom area was done using production rules (it is still the case), and this perfectly falls into the CEP area.
In fact, EDA comes after CEP, but the CEP at that period was not explicitly called CEP. The nature of their respective study is not the same, one is at the architecture and middleware level, the other is at the algorithm side. As both are concerned by events, it seems that people more or less implicitly include CEP in EDA, mix the two and introduce confusion. Why not. But it’s important to understand that CEP (on its algorithm side) could mature on its way without being worried about the event transportation layer.
As a system, CEP needs input events for processing. If EDA is considered as the only way to bring and transport events to the CEP systems, then of course CEP won’t become successful without the prior success of EDA. But in my understanding, CEP targets some real-time or close to real-time applications, and the event transport layer in those applications are the most often ad-hoc and over-optimized. I fear that EDA has the same kind of performance goal.
Another distinction needs to be made. CEP is more general than ESP (event stream processing), characterized by an EPL for data aggregation with notifications. Even on the market most of the CEP vendors provide EPL languages, CEP has the vocation to cover more than that. The “more” part is not well defined, at least it should include the event correlation, and correlation is not just data aggregation.
The ESP part of CEP could be considered as quite mature. There are so many EPL languages, and tuning has been made on the runtime side. It seems also that some applications based on ESP have proved to work. But the “more” part of CEP over ESP is far from mature. It is often described that CEP could use several technologies, such as statistical models, Bayesian network, time series, rules, etc. I agree that there are a few systems using rules. But where are the others?
Sincerely,
Changhai Ke
[...] On CEP Maturity and the Gartner Hype Cycle [...]