Managing change in a SaaS environment

Migrating applications to the cloud poses a particular set of change management challenges for organisations.

The many benefits of cloud computing are well known. At a high level these can be grouped into infrastructure and application management benefits.

Let's focus on some of these benefits from an application management perspective: scalability, rapid deployment, ease of configuration changes and a culture of iterative releases. These benefits inevitably result in key stakeholder groups requiring a change in mindset especially during the post roll-out release cycles.

The typical implementation consists of a rapid deployment to either the entire user base or a subset of users. This is then followed by a series of new functional releases and a roll-out to the remaining user base. This can be described as a rolling roll-out and requires the deployment team to think differently.

From the requirements gathering process right through to the training sessions the deployment team has to adjust to running multiple mini-releases in a compressed time frame. This is not sustainable indefinitely but can be done over a 12 to 18 month period as opposed to a having one massive release at the end of, say, a 15 month project.

The key to success lies in the ability of the deployment team to re-engineer and re-imagine the old way of doing things. This means defining the nature of application changes and developing a strategy to manage each of these types of changes. For example, basic configuration changes will not require the full suite of change control tasks while new functionality which requires some level of code customisation will require a more rigorous approach.

Zoho

Zoho is under-rated, not sure why. Perhaps it has to do with the name. No other platform has the breadth and depth of vision as Zoho. It's an amalgamation of Google apps and Salesforce.com.

Read what ReadWriteWeb has to say on this.

Thoughts on choosing a saas provider

Have been trying to unpack some of my thoughts on saas and saas providers. Here's the first pass.

1. Are the requirements met by the existing offering? Are add-ons, third-party modules required?

Understand how much of the native platform's functionality will meet your needs and how much will have to be added on (and at what cost)

2. How open is the saas platform to integrating with other applications?

If you have existing an application, say, which holds your master customer data like a CIF then you'd want to integrate the data rather than maintaining multiple databases

3. Is the platform extensible? Can new functionality be added and/or existing functionality customised?

You don't want to invest in a niche-platform which will be limiting should you want to extend functionality later

4. What is the track record of the saas provider and what is the vision?

Have a quick look backwards and forwards, you want a platform which has been around for a while and has a roadmap for growth.

5. Are you considering saas because you really need and understand the benefits or are you caught up in the cloud hype?

In my view there are a couple of compelling reasons for going saas: you don't want the hassle of managing infrastructure, you want to be up and running quickly and you need access from geographically dispersed regions (the common theme being avoiding effort and investment in and management of I.T. infrastructure)

Saas adoption

For all the benefits of saas, enterprise adoption may be hampered by a number of factors. These may vary from region to region but are mostly generic. These include total cost of ownership, trust and privacy, and application performance.

Total cost of ownership

While infrastructure capital costs and subsequent running costs are avoided in the saas model. In an on-premise model, assume hardware, software and implementation comes in at $100k with recurring annual costs of $25k. For a SMBs/SMEs the saas subscription model is virtually a no brainer since it can be up and running in weeks and can scale as users grow assuming a modest user base of 40 users and say, a subscription cost of $50 per month. The annual cost is still under the annual cost of the on-premise model even before taking the initial costs into account.

In a corporate environment the numbers are amplified but the cost progression is the same. At some point, as user numbers grow and the application is enhanced to cater to specific business processes, the subscription cost nears and then may surpass the on-premise cost.

The discussion with the executive then should be based not only on the TCO threshold but also on whether the enterprise is willing to develop and maintain a competence in IT infrastructure management. The case can be made for core business application infrastructure management while other functions such as CRM, billing, HR and marketing can be saased-out.

Next time we'll discuss trust and privacy.