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 technology?

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 from now?'"

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

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

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 by $50,000.

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

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 with systems."

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?"

Tangled Web

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 these things."

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

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

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.