SOA Success: Five Actions CIOs Say You Should Take

By John Moore  |  Posted 11-06-2006

SOA Success: Five Actions CIOs Say You Should Take

Alan Goldstein, managing director of the Bank of New York's technology risk management and architecture division, says service-oriented architecture has let the bank trim 15 percent to 20 percent of the cost of new development and testing. He also reports a 10 percent shrinkage in development cycle time. "The core of what our management and business owners really care about is delivering innovative functionality to customers as quickly as possible, at a high quality and in a reasonably cost-effective manner," says Goldstein.

The underlying software design philosophy of SOA challenges organizations to create reusable services, rather than one-off applications The reuse aspect of SOA translates into lower costs—since information technology shops can minimize redundant software code—as well as faster software development times. The economy of development means organizations can more readily respond to the evolving needs of customers and business partners.

Those benefits don't come without considerable effort, however. The departure from the traditional software development lifecycle has required some companies to overhaul their IT departments. Service-oriented architecture also requires closer coordination between IT and the business side of the house, a situation that can call for organizational tweaking.

Next page: Retool the IT Department

Retool the IT Department

Success generally boils down to five action items, according to chief information officers and systems architects who have employed SOA as a software design practice. Those items include:

Action No. 1: Retool the IT Department

Organizations need to take a hard look at their IT shops before taking on service-oriented architecture projects. Developers will likely require retraining, and the department may need to rethink the way it assigns development responsibilities.

"You can explain this whole space in terms of enterprise computing, reusable components, and a better, faster construction methodology," says Toby Redshaw, corporate vice president of IT strategy, e-business and development at $37 billion Motorola Inc., based in Schaumburg, Ill. Service-oriented architecture is a straightforward concept, he says, but it involves a steep learning curve for those who deploy it. "It's a significant paradigm shift for [IT] shops," Redshaw explains.

The services approach revolves around the creation of reusable software components—services—as opposed to monolithic applications. Developers schooled in traditional practices will need to learn to break down coding into smaller pieces.

The trick is to get a core group of developers on board with services and let the practice spread from there. Tarrant County, Texas, which includes the area around Forth Worth, devised its own training program with help from one of its service-oriented architecture vendors, Progress Software Corp. Progress' Sonic ESB, an enterprise service bus, serves as the foundation of the county's service-oriented architecture strategy. (An enterprise service bus provides a messaging layer that lets services communicate.) Progress' Sonic ESB training provides an overview of SOA concepts and technical requirements, and covers such areas as enterprise-service bus development.

But retraining developers may not be enough to institutionalize services. The broader structure of the IT department may have to change from one that mirrors monolithic application development to one that facilitates the service design. Tech shops may need to divvy up assignments to different teams of developers, given the componentized nature of services.

The MedicAlert Foundation International, a nonprofit healthcare organization based in Turlock, Calif., split its developer team into two groups to better accommodate its services push. The foundation sought to build services and a security infrastructure—the means for governing who can access services—in which they could operate. Managers decided an individual developer shouldn't be assigned both chores, in light of the different skills sets involved. So MedicAlert launched two developer teams: one to handle security infrastructure, and one to write the organization's core business services, notes Jorge Mercado, manager of MedicAlert's service-oriented architecture and software architecture group. "We decided that developers accustomed to developing code should only be concerned with writing business applications or Web services, and not concerned and burdened with security," Mercado says.

Next page: Establish an Oversight Group to Get Results

Establish an Oversight Group

to Get Results">

Action No. 2: Establish an Oversight Group to Get Results

Service-oriented architecture adopters—large entities in particular—should set up a group to coordinate activities. This chore is often described as "SOA governance."

An organization with hundreds (or thousands) of developers needs a common development approach to maintain consistency and interoperability among services. Developers in far-flung business units need to know what services exist. And reuse, as a policy, needs enforcement to make it a reality. A dedicated architecture group can make those things happen.

Thomson Learning, a $2 billion global market group of Thomson Corp., the electronic media conglomerate based in Stamford, Conn., operates an architecture council that provides guidance to developers. The council consists of a group of enterprise architects from across Thomson Learning's business units. The group provides guidance to developers in the design and implementation of service-oriented architecture technologies.

Such architecture groups get the word out to developers through face-to-face meetings with developers and published "blueprints" for designing services. Governance may also involve the use of a repository that provides a common resource for looking up services already developed. The main idea is to encourage the use of common guidelines so service development remains consistent.

"It's like Legos," says Motorola's Redshaw. "The moment you start introducing pieces that don't have the right connectors, you've ruined the Lego set."

Good governance reduces the risk of mismatched services and redundant development efforts. Uncontrolled development, on the other hand, can lead to redundant code. Such duplication runs counter to reuse, the key benefit of service-oriented architecture, notes Prashanth Ajjampur, vice president of architecture at The Hartford Financial Service Group Inc., the $27 billion insurance giant in Hartford, Conn. "The biggest risk we saw early in the service-oriented architecture was the recognition that we could have renegade services out there," he says.

Next page: Catalog Services to Enable Reuse

Catalog Services to Enable


Action No. 3: Catalog Services to Enable Reuse

As an organization grows its services portfolio, it will need a formal mechanism for keeping track of its software assets. SOA adopters should maintain a catalog of services that developers can consult to learn what services exist, and avoid duplication. Those catalogs, sometimes termed registries, let developers look up reusable services. "You need a directory or a Yellow Pages so people can find these services," says Motorola's Redshaw. Developers who are able to locate a particular piece of functionality don't have to rebuild it, adds Jeffrey Adkins, integration architect with the Ohio Bureau of Worker's Compensation's Integration Competency Center in Columbus, whose bureau is in the process of establishing a registry. Motorola uses Mercury Interactive Corp.'s Systinet Registry, and vendors such as SOA Software Inc. and IBM Corp. also offer service registries, which allow to developers publish services, list them according to category, and discover them via a search mechanism.

Next page: Monitor Performance

Monitor Performance

Action No. 4: Monitor Performance

Registries fall under the general heading of design-time governance, software and best practices that help enforce corporate design standards for services. But once services go live, organizations need to keep tabs on them. Here, services-management software plays a run-time governance role. Such products monitor the behavior of services after they are designed, tested and deployed.

Services "behave very differently" from traditional application programs, says Redshaw. "So you have to manage these in a different way," he says. Services-management tools take into account, for example, the reuse factor and the dependencies among services reuse creates. A change to one service will affect every application that makes use of it. Such products automatically discover services operating in an enterprise and their interdependencies.

MedicAlert, for instance, uses Amberpoint Inc.'s run-time governance software to monitor the performance of services. The software lets MedicAlert track performance during peak hours and makes adjustments accordingly.

Says Kevin Bohan, CIO at Garden City, N.Y.-based Proginet Corp., a maker of data integration software: "From a performance standpoint, the tools can monitor a service and ensure that it is functioning according to defined service levels. If it is not, a tool can notify administrators or change the way the service runs," he adds.

MedicAlert's Mercado says services management tools can also provide such functions as automated failover: If a service fails, a back-up service is initiated. Run-time tools are available from such vendors as Amberpoint, Infravio Inc. (acquisition by WebMethods pending), Progress Software and SOA Software. Prices generally start upwards of $50,000. But with that price comes greater visibility.

Next page: Coordinate IT and the Business

Coordinate IT and the


Action No. 5: Coordinate IT and the Business

To make service-oriented architecture stick, adopters should make sure their IT departments and lines of business are talking.

Indeed, the services approach calls for close collaboration between technologists and the business side of the house. After all, a service is defined in terms of a specific business function, notes The Hartford's Ajjampur. "In order to really have a service-oriented architecture, you need to understand what the business wants to achieve," he says.

Some companies have launched groups designed to keep the conversation going. Thompson Learning recently assembled a chief technology officer council, comprised of CTOs from the group's business units. The council meets several times a year to create and refine technology strategies based on the units' business strategies.

"As a result, they make sure the technology strategy is in sync with the business strategy," says Ray Lowrey, a senior vice president and chief technology officer at Thomson Learning. As for development, the objective is to "make sure we are reusing services that exist and we are building things in such a manner that reuse is possible," Lowrey says.

The Bank of New York, meanwhile, also runs an enterprise architecture council. The council brings together architectural experts from across the bank's development activities, which are typically aligned with individual business lines. The group encourages the adoption of common services and also plays a role in reviewing applications proposed for development. Architectural approval is required for all software development projects at the bank.

The upshot?

A closer linkage between business and technology improves the chances that the information technology department delivers what business executives want. Motorola's Redshaw says the two sides haven't always communicated well and, as a result, prototypes have been iterated multiple times. "With the new model, the feedback we got from business was: 'Wow, a prototype—that's exactly what we wanted,'" he says.