Service Oriented Architecture is about creating services - period. Business people understand services. They have been doing this for years. Services usually have contracts associated with them. Useful services will ALWAYS have contracts between the provider and the consumer that establish common understanding of the offered service and terms and conditions of use. Even if the service as simple as a dry cleaning and laundry service there will be a price, a ticket, agreement on the price, type of treatment (starch, no starch, folded or on hangers etc) and an expected delivery date. There are also questions of risk and liability. Does the customer have to pay if the cleaning fails to remove the stain on the sleeve? What happens if the garment is damaged?

The fundamental idea of the service is that I can separate the providing and using tasks. To make use of the service I don’t have to know how to operate the washing machines or how to iron shirts. All I need to know is how to describe the service to the provider. If the provider chooses they can subcontract the service to another provider. In fact they may have separate contracts for different dry cleaning and laundering services for different materials such as wool, silk, suede, cashmere, leather etc as well as ironing and finishing. They may have different subcontractors for week days and weekends, or even every day of the week. All these separate subcontract services are aggregated into one composite service that is presented and agreed with me the consumer.

But let’s not get too carried away with over simplification and analogies, we can only carry that so far. The contract “we” are talking about is a complex specification of service capabilities. It specifies the message signature, sequences and behaviours, (tell me this and I will respond in this manner), as well as dependencies and rules (pre and post conditions) and information usage and then a host of properties that cover the operational requirements.  The service specification is therefore a formal and comprehensive statement that defines the obligation of both parties.

There are some very significant benefits or business values that arise from this form of service architecture:

Lower integration and testing effort.
Services from disparate sources can be more easily assembled together because the assembly task is confined to the external or contractual view. The internals are of no concern to the consumer. By comprehensively defining the consumer expectations the service specification also acts as a comprehensive test specification. This combination offers the opportunity to substantially increase quality with lower integration and testing effort by the consumer.

-          Reduced cost and increased business consistency.
Lower integration and testing effort make it much easier to share services - across an enterprise, supply chain or other form of ecosystem. For many years the IT industry has focused on reusing small units of technical functionality with mixed success. With services the unit of reuse is a business service published at the level of granularity required by the consumer. For example an Orders Service, or a Security Service. This allows us to standardize certain elements of business process or business intelligence either to simply reduce cost of both delivery and operation, or to impose standardization of business process and rules where standardization is supportive of the business strategy.

-          Assembly of custom solutions from standard components.
The service architecture is recursive – that is a service can call one or more services. And this is a repeating pattern with no inherent limits to the depth of the hierarchy. This so called composable architecture allows us to use the services as components, assembling them into different business processes as required. For example we may mandate that all parts of a supply chain or enterprise use a standard customer service in order to ensure core aspects of customer interactions are consistent. Then the service may be assembled into several instances of line of business specific business process that extend the standard behaviours and information appropriate for varying product groups, geography or delivery channels.   

-          Reduction in existing cost and complexity.
The information service may look like a component or building block from the consumer’s perspective, but under the covers the reality is it may be implemented by one of more legacy applications. However over time the provider will be able to rationalize and or componentize the underlying applications, and because the interface with the consumer is stable, make changes with minimum impact on the consumer. This is unlikely to happen in the very early stages of SOA, but over time it represents major cost saving opportunity for most enterprises.

-          Choice of supply enables better fit to business needs.
The separation of the concerns of the provider and consumer are a fundamental part of the service architecture. It allows increased choice of providing components for the provider and choice of supply for the consumer. We fully expect that service architecture will in time break down the complexities inherent in widely used enterprise application products, enabling consumers to have greater control of their own architecture – to more easily integrate services from multiple suppliers, customize the standard product and support business processes required by the enterprise, rather than having to adapt the enterprise to the application provider’s process model.

-          Diverse sources of supply enable the service market.
The most interesting aspect of SOA is a little further away, but as enterprises gain experience in managing services from mixed sources, the market for services will become very active. The level of dissatisfaction with existing enterprise applications is very high, in terms of both cost, business fit and performance. Service architectures will stimulate a major change in the de facto economic model as smaller, specialist providers create service products that are very massively cheaper and functionally superior to existing market leaders.

Business Agility – the holy grail.

Much has been said about the way SOA can deliver agility and I continue to observe comments that suggest everything can change constantly in an SOA. Frankly this is dangerous nonsense. In a large enterprise change needs to be controlled both from a technical and business perspective in order to manage quality and regulatory compliance. But what SOA does give us is an enhanced ability to cleanly separate the things that do need to change from the things that don’t.

In this commentary I have touched on many aspects of architecture that can deliver agility including reduced testing and integration effort, standardization and assembly into variant process designs and increased source of supply. But the bottom line is that SOA enables agility by creating an architecture that has clear, formal, contractual separation between the moving parts. This is a fundamental and profound change that reduces complexity and serves to facilitate as well as contain the impact of change.

The idea of Lego blocks is actually very misleading. Lego^TM blocks are homogeneous and proprietary – they all have the same interface, they come from the same supplier, they don’t interface with other building blocks and they don’t do anything that remotely looks like a service. Furthermore, Lego^TM isn’t even a good example of simple reuse any more. Modern Lego kits are extremely complicated - they contain a large number of single-purpose blocks, and you have to follow a precise set of assembly instructions. Making a castle according to the specification is hard enough; making an entirely different castle with these blocks is practically impossible. The metaphor is more relevant to an old fashioned enterprise application than service architecture.

If we try to communicate new ideas in such a superficial manner it should be no surprise if our business colleagues completely fail to understand us.