Business Transformation in Action

I know it's still early in the life of service-oriented architecture, and most companies are just starting to wade into the SOA waters, but it's always helpful to look what is coming in the next wave. Two compelling write-ups, one by Jack van Hoof and the other by Brenda Michelson (a colleague here at ebizQ), provide a very detailed picture on what to expect next in the wake of SOA -- Event Driven Architecture, or EDA.

Some industry mavens, in an attempt to start capitalizing on EDA, gave it the stupid label of "SOA 2.0." Thankfully, the SOA 2.0 moniker was quickly shot down and put out of its misery.

Jack van Hoof, who is enterprise integration architect with Dutch Railways, has mapped out what event-driven architecture will mean to enterprises. van Hoof explains that EDA delivers the loose coupling that is only promised -- but not delivered -- by SOA. "EDA is not a synchronous command-and-control type of pattern, but just the contrary: an asynchronous publish-and-subscribe type of pattern. The publisher is completely unaware of the subscriber and vice versa; components are loosely coupled in the sense that they only share the semantics of the message."

There are roles for both SOA and EDA, van Hoof says. "If you are seeking to support strong cohesion in the business processes, situations where all process steps are under one control, SOA is the way to go," he says. "If you are seeking to support independence between business process steps, EDA is the way to go."

Brenda Michelson, principal at Elemental Links, also identified, at a very early stage, EDA as not just the next evolution for SOA, but an architecture that can effectively work in conjunction with SOA. Brenda noted that as we move forward, "the most viable, agile architectures will be comprised of a blend of architecture strategies, including (but not limited to) service-oriented architecture, event-driven architecture, process-based architecture, federated information, enterprise integration and open source adoption. How you blend, depends on your business."

Brenda provides an outline of how the interaction between EDA and SOA is occurring: First, "the occurrence of an event (a notable thing that happens inside or outside your business) can trigger the invocation of one or many services. Those services may perform simple functions, or entire business processes. This interaction between events and services is commonly referred to as event-driven SOA."

Next, "a service may generate an event. The event may signify a problem or impending problem, an opportunity, a threshold, or a deviation. Upon generation, the event is immediately disseminated to all interested parties (human or automated). The interested parties evaluate the event, and optionally take action. The event-driven action may include the invocation of a service, the triggering of a business process, and/or further information publication/syndication. In this interaction, the service is purely one of many event sources in a broader event-driven architecture. A broader event-driven architecture stretches beyond event-driven SOA, to include real-time information flow and analysis, and complex event processing."