Lustratus LiteBytes

I have been involved in some recent research into event-driven architecture (EDA) and its relationship to service-oriented architecture (SOA), as a result of confusion abounding over the two concepts.

Some people seem to think EDA = SOA 2.0. Others that they are already doing EDA in their SOA implementations because they are using asynchronous communications such as a JMS or IBM WebSphereMQ. This confusion is exacerbated by vendors with their own agendas – TIBCO has been banging the EDA drum for ages as the preferred way to go to solve integration problems, IBM has just held a massive event to drive its own SOA agenda, Oracle seem to be trying to straddle the two approaches, and complex event processing (CEP) vendors like Progress have their own stories about EDA.

My own analysis, together with Dr. Ronan Bradley, also of Lustratus, has concluded that as is so often the case, the problem comes down to confusion over terminology. EDA is an architecture, just like SOA. It is a way of running operations, and before anyone starts to ask whether I am on the side of SOA or EDA, the two can happily coexist. But the confusion arises when people start to use EDA as a term to refer to particular implementations rather than to the architecture itself.

In fact, we identified 3 major ways that EDA relates to SOA, and concluded that EDA may have a key role to play as SOA matures – to deal with the increasing management complexity of widescale SOA deployments through a ‘management by exception’ approach.

For those interested in reading the detailed research, Lustratus has published an Insight on the subject, available at the Lustratus site.

Steve

Related Posts

1. Clearing up the confusion over EDA, SOA, services and events (pt 1)
2. Justify BPM with a free night in Vegas?
3. SOA, governance and the Trough of Disillusionment™
4. SOA success, and what causes it
5. SOAs and ESBs

4 Responses to “EDA vs SOA”