Editor’s note: To read Part I of this article, click here. To read part II of this article, click here.

In talking about the benefits that SOA can bring to an organisation, most people concentrate on two things: firstly, the ability to develop more flexible systems from collections of loosely-coupled services; and secondly, the ability to develop new systems more cheaply, quickly and at higher quality through the use of shared services. These are both sound reasons to think about pursuing a SOA initiative. But is there more to the potential value of SOA than this? From talking to leading-edge companies which have made serious commitments to SOA, the answer is a resounding "yes." SOA, done right, can show the way for IT organisations to clearly demonstrate the value they provide to their "customers" - the businesses they work within.

Before SOA can raise the visibility of IT organisations' value, though, we have to use SOA to help create that common language between IT and the business - in other words to enhance comprehensibility. Luckily, many IT organisations will be pushing at an open door here. More and more, organisations driving for new business efficiencies and innovations are looking beyond the work done in individual departments, to the work that gets done in end-to-end processes that span departments (such as "order-to-cash") and even organisational boundaries. Fundamentally this exercise (which is targeted by Business Process Management or BPM initiatives) is about looking at what the organisation does from the perspective of customers, partners and suppliers - from the outside in - rather than looking at it from the inside out. Consequently, many organisations are in the middle of re-thinking the ways that they express what it is that they do, and how they do it. They are inventing new language - and business processes are a key part of that language.

In this context, you can effectively sell SOA initiatives on the basis that they will deliver sets of high-level, business-meaningful services which intermediate between the morass of existing IT systems and capabilities; and newly-automated, reorganised or reinvigorated business processes. Examples might include services which manage customer information, or which validate orders: they will implement concepts which are readily understandable by non-technical business professionals. You should aim to create groups of these services which can be clearly linked to individual tasks within business processes, as well sets of services which encapsulate and implement lower-level layers of business and technical capabilities. If you empower your senior architects to get involved in these process analysis exercises and collaborate with business analysts (and the consultants they're probably working with) the result can be a common language comprising business processes, and the high-level IT services which underpin and support those processes.