Being Contrary to the Contrarian

This month’s CFO Magazine has an article by John Edwards called “Software as a Serpent“, in which he mentions leading SaaS vendors (including LucidEra) and highlights what he considers to be issues with the SaaS model. Certainly there’s no perfect model for software (or anything else in business, for that matter) — everything has it’s pros and cons. But, some of the cons presented in this article aren’t very valid. Just as SaaS is sometimes criticized for being too hyped, I’m sensing the inverse here — maybe it should be called anti-hype? Some of the overly anti-hyped topics are listed below.

One bad apple doesn’t spoil the whole bunch

The article mentions how Covalent Technologies originally went with SaaS solutions, but it “failed pretty miserably” for them. To me, finding one company with a failed SaaS implementation doesn’t damn to whole category. What we should be looking at is the success / failure rates across broad ranges of companies. Companies in general have had higher success rates with SaaS implementations than with traditional on-premise software. Part of this is due to the nature of the model — if you’re not successful with a SaaS implementation you’ll stop paying the vendor, so the vendor has a direct financial incentive to make their customers successful. With the traditional model, if a customer isn’t successful with the solution, they’re stuck with it — they can’t return it, so they end up with shelfware, and the vendor still keeps all the money (though admittedly they won’t get future maintenance fees). Also, this ties in to the cost of failed implementations between the two models. With the traditional model, there’s much higher risk. You have to make a major investment upfront (you have to buy the software), and if the implementation fails, you are out the full cost of the solution. With SaaS, it’s typically a pay-as-you-go model. If it doesn’t work out for your company, don’t renew your contract when it expires, and you’re out the subscription fees and the consulting fees that you’ve spent to date, which are typically far, far less than the upfront costs associated with buying traditional software. (When I was at Siebel, their largest customer spent $22M on Siebel software and services and never got it working. Ouch.)

Integration frustration

The article also talks about how it can be difficult to integrate on-premise solutions with SaaS solutions. This is a red herring. Ease of integration has nothing to do with whether that application is a SaaS application or an on-premise application. From a technical standpoint, there’s not that much difference integrating two apps that are in the same data center versus apps that are in two separate data centers. The only real difference is whether or not the data goes through a firewall, and that’s not much of an integration hurdle anymore.

In 2000, when I was at salesforce.com during its early days, there was a valid argument that it was difficult to integrate on-premise solutions with salesforce.com. But many years ago salesforce.com introduced a great web services interface, and for the most part many of the other SaaS vendors have followed suit. And how easy is it to integrate with salesforce.com now? As a case in point, LucidEra’s solution integrates with both salesforce.com and Oracle Financials. It took us a few weeks to build a robust connector to salesforce.com. The Oracle Financials connector was much harder to build and took a few months.

Blackouts

The often quoted multi-hour salesforce.com blackout is often used by traditional vendors to sow fear in the minds of prospects considering a SaaS solution. This needs to be put in perspective. The valid comparison is to look at the uptime of a hosted solution vs the uptime of a solution you would manage yourself in-house. Check out http://trust.salesforce.com. Does your internal IT staff provide the same level of reliability? Have any of your internally managed systems ever gone down? For the majority of you, I’m willing to bet that your internal systems are far less reliable than services offered by most SaaS vendors. This is because SaaS vendors spend a large amount of money building reliable systems — much more than a typical midmarket company could ever spend. (The article mentions that Netsuite disclosed that it doesn’t have a backup data center. Admittedly, that’s an exposure. But it’s certainly no different than the vast majority of midmarket companies that don’t have backup data centers either.)

Customization

This is an interesting point. It’s often true that you have more ability to tweak anything you like with on-premise software than with SaaS solutions. But, for most companies this is a double-edged sword. The ability to customize anything has created a culture of over-customization in the industry — people customize everything just because they can, even though a large percentage of the customizations add very little value. Another case in point from the Business Intelligence world: Wayne Eckerson from the Data Warehousing Institute wrote a paper called “Development Techniques for Creating Analytic Applications” in which he surveyed companies regarding what types of customizations they did to analytic applications that they had purchased. Customizing the look and feel was the largest source of customization expenses, closely followed by customizing the layout as the second largest customization expense. Neither of these add much value to an organization or increase the insight they get from their analytic solution.

Nothing’s perfect, and it’s good to know the pros and cons of all options available to you. But, in my experience the key deciding factor for most companies looking at on-premise versus SaaS solutions isn’t based on an unbiased analysis of the pros and cons. It’s based on their culture and their comfort level with trusting someone else to manage a part of their technology platform. Companies are already extremely comfortable letting third parties manage two core technology platforms: their electricity and their phones. It’s only logical that this will extend to other technology platforms such as operational and analytic applications.

posted by Ken Rudin at 3:39 pm

---