Being service oriented (SO) is, and continues to prove itself to be, a valuable and elegant approach for applications as well as enterprise architectures.  However I am a bit baffled by why an architecture which is service oriented is being branded a new kind of architecture.  An architecture may or may not be service oriented but the underlying architecture exists separately. 

My search for clarity started by trying to pin down a definition for Service Orientated Architecture.

The W3C's Web Service Architecture Working Group defines Web Service Architecture as an instance of an SOA in which "a service is viewed as an abstract notion that must be implemented by a concrete agent. The agent is the concrete entity (a piece of software) that sends and receives messages, while the service is the abstract set of functionality that is provided."  Well that clears that up, doesn’t it?  

Equally obscure but I believe more insightful is a definition from Rick Murphy in his article “Centers: The Architecture of Services and the Phenomenon of Life : Christopher Alexander's theory of centers helps explain the essential properties of service-oriented architectures”   He invokes Christopher Alexander, one of the original thinkers on architecture, theory’s on centers.   Mr Murphy defines SOA as “… services encapsulate the enduring mission of a virtual organization as centers of value. Services, as centers of value, are living structures we choreograph through a common grammar subject to fitness and evolution. Customer demand determines fitness based on service discovery and service description. Choreography defines the sequence and conditions under which services evolve.”  I love the abstraction but I think we need a more readily consumable definition.

 For that I turn to Ramkumar Kothandaraman from Microsoft.  In his MSDN article “SOA Challenges: Entity Aggregation” Ramkumar defines SOA as having “several core design principles:

• Service boundaries are explicit;
• Services share contracts and schema;
• Services use message-based communication for interaction;
• Services are autonomous and managed independently; and
• Services use policy assertions to control the behavior.”  

This works for me.  A five point test I can apply to an implementation to gauge is level of SO-ness.  Even so, these 5 points are possible characteristics of ANY implemented architecture.  Personally, I would add Service Orientated as another style in Roy Fieldings’ dissertation on Architectural Styles and the Design of Network-based Software Architectures.  In which he categorizes architectural approaches and weights their appropriateness to a target problem domain.  A distributed system can be Layered, implement client caching, AND be service oriented.  Considering one can maintain the basic constructs of SO in an embedded, layered, or distributed system it seems clear that the base architecture is not effected by the inclusion or exclusion of services.