Smash and Grab Semantics: Cloud vs. Hosted
September 27, 2010
What is “cloud” computing, and how does it differ from “hosted?” The question emerged once again recently among the Enterprise Irregulars, as one Irregular used the terms interchangeably and another objected. Neither, however, wanted to get into semantics (that is, what the words “cloud” and “hosted” actually mean), so they agreed that the problem is knotty and went on with their lives.
These are both sensible, intelligent people who make sane decisions. But I want to point out that something has happened to both of them. Both of them, I think, have become victims of what I’ll call “smash and grab semantics,” a practice where companies will take a term that they find attractive and use it to describe something that they do. In some cases, this is pretty legitimate–I think both Salesforce and Amazon can use the word, “cloud,” without arguing about it too much–but in the case of “smash and grab semantics,” there’s a real distortion; something of value has been taken when they do it.
In other contexts, we regard smash and grab semantics as pretty reprehensible, because something quite real is at stake. I was talking last night to the editor of a newspaper in a country that calls itself “democratic,” but isn’t. He goes to court regularly and regularly ends up in jail, though not usually for too long. The last time he was hauled into court, the judge began the proceedings by asking, “Do you stand behind the lies that you just published?” As far as he’s concerned, when a regime practices smash and grab semantics on the word, “democratic,” it helps this regime get away with putting him in jail. And he should know.
So, is there a distortion in the use of the term, “cloud” vs. the term, “hosted?” And does this distortion give the people who’ve grabbed the term something they shouldn’t have? I think so. The plain fact is that cloud is a lot cheaper than hosted, a lot cheaper, because cloud applications or services have been engineered to share resources efficiently, something that hosted applications or services can’t do, because they’ve had to be rewritten from the ground up.
So when people offer something hosted and make their customers think it’s cloud, they’re giving people the idea that they’ve done the homework and were providing the advantages of efficient resource sharing when they haven’t in fact.
The details matter, of course, which is why my two very smart colleagues didn’t want to get into a complicated argument. With hosted applications there is always some resource sharing, by definition. But the plain fact is that whatever the details, something that’s engineered to be cloud is roughly ten times cheaper than hosted. So whatever the details, people who call themselves “cloud,” are doing a bit of smash and grab.
So how do you combat smash and grab semantics? Fortunately, the answer to this question has been known for a 100 years. You don’t let them get away with it. Despite the fact that they want you to use the term they’re using, you don’t go along. George Orwell put it better than anyone in “Politics and the English Language.” I am paraphrasing. If you want “language [to be] an instrument for expressing, and not just concealing or preventing though,” you must “choose…the phrases that best cover the meaning.”
Don’t get me wrong. If somebody says their offering is “cloud” or “SaaS” or “on-demand” when it is actually hosted, this is smash and grab, but only on a small scale. It is not the same as using the word “democracy” to describe a tyranny. One is good, aggressive marketing; the other is morally confused. But since the technique used–smash and grab semantics–is the same, you combat both in the same way You use the right word.
The Value of Cloud Computing
June 7, 2010
A client asked me whether I had anything in the files that laid out “the value proposition of cloud computing.” I don’t, and I don’t know of another good treatment. (Please, commenters, refer me.) But I thought I’d provide an answer here. It’s provisional, but I’m hoping that the comments will help improve it.
Before I begin, a few notes. First, as I noted in “Silver and Tinsel” the term “cloud computing” is heavily contested.If you are confused by all the silly claims, Ray Wang does a good job disentangling the terms. In what follows, I am ONLY talking about rue multi-tenant cloud applications, not hosted or single-tenant applications.
Second, in what follows, I’m only talking applications (SaaS). The value proposition for infrastructure (IaaS) or platforms (PaaS) is somewhat different. Third and last, I am assuming that multi-tenant application vendors are exploiting the advantages I’ll describe. In making this assumption, I’m clearly oversimplifying; many vendors simply don’t exploit the technological oopportunities as effectively as they could.
That said, here are the advantages of cloud computing:
I. Cloud computing is much cheaper.
The cost per unit of application functionality delivered by a SaaS company to the user is, in principle, much less than the cost of the same functionality delivered from your own premises, because the SaaS company shares the cost of expensive resources among all its customers and because the costs of distribution and remote support drop to zero.
What resources are shared? Database. Application server(s). Disk memory. RAM. Backup. Load management. Bandwidth. Provisioning. Patching/Patch testing. Security. Utilities. Personnel. All of these provide major economies of scale. What costs disappear? The cost of testing on multiple machines/OS’s/DBs. The cost of preparing and sending out disks or downloads. The cost of getting access to and understanding the configuration of a remote site.
Now, within the world of cloud applications, the problem of sharing all these resources efficiently is not an easy one to solve. There are several different “standard” approaches, each involving tradeoffs. Nevertheless, it’s safe to say that the more resources shared, the cheaper the cloud computing application. So if you want to figure out whether the cloud computing application you’re thinking about buying is any good, ask them for details about how they share those resources.
Now, very few of us really have a good intuitive feel for how much saving is involved. Your knee-jerk reaction might be that your data center costs roughly the same amount as a SaaS company’s data center. And if you know that your own data center is a little expensive, maybe you think that some partial solution, like hosting the application somewhere else, is roughly as good.
So, when Oracle tells you that their cloud application is hosted in their datacenter, so that you share data center management costs with other customers, that sounds good to most of us. And if Lawson tells you that they’re running on Amazon, so you’re sharing data center and app server and disk costs with other Amazon customers, that sounds good, too.. And if some smaller vendor tells you that you’re running on a virtual machine in a rented data center like Rackspace, that sounds good. It turns out, though, that none of these common, single-tenant “cloud” solutions really get anywhere near close to achieving the cost savings that are available. The only way you can get those cost savings is if the application itself is “multi-tenant,” which means that the application has been written in a way that allows it to manage the resource sharing.
How much of a difference does multi-tenant make? It’s astonishing, but the answer appears to be that multi-tenant is ten times cheaper than a single-tenant solution in a shared data center. (See “Silver and Tinsel” for more on this.)
And what does that say about taking delivery of a solution. Obviously, it depends. But the experience so far says you should think of it this way. Choice 1. Multi-tenant solution taking advantage of shared data center resources, shared computing resources, lower distribution costs, and lower management costs. Choice 2. You take on all the costs of the data center, computing, distribution (to you), and management, sharing those costs among all the applications at your company. You know that companies that do hosted or single-tenant cost 10 times more than multi-tenant. Do you really think that Choice 2 is comparable in cost to Choice 1?
II. Cloud Applications Are Easy to Consume
Cloud applications are generally much easier to set up, try out, get access to, buy, and use than on-premise applications are, for a very simple reason. Cloud applications are designed to be delivered with as little intermediation as possible to the end user. On-premise applications are designed to be intermediated by IT. They are built and sold under the assumption that IT will approve the purchase, take delivery, find all the computing resources, install the software, set up the users, arrange for training, fix problems (if any), ask for improvements, etc., etc.
To some extent, this is an artifact of the first value. The SaaS company is taking over the job of delivery to the user from your IT department, and they’re getting a lot of leverage because they’re delivering it to lots of users, not just the users at your company. Not unnaturally, they can do automatically what your IT department has to do manually. With that automation come a lot of savings in cost for them and a lot of improvement in the user experience for you.
III. Cloud Applications Are Up-To-Date
According to the many really knowledgeable people who have tried the real edge that the cloud application vendors have lies in the speed and effectiveness of their development.
A cloud application vendor can develop more efficiently than a vendor that delivers on-premise, because they’re only developing for one installation. They can develop faster, because they don’t have to build up a massive “release.” They can deliver much, much, much faster. They can fix problems much more easily, because they’re basically fixing once and they can do analysis on the same system that they’re delivering. They can respond to customer requests more easily, partly because of the aforementioned, but also because they can actually look at how customers are using the application.
Cloud application vendors often tell customers, “No more upgrades,” and wonder that this statement fails to thrill. (It is thrilling, but only to the poor gents in IT who have lost too much of their lives in 72-hour stints over some Labor Day or Christmas.) They should be saying, “Look, we’re keeping up.” New devices? We’re on it. New interface techniques? Done. New requirements? Months, not years.
In my view, even the most modern of modern on-premise applications is roughly 5 years behind what a modern consumer experiences every day, and most applications used today are 10-15 years behind. With a cloud application, you have a chance of staying within reach of the latest innovations. With an on-premise application, you simply don’t.
IV. Cloud Applications Can’t Be Customized
Wait a minute? Wasn’t that supposed to be a disadvantage of cloud applications. Sorry, it’s an advantage. A big one.
The problem with customization is simple. It costs too much. Unfortunately, the way modern corporations and IT organizations are structured, most of the costs are hidden. IT organizations are service organizations, and they’re rewarded for providing service, so they simply defer the astronomical costs of managing, maintaining, and upgrading around the customizations because they look bad. They’re in the position of a butler at a billionaire’s house who is asked for fresh raspberries in February and, rather than disappoint, simply charters a jet from Chile and accepts the complaints when the billionaire finds they’re not fresh enough.
So when a SaaS company says, “No,” to its customers, they’re providing the same kind of benefit that I am when I tell my daughter, “No sugar.” They’re helping the customers to do something that they shouldn’t do anyway.
This doesn’t mean and shouldn’t mean that the SaaS company doesn’t allow any changes whatsoever to the way the product is used or doesn’t allow customers to do things with the data that they hadn’t envisioned. But typically, anything that the customer should want can be provided either by changing configuration settings or by moving the work (far more cheaply) to some external system.
If you find a SaaS system where you MUST have a customization (or an integration, the same logic applies) or it will be literally impossible for you to use the system, don’t buy it. Period. The fit is wrong for you, and it will never be right. This, too, is a huge value, both for the SaaS company and the customer. They have fewer customers who should never have bought in the first place, customers that are excessively expensive to support and often likely to sue.
Choice and Control
What is the cost of all this value that’s suddenly being delivered? To SaaS naysayers, the cost is choice and control. “We let the customer choose between on-premise and on-demand.” “We let the customer run on his own machine, which he controls.” “We let the customer run the application the way he wants.” (I use the word “he” advisedly.) Those silly SaaS companies force you to do things their way.
Well, if you ever, ever hear the CEO of an on-demand company say, “What we offer is choice,” run, do not walk, in the other direction. Because what he is not telling you is the cost of that choice. Modern enterprise applications are highly tuned, finely designed, very complex machines–think Ferrari, if you want–and for such machines, the kind of choice offered to customers is pretty much akin to offering Ferrari customers a choice of rear axles or of steering systems. Giving you that choice costs you a lot, costs them a lot, and is completely pointless.
The same thing applies to when an IT person says, “We need to have the control” or “We really can’t afford the security problems.” Unless you ask what the cost of that control is or the cost of that [non-]security, and get very accurate answers, you have no idea what a bill of goods you’re being sold.
About three years ago, I was a judge in a software contest, and all the entrants were SaaS vendors. They had figured out already what my client was asking me last week: the value proposition of a SaaS (multi-tenant) is so overwhelming that there’s simply no point in building an application for on-premise delivery.
Multi-Tenant, Silver: On-Demand/Hosted, Tinsel
May 7, 2010
I have been watching the earnest attempts with which Ray Wang is trying to “define” the flavors of cloud computing and Phil Wainewright is trying to describe its “unspoken benefits” and James Governor’s simplifications of cloud concepts, and all those efforts make me want to use words that you shouldn’t use on the Internet.
Why? Well, they’re a bit too high-minded and value-free.
Let me explain the problem with the use of an example. Imagine you were a high-minded dictionary writer who was trying to stand above the fray, so you defined “good,” as a ‘set of behaviors and attributes approved of by some,” and “bad” as “a set of behaviors and attributes not approved of by people who approve of the good.” There may be some sad, sorry truth to these definitions. But far from being even-handed or fair-minded, they’re simply serving the interests of the bad guys, who get to turn bad and good into a popularity contest.
Similarly, if you define hosted or SaaS or whatever as if all of these were legitimate choices which you, the high-minded definer are not going to evaluate, you serve….well, all the guys who want to foist a bad choice on you while pretending that it has all the virtues of a good choice.
You can see this most clearly if you look at the history. Ever since people (Marc, you know who you are) started using the term SaaS, applications that are shared and leased have been what the academics call “a site for contested definition.” As soon as the term SaaS was bruited about by some people, other people would say, “Oh, well that’s just a silly new term for ‘hosted,’ and ‘hosted’ is a great thing and it’s what we’ve always done. If you’d like to lease our software, go ahead.” (Larry, you know who you are.) The same things have happened to “on-demand” and “cloud” and all the other terms that the eminent and high-minded analysts are trying to explain.
This contest is exactly why there is the confusion in the market, a confusion that Ray rightly decries. The terms are confused and confusing because people are trying to appropriate them.
They’ve tried to appropriate them for a perfectly obvious, simple reason. They’d like to get the credit and money associated with doing something difficult, but very good, without all the trouble and bother of doing that difficult and good thing. But as a definer (or as an entrant in the marketplace), you will never, repeat never figure out what they’re trying to do if you don’t look squarely at why the difficult design choice really is difficult and what the payoff for that design choice really is.
If you try to define “good,” that is, without deploying some notion of worth, you’ll end up with no practical difference between the two and a whole lot of bad people trying to use your definition to show that they’re really good.
Maybe in one of those hoity-toity academic environments like the one across the street from me, it’s OK to publish even-handed appraisals and fine, nuanced distinctions that clearly lay out all the issues for those five other people who are interested in publishing themselves on the subject. But in the real world, where some people who haven’t done their homework are trying to appropriate the hard work of people who have done their homework, it’s not OK.
That said, let me tell you the real scoop on “cloud,” “multi-tenant,” etc., etc., etc. True SaaS, true multi-tenant, true cloud applications are shiny like silver. Hosted, on-demand, and private cloud are shiny like tinsel. For any purposes that aren’t temporary and don’t have pretense built in, silver is better. Multi-tenant applications have more functionality. They’re more adaptable. They are easier to operate for the vendor. They are cheaper. They are easier to manage. They are more competitive and more likely to last. Unless you’re throwing a party and are planning to take down the decorations the next day while suffering from a hangover, they are better.
Why is true multi-tenant better? It’s very simple. They’re more efficient. More of any dollar spent on a multi-tenant application goes into value delivered to the customer. A programming dollar spent on a multi-tenant application is immediately delivered out to all the users of the product, and, it’s put there to make the product more useful. To get the same effect in an on-premise application, it takes a lot more money. The same dollar for the programming (actually a little more), another dollar (say) for the testing, packaging, and delivery, another dollar (say) to test it at the other end, and another dollar (say) to get users to make it effective. Let me be generous and include the cost of delay in the delivery of value in those last two dollars. I think the cost is really more. But of course, there are no reliable published figures. Analysts, where are you?
Aghast? Don’t believe me? Well, let me use an example where there are published figures. A couple of years ago, a senior executive at a major application company gave some lectures at local universities where he claimed that single-tenant (hosted or on-demand) applications cost 10 times more to run than multi-tenant. Let’s say he’s right. The benchmark in this area is the (highish) per-user cost of a major SaaS provider, which is about $3.50/month (not published, but widely known). His company, at the time, offered a single-tenant application that it leased out for a hundred and change each month. Let’s assume that the major SaaS provider was a direct competitor and was charging the same. Are these companies really offering the market good alternatives, both of which need to be respected. Remember, one is putting $31.50/month/user (roughly 1/4 of your subscription) into paying for extra servers, extra electricity, extra licenses for virtual machines, extra complexity in their provisioning systems, extra management of load balancing, etc., etc., etc., all of which (from your point of view) add exactly zero value?
Imagine you’re buying one of these two choices. One vendor has made a bad, inefficient, and expensive design choice in the way it delivers the software. The other vendor has made a good, efficient, and inexpensive design choice. Which should you buy? Wouldn’t you feel really annoyed at any analyst who said, evenhandedly, that there’s much both good and bad to be said about both choices?
“But…but…but…” I hear you saying, “I just read Ray, and Ray says that you can customize single-instance products, whereas you can’t customize multi-tenant apps, and you can have more confidence that your installation is secure if it’s not sharing resources with some other application.”
Ray is perfectly right in his facts and perfectly wrong in his emphasis. What he isn’t saying is that in this context, customization and security are impossibly expensive, ridiculous luxuries, the moral equivalent of the rear-view mirrors in the Rolls-Royce that used hand-blown glass. Imagine the following conversation with your CFO. to see what I mean. “To get customization and security, we have to pay ten times as much for the software to be delivered by a company whose gross margins are 1/10 of industry best practice? Excuse me? We’re paying for a limousine when everybody else is paying for a bicycle messenger? Hello. Do we really need customization? Is the security really all that much better?” To which, the only rational answers are “No” and “No.”
The real question in this era of contested definitions is not what the definitions are, but how we can tell when we’re getting the real goods. This is a very, very difficult question, not at all easily answerable through the use of a single label. “Multi-tenancy”–essentially sharing computing resources among users of applications in a way that valorizes efficiency and accessibility–is a difficult and complex engineering problem involving numerous, complex tradeoffs. There is good multi-tenancy and bad multi-tenancy, and bad multi-tenancy can be so bad that it is virtually indistinguishable from single-tenancy. (That’s why, Naomi, I sometimes only give two cheers to your own really laudable insistence on multi-tenancy from HR vendors; it isn’t just multi-tenancy, but how you do multi-tenancy.)
Over the years, we’ve seen many attempts to isolate the truly distinguishing feature of multi-tenancy: that it runs on a single database or a single machine, that everyone gets upgraded at the same time, etc., etc. It’s just as silly and fruitless to do this as to find the single, isolating characteristic of “chair.” (Four legs? No, there can be chairs with any number of legs or none. People sit on it? People sit on lots of things besides chairs.) The only real way you can tell is to look at the engineering.
Not surprisingly, many vendors, even ones claiming to be “true multi-tenant,” don’t pass muster. A month or so ago, my old colleague, Brian Sommer spent a good deal of time calling around to companies that claimed to be multi-tenant. “You would be astonished, ASTONISHED,” he told me in his inimitable way, “at how few there actually were.”
If we hadn’t wasted time wrangling about definitions and propounding definitions that simply missed the real point, maybe a healthy discussion of the engineering issues surrounding multi-tenancy would have grown up by now. The plain fact is that the way Salesforce.com does it is really different from the way NetSuite does it, each company making quite different tradeoffs and pushing quite different levers. But today, whenever you get one of these obligatory “due diligence” site visits from companies fearfully dipping their toe into the cloud waters, the only “engineering” questions anybody asks have to do with SAS-70 Type II.
The Elephants and the Rabbits (Accounting at SaaS Companies)
August 19, 2009
Brian Sommer just posted a very funny piece on how SaaS CEOs can prepare for an earnings call. If anything, he understates the problem.
We have learned over the years how to respond to software company earnings calls. We look at license revenues; we look at revenues; we look at margin; and we decide whether the company is doing what it “should” do at its level of maturity.
What few people realize is that the rules governing SaaS vendors are different, so comparing SaaS vendors and perpetual license vendors is like comparing–oh, let’s try to avoid a cliche–elephants and rabbits.
This gives these guys so much opportunity to obfuscate that frankly, they don’t even need to practice.
To understand how this works, you need to understand the differences between the rules. I’ll stick with the basics. The key difference is that when a perpetual license vendor sells something on the last day of the month, they report the total amount of the contract as revenue; when a SaaS vendor sells the same software, they don’t.
With the perpetual license vendor, the idea of the accounting powers that be is that selling a software license is like selling a piece of packaged software over the counter. You sign the contract; they invoice; ka-ching. With the SaaS vendor, the idea is that they’re not selling an over-the-counter product, they’re selling a promise to deliver a service. And, since there’s always a risk that they won’t deliver, they can’t recognize revenue until they actually do that delivery.
Let’s see how this works in an example. What we’re trying to do is evaluate how sales are going. With a perpetual license vendor, at the end of the quarter, we can look at their reports and be able to tell, basically, what they sold, and how sales are going. If SAP sells a $1 million contract on June 30 (and ship and invoice), they report $1 million in license revenue, and we know that’s what the sales force did.
Now imagine that a SaaS vendor is working equally effectively. At the end of a quarter, they sign a $1 million contract that is effectively equivalent in the customer’s eyes. (Who knows, maybe SAP and Salesforce were competing and Salesforce won.) If we look at their revenues, we’ll have no idea that this is the case. Almost none of that $1 million will appear as revenue, because they are only allowed to report revenue for the days of SaaS that were actually delivered. For that $1 million contract signed on the last day of the quarter, SAP will report $1 million in license revenue, but Salesforce will only report $1,000, assuming they turned the product on that day and so delivered one day of a 1,000-day (3-year) contract.
This makes Salesforce look bad. But later on, things reverse. Imagine there’s a quarter when both SAP and Salesforce reps sell bupkes in a quarter. That quarter SAP reports $0 license revenue, but Salesforce reports the $90,000 that it earned from the 90 days of delivery on that old contract.
Two companies. Identical performance. Completely different-looking results. Now, we’re not completely trapped. We can get some idea of what’s going on, by looking at what are called the “bookings” numbers. (The booking is the amount of money invoiced during the quarter for the contracts that are signed.) Most financial analysts just use a quick and dirty rule of thumb for comparison purposes; bookings for SaaS companies are roughly equivalent to sales revenues for perpetual license companies.
if SaaS companies booked revenues the same way that perpetual license companies bill for revenues, this would be fine. But in fact, SaaS companies don’t necessarily book all the revenue from contracts like that $1 million contract that I’m using as an example. Very often, they don’t invoice for the product until it actually starts being used. So on that last day of the month, it’s reasonably likely that the bookings will be, say, $299,000 and the revenues $1,000 for that contract. But the rest of that $1 million won’t appear anywhere. It will be booked in the fullness of time, but by that time, we won’t really care.
So how do you compare the elephants and the rabbits? You don’t. To compare the two, you would have to know the value of the contracts that the SaaS companies signed And they have no responsibility whatsoever to tell you what that value is. In fact, they can say anything they want to about that imaginary $1 million contract; they can announce it, hide it, whatever. If this quarter, they want you to believe that they’re selling as much as SAP is, well, they can release figures that make it seem that way. And if this quarter, they want you to believe something else, well, OK. All perfectly legal. In our example, Salesforce and SAP are “actually” doing equally well. But there is no way of knowing this.
Oh, it gets worse. It turns out that the accounting standards that govern SaaS companies make margins worse than they “actually” are. So even if you did get data that let you compare sales accurately, the accounting standards would automatically make the SaaS company look less profitable than the on-premise company.
Awful, right? Not even close. You see, very soon, it’s going to get even worse. The accounting standards are changing. But hey, that’s material for another blog.
Chiseling On-Demand
June 15, 2009
You know the old joke, “How can you tell whether a software salesperson is lying?”
What about when it’s a “No-software salesperson?”
The question came up the other day when one of the people in the office went off to Intuit’s road show for its on-demand database. (Intuit is putting Quickbase on line, promoting it as the cloud’s answer to Access, and the road show was for people who might develop on it, using a Flex-based front end.)
This person came back less than wowed, of course; what do you expect, it’s Intuit. But the quality of the product seemed to me to be beside the point. No matter how good or bad it is, I argued, you would have to be absolutely cracked to have anything to do with it.
Why? Because the way Intuit behaves itself in the on-premise world makes them a non-starter in the on-demand world.
Believe me, I know whereof I speak. I am a heavy user of Intuit products: TurboTax for 10 years or so, QuickBooks for four, Quicken, now, for two. I have thus had more exposure than I would ever, ever like to have to Intuit’s chiseling ways: the design that plumps unerringly for the cheap and stupid way of doing things, the support that has at times left me screaming at the telephone, the innumerable ways they have made my life harder because they only want to deliver the absolute minimum, the endlessly inventive efforts to extract an extra $5.00 or $20.00 from me.
I use the products, despite all this. But only because, over the years, I have figured out how to keep the chiseling costs down to what I think is an acceptable minimum.
Mind you, sometimes they nail me, even so. This year, it happened twice. This year, for instance, they decided de-support QuickBooks 2006 Professional Edition. “Desupport, I thought? I don’t get any support from them anyway.” Turns out, of course, it was a way to get me to plunk down another $300 for the latest edition. Didn’t work; I finally figured out that there was no reason to pay another $300 for software that I already owned. But it did cost me more than a few hours to figure that out. And it burned me when I figured out that what they were doing, in order to make me want to upgrade, was taking away their QuickBooks e-mail invoicing service. $100/year to send out invoices? Give me a break.
But they weren’t through with me of course. This year, I saw the most inventive piece of chicanery I’ve seen in a long, long line. Instead of sending me a check for the TurboTax rebate, they sent me a debit card with a $10 credit. This turned out to be much more fiendish than you might think. First of all, even though it says debit card on the card, it’s actually a credit card, so if you say, “Debit,” to the cashier, it’s refused, something I find embarrassing. Second of all, even after you get on to that dodge, it’s a lot of work just to use it. Either you have to come up with an item that costs exactly $10, or you have to split the bill between two credit cards–also embarrassing. So what did I do? I finally bought a $7 item, and I guess I’m going to let them have the remaining $3.
So what does this have to do with cloud computing? Well, let’s put it simply. If you have enterprise application software, and you’ve bought a perpetual license, you have a defense against at least some of the chicanery and chiseling that seems to be built into relationships with software vendors. You can stop dealing with them and still use the software. But with a cloud computing vendor, you don’t have that defense. So you’re much, much more vulnerable.
My supplier of enterprise application software happens to be Intuit, and with Intuit, I simply don’t allow myself to become that vulnerable. I never use the Intuit Quickbase product or the On-Demand version of Quicken or QuickBooks; I don’t even use the on-demand TurboTax backups. Why? I have been victimized by Intuit’s sharp practices many times, and I don’t want to give them an even bigger and more vulnerable target.
Now I don’t blame Intuit. They invented a business model that really worked for them and apparently works for millions of customers–a kind of RyanAir for software, where you provide the maximum amount of irritation and inconvenience possible in return for a rock-bottom price. But this is not a business model, I think, that consumers should accept when it comes to cloud-based applications. There’s just too much risk that a Ryan Air-like application company will ask you in mid-flight to chip in a little bit more so they can get you back down on the ground.
If it were just Intuit, of course, I wouldn’t burden you with my ranting. But it seems to me that Intuit is not the only company that came of age in an era when you delivered software to the premises and discovered that you can make a fair amount of money in that context by overpromising, underdelivering, and making sure that you have your customer’s wallet firmly in your gunsights at every moment. I hate to say it, but there are much bigger companies that deliver much bigger accounting software that have the same mind-set. So if it’s unwise for consumers to trust Intuit’s approach to business when it comes to cloud applications, isn’t it unwise for consumers to trust the other guys?
Now wait a minute, Leo or Larry might say, aren’t you tarring perfectly reputable, upright, leading companies with a brush that should be reserved for Intuit? Well, I dunno. I don’t own your software. You tell me, L&L. I know that Intuit has provided me with support that was completely inadequate and left me genuinely vulnerable as a result; has your enterprise software company done that? I know that Intuit has misled me about what’s in upgrades or in more expensive editions and cost me a lot of time and money as a result; has your enterprise software company done that? I know that Intuit has tried to charge me for things that I thought were included in the original deal and has raised rates on me without providing anything to me in return; has your enterprise application done that? And I know that Intuit designs software in a way that shifts a lot of costs onto me, even though it would often be very simple for them to avoid doing this. Does your enterprise application company do that?
If the answer is, “Yes,” to any of those questions, what’s going to stop you from doing this to your customer again, when your customer buys your cloud-based apps?
Maybe there’s an answer. But until there is one, my recommendation for customers of companies that do this would be to avoid their cloud-based applications for the same reason I would run, not walk away from Intuit’s.
So how do you know if your No-software salesman is lying? Well, I guess you don’t. But if he used to work as a software salesman, shouldn’t you at least check what he says?
Cloud Confusing
June 5, 2009
This is one of what I hope is a long series of posts on what’s wrong with cloud computing. (The more cloud computing grows, the more things there will be wrong with it.)
OK, so this morning I get an e-mail from Xactly, a sales compensation software company closely allied with Salesforce. It’s a hosted, oops, cloud application, a fixture on the AppExchange, which at least theoretically lets salespeople who use Salesforce figure out what their compensation is going to be if they ever get one of those sales.
Steve Cakebread, part owner of Cakebread Cellars and, oh yes, for many years CFO at Salesforce is giving a seminar on how to sell to the CFO. The seminar is sponsored by Xactly of which, not coincidentally, Cakebread is now the CFO.
The wine is quite good. I’ve had it at many of those lavish events for analysts that Salesforce used to sponsor back in the days now gone. But of course it was before noon when I got this e-mail, so I didn’t think too much about the wine.
So I signed up, or tried to. You see, while Xactly may be on the AppExchange, they don’t use Force.com as a platform, they have their own product which is hosted by OpSource, another long-time Salesforce partner and AppExchange stalwart that has a particular appeal to AppExchange partners because they help people through the process of joining the AppExchange.
The e-mail comes from Xactly, but actually Xactly is using the events software from OpSource, so when you register, you register at a site with an OpSource URL.
So when you get to the registration site, you can see labels, like Name, E-mail, etc., but you can’t actually see any fields to put your name in. This is probably due to the fact that OpSource (or whoever wrote this registration page) actually doesn’t believe in providing products that work correctly on Firefox, another cloud computing provider.
Where is that wine?
To register, I have to find the fields by hitting the Submit button, which gives me an error message, saying I haven’t filled out a field, and then I can kind of guess where to put the cursor, and at the end, my name is David Dobrin Dobrin, because I put David Dobrin in what I thought was the Name field, but was actually the First Name field and then had to poke my way around until I could find the Last Name field and put my last name in again.
Is it noon, yet?
So I’m registered, yay, but I can’t actually remember when it is, so there’s a little button that says, “If you’d like to sign up with Adobe Connect, you’ll get an e-mail with an item for your Outlook calendar.” I cringe a little because Outlook calendar items don’t integrate very well with the Mail app from Apple, but OK. So I hit the button. I am now hooked up with Adobe Connect (although it’s still an OpSource URL), and again, I am asked for my registration information. So do I have to register again or not? You tell me. I don’t know.
Except that there’s another button that says, “If you’ve already registered with us, click here.” Now who is “Us?” OpSource? Adobe Connect? Xactly? Salesforce? Cakebread Cellars? I’m assuming “us” means “the seminar you just signed up for, dummy,” so I click the button. Up come a username and password field. For whom? OpSource? Adobe? Crud, I wonder if my old username and password for that meeting software that Adobe bought years ago still works. What was it? I can’t remember.
Guys. Give me a break. If I want to sign up for your seminar, I don’t want to have to establish/remember relationships with three other cloud computing companies. The only other company I even want to know about is Cakebread Cellars. If you don’t actually believe in, want to participate in, or know anything about universal identifiers as a necessary lubricant in the cloud, then at least have the good taste not to inflict all your relationships on me.
In cloud computing, you always do a lot of function shifting onto your partners. But if that simply becomes cost-shifting onto your customer, you and cloud computing have failed.
And when that happens, I have a ready alternative. Instead of dealing with Cakebread CFO, I deal with Cakebread Cellars. Have some wine.
Let’s say you go off maintenance. (I know, I know, it’s unthinkable. But there’s no harm in a little noodling, is there?)
So you go off maintenance. What consequences does that have for your application strategy?
Don’t tell me you don’t need one any more. You still need a strategy. True, you’re letting your primary back-office application lie dormant. Unfortunately, though, even today your current application doesn’t work perfectly. And, as time marches on, your business will change, your work will change, new kinds of work will come in–and you’ll need to deal with it.
I don’t know of any analyst who has actually addressed this issue. So there isn’t a canon of accepted practice. You’re kind of on your own.
But I think there are some principles you can follow, so let me suggest them. It might help. Broadly speaking, they are as follows:
* Don’t go backwards
* Embrace heterogeneity
Going backwards is dropping back to an era when IT tasks or business tasks were done on isolated, often custom-built applications. If you need new functionality, and you’re not going to get it from your now moribund application, the obvious thing to do is build it yourself, just as you used to do.
Don’t. The reason we bought commercial applications was that doing it yourself cost too much. The cost of maintenance for the home-grown stuff and the unsatisfactory performance of what you got, often due to limitations on access, outweighed the benefits of having a bespoke application. If you ignore this lesson, you’ll repeat the same mistake. If you learn from it, on the other hand…
And heterogeneity? Well, the other reason we embraced commercial applications was that heterogeneity was too expensive. Yes, you got a best-in-breed application, one that was well-suited to the business.But the cost of integration (and other maintenance costs) was simply too high. You were better off using the [Fill in blank] stuff that your platform vendor foisted on you.
So, shouldn’t you learn from this and go back to the platform vendor with your tail between your legs? Not necessarily. You see, the cost of best in breed has gone down a lot, and the difficulty of integration is less. What’s more, the delta between what best in breed does and what the platform vendors do remains very high. (i2 or Manugistics works much better than APO or Demantra in many cases.)
Bearing these principles in mind, how do you approach the problem of adding to or extending what you’ve got, when you can no longer ask the software vendor for help? Here are some suggestions.
1. Always ask yourself, “Why not the cloud?” If you’re thinking of buying a best-in-breed application, can it be a cloud-based application? If (horrors), you’re building something yourself, can you put it in the cloud? Why the cloud? Because a cloud-based application changes the economics, be it an application you build yourself or a new, best-in-breed application.
Take a simple, simple example to show you what I mean. Assume that you’ve gone off maintenance, and you want to establish a new discounting system for large customers, which involves basing the discount on the volume of orders, frequency of orders, credit history, and credit rating. Let’s assume that customization is unreasonable, partly because of the maintenance issue.
The temptation is to put the data on a spreadsheet, roll in the data once a week, have it do the calculation, and then and change the discount table. Fine. But wait a minute. Why not the cloud? Rather than putting it on a spreadsheet, which will be locked on somebody’s computer for the rest of time, why not put it on Google Apps?
It may not seem like it, but the costs of storage and maintenance for that mission-critical spreadsheet are significant. So are the costs of making the data easily accessible and securely available to all the people (and systems) involved. So are the costs of getting updates from public data sources out in the cloud. So are the costs of having the spreadsheet “belong” to one person.
Get rid of all those costs, in one swell foop, and make it easy to use other public data sources as you refine your discounting. Put it in the cloud.
2. Try to do less for your application customer. No, don’t recoil in horror. Ask yourself what the right strategy is going forward. With your old platform strategy, which you’re now abandoning, you always wrote for the ages. Be it a report, a custom app, or an app extension, you wanted it to be robust and highly satisfying to the user, doing everything that the user wants. But if you’re not building for the ages, you want to rethink this. There are many situations where quick and dirty is superior, where even the users would rather have something fast that works more or less. You’re in an age of limited resources; don’t go backwards to the time when you were expected to achieve perfection.
3. Tolerate application islands. The idea of your platform, remember, was that eventually everything would be on one system. Great idea. More work done by the platform would mean fewer systems to manage, more consistent data, better access, etc. Well, that idea is over with; why not look to make the best of the freedom this gives you. Lock down the mission-critical data and functions, sure. But aren’t there areas where people want to use best-in-breed apps, iPhone apps, social networking apps–am I scaring you, yet?–and really, at the end of the day, you’ll make their computing environment better if you let them? Remember, if you’re off maintenance, the new work still needs to get done. Why not be open to finding the best way of doing it?
I could go on, but hey, I know that I already write the longest blogs in the known universe. Comments (and more questions) are welcome. It’s a fruitful and interesting topic. It needs more discussion.
Problems with Cloud Services I: RIM and XO
April 13, 2009
Talk to the typical SaaS executive about the complexities of customer service in Cloudland, and they give you a blank stare. What’s the problem. We provide our service. We guarantee it. We do a better job than
Well, yes. But that’s not all. When you’re getting cloud services, the services are often coming from multiple providers. Each of them can think they’re doing a good job or the right job. But even so, delivery can fail. And when that happens, it’s a nightmare for the customer. A nightmare.
Here’s a simple example. I have a Blackberry Pearl. My web site and domain name are hosted by XO. Two SaaS providers. I get my Blackberry e-mail from XO, which forwards it to the Blackberry domain name (tmo.xxx.com).
All of a sudden, this weekend, I started lots and lots of new spam–you know, the usual, sex stuff, plus a lot of spam with a Facebook return address, etc., etc., stuff that had been filtered. The new spam appears on both my Blackberry and in the e-mail delivered directly to my POP3 Mail account on my Mac. But much more new spam appears on my Blackberry.
Obviously, something happened to one or more of the spam filters that are provided to me. I know of at least two of these filters: one at XO and one on my Mac. Is there another one at RIM? Who knows.
I’d like it to stop, but I don’t have the time to troubleshoot this problem. Did XO change its forwarding policy? Did RIM install a new filter and screw up? Who knows.
If I just had one provider, I’d have some chance of solving it. But when I have two, I just have to sit and wait. The worst of it is, it might be the case that neither provider will ever realize that there’s a problem.
I wonder if the iPhone has a spam filter on it?
The point? Well, cloud service providers need to start thinking about this–and taking responsibility for the actual delivery of services, not just for making those services available.
Four-Five Years
March 31, 2009
Within the tiny world of SaaS executives, there’s a little-known rule of thumb. I call it the Four-Five Years Rule. The rule is this. “When comparing the cost of SaaS offerings against an equivalent perpetual license offering, the break-even point comes in four-five years.” That is, when you add up the total cost of leasing a SaaS offering and the total cost of a perpetual license offering, the latter including hardware, the software license, and maintenance, and even the cost of money, the SaaS offering is cheaper for four years-plus; after five years, you’ve spent less on the perpetual license offering.
Did you know that? Bet you didn’t.
So is that an argument for SaaS, or is it an argument for perpetual license? After all, most installations last longer than 5 years. So maybe you should bite the bullet and pay up front, right?
No. You see, there’s a big, big difference between the two at the break-even point. With a perpetual license application, the application you’ll have is four-five years old. (You see, I’m not including the cost of upgrades.) But with a SaaS application, the application you’ll have is brand new and up-to-date.
It’s sort of an inversion of the old automobile lease-vs-buy conundrum. At the three-year breakeven point, if you buy you have a car, but if you lease, you have an empty parking space. With software, if you lease, your installation stays new. If you don’t, it gets old.
It’s also an inversion of the standard idea about SaaS, that it’s cheaper, but you get less. Not at all, after five years, it’s more expensive, but maybe worth it, because you’ve got a superior product, one that’s been kept up to date.
Not necessarily worth it, mind you. If you don’t need all the stuff they put in to keep the software new, or if you need to customize, you’re definitely better off with perpetual license. A lot of it depends on what you think the useful life of the old software will be.
One last argument for perpetual license, of course. If you do think the old software will have a long useful life, you can plan to save a boodle by going off maintenance sometime after those five years are out. If you do that, perpetual license can be way cheaper.
The Applicator 