Work In Progress

Service-oriented architectures are promoted as a model of efficiency for software development, a way of bringing plug-and-play ease to software "services." But implementing them hasn't been easy, with some companies finding that SOAs add complexity rather than simplicity.

Nearly a third of companies using them say service-oriented architectures are falling short of expectations, according to an InformationWeek Research survey. Among this group, a quarter have seen growing complexity in their IT systems, a third have been hit with higher-than-expected costs, and half report trouble cost-effectively integrating legacy systems into new software-development processes. It's a disappointing report card for a technical philosophy that's meant to guide software projects for years to come.

Software honchos haven't given up on SOAs, and many continue to be believe that their efforts will be worth the frustrations. In our survey of 120 business-technology professionals, respondents cited IT platform standardization, business-process automation, business flexibility, and operational savings as the leading business drivers behind their moves to service-oriented architectures.

The hard part is getting there. SOAs involve more than a few software services that get used across a couple of applications. They require a fundamental change in an IT organization's approach to software development, a broader role for business analysts, a clear understanding of employee and customer needs, and a plan for managing and securing the services that are key to it all.

The transition to service-oriented architectures from monolithic apps, where a big mass of code runs a series of processes from start to finish, is on the same scale as the move from mainframes to client-server systems, contends Gary Free, senior systems consultant at health insurer Highmark Inc., and it's fraught with as much uncertainty. "It's a totally different way of looking at things," says Free, lead architect for what Highmark considers its first true SOA project, revamping its entire claims-processing system.Limited Scale

Highmark is like most companies in that it's implementing a new architecture on a limited scale. It's already using a Web service it built a year ago that lets the insurer provide in seconds an automated response to queries from the University of Pittsburgh Medical Center about a patient's insurance coverage. The Web service converts a query from one of 19 hospital registration systems into an XML message that's moved over a network to Highmark's WebSphereMQ middleware, which then moves the message to Highmark's mainframe eligibility-status systems. Now Highmark is working with IBM Global Services to rebuild its claims-processing system as a set of reusable services, an effort that's likely to take three to five years, Free says.

That's infinitely more complicated than building a solitary Web service, and Free isn't sure he's got everybody in sync with the new thinking that a service-oriented architecture requires. "The No. 1 pitfall to getting to SOA is the developers' attitude of, 'We're doing that already,'" Free says, which comes from their belief that any componentized project is a service-oriented architecture. Highmark considers the SOA a critical part of a strategic information-systems plan the company developed in 2003 to get IT more connected with the business. But left to their own devices, developers--even those experienced at building modular software, as Highmark's were--won't necessarily succeed at this goal. When IT builds services, it typically does so from components that are convenient to put together, which doesn't necessarily match the grander vision of an SOA automating the right processes to fulfill business needs. IBM's Services Oriented Modeling and Architecture methodology helped Highmark identify its unique business advantage--in this case, its close relationship with the University of Pittsburgh Medical Center, the region's largest health-care provider--and which components to put together as a service to exploit that advantage.

An architecture needs to lay out a pattern of how a company will build software for the future and assess whether something even ought to be built. "People are forgetting the A in SOA," says Ron Schmelzer, analyst with technology consulting firm ZapThink. Multiple Web services strung together do not an SOA make. That approach ultimately drains IT departments as staffers try to monitor service levels and enforce policies across a growing string of scattered applets.

Deep Understanding Needed It takes both services and custom code to implement applications in service-oriented architectures and sharp business analysts to relate the requirements for an application to discrete processes. Highmark is considering creating a role of "SOA business-process analyst" to formulate a deep understanding of the company's business and identify frequently repeated processes that can be rebuilt as services, says VP of technology Michael Kronenwetter. Not all processes are so deserving; those that aren't will be built as custom application code or will continue chugging away as part of the 6 million lines of custom code in Highmark's legacy applications.

At freight hauler Con-Way Transportation Services Inc., Praveen Sharabu, director of enterprise architecture, understands the need for careful design to ensure data integrity. Con-Way started turning apps into components eight years ago, giving it a jump when an SOA became a goal in 2002. Con-Way uses IBM's WebSphere Application Developer, WebSphere Application Server, and WebSphereMQ messaging middleware to develop apps in Java.

But developing a service-oriented architecture to support its 70,000 customers meant closely matching the decisions customers need to make with the options Con-Way presents online. For instance, services had to be designed so that customers requesting a long-haul shipment provide all the data Con-Way would need to rate that shipment. "You have to cement data into the current status of the shipment--when it needs to be picked up, how it's rated, when it needs to be loaded and dispatched," Sharabu says.

Con-Way also had to follow good data-integrity practices with the new services. Data changes during any step of a service aren't committed to the database unless all steps are completed: If one fails, all data changes must be backed out. By ensuring that a business process is completed, Con-Way preserves data integrity. "We had to struggle with that," he says. "We had to ask, 'Are we leaving the data in a stable state?'"Con-Way is meeting what Ali Arsanjani, chief architect for SOA and Web services at IBM's Center For Excellence, calls "the litmus test of an SOA service": whether it serves a business user's needs. The second test, he says, is whether it eliminates redundancy. In Highmark's case, as it develops its architecture, it plans to encapsulate within a single service what now are separate steps of reading medical procedure codes and identifying the health-care provider for each claim. All told, 6,000 programs comprise Highmark's legacy apps, with many repeating the same function over and over again. "The ROI of developing reusable components is a big plus," Free says.

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.

Coming Around

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.

Version VisionDepending 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

Continue to the sidebar:
Safer With SOAs--Or Not?0