A Discussion About Apprenda & SaaSGrid
A quick note for everyone: Paul Miller of Cloud of Data was kind enough to hold an interview with me regarding Apprenda, SaaSGrid and the Cloud. Check it out!
read more
A quick note for everyone: Paul Miller of Cloud of Data was kind enough to hold an interview with me regarding Apprenda, SaaSGrid and the Cloud. Check it out!
read more
As of late, I’ve had a number of conversations with different individuals regarding release cycles and what SaaS companies currently do and/or should do with respect to releasing upgrades to their offerings. The biggest question is how to map the release to your customer’s needs. In many cases, it’s ok to release an upgrade to your SaaS offering and “force feed” the upgrade to your customers (i.e. they don’t have a choice regarding acceptance of your upgrade). In other cases, however, this could be a terrible mistake.
Let’s start with an example: imagine you are an ISV that writes software for helping manage law practices or that aides in litigation. Your law firm customers generally use your software in a mission critical, time sensitive fashion like managing a current legal case that is making its way through the court system and is worth millions of dollars. A midstream upgrade to your SaaS offering could be catastrophic for the law firm. Your changes could require some amount of retraining, could accidently introduce inefficiencies that were unintended, or might impact your customers in unforeseen ways. Any of these changes would mean that the imaginary law firm would be negatively impacted due to your upgrade, which is most certainly not the intent of an upgrade (Ask Microsoft, I’m sure they remember Windows ME). How can issues like this be solved? By supporting multiple versions! Before calling me a SaaS heretic, let me give some detail!
Ideally, the law firm in our imaginary scenario should have been able to opt out of the upgrade for a period of time, accepting an upgrade when ready. This would indicate that while some customers were on version ‘new’, others were on version ‘old’. In SaaS, it is wise for a SaaS ISV to take a “one version only” stance as a mantra during periods of non-release, but real world pressures exerted by customer needs should always come first during releases. SaaS providers can be bucketed into 1 of 3 buckets in the following maturity model:
Part of the upgrade process that applies at all 3 maturity levels would be the ability to have ‘preview access’ to the new version prior to releasing. This would allow customers to retrain staff and understand changes to the offering outside of normal operational constraints.
Which maturity level seems to be most common in the marketplace? If your organization functions at any of these levels, what has your experience with that level been and have you considered maturing to a higher level?
The SaaSBlogs group on LinkedIn now has 1300+ members and it’s growing every day; make sure you are not missing out and join today.
read more