Application Support from ASPs

Continuing to examine the fundamental questions about using application service providers (ASPs), let's take a look at support. In September 1999, CIC Research conducted a study for CMP Publications to learn more about industry attitudes about ASPs. (Ogilvy and Mather One, IBM's agency, developed the questions.) CIC interviewed 100 people, drawing them from subscribers to Information Week, Network Computing, and InternetWeek. The study was limited to respondents involved in IT decision-making, familiar with the concept of an ASP, and working for an organization that might consider using an ASP. The study's results show good potential for the ASP market, but one statistic stands out: 70 percent of respondents and potential ASP users were concerned about application server downtime.

One of the scariest parts of outsourcing your applications to a third party is giving up control. No matter how many assurances you have, the bottom line is that someone else is responsible for whether your applications are up and running and whether you can get to your data. When you sign up for a service, you typically contract for a service level agreement (SLA) that defines the maximum amount of downtime allowable per month. However, how much does the SLA help you when you walk into the office Monday morning and you can't get to your contact database? Having a reason to be justifiably annoyed is satisfying, but not nearly as satisfying as having the applications running.

Late last month, I talked with Keith Gaylord, marketing manager for NetworkStations Industry Solutions Unit and IBM's leading executive for ASP markets and trends. One point he brought up was how far customer support needs to go for people to accept the idea of outsourcing crucial applications. "People talk out of both sides of their mouths," he said. "End-to-end support means delivery to the customer premises. However, that doesn't help you when the screen goes black and you have no one to call."

"To the customer premises" doesn't always mean "ON the customer premises." At the moment, outsourced applications have no consistent support model. The kind of support available depends on the contract that you and the ASP draw up and the kind of connection that you have to the ASP. For example, various ASPs offer onsite support (either their people or through a consulting firm), online Help desks that field questions electronically, toll-free Help desk numbers, session shadowing for those using display protocols to access their applications, and so forth. For companies to trust their critical applications to outsourcing, they need assurances that they'll be able to get help if and when they need it. One ASP's response to my questions about support—that nothing could go wrong on the client end because all applications were run from the server—was no help at all. Client-side problems, such as dropped terminals, can occur even if the applications aren't running on the client. Server-based computing just makes client-side configuration problems less likely.

If ASPs are going to support mission-critical applications, they need to provide a good support structure with one point of contact. If I can't get to my online applications, I want one person to call—one person who can help me. I don't want to figure out whether I need to talk to the network support person, the server support person, the application support person, or the person who supports customer premise equipment. Some ASPs already follow this single point of contact model. I'll bet that the ASPs that succeed beyond niche applications in 2000 will be those that make it easy for customers to get help when they need it and support clients all the way to the user, not just to the customer's site. After all, when you're selling applications as a service, part of the service is ensuring that the applications are there.