Outsourcing /

The AIP advantage

By Jeb Bolding
Network World ASP Newsletter, 02/07/01

Despite a sea of acronyms describing all sorts of service providers - including application service providers, management service providers and storage service providers - don't be fooled into thinking there is a divergence among xSPs. In fact, it appears that the perceived slowdown in the high-tech economy is bringing about the convergence of service providers that has been predicted for the last six months.

One group attempting to take advantage of impending consolidation are application infrastructure providers (AIP), a relatively new segment of the xSP market. AIPs offer hardware, software and management services to ASPs in the belief that they can act as a sort of keiretsu umbrella for various ASP and MSP applications and services.

Companies in the AIP space include Loudcloud, Exenet, Exodus (sort of), PSINet, and many of the telcos such as Nortel Networks, Sprint and MCI/WorldCom.

AIPs subscribe to the belief that there are two kinds of ASPs. One kind of ASP builds an ASP product and supporting infrastructure from the ground up, focusing on a specific market. This kind of ASP has an understanding of the software it provides and the need for that software in the market the ASP is targeting.

The other type of ASP builds up a support infrastructure to host applications built by a third-party vendor. This type of ASP has expertise in the software, and may or may not know much about any specific vertical markets.

AIPs think that both types of ASPs made a fundamental mistake in attempting to build the infrastructure necessary to support their hosted applications. Six months ago, AIPs argued that maintaining a million-dollar network operations center was placing a substantial personnel and financial burden on ASPs. This is a burden that AIPs believe they can alleviate, allowing ASPs to concentrate on software and services development.

As the current economic crisis deepens, the AIP argument seems to be sinking in. ASPs are strapped for cash, and building a $500,000 to $1 million datacenter is an extravagance that most cannot afford.

For those ASPs that host third-party vendor software for enterprise resource planning, customer relationship management, or supply chain management, for example, joining forces with an AIP seems to make sense. The applications that these ASPs are hosting are, for the most part, off-the-shelf products that make basic assumptions about databases, external application calls, directory access and operating system requirements. In most cases, these large applications have defined APIs that allow providers to write extensions to the software in a consistent fashion.

An AIP can offer these types of ASPs inexpensive use of standard databases such as Oracle, Informix and DB2 as well as high-end hardware such as E4500s, E6500s and E10ks. On their own, ASPs would need to invest in expensive management personnel to run any of these systems, not to mention the up-front cost of buying the hardware and software. More importantly, ASPs can broaden their product offering if they have this kind of support.

This brings us to the second type of ASP, and its need for AIPs.

While I buy the AIP argument for third-party product hosting ASPs, I'm not so sure that the rationale holds for ASPs that have built a custom application targeted to a specific niche or vertical market.

I suspect that many of these types of applications were built in an ad hoc fashion (this is not meant as a criticism, just an observation). The original application was probably formed around a small core of functionality based on the needs of one or two customers. Later, functionality was added to the application on-the-fly in an attempt to be service oriented toward the few, but powerful customers in the ASP's pocket. At this stage of development, speed, more than quality, was the issue. Shortcuts were taken and programmatic consistency with an overarching product architecture was considered a luxury. As customers increased, scalability probably became an issue and significant rewrites occurred in an attempt to address some of these irregularities, but overall, the product is not polished in the traditional development sense.

My point is that I suspect that many of the original ASPs in the marketplace have developed their product offering with the inherent strengths (and weaknesses) of their software and hardware infrastructure at the foundation. As a result, these ASPs cannot take advantage of the services that an AIP or other aggregator offers because any attempt to abstract the application from its existing infrastructure would cripple the application.