Calculated Risks

Many companies are jumping in to Web services before standards emerge. Sure, there are risks. Here's how some early adopters are managing them.

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 fulfilment of the Web services promise to simplify integration depends on standards that today are the subject of rancorous debate by competing vendors and standards organisations.

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.

Desai and his team are in the midst of placing 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 per cent said they were already using Web services for business-critical applications as of last January, while 54 per cent 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 organisations - Motorola, the US Navy and Wells Fargo - are addressing five major risks of Web services in their deployment strategies.

Page Break

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 organisations 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 catalogues 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 authorised 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 authorised to perform - has less to do with protecting systems and data from unauthorised access than it does with maintaining systems' performance. As each application is currently designed, authorisations are verified when a customer launches the application. Because in the future customers will access Web services instead of launching an application, "the authorisation 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 authorisation change." Peltz says he expects to choose an industry standard for managing permissions, but observes "there's no clear roadmap 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 US Navy, meanwhile, has decided to adopt Security Assertions Markup Language (SAML), an emerging standard that supports authentication and authorisation 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 $US1 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.

Page Break

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 organisations 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 centre 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 $US1 billion a year on its intranet alone) and influence with standards organisations 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 non-standard 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."

Page Break

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 among 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 scrutinises 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 organisation, Wells Fargo Services Company. "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.

Page Break

RISK NO. 5: No evidence yet for enterprise ROI.

MITIGATION: Think long term.

While evidence is emerging that companies already have realised benefits from their investments in Web services, enterprise-level ROI is still largely theoretical. Leading organisations 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 US Navy lopped more than $US8 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 centralisation of mission-critical weather reports.

While it's taken a year and a half to whittle 100,000 applications down to 6000 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 US 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 (customised 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."

Page Break

SIDEBAR: How to Build Securely on Shifting Sand

Five best practices for successful Web services projects

• Pilot, pilot, pilot (and plan to screw up). If you haven't been experimenting with Web services in the past two years, don't rush headlong into an enterprise deployment. "If there is one single factor that can help you minimise your risk, it's understanding what you're doing," says Tom Welsh, senior consultant with the Cutter Consortium consultancy. "There are tremendous amounts of people running into production with things they don't understand." Toby Redshaw, corporate vice president of IT strategy, architecture and e-business for Motorola, advises doing multiple prototypes to see where Web services offers the greatest bang for the buck - and making sure everyone knows some tests might fail. "I have a pilot that's an absolute disaster," he says. "Occasionally, we're going to have blowups like that."

• Focus on architecture. "You'd never let anyone build a house without a blueprint," observes Redshaw, and by the same token, you need a service-oriented architecture, which is designed to facilitate connection of software components, to deploy Web services most effectively. As with many infrastructure investments, the ROI isn't readily apparent. "In the past 20 years, IT was built to last, but in the next 10 years, the goal is building IT to change," says Brand Niemann, a computer scientist who heads the federal CIO Council's XML Web Services Working Group in the US. "You won't see the cost savings [of a service-oriented architecture] initially, but in the long run, it's cheaper and creates a more agile organisation."

• Remember that nothing is set in stone. Standards are fluid, software is maturing, and the Web services you deploy now may have to be rewritten sometime in the future. "You're guessing the benefits outweigh the cost of recoding," says Whit Andrews, research director with Gartner.

• Involve the business. Every Web service is a component of a business process. Monica Shephard, director of command, control, communications, computer and combat systems with the Navy's Atlantic Fleet, has business managers decide which applications to convert to Web services and which legacy applications to kill. Some legacy systems will die a natural death, she says, but "sometimes the right thing to do is wait" until users have time to revamp their business processes to accommodate the new environment.

• Communicate with your IT team. By its nature, Web services is interdependent, and unless all your software developers are subscribing to the same programming principles, you'll end up with a mess of systems that won't interoperate. For instance, everyone should use the same protocols and access databases the same way, says Danny Peltz, senior vice president of Wells Fargo's Wholesale Internet Solutions Group. Educating developers about new data and communications protocols is being handled by Wells Fargo's Enterprise Architecture Group through published documents, brown bag lunches and the existing process for reviewing new software.