Site Archive (Complete)
Architecture Blog: SOA Definition and the Enterprise SOA
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
January 07, 2008

SOA Definition and the Enterprise SOA

Sam Gentile and I exchanged a few blog posts on the definition of SOA. In the latest installment Sam disagreed with me that SOA should first be looked at in the pure architectural sense without bundling in the business and enterprise aspects.

In a nutshell, I have two main reasons to prefer looking at SOA at the core as a pure architectural style.

The first is the when you bundle in enterprise-wide aspects of implementing SOA you loose out on the option (or the audience) that can use it to solve more local problem (i.e. at the product/solution level) using the same principles that bring the benefits on the enterprise scale.

The other reason I have for separating the concepts is that the business encompassing definitions tend to be fluid, hand-waving ones and cannot be measured for compliance.

Consider the definitions Sam quotes from one of Thomas Erl's books:

SOA establishes an architectural model that aims to embrace the efficiency, agility, and productivity of an enterprise by positioning services as the primary means through which solution logic is represented in support of the realization of strategic goals associated with service-oriented computing. (emphasis by Sam)" SOA represents a model in which functionality is decomposed into small, distinct units (services), which can be distributed over a network and can be combined together and reused to create business applications. [3]

Now what the hell is that? These are all noble goals but shouldn't this be the goal of any enterprise architecture ? What makes SOA unique in this sense?

Also how does these definitions help us build services? What makes a service a service ? Why is (or isn't) any web-enabled component a service?

Definitions that distance themselves from the architectural roots seems to me like smoke and mirror and contribute to the general confusion around SOA - to the point where even people like Harry Pierson wonder why we should even bother defining it.

Personally, I still think it is worth while defining *** (the architectural style, formerly known as SOA) since as I mentioned earlier it is (in my opinion) a useful architectural style for building distributed systems -- whether the distributed system is a solution, product, product line, or a complete enterprise.

Posted by Arnon Rotem-Gal-Oz at 04:34 PM  Permalink




 
INFO-LINK


Related Sites: DotNetJunkies, SD Expo, SqlJunkies