What is SOA Anyway? Part III - And Then There Were Two

Looking beyond the hype and misconceptions, it seems we can narrow SOA into two points of view, both which seem to be valid -- one from the business perspective and another from the technical one.

At the enterprise architecture level, it is always about the business. This is not a bad thing. On the contrary, the enterprise architecture perspective should be focused on the business needs to make sure IT serves the business, and not vice versa.

The emphasis from the business perspective is on "service orientation". Consider, for example, the SOA definition from Service-Oriented Architecture (SOA): A Planning and Implementation Guide for Business and Technology, by Eric A. Marks and Michael Bell.

SOA is a conceptual business architecture where business functionality, or application logic, is made available to SOA users, or consumers, as shared, reusable services on an IT network. "Services" in an SOA are modules of business or application functionality with exposed interfaces, and are invoked by messages.

Looking at other "business oriented" definitions of SOA, we can see they follow the same reasoning. In a nutshell, they can be summarized as follows:

From the business point of view, SOA is about analyzing the business to identify business areas and business processes, followed by defining services to represent these "areas". Services expose their capabilites through message interfaces. The services can then be choreographed or orchestrated to realize the business processes. The goal of SOA is to increase the alignment between business and IT and achieve business agility -- the ability to respond to changes quickly and efficiency.

And then there's the other face of SOA -- the technical point of view.

On the business side of the fence, the emphasis is on "Service Orientation" (SO). On the technical front, the emphasis is on the "A" of SOA -- Architecture. True, there isn't a single unified definition for SOA; however, just like the many definitions of software architecture, there are several characteristics that are more common and frequent than others. Looking at definitions of SOA such as those from Wikipedia, O'Reilly , JavaWorld, and Microsoft, etc., you can see that SOA is commonly thought of as an architecture or an architecture style that builds on loosely coupled, interoperable, and compostable components (or software agents) called "services." Services have well-defined interfaces based standard protocols (usually web services but most definitions mention that it is not the only possible implementation) as well as QoS attributes (or policies) on how these interfaces can be used by Service Consumers. SOA definitions mention the basic communication pattern for SOA is request/reply but many definitions also talk about asynchronous communications as well.

If we look at the business and technical approaches for SOA we can see that there's still hope to achieve convergence as there are some common grounds -- the next section will try to do just that.

Posted by Arnon Rotem-Gal-Oz at 07:07 PM  Permalink