SOAs promise business benefits but users need to be
clear about what they are trying to achieve if systems are to be
successful. Cliff Saran charts the route from theory to
real-world application.
The whole of the IT world seems to be talking about service
oriented architecture (SOA), but many people are unclear about what
it means in practice. To understand SOA, it helps to know how it
was developed and the needs it is designed to address.
According to analyst firm Ovum, SOA is the latest in a series of
approaches to provide organisations with a technology framework for
designing and integrating reusable software components.
Since the 1990s, when people realised the inefficiencies of
running monolithic applications on ever larger and more expensive
mainframe hardware, there has been a demand for different computer
systems to communicate in a standard way. Networking protocols such
as TCP/IP have enabled computers to share information via a network
cable. What users wanted was a straightforward way for applications
to do something useful with this information in a controlled and
managed way.
Early attempts in the 1990s came from open standards such as DCE
(Distributed Computing Environment) and RPC (Remote Procedure
Call). Such standards allowed one application - the client - to
initiate a process within another application - the server.
By the mid-1990s, the trend in software development was towards
treating code as objects. By splitting their programs into a series
of simpler components or objects, developers could reuse some of
the code they had written for one program in another, possibly
completely different, program.
To complement this object oriented model of programming, two
further approaches to inter-application communications appeared:
Corba (Common Object Request Broker Architecture) from the Object
Management Group (OMG), and DCom (Distributed Common Object Model)
from Microsoft.
By the late 1990s, the industry had moved on again. Users were
reluctant to be tied into the complexities of an architecture such
as Corba; and they were unhappy being locked into something
proprietary such as DCom, which was very much Windows-based.
At the same time, software companies started offering tools to
address the common problem of how to link together all the separate
silos of information within an organisation. As users bought new IT
systems, they were increasingly faced with the challenge of how to
share information. Although Corba and DCom applications could
exchange data, most applications could not.
Enterprise application integration (EAI) was the way forward and
the industry developed sophisticated brokering middleware that
could connect to commercial applications, transform data from one
format to another, and automate business workflows between
applications. The drawback with EAI was that user projects to link
every major application used in a company could take a long time
and were expensive and complex.
Instead, users looked to provide simpler integration between
applications by building point-to-point links between them. But as
the number of such links increased, users found themselves managing
"spaghetti code", containing countless, unmanageable links.
The advent of Java and the success of the web gave the IT
industry another chance to show it could tackle the problem of
application interoperability. A general consensus was achieved and
the era of web services was born.
The idea of a web service is that although an application can be
written in any language and run on any operating system, it must
provide an external standardised interface - a bit like an
application programming interface. A web service interface may not
be proprietary and must conform to an Internet Engineering Task
Force specification known as Soap (Simple Object Access
Protocol).
With a common Soap-based interface, one application could invoke
services in another application by sending specially formatted XML
messages using the Soap mechanism. A directory of available
services can be made available through a look-up table called UDDI
(Universal Description, Discovery and Integration), an XML-based
registry that allows organisations to find web services that can be
reused in software projects.
The logical extension of web services is the service oriented
architecture, says Teresa Jones, senior research analyst at Butler
Group. "SOA is an architectural design style for assembling web
services into high-level applications." Jones says that although
users have understood the need to think in terms of a services
approach to IT, web services have allowed SOA to work. It provides
standard interfaces that are essential to manage services. Jones
regards SOA as management for web services, providing the necessary
support for service level agreements, authorisation and contractual
tie-in.
Along with the management aspects, an SOA has to ensure that web
services are used in a controlled manner. Otherwise, users could
end up with applications creating an anarchic slew of
point-to-point connections to web services, resulting in spaghetti
integration. It would be far better if a separate dedicated
application managed all the web service connections, converting
data to a different format and firing off a web service to initiate
a new business process in response to some internal or external
change.
Enter the enterprise service bus (ESB), which users can deploy
to manage web services within an SOA. Jones says, "An ESB
facilitates communications between web services, orchestrating data
transformations and content-based routing."
One organisation looking at SOA is Great Ormond Street Hospital.
Head of IT Marc Saldanha has been using SeeBeyond's Integrated
Composite Application Network (now part of Sun's Java Composite
Application Platform Suite) to build services that can be mixed and
matched. "We have always built process-based applications and these
lend themselves to the SOA ideal," he says.
Saldanha is building on the SOA and has a wide variety of
projects on the go. He says the applications under development for
the SOA are relatively simple, such as driving a data entry form to
contract to a back-end system, as in a request system to book
annual leave. Saldanha's advice for anyone looking to develop an
SOA is, "Start simple and build up - we have fairly simple projects
because we want to build an understanding of SOA."
Starting simple makes it possible to look at different
approaches to the same problem. In the case of the Great Ormond
Street customer relationship management system, which manages
donations, there are two ways to consider a donor: individually or
as a group. The initial SOA implementation treats each donor as an
individual, but Saldanha says, "As a purist, I want to deal with
donors as individuals, but you have to weigh the efficiency." He
intends to test the other option, where donors are treated as a
group, in one service because there are fewer overheads.
An interesting point is that this application uses a Microsoft
Com (Common Object Model interface. Using the SeeBeyond software,
Saldanha has created a wrapper around the interface, allowing the
application to be used in an SOA.
At Heathrow's Terminal 5, due to open in April 2008, airport
operator BAA is using an SOA to handle events such as baggage
delays at other airports around the world affecting Heathrow
customers. Nick Gaines, head of systems and IT at Terminal 5, says,
"Integration is necessary. If we could not get data from national
air traffic control or the airlines, the airport would be severely
restricted."
As with Great Ormond Street, the SOA at Terminal 5 is
incremental. "We will not change our standard interfaces," says
Gaines. The external interfaces to systems such as baggage handling
and national air traffic control are unchanged. Instead, he is
using Progress Software's Sonic ESB to mediate between the old
systems and the new IT.
Sonic ESB allows users to configure workflows and data
transformations. This is something that needs to be managed
carefully at an airport, says Gaines.
All web services for Terminal 5 are defined in an XML
repository, access to which is tightly controlled. Gaines says, "It
is very easy with an SOA to get a programming whizzkid to change a
configuration. We will not need that in an airport
environment."
The SOA is governed by a system integration steering committee,
which monitors and manages all changes to web services definitions.
There is a formal sign-off process before a new or modified web
service is put into the repository, involving an independent
assessment to check the quality of the work, says Gaines.
Gaines advises users who are considering developing a SOA to
stick closely to industry standards. "These systems are very
immature," he says. Gaines has found he has needed specialist
skills. Although it is possible to find system designers who
understand "solutions", Gaines says it is important to have someone
who can consider the whole business model, design, systems
development and the future of IT. "The maturity of IT in this area
is such that there are very few good people," he says.
This is the reasoning behind BAA's decision to use a business
partner, Ultra, which specialises in airport information systems,
to implement the SOA. Gaines' internal operational team is being
trained to use Sonic ESB, allowing internal staff to support the
application when Terminal 5 goes live.
SOA moves users away from building systems and standalone
applications to the creation of reusable business services.
However, Ian Charlesworth, senior analyst at Ovum, says, "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 create new ones."
Ovum advises users to invest in tools and control mechanisms to
ensure that best-practice principles are documented and adhered to.
Charlesworth recommends clearly defining and widely publicising
such policies.
Click here for: Getting more than integration from
SOA
ERP suppliers' SOA plans could cut upgrade
costs
Enterprise resource planning software suppliers such as Oracle
and SAP are looking to transform their offerings from monolithic
applications to more flexible systems based on a service oriented
architecture.
With the SOA approach, business applications still operate as an
integrated system but the processes behind them are not bundled
together. Analyst firm Gartner says this could enable suppliers to
deliver componentised functional enhancements more quickly and
could lead to easier, cheaper upgrades for users.
Many businesses are unable to take advantage of software
enhancements bundled as large, complex, interdependent upgrades
because integrated systems that control a breadth of processes have
long and costly upgrade cycles.
As packages move from a tight-coupling to loose-coupling model
(as business processes are unbundled and componentised), so users
will have the flexibility to take advantage of them in an isolated
manner, says Gartner.
Case study: SOA speeds mortgage sales
system
When Milton Jones, chief information officer at new national
mortgage network Home of Choice, was given three months to build an
IT system to support third-party financial advisers, he opted for
the SOA approach.
The application had to provide online registration,
online/offline sales processing, automated and personalised
suitability letter processing, and commission information.
"It was too expensive to build something from the ground up,"
says Jones. "I could not have a team of developers."
A reusable component-based approach was essential, so Jones
looked for a supplier that could provide pre-built components. He
selected Focus Solutions, whose MCA system is built around an SOA,
with BEA Weblogic 8.1 providing integration and code generation for
the project.
"Focus had components already but others had to be developed
quickly and adapted to meet Financial Services Authority
regulations," says Jones.
The project team consisted of developers from Focus plus
technical and business staff from Home of Choice to ensure that the
system satisfied business and compliance needs.
The project began in March 2005 and the first part, a financial
adviser recruitment system, was completed in April. A sales support
system was delivered two months later and a commission processing
system a month after that.
Home of Choice says up to 80% of all enquiries from third-party
financial advisers are now dealt with via the automated sales
support systems. Jones is now planning to train his internal IT
team to take on responsibility for low-level maintenance of the
system.
"The SOA ties the business closely to IT," he says, providing a
rapid mechanism to implement business change.