SOAs can provide a credible way to relate the productivity of systems in their IT context to their ultimate value in the business world, says Neil Ward-Dutton
In talking about the benefits that a service oriented architecture (SOA) can bring to an organisation, most people concentrate on two things: the ability to develop more flexible systems from collections of loosely coupled services and 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 an 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, I have come to the conclusion that the answer to this is a resounding “yes”. SOA, done right, can show the way for IT organisations to clearly demonstrate the value they provide to their customers – that is, the businesses they work within.
But before SOA can raise the visibility of an IT organisation’s value, we have to use SOA to help create a common language between IT and the business – in other words, to enhance mutual comprehensibility.
Luckily, many IT organisations will be pushing at an open door here. Increasingly organisations pushing 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 organisational boundaries.
Fundamentally this exercise (which is targeted by business process management initiatives) is about looking at what the organisation does from the perspective of customers, partners and suppliers – from the outside looking in, rather than from the inside looking out. Consequently, many organisations are in the middle of rethinking the ways they express what it is that they do, and how they do it. They are inventing a 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 services that are meaningful for business and which mediate between the morass of existing IT systems and capabilities on the one hand and newly automated, reorganised or reinvigorated business processes on the other. Examples include services that manage customer information or validate orders: they will implement concepts that are readily understandable by non-technical business professionals.
You should aim to create groups of these services that can be clearly linked to individual tasks within business processes, as well as sets of services that 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 are probably working with), the result can be a common language comprising business processes, and the high-level IT services that underpin and support those processes.
Once you have engaged the business by linking the idea of high-level services to 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 is so hard for them to understand whether they ever receive value from the money they have invested in IT projects.
Take a hypothetical example. John Doe Ltd’s CEO is networking with his peers, who are all working with a big IT application provider. They are all implementing the supplier’s suite of applications, which automate a lot of their back-office processes. John Doe’s CEO likes what the application provider is saying about the efficiencies his peers are seeing – and instructs his own IT director to do a feasibility study. A couple of months later, the project starts, and three years down the line, with £10m spent, it goes live.
A year after go-live, the CEO asks his IT director, “Did we get value from that £10m?” So 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 does not go well.
Until now, it has been extraordinarily difficult to have IT investment conversations that can clearly map to operational (and change management) conversations which seek to uncover the value of those investments.
Investment conversations tend to be very coarse-grained and go along the lines of “Let’s implement Siebel CRM.” Value conversations tend to be more fine-grained, as in, “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 co-operative management of change. But it only works if you think of SOA in the context of how systems are procured, designed, built, tested, deployed, monitored, managed and changed, as well as how they are built.
You must then look for tools, technologies and practices that help to link all these activities together. The visibility and comprehensibility of systems both rely on effective collaboration between a range of people, roles and technologies throughout the lifecycle of systems.
Each phase in the lifecycle of service oriented software systems requires co-operative 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 goal 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 that 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.
Neil Ward-Dutton is co-founder of analyst and advisory company MWD