One explanation for the sudden openness to the on-demand model has to do with licensing. Customers are tired of the “Costco”
style of software purchasing, as Merrill Lynch’s Maynard terms it. “I can’t eat that many cheese nips in my lifetime. A four-gallon
drum of licorice; that’s how we buy enterprise software,” he says. Paying for what you consume rather than paying up front
for a lifetime of usage fits better with today’s downsized IT budgets.
According to Grand Central’s Minor, botched deployments provide even greater motivation to make the on-demand switch. He points
to Avis, which recently sunk $100 million in an ERP system that never saw the light of day. “The pay-and-pray model of enterprise
software is over,” Minor says. “Instead, it’s going to be delivered as utility, where you’ll pay for successful delivery like
you pay for your phone calls.” Rather than the “big bang” theory of utility computing promoted by IBM, where enterprise datacenters
suddenly become self-healing and self-managing, the on-demand model is more like utility computing, one enterprise application
at a time.
Poor visibility is another factor for moving to an on-demand model, suggests Todd Johnson, president of Jamcracker, which
began as an aggregator of hosted IT services such as VPN and backup and currently provides platform technology for companies
in the on-demand business. Today, enterprises are lucky if they can see beyond the next quarter, he says. The risks of an
18-month global Siebel rollout are enormous compared with a Salesforce.com deployment, which, even if sophisticated, should
take no more than 90 days — and with zero investment in software licensing or hardware.
Mercury Interactive, which has been offering a hosted version of its application-monitoring solution for years, is in a unique
position to observe customer reaction to the on-demand model. “We’re not as religious as some. We offer a choice,” says Christopher
Lochhead, Mercury’s chief marketing officer. During the sell cycle, he notes, customers like the idea that they can switch
from hosted to internal deployment. But in fact, very few do. Today, Mercury delivers application management as a hosted service
to between 3,000 and 4,000 customers, approximately half the installed base for that solution. “When the customer looks us
in the eye and says, ‘Hey, what’s the best way to deploy your technology?,’ we lead with the hosted offering.”
Objections and Opportunities
Not everyone is biting, of course. Topping the list of doubts is whether hosted offerings can be properly integrated with
internal enterprise apps, and skepticism over the efficacy of adapting on-demand solutions to unique business processes. And
some IT managers bristle at relying on an outside host’s ability to run its datacenter impeccably, not to mention maintain
a solvent business. Total dependence on a browser-based UI is another sticking point (see “Can the Browser Meet the Demands
of On-Demand?”).
Ask any on-demand partisan about the integration issue, and you’ll hear two words: Web services. As SOA (service-oriented
architecture) and Web services spread across enterprises and as on-demand providers outfit their offerings with Web services
interfaces, data-level integration gets easier inside and outside the enterprise. But in most cases, Web services’ share of
the integration pie remains small, which is one of the ideas behind Grand Central: Provide a complete services bus, which
supports not only Web services but also legacy messaging protocols.
Grand Central, however, has more up its sleeve than helping on-demand providers and their customers to integrate. The company’s
approach not only facilitates customization, it focuses on integrating hosted services before they touch the customer’s enterprise.
“No one is going to buy a bunch of services and then buy a bunch of software to try to integrate them,” Minor says. For example,
he adds, Grand Central routinely integrates Salesforce.com with ADP payroll processing so that a customer can cut commission
checks without leaving the Salesforce.com environment.