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 "enterprise-wide 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."

What does matter is engineering your SOA efforts, taking the architecture and business processes and then figuring out the implementation requirements, acceptable trade-offs, likely data and process flows, and management and performance needs. With those understood, you can use whatever technologies you like to construct the actual services and supporting infrastructure.

"SOA deployments should follow a federated model, of incremental deployments in a loose way, but with the same goals and direction," consultant Hurwitz says. "Start off with a set of rules on how you do SOA, so people have the same philosophy and approach in mind on each project."