Making events, EDA, CEP, and SOA interesting

I’m back from my vacation and have a few topics queued up for some blog entries. The first one that I wanted to cover was the topic of events and SOA. The relationship between EDA, CEP, and SOA is one that pops up on a regular basis, however, in my opinion, it still hasn’t reached a sustained level of interest. There was a big peak some time ago when Oracle and Gartner used the ill-fated moniker SOA 2.0 to represent the combination of SOA and EDA, but once the backlash died down, the discussion around events faded back into the background again. Thankfully, it hasn’t gone away completely. One of the more recent publications on the topic came from Rich Seeley with in this article. He stated that, “The relationship of complex event processing (CEP) to service-oriented architecture (SOA) remains, in a word, complex.” Why is the case?

The article included quotes from Jason Bloomberg of ZapThink comparing EDA to SOA. While I usually agree with the ZapThink guys, I disagree with Jason’s quote that there is no particular reason to distinguish SOA from EDA. Jason points out that all service messages are essentially software events which “contain all the information you’d ever want about the behavior and state of your business.” At a technical level, there’s nothing wrong with Jason’s statement. Where there are differences, however, is in the intent of the message. A message associated with an interaction between a service consumer and a service provider is either a request for the provider to do something or a response from the provider back to that consumer. The fundamental difference, in my opinion, is that these messages are directed at a specific destination. While you can certainly intercept these messages and use them for other purposes (and I’d argue that doing for so for business intelligence analysis reasons is a good thing), there’s a risk involved in doing this because now there are unintended side effects. In contrast, events have no requirement to be directed at any particular destination, typically using a publish-subscribe approach for distribution.

Let me get back to the question of complexity. I will admit that discussions like paragraph above are part of the reason that people find EDA and CEP hard to grasp. Often times, discussion in the blogosphere will focus on areas of disagreement, losing sight of the areas of agreement. I’d argue that if you talked to Jason and myself on the relationship between SOA and EDA, 80% of what you’d hear would be consistent. So, just because Rich Seeley received a number of different takes on SOA, CEP, and EDA, doesn’t mean it’s complex.The right question we should be tackling is how to make events, EDA, and CEP more interesting, building on the natural relationship to SOA. As I’ve previously stated in my uptake of CEP post, I don’t think that most organizations are ready for CEP and EDA yet. The debates that are occurring in the blogosphere and press are being made by people that have a vested interest (typically vendors, but you could argue that niche analyst firms do as well) in creating “buzz” about the topic. As a corporate practitioner, I have no such vested interest except where it makes business sense for my employer. So, I need to ask the question on how to make CEP and EDA relevant (and interesting) to the business. The challenge with it, and why it was important that I wrote about my difference of opinion with Jason of ZapThink, is that events, on their own, don’t do anything. A service performs some function. It does something. The business can grasp this. An event is just a nugget of information. A collection of events presented to business stakeholders are not going to be very meaningful until you start doing something with them. As a comparison, let’s look at baseball. If you watch or listen to a baseball game, you’ll get a barrage of statistics. Are they useful? Some managers, like Tony LaRussa of my hometown St. Louis Cardinals, have always made extensive use of the data. Has it made him more successful? We’ll probably never know. We can certainly say that he’s been a successful manager, but can we tie it specifically to his use of event capture and analysis? There are probably other managers or baseball pundits that would argue that the cost of collection and analysis isn’t worth it.

The same thing holds true for EDA and CEP. There is a cost associated with the generation of events. There is a cost associated with the analysis of events. What’s missing is the benefit. To get this, we need to do analysis of the business and come up with suitable justification. For a domain such as risk analytics associated with securities trading, the justification is there. Complex analysis of the trading and news events occurring in real time can result in better timed market activities with millions of dollars in potential benefits. In other domains, it may not be as crystal clear. If an organization has a stated goal of better knowledge of their customers, it would seem that event capture and analysis could assist in this, but how do we quantify the potential benefits? Just as with SOA, I think a key to this is selecting an appropriate proof-of-concept and then pilot. Some event capture and analysis can be done without purchasing any new infrastructure. There’s nothing wrong with performing analysis on a week’s worth of data that takes another week to complete if the end result is valuable, business relevant information. As Jason suggests, you can use service messages as your starting point for analysis, so if you’ve got audit logs of them, you only then need an analysis engine. Every organization already has many of these, and I’m not talking about a BI system. I’m talking about employees. While we may not capture all of the correlations, most of us are pretty good at spotting trends. It’s simply a matter of having someone look at the information that’s already there. Guess what that activity is? It’s business analysis. Do the analysis, understand the business, create the business case, and go make things better.

3 Responses to “Making events, EDA, CEP, and SOA interesting”

  • Rob Eamon:

    IMO, SOA and EDA are independent, orthogonal notions. One can design and implement an EDA-based system without any thought of using SO principles. MOM and EAI tools of yesteryear did this with varying degrees of success.

    One could argue, I suppose, that all service interactions are “events.” I think that’s a stretch. “Get data for customer XYZ” doesn’t seem like an event. “Customer XYZ was updated” does.

    The interesting thing in EDA is determining what are the meaningful events.

    I attended a META Group conference in ’98 or ’99. An example they used was an insurance company. They found that the more quickly they settled a claim, the lower the payout was, on average. So the key for them was identifying the key event. Was it the claim submission? No, it was when the car hit the tree. Why? Because the claim may not be made for some time after the accident. So they hooked into the OnStar systems to know when the accident occurred, allowing them to be more proactive in processing the claim and therefore being more cost-effective.

    EDA is not a subset of SOA. An architecture and resulting systems may include both sets of principles.

    CEP, in my mind, is best suited as an application notion. That app is EDA driven. It *might* be SOA driven. CEP isn’t an architecture thing, IMO. It’s similar in concept to OLAP and DW tools.

    Apologies for the lengthy comment. I should probably start my own blog!

  • […] Todd Biske: Outside the Box » Blog Archive » Making events, EDA, CEP, and SOA interesting (tags: eda soa cep) […]

  • Todd, I think to some extent it depends on your business – and that is maybe what I can take away from the original post. For me the crucial consideration lies in the autonmoy of event processors. When an “interesting” event occurs, the levels of interest will vary. If there are many interested parties, and the interested parties are autonomous, you had better have an architecture that allows for this. If the above hold true, and even if the interested parties are autonomous, something (e.g. business policy) demands that some kinds of failure can be tolerated and some not, then you need to look across the interested parties. Whose responsibility is that? Can’t be the initial publisher”. Can’t be the autonomous interested parties. Must be something else. looks like CEP to the rescue, perhaps.

Leave a Reply


This blog represents my own personal views, and not those of my employer or any third party. Any use of the material in articles, whitepapers, blogs, etc. must be attributed to me alone without any reference to my employer. Use of my employers name is NOT authorized.