Skip to main content

The Failure of Web-Based ASP Business Models

Posted by jhook on February 11, 2007 at 1:39 PM PST

With the tech market in an upturn, we are seeing an revitalization of startups on the web for application service providers. Sometimes these are analytical/informational services or point of sale applications which provide supplemental support for one part or all of the customer's business.

First, lets take a look at the pro's of web-based ASP models:

  • Quick to develop and deploy.
  • Maintenance cycles and patches can be immediately applied for all customers.
  • Internal, centralized distribution on controlled hardware.
  • Zero install on the part of the customer by using existing browser platforms.

Basically we have a list of pro's for the developer which are founded in ease of deployment. The exception is zero install on the part of the customer as a pro for the end user. But, rationally speaking, this is where we draw the line.

The con's of web-based ASP models are:

  • Single point of failure (the fallacies of the network).
  • High demands on your own capital in the form of bandwidth and hardware.
  • Maintenance of customer's volatile data, how to integrate?
  • Limitations of the browser platform.

When providing a service over the web, the crucial point of issue is how to integrate your data models with the customers'? In the case of providing a singular service as a facet of a customer's business, such as reporting or CSR facilities-- how will the customer's other systems, services and data integrate with your application? Often times this is approached through manual import tools to port data over for external storage within your own hardware.

Also consider how much the customer depends on your services to make their business function. If you have a web-based application, can they afford down time? Even as an example of non-ASP models, sometimes centralizing functionality to a central data center can cripple your business if not scaled out correctly. Online magazines reported some of the biggest IT failures of 2006 were attempts at centralizing business-critical operations.

So am I suggesting reverting back to pre-dot com with installed software nightmares? No. Just that we should be more open to moving back to distributed software on the client. Data is king-- and in application service models, it's often the customer that owns all of the data. Understandably in this condition, off site application services deployments seem to be wrong route.

Following the 80/20 rule, a majority of operational information is localized to the business where the minority service provided can instead be remoted into a localized platform on the client. In addition, you have a much more valuable and tangible revenue channel with the customer instead of a service that can simply be dropped next week (because it's too much of a headache to maintain data in multiple places just to use your service).

What's changed in Java world that makes desktop deployments more practical?

Hybridizing Java on the Desktop

Bruce Eckle recently blogged about hybridizing Java. Hybridizing for what? Prettier animations with flash? The Java runtime download now sits at 7 MB, which is fairly reasonable (more info here). While both Flash and Java are OS agnostic, can the Flash platform deliver the springboard of functionality that exists in the Java platform? If I'm committing to doing a desktop deployment (where the mechanics of the web aren't going to fit), I'll want to be able to 'really' integrate with the network, data, OS, etc. Not just deliver a pretty UI over the web. If there was a real benefit from delivering a pretty UI, Flash would've been much more popular for application delivery years ago. Adobe Apollo shows a bit more promise, but then again it still doesn't have everything the Java platform has or ever will.

.NET vs. Java on the Desktop

I've been going through phases at work where I keep feeling like I need to pick up .NET for desktop development. But a few things dawned on me. If I commit to .NET, then there's the whole issue of installing the .NET runtime, which is just as large, if not larger then Java. From my experience with ASP businesses, even with deploying to windows OS, the .NET runtime installations and updates come up constantly with support issues. Secondly, with the increasing popularity of Linux and the Mac, even with exceptions, the .NET platform isn't as 'native' here.

Swing vs. Eclipse on the Desktop

One of luxuries that web-based ASP models afford you is easy patching and updating. As a web developer, it's extremely difficult to pull yourself away from that security blanket. So what has Swing and Eclipse done to alleviate this concern? Swing hasn't done much. The whole module, OSGi attempts within the JCP have been poorly spec'ed. I was somewhat interested in the Swing application JSR, but all it ended up being was an exploration in the academic ideology of coding an application. It doesn't have any tangible benefits for actually solving the Java on the desktop issue except for add more useless code abstractions to the runtime.

Eclipse RCP on the other hand has deployment and modularization built in with native rendering. I can't emphasize enough over the importance of this in making Java work on the desktop!. Finally we have a solution that allows developers to push out updates and features the same as you would in web-based deployments. From an ASP perspective, you have a localized deployment where additional features can be added/purchased all while the customer continues to have ownership over the data. Ah, the security blanket exists on the desktop too.