One of the realities of SOA is that even in the most enthusiastic organisations not all services can or will be delivered by discrete services written in .NET or Java. For historical or pragmatic reasons, some of the functionality is likely to be delivered by business applications. These may be legacy systems that have been bought or developed pre-SOA. In many cases new applications have been brought in post-SOA, much to the architects’ dismay.

Despite the widespread hype and reams of articles in technical and business journals alike, one question that still causes consternation amongst customers and practitioners alike is, “What is Service Oriented Architecture (SOA)”? If compiled, the answers to this question would fill copious volumes, but a consensus on an answer would be elusive. The reason the answer to this question doesn’t fit into the mold of a precise technical definition is due to the fact that SOA is mostly a business concept, hence it has to be defined in a business context.

With the current hard times continuing to challenge IT budgets, I fear that all the good effort that is going into SOA currently could be squandered by ill-conceived or rushed outsourcing of the wrong services and wrong responsibilities at the wrong time to the few remaining IT service companies.

It is worth pointing out that the analyst community have consistently promoted SOA and outsourcing as being good bedfellows. There are two main models here: