History is not on our side. Organisations have wasted
vast amounts of money and time chasing suppliers' claims, consumed
by the notion that investing in IT is going to help them make more
money. Various middleware and integration stacks have been deployed
in a bid to facilitate increased flexibility, yet we seem no
further on.
Although software suppliers would like us to buy into the vision
of organisations running their software wall-to-wall, the reality
is that heterogeneous IT is very much the norm. As a consequence, a
vast proportion of IT budgets are eaten up trying to manage
complexity.
This is an intricate mix of maintenance, additional custom
development, integration and change management, which constrains
the IT department and puts a firm lid on innovation. Add to this
the demands of modern business for 24x7 operations, high
availability of systems, and the challenge of integration, and it
is little wonder that IT impedes the speed with which businesses
can execute. For many organisations technology has had the effect
of casting processes in "concrete boots", making agility a
laughable notion.
Regardless of the capabilities or potential that a service
oriented architecture may have, if we approach it with the tired
techno-centric mentality of the past then we are not even giving it
a fighting chance. Unfortunately, many organisations have already
started down this road, somehow convinced that it was the
technology that let them down last time and that all they needed
were better tools and standards.
Although standards have evolved and supplier tools are now more
aligned with requirements and business processes, SOA conceptually
delivers nothing new. Putting blind faith in it is a sure-fire way
to court disaster.
What is needed is a middle ground - one that recognises and
accepts the promise of SOA without getting carried away, and which
acknowledges the problems and practical issues encountered with
other component- based notions.
SOA needs to be approached from a balanced and considered view.
Unfortunately this is extremely difficult. Firstly, reaching a
common understanding of exactly where SOA starts and finishes is
difficult. Definitions range from the narrow and technical, to the
broad and eclectic. Again, in order to extract any kind of sensible
meaning out of it, SOA needs to be defined somewhere in between
these two extremes.
It is not just technology - SOA does not come on a disc, nor can
it be installed. Similarly, it is more that just a concept or idea.
SOA is a series of design principles, based on the concept of
service definition, discovery and reuse. These principles are
underpinned by an integration architecture that supports the
creation of services from underlying applications and their
components, and which in turn allows services to be loosely bound
to one another at runtime.
Critically, within an SOA services are entirely self-contained
and completely independent of the underlying technologies. This
marks out SOA from previous component technologies such as Corba
and Com, which remained technology-dependent. In this respect, SOA
is something of a logical evolution from web services, which
provide the technical isolation between the transport and
application layer and the notional services layer.
Much is made of the ability of a SOA to "join business to IT".
Again, this is far from being a new idea. Indeed, the phrase is so
often used it is a clich‚. However, SOA concepts can foster closer
integration between business and IT, but only if approached with
the right mindset.
SOA allows, or even encourages, organisations to consider the
role that application components and services play in business
processes. Organisations approach this challenge in one of three
main ways.
By the academic textbook
Starting with an understanding of a particular process (which in
itself can be a challenge), line-of-business experts and business
analysts will model the desired process.
By understanding the various steps and participants within a
particular process, they will then define the high-level business
services required to execute the process.
Finally, they will engage with IT in order to map these business
services onto the underlying technology and infrastructure
services. Although some organisations have been able to establish
their SOA through a top- down, process-driven approach, it is
several steps too far removed for most.
By the IT manual
This bottom-up approach is the antithesis of textbook approach,
and starts with the IT department creating reusable services out of
IT assets. Technically, this is straightforward - there is a
plethora of development tools that support the web service
enablement of interfaces and components.
Without knowing the context of the business processes that will
eventually consume the service, developers will inevitably fail to
create the service with the right level of granularity or
functionality. In time this situation will become anarchic, with a
multitude of services and, unsurprisingly, little or no reuse.
This characterises a large proportion of SOA initiatives which,
unless the situation is addressed rapidly, are set to fail.
By the blueprint
The problem with both of the above approaches is that they lack
structure or discipline and do not even begin to address the SOA
lifecycle. The first fails to capture the needs, limitations and
restrictions imposed by IT, and the second ignores the requirements
of the business.
Middle ground must again be sought with a methodology that
simultaneously respects the needs of business, and the practical
reality and complexity of IT. This will be a highly iterative
process which sees the needs of the business reflected in the
development process, with agreement and collaboration between the
two on the requirements and design of business services. Industry
blueprints and methodologies are starting to emerge in an attempt
to capture best practice and encourage organisations to think more
strategically about SOA and the supporting architecture. It is with
these initiatives that the hope and promise for SOA currently
rests.
One of the frustrating mistakes I consistently observe with
regard to SOA is that organisations seem to expect reuse to happen
by magic. Not only is this frustrating, it is also somewhat
depressing - have we really learnt nothing from our experiences
with Corba and object orientation?
The industry's failure to achieve service reuse after many years
and different technologies is the equivalent of obsessive
compulsive disorder in humans. We know what we are doing is not
productive, but seem unable or unwilling to change.
Maybe the situation is not quite as bleak as that, as some high
profile successes with SOA help to prove. However, scratch beneath
the surface of these glossy case studies and you will find some
stark home truths: SOA is hard, complex and expensive to do right,
and it absolutely depends on a business oriented view of service
design and reuse.
If you are not prepared to commit to SOA and to invest in
radical change, then the only thing you are prepared for is
failure.
SOA moves us away from building systems and standalone
applications to the creation of reusable business services.
However, this will only be realised if the developers creating the
services move in the same direction.
Both culturally and from the point of view of rewards and
incentives, the desire has to be there to find and reuse existing
services, rather than creating new ones. Where services do not
exist, a controlled process needs to be enforced to ensure that
there is agreement on the definition, functionality and metadata
appended to the new service, in order to encourage and facilitate
its subsequent reuse.
Ian Charlesworth is a senior analyst at Ovum, where he leads
research on integration