by Elana Varon

Managing the Risks of Web Services

Oct 01, 200316 mins
Web Development

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

However, there are some risks Redshaw isn’t willing to take. A vendor’s lack of attention to security, he says, “is a deal-breaker.” Vendors must address how they plan to maintain security as their software passes data to another vendor’s application. “If you have a serious enough gap there, you just walk away,” he says.

Whit Andrews, research director at Gartner, adds that a critical factor in the choice of vendors should be whether they are driving the development of standards “or being driven by them.” He advises picking vendors that have a financial stake in the outcome of the standards battles.

Risk no. 4: Adoption by partners is unpredictable.

Mitigation: Deploy robust middleware that can translate a variety of formats.

If you build a Web services application, will anyone use it? That’s a risk you take when you develop a process that’s meant to be used by a trading partner. It’s one thing to adopt new technology yourself—another to expect customers and suppliers to make the same investments. And when you rely on trading partners to supply Web services that are critical to some business process, the potential points of failure are multiplied. The vision of Web services as a way trading partners could “discover” and use externally published components has generated a lot of hype, but it’s far from reality. Nevertheless, early adopters anticipate benefits to using Web services with external partners. The key: Don’t rely on anyone else to supply any Web services you need to execute a transaction.

Wells Fargo learned from its experience in rolling out its Internet applications that customers “don’t care about the technology,” says Steve Ellis, who heads the Wholesale Banking unit, as long as the bank provides reliable and convenient service. So he and Peltz see little need to push customers to adopt simple object access protocol for sending XML messages, or even to send XML messages at all. Instead, the bank will accept messages in any format and convert them to XML for use by the Web services that apply EAI tools.

“We see this as one of a suite of formats,” says Ellis. “How people connect, we expect that to evolve over time. We have 30,000-plus companies we work with with different expertise and skill sets.” Donie Lochan, vice president with the Cap Gemini Ernst & Young Financial Services Consulting Group, says Wells Fargo’s strategy will be a common one as Web services is offered externally. “There’s a large cost to develop common middleware across an enterprise,” says Lochan. “But if you didn’t have that, you would need to go and rewrite a lot of the mainframe applications that you have to expose them securely.”

It’s also necessary to think hard about how to maintain systems’ performance when Web services applications interact with each other, says William Wood, executive vice president for enterprise business services and information management with Wells Fargo’s IT organization, Wells Fargo Services Co. “To manage end-to-end availability, you’re only as strong as the weakest link, so capacity and performance planning and really understanding what service levels are provided needs to be a very big focus,” says Wood, who oversees Web services investments at the enterprise level. That’s easier to do yourself than if you’re depending on external trading partners to provide Web services.

Risk no. 5: No evidence yet for enterprise ROI.

Mitigation: Think long term.

While evidence is emerging that companies already have realized benefits from their investments in Web services, enterprise-level ROI is still largely theoretical. Leading organizations currently report their gains in terms of the time and money saved on application development, says Cap Gemini’s Lochan. Such savings can be impressive—the Navy lopped more than $8 million a year from the cost to manage just one operation planning application as a Web service, and can now develop new applications in a few months instead of years. The Navy also reports improvements in strategic processes such as mission planning due to Web services that, for instance, enable the aggregation and centralization of mission-critical weather reports.

While it’s taken a year and a half to whittle 100,000 applications down to 6,000 Web services, Shephard anticipates it will take several more years to reach her ultimate goal of a few hundred Web services. Because technological change is driven by fundamental changes in how the Navy operates, the business value of Web services is dependent on how commanders execute their mandates to collaborate more closely. Getting top Navy leaders to buy into the potential of Web services was one of Shephard’s biggest challenges. “We may have disagreements [now] about whether a particular effort takes advantage of Web services in the best way possible, but we’re not arguing about whether [Web services] is pertinent to the U.S. Navy,” she says.

Wells Fargo’s Wood notes that “it’s difficult to have short-term metrics” for Web services. Wells Fargo doesn’t even maintain a separate budget for its Web services investments, instead incorporating them into its IT architecture budget. At the corporate level, Wood looks for ROI in the progress made toward sharing customer information among different business units and improvements in levels of service provided to customers. When it comes to specific projects, Peltz says he’ll keep investments under control by developing new services in short, iterative cycles rather than sinking a lot of money into big projects. And he’ll tackle first the projects that customers want the most—services like event messaging (customized notifications about payments received or other financial events) and payment transactions.

Becoming an early adopter of Web services is not an easy road. “Most cultural change programs fail. Most strategic change programs fail. Most large IT programs fail or underperform,” says Motorola’s Desai. “Aggressively adopting Web services at the enterprise level is all three combined. So the most critical decision is to see how not doing this can be competitively dangerous.”