No amount of testing will catch every error, of course. Transactional errors can be caught as part of the monitoring process. But to identify logical errors in the services themselves at run time, the calling services must look at the returned message to see whether there is a mismatch in format, policy, or other expected attribute, based on the business process specifications, Moreland says.

Staying close to home

The choice of development platforms, registries/repositories, management schemes, messaging systems, security technology, and testing tools is dizzying. It’s easy to get caught up in tactical decisions, such as whether to buy an ESB and from whom. But the approach you pick should come after you have defined your business processes, core services, and overall architecture.

“The alphabet soup discussion is a distraction,” says Bill Adiletta, president of consultancy TekFinancial Solutions. Rather than attempting to evaluate all the possible technologies, see what you already have and exclude whatever doesn’t support your needs. If no internal technologies do the job, then look at vendor offerings. Of the remaining candidates, pick those that fit most closely with your existing technology base and skill set and eschew proprietary technologies as much as possible, he says.

The Hartford takes that approach, too. “Our vendor philosophy is: ‘The easier it is to replace you, the more we like you,’ ” Moreland says.

“Your technology choices should be based on what you already have and what you need that it can’t deliver,” says Judith Hurwitz, president of consultancy Hurwitz & Associates.

“If you have a deep commitment to SAP, for example, then NetWeaver might be worth leveraging,” Hurwitz says. “If you don’t, then take a hard look at your applications before exposing them as services. You have to look at the component parts first, then decide what you need. As the services become clearer, you then look at technologies such as service buses and business process engines to manage them as needed.”

GM, for example, used its J2EE platform for its first Web services efforts in 2001, an online shopping service that consolidated all 14 GM car brands. Hong Zhang, chief architect at GM’s Emerging Technology Group, liked the fact that J2EE had a separate layer for data access, which made it easier to handle the many data sources without creating business process dependencies around them.

But Zhang says he’s not wedded to J2EE or any specific technology. “You need to focus on the services and how they implement the business processes. Technologies come and go and will evolve,” he notes.

In the big picture, specific platforms and technologies represent tactical, not strategic decisions. After all, in SOA, the processes, data flow, data definitions, service interfaces, policies, and so forth should be abstracted so they have no dependencies on specific technologies. Burton analyst Manes describes the challenge as “enterprisewide planning with local implementation. SOA is not middleware.” If properly considered, “it can be done with any middleware,” she adds.

TekFinancial’s Adiletta agrees: “Use the strong governance model to agree on the standards: service definition, naming conventions, utilities, etc. The worst way is to start with the technology and say what it can or cannot do.”