*Editor’s Note: For Part I of this article, click here.

SOA is about much more than integration using Web services technologies – it has the potential to enable IT and the business to start to talk and collaborate using a common language. In our research, we’ve found that there are four steps involved in getting to this common language: using SOA to increase software flexibility; increase software reuse; increase the comprehensibility of IT to the business; and lastly, increase the visibility of the value of IT.

The first two steps are the most talked-about aspects of SOA, and they are closely related. The first is basically about using SOA simply as a way to carve existing applications up, and develop new systems in a modular fashion, so that changes are potentially localized and the impact minimized; the second is about organizing a portfolio of services so that as many of them as possible can be shared across multiple systems.

However contrary to what it would be easy to believe, based on vendors’ marketing material, implementing an SOA initiative won’t automatically yield improved software flexibility and reuse – there are a number of important principles and practices which need to be applied, and which have nothing to do with technology per se. There are too many of them to go into detail on them all, but I’ve highlighted some of the most important ones here.

Get the big picture

A big part of the value of service-orientation is the ability of services to represent what a business does. In this context, if you don’t understand the nature and structure of the business processes, which are going to make use of software services once they’re published, those services don’t stand a chance of fitting the needs of the business. Moreover, the nature of SOA is also such that individual services can – and should – be applicable to more than one system and more than one business process. This, of course, is a big part of the reuse promise of SOA. But it means that looking at service requirements purely within the context of a short-term system or business process requirement will miss wider opportunities to generate value from your investments.

In order to ensure that broader and longer-term requirements are taken into account when services are being designed, a full-time skilled architect resource must be in place in your IT organization, which is available to all integration and development projects which take place within the context of your SOA initiative. The architect(s) must be more than glorified software designers: they must have the responsibility of balancing short- and long-term business requirements in the context of your IT delivery capabilities, which means they must sit squarely between IT and the business, talking to and understanding the needs of both constituencies. And along with that responsibility, they must have the authority to strongly influence the way that services are implemented and deployed. In other words, an architecture team which is seen purely as a “team of clever people we can ask questions of,” isn’t going to be nearly enough.