Benefits and Drawbacks of SaaS

Benefits

For the Consumer	For the Provider:
No client/server software installation or maintenance - that's right, no more 800-page planning and implementation guides.	Aggregate operating environment - as a provider, you own your domain.  No longer are you sending technicians to fix or customize your software because it doesn't fit into a customer's highly-specialized (or horribly outdated) infrastructure.  You have complete control to optimize an infrastructure to your SaaS application's specific requirements.  This is synergy at its best, and leads to financial savings as well as less headaches.
Shorter deployment time - potentially minutes as opposed to a phased implementation that could take months.	Predictable Revenue Stream - the subscription model associated with SaaS means that your customers will pay you on a recurring schedule.  If you make this cycle flexible enough, you can get a real handle on forecasting revenues.  The payment may be tied to your product (think cell phone plans) where everybody pays according to the same term, or tied to your individual subscribers where some may pay monthly, some yearly, and some quarterly.
Global availability - sure the technology exists to make on-premise software available outside of the premises, but we're talking about functionality that is available from anywhere on the internet natively	Predictable Growth - Same as above, but here we're talking about sheer volume of subscribership.  The fact that users hit your site to access the application means that with the right tools you can monitor their usage pretty closely - something that's not so easy with all your customers running the application on premise.
Service Level Agreement (SLA) adherence - reported bugs can be fixed minus any rollout overhead.  Sure the provider actually has to fix the issue, but assuming they've deployed a moderately efficient SaaS application the rollout of a patch or fix should happen in the blink of an eye.	Focus On Smaller Upgrades Instead of Monster Patch Rollouts - and while you're at it, don't worry about rollout logistics across all of your customer sites either.  Your development teams can focus on fixing core application functionality, tackling bugs and enhancing features in smaller incremental rollouts because it's just easier to do so.
Constant, Smaller, Upgrades - when you use a SaaS application, it is in the best interest of the provider to keep you happy and they can do so by constantly improving the application experience.  With SaaS this can come in the form of consistent miniscule changes that add up over time instead of monster patch and upgrades that cost you time and money to implement.	Sales Becomes Customer Relationship Management - When you are selling a subscribable service, the game of gaining subscribership becomes one of balancing user retention vs. attrition more than a game of landing the 'big deals'.  Sure, it's important to have a team out there pounding the pavement to sell your application - i.e. getting subscribers in the door - but the real thrust of the new sales and marketing in SaaS is customer relationship management.  The equation becomes quite simple - keep retention rates higher than attrition rates and focus on bringing in new customers.
Ease Your Internal IT Pains - This is a big one. Most of the last several points here highlight that SaaS offloads a great deal of IT pains incurred by software consumers in the traditional client/server model.  This leaves IT personnel to focus on improving the day-to-day technical operations of your company instead of being called upon to troubleshoot 3rd party software or maintain aging infrastructure.
Redistribute IT Budget - by outsourcing software functionality to a provider, the enterprise realizes a cost savings in infrastructure requirements and IT personnel knowledge requirements.  This allows the enterprise to focus on core competencies.  It also means that the cost savings from using SaaS applications can be flat out saved, or reallocated to boost productivity through other services

 

Drawbacks

For the Consumer:	For the Provider:
No direct control of the data - One of the biggest hurdles to get over is the control of the data. Specifically, what happens when things go wrong? I'm sure every company trying to sell you a product will tell you that things can't go wrong and that they will be there to support you for years to come. It is important that you ask the difficult questions: How safe is my data? Will I be able to download it? Will it be disposed of properly and safely? Can it be sold? Can anyone else host the application and my data? Will the application source be opened so that hosting can happen in house or by another provider? Stories of companies going belly up are not uncommon, and not only for SaaS companies but for traditional software companies as well.	Focus on customer satisfaction - This is one of those bad things that it's good to have and makes great companies but we have to mention it anyways. SaaS providers need to focus on customer satisfaction month in and month out or they will lose their customers. They need to earn their customer's business every month or they can simply leave. Contrary to on-premise deployments which are very costly and time consuming, if your customer is unhappy with the service he can up and leave at any time with very minimal cost. Some might argue that you can negotiate longer term contracts, make it hard to take their data and all other kind of shenanigans but if you ask me, it is bad practice and if you are not the best, then you better have one damn good reason why they should stick with you other than a binding contract.
Internet connection required - I don't know of many businesses that run without an internet connection these days. Nonetheless, it could affect your operations if you need to access an application and the internet connection is down.  A good set of companies are trying to solve this problem by allowing their applications to continue to work in a disconnected fashion for a period of time but at some point you will need to sync back up to the server. If this is a big concern for you make sure that your provider can address this need.	Harder development process - There are many different approaches to writing SaaS applications and they are outside the scope of this article but the bottom line is that there is a whole new set of things that you need to worry about when writing a SaaS application that you otherwise wouldn't need if it were a traditional on-premise deployment. Things like tenant isolation, provisioning and scalability to mention a few could be a hard thing to tackle where you wouldn't even have to think about if you were writing an on-premise application.
Dependence on an outsider to run your business - In a big way, you are trusting an outsider to help you run your business, and if they are not keeping their end of the bargain it can really affect you. To keep it in perspective, these people are out there to stay in business and they do this for a living so arguably 95 out of 100 times they can do it a lot better than you could in house. This does not mean that you shouldn't be aware of the implications so make sure you ask the tough questions.	Compensation issues - One of the early problems for SaaS providers is how to maintain operations when there is only very little money coming in. Unlike traditional on-premise deployments where one deal could bring you $60,000 upfront and carry you for a couple of months while you close more deals, SaaS deals are MUCH smaller so initially it will be a lot harder to maintain operations unless you are properly funded so you can survive until enough money is coming in .
Security awareness - Another big hurdle is security. This concern is the umbrella that is home to the concerns above, as the common thread among them all is that they make you consider how "secure" you feel with SaaS. You are trusting your really valuable data to someone else. This can be a painful reality to accept but most security breaches occur because of disgruntled internal employees that end up selling or releasing the data when they are fired or when they quit, having your data managed and stored by an expert of the application is not a bad idea as long as they take it as seriously as you would.	Success can be a problem - You've heard many times that being too successful is a great problem to have but in the case of SaaS it can literally bring you to your knees if you are not prepared. This goes back to my second point of SaaS being harder to develop. Things can grow out of control if the application is not architected properly and addresses scalability issues and your service can become unusable over time if it does not scale properly with the addition of new tenants. Make sure you don't leave the hard decisions for later because you will run into a wall down the road.

This blog entry is a tabulated version of SaaS' Benefits and Drawbacks