Posts Tagged ‘SOA’

A SOA by any Other Name…

Posted on January 12th, 2009 by Dennis Stevens  |  No Comments »

Here is an SOA Definition from the SOA Working Group of the Open Group.

Service-Oriented Architecture (SOA) is an architectural style that supports service orientation.

Service orientation is a way of thinking in terms of services and service-based development and the outcomes of services.

A service:

·         Is a logical representation of a repeatable business activity that has a specified outcome (e.g., check customer credit; provide weather data, consolidate drilling reports)

·         Is self-contained

·         May be composed of other services

·         Is a “black box” to consumers of the service

An architectural style is the combination of distinctive features in which architecture is performed or expressed.

The SOA architectural style has the following distinctive features:

·         It is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes.

·         Service representation utilizes business descriptions to provide context (i.e., business process, goal, rule, policy, service interface, and service component) and implements services using service orchestration.

·         It places unique requirements on the infrastructure – it is recommended that implementations use open standards to realize interoperability and location transparency.

·         Implementations are environment-specific – they are constrained or enabled by context and must be described within that context.

·         It requires strong governance of service representation and implementation.

·         It requires a “Litmus Test”, which determines a “good service”.

There are some really important distinctions about the SOA definition.

SOA is not technology – it is a way of thinking about architecture. There are various standards around services that lead to interoperability, but these standards are technical standards – they are not SOA.

SOA discussions are about business outcomes – not about technology. One really important thing is to identify and deliver services that provide business value. We don’t need to be discussing SOA with the business – they just don’t care (hence its demise). We need to get architects thinking about the business, and what the business does to create value for the customer. Then that can be translated that into a technology solution.

I believe that a business capability-based assessment of the company is a great way to facilitate this discussion between technology and the business. A business capability is a something the business does which produces a specific result or outcome. A business model can be viewed as a network of business capabilities. When viewed this way, you can identify those capabilities that need to be changed or improved to accomplish the business strategy. From these capabilities, you can identify services that are valueable to the business. Now you are having a business discussion that aligns your business model to the technology.  And you can align your technology investments with the best interest of the business.

You can get a copy of “The Next Revolution in Productivity” to look at an approach for doing this. Either go to the Harvard Business Review website and buy one, or get one for free by registering at (Official Disclosure: I was an author on the paper). I also have a tool set I will share with individuals who want to help improve this approach.

I will be writing more about business capability analysis as a way of identifying where to focus improvements in the business, and how to identify where SOA is a good approach. I would appreciate feedback on the article and the capability analysis approach.