Holly Burgess is happy with her web-based software; just don’t ask her how it works. The attorney and assistant vice president of advanced sales at CGU Life Insurance Co. of America, in Quincy, Massachusetts, says that in the year she’s been using PlanLab, from Impact Technologies Group Inc., she’s been able to close bigger cases and sign on more agents, thanks to the analytical help provided by the software. The fact that, behind the scenes, Impact is using certain “Web services” technologies to provide her with the capabilities she needs means little to her.
It does, however, mean a great deal to Impact, to Microsoft (which supplies the tools Impact uses to develop its products), and, by extension, to the makers and consumers of virtually every kind of software. Awash in the sort of hype usually reserved for Olympic figure skaters, Web services — a term applied to both the tools used to build easily integrated Web-based applications and to the underlying technology standards they rely on — can use some early success stories to bolster the claims being made for them.
In the Harvard Business Review last October, senior executives at 12 Entrepreneuring Inc., a Web services incubator, predicted that Web services would ultimately turn many companies “inside out, with their formerly well-guarded core capabilities visible and accessible to all.” Research firm IDC says that an “acceleration of the transformation of business models” is possible, with some companies embracing a “virtual IT” department while others turn in-house IT into a profit center, all thanks to Web services.
Transformative technologies have been hailed before, only to disappear into the chasm of failed expectations. Ironically, what makes Web services a legitimate contender for “next big thing” is that it is actually many small, old things redesigned and fine-tuned via years of trial and error and collective hindsight. There have been many efforts to make software programs easier to write, to simplify the connections between programs, and to network companies within and without their walls. While many of those efforts have been disappointing or outright failures, they’ve provided valuable lessons for developers of Web services. Combine those lessons with the fundamental “openness” of the Internet, and solutions to many of IT’s thorniest problems may be at hand.
A Welcome Misnomer
Despite a surfeit of headlines about Web services, a CFO could be forgiven for not understanding what they are. In large part that’s because the term itself is misleading. Leave it to the IT world to finally forgo an acronym in favor of a simple phrase, only to get the phrase wrong. These “services” are really an emerging set of protocols and standards that will allow software programs to describe themselves to each other and integrate with each other without the handcrafting that has marked most “systems integration” efforts to date.
There are at least two reasons why CFOs should take a keen interest in Web services: They probably won’t cost much, and they really may change everything. The era of quickly built, easily integrated software may not be here, but it’s tantalizingly close. The armies of internal IT staff or hired guns who spend months or years on projects may eventually be able to develop new applications in just weeks.
By most accounts, Web services will creep into organizations gradually, incorporated into new applications or working quietly behind the scenes in software that companies rent from application service providers (ASPs). That’s the case with CGU Life and its ASP, Impact Technologies. A software application gathers financial data about a prospective client, effortlessly passes that information via the Internet to a secured Web site, where a CGU Life analyst can pass it through several applications at once with a single mouse-click, creating an estate plan without the rekeying of data and other manual processes that hamper customer service.
Connecting applications via the Internet is not new, of course, but what excites many companies is how easy it is to build and integrate software using Web services. Working with new software development tools from Microsoft’s .Net product family (which represents part of the software giant’s $2 billion effort to create the tools that will give rise to Web services), Impact developers achieved a fourfold boost in productivity, says company founder, chairman, and CTO Howard Keziah. And they did it without having to undergo significant new training, which means that 20-year-old Impact is managing to transition into a Web services firm without any wrenching expense or reinvention. Able to do more work in less time, the company is far freer to explore new products and improvements.
Those same benefits should accrue to companies’ internal development efforts. Corporate IT departments won’t have to worry about current staffers becoming obsolete; in most cases, the protocols that define Web services will be built into the development tools they already use, whether from Microsoft, IBM, Sun, or other companies. Programmers already schooled in object-oriented design will find the transition easy, says Keziah. They will be able to write new applications that incorporate Web services capabilities with only minimal training.
Build Your Own?
To be sure, IDC and other research firms expect most companies’ initial exposure to Web services to come via internal development. But new tools that develop applications that talk more easily to each other or to older applications will help some companies tap Web services first through third parties. ASPs, for example, are logical candidates for early adoption, because they host software programs that must, in most cases, talk to other programs to be effective. When an agent for CGU Life, for example, sits down with a client to evaluate his or her financial position, the PlanLab software running on a desktop machine must pass data to and from beefier, server-based applications that Impact hosts on behalf of its customers. But agents may want to tap expertise beyond what Impact can offer. Using Web services, says Keziah, Impact can make its software interface easily with applications from other companies. Someday, Web services proponents say, the technology will facilitate a profoundly modular approach to software development: Instead of writing big applications that tackle all the steps of a complicated process like electronic payments, corporate IT staff or third parties could snap the subcomponents together like so many blocks of Lego.
Applications built with Web services standards such as SOAP (simple object access protocol) in a sense describe themselves to each other so they can link up automatically. That has big implications for intercompany integration, because while companies today can help their own applications talk to each other by standardizing on certain technologies or platforms, they have little or no control over what their business partners use. If everyone writes to a Web services standard, though, supply-chain integration could take a huge leap forward. Companies that already have a working relationship through electronic data interchange, E-procurement, or other forms of electronic communication will be able to extend that through Web services.
These “contained external users,” in the parlance of IDC, represent a likely second phase of Web services adoption. A pilot program between Royal Dutch Shell and the British government, with help from IBM, is one example. Volumes of data pertaining to drilling activity, once provided to the government in paper form to satisfy regulatory requirements, will now be passed along automatically from Shell’s computer systems to the government’s, using Web services communication protocols.
Plug and Pay
The longer-term possibilities entail “dynamic search and use,” in which companies buy and sell (or, more likely, rent) applications modules in a vast electronic bazaar. In this vision, a technology known as UDDI (universal description, discovery, and integration) would act as an automated yellow pages, alerting the software builder to the existence of, say, a claims-processing module here, an electronic remittance module there. Plug them together, add other functions as needed, and you could build a complex application on the fly. And if you happened to build a module in-house that others might find useful, post it via the UDDI and let the world beat a path to your door. While one part of your IT shop operates in a newly lean and mean manner, another becomes a profit center.
That vision is years away from reality, and depends on not only further refinement of the standards that would let applications snap together but also issues pertaining to security and identity — just who are you buying that module from, anyway, and will that company support it?
Even if Web services never reach full flower, they promise great benefits. But it’s not a foregone conclusion that they will evolve smoothly. For one thing, efforts to create standards within the IT world almost always encounter strife, and Web services are no exception. At press time, Sun Microsystems, whose Java technology is among the most dominant software-development environments in the world, was still debating whether or not to join the newly formed WS-I (Web Services Interoperability Organization). Sun says it was invited to join only a day before Microsoft, IBM, and other companies announced plans for the organization.
Beyond the Sniping
Not that IBM and Microsoft are particularly cozy: both will compete mightily in the near term to sell software tools that allow companies to build applications that adhere to Web services standards. “We don’t advocate a rip-and-replace approach,” says Bob Sutor, IBM’s director for E-business standards strategy. “We think Web services will penetrate IT shops stealthily; Microsoft, on the other hand, has come out with new programming languages and new servers.”
Sun’s chief technology evangelist, Simon Phipps, says that it’s too soon to tell whether the WS-I will succeed in establishing standards or simply become “just another industry consortium that does testing.”
Notwithstanding the sniping, vendors know that in these times of extremely tight IT spending, even technologies with enormous buzz won’t get far unless a solid business case can be made for them. “My toughest job,” says Marvin Balliet, CFO of the technology and services group at Merrill Lynch, “is to manage the euphoria that crops up around every new technology. There is always a new white paper out about some technology that will save the world.” (Not to mention bullish analyst reports put out by his own company.)
Merrill Lynch is, in fact, pursuing Web services on several fronts, but Balliet says “dedicating resources to [emerging technologies] has been substantially reined in. Eighteen months ago we let our best and brightest explore new technologies, in part to keep them from leaving for dot-coms. Today we still do it, but it’s far more controlled.”
The same philosophy holds true at companies that Merrill Lynch relies on. Business Engine, for example, provides IT project management services to Merrill in an ASP model. As such, it’s a strong candidate to explore the potential of Web services. But John O’Neil, the company’s CEO, is approaching the technology cautiously. “We don’t want to be 12 months ahead of our customers,” he says. “Today most companies don’t want bleeding-edge, they want bandages.”
O’Neil says his firm is “optimistic but sober” about the eventual benefits of Web services. “But it’s a road, not an event.” True enough, but all indications are that this road may soon be as heavily traveled as that other metaphorical highway.
Scott Leibs is a senior editor at CFO.
No Overnight Success
Web services will enter most organizations in three distinct phases.
2002: Within the firewall
- Simplified application integration
- Increased developer productivity
2004: Contained external users
- Simplified business-partner connectivity
- Richer application functionality
- Subscription-based services
2006 to 2008: Fully dynamic search and use
- Casual/ad hoc use of services
- New business models possible
- Commoditization of software
- Pervasive use in nontraditional devices