The marketing folks and their friends are buzzing with hype. Well intended, they want to convince the marketplace that EDA is really a type of SOA, or that EDA is an evolution of SOA. Unfortunately for the end user, they are mostly off target.

On this topic, I tend to agree with Dr. Mani Chandi.  Mani gave an excellent talk at the recent Gartner Event Processing Symposium titled, Evaluating Costs and Benefits of Event-Driven Applications. In his keynote presentation, Dr. Chandi did not make any marketing statements about EDA (and events) somehow being the “magic” missing from SOA. Instead, he focused his keynote on the differences between SOA (request-reply) and EDA (proactive event push) and how to determine the best architectural pattern (EDA, SOA or both) when designing an application.

I was really pleased to listen to a CEP presentation based on sound design principles and not on the “EDA piggybacks on SOA market share” story to promote CEP and EDA. Most, if not all, good network engineers know that orchestrated request-reply is quite different than asynchronous event processing. Only marketing folks would convince us otherwise, hoping to somehow get the CEP “camel’s nose” under the “SOA tent”!

Baa Humbug!

There is a downside (more than one!) to trying to put the CEP nose under the SOA tent. First of all, SOA, while a great idea, suffers from over hype and the increasing weight of it’s less-than-successful status, even after years of over marketing. Secondly, EDA and CEP actually have a chance of success. SOA has seen such a lack of progress that the analysts continue to redefine it, so it will eventually fit somewhere!

If you fly high enough, the snow bears, the igloos and the snow all look the same – and we are seeing folks flying snow blind in the EDA and SOA space.

Network engineers have been dealing with events and EDA in the form of SNMP traps for many years, and SOA in the form of polling devices for information for the same amount of time. Experienced engineers don’t debate which is better, SNMP traps or SNMP polling, they use the appropriate pattern based on solid design principals and engineering tradeoffs, just like Dr. Chandi discussed in his recent presentation.

EDA is not SOA. SOA is not EDA.


Let’s don’t send CEP on an ill-fated flight to the future of event processing with a large SOA stone around it’s neck.


One Response to EDA is EDA. SOA is SOA.

  1. […] and leading event processing community builder Opher Etzion, added to the chorus of my recent post, EDA is EDA. SOA is SOA. with More on EDA is EDA and SOA is SOA.   Opher correctly elaborates that event processing can be […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: