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:
3 Comments
Join the conversation and post a comment.
Leave a Comment
Follow Me!
Steve, good points but begs the question why CIOs are trailing, not leading their business users when it comes to SaaS. In the work I have done with some of my CIO clients they understand the risks with SaaS but see it as way to clobber traditional on-premise costs and in fact get closer to users by “outsourcing” a lot of the mundane stuff SaaS takes over – like Eric Dirst, CIO of DeVry as he wrote below on my blog
http://dealarchitect.typepad.com/deal_architect/2009/04/the-cloud-pioneers-eric-dirst.html
Steve, good post. I think the “IT involved at the last minute” item is the key point for many. I hear about this often in organizations/departments where either 1) IT has not had a history of effective partnership with the business or, perhaps more likely, 2) the business is “blown away” by how fast things can be procured and installed in this new model, and would just as soon bypass the weeks (months?) delays just to get a server up and running internally. Having managed both the infrastructure, and the developers wanting to have infrastructure deployed (in a reasonable time), there is a real dynamic tension there. Should keep us on our toes for the next few years….Thanks
Steve,
Funny thing as I was just thinking about this very topic. IT is seen as a hindrance in most corporations and not helpful to the business units. In fact, most business users’ experience with IT is delayed ERP implementations (sometimes years) and systems that do not solve their business needs.
Therefore, business users are forced to use SaaS or cloud applications to handle issues IT is incapable of. In fact, some are relieved they don’t need IT because of the challenges of NIH (not invented here) or working with an IT group incapable of understanding how to deliver a CRM system.
How do you think Salesforce.com got so big? I’d argue they took advantage of an IT black hole in this area.