Custom Services: Putting Web Services to Work
By Stephen Lawton
Three companies show how to use Web services to save
time and boost the bottom line.
Everyone agrees that the term "Web services" refers to a new set of flexible
application building blocks that let companies exchange data easily between
dissimilar systems. But that's where the agreement ends; the rest appears
to be a mass of confusion. Sometimes the technology is said to be as simple
as basic browser-based services-a single request by a PC in New York City
for a currency conversion from a server in Geneva, for instance. Sometimes
it's described as sophisticated communications links between Web servers
and host computers that let incompatible systems talk to one another as
if they were virtual twins. Meanwhile, vendors, looking to jump on what
they perceive as a bandwagon rapidly gaining speed, claim that anything
they do that uses XML is Web services.
And the confusion extends beyond the complications of the technology itself.
How best should CIOs determine the business value of Web services when
they are so hard-pressed to figure out how exactly to go about using the
Says John Hagel, a former McKinsey & Co. principal who coauthored a forthcoming
book on the business value of Web services: "I think there's confusion
at three levels. First, a lot of people, when you say, 'Web services,'
just think Web sites." Then there's the changing nature of the technologies
themselves. Confusion at "the second level is understandable, given that
standards are still in the process of definition," he notes. As for the
third level, "users say, 'Okay, I think I understand the technology. Now
tell me as a business person why I should be interested in this stuff.
What are we talking about today, versus a year from now, versus five years
Says Bob Sutor, IBM Corp.'s director for e-business standards strategy
and the man most responsible for the technology giant's multivendor efforts
with Web services: "It's confusing because there's been a little bit of
marketing hype, as opposed to speaking to Web services' business value,"
he said. "We have a tremendous amount of education to do."
To that end, rather than offering up yet another explanation of what Web
services is, we went at the problem by talking to several corporate CIOs
who have already taken the plunge.
Gift Horse: Nordstrom Inc.
Nordstrom Inc., an upscale department store based in Seattle that targets
female shoppers, had a problem. All its major competitors offered some
high-value services on their Web sites that Nordstrom's Web site, Nordstrom.com,
couldn't. Competitors' online customers could purchase a wide range of
cosmetics and order gift cards by simply clicking on a link.
Lacking such services put Nordstrom at a "significant competitive disadvantage,"
says Paul Onnen, Nordstrom.com's former chief technology officer and now
an independent consultant. But putting together the technology to offer
and accept gift cards on the Web is a complex process. Using a gift card
on the Web site would require a link to Nordstrom's bank-yes, Nordstrom
has its own bank-so that the card number could be validated and the amount
of the purchase deleted from the card's dollar value. The transaction
would also have to link to Nordstrom's inventory control system on its
corporate mainframes, which would deduct the items purchased from the
company's inventory list. And if the purchase were executed through the
store's catalog rather than its Web site, mail-order software on yet another
system also had to be linked to the transaction in order to make sure
the product got to the customer.
But the company's Windows 2000-based Web servers were incompatible with
the IBM mainframes in the corporate offices, retail stores and the banking
subsidiary that handles credit cards, and even with the Hewlett-Packard
Co. server running the mail-order applications. Onnen's task: Design a
system that could unobtrusively reach through all three business operations'
firewalls in real time. And the software to do this had to be written,
tested, debugged, tested again, and up and running in time for the 2001
holiday shopping season-less than six months away. Add the ability to
sell cosmetics-no small task in itself-and you have a recipe for a missed
Nordstrom.com considered, but quickly rejected, the prospect of developing
custom software. It could have been done, Onnen said, but it would have
been far too expensive, and it would have taken close to a year to test
and deploy. Instead, Nordstrom opted for Web services development software
from IONA Technologies PLC. Since Nordstrom already was using IONA's XML-based
Netfish software on its corporate mainframe, going to the same vendor
eliminated the need for extensive compatibility testing.
The entire project was completed in less than three months-well ahead
of schedule, says Onnen. The Web-based application, which translates the
gift card transaction data so that each system could process it through
its respective firewall, worked correctly from the outset, said Onnen,
allowing Nordstrom.com to provide not only gift cards, but cosmetics order
fulfillment as well-and all in time for the holiday rush.
The value to Nordstrom? Since the company doesn't break out revenue by
product category, it's difficult to estimate the kind of revenue opportunity
the new services on its site represent. But cosmetics alone is a high-revenue
product category for department store retailers, said David Unter, a retail
analyst with Deloitte & Touche LLP in Costa Mesa, Calif. Unter estimates
that cosmetics represented 10 percent to 15 percent of Nordstrom's total
revenue last year, and that sales from Nordstrom.com represented 7 percent
to 10 percent of the company's overall sales. Had the cosmetics product
category been available for the entire year, given Nordstrom's $6 billion
in revenue for the fiscal year ended January 2002, cosmetics revenue from
Nordstrom.com could have reached $90 million.
But Nordstrom isn't stopping with cosmetics and gift certificates. Nordstrom
is currently testing what Onnen calls a "perpetual inventory system" in
the shoe department of some of its stores in the Pacific Northwest. Salespeople
can go to a special version of the Nordstrom.com Web site to order out-of-stock
shoes. The customer pays no shipping charges, the store is credited with
a sale, and the salesperson gets the commission-a transaction that would
not have been possible without Web services, says Onnen.
Banking on It: Putnam Lovell Securities Inc.
Putnam Lovell Securities Inc., a San Francisco-based boutique investment
banking firm, found itself unable to deliver the kind of value-added research
reports its customers wanted. Traditionally, research documents were created
in-house every morning. Then the company had to manually download information
from two databases, one for customer contact and research preference data
that's managed by Web-based software from application service provider
Salesforce.com Inc., and the other for distribution data such as clients'
names and e-mail addresses from a database hosted by research services
vendor BlueMatrix Inc. The data was then loaded into an Excel file, where
it was cross-referenced. Only then could the research documents be e-mailed
to customers. The process could take as long as 30 minutes for a simple
piece of research, said Putnam Lovell Chief Technology Officer Rodric
O'Connor. And since the research needed to be in customers' hands when
the financial markets opened each day, only a relatively small number
of reports could be sent out based on the size of O'Connor's staff. The
result: Putnum simply couldn't create the more complex, personalized reports
it believed would give it an advantage in a highly competitive institutional
Last summer, the firm decided to change the way it distributed its reports.
The company's lofty goal: Send customized research to each client while
cutting in half the $300,000 per quarter the company was spending to distribute
the reports. O'Connor considered two alternatives: buying enterprise application
integration (EAI) software or integrating the existing data using some
type of application over the Internet. But EAI, he decided, would be prohibitively
expensive: The license alone would cost $250,000. Meanwhile, the cost
of ownership of a Web service was at most 20 percent of the cost of using
EAI, and integration software was estimated to require more than six months
to develop before testing, versus what O'Connor estimated to be weeks
to develop an XML-based Web service.
Rather than solving the problem internally, the company decided to look
outside for help. So O'Connor chose a hosted Web service, which would
serve as the hub to the "spokes" of the databases maintained by Salesforce.com
and BlueMatrix, as well as the research reports created by Putnam Lovell.
The software he chose, from San Francisco-based Grand Central Communications
Inc., matches each customer's requirements to a customized version of
the investment firm's research, then automatically e-mails it directly
to the customer. Rather than sending entire reports, the Web service transmits
only the specific components of the research that the customer requests.
And because the software hub is located outside Putnam Lovell's firewall,
security, encryption, authen- tication, policy management and any data
transformation become Grand Central's responsibility, says O'Connor. The
result: Putnam exceeded its goal of reducing costs by $150,000 a quarter
The new system integrated the data from both databases and the documents
created in-house in just one month, says O'Connor. That first step alone
was able to get the company halfway to its goal, he said.
Catalog Shopper: Eastman Chemical Co.
Web services won't necessarily roll out without a little pain. As Eastman
Chemical Co. found, it's essential to test thoroughly before putting a
system into production. "This is definitely technology that we're rolling
out carefully, and measuring," says Carroll Pleasant, an analyst in Eastman
Chemical's emerging digital technologies group, a research and development
arm of the Kingsport, Tenn.-based chemical giant.
Eastman maintains a Web-based catalog containing thousands of detailed
entries about the chemical products it sells, and its distributors use
the catalog regularly. "Through one mechanism or another, [distributors]
have managed to take our product catalog data and put it into their systems"
on the Web, says Pleasant. Distributors gathered this information in a
variety of ways, including file transfers, rekeying data and even using
software to automatically pull catalog listings from Eastman's Web pages.
But these largely manual processes meant that the information on distributors'
sites was usually out of date.
"Fairly early on, I recognized the value of what was going on here, that
we were talking about being able to effectively extend these applications
out to our trading partners," says Pleasant. "When we were looking for
something to pilot Web services with, [the catalog] immediately occurred
to us as a great place to get started. If we could make it electronically
available with a single source, everybody can share the same data and
technical information about our products."
Like Putnam Lovell, Eastman is a fan of outsourcing. Rather than building
its own Web services internally, Eastman used XML to link the catalog
data on a Windows 2000 server to an outsourced "hub-and-spoke" service.
Requests from customers accessing Eastman's custom pages on outsourcer
Grand Central's server would be automatically forwarded to Eastman. Then
Eastman's Web service would send back the requested data, and the customer's
Web site would be automatically populated with Eastman's up-to-date catalog
At least, that was the plan. But Pleasant says the company's testing turned
up several glitches, including interoperability problems with different
implementations of SOAP, the Simple Object Access Protocol for invoking
Web services applications, and the difficulties of using the Web Services
Description Language that defines how Web services are used. Had Eastman
not tested the process by which a wide range of customers would access
the Web service, it would have fielded an offering that could have failed
some customers the minute the service went live.
Eastman is facing internal issues as well. Pleasant believes Eastman's
business units will require extensive help to understand how the much
quicker turnaround of Web services will demand a radically different approach
from traditional software initiatives, requiring the business side to
identify focused, near-term business opportunities for Web services that
can be put in place rapidly. "You really have to work hard to educate
people about this," he says, "because it's a real change in what's possible
Pleasant is philosophical about the challenges they've encountered. "I
mean, this is an emerging technology," says Pleasant. "If it worked out
of the box, then it wouldn't be emerging, would it?"
Web services represents an opportunity to derive business value quickly
out of business situations where interoperability and time to market are
critical. Michael Hoch, senior analyst for Internet infrastructure at
Boston-based Aberdeen Group Inc., estimates that companies can create
new applications or integrate old ones in 30 percent of the time it would
take to build their own integrated applications using traditional software
development methods. That means CIOs can often tell their staffs simply
to jump in and pilot Web services projects without having to change their
existing infrastructure significantly. "With Web services, you don't have
to rip out the software investment you've already made," says consultant
Hagel "You can get more business value from existing platforms."
Yet with standards still developing and many efforts still in the pilot
stage, Web services still has far to go before it fulfills its potential.
"But that's always true with these emerging technologies," says IBM's
Sutor. "It takes some time to really understand the business value of
Service With a Smile
With all the hype about Web services, you'd think it would solve every
ill known to IT kind. To the World Wide Web Consortium, or W3C, the defining
body for all things Web, the term "Web services" refers to any of the
various schemes for allowing applications to communicate with one another
over the Internet to share information and support business processes.
But it's the very broadness of that definition that contributes to the
Web services are really modular components, basic building blocks that
can be assembled into larger applications. They can be as small as a single
function, such as asking a legacy system about the exchange rate between
two currencies, or as large and complex as initiating a series of currency
exchanges using multiple banking systems. And these services can be run
by everything from a single user with a Web browser to a massive enterprise
But that's nothing more than middleware, you say. Actually, middleware
is responsible for finding and supplying the necessary data wherever it's
located; Web services are responsible for processing the data. Think of
Web services as a layer of standards slathered over middleware and Web-based
applications that ensure information will be transmitted and processed
in consistent ways.
To build a basic Web service, you need HTTP, the HyperText Transfer Protocol;
XML, the Extensible Markup Language; and SOAP, the Simple Object Access
Protocol. XML defines the standard format for the data, and can even define
the business processes that should be used with the data. HTTP lets you
send and receive data freely through the corporate firewall, without needing
to punch a new security hole in the firewall. SOAP lets applications,
either on your own system inside the firewall or on another company's,
"invoke," or execute, the Web service.
But Web services can start to get complicated when you want to do more
than transmit basic information. If you want to make it easy for your
applications to find unfamiliar Web services somewhere on the Net so the
applications can run those Web services, you'll need some kind of white
or yellow pages: That's the Universal Description, Discovery and Integration
service, UDDI. And if you want your applications to be able to find information
about a Web service, such as how it should be used, you need WSDL, the
Web Services Description Language.
Here's another way of looking at it. Think of how you might go about finding
a plumber when you're living in a foreign country. If you already know
the plumber and the language he speaks, you'd simply dial him up (HTTP).
But if you didn't speak the same language, you'd need a translator who
could speak both your language and the plumber's, and translate between
them (XML). Now suppose you needed the plumber on a regular basis; you'd
want to be able to put his number on speed dial, and possibly even have
a recorded message saying what you wanted him to do automatically (SOAP).
But what if you didn't know how to reach the plumber? You'd need a good
phone book (UDDI). Now suppose you regularly required different kinds
of laborers on a regular basis, but needed to know ahead of time what
their qualifications were, when they were available, and so on; you'd
need a standard way of describing, in a manner both you and the workers
understood, what they could do (WSDL).
Most users today are focusing their Web services efforts inside the firewall,
on relatively straightforward problems such as linking two legacy systems
to a new business process such as allowing visitors to a corporate portal
to check their benefit balances. The best way to begin with Web services
is to start off with small pilot programs using the basic XML and SOAP
protocols, then continually adapt those basic applications until they're
performing as needed.
| FACT SHEET
Web Services Let Companies…
Link new and legacy systems to new applications
Conduct online transactions with less integration cost Reduce time
to market by decreasing development and testing time
Continually adapt applications to match new business processes
Web services can speed application development and reduce costs to
access data on disparate systems.
Dissimilar legacy systems can communicate without expensive translation
Developers don't have to know anything about systems they're communicating
Users only have to install a translation process for their disparate
Lack of agreement on a definition means confusion for users.
Standards are in flux, with more than a dozen competing schemes.
Services written to one standard will not work with Web sites supporting
others without a translation service between.
Today, services created for one vendor's scheme won't necessarily
work with another's standard (such as J2EE and .NET).
SOAP Simple Object Access Protocol allows information in XML to be
exchanged and defines how applications execute Web services.
UDDI Universal Description, Discovery and Integration service helps
applications find Web services elsewhere on the Internet.
WSDL Web Services Description Language lets Web services describe
what they are, where they can be found and how they should be used.
IBM: Offers Web services through its Tivoli application family.
Microsoft: BizTalk Server, built on XML-based .NET services, is becoming
popular with Windows users.
BEA: WebLogic Server helps developers create Web services in Java.
Talking Blocks: Develops infrastructure software that lets companies
develop and manage next-generation business applications.
The Mind Electric: GLUE, the company's Web services platform, is the
leading independent implementation of SOAP.
Systinet: This firm's Web Applications and Services Platform (WASP)
development tool helps users create, publish and use Web Services.
The World Wide Web Consortium's documentation and working groups
O'Reilly & Associates Inc. site with primers and instructions for
Tech resources for CIOs and CTOs
A "community portal" for Web services developers
Resources for developers from Web Services Journal
Information about industry standardizing efforts from the Electronic
Business XML Initiative
Researcher covering the Web services market