SOA’s Business Value (Part II of III)

*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.

Don’t get carried away

Given the potential of SOA to make IT as a whole more service-oriented, it might be tempting to attempt to recast the whole of your IT organization’s application portfolio as networks of collaborating, loosely-coupled services. But this way lies madness. You must focus on the problem domain in which SOA can yield real benefit – and that is in the area where business meets IT. This domain is increasingly being modelled as sets of clearly defined business processes, which are partly automated through the use of integrated business application software functions. The ideal “service domain” where you focus your SOA efforts should not extend, initially at least, too far down into business functionality that is already implemented in application software: it should focus on the interfaces between those software functions and the business processes that need to make use of them. It should also focus in areas where IT flexibility, rather than cost and efficiency, are paramount. That’s likely to be in support of business activities and process that differentiate the business.

Use tried and tested design principles

There are two principles that work well in improving the flexibility and reuse of systems and services that are particularly suited to SOA initiatives:

  • Create well-defined and distinct layers of services, each of which is responsible for a particular set of tasks (for example, information access logic; business rules; navigation logic; and user interaction and presentation logic), and each of which delegates responsibility for some tasks to the layer below.
  • Discover and refine requirements for the overall system in the context of an understanding of the business processes, which will drive the system and its services. Start a “first cut” design with definitions of services within each layer according to the natural boundaries of steps in those business processes.

The first design principle mentioned above will yield an important category of software reuse as a side-effect: reuse of a clearly designed set of infrastructure services (such as state persistence management, identity and access management, workflow, and platform administration and monitoring) which today are very often delivered within the boundaries of business applications. The outcome of this “stovepipe infrastructure” is islands of technology, which constrain interoperability and inhibit employee and administrator productivity, and make things like regulatory compliance so painful to deal with. SOA initiatives enable us to deconstruct these application stovepipes, and so re-design the way that those infrastructure services are delivered – operating common infrastructure services which work consistently across large parts of the organisation. This aspect of software reuse is one of the very important but often-ignored benefits of SOA.

Recognize and plan for costs

Reuse of existing services in support of new system and business process requirements won’t happen by accident – your analyst and development teams will have to take explicit steps to work together across their own “mental stovepipes” to foster reuse throughout the lifecycles of systems and services. Additional time spent collaborating will cost money, as will tools to facilitate consistent sharing of service analysis, design and implementation information. You need to take some time early on in your SOA initiative to understand how much, and make budget adjustments accordingly. In the world of SOA, just as in everything else, there’s no such thing as a free lunch.

About the Author

Neil Ward-Dutton is Research Director at Macehiter Ward-Dutton, a specialist IT advisory firm which focuses exclusively on issues concerning IT-business alignment - including IT architecture, integration, management, organisation and culture. Neil is an accomplished and experienced IT industry analyst and public speaker. He advises clients on technology and management issues relating to enterprise architecture, application development, business integration, process management and application platforms. Neil has acted as an advisor to leading vendors, including IBM, Oracle, Microsoft, BEA, Hewlett-Packard, SAP, and Borland; and to large IT user organizations - particularly in financial services, government and telecommunications sectors.

More by Neil Ward-Dutton

About Macehiter Ward-Dutton

Macehiter Ward-Dutton is a specialist IT advisory firm which combines industry research and analysis with tailored consulting services, and is focused exclusively on issues surrounding IT-business alignment.

The company was formed in February 2005 by two top-level analysts formerly of Ovum: Neil Ward-Dutton and Neil Macehiter.