Organizations that struggle with implementing SOA and Web services also tend to make another miscalculation, says Chris Spurgat, president of Object Partners, an IT consulting company in Minneapolis. They pour all of their energy into building services that can be reused across the organization, instead of first focusing on ensuring they’re usable in one part of the business. Making reusability the chief goal often results in shortchanging the organization’s current needs.

“First, figure out how the service can be used today by existing applications, something which is already defined. Build the service that way and then let it grow and evolve as you find new uses for it,” Spurgat says. “If it becomes reusable across other applications or units, that’s gravy.”

Richards believes SOA’s most overlooked problem is how the data underlying linked applications is affected by the architecture. “The merging of services in SOA is fairly easy, but the consolidation of data involved is not nearly as straightforward,” he says. For example, an organization might have five different ways of keeping customer records in five silos or units of the organization; some records might be kept by full customer name, others by abbreviations, yet others identified by demographic information. So when an employee does a “customer lookup,” from which of those five systems is that information pulled, and what are the implications of that request?

“People in business units are keen on the idea of Web services, but my experience is you don’t dare touch their data,” Richards says. That concern has fueled the use of tools such data buses, a subsystem that transfers data between central processors and all internal devices. Unlike point to point connections, buses can connect several peripherals over the same set of wires. These buses can consolidate and abstract data for particular user purposes or “views.”

Getting companies with multiple business units to agree on requirements for Web services and their underlying data can be a major challenge, Spurgat says. Questions such as who owns the data and how it might consolidated should be dealt with up front in any SOA effort “because it can literally make or break that effort,” he says.