SOA's Business Value (Part III of III)

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.

Now, once you have engaged the business by linking the idea of high-level services into concepts about end-to-end business processes, you have a very powerful lever in your hands - one which has never been available to most IT organisations before.

One factor which contributes hugely to the mixed views that so many CEOs and CFOs have of IT organisations, is that it's so hard for them to understand whether they've ever received value from the money that they've invested in IT projects. Let's look at a hypothetical example: five years ago John Doe Ltd's CEO has been networking with his peers, who are all working with a big IT application provider (let's call them Walldorf GmBH). They're all implementing the company's suite of applications, which automate a lot of their back-office processes. John Doe's CEO likes what Walldorf is saying about the efficiencies his peers are seeing - and when he returns he instructs the IT Director to do a feasibility study. A couple of months later, the project starts - and three years after that, after £10m spent, the project goes live.

Now, a year after go-live, the CEO asks the IT Director: "did we get value from that £10m?" The IT Director kicks off a small project to find out. A month later, he reports back, exasperated. All he can show the CEO is a page of statistics detailing server uptimes, database performance, and so on. The meeting is not good.
Until now, it's been extraordinarily difficult to have IT investment conversations that can clearly map to operational (and change management) conversations that seek to uncover the value of those investments. Investment conversations tend to be very coarse-grained: "let's implement Siebel CRM". Value conversations tend to be more fine-grained: "the servers underpinning Siebel were up 99.8% of the time last month". For the first time, with SOA, you have the opportunity to clearly relate the production of solutions in an IT environment, to the operation of solutions in a business environment. Together with the promise of comprehensibility, the visibility that comes with SOA enables business stakeholders, administrators, designers and developers to share a common view of solutions which makes sense to all of them. This has clear implications for more "business-aligned" IT investment and IT service delivery, and also in the cooperative management of change

This only works, though, if you think of SOA not only in the context of how systems are built; but in the context of how they are procured, designed, built, tested, deployed, monitored, managed and changed. You must then look for tools, technologies and practices which help to link all these activities together. The visibility and comprehensibility of solutions both rely on effective collaboration between a range of people, roles and technologies throughout the lifecycle of solutions.
Each phase in the lifecycle of service-oriented software systems requires cooperative contributions from people in a variety of roles, from the business as well as across IT delivery functions. The key roles throughout the lifecycle, though, are the architect roles.

An IT architect's job is to work with a range of stakeholders to bring IT and business needs together in the development and implementation of IT solutions. In this, the architect's natural value is to balance the need for short-term business outcomes with the need for long-term high-quality IT value. In the context of a delivery lifecycle influenced by SOA principles, this means that the role of the architect is absolutely crucial. It is the architect roles which are best placed to take responsibility for the effectiveness of the overall delivery lifecycle: helping ensure that information flows from one phase to another, and also ensuring effective communication between business stakeholders and the various IT roles.

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.