my musings on technology

SaaS Deployments – Lessons Learned

Posted by on Jun 12, 2009 in Musings | 3 comments

There is no shortage of buzz around Cloud Computing and SaaS and I know a large number of companies are looking at SaaS as a cost-effective mechanism to get applications out to their users, but who should own the deployment and management of a SaaS application?

Cloud computing is defined by Wikipedia as:

“Cloud computing is a style of computing in which dynamically scalable and often virtualized resources are provided as a service over the Internet. Users need not have knowledge of, expertise in, or control over the technology infrastructure in the “cloud” that supports them.”

I have been involved in a few SaaS deployment over the past couple of years and have learned some lessons from these deployments that I’d like to pass on to hopefully prevent these mistakes from happening to anyone else!

In the ‘pre SaaS’ days, if a HR department (for example) wanted to purchase a new HRIS system they would be forced to engage the IT Department (even if at the last moment) as ultimately they would at least require servers to install the application on. There was at least a crude mechanism in place to prevent a rogue application deployment.

Nowadays a non-IT business unit can very easily procure and deploy a SaaS application and have it up and running with absolutely no IT knowledge or engagement – and this is extremely scary! For an organization to grow and deploy applications successfully they need to centrally managed.

I have worked for a couple of companies now that have deployed SaaS applications – both successfully and unsuccessfully and below are some of my experiences:

1) IT Involved at the Last Minute

This is my biggest concern regarding SaaS. It is far too easy for a department or group to go out and sign a SaaS contract for a software application they claim they need without council from IT. It is easy for a SaaS vendor to turn up an environment and hand it over to the end user department. What the department then discovers is that the setup, configuration and administration of the software is not as easy as it looked when the vendor salesman was doing his demo. At that point they have 2 options, either pay the vendor for additional professional services hours or call IT up and request assistance.

2) Post Go Live Integration Woes

One item that can be overlooked is how these SaaS applications will integrate with current IT systems. A number of SaaS vendors adhere to SOA standards which make the integration piece technically possible, but if the integration is overlooked or left until the last minute then this can cause problems and unscheduled IT projects.

3) SaaS Applications Not Meeting the Need

Another interesting observation is that users underestimate the flexibility of the SaaS application. It is only after the SaaS application is deployed and being used that the users find out how inflexible a hosted application is. This makes sense to us IT people but our users expect an application that is hosted in a Cloud Computing environment (shared among many subscribers) to be as flexible as an on-premise solution! And quite simply, it is not!

SaaS applications can be extremely advantageous to an organization for many reasons, but to be successful in deployment I would recommend the following to any company – large or small:

1) Engage IT… Early!

Your IT department is very well versed in software application deployment and knows what to look out for. They will be able to ask the Vendor many questions regarding both the implementation and integration of the SaaS application to current IT applications.

2) Be Prepared for Tighter Controls

Unlike on-premise applications, with SaaS you are at the whim of the SaaS vendor with it comes to upgrade schedules and planned outages. This is also true for application modifications which are more limited as you are typically on a shared infrastructure.

3) Always Expect Longer Deployment Times

SaaS vendors often quote 30-days or less deployment times and that might be true with respect to getting your environment provisioned but that is not the whole picture! Make sure you press the vendor for just how long it will take to get your environment customized and integrated with your existing systems before making internal time commitment promises!

4) IT Supportability

There is often the assumption made that once the application is Live and being used, that your internal IT shop is the support mechanism for any day to day troubles you may experience. We simply are not and don’t desire to be! One of the benefits of outsourcing the software is that IT doesn’t have to be the expert with your software product. Make sure you have the appropriate support contracts complete with acceptable SLA’s setup with your SaaS vendor to ensure you have the support available when needed.

Please don’t get me wrong, I’m not trying to shed a negative light on SaaS deployments – I just want to make sure you are aware of the potential pitfalls and don’t get caught up in the hype that SaaS is the quick, cheap and easy solution to your software problems! I love the fact that my IT department doesn’t have to learn, support and maintain a new application. But please be aware of the gotchas I’ve outlined and learn from my (and others) experiences.

Similar Posts:

Get Adobe Flash player