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.

	It was important that Con-Way preserve the integrity of its data when moving to a service-oriented architecture, Sharabu 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.

Counting On Service-Oriented Architectures
41% say SOAs or Web services are very important to business goals	69% say SOAs or Web services met or exceeded expectations	82% say a goal of SOAs is to make app development more flexible	36% are adopting SOAs or Web services to increase customer satisfaction and revenue	37% say standards for Web services are being established too slowly
Data: InformationWeek SOA/Web-services survey of 120 business-technology professionals

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?'"