Comments on: SaaS Upgrade Maturity Model

By: Larry Port

Larry Port — Thu, 05 Feb 2009 21:45:54 +0000

Interesting – we actually have a SaaS product for law firms.

Without a doubt these are interesting ideas. I think though what also needs to be taken into account are the nature of changes. This is especially so in Agile shops where sprint cycle releases are the norm. So, consider, for different types of rollouts:

1) Substantial changes to existing product – absolutely levels 1 2 and 3 should be considered.
2) New features not affecting existing product – deploy at will in conjunction with PR/Marketing and subscriber agreements.
3) Bug Fixes/small improvements – also deploy at will.

Otherwise, you risk making a muddled mess of deployment. The simpler the better.

By: Scott Sheppard

Scott Sheppard — Wed, 21 Jan 2009 17:18:31 +0000

The client for Buzzsaw was developed in 1999. It is an ActiveX Control. It communicates with an ISAPI extension on the server. As we evolve the service, the client will leverage newer technologies, but for what it is now, Level 3 meets our needs.

By: Sinclair Schuller

Sinclair Schuller — Wed, 21 Jan 2009 08:42:39 +0000

Wes, I would argue that 3 has the ability to be most cost effective given the right automation system. The cost associated with any of the maturity level seems to be related to how much intervention is required.

Scott, have you experienced a cost effectiveness difference? Also, with respect to your desktop client, have you considered technologies like Silverlight or Flex via a browser to help with the update issue, or is Buzzsaw taking advantage of something on the host OS beyond what’s exposed via those technologies?

By: Scott Sheppard

Scott Sheppard — Wed, 21 Jan 2009 05:49:47 +0000

Autodesk Buzzsaw is not pure SaaS. It’s more like software + services. There is a Buzzsaw client to install. When we upgrade our servers, all of the customers affected have to install a new client. Sometimes customers are in the middle of a critical project, so an install is inconvenient. As a result that’s why we go with Level 3. Customers get their data moved to the upgraded server at a time that meets their schedule, and then the client installs begin from there.

By: Wes Smith

Wes Smith — Wed, 21 Jan 2009 04:50:13 +0000

Clearly option 1 is the most cost effective model for SaaS. Why not just give a 60 day lead on the blanket update and have a preview like most do anyway. Then option 2 and 3 are moot and you have solved all the issues. Besides, when you stray from option 1, you stray from basic SaaS foundations. So if a customer does not like it, they should just just do managed host. In fact it’s why managed host is still, and likely to continue to be more poular than SaaS.

By: Scott Sheppard

Scott Sheppard — Tue, 20 Jan 2009 18:39:30 +0000

Having lived through the dom com era as the sofwtare development manaer for Buzzsaw, we have tried all 3. Certainly we started with Level 1. This did induce pain on the part of customers. We tried Level 2 for the shortest amount of time, since even the second coming was painful. Now Autdoesk offers Buzzsaw using the Level 3 method. This works well. Customers pick a date, and we migrate their data when such migrations are necessary.

By: Michael Dunham

Michael Dunham — Mon, 19 Jan 2009 23:40:19 +0000

Sinclair – I’ve worked with an application very much like you describe. A couple of interesting things from the experience:

Process/feature changes that positively impact usability and productivity are excepted immediately – however, in many cases those should be considered for monitization. Depends a lot on the competitive atmosphere.

Feature changes that require “relearning” with no apparent usuability or productivity bonus are roundly rejected and likely to lower user retention. It doesn’t mean they aren’t necessary in some cases however for reasons the users aren’t aware of. Making them aware of the deeper issues is key in this situation.

But the worst case scenario is when a change requires API restructure and integration realignment. Planning this level of upgrade can be very difficult when customers have a significant investment in integrated apps.

In the first case, I can see the positive upgrades being pushed out immediately – in coordination with marketing of course.

The second and third situations would require your “level 2″ or “level 3″ upgrade, but there is also a very serious service component both helping customers understand potential issues and in some cases helping them test and prepare for the upgrade. In SaaS we are selling service, in some cases added service ($) and retention is king.

So, I wouldn’t necessarily call this a “maturity level” decision – it is more a matter of the product manager, QA, and service team having a way to evaluate changes and determine which plan works for an individual situation. There are going to have to be some parallel versions during testing and in some cases evaluation or “beta positive” users that allow themselves to be pushed to the new version as soon as it is ready. Getting to that discussion before release is where the maturity comes in.