SOA and EDA: Separate Architectures or the Same?

SOA and EDA: Separate Architectures or the Same? - SOA and EDA, and the Problems They Solve

For several years companies have been trying to solve two strategic problems with middleware. The first is how to automate and streamline business processes that span multiple divisions and applications. The second is how to detect and react to specific business events or problems as they happen, and to automate more intelligent responses.

These two problems are really part of the same problem: how to automate your business. Your business consists of events, tasks, and processes. When automating your processes with software, business events often trigger business processes. Business processes often generate business events.

SOA service oriented architecture is now widely recognized as a solution to the first problem and an approach that delivers new functionality faster with greater productivity and greater flexibility to accommodate changes. EDA has been around for a while but is not widely known. It’s now becoming more widely used to solve the second problem of detecting and reacting to events.

The bad news is some service oriented architecture SOA technologies don’t support EDA, so you could end up having to spend more money on a second architecture to gain EDA capabilities. And then every time you wanted to automate or change part of your business, you’d need to change two different systems.

The good news is service oriented architecture SOA and EDA can be part of the same architecture. In fact, an “advanced SOA” or “event-driven SOA service oriented architecture” is an evolution of SOA service oriented architecture that has already been implemented by several companies. Following the very principles of SOA service oriented architecture, these companies have been able to incrementally add on eventdriven technologies as needed.