asp issues

Will keep this short – I was reading an article (whose authors will go unnamed) describing some recent trends in software licensing and issues arising from those trends. One trend that was highlighted was the change from licensing of software to be installed and operated by a licensee (with maintenance and support from the licensor) to a vendor-hosted model (or “application service provider” or “ASP” for short), where the vendor instead sets up the software on its own machine and the vendor’s customers then make use of the software remotely – often through a browser, but sometimes through other “thin” clients.

What was the primary issue they identified? To make sure you get acceptance testing. Hmmm. Well, hate to disagree but I would think there might be a few others that might be at least (if not more) important. So, without further ado, some thoughts on what to keep an eye out for if you are thinking of signing up to an ASP service, in no particular order:

Your Data – Will your ASP be storing your data? Will it be your primary repository of your data? Is your data important? Does your data contain sensitive, confidential or personal information? If so, then you should make sure that your ASP is handling your data appropriately, including giving adequate assurances that it is only used for providing the service (and not anything else) and that appropriate security measures are taken to protect it, such as encrypted communications when sending/receiving as well as encrypted storage. We’ve all read the recent horror stories about certain large corporations who have misplaced, lost, or inadvertently disclosed sensitive data, such as credit card numbers. Make sure it isn’t your company making the headlines.

Service Levels and/or Easy Outs – Addresses the same issue as acceptance testing but in a different way. Typically one big advantage of ASPs is that there is no big upfront licensing fee and therefore no big upfront capital to invest, or risk regarding that capital investment in the event the software doesn’t do what it was expected to do. Thus, the concept of acceptance testing was invented to address this big upfront risk, with the thinking that you get to kick the tires extensively before you hand over the the truckload of cash. And if the testing doesn’t pan out, you don’t pay. OTOH, ASPs usually involve a periodic (typically monthly) payment which is much smaller. In effect, the monthly service fee can be thought of as a replacement for: (1) the amortized cost of the initial license fee; (2) maintenance and support; (3) investment in hardware and infrastructure; and (4) additional people costs on the vendor side, to keep (3) up and running. Very often this is a win-win situation, since vendors can often achieve economies of scale by running a large number of instances centrally at one dedicated data centre (and ironically to some extent harkening back to the days of mainframes + terminals – but I digress) and offer very attactive savings over what it would otherwise cost a customer to maintain the application in-house.

Anyway, the point being that there is less upfront risk with an ASP solution, provided of course, you’re: (a) not locked in to a 50 year contract; or (b) you have really good assurances that the software will be up and running as needed when you need it. Its good to have both, but at the same time it can also be thought of, to some extent, as an either-or proposition – if you can arrange for a month to month contract, then if the ASP stinks, just terminate and go elsewhere. Alternatively, if you get ironclad service levels (including significant credits and termination rights) then you might be willing to commit longer. Of course, you’ll also need to ensure that you have the ability, in the case of a month to month agreement or termination rights, to move to another service easily, and to get your data back, etc. But I’ll leave that for another time.

Anyway, not necessarily saying that acceptance testing isn’t important (and in fact if you need to spend a ton of money to have the vendor customize a solution for you it may still be very important) but just a couple of other issues to keep in mind.

hybrid computing – bigger than i thought (possibly)

I recently mentioned Prism in a prior entry and how it was an intriguing business model. What I didn’t realize is how widespread a movement it seems to be, as suggested in this Knowledge@Wharton article. A brief blurb:

It’s been a busy few weeks for the big technology companies. On October 1, Adobe Systems announced an agreement to buy Virtual Ubiquity, a company that has created a web-based word processor built on Adobe’s next generation software development platform. One day earlier, Microsoft outlined its plans for Microsoft Office Live Workspace, a service that will combine Microsoft Office and web capabilitiesso that documents can be shared online. Recently,Google introduced a technology called “Gears” that allows developers to create web applications that can also work offline. The common thread between the recent moves of these technology titans: Each company is placing a bet on a new vision of software’s future, one which combines the features of web-based applications with desktop software to create a hybrid model that may offer the best of both worlds.

Such a model seems to make a lot of sense, both from the perspective of users as well as developers. From a developer perspective, I can see how simply gaining information on how their products are used (albeit possibly involving some privacy complications) could be invaluable. In addition, tying software to a service will likely curb piracy – its one thing to bypass protection mechanisms on standalone software but something quite different to try to fake an account setup to take advantage of an online service (at least given what little I know about it).

Then again, as the article points out, this movement may simply be the latest iteration of a trend that has never quite caught on (e.g. MS Hailstorm, “thin” computing, network as the computer, etc. etc.).