In-Depth

Friends Or Foes?

Expect lower prices, faster deployment and easier integration as ASPs package Web services into their hosted services.

• By John Harney
• 12/05/2001

Gartner Inc. predicts that through 2002, 75 percent of businesses with $100 million-plus in revenue will periodically use Web services, and by early 2003, 50 percent of them with less than $100 million in revenue will do the same. What’s more, all the leading e-business platforms from a handful of vendors—IBM, Microsoft and Sun among them—will support 75 percent of all Web services by 2003. Similarly, despite a rocky year of low stock valuations and some closings in the U.S., between 1,000 and 1,500 ASPs worldwide are prospering in just about every vertical market with every kind of hosted application. In fact, IDC estimates the entire market for service provider revenue will leap from $106 billion now to $392 billion in 2005, mostly from xSPs outside the U.S.

Besides impressive growth, these two new types of IT services share a common goal—the virtualization of applications. You might say ASPs launched first-generation virtual apps using a hosting IT model, while Web services propose second-generation applications using an interoperable “programmatic” IT model. Whereas ASPs accelerated deployment by leasing more affordable hosted applications, Web services hyper-accelerate app development and deployment of (oftentimes) free apps.

If you were to imagine installed, hosted and Web-service apps along a continuum, installed ones would reside at the robust/inflexible/proprietary/expensive extreme and Web-service ones at the “lo”-bust/flexible/open/affordable opposite extreme. (Most Web services are not robust now, but theoretically could be.) Hosted apps reside somewhere in the middle—they can be robust, somewhat flexible, not strictly proprietary and pretty affordable. So hosted apps are more like Web services than are installed apps—but the two “software as service” types of app are far from identical.

In “Defining Web Services,” the Stencil Group points out a few more key differences between the two—“ASPs deliver entire applications from a central hosting location,” they say, “while Web services are distributed components.” “ASPs form a closed ‘black box,’” they add, “while Web services are inherently extensible.” And, finally, “ASPs are as much business model as technology solution …,” while, they believe, “Web services may enable new forms of business models, but are fundamentally a technology solution.”

Aside from understanding the generic distinctions, though, customers want practical information about key issues. For example, will the two approaches complement or compete with each other? If they complement, how does one use them together? If they compete, what providers do they threaten? Which approach better solves what business problems?

Faster Apps
In most cases, Web services will complement hosted services. Greg Flurry, a senior technical staff member at the IBM Software Group Technology Center, created a prototype ASP to demonstrate that Web services could function as hosted applications themselves. His group created lightweight apps that did things like provide directions and report weather by wrapping existing Web-based apps in JavaBean components. In “Applying Web Services to the Application Service Provider Environment,” he suggests that “many of the services that are part of the ASP infrastructure … can also be implemented as Web services; this would provide tremendous flexibility in constructing an ASP infrastructure and in tying Web services-based applications into an ASP.”

This suggests how IBM, a major e-business infrastructure vendor, will tie Web services to its advanced ASP program. By leveraging what it calls a service-oriented architecture, IBM will enable customers to efficiently “publish,” “find,” and “bind” Web services to hosting platforms. And while the prototype services were “lite,” Flurry believes ASPs could eventually host more complex services ranging from a reusable component that’s combined with others to complete a business process, to an entire application or suite of applications.

Less Integration
According to Adam Gross, vice president of product marketing for Grand Central Networks, it costs anywhere from $.5 to $1 million to integrate two business processes or applications—whether installed or hosted. And this remains a drawback for ASPs—while faster and cheaper than traditional integration, hosted app integration is still where the ASP customer loses the most deployment time.

Grand Central offers a set of between-the-firewall value-added services that help customers secure, monitor, manage and upgrade Web services. For example, Grand Central will authenticate users, monitor the performance of one Web service or track transactions spanning several services, and seamlessly upgrade Web services for customers. You might say in the Web-service ecosystem they play the role of Managed Service Provider (for performance monitoring), and Managed Security Provider (for managed security) in the xSP ecosystem. Indeed, ASPs offering Web services find them very useful.

SalesForce.com, for instance, is a pure-play ASP with its roots in sales force automation. It has now diversified into Web services that offer similar functionality and uses Grand Central to guarantee the quality of those services for its customers. As an additional offering, the Web service is less expensive than a hosted solution and allows the ASP more flexibility in its services portfolio. For example, it might use an inexpensive Web service to demo functionality or as a “lite” introductory service from which it can later ramp up customers to hosted apps and professional services—good for customers too because they get lower entry costs.

But the solution also addresses the integration issue. For example, says Gross, if a customer needs to integrate the hosted sales force automation app with a legacy Oracle Financials installed app, linking them as Web services is faster and cheaper. Prepping the legacy app as a Web service so it can play with the sales automation Web service would only run the ASP customer a leasing fee from Grand Central of $2,500 a month, plus professional-service fees for creating and prepping the two applications.

The Next Thing
John Hanger, chief marketing officer for Flamenco Networks, goes one step further. He believes that the differences between hosted apps and Web services will diminish over time until “all ASP services will be offered via Web-service interfaces.” In the near term, he thinks providers will expose more large-grain functionality like Microsoft’s PassPort single sign-on Web service. Longer term he sees providers of all types offering more complex, robust, small-grain applications as Web services. Hanger, like Flurry, believes Web-service technology certainly places no limits on an application’s scope—“you could expose an entire ERP system as a Web service,” he says.

Flamenco offers services similar to Grand Central—it provides a logical layer on top of a customer’s network or the Internet that improves its Web-service security, reliability, performance and management. And, Hanger claims, its services can reduce Web-service implementation time and cost by up to 80 percent.

The service is tailored for companies deploying private Web services that, for instance, need to securely check order status, not public ones that, say, provide weather in a certain Zip code indiscriminately to anyone. Hanger explains that Flamenco quickly exposed order management functionality as Web services for an electronics manufacturer whose employees and b-to-b customers needed to check order status.

Originally, employees checked orders from a screen in the internal ERP system. Flamenco exposed that functionality to another internal application employees accessed via browsers, and programmatically to external customers because they needed to check on orders much more often, and browsers would slow the process. Hanger says, without Web services, the customer would’ve expended about four times the effort writing code to accomplish things like access control, compressing XML data for better performance, and encryption for data accessed from outside the firewall.

ASPs and Web Service Brokerages
Mike Clark, a senior analyst for Lucin Consulting, has devised a business model he calls a “Web service brokerage” that may support Web services just as ASPs support hosted applications. Clark is also the principal designer of the SalCentral.com registry for Web services, an organization that could play a wholesaler role in the Web-service ecosystem.

In “Business Architecture for a Web Services Brokerage,” he defines a brokerage as an organization or coalition of organizations that creates, publishes, promotes and sells Web services. Clark suggests that ASPs, in fact, might play a reseller role in the value chain as a publisher of the brokerage’s Web services. This would not involve Web-service creation, but it would entail more than simply reselling single-hosted Web services.

Until the industry matures, customers will obtain many Web services via the Internet from relatively new and unknown providers that could be physically located anywhere in the world. ASPs might serve as third-party virtual warehouses for Web-service source code and customer data, manage Web-service upgrades, and combine smaller Web services (even from different providers) into larger ones—as “trusted intermediaries whose only business function is to administer Web services,” says Clark. The ASP, therefore, would have service level agreements with both Web-service developer and customer guaranteeing that the Web service as hosted is performing per the developer’s specs and customer’s contract.

Many xSPs, such as Full Service Providers (for integration) and Storage Service Providers (for managed storage), already provide analogous services for hosting customers per SLAs. As third-party “backup service providers” for ASPs, they provide value-added services for both end customers and ASPs. ASPs, as well as these other players in the ASP ecosystem, could easily play a similar role as part of a Web service brokerage.

Of course, concludes Clark, ASPs could easily profit from “thin” Web services “that simply attach to a standard product and offer a new method to access it [by simply] buying access to a service and offering it at a higher rate.”

Competing with Web Services?
If Web services and hosted services compete, it will probably be the result of the trepidation of ASPs. They have a year or two to decide how they’ll incorporate Web services into their existing business strategies. If they’re slow, then users will become accustomed to accessing Web services from independent directories supported by other types of providers. However, at this point, few Web-service providers have come up with a proven business model—ASPs, by contrast, have a model that works.

In “Making Money out of Selling Web Services—Part I,” Clark suggests that ASPs may leverage that model by developing what he calls “hare” Web services. Like SMS messaging, these are “quick-fix Web services—they offer immediate satisfaction and require little or no commitment from customers [and] … take minutes, or at most, a day to implement.” These “hare” services may take off fast and prime a new market because they instantly gratify a specific customer need and build interest. Once lower-end users accept the viability of the new model, ASPs can begin offering “tortoise” Web services. These services are more time-consuming and complex to implement, Clark says, but “benefits are seen over a longer term in lower costs, low maintenance, easier payment terms,” and so on. These “tortoise” services are better suited for corporate implementations in a mature market.

When to Use Hosted Services and Web Services
Obviously, three major issues differentiate hosted services from Web services: Speed of deployment, integration costs, and robustness of functionality. But these are probably the factors that most crudely characterize the two. Nonetheless, when deciding which service is best, customers should determine whether the solution requires fast deployment, low integration costs, extensibility and comprehensible functionality. If so, it’s a good candidate for Web services. Inasmuch as hosted services can be deployed on accelerated schedules for premium fees and may involve minimal integration costs if the app will not interact with another hosted or legacy app, complexity of functionality will be the key high-level discriminator. If the solution requires complex, mature, bulletproof functionality, a hosted service backed up with an SLA is the safer bet.

Customers must also decide whether the solution requires a graphical user interface. If it definitely must operate programmatically, then using a Web service is the only option. If it needs an interface, can the provider expose functionality in an existing app as a Web service that works with a GUI? If so, this favors a Web service. If not, a hosted service is the better option.

Mission-criticality is also crucial. While Web-service networks may guarantee security, performance and so on, ASPs have been doing it for several years and have successfully addressed customer fears about security, reliability, and data and app control. Also, at this point most production situations that require dense data processing and fast response times may be better addressed with hosted apps than Web services—their transportation specifications like Simple Object Access Protocol weren’t designed to rapidly handle that type of load.

Finally, bundling services might become an issue. In the ASP ecosystem, ASP Application Aggregators and Enablers bundle hosted and other services from different ASPs and xSPs behind a single interface with an SLA they, as resellers, guarantee. Customers deal only with the AAA. Organizations providing similar bundling services for Web services—say, combining less complex Web service components into more complex apps—will probably take a while to work out licensing, distribution and SLA issues, so be forewarned.