The best way to manage version control is to design for it in the first place, The Hartford’s Moreland says. “Go in with the expectation that you will retire it,” he says, such as by setting -- and enforcing -- end-of-life periods for all services. And while you have multiple versions of a service running during the necessary transition time, use translation services wherever possible to map calls to the old service instead to the new one, filling in any new data that can be derived or assumed in the translation.
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.