RISK NO. 1: Web services isn't secure.
MITIGATION: Choose a standard, but be prepared to switch.

Any plan to expose data and applications beyond the corporate firewall carries risk. Web services adds an extra dose of complexity to a company's IS strategy because there are no agreed-on standards for authenticating users and controlling access to Web services applications that are accessed from outside the corporate firewall. So far, that's deterred many organizations from pursuing one of Web services' grandest promises: that trading partners could assemble application components they need to use at the time of each transaction. For instance, a builder could use one Web service to query catalogs from multiple suppliers, and another one to generate purchase orders to send to two of them. Upon receiving the purchase orders, one supplier could use a Web service to access an internal database and confirm that the order comes from a customer in good standing. The other could use a Web service provided by a third party to run a credit check. The software to run each transaction could be reused multiple times without additional programming. But each of those transactions requires a means to verify that the customer is who she says she is, and that she's authorized to do business.

Secure verification hasn't arrived yet, but early adopters have learned that with planning, it's possible to get around that problem. Wells Fargo's Wholesale Banking unit is rewriting 35 online banking applications for corporate customers as Web services. The applications, now available through the bank's Commercial Electronic Office portal, will be broken up into their discrete components so that customers can pick and choose the features they want to use without having to open entire applications to perform individual tasks. For instance, a company treasurer who wants to make an investment could check her account balances, create a wire transfer, and conduct a trade without having to open and click through three different applications.

The bank has addressed the security conundrum by maintaining its existing methods for customers who want to access its Commercial Electronic Office and transmit data. Customers have to first establish a business relationship with the bank and obtain a user ID and credentials before they can use any online services. Those procedures don't have to change for the bank to make Web services available to customers, says Danny Peltz, senior vice president of Wells Fargo's Wholesale Internet Solutions Group.

The major security challenge Peltz faces - keeping track of which transactions each user is authorized to perform - has less to do with protecting systems and data from unauthorized access than it does with maintaining systems' performance. As each application is currently designed, authorizations are verified when a customer launches the application. Because in the future customers will access Web services instead of launching an application, "the authorization has to travel with Web services," notes Peltz. "You don't want to have thousands of calls to a database each time there's an authorization change." Peltz says he expects to choose an industry standard for managing permissions, but observes "there's no clear road map for how to do it."

It's possible that no standard will address his needs adequately. But Peltz has built into his strategy the time and money to evaluate different options. His first deployment, at the end of this year, will be a new portal server that supports access to Web services applications through the Commercial Electronic Office portal. Then he'll roll out the actual Web services every quarter through mid-2005. "We're not going to tackle everything all at once," he says.