Is EDA the "new" SOA?

This article (Is EDA the ‘new’ SOA? by ZDNet's Joe McKendrick) was published this week, and is a response to the article EDA + CEP:  A New Physics of Computing by Rich Seeley, which was the result of a discussion with Rich, John and I. 

The idea that complex event processing is a new physics of computing is a concept we have discussed for years with Apama.  The fundamental idea was captured by Rich when quoted John Bates:

Where in the traditional system the "data is static and the queries are dynamic," he said. "In event-based systems it's different. The rules that you're using to monitor the data and take action are fairly static, and it's the data that's dynamic. The data is continuously changing. So you have to structure your software to take into account that paradigm shift."

The article, and the idea behind it, seems to have touched a nerve about suggesting that EDA is "the next big thing."  True this is bold claim, and one that needs to be considered carefully.  But the fact is that CEP is a fundamentally different computing model, as John describes above.  It has a unique technical capability to identify patterns of events, and apply temporal, or spatial, constraints to streaming data, at tremendous scale and low latency.  No other technology has this capability, and it's why CEP is generating so much excitement.

And CEP's adoption in some classes of applications, like algorithmic trading, illustrates that CEP has proven it has a major role to play in enterprise IT architecture.  We're not making these claims based on pipe dreams and "what if" scenarios - CEP is proven:  ABN Amro, JP Morgan, Deutsche Bank, HG Trading, Koscom (Korean Stock Exchange), Finamex (In Mexico) all have been public about their application of CEP to algorithmic trading, and, when that many large firms are public about their use of a particular type of software, you know that it's just the tip of the iceberg.   Even Microsoft has selected Apama as part of their MiFID solution suite, illustrating yet another use case for the technology.

As for IT architecture, the distinction between EDA and SOA is still fuzzy.  SOA is designed to support an event-driven interaction between services, but says nothing about how to process those events - that's what CEP does.  As a case in point, algorithmic trading systems are event driven.  Many of algo trading applications don't use SOA;  some do.   Therefore CEP is agnostic to the presence of SOA, although, if it's in place, great. 

Does that mean EDA will "replace" SOA?  Certainly not. 

Does it mean EDA and SOA are complementary?  Yes. 

Does it mean that EDA is an "advanced" form of SOA?  I don't think so.

As for the size of this market, we'll leave declarations of "the next big thing" to the analysts that can do some sizing and crystal-ball gazing.  They are starting to talk that way, which is flattering.  But for now, the job at hand is to continue to identify and solve real problems with CEP that are difficult to solve without CEP, and then educate the market about those applications, which is one reason we're starting to blog.  The big issue is how many applications out there really NEED CEP, and how many are just fine using traditional database oriented approaches.  From our perspective, there are a ton of applications using Apama for CEP, and, if our growth rate continue, the market will be very big.  If the market becomes big, than we're happy.  If it doesn't become big, we're still having fun.  Stay tuned.