A clear path to SOA

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


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.

Read more on Web software