Officials at Wachovia Corp., Railinc Corp. and other large corporate and government IT shops have taken measures to tackle the myriad challenges that come with using SOA technology, including changing roles for developers and architects and a blurring of the lines between IT development and operations groups.
Wachovia's retail banking division this month started work on a new multiyear SOA project to create business processes from Web services that can be used in a new call-center application and eventually be reused across the bank's various customer channels.
The project is the division's first foray into designing, assembling and managing common business processes that span multiple channels, and the IT shop is feeling the pinch of the transition.
This and an earlier, less-complex SOA project are already presenting challenges to Wachovia developers, who must adjust their mind-sets from the traditional waterfall development approach to a more iterative one, according to Harry Karr, strategic architect for the retail banking division at Charlotte, N.C.-based Wachovia. Using the waterfall approach, developers build monolithic applications in one fell swoop. The iterative approach calls on one group to develop a service, for example, while another builds a client to consume a service, explained Karr.
To ease the taxing transition for its application development group, the division brought in new tools for designing a development process and created new IT roles.
"SOA is a set of best practices, a discipline you have to follow," said Jason Bloomberg, an analyst at ZapThink LLC in Baltimore. "For the developer, this means there are new rules they have to follow. They don't want to follow any rules."
Tools for change
Wachovia used IBM's Information FrameWork -- a set of business models and an information architecture blueprint -- in its project to build common processes from services that can be used by all customer channels.
"We haven't really mastered the business process part of it," Karr acknowledged. "We're trying to figure out how to do a more iterative approach but also outsource. If we had the business processes modeled ahead of time, that might help us." In addition to starting the SOA projects, Wachovia plans to begin outsourcing a significant portion of its development and operations staff over the next year.
The bank has also tapped Flashline Inc. in Cleveland for its services registry, repository and life-cycle management tools. Those should help its developers model the processes, show dependencies and build reports to help manage and understand the effect of the changes, Karr said.
The project continues to evolve as managers hunt for methods to ease the work. For example, Wachovia's IT division last week added a connectivity layer to its architecture. Karr said that the new layer, an enterprise service bus (ESB) from IBM, can handle message orchestration, transformation and routing.
"We're trying to figure out what types of things we have to have in place so the outsourcers can build in this distributed environment," Karr said. "[With the ESB], we can put out some dummy services for the outsourcers to use to test their services with."
The chief architect of enterprise architecture at a large U.S.-based financial institution, who asked not to be named, said recently hired developers there are embracing the organization's shift to SOA. At the same time, veteran mainframe and legacy experts are bucking the change. The plan to use SOA technology "has not been easy for our developers," the architect said.
To ease the transition, the financial institution created a grass-roots community for its 1,200 developers to share best practices and connect with the owners of Web services. In addition, the organization is helping the mainframe and legacy developers fine-tune their skills while it hires new developers for the SOA project, the architect added.
The institution plans over the next 18 months to create an SOA with sufficient security and performance to extend Web services beyond the firewall, the official said.
ZapThink's Bloomberg said that developers often find the cultural changes associated with a move to an SOA more taxing than the technology associated with the shift.
"To move to SOA requires organizational changes across IT and even into lines of business," he said. "Often, the developers have to work with people they may not have worked with much before."
As Cary, N.C.-based Railinc has taken on more SOA projects, the Association of American Railroads subsidiary has created training programs for both developers and recipients of the services to show the benefits of the technology.
Over the past two years, Railinc, which provides supply chain information to 460 railroads, has developed several external Web services for its clients -- including one that went into production in March to allow railroads to report rail-car repairs.
The latest initiative includes various project teams within IT and the lines of business that are creating reusable services for application development, said Garry Grandlienard, Railinc's IT director of enterprise architecture. The project is slated for completion by year's end.
The training sessions aim to show developers and managers the benefits of building an SOA and why they should buy into the concept, he said. "They may have to help build something today, but maybe later this year they may be the recipient of the service," Grandlienard said. "We have to help them see the bigger picture of why this is a good thing to invest in."
The state of Kentucky used senior developers in its early SOA projects and is forming an integration governance group and a competency center to extend training to more of its staff.
The state has built various applications using a service-oriented approach. Among them is an enterprise system that will allow the state's revenue department to streamline the collection of delinquent taxes and a service to allow the U.S. Department of Justice to query Kentucky's sex-offender registry.
Kentucky's IT shop is now moving to tackle its newest SOA challenge -- identifying opportunities to re-engineer business processes and creating the associated supporting infrastructure, said Ashiq Zaman, branch manager in the Office of Application Development in the Commonwealth Office of Technology.
The District of Columbia earlier this year went live with an SOA-based system called CapStat, which uses Web services to help emergency command centers in Washington and surrounding areas coordinate responses in the event of a natural disaster or terrorist attack.
The district also has a program called DCStat that uses Web services to monitor the delivery of municipal services. It has been expanding that program since the beginning of the year.
Despite those efforts, Dan Thomas, director of the DCStat program in the district's Office of the Chief Technology Officer, noted that the city's developers are still "not the biggest believers" in SOA. "Some of my junior developers think all I am doing is adding overhead, and they don't see the value of the reusability yet," Thomas said.
To address such skepticism, his group developed a metadata engine to help track down services as they are mixed and matched to build new applications. The engine associates metadata with data to be used in a service as it is pulled from a source system.
The final payoff
Despite the technical and cultural challenges of SOA, the returns can be substantial, successful users say.
SOA veteran Helvetia Patria Group, an insurance company in St. Gallen, Switzerland, has seen a 201 percent return on investment since launching its SOA six years ago. Helvetia officials said the SOA project cut IT costs for the company's Internet-based businesses by 59 percent.
Helvetia overcame the "tough exercise" of bringing developers on board by using a change management program from Hewlett-Packard Co., said Didier Beck, director of Helvetia's eBusiness Center.
Beck said the HP tools and services helped developers integrate 15 systems into a centralized SOA platform. "The way we are working today is really very different because before, there wasn't any contact between the different subsidiaries -- they had all their own development processes and tools," Beck said. "The consequences and impact were really quite high."
The new development processes included centralizing change management and software-release schedules, Beck said. In addition, the company now provides all new developers with six to 12 months of training at its eBusiness Center, where it centrally manages the SOA.
"An SOA implementation is really a journey," Beck said, "and you have to invest a lot before you can reach a new agility level."