Many benefits have been claimed for the deployment of SOA. Surprisingly, most of these appear to be deliverable provided that sufficient investment is made in the planning, design, change management, and ongoing governance (plus, of course, the infrastructure investments that will be needed, although these are strictly secondary to the organisational issues).
However, there remains one claimed benefit regarding SOA that is somewhat questionable. This is the claim that SOA will enable organisations to extend radically the useful life of their existing applications.
The argument in favor of this benefit is that the business functionality delivered by the legacy applications is exposed as business services using off-the-shelf or custom-written adapters. The service layer provides abstraction from the specific technologies used to deploy the applications, so that these can then be assembled into composites and processes irrespective of their age or origin.
This argument is fair so far as it goes, but it makes some fairly basic assumptions, the first of which is whether the functionality exposed by application adapters really equates to business services. In very many instances this is, regrettably, a false assumption. It is the result of an IT-centric view of services rather than a genuine analysis of business requirements.
The application legacy with which most organisations are faced is the result of deploying systems to support the stovepiped organisational structure that used to be predominant. This has resulted in significant redundancy.
The redundancy is most apparent by taking a data integration perspective. Data integration is only made necessary by the redundancy of information, which must of course be the result of redundancy at the application functionality level. The immediate impact of this is that services exposed by the bottom-up exposure of application functionality are not business services at all, but simply application services abstracted from the technology.
To create a service that truly represent business requirements needs firstly an analysis exercise to determine just what those requirements are, and secondly an integration exercise to create the business service by combining the lower-level application services.
It may be the case that SOA provides a suitable infrastructure for creating business services from component parts in addition to enabling the creation of new and useful composites, but in many instances the performance overhead of using SOA in this way are prohibitive.
This leads to one of two different compromises. Either the creation of the business services is custom-coded using traditional hard-coded integration techniques, or the business service layer is omitted altogether resulting in a large number of services that do not really represent what the business needs.
The first compromise leads straight back to the unwieldy and expensive point-to-point integration scenario that we have been trying to escape for years, while the second leads to unnecessary complexity in the orchestration of composites and processes, essentially to manage the integration at the business process level.
Both of these are far from ideal and are the source of frustration with SOA, although it is not really the fault of SOA, but that of the very complex legacy.
The second basic assumption is the requirement that services in a SOA are autonomous and changes made to the implementation of any one service are abstracted by the service interface so that the changes are not apparent to any other service. In the case of most services that result from the exposure of functionality in a legacy application package this is manifestly untrue. Hard-coded process logic within the legacy applications provides unwanted tight coupling, while the resulting services are also very likely to share a common data model that will itself have embedded integrity rules that will create a dependency between the services.
The result of these legacy considerations is that SOA becomes in practice far more complex than should be expected. It is complex in design because of the need to map available applications on to the requirements of services, it is complex at runtime in terms of resolving performance issues and the need to federate authentications across multiple applications, and it is particularly complex in the change lifecycle because of the hidden interdependencies.
One of the principal early claims of SOA was that it was unique in being a major paradigm shift that permitted and encouraged the reuse of legacy investments. It avoided the resistance to change that accompanies any expectation of a 'rip-and-replace' strategy.
SOA does indeed provide the means to deliver new capabilities while re-using legacy investments, but at the cost of additional complexity and expenditure. It is only realistic to set expectations that a commitment to SOA is likely to include the replacement of a considerable part of the application legacy. However, what SOA does do is buy the organisation time to do this in a controlled fashion, and to take a piecemeal approach to identifying the most cost-effective replacement strategy.
A prerequisite to this, however, is sufficient investment in the analysis of the required business services so that the applications presenting the biggest mismatch can be identified, and a planned migration and replacement implemented.