eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Back in the good old days of the 1990s, we used to refer to software companies that delivered applications over the Web as ASPs, or application service providers. Back then, there were many concerns about the viability of ASP products.
Business managers worried if browser-based products would be robust enough to provide the rich interfaces that users demanded. IT administrators worried that the applications provided in this way would not be fast or reliable enough.
And CIOs and other C-level types worried that either the small start-up ASP companies would go out of business or that the bigger companies experimenting with an ASP model would give up on it-—in either case, leaving customers without a working application.
Up until the early 2000s, many of these fears proved to be justified—especially the last one, as many ASP companies and applications did go belly up, leaving businesses with an infrastructure hole or trying to use a complicated code escrow to try to get the previously ASP-delivered application to work as an internally run application.
Fast-forward to today, and many fears seem to have been addressed in the current crop of ASP applications, which now tend to be referred to as SAAS (software as a service) or on demand. Better use of Web standards, and the emerging use of AJAX, has enabled Web-based interfaces that rival those of locally installed GUIs.
And while major SAAS vendors such as Salesforce.com have experienced some high-profile outages, service-based applications have, for the most part, quieted naysayers with uptimes and performance ratios rivaling those of internal applications.
Also, vendor reliability seems to be much better with the current generation of services. Salesforce.com, for example, is as healthy and robust as many traditional large software vendors, and major vendors, such as IBM, have made SAAS a major part of their technology strategies.
So companies should feel totally safe about using an on-demand or SAAS solution, right? Well, yes and no. The current generation of SAAS products and companies does face a significant risk of shutdown that doesnt have much to do with application quality or a vendors health.
Just ask the many users of Research In Motions BlackBerry product and service—earlier this year, these users faced the very real threat of seeing their addictive little devices turn into useless tchotchkes. Or, more recently, ask the millions of users of EchoStar Communications DVRs (digital video recorders), who could see the devices turn into very large paperweights.
In both cases, there was nothing wrong with the products in question, and both of the vendors of these products are financially healthy. However, all of that matters little once a patent trial occurs and a judge orders an injunction to shut down a potentially patent-violating product.
In the EchoStar case, Tivo brought patent claims against EchoStar, which provides DVRs for subscribers to its Dish Network satellite service. Tivos claims look to be pretty valid, unlike NTPs against RIM, but thats of little comfort to the millions of users who will be hoping for some last-minute reprieve for their cherished DVRs.
Both cases illustrate a clear danger in the subscription–based product model that most software companies have been hoping to switch users to for years. When you rely on a product that works only through a subscribed service, you are at serious risk if that service gets shut down—for whatever reason.
What would your company do if a CRM application or some other vital app suddenly faced total shutdown because of a patent case? In many cases, the answer is, unfortunately, not much.
If you were smart, you made sure from the get-go that your SAAS vendor offered a code-escrow deal so you would have the option of running the application internally if the service were to be shut down. This model can work, but it might be weeks or months until you have the application running satisfactorily in-house.
Or, hopefully, everything in the product was standardized enough that you could easily switch to a competing product. Maybe the new vendor wont stick it to you too much in your desperation.
Or, maybe youll just be up the river without a paddle, forced to lose data and start from scratch. Guess theres still reason to be cautious about software that doesnt live on your own systems.
Contact Labs Director Jim Rapoza at [email protected].