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 modeling, 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."

For further information, please contact: press@epam.com