SOA in the Real World
SOA's Business Value (Part III of III)
By Neil Ward-Dutton, Research Director, Macehiter Ward-Dutton
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
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
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
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.