With SaaS Are You Are 100% Helpless Or Much Better Off?
Posted by Bob Warfield on August 31, 2007
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
9 Responses to “With SaaS Are You Are 100% Helpless Or Much Better Off?”
You must log in to post a comment.
You’ve Already Had a Multicore Crisis and Just Didn’t Realize It! « SmoothSpan Blog said
[…] Submit to Digg | Submit to Del.icio.us | Submit to StumbleUpon […]
ebsherman said
Let’s just be clear, here. Mr. Warfield is an executive at a company whose business is this very area, so he does have an axe to grind. Further, he’s addressing the issue of a major technical problem and needing help, and he does have a point that depending on the kind of problem the SaaS vendor may be in a better position, because it’s giving the vendor complete control.
But that doesn’t address the issues of needing Internet connectivity to do anything if a worker is mobile, of who actually has possession of data and of the larger security issues (not just electronic security), of being forced to move to a new version, of having to revert to a leasing approach to software rather than owning, and of being more tied to a vendor than you are if you have the software and data in house.
When looked in a broader view, Mr. Warfield’s argument is limited and constructed to emphasize the positive of his industry – which is fine. But those who are not in the industry might want to consider a broader set of issues.
smoothspan said
Eric, thanks for writing us!
Let’s take up your points. First, I’ve been an Executive at both kinds of companies, and I think it’s important to look at both sides of the fence. There are certainly trade-offs, I just happen to think that when the dust clears, the advantage lies with SaaS by a pretty big margin. Others may disagree–that’s why we have both chocolate and vanilla. But let’s at least try both flavors and understand what we’re talking about. Let’s deal with the facts and not so much who works for whom, in other words.
RE mobile workers. Interesting point. Note that for most Enterprise Software, the mobile worker is equally as disadvantaged. Whether they are outside the corporate firewall or dealing with a SaaS vendor, they need a solution to the connection problem. The good news is that products like Adobe’s AIR and others are making it easier for web-based software to run disconnected, which is going to ultimately eliminate this particular objection together with the increasing ubiquity of connections. SaaS vendors need to address this by jumping on the bandwagon and providing disconnected functionality using platforms like AIR.
RE possession of data. A good SaaS vendor lets you take possession of your data back for your own peace of mind. No objections there. OTOH, my experience is that the SaaS vendor is much more likely to have implemented the kind of robust infrastructure that’s needed to handle multiple site backups, failover, and all the rest. The reason is that they can defer the costs for all that across multiple customers. This is once again particularly true for the smaller businesses that often have only very embryonic capabilities in this area because their budget and IT staff are very small.
RE being more tied to a vendor. I don’t see that argument at all. Where Enterprise Software (or any other) is concerned, the idea that you can just keep running the software and ignore your vendor is head-in-the-sand thinking. Take a look at my recent experiences between two different versions of Microsoft Outlook (http://smoothspan.wordpress.com/2007/08/29/luddites-need-saas-too-or-dont-get-stuck-on-the-far-side-of-the-chasm/). Wow, was that ever painful, and it would have been totally avoided in the SaaS scenario! As I’ve pointed out in this post, the SaaS vendor has hugely more at stake than the On-premises vendor, and hence they have to work harder on your behalf. By their very nature, if you could deploy a SaaS app (i.e. get your data in and out of it and so forth), you have an app that has fairly low switching costs. If you don’t like your vendor, you can walk a heck of a lot easier than if you’ve made a far larger investment in On-premise.
RE leasing vs buying, it’s an interesting old chestnut that doesn’t wash. Look at the Total Cost of Ownership. The traditional vendor sells you a $1M software license. IBM or Sun together with Oracle, BEA, and whomever else then sell you $3M in hardware and ancillary platform software. Whoops, you just paid $4M, not $1M. Even assuming the cost to deploy in terms of Services is identical for the 2, and that the SaaS vendor charges you full license in the first year, you are still ahead with SaaS for 4 years because that’s how long it takes you to pay $4M. And, you get all the upgrades for free with SaaS and there is no additional maintenance charged.
My point in all of this is that there are nits to be picked with any model. The SaaS model just looks to me like a lot better deal when all the cards are on the table.
benkepes said
Excellent post (as always) th points you make, while made from the frame of reference of enterprise users, rings equally true (and arguably more) for individual users going down the personal SaaS route
Well done!
bunreasonable said
Hey Bob,
This whole debate is based on religion. Your religion being SaaS, others being i have to see the flashing lights to make sure the app is working. Either side can give working examples of the pro’s and con’s of their approach.
I think the approach around benchmarking is the way forward. SaaS is just another name for outsourcing and if you look at the global split about 30% totally outsource, 30% partial, 30% never and this split is usually based upon how burnt a particular CIO was in a previous outsourcing deal.
My thinking is in that in the SME / SMB space SaaS restore time is usually much better.. the total SLA being a much improved ratio…where a company has good inhouse resources its a coin toss.
What i would say tho is that every single day, a SaaS provider puts their reputation on the line with thier entire customer pool. They are only as good as their last fault, whereas on prem guys are only as good as a isolated incident… or a multitude of them (if you take Vista as an example)
smoothspan said
“SaaS is just another name for outsourcing”
Wow, on that I couldn’t disagree more! Outsourcing is a completely different animal in so many ways. Most often it involves yet another random variable in the form of a third party. SaaS ties the operation of the software to the same vendor that built the software. There are so many reasons (some of which I’ve outlined) why that provides a qualitatively and measurably better answer that I can’t imagine putting Outsourcing and SaaS into the same box at all if you really understand what’s at the heart of the two. OTOH, IT has already done so much outsourcing, that if they want to think that SaaS is just more of the same, I guess I can say whatever gets them to try it is a good thing.
Not sure what you’re saying with the remark that the SaaS provider’s reputation is a function of the entire customer pool whereas On-premises is a matter of isolated incidents. I can give counter example for both. A bug or problem can affect every one, or it can affect just a few or even one depending on the exact nature of the bug and how the platform delivers. I will say that SaaS vendors have a risk if their architecture forces them to deliver “all or nothing”, something I’ll talk about more shortly in conjunction with the flurry of problems PayPal is having.
bunreasonable said
Sorry Bob, i think you are wrong here mate
SaaS is a form of outsourcing. IDC would define it as discrete outsouring (as opposed to whole of business)
Wikipedia Definition “Outsourcing became part of the business lexicon during the 1980s and refers to the delegation of non-core operations from internal production to an external entity specializing in the management of that operation. Outsourcing is utilizing experts from outside the entity to perform specific tasks that the entity once perform itself.”
That last bit sounds a whole lot like what you said above.
Quite apart from that, ask your customers. To them they are outsoucring
smoothspan said
Once upon a time, large businesses built their own digital communication networks, worldwide and entirely under their control. Along came the Internet, and most businesses gave up the practice. Something similar happened when cell phones took over for 2-way radio dispatch networks that were once used. Does that mean they outsourced to the Internet or cell phone providers? Apparently so, based on the definition, but practically speaking, nobody thought about it that way. Why? Because this new “outsourced” medium so changed the original task that it went way beyond “tasks that the entity once performed itself.” New services and opportunities were created that were not even possible for the entity to perform itself. So it is with simple outsourcing and SaaS. Combining the service provider and the vendor under one roof together with seamless delivery over the Internet of Software as a Service results in an experience that can’t be had any other way.
Customers I’ve talked to that use SaaS see that it’s qualitatively different than just simple outsourcing. Customers that don’t want to try SaaS for whatever reason are the ones who want to lump it in as simple outsourcing. But if that’s really all it is, there is tremendous sound and fury as well as many measurable results in favor of SaaS that we just haven’t seen for outsourcing.
The danger in continuing to think about SaaS as nothing more than outsourcing is that it will lead you to miss a lot of essential points. The over generalization doesn’t bring you any corresponding better insights. That’s my problem with just saying, “Ho, hum, it’s outsourcing, let’s move on, nothing happening here.” That’s why people like Phil Wainewright (http://blogs.zdnet.com/SAAS/?p=372) get incensed when others want to simplify SaaS to the point the real meaning gets lost.
As Mies van der Rohe put it, “God is in the details.”
bunreasonable said
Thats an interesting take,
I’m trying really hard to not belittle the value of SaaS. A statement i’ve made and feverently believe is that SaaS is finally delivering on the promise of IT , you know the stuff that gets bandied around like productivity, competitive advantage, cost savings.
What I am trying to do is take a smb customer take on this stuff (hence my post on SaaS being hype http://unreasonablemen.net/index.php?option=com_content&task=view&id=68&Itemid=42)
I read Phil’s post and i find myself agreeing, but i think i’m coming from a different angle.