Analysts: don't 'shoehorn' event-driven processing into SOA

Is event-driven architecture (EDA) the new SOA? My recent post on the topic kicked up some interesting commentary out in the blogosphere. Generally, analysts/bloggers feel that while more of SOA will be event-driven, EDA is a phenomenon that will evolve in its own right.

My original post was inspired by a Rich Seeley interview with John Bates, who could be considered the father of event-driven computing. Bates said that event-driven processing could "create a new physics of computing," in which data will always be on the move.

My sense is that buzzwords and acronyms have limited shelf lives, and after a few years, something new begins to move up the hype cycle. That's why it's likely that at some point in the very near future, vendors may begin to tire of calling everything 'SOA' and move on to the Next Big Thing. 'EDA' is a prime candidate for the next wave.

How significant will EDA become? Todd Biske, for one, says it may take time for many businesses to drive value from EDA. questions the value of EDA to many businesses. "I simply think event-oriented thinking is the exception, rather than the norm for most businesses," he said in a recent post. "I’m not speaking about events in the technical sense, but rather, in the business sense." Some businesses, such as the airlines and financial trading, need EDA.

Event-driven processing will be mainly about systems management and technical monitoring, and it will be a long time until we see business event-driven processing, Todd said. "To be appropriate for the business, however, this approach needs to be generating events at the business level. Look at the applications in your enterprise’s portfolio and see how many of them actually publish any sort of data on how it is being used, even if it’s not in real time." And, he added, many of the events now being captured by systems management tools "will never be exposed outside of IT, nor should they be."

UPDATE: Todd Biske just posted a clarification on his position on EDA, noting that "EDA, as a concept, has the potential to create value. EDA will fail to produce value, just as SOA will, if it is incorrectly leveraged. Everyone says SOA should begin with the business. Guess what, EDA should as well. ... I’m still of the opinion that many businesses would be at significant risk of creating ABOE-a bunch of events. This isn’t a knock on the potential value of events, it’s a knock on the readiness of the business to realize that potential. If the business isn’t thinking of themselves in a service-oriented context, they are unlikely to reach the full potential of SOA. If the business isn’t thinking of themselves in an event-driven context, they are unlikely to reach the full potential of EDA."

Ronan Bradley also weighed in on the debate, stating for the record that, no, EDA will not be the new 'SOA,” mainly because the "the level of enforced decoupling in EDA can make it awkward to shoehorn the range of problems that an enterprise architecture has to solve into a pure EDA form;" and "for those problem types that EDA is well-suited for, SOA can be extended with a bit of EDA and therefore do the job."

Rather, Ronan continues, "I see EDA being used ‘on top’ of SOA – to allow identification and processing of unusual events or combinations of events that should generate alerts or recovery processes. SAP for one is already providing some of this type of capability within its NetWeaver product set where BPEL-defined processes can be fired off in response to specified events. This type of functionality will be crucial in terms of delivering control across the SOA-based network of integrated components exchanging more information and information of greater business value."

Mark Palmer, an associate of John Bates at Apama, also responded to my original post, noting that the "distinction between EDA and SOA is still fuzzy." SOA, he writes in a new post, "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 algorithmic 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."