Just over a quarter of respondents to the InformationWeek survey who are measuring ROI for SOA projects already see a return, and 42% expect to realize one within a year. It's easier to achieve ROI goals if companies review their IT architectures before they plunge into developing services. That way they'll know if they need to build a service from scratch or if its components already are in the business logic of an existing system.
Aerospace and defense contractor Rockwell Collins Inc. did a review before it began work on a Web service that would let customers such as Airbus S.A.S. and Boeing Corp. tap into its SAP applications to look up repair projects. It found that while the repair-status service existed as logic in the company's customer-service portal, getting project-status information still required assistance from a customer-service rep, says Shawn Furgason, manager of Web delivery at Rockwell Collins. Two months ago, the company built a Web service linking the portal directly to the SAP systems, turning customer service into customer self-service.
Rockwell Collins plans to launch six more services in the next quarter. Developers' "initial reaction was, 'This is going to be harder and cost more,'" Furgason says. Now he sees the "resistance giving way to advocacy." Many companies are taking it slow. More than a third of respondents to the survey say they expect to spend less than $250,000 on systems incorporating SOA and Web-services technologies this year.
Developers might be coming around, but IT architects can't seem to agree on what's needed to deliver an SOA. One disputed infrastructure pillar is an enterprise service bus, which, like the messaging middleware before it, guarantees delivery of a message by requiring an acknowledgement of receipt. Some SOA adopters say the job can't be done without one. Con-Way is using one and Highmark is contemplating doing so. But others say it's optional, and besides, the suppliers of enterprise service buses haven't agreed on a standard. Enterprise service buses are an example of "vendor-driven confusion" on SOAs, says Jason Bloomberg, an analyst at ZapThink. If you've invested in BEA Systems, IBM, or Tibco Software middleware, "you don't need to buy that much new software."
Beyond The Walls
Companies like Con-Way, Highmark, and Rockwell Collins are comfortable with extending their SOA systems beyond their four walls. They share that attitude with 69% of survey respondents, who say their companies use service-oriented architectures and Web services for internal and external applications. At Amazon.com Inc., an ever-changing SOA drives the actions of some 120,000 developers at other companies who produce apps for selling goods through the retailer.
Take Amazon's E-commerce service, which outside developers use to connect with shoppers through an Amazon-provided API. To them, that's a fixed and stable interface, but behind the scenes, Amazon is constantly updating it using a service-based architecture approach, though the retailer declines to name what technology it's using. Amazon has about 15 such services, says Jeff Barr, Web-services evangelist for the retailer. With SOA, "you need to present an idealized view of your company to the outside world," Barr says.
Depending on the business, a single-service API may have many slight variations of a Web service behind it. That's the case at MedicAlert Foundation, a nonprofit organization that uses an SOA platform to handle a medical-records storage function. The underlying technology for MedicAlert's SOA applications for different insurers had to be tweaked repeatedly, leading to multiple versions of the same service, says Jorge Mercado, a MedicAlert SOA architect. Failing to provide service versioning to manage multiple versions often trips up companies trying to implement a service-oriented architecture, Mercado says. To avoid that, MedicAlert installed AmberPoint Inc.'s services-management product, which ensures that response times to queries are met, among other aspects of service management.
As enthusiasm grows for SOAs, it's important not to get carried away and try to build a service that will be reused under all circumstances. Developers enter "analysis paralysis trying to think of every possible way a service will be used," says Rockwell Collins' Furgason. The goal is to develop a service that can be used across more than one application but not necessarily every possible application, Furgason says. "It can be extended later."
The answer is a mix of solving today's problems and imagining the future's. As Highmark plans to expand its SOA offerings, it's identifying what business processes might be captured as services and thinking about new ones. "You try to get a better understanding of the business," Free says. "What business goal are we trying to accomplish? Then a light goes off in your head. You can see the service and how to implement it and you think, 'This service stuff is really cool.'"
Illustration by John Francis
Safer With SOAs--Or Not?