Ronan Bradley provided some of his insights on a recent post I made over at ZDNet on whether EDA is the New SOA.
My original post in turn 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." He said that in the present paradigm, "data is static, and queries are dynamic." In event-driven SOA, however, data is constantly on the move. "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."
I also quoted a very well-stated analysis of the event-driven architecture phenomenon by ebizQ colleague Brenda Michelsen. Brenda observed that EDA is not the next evolution for SOA, but an architecture that can effectively work in conjunction with SOA as part of a "business driven architecture."
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.
Ronan, however, says 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 Bates at Apama, notes 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."
Leave a comment