How to Navigate a Sea of SOA Standards

While the potential benefits of SOA are clear, like the ability to reuse existing assets, the standards picture looks anything but settled.

Not only did Forrester Research count some 115 standards floating around SOA and Web services in its most recent study on that topic, but also, it found that just confirming which vendors support which standards is nearly impossible. Yet CIOs must press ahead with SOA projects in order to meet business needs. Hong Zhang, director and chief architect of IT Architectures and Standards at General Motors, has been balancing the standards dilemma with ongoing SOA work for several years.

Zhang says it’s actually good that there are many standards related to SOA. “This indicates that the software industry is moving toward a broad adoption of SOA,” he says. “The challenge is that there is no common, consistent architectural framework to guide the evolution, integrity and integration across these standards. Many of these standards are not yet mature.”

How can CIOs navigate the muddy waters until those standards do grow up? Technology executives and industry experts offer this advice: Closely monitor the standards scene and try keep your options open, but by all means, don’t delay the launch of key SOA projects. Several strategies can help you avoid getting stuck in a standards pickle.

The Standards That Matter

First off, you can construct just a key list of standards, not a comprehensive one, as you do your SOA planning. For instance, standards such as SOAP and WSDL have been broadly adopted and others, including WS-Security, are ready for wide adoption, says Randy Heffner, an analyst at Forrester Research. But other specifications needed to build Web services that operate with high quality of service—such as standards for management, transactions and advanced security—are mature enough only for aggressive technology adopters, he says.

Of the emerging SOA and Web services standards, Heffner says CIOs should focus on the following: SOAP 1.1, WSDL 1.1, WS-I Basic Profile 1.0 or 1.1, UDDI 3.0.2, WS-Security 1.0 or 1.1, WS-BPEL 2.0, BPMN, WSRP 1.0, XML Schema 1.0, XSLT 1.0, XPath 1.0, XQuery 1.0, XML Signature and XML Encryption.

CIOs should favor standards-based SOA over native protocols, Heffner says, “but don’t sacrifice needed quality of service (QoS) for any given app just to use standards.” Where an application must have greater QoS than Web services can provide, “do tactical workarounds that stay close to the design models of emerging specifications,” he says. Is it necessary for CIOs to know which vendors are supporting which standards at this point? “Not in a comprehensive way,” Heffner says. “But CIOs that are making a major software infrastructure partner choice should get a strong picture of candidate vendors’ current and future support for SOA and Web services specs.” You need to understand your current vendors’ plans as well, he says. Otherwise, you risk investing in technology that might not meet the long-term business goals of the organization or its SOA strategy.

Many organizations will look for temporary solutions—say middleware—to overcome a lack of mature standards. “From the CIO’s perspective there’s a lot of pressure to adopt a middleware platform to fill in where standards are not there, but in a way that doesn’t lock them into it,” says Jim Stogdill, CTO at Gestalt LLC, a defense and energy consulting firm that helps clients launch SOA projects.

But it’s important not to commit too much to one middleware vendor, “because it will be much more disruptive later to swap out,” he says.

Stogdill advises organizations to stick with fairly common standards such as SOAP and WSDL, “and also look to where your line of business application vendors are providing services: Then integrate line of business applications via those service interfaces using unintrusive middleware.

GM’s Selective Strategy

For its part, General Motors learned in its early SOA efforts to identify which standards were most important to what the company was trying to achieve. GM launched its first SOA project in 2000, an architecture called Northstar, for its global online vehicle showroom services (GM Global BuyPower). Northstar’s goal: to establish a global common SOA plan flexible enough to support the dynamics of GM’s business, Zhang says. To achieve this, GM designed the architecture to separate business functions from business process flow (the sequence of the business functions to be performed). The company also separated the physical locations of business data from those of the business functions using the data, and user interfaces from the business process flow, business functions, and business data, Zhang says.

GM successfully deployed the Northstar architecture in more than 40 countries in 2001. The architecture helped GM fulfill various business needs quickly, such as meeting data location regulations, making business process flow changes based on business engagement rules and varying the end user’s software experience based on culture differences in individual countries, Zhang says.

Since the company also uses SOA in other consumer-focused online services, including GM OnStar services, it plans to develop an enterprisewide strategy and governance program for broad deployment of SOA internally and with external partners, Zhang says. As part of the planning for GM’s next-generation SOA implementation, he’s evaluating the latest enabling standards and technologies.

For GM today, the most important specs are those that help standardize the interfaces among services across the well-defined service layers (presentation, business process and so on) The next most important are those that help standardize the implementation of the services within each of the service layers.

As part of developing its enterprisewide SOA strategy, the company is identifying the SOA standards around which of its needs are mature, which should be monitored and which are mandatory. Among these, GM is looking at WS-I Basic Profile 1.1 for enterprisewide interoperability. After this, the company will be able to make a well-informed decision about which vendors and products to use in its broad rollout of SOA.

Another SOA adopter, TD Banknorth, has taken a strategy of prioritizing standards adopted by vendors recognized as market leaders in the SOA space (for example, webMethods) and standards recognized by several key standards organizations. The banking company is using a service-based architecture as a framework for the development of Web services for application integration, according to CIO and executive VP John Petrey. TD Banknorth initially used SOA in 2004 when it deployed webMethods’ Fabric software suite to use a Web service to simplify the process of completing customer address changes.

The Web service, being implemented now, allows TD Banknorth’s call center agents or branch employees to make changes in address, then automatically have those changes take effect in each of the customer’s accounts with the bank. Today TD Banknorth is planning other SOA projects, one involving a small-business loan origination service and another for the company’s online banking system.

“The primary benefit of SOA we realize is significant reuse of services across the integration solution space,” Petrey says. That’s resulting in a substantial reduction in service development time and the creation of higher-quality services that require less debugging and testing, he says.

To date, TD Banknorth has adopted basic standards around Web services, including XSD, SOAP and WSDL, Petrey says. “Going forward, the most important standards will be related to WS-I, like policy, reliability and security, and, to a lesser degree, addressing,” he says.

The bank works “only with standards adopted by vendors recognized as market leaders in the SOA space…and regarded as sufficiently mature” by industry research firms such as Gartner, Petrey says. “The standards we adopt are recognized by multiple standards organizations like W3C and WS-I,” he adds.

TD Banknorth queried companies that had adopted standards such as WS-Security and SAML, “and found that most were struggling,” Petrey says. “The standards supposedly were ready for adoption over a year earlier, yet no one was really using the standards the way they were designed or marketed. We were unable to find a success story.”

Among the lessons the bank has learned in its foray into SOA: Build an architecture in a way that promotes a modular, flexible and incremental deployment, “with placeholders for those standards to be adopted as subsequent functionality requires,” Petrey says.

Mastering Middleware

At smaller organizations, some CIOs are forging ahead with SOA without a major emphasis on standards. The John F. Kennedy Center for the Performing Arts in Washington, D.C., is a midsize organization that uses a lot of commercial software products, some of which are moving toward SOA, says Alan Levine, the CIO.

For example, the center’s enterprise resource planning vendor, Lawson, is moving to a services architecture. The Kennedy Center’s customer relationship management platform, Tessitura—an industry-specific application developed by Impressario, a wholly owned subsidiary of the Metropolitan Opera—also is moving toward SOA.

Levine says he’s taking steps to implement SOA without being overly concerned about standards. “We focus on creating the ‘glue’ that allows the SOA capabilities of the different commercial systems to fit together.”

To that end, the center is developing middle-tier solutions in-house, Levine says.

“Our focus is rather than trying to choose a standard, it’s knowing what to do to get the back ends to interoperate,” Levine says. Of course, middleware strategies depend on your organization’s size and existing systems. Overall, keep your eyes on the prize: a nimble IT organization. As GM’s Zhang puts it, the ultimate goal of using SOA is “to establish a flexible information systems and services environment that can quickly realign” as business needs change.

Bob Violino is a freelance writer.