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
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
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
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.
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
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.