More than merely linked web services, SOA has the
potential to enable IT and the business to talk and collaborate
using a common language.
Service oriented architecture is about much more than
integration using web services technologies - it has the potential
to enable IT and the business to start to talk and collaborate
using a common language.
There are four steps involved in getting to this common
language: using SOA to increase software flexibility, increasing
software reuse, increasing the comprehensibility of IT to the
business, and increasing the visibility of the value of IT.
The first two steps are the most talked-about aspects of SOA,
and they are closely related. The first is basically about using
SOA simply as a way to carve up existing applications, and develop
new systems in a modular fashion, so that changes are potentially
localised and the impact minimised. The second is about organising
a portfolio of services so that as many of them as possible can be
shared across multiple systems.
However, contrary to what might seem to be the case based on
suppliers' marketing material, implementing an SOA initiative will
not automatically yield improved software flexibility and reuse -
there are important principles and practices which need to be
applied and which have nothing to do with technology per se.
A big part of the value of service orientation is the ability of
services to represent what a business does. If you do not
understand the nature and structure of the business processes that
are going to make use of software services once they are published,
those services do not stand a chance of fitting the needs of the
business.
The nature of SOA is such that individual services can, and
should, be applicable to more than one system and more than one
business process. This is a big part of the reuse promise of SOA.
But it means that looking at service requirements purely within the
context of a short-term system or business process requirement will
miss wider opport- unities to generate value from your
investments.
To ensure that broader and longer-term requirements are taken
into account when services are being designed, full-time skilled
architects who are available to all integration and development
projects in your SOA initiative should be engaged.
The architects must be more than glorified software designers:
they must have the responsibility of balancing short and long-term
business requirements in the context of your IT delivery
capabilities, which means they must sit squarely between IT and the
business, talking to and understanding the needs of both.
And along with that responsibility, they must have the authority
to influence the way that services are implemented and deployed. In
other words, an architecture team that is seen purely as a "team of
clever people we can ask questions of" is not going to be nearly
enough.
Given the potential of SOA to make IT as a whole more service
oriented, it might be tempting to attempt to recast the whole of
your IT organisation's application portfolio as networks of
collaborating, loosely coupled services. But this way lies
madness.
You must focus on the domain in which SOA can yield real
benefit, and that is in the area where business meets IT. This
domain is increasingly being modelled as sets of clearly defined
business processes, which are partly automated through the use of
integrated business application software functions.
The ideal "service domain" where you focus your SOA efforts
should not extend, initially at least, too far down into business
functionality that is already implemented in application software.
It should focus on the interfaces between those software functions
and the business processes that need to make use of them.
It should also focus in areas where IT flexibility, rather than
cost and efficiency, are paramount. That is likely to be in support
of business activities and process which differentiate the
business.
There are two principles which help to improve the flexibility
and reuse of systems and services that are particularly suited to
SOA initiatives.
First, create well-defined and distinct layers of services, each
of which is responsible for a particular set of tasks (for example,
information access logic, business rules, navigation logic, and
user interaction and presentation logic), and each of which
delegates responsibility for some tasks to the layer below.
Then discover and refine requirements for the overall system,
understanding the business processes which will drive the system
and its services. Start a "first cut" design with definitions of
services within each layer according to the natural boundaries of
steps in those business processes.
This will yield an important category of software reuse as a
side-effect: reuse of a clearly designed set of infrastructure
services (such as state persistence management, identity and access
management, workflow, and platform administration and monitoring).
These are often delivered within the boundaries of business
applications.
The outcome of this "stovepipe infrastructure" is that islands
of technology develop which constrain interoperability, inhibit
employee and administrator productivity, and make things such as
regulatory compliance painful to deal with.
SOA initiatives enable us to deconstruct these application
stovepipes, and so redesign the way that infrastructure services
are delivered - operating common infrastructure services which work
consistently across large parts of the organisation. This aspect of
software reuse is one of the important but often-ignored benefits
of SOA.
Reuse of existing services in support of new system and business
process requirements will not happen by accident - your analyst and
development teams will have to take explicit steps to work together
to foster reuse throughout the lifecycles of systems and
services.
Additional time spent collaborating will cost money, as will
tools to facilitate consistent sharing of service analysis, design
and implementation information. You need to take some time early on
in your SOA initiative to understand how much, and make budget
adjustments accordingly.
Neil Ward-Dutton is co-founder of analyst and advisory firm
MWD. Next month in Computer Weekly he will examine managing
services and service-based systems throughout their
lifecycles
Feature article: Clear path to SOA
Leader article: Building an SOA without the hype