I can’t help but comment on some of the doings out there by John Dvorak and Matt Asay. Troublemaker that he is (heck, I love John, he’s been stirring the pot ever since I can remember), Dvorak kicked the whole thing off with a rant about how maybe moving everyone’s software into the cloud is really not such a good idea. It makes us more vulnerable and John tickles our sense of paranoia into a throbbing feelling of vague unease:
All this proves is that these Web-based applications cannot be trusted.
Matt makes the source of the paranoia seemingly much more concrete:
In a SaaS world, even more than in the traditional proprietary world, you are 100% helpless if something goes wrong. Not only do you not have the code (as you would if you had a on-premise desktop/server software), but you also don’t have the IT staff to be able to go in to troubleshoot. You’re completely reliant on the vendor.
I say seemingly, because both these guys are dead wrong. There are some folks like Amy Wohl, Fryer’s Blog, and others chiming in with their two cents, but I wanted to give my own spin.
It may seem that SaaS leaves you helpless (I’m not even sure I agree with that), but reality is that you’re actually better off. Let’s pick apart some of this stuff and get a real perspective on what’s going on.
Let’s just start with the proposition about the code. Who in the Enterprise has the code for their Oracle DB servers? What about the code for SAP? No takers? And what happens when there is a big time problem with your On-premise ERP application? Is your IT staff fixing it? Or are you running to your ERP vendor to get them to do it? Haven’t we reached a point where IT is writing very little code, and isn’t that a good thing because the code they do write is hopefully something to give their business a unique advantage? And what about the issue that SaaS is largely a phenomenon of Small and Medium Businesses? Aren’t these organizations even less likely to have IT staff writing code on apps that can be bought?
My experience building and selling mission critical enterprise software leads me to a much different conclusion than what the armchair quarterbacks are touting. If your mission critical software goes down, you are not fooling around in IT with source code, you are on the line to Tech Support, and if it’s really bad, you are on the line to the Executives or CEO of your vendor and whatever VAR installed the silly thing demanding immediate action.
Let’s walk through an unfolding IT crisis and see what happens with typical On-premise vs SaaS Enterprise Software. I think you’ll be surprised if you haven’t thought about this or lived through the exercise yourself.
I have to make a point in favor of SaaS right up front as we walk through the chronology. If the SaaS vendor and their offering are up to snuff, they know you have a problem almost as soon as or even potentially before you do. In fact SaaS vendors are much better positioned to have taken care of the problem before you will ever have a chance to see it than their On-premise cousins. Huh? Isn’t this just testing your code properly? Why does a SaaS vendor have an advantage? Testing is important, but SaaS vendors have another huge advantage over On-premise: they fix problems before you encounter them much more easily.
I did some benchmarking among SaaS and Enterprise vendors by going out and talking to a number of my peers. One of the questions I asked was quite illuminating:
How many of the problems reported to your Tech Support organization had already been fixed in some release of your software?
I tended to get 2 strongly polarized responses. The vendor either had no idea, or more interestingly, they concluded that well over 50% of problems were already fixed in some release of the software. I can tell you that my experience was definitely in the “well over 50%” end, hence I wanted to see if others were seeing the same. Since SaaS vendors are upgrading you constantly and transparently to the latest versions, 50% of all Tech Support incidents are being nipped in the bud before the customer even sees them. Imagine what it does for customer satisfaction when half your Tech Support incidents are eliminated? Bugs are going to slip through for any software, but with SaaS, we can fix the bug for everyone as soon as even one customer (or our internal testers) finds it.
While on the subject of testing, consider how much easier it is for the SaaS vendors to test because everyone runs the same version of the software. Testers don’t have to split their time and energy among multiple platforms. They don’t have to waste time certifying hot fixes that will only matter to one customer who stubbornly refuses to upgrade. Worries about the interactions between patches and hot fixes are a thing of the past for a SaaS vendor.
Continuing with the process, you’ve now gotten your ISV’s attention and its time to diagnose the problem. Diagnosis is another area where the SaaS vendor has a huge advantage. Before diagnosis can proceed, the ISV has to narrow the search down to one of three categories:
– It’s a bug or product problem.
– It’s pilot error (the FAA is right, this is usually the reason). But which pilot? Was the software improperly customized or installed? Are users asking the software to do something it just doesn’t do? Documentation, help, or UI confusing customers (that’s only partially pilot error)?
– It’s an environmental problem. I’ve had customer DBA’s delete all the indexes on my app’s DB and then someone calls and says, “The app has crashed.” Well no, it didn’t crash, it just ran so slowly you wished it did. Who deleted the bleepin’ indexes anyway? In another case, a customer had a faulty router between 40 cpus of transaction processing and the DB. Guess what that does for throughput, and why weren’t they on the same subnet anyway?
The customer (and the VARs, unfortunately) will always start out assuming there is a bug. The ISV starts out assuming the problem is first pilot error, second an environmental problem, and only after eliminating the first two do they move on to the assumption there is a bug. Diagnosis almost always takes longer than coming up with a fix, often days longer while your organization is in agony over the problem.
Now let’s consider how the two vendor types (On-premise and SaaS) triage through the three diagnosis categories. The On-Premise ISV will start out walking the customer over the phone through what’s happening, hoping to identify a misconception or user error right there. We’ve all sat through these painful sessions where the Tech Support guy just doesn’t seem to get it: they can’t see your problem and it’s painful to explain over a phone. Now let’s consider the SaaS vendor. The software runs inside their data center, not yours. This gives them the access to be able to see much more directly what you are doing on the application. Clever vendors will set it up so they can see exactly what’s happening on your screen step-by-step. Advantage SaaS.
If the phone session fails the next step is to check the bug database and see if anyone has reported anything similar. But wait, the SaaS vendor can eliminate most of this as bugs get fixed as soon as they’re reported for all customers. Meanwhile, the On-premise guys are going to tell you to install this new version or that patch. Never mind that this can be a huge undertaking for Enterprise Software. I’ve seen cases where just upgrading to a new app server version that’s known to fix the problem can’t be done because it would interfere with other 3rd party software running on the same server. Drat! We’ve also all been through doing the upgrade or reinstall on something and despite Tech’s assurances, it made no improvement whatsoever, it just wasted our time.
Are you beginning to see how this works? No? Let’s keep going. The phone talk through didn’t help. New versions and patches didn’t help. Now we have to try to duplicate your problem on our in-house hardware as a final check against environmental issues. The ease with which some DBA or person in the IT shop can mess up the carefully nurtured environment for a piece of software is frightening. Database servers are filled with parameters and DBA’s like nothing better than fooling with them to get a little more performance. Worse, some enterprise software just has to be constantly tweaked to keep it happy. Of course with SaaS, your software is already running on our hardware. The people that wrote the software have dictated the ideal environment. You don’t have to wonder if you are the largest customer running on a particular stack that has hardly been tested. Every customer runs the same software version on the optimal reference stack and that environment is tended to by experts. Lastly, you are most likely part of a multi-tenant environment, meaning that if you are the only one with a problem, that’s another immediate tip-off that it isn’t environmental. SaaS, move ahead three squares; On-premise, do not pass “Go”, do not collect $200.
Now we’re at the last, most finicky, and most contentious stage. We know it isn’t environmental. We know it isn’t a problem with a prior release. We know it isn’t user error because we can see exactly what you are doing. It has taken an On-premise vendor a huge effort and probably quite a bit of time to establish all this. The SaaS vendor knows within the first phone call if they’re set up right, and already has a huge advantage. Even better, they may have eliminated the problem before you encountered it. But assuming that’s all failed, we now have to fix a bug.
Even here the SaaS advantage is huge. Customers for On-premise ISV’s frequently want the developers to fly out to their site to fix a problem. It makes them feel better, because after the painful diagnosis process, they’ve now gotten the message up close and personal about how hard it is to do remote diagnosis. Guess what? With SaaS, the best and the brightest are already at your data center! You get that red carpet treatment that is usually offered only rarely to the best and biggest customers no matter who you are when you buy SaaS. And the developers are much happier and more productive. You can never fly everyone to the customer, but all the developers are together for SaaS, and anyone who needs to help can easily jump in or give feedback.
Let’s consider a last issue in terms of preventative maintenance. If you’ve been in the Enterprise Software game as I have, you will know that not all customers and SI partners follow your Best Practices recommendations. Sometimes they can’t, sometimes they won’t, sometimes they just didn’t know, but always they should. This can range from how the software is installed, the infrastructure supporting it, day to day operations, or whatever. With SaaS, the vendor can ensure that the latest Best Practices are always used with their software. Six Sigma devotees will recognize the enormous advantage SaaS has with respect to repeatability. On-premise vendors will know firsthand of the tremendous variability of customer experience with the same software because of all the factors one has to get right before it all comes together. With SaaS, the vendor is in control of many more of those factors, and this does lead inevitably to better Customer Satisfaction.
As to the “helpless” slant, the real power to help one’s self was never a matter of laying hands on software or hardware. It has always been the ability to bring pressure on the vendor. Once again, advantage SaaS. The On-premise ISV has your software license check a long time ago. At this stage they are gambling with maintenance and their reputation. The stakes are higher with SaaS. They get their payments monthly, and not all up front. A monthly SaaS payment is bigger than a maintenance payment, aAnd by the way, most of the problems with these systems strike early on, so the SaaS vendor has a lot at risk from the beginning. As Chris Cabrera at SaaS vendor Xactly is fond of saying, “We have to earn your business every day. ”
I hope all of this makes it clear how much better off the customer is with SaaS. It’s yet another testimony to what the final “S” for Service in the acronym really means (if you’ll pardon the double meaning):
SaaS simply works better.
Related Articles:
Things that SaaS Customers No Longer Have to Worry About
SaaS Resolves the Software Prisoner’s Dilemma
Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon