Service oriented architecture
(SOA) is frequently touted as the "silver bullet"
for complex IT integration problems. And with business factors
like mobility, flexibility, governance, compliance,
collaboration and security placing extra expectations on the IT
infrastructure, SOA is an approach more and more IT departments
are adopting to respond to ever changing
requirements.
While it is widely understood that SOA involves tools,
integration, web services technologies and process modelling, it
may not be so obvious what new investment is needed for a
successful strategic SOA deployment.
Know your requirements
"A lot of people know what they want from SOA - speed of change,
integration, turning IT into a service for the business - but they
do not actually know what SOA is," says
Neil Ward-Dutton, research director at
specialist IT advisory firm
Macehiter Ward-Dutton.
According to Ward-Dutton, this lack of clarity could make it
difficult to make sense of a market where, "if Gartner says an
enterprise service bus (ESB) is a key SOA technology, suddenly
every supplier has one".
All the major integration and middleware companies have updated
their portfolios in the past few years to include some form of SOA
technology at a very high level, says Ward-Dutton.
"At that level they all do the same basic thing. They all
provide some level of application integration, but in a more
standards-based way."
But SOA is about defined units of work that make up a business
process - billing, for example - and the way corresponding IT
components interact in support of that process, performing a
"service" to the billing part of the business.
Service interactions are defined using a description language.
And each interaction is self-contained and loosely coupled, so they
are independent of each other and reusable, like building
blocks.
In such a context, it is easy to see why the enterprise
application integration (EAI), business process management (BPM)
and middleware technology heritage of many of the most popular SOA
players has given them a headstart in this market. These include
IBM's Websphere and
Rational, Sun's
Seebeyond,
BEA Weblogic and
Tibco's Businessworks and Activematrix.
The seemingly essential ESB, for example, is an enterprise
messaging system found within the software architectures of many
middleware infrastructure products. An ESB provides an abstraction
layer to automate many EAI functions that would otherwise involve
time-consuming coding in a traditional hub and spoke software
architecture approach.
Although an ESB can provide the features with which to implement
SOA, it does not implement one in itself. It usually only provides
a standards-based framework for messaging that relies on web
services.
Simple Object Access Protocol (Soap) based web services are
becoming the most common implementation of SOA here. But the
protocol-independent principles of SOA mean different systems
should be able to communicate with new services in different ways,
and so make use of many other third-party tools and approaches.
But every supplier's SOA approach needs to expose the component
services created, and enable their adaptation and recreation in the
true "building block" sense to offer the flexibility most SOA
proponents crave. Some suppliers offer a design environment to
model these services others rely on programme development tools or
offer application server capability for integrating systems or
knitting them together in a portal environment.
"In SOA, generally, there are service enablers that extend,
interface to or build on existing domains. If you think of the
services above the line masking the integration activity below it,
which involves the ESB, message queuing and so on, then the
orchestration of services takes place above that line, composed in
portals for instance," says Ward-Dutton.
SOA suppliers
Technology suppliers tend to fall into three camps in delivering
these functions, he says. Application servers and EAI tools enable
the reuse of existing components development or modelling tools
allow for the creation of entirely new web services below the line
and above the line, BPM tools, portals and composite application
builders modify and create, or "orchestrate" and "choreograph", new
functions or services, and support their development and lifecycle
according to performance or service expectations of the
business.
"There is so much initial SOA technology around for doing more
with what you already have that all the major players are pretty
good, with IBM gaining the most market exposure," says
Ward-Dutton.
"But when it comes to the building and supporting through a
lifecycle scenario and adopting SOA as a way of doing things across
the board, there are gaps in the market and a lack of case study
evidence."
Tibco recently upgraded its Businessworks ESB to exploit the web
services business process execution language (BPel) 2.0
specification and to allow companies to plug those gaps so IT
departments can deploy SOA more strategically than the commonly
project-led way.
This makes the new Tibco ESB, version number 5.4, the first to
adopt the Organisation for the Advancement of Structured
Information Standards (Oasis) specification. Oasis provides a
common framework and language for specifying business-process
behaviour and the orchestration of processes based on web
services.
BPel 2.0 is now undergoing public review - version 1.1 was never
formally ratified as an Oasis standard - and the organisation has
said 2.0 could be approved as an official standard as early as 1
April.
BPel limitations
Ronald Schmelzer, senior analyst at SOA expert ZapThink,
acknowledges BPel's ability to leverage XML to define orchestration
of multiple web services for business processes. But, like
Ward-Dutton, he is quick to point out that in itself it is not
without its shortcomings in terms of SOA development.
"The problem with the BPel specification is that it still does
not support the human aspects of workflow well," he says.
"And it approaches composition of services from a programmatic
perspective, so some see BPel as simply another way of coding
processes using XML rather than a programming language." Here,
Microsoft, for example, offers the Visual Studio integrated
development environment (IDE), supported by the .net framework.
But, again, this option cannot easily be said to be an
enterprise-wide standard.
David Byrne, group information systems architecture director at
Carphone Warehouse, says he adopted an SOA-led integration strategy
last year. "The fact SOA is moving towards industry standards has
helped raise the capability of the SOA work we do here," he
says.
Carphone Warehouse became a Tibco Businessworks ESB and iProcess
BPM suite user to integrate the various businesses and disparate IT
infrastructure it has acquired with its services portfolio "below
the line".
"I would like to extend the work to couple a lot of business
functionality together as services using modelling as an approach
to capturing business requirements to define the IT processes
supporting those requirements.
"For example, we used to report back to the business on how we
perform largely in terms of the availability of technology
components, but that is not actually very useful," Byrne says.
"It is all about the ability to serve our customers, and because
we are constructing a way of working that is taking us towards a
service-based view of our IT infrastructure, this percolates back
through the service delivery function into a range of services we
really do provide.
"That allows us to structure conversations around meaningful
performance indicators and service level agreements on the ability
to sell handsets or deliver welcome packs, for example."
Betting company William Hill needed to update legacy technology,
while at the same time introducing new services to keep pace with
its growing multichannel, real-time market landscape "above the
line".
Victor Kemeny, group information systems director, says it has
been a people and process challenge to implement SOA, as well as a
technology standards-led one.
"During 2006 we began moving the online betting sports book onto
portal technology to allow the business to dynamically create more
innovative betting opportunities for the punters," he says.
Nail down your specifications
William Hill took on the BEA Weblogic portal in 2005 and moved
to develop an SOA-led project using the expertise of offshore
third-party software engineers Epam.
"I have realised over the past 12 months that to make SOA a
success you really have to nail down every aspect of your technical
architecture, beyond the level of specification you would normally
expect," says Kemeny.
"Nail down your standards from the point of view of high-level
design too, right down to things like your Lightweight Directory
Access Protocol security process.
"Understand the technology standards you are going to work with
and make sure your developers - onshore or offshore - have a
standardised, template-based way of working," says Kemeny.
"There are so many ways to configure systems nowadays. One way
may lead to the same result as another, but be more time-consuming
to code. There is a wealth of tools out there and you should
mandate exactly how you want them used, without stifling the
creativity of your development community."
A key development for Kemeny has been a recent upgrade to
version 9.2 of the Weblogic portal with its content management
system capability - an important feature for managing the company's
ever expanding online sports book.
"Now the system is live, we are looking at how it affects our
business processes so we can avoid extra bespoking or add-ons when
introducing new internet or mobile channels," he says.
His is advice to anyone looking at SOA is, "The technology can
be complex, but you must not forget there are some old-fashioned
processes out there too."
SOA forecast as
key trend in 2007
SOA toolbox
Oracle moves a step closer to Fusion
Comment on this article:
computer.weekly@rbi.co.uk