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.
1
Solution Center Resources