History is not on our side. Organisations have wasted vast amounts of money and time chasing suppliers' claims, consumed by the notion that investing in IT is going to help them make more money. Various middleware and integration stacks have been deployed in a bid to facilitate increased flexibility, yet we seem no further on.
Although software suppliers would like us to buy into the vision of organisations running their software wall-to-wall, the reality is that heterogeneous IT is very much the norm. As a consequence, a vast proportion of IT budgets are eaten up trying to manage complexity.
This is an intricate mix of maintenance, additional custom development, integration and change management, which constrains the IT department and puts a firm lid on innovation. Add to this the demands of modern business for 24x7 operations, high availability of systems, and the challenge of integration, and it is little wonder that IT impedes the speed with which businesses can execute. For many organisations technology has had the effect of casting processes in "concrete boots", making agility a laughable notion.
Regardless of the capabilities or potential that a service oriented architecture may have, if we approach it with the tired techno-centric mentality of the past then we are not even giving it a fighting chance. Unfortunately, many organisations have already started down this road, somehow convinced that it was the technology that let them down last time and that all they needed were better tools and standards.
Although standards have evolved and supplier tools are now more aligned with requirements and business processes, SOA conceptually delivers nothing new. Putting blind faith in it is a sure-fire way to court disaster.
What is needed is a middle ground - one that recognises and accepts the promise of SOA without getting carried away, and which acknowledges the problems and practical issues encountered with other component- based notions.
SOA needs to be approached from a balanced and considered view. Unfortunately this is extremely difficult. Firstly, reaching a common understanding of exactly where SOA starts and finishes is difficult. Definitions range from the narrow and technical, to the broad and eclectic. Again, in order to extract any kind of sensible meaning out of it, SOA needs to be defined somewhere in between these two extremes.
It is not just technology - SOA does not come on a disc, nor can it be installed. Similarly, it is more that just a concept or idea. SOA is a series of design principles, based on the concept of service definition, discovery and reuse. These principles are underpinned by an integration architecture that supports the creation of services from underlying applications and their components, and which in turn allows services to be loosely bound to one another at runtime.
Critically, within an SOA services are entirely self-contained and completely independent of the underlying technologies. This marks out SOA from previous component technologies such as Corba and Com, which remained technology-dependent. In this respect, SOA is something of a logical evolution from web services, which provide the technical isolation between the transport and application layer and the notional services layer.
Much is made of the ability of a SOA to "join business to IT". Again, this is far from being a new idea. Indeed, the phrase is so often used it is a clich‚. However, SOA concepts can foster closer integration between business and IT, but only if approached with the right mindset.
SOA allows, or even encourages, organisations to consider the role that application components and services play in business processes. Organisations approach this challenge in one of three main ways.
By the academic textbook
Starting with an understanding of a particular process (which in itself can be a challenge), line-of-business experts and business analysts will model the desired process.
By understanding the various steps and participants within a particular process, they will then define the high-level business services required to execute the process.
Finally, they will engage with IT in order to map these business services onto the underlying technology and infrastructure services. Although some organisations have been able to establish their SOA through a top- down, process-driven approach, it is several steps too far removed for most.
By the IT manual
This bottom-up approach is the antithesis of textbook approach, and starts with the IT department creating reusable services out of IT assets. Technically, this is straightforward - there is a plethora of development tools that support the web service enablement of interfaces and components.
Without knowing the context of the business processes that will eventually consume the service, developers will inevitably fail to create the service with the right level of granularity or functionality. In time this situation will become anarchic, with a multitude of services and, unsurprisingly, little or no reuse.
This characterises a large proportion of SOA initiatives which, unless the situation is addressed rapidly, are set to fail.
By the blueprint
The problem with both of the above approaches is that they lack structure or discipline and do not even begin to address the SOA lifecycle. The first fails to capture the needs, limitations and restrictions imposed by IT, and the second ignores the requirements of the business.
Middle ground must again be sought with a methodology that simultaneously respects the needs of business, and the practical reality and complexity of IT. This will be a highly iterative process which sees the needs of the business reflected in the development process, with agreement and collaboration between the two on the requirements and design of business services. Industry blueprints and methodologies are starting to emerge in an attempt to capture best practice and encourage organisations to think more strategically about SOA and the supporting architecture. It is with these initiatives that the hope and promise for SOA currently rests.
One of the frustrating mistakes I consistently observe with regard to SOA is that organisations seem to expect reuse to happen by magic. Not only is this frustrating, it is also somewhat depressing - have we really learnt nothing from our experiences with Corba and object orientation?
The industry's failure to achieve service reuse after many years and different technologies is the equivalent of obsessive compulsive disorder in humans. We know what we are doing is not productive, but seem unable or unwilling to change.
Maybe the situation is not quite as bleak as that, as some high profile successes with SOA help to prove. However, scratch beneath the surface of these glossy case studies and you will find some stark home truths: SOA is hard, complex and expensive to do right, and it absolutely depends on a business oriented view of service design and reuse.
If you are not prepared to commit to SOA and to invest in radical change, then the only thing you are prepared for is failure.
SOA moves us away from building systems and standalone applications to the creation of reusable business services. However, this will only be realised if the developers creating the services move in the same direction.
Both culturally and from the point of view of rewards and incentives, the desire has to be there to find and reuse existing services, rather than creating new ones. Where services do not exist, a controlled process needs to be enforced to ensure that there is agreement on the definition, functionality and metadata appended to the new service, in order to encourage and facilitate its subsequent reuse.
Ian Charlesworth is a senior analyst at Ovum, where he leads research on integration