Service oriented architecture (SOA): An SOA can help IT
become more responsive to business needs, but confusion about the
approach means some fail to realise its potential.
Service oriented architecture (SOA) was one of the hottest
topics in enterprise software in 2005, and it is set to continue to
generate a huge amount of interest in 2006, as more and more people
look to it to help them deliver IT which is more responsive to the
needs of business.
Although some industry analysts predict that SOA is soon to
become a mainstream proposition, there is still a lot of confusion
and misunderstanding in the industry about what SOA is and why it
is important.
The more misunderstanding there is, the more opportunities will
be missed, and the more challenges and risks will go unmanaged.
Let's start from first principles. But I won't bore you with
talk of Soap, WSDL, UDDI or any one of a hundred other acronyms;
instead, I want to concentrate on a broader perspective of what the
"S" and the "A" in SOA mean.
Both "service" and "architecture" have meaning far beyond the
context within which most discussion of SOA is taking place.
The idea of a service is something that is relevant not only to
how you build, deploy and integrate application software - the "web
services perspective" - it is an opportunity to capture and
formalise the way in which IT in general is delivered.
Why? Because the concept of a service in the context of IT is
something with a long heritage, and there are many perspectives,
all of which have value and all of which are going to remain in
place, even when Soap (Simple Object Access Protocol) and WSDL (Web
Services Description Language) are old hat.
For example, in the world of systems management tools, there has
long been talk of service management, which aims to aggregate and
abstract operational system metrics to a level where they can be
measured against high-level service level agreements defined for
business services.
In the world of IT helpdesk tools, suppliers and users talk of
service management in terms of improving how IT problems are solved
by support staff. In the world of systems integration and
consulting, IT services describe things like software development,
integration and IT maintenance activities that are carried out by
engineers.
In this context, SOA makes the most sense as a way of thinking
about IT that explicitly recognises that all IT organisations are
service providers, with customers that have a variety of needs. And
SOA should help IT departments act in a systematic way that
improves the overall quality of the service that they provide to
those customers.
Soap, WSDL and their cousins may be merely the mortar that holds
the bricks together that make the overall house, but it is the
adoption of these standard software interface protocols by the IT
industry, coupled with increasing maturity in all the areas
outlined above, that makes SOA such a powerful force. SOA can, and
should, encompass all the perspectives on "IT service" outlined
above.
In our discussions of SOA, we distinguish three types of IT
service, all of which play a role in helping organisations get
business value out of IT:
- Business function services. The content of these services is
the core of what provides direct value to consumers, by automating
aspects of particular business functions.
- Infrastructure services. These services play a supporting role
in delivering value to the ultimate service user, by providing the
underlying platform over which business function services are
delivered.
- Lifecycle services. These are the wrapper which in the vast
majority of situations provide the real services which IT users
experience. Lifecycle services are responsible for the design,
implementation, operation and alteration of infrastructure and
business function services.
In reality, all these perspectives are interrelated in the
service-based delivery of IT. They all have to be considered if SOA
is going to live up to its promise of making IT more responsive to
the needs of business.
There is another aspect in which the definition of service in
SOA has to be carefully considered - the way in which services can
represent concepts that businesspeople understand. Software
services are not interesting because they can be exposed using WSDL
and interacted with using Soap, or indeed using any other
combination of readily-available interface definition language and
communication protocol.
They are interesting because of what they can represent. Just as
object orientation was valuable primarily because objects could be
representations of real-world objects, service orientation is
valuable primarily because services can be representations of
real-world activities and capabilities of companies.
If we can use SOA to more accurately model how software systems
can implement and automate business activities, SOA's potential
value is really about helping IT organisations and the businesses
they serve start to talk and collaborate using a common
language.
Architecture is not (or should not be) just a fancy way of
saying design. If we were to take that road, then SOA would just be
what a lot of people think it is: a way of designing systems so
that they are composed of loosely coupled units of software.
But architecture is different from design. It operates at a
larger scope and scale. Architecture is about forethought and
planning "in the large" - above the level of individual projects
and initiatives. In the context of SOA, the role of architecture
concerns setting policies and rules that govern the design of
individual services and systems, to maximise the overall value of a
service portfolio to the business.
This is a question of service granularity and reusability, of
representations and interactions, of semantics and much more. It is
also a question of strictly non-technical things like how you
organise and govern the IT function, and the way that the business
and IT work together to direct investment.
Fundamentally, in the context of SOA, architecture is about
laying the foundations for building a common language between IT
and the business. It is something you do - not something you build
or implement.
Neil Ward-Dutton is co-founder of analyst and advisory firm
MWD. Next month in Computer Weekly he will examine building reuse
into SOA initiatives