Managing the Risks of Web Services

Current Job Listings

Motorola has committed to the enterprisewide deployment of Web services, with the full knowledge and backing of Samir Desai, senior vice president and CIO.

Never mind that Web services is still an emerging set of communications protocols that most vendors do not fully support.

Never mind that the fulfillment of the Web services promise to simplify integration depends on standards that today are the subject of rancorous debate by competing vendors and standards organizations. (See "The Battle for Web Services," Page 54.)

Never mind that if an enterprise such as Motorola bets on standards that are eventually abandoned, its dream of communicating cheaply and efficiently with customers and suppliers would turn into a nightmare of expensive changes and upgrades.

After two years of ever-expanding pilots at Motorola, the business benefits of converting hundreds of applications into

Web services and updating the company’s underlying IT architecture to support them are, according to Desai, obvious and irresistible.

"This is about increasing the throughput, agility and cost-effectiveness of IT," says Desai. "How many times should I code a credit card check? With Web services the answer is one. In the past no one really knew the answer, but it was a much, much larger number." Merely by automating standard transactions, Web services promises to save a huge amount of effort and money.

This fall, Desai and his team will place bets on a cadre of vendors to supply the platform and tools for a multimillion-dollar effort to develop and operate Web services, both internally and outside the firewall. And as Desai acknowledges, no matter the anticipated ROI, it’s still a gamble.

If standards fail to evolve, then the whole effort is cast into doubt. "No Web services standards means no enterprise Web services. It’s that important," Desai says. Adds Toby Redshaw, Motorola’s corporate vice president of strategy, architecture and e-business, "If you back the wrong vendors and the market evolves past you, the vendors go out of business and the whole learning relationship, the whole [return on] investment sort of goes close to zero."

That’s just one risk among many. But diverse companies are rolling out Web services in defiance of these and other risks, looking for early mover advantage, ROI projected in the millions, and huge cost savings over developing and deploying software in conventional ways. In a survey that the Cutter Consortium consultancy conducted earlier this year of 250 clients, 13 percent said they were already using Web services for business-critical applications as of last January, while 54 percent said they were developing or prototyping Web services applications.

Early adopters are betting that by investing in multiple standards, performing extra due diligence on vendors and keeping a long-term outlook, the effort will be worth it. Here’s how three very different organizations—Motorola, the U.S. Navy and Wells Fargo—are addressing five major risks of Web services in their deployment strategies.

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.

The Navy, meanwhile, has decided to adopt security assertions markup language (SAML), an emerging standard that supports authentication and authorization of end users. As a member of the Oasis standards body, the Navy has been involved in the development of SAML. "Based on what we know, we think that’s a good choice," says Monica Shephard, director of command, control, communications, computer and combat systems for the Navy’s Atlantic Fleet. Because Navy personnel are stationed around the globe and support contractors require access to both classified and unclassified information, Shephard says a standard sign-on capability managed as a reusable Web service is essential to ensure that everyone who needs access gets it. And that those who don’t, don’t.

If the market takes a different tack and the Navy decides to change protocols, Shephard would follow change management policies set out by the Navy’s CIO, David Wennegren. To facilitate technical changes, the Navy has spent about $1 million to develop what it calls a "portal connector," a middleware layer that lets the Navy substitute standards or data definitions without forcing changes to user services or to underlying databases. Shephard has already been through one forced technology change—the choice to adopt new portal software, made by managers of the Navy’s enterprise network, the Navy Marine Corps intranet. With that experience behind her, she is confident that she can change Web services standards successfully, if need be.

Risk no. 2: The lack of standards breeds complexity.

Mitigation: Support multiple standards for now.

The users of my information and my services and my architectures are frequently disconnected, often have extremely small bandwidth, and have to do business in real-time with organizations that are dispersed globally," says the Navy’s Shephard. A big benefit of Web services is that those disparate groups—whether a land-based command center or a battleship—can easily access centrally managed data. But there’s no consistent way to deliver that information through the many proprietary portal platforms Navy users have deployed.

A standard called Web services for remote portals would provide a common way to plug Web services into any portal, but it’s still under development by Oasis. As part of the Navy’s coping strategy, it’s using its market power (the Navy spends $1 billion a year on its intranet alone) and influence with standards organizations to cajole vendors into supporting as many of the emerging standards as possible. The Navy calls its strategy "vendor neutrality" because it presumes infrastructure vendors will eventually provide products that will work with any standard and therefore will be easy to integrate.

"It’s a difficult strategy for the short term, and the most powerful strategy for the long term," says Shephard. In the short term, Shephard’s staff has to put extra effort into making Web services work in a nonstandard environment and keep up with technical details. The alternative—picking a few software products that every Navy unit would use—would ultimately be a more difficult strategy to execute, says Shephard, because it would risk getting stuck with proprietary software. "Then we would be tied to a single view change and a single company’s ability to generate new and inventive ideas," she adds. In the meantime, the Navy is using its portal connector to facilitate integration between Web services and proprietary applications.

For Motorola’s Redshaw, that strategy of covering your bases with multiple standards extends to the choice between Microsoft’s .Net and Sun Microsystems’ J2EE as development platforms for Web services applications. In his view, there isn’t really a choice: Most companies, he thinks, will have to invest in both, as Motorola has. "It’s strategically dangerous to go down one path or another," says Redshaw. Most established companies already use J2EE, he notes, but "if you say, I don’t like Microsoft, and get stuck in stupid politics, you may get leapfrogged."

While it’s hard to know exactly how much it’s going to cost companies that maintain both platforms, Tom Welsh, senior consultant with Cutter, says to plan for purchasing software and servers to support both environments, as well as staffing up with trained programmers. "Few people are dynamic enough to be conversant in both .Net and J2EE," notes Welsh. It’s also necessary to account for the cost of managing and maintaining the two platforms. Yes, those costs add up, but as Welsh says, "It’s a mistake to hope for the benefits of IT when you grudge the time, money and sheer effort necessary to understand what it’s all about."

Risk no. 3: Vendors might go out of business.

Mitigation: Look past a vendor’s software to its management.

As with any emerging technology, not all of the software you need can be purchased from well-established vendors. There’s a risk that you could choose a vendor that goes under or a product line that doesn’t survive.

"Theoretically, you’d say you have to let this space mature, you have to let the rate of change amongst the vendors slow down, and you have a much higher chance of picking the right choices," says Motorola’s Redshaw. "It’s nice, safe, probably a good approach for some companies. But if you’re using old ’me too’ technology, someone who is several steps ahead of you may have competitive advantage." Redshaw is willing to accept, as the premium Motorola pays for being an early adopter, the possibility that some of the vendors he picks may not survive.

To mitigate that risk, Redshaw recommends that companies look past the capabilities vendors offer in their current products and conduct due diligence on their R&D plans. "The tricky part is to look under the covers, to see what their underlying architecture is," he says. "We’re trying to pick the horse that’s going to win 20 races over the next two seasons."

To this end, Redshaw scrutinizes the vendor’s middle management. "Who’s running R&D? If those guys really get it, I have a more comfortable feeling," he says. By this test, the major software vendors probably understand Web services technology best, even if their products aren’t mature. Working with companies that aren’t well established also requires some extra effort. "You have to really play a partner, if not ’big brother’ role," adds Desai. "In many cases where we think it is strategic to IT, we become an owner as well as a customer."

Related:
1 2 Page 1
Page 1 of 2
How do you compare to your peers? Find out in our 2019 State of the CIO report