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:
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.
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.
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.
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.
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.
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.
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.
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.
What makes this decision particularly challenging today is that these concerns cannot be easily separated. It does not have to be this way. SaaS vendors do not necessarily have to do the hosting themselves and could license the intellectual property independently from the cost of hosting the software. This will allow large companies to host the software internally, maintaining full control over data security, availability, etc. For legacy apps, introducing a SaaS option may mean as little as changing the licensing model and adding a third-party hosted option to make it more cost-effective for small and medium-sized businesses. How exactly this will play out will be determined by a combination of market forces and technical innovation and it is hard to predict. This makes SaaS one of the most exciting things to follow these days.ReplyDelete
Good read Lubor. I agree with your position that SF.com may not exactly be 'mission critical.' The thing that always struck me about their success in the SaaS market is that their very being kind of dispels some of the concerns about security. A company's detailed customer information is arguably one of their most valuable and prized assets. Yet, of all the SaaS solutions to become most popular (sans email) much of corporate america seems to have no issue with shipping off valuable CRM data to the cloud and trusting a 3rd party with keeping it safe from prying eyes.ReplyDelete
A solid examination and assessment of the factors. Once the security and other barriers recede, I believe there will truly be an explosion of these...and they will be creating even more content which remains in the cloud...more thoughts at http://jameslatham.wordpress.com/ReplyDelete