Out with ASPs, in with Software as a Service suppliers

Introducing the Software as a Service model

In the late 1990s, the notion of a company providing applications over the Internet was a novel way to think about application delivery. From an IT manager's perspective, if the ASP could provide the application so that anyone in the company who needed it could use their browser to access it, many troublesome business elements would be addressed. The ASP customer would be billed on a subscription per/user basis, potentially saving management and operations costs, and customers wouldn't have to worry about application upgrades, availability, and maintaining staff to run the application internally. Also, all the security bugaboos would be the responsibility of the ASP.

However, at that time the Internet infrastructure had not been built out as thoroughly as it is now. Some companies used very low bandwidth connections to get to the Internet and most ASPs had to break new ground in terms of redesigning application user interfaces to make them fit in a browser. ASPs had to grapple with how to monitor usage and billing, and how to validate that a user was a signed-up (i.e. paying) customer and not someone who'd hacked in.

In other words, we were in the "Hey! Look at this: someone just invented the wheel and concrete and hammers" phase of Internet commerce.

To continue reading, register here and become an Insider. You'll get free access to premium content from CIO, Computerworld, CSO, InfoWorld, and Network World. See more Insider content or sign in.

In the late 1990s, the notion of a company providing applications over the Internet was a novel way to think about application delivery. From an IT manager's perspective, if the ASP could provide the application so that anyone in the company who needed it could use their browser to access it, many troublesome business elements would be addressed. The ASP customer would be billed on a subscription per/user basis, potentially saving management and operations costs, and customers wouldn't have to worry about application upgrades, availability, and maintaining staff to run the application internally. Also, all the security bugaboos would be the responsibility of the ASP.

However, at that time the Internet infrastructure had not been built out as thoroughly as it is now. Some companies used very low bandwidth connections to get to the Internet and most ASPs had to break new ground in terms of redesigning application user interfaces to make them fit in a browser. ASPs had to grapple with how to monitor usage and billing, and how to validate that a user was a signed-up (i.e. paying) customer and not someone who'd hacked in.

In other words, we were in the "Hey! Look at this: someone just invented the wheel and concrete and hammers" phase of Internet commerce.

Some ASPs hung on and have been successful. CAP Systems (http://www.capsystems.com) for example, is an ASP that provides reporting capabilities to agencies involved in the federal Head Start child development program. But overall, the clang of the bell we thought we'd hear from this new way of doing business was, for the most part, a resounding thud.

But now, it appears that ASPs are back with a vengeance. This time they're called 'Software as a Service' (SaaS - pronounced "sass") providers and they've got a very compelling story to tell.

SaaS firms have reinvented the ASP business with practical applications that you might consider outsourcing for your own business. I say "reinvented" because these companies are now focusing on specific services that IT shops everywhere have in use (see MXLogic below), or they offer outsourcing of common applications (such as e-mail hosting), or offer hosting of management services. Rather than the old ASP model of "We've got an application that people should be using locally, but we'll offer it over the Web", the SaaS companies are targeting specific objectives with their offerings.

There are two reasons I think SaaS will survive and even thrive going forward: 1) The Internet backbone is built out and robust, and 2) SaaS vendors understand the pain-points of IT directors and CIOs who are after specific outsourced marketplace wins. Below are three examples of SaaS providers. If you're considering becoming a SaaS provider yourself, the stories these companies tell might help you kick-start your initiative.
 
MX Logic (http://www.mxlogic.com) of south Denver handles corporate spam. The idea is really simple. Your administrators point their DNS Mail Exchange record to MX Logic so that all incoming e-mail is run through MX Logic's seven spam filters before they are distributed to your organization. The company charges a reasonable per/node per/month fee for its service.