Challenging SaaS (part 2)

In this post I shall continue with the “anti-SaaS” arguments. In the previous post, we saw some arguments that are usually thrown to the table, from the first 5 minutes of discussion. If you get past these critical 5 minutes, then the discussion goes into more specific issues, such as the following:

What happens if Internet fails? Assuming that SaaS is a synonym to Internet Technology, this is the among the first (and funniest!) arguments that I have heard. Some people (say that they) recognize all positive aspects of SaaS but they are afraid of what’s going to happen if Internet fails. My usual answer is that “internet DOES NOT fail”. It is more probable that the electricity in your neighborhood is going to fail, than the Internet lines. And what do you do when electricity fails? You just stop working because your PCs are not working; the elevators in your building have stopped etc. Or, if you MUST work then you switch to manual: You issue invoices from your hand-written statement block and you process orders manually. That’s life!
I challenge all those people to tell me when was the last time that internet failed and they just don’t remember. Let’s face it: Internet is a commodity just like the running tap water and electricity. It is essential for everyday (corporate) lives and we cannot design our policies around the possibility that “internet may fail”.

Our corporate policy refuses SaaS architecture. General corporate rules may refuse or discourage the adoption of SaaS architecture and/or offerings. The main concerns are a) the actual location of the data and who has access to them, b) general security architecture guidelines and requirements that the Enterprise believes cannot be met by the vendor. The first problem of where the data actually resides has been answered in the previous post. Regarding the second issue of architecture guidelines, we have first to make this remark: it is not unusual that a SaaS vendor overbalances the customer’s requirements, simply because the vendor has “done it before”. In any case, the vendor should be in a position to accept security reviews, apart from offering a “good” SLA. This may even come down to actual Data Center review on behalf of the customer’s security team. Now, maybe, all these sound a little too much for lightweight applications that tend to sell directly to internet customer. But when we are talking about medium-large enterprises, then it becomes a real consideration.

We are OK with the data being stored in the cloud, but we need local backups, on demand. In my opinion, there is no reason for this request. If the SLA covers the backup issue (which, obviously, it does) then the enterprise does not need local backups. Even in the event of contract termination the customer can surely expect that their data will be delivered to them in a readable format. But again the vendor must have a ready answer: either their systems offer this on-demand local backing up by the end-user or they provide this service upon request.

We need to deploy our own Reporting and Business Intelligence tools. OK, now it gets tricky! This customer wants to buy SaaS but they want to apply their existing BI methods and tools on that Cloud Software. Not very probable! Unless these systems offer some out-of-the-box functionality for plugging-in. Or if the vendor has already integrated with some of the famous BI and reporting tools. In any case, I think that this is just wishful thinking: you can’t expect that you’ll change your “heavy-duty ERP” with a new SaaS offering, but still be able to use the good-old same reporting system. It’s like changing your car with something new and advanced but insisting on using that old steering wheel! Sure, it worked fine, but it doesn’t fit to your new car!

More to come on the next (and last) part of this blog sequel.