Key Best Practices - What is Service Orientation?

What is Service Orientation?

1. It is the ability to use of simple business syntax for defining and discovering business services whose interfaces encode business behavior using the business language
2. It is the ability to define a business service policy that governs the avaialbilty and reliability aspects of the business service

Service Orientation most of all is about the use of simple business terms defining business offerings that execute business capabilities. There is no place for the use of architecture terms, technological jargon or even as much as a mention of the web services or the WS-* stack in this definition!! The need for web service standards, SOA infrastructures technical stacks including HTTP, URIs or SOAP/ HTTP and WSDL enter the picture only when talking about the how to achieve Service Orientation, not the what is Service Orientation!

The technology is undoubtedly important provided an enterprise has the discipline of Business Architecture in place to define its' business service portfolio. In addition to this, the business service portfolio represents an enterprise' unique interpretation of Service Orientation and this enables the enterprise to deliver the strategic capabilities that are sought by the business. These strategic business capabilities are delivered as business service offerings that lead to market differentiation opportunities.

Without undertaking an effort to leverage in the Business Architecture discipline an enterprise has IT investments in technology of ESBs, the Service Registry and Service Repository etc. but the Web Services that are published look more like API calls. These API like web service interfaces will befuddle the business and will not help the enterprise realize the full potential of "Service Orientation". As would be noticed Service Orientation is built right into the concept of Service Oriented Architecture (SOA).

WOA and SOA are both architecture models that speak to the implementation models for achieving "Service Orientation".

WOA is a way of taking the REST-like service interface concepts that involve the invocation of standard operations that act upon simple payload identifiers and are transmitted over standardized internet protocols. The WOA paradigm embeds complexity in the "message format" or the payload. In other words, WOA prescribes a clean architecture model that enables an enterprise to quickly expose services with information constructs represented as URIs (instead of complex XML Schemas). Furthermore, the interfaces are defined as simple HTTP commands of "GET, POST, PUT and DELETE". It must be reiterated that the key point of the WOA model is to abstracted away complexity behind the simple interfaces and URIs. This aspect of simplifying the interface is very much in keeping with one of the principles of Service Orientation. However, this model may not really meet the other tenet of Service Orientation i.e. interfaces are represented using business vocabulary and are codified using business syntax.

SOA on the other hand is an architecture paradigm that leverages a more complex message format (that is defined as XML Schemas) with the interface definition that is could be deemed more business-like. Here the complexity of the message construct is codified using XML Schemas. These XML Schemas encode the business-document structural rules but do not expose the complexity of the business rules. So to some extent SOA meets the other Service Orientation tenant in keeping service interface definitions more business-like long as the interface definitions are driven by business architecture process.

WOA or SOA do not by themselves address the governance and monitoring of the business service policy. SOA infrastructure is needed to address service policy monitoring, service clustering and scalability concerns. In addition, the use of service infrastructure components such as ESB service-mediation flows enables IT to achieve location transparancy of business services that indirectly influence business service availability. It must be remembered that SOA infrastructure products are important to the business only in that they help meet the business’ service availability needs.

Just because the business does not need to be exposed to the implementation details does not mean that IT has the luxury of glossing over how the enterprise deals with transaction management rules and the incorporation of the ever changing regulatory business rules. It is just that these complexitites are left up to the technical and operations experts in the IT area.

An important aspect in talking about the maturity of SOA based technologies is that most commercial SOA infrastructure component vendors are striving to comply with the WS-* standards. This level of standardization promotes interoperability of the SOA based infrastructure components even when purchased from multiple vendors. The effect of this interoperability is that it finally affords IT a chance to now purchase packages to implement these complex implementation behaviors (such as transaction managment, service monitoring, service management and deployment, regulatory and security business rule interception etc.) as opposed to having to implement these complex implementation behaviors from ground-up. Now IT has a way of aligning its' business serivce delivery model to achieve the business need at the speed of the business instead of having to deal with infrastructure and integration issues.

Whether a WOA model or a SOA model is used to define and deliver the business capability to the business does not impact the concept of Service Orientation. The use of the WOA/ SOA constructs do not add a competitive business edge. They are just best practice architecture models that add to the reliablility of the service delivery aspect.

Your feedback is invaluable.
Thanks.
surekha -