To SaaS or Not To SaaS

A couple of years ago, Nicholas Carr published the book The Big Switch where he proclaimed that Software as a Service (SaaS) is taking over IT. Since then, it’s been a few years now and we are still waiting for the next SaaS killer application since Salesforce.com. Sure, there is Gmail which is supposedly a SaaS replacement for Exchange. But Gmail is basically the same as Yahoo Mail which we have been using since the early 90s – it would be presumptuous to declare that SaaS based email has made the ‘big switch’.

Don’t take me wrong, I am a SaaS optimist. I do believe that you can start a company today in which the entire IT infrastructure consists of a wireless router. But for most existing organizations, the big question is which applications are candidates to be taken on by SaaS and which are not. The following factors should help:

1.Security
One of the most common questions about SaaS applications remains “can we trust a SaaS provider with our confidential data”? But what if your data could be more secure in a SaaS application than inside your enterprise? Many organizations use ADP as a SaaS application for their payroll. I’d trust ADP’s security more than the security of most employers. Similarly, when subjected to a denial of service attack, Amazon may be better equipped to protect you than your own firewall. I believe that security is only a factor in truly high-security environments such as military or national intelligence.
2.Mission Critical
Can we assume that SaaS applications candidates are only the non-mission critical applications? After all, Salesforce.com can hardly be labeled as mission critical. Sure, a Salesforce failure in the last week of a quarter sounds like a bad thing but most of sales pipeline work is not done in the last week and even then the sales reps find a way to get the contract signed using e-mail or fax. Not many organizations that use Salesforce actually process orders in a SaaS application.
3.Legacy
Are SaaS applications more likely to succeed in an area without a lot of history? Replacing incumbent applications, particularly those with significant data legacy is difficult. Sales Force Automation existed before Salesforce.com but it had a very low penetration and most of the Salesforce.com deployments replace spreadsheets. If you have terabytes of transaction data in your ERP, you may not want to move it all out into the cloud. And if you don’t you will end up keeping your on-premise system and not achieve your SaaS objectives.
4.Customization
Are SaaS applications limited to solutions that need no customization? After all, the most widely used SaaS-based application is e-mail which is a perfect example of no customization. Salesforce.com is combating this challenge with APIs and an array of add-on modules but it can hardly be expected that every SaaS solution could do the same. Besides, highly customized Salesforce deployments start resembling the complexity of on-premise applications. Also, the customization needs are correlated to the application maturity and their innovation cycles. Less-mature applications should expect a high pace of innovation with frequent upgrades.
5.Silos
If you entrust your data to a cloud, you have to accept that it will not be managed consistently with the data in another cloud. When applications require a common data store, it can only work if they actually come from the same vendor. I don’t think that all applications need to share a common data model and policies but some for sure do. If they do, SaaS might not be the right approach.
6.Data Volume
The math is pretty simple – the total costs of ownership of a SaaS application is determined by the number of months and megabytes of data stored. If your pricing model includes charges for the volume of data stored, you need to consider that a factor for SaaS suitability. Annual performance reviews in SuccessFactors hardly consume a ton of data. An email archive, however, does, and if it charges by data capacity, you might be looking at a steep bill down the road.
7.Utilization
One of the greatest benefits of running a SaaS application is the ability to leverage a vast infrastructure providing sufficient provisioning for any peak in utilization. That is assuming that your SaaS provider operates an infrastructure shared across multiple customers and that all the customers don’t experience peaks at the same time (e.g. quarter end or tax time). Scaling effortlessly to utilization peaks is important to certain applications and such applications are good candidates for SaaS.
8.Performance
Performance is only a factor in some cases. The performance of SaaS applications is likely to be better than the performance of on-premise web-based applications – the SaaS apps enjoy greater resources and better optimization. Only certain applications in which users are paid by the volume of processed transactions or where they manipulate vast data volumes need to consider performance a factor.

The table below features examples of different content applications, covering a broad spectrum of ECM. I have done a simple and very high level assessment of the factors above. This assessment has to be taken with some care as there is a lot of room for interpretation. But the table suggests interesting results:


As you can see, there are only very few slam-dunks here. Arguably, new product introductions and idea management are well suited for SaaS deployments. A marketing web site and litigation discovery (used for the review, analysis, and production stages of the litigation process) are also likely candidates. Running a terrorist threat assessment or insurance claims processing, on the other hand, seem to be better done on premises. The bottom line, however, is that the answer is almost always ‘it depends’. But it depends on the factors laid out above. Those factors and their weighting should be examined for every application before making the call whether to SaaS or not to SaaS.