Implementing web services within a service-oriented architecture is supposed to reduce integration headaches.

	express delivery
	• print  • comment
	Enterprises implementing SOA aim to maximize the benefits while minimizing unforeseen burdens: Every potential way forward has hidden pitfalls Incumbent vendors are likely to be offering SOA capability Others recommend using ESB or emerging web services standards SOA requires a management and control infrastructure of its own Organizations should pick short-term goals within the context of a long-term plan
	Glossary terms: SOA, ESB, web services, lookup tool Sponsored links: your text link here

But with so many products and packages in the market that claim to offer the best foundation for SOA — all accompanied by dire warnings of what could go wrong if customers choose a different path — most IT buyers are rightly wary.

Picking the right starting point is vital, especially when there are vast areas of existing infrastructure that web services cannot yet reliably integrate with. But with no proven best practice yet established in the field, vendors are as much in the dark about what really works as their customers are. Solutions that claim to bridge the gaps, such as enterprise services bus (ESB), have their own drawbacks, while established players with an existing product set often bring along baggage of their own. "You're always worried you've got this huge iceberg coming along under the surface that you don't need," says Kevin Poulter, application technology manager at British American Tobacco, an early adopter whose SOA went live last year and already has production services in operation.

The challenge that early adopters face is to make choices that maximize the benefits while minimizing the unforeseen burdens that new technologies always seem to bring along with them. The most significant pitfalls lie along two critical dimensions: getting the interface right between the new technology and the organization's existing infrastructure; and maintaining control of the new architecture as it evolves.

There are any number of choices for aligning an SOA with the existing infrastructure. For starters, every incumbent vendor is likely to offer their own flavor of SOA capability. Others claim the best way to avoid becoming dependent on a specific platform within the existing infrastructure is to link them all via ESB. Some say the only way to avoid vendor lock-in is to remain faithful to the emerging web services standards stack.

Getting started

With so many conflicting voices, it's no surprise that enterprises are often unsure how to approach an SOA strategy. "What customers most of all want to know today is how to get started on this," says Mark Carges, CTO of BEA Systems. He recommends identifying some initial goals that will provide a business case for starting to put the infrastructure in place. "The key is to set out so that over time, you've got this blueprint." Once the SOA begins to take shape, future projects will cost less because they can take advantage of the emerging shared-services infrastructure: "The key phrase here is operating leverage," he explains. "Each new application doesn't cost the whole amount."

This approach allows an organization to defer clarifying elements of the blueprint that currently seem unclear, such as how much of the architecture will be web services based, or when it will converge with future SOA standards. With no proven roadmap that anyone can rely on today, this is a pragmatic approach, but it carries a high risk of tripping over pitfalls along that other critical dimension: maintaining control of the new architecture as it evolves.

It's becoming evident from the experiences of early adopters that an SOA requires mechanisms for oversight, policy governance and change management — and that these mechanisms typically have to be supported by automated tools rather than being left to manual processes, which can easily be overwhelmed. This means adding a further layer of infrastructure to control the development, deployment and usage of services, on top of the layers that manage the underlying messaging technologies.

"It's a long journey," says BAT's Poulter. The important thing is to be able to have some projects that can produce early evidence of the benefits, he says, but to keep the long view in mind at the same time. "We're probably three years into it and we've got another ten to go. It is a long-term thing."

This is an abridged extract from a four-page feature article published in this month's Loosely Coupled monthly digest. To read more about the SOA implementation and governance strategies of early adopters and the vendors they work with, subscribe here today.

More on this topic