Is your SOA really SEA?

In reading through ZapThink's latest post regarding the "Great ESB Controversy of 2008" it occurred to me that it is quite possible, and probably likely, that the issue of ESB use primarily revolves around whether you're doing SEA or SOA.

Yes, I know. You've never heard of "SEA" before. That's because I just made it up to describe the difference between a service-enabled architecture and a service-oriented architecture. And there is a difference.

A SOA (service oriented architecture) implies that an architecture has been designed around the concept of services. A SEA (service enabled architecture) implies that an existing architecture has been service enabled through various service-enablement products such as, you guessed it, an ESB.

These are two very different architectures, with SEA being focused primarily on reuse of existing applications as opposed to reusing new services. That being the case, it is likely that one of the primary goals of organizations whose idea of SOA is really SEA is that of integration, in which case it makes perfect sense that an ESB would be an integral component of such an organization's service strategy. An ESB provides not only service enablement capabilities, but usually also provides an easy mechanism for transforming data and messages such as XSLT and a graphical mapping tool, which makes integration a whole lot less painful than it has been in the past.

Obviously SOA and SEA can be used concurrently and in conjunction with one another; they aren't mutually exclusive. The interoperability of services makes that a breeze and is one of the technical benefits of implementing a standards-based service focused architecture, whether that's a SEA or a SOA.

But it might help to make the distinction because they do require a different thought process to architect and have different implementation problems associated with them. There are benefits to a pure SOA in streamlining processes, removing redundancies in application responsibilities, and introducing consistency into the applications that run the business. SEA doesn't necessarily bring those benefits to the table because you aren't going through the process of evaluating all the application and data sources and determining sources of authority and eliminating the inherent redundancies built in over the years. The goal of SEA is to quickly integrate existing applications and data sources into business processes and new applications, without a lot of concern for whether or not they are redundant or could be streamlined or need to be decomposed and rearchitected into their composite services. But it's fast, and provides benefits moving forward that are similar to SOA in agility and reuse.

Both architectures have benefits and there are good reasons to go with a SEA instead of a SOA, or both.

It's time we recognize that SOA isn't The One True Way and that there are other, equally beneficial and valid architectures involving services.