I attended the Event Processing Summit in Orlando today and will summarize my understanding of event-driven architecture (EDA) and how it is different from service-oriented architecture (SOA).
EDA is not a new concept. Like BPM and SOA, EDA has evolved to the point where it is mainstream enough for vendors to make a profit from it. Vendors have been aggressively working on being the first to market with an easy to use and open platform for customers to add to their stack.
So how is EDA different from SOA? SOA is a request/respond type architecture. The users request information from the system and the system produces a response. EDA is a sense/respond type architecture where the user is alerted or notified of some condition(s) that the system predicted or discovered. Think of EDA as a tool to teach the computer how to respond to events.
To get a better understanding of these terms, let's look at the following pictures. The first picture depicts the classic stovepipe or silo type architecture where applications do not integrate well with each other.
In this example, a customer calls a customer service representative (CSR) and requests information that spans multiple systems. The CSR goes into each system and manually collects the various data points. Once finished, the CSR responds back to the customer. This type of architecture is inefficient, error prone, and time consuming.
Enter SOA. SOA allows you to build composite applications while leveraging years of investments in your legacy applications.
In this example, the CSR was completely eliminated and the customer was given a self service portal that has a single view into the various legacy systems. To keep the chart simple, I did not display the service bus or BPM workflow. The idea here is the customer has a single view into all of the data that is relevant without dealing with the complexity of interfacing with various different backend systems. This is SOA's sweet spot. You can see from the picture that the composite application is made up of data from various legacy systems both internal and external (Salesforce. com) and across different platforms. SOA, like the old silo architectures, is also request/respond. Wouldn't it be nice if we could anticipate our customers' needs and notify them in advance of events that took place or conditions that require their attention?
Enter EDA. EDA creates a composite view of data from your legacy systems and analyzes the data to identify patterns or trends.
In this example, the EDA system is constantly evaluating data that is being pulled into a composite view in real time. Once certain events are identified based on some set of rules, the EDA system alerts or notifies the customer. This is extremely efficient, timely, and very cost effective. This is proactive computing.
EDA can be implemented stand alone without SOA, but it is very complimentary to SOA. EDA can leverage your existing SOA assets (BPM, ESB, Repository, Governance model, BAM, etc.).
I like to think of EDA as Proactive SOA. It is a natural extension of SOA. If you are implementing SOA today, keep an eye on EDA. Once you reach a decent level of SOA maturity, EDA will take your SOA to the next level.
I'll be back tomorrow to summarize more great insights from the Events Processing summit.
