March 30, 2011
Groupon at $6 billion, for what, coupons? Twitter at who knows how much more, for what, stray pulses of thought? CornerStone OnDemand at 10 times revenues? How much of that is for the words “OnDemand” cleverly tacked onto the name?
Are we in the middle of a cloud boom? And if so, can we learn anything from the last big boom, the dot-bomb?
Well, I remember the last boom pretty vividly–I was young and foolish back then–and I would like to offer, if not sage advice, a way of thinking about these companies that at least help you separate them.
I’m going to use as Exhibit A, a rather smurmfy story that was circulating a few weeks ago in the financial community. Marc Benioff calls up Dave Duffield at Workday and says, “How much?” Dave says, “$2 billion.” The person telling the story intends for you to be shocked, shocked, but just in case you missed the point, he closes the story with a snide comment: “$100 million in revenue, and they want $2 billion? Time to sell cloud stocks.”
Now, I don’t believe that this story actually happened, for two obvious reasons. Reason #1. Both people have the good sense to keep the story to themselves. Reason #2. Well, wait until you get to the end.
But first, let me tell you about Workday.
Workday is a SaaS (cloud) company that does full-suite (HR, Payroll, and now Talent), global HR on an object-oriented in-memory database. It is run by two of the smartest people in the business, and since they cared about HR, they recruited many of the best people from PeopleSoft, which at one time had the best HR and Financials package out there. I’m not a super HR geeko dweeb genius–you know who you are, Naomi–but I’ve seen the package many times, and I’ve talked to them often about what they’re trying to do, and as far as I’m concerned, they’ve got a better mousetrap. They do HR (for their target market) better than anybody else in their space.
Now, when Workday was being started, they decided early on that they would build a product for big, global companies. They had done this once before at PeopleSoft, as I said, so they understood the challenges. Privacy laws, getting the addresses right worldwide, languages, expats, payroll, you name it. Hard stuff (and, I might add, not done entirely successfully the first time around). This time, though, they figured that their cloud-based, object-oriented, in-memory technology would be way better able to do all this hard stuff than what they had the first time around, plus, as it turns out, it would be highly buzzword compliant.
Have they gotten there? Not yet. But so far, so good. They’ve recruited one global client, Flextronics, and installed the package worldwide. There are issues, there are complications. But they’ve got a pretty good proof point, and now, they’re trying to sell it to and install it in other large, global companies who happen to want better mousetraps in HR.
So what do you think? Is this one-third as good as Groupon? One-fifth? As good? Or, as the smurmfer seems to suggest, 1/20th of what Groupon is worth, max.
Well, let me suggest a way of looking at this question. And please, the usual disclaimers. I don’t own any Workday stock, don’t have any economic relationship with them, and paid my own way to the last meeting I had with them. I’m enthusiastic about them, but because I can really see the point of in-memory, object-oriented cloud computing and I like the way they applied the technology to the problem.
So what’s the value of a better mousetrap?
When I think about any of these companies, I start by trying to figure out what kind of value they could deliver. Back in the dot-bomb days, this was a really good way of separating out the wheat from the chaff, because many of the vendors didn’t deliver any value at all and wouldn’t unless they changed what they were doing radically. CommerceOne, I remember, was my paradigm for this. Their software didn’t do anything and wouldn’t do anything, so there was very little value.
I then figure that the value of the company is some function of the value they deliver multiplied by the time that they can deliver it for. This last part is important. One worry I have about Groupon, for instance, is that it might turn out to be a fad. People will get tired of getting coupons (unlikely, I admit), or merchants will get tired of giving stuff away, and after a while they’ll fade to black. With Google, by contrast, I don’t have that worry. It will deliver value for a very long time to come, unless people stop using the web.
So where does Workday stack up on this measure? Obviously, it’s not bad. If it really is a better mousetrap and it gets into more of the large companies in the world, there’ll clearly be a lot of value delivered. And given how long companies use these products (20 years is pretty normal), the total value delivered over time is significant. As much as coupons? Sure. Maybe more.
But, then why haven’t they already zoomed up into the stratosphere, like Facebook or Twitter? The answer, I think, points up a really important difference between the public cloud applications and the ones, like Workday, which are meant for organizations. The public consumer applications are things that an individual picks up and uses. But enterprise applications are really a piece of infrastructure, like buildings or electrical systems, which don’t deliver much value until they work for a lot of people.
When you build products for individuals, you can bootstrap. But when you build infrastucture, revenue doesn’t come in right away. There’s always a large up-front investment, partly in physical plant, partly in getting the infrastructure to the user. True of electrical systems or telephone systems. True of roads or harbors. True of enterprise software systems.
So Workday today isn’t zooming because it’s still building out. In a way, it’s a little bit like Hoover Dam, say 75 years ago, when the dam was done and the pipeline was being built. A monster amount of money had already been spent on the dam, and during that time, there was no revenue at all. Then, while the pipeline was being built, some revenue came trickling in (hee, hee). The people in El Centro or Thermal or Brawley were getting good, fresh water, and they were paying for it. But it didn’t add up to a lot. No offense meant to Flextronics, but this is the situation that Workday is in now, with that $100 million that some people find so sneer-worthy, if $100 million it is.
So why are they sneering? Well, sure, if the pipe stopped in Brawley, it wouldn’t be so great. But you have to ask, why does anyone think the pipe’s stopping there. Presumably, the pipe will go farther, hit a city or two, and then the investment looks a lot better.
Sure, there is some doubt, as long as the value isn’t actually being delivered. An earthquake might break the pipe or the dam. The water might be no good. Somebody might invent a fresh-water-from-salt process that works really well. At Workday, people might not like the product as much as I do. It might be difficult or expensive for companies to dump their old systems. New competition might crop up.
But that’s not the point. The question is, how do you value Hoover Dam when the pipe has only gotten to Brawley? Well, you don’t start out by sneering at the revenue they’re getting so far.
So, two points to remember, if you’re afraid of boom valuations.
1) The real value is a function of the total value delivered over the life of the product.
2) For infrastructure products, especially cloud infrastructure products, you see a huge up-front investment, and while things are being prepared, money comes in slowly.
So, under these criteria, how does Workday look? Well, it’s pretty good. Take a look at the value that Flextronics is planning to get. Assume that other large, global companies will also want that value. And assume that once it’s in place, the product can go on for the 20 years that PeopleSoft seems to be lasting inside companies. As good as Groupon, ya think? I think.
Which brings me to the second reason I don’t believe that story. $2 billion sounds like a number that a value investor made up because he’s trying to show how ridiculous valuations have gotten. But when you look at what’s actually going on there, $2 billion seems off. It appears to me that it’s rather too low.
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.
July 9, 2010
The Supreme Court threw a big stone into a small pond last week when they decided a case popularly known as Bilski and for the third time in 15 years changed the rules for the protection of software. I won’t weary you with all the ins and outs. But I do want to say, quickly, what’s changed in this area of the software industry and speculate a little about how this might affect things.
(By the by, not enough credit for all this can be given to a long conversation I had earlier this week with Robert Tosti of local IP law specialists, Brown Rudnick.)
Change 1: Many of the patents granted in the last 15 years that essentially try to patent a business process done in software are now called into question. They are NOT invalidated, per se. But the Supreme Court has also said that at least some business processes (like the eponymous Bilski’s) are not patentable, because they are “abstract ideas.” So the more like an abstract idea the patented process is, the less likely it can be enforced.
Change 2: You can still patent software, but in the absence of any guidelines as to what is an “abstract idea,” (not patentable), it is not clear that software patents will take the form they used to take. Clearly, any attempt to patent something in this area is now fraught, but clearly, a sequence of screens is less risky than (but also more limited than) the business process that the sequence is intended to support.
Change 3: Innovation in software is no longer as easily protected as it was when Amazon patented “one-click shopping.” (Tosti’s example of a patent that could well be still enforceable, but might not be). To get protection for an innovation, software companies will probably need to design and coordinate efforts in four separate areas of the law: patent law, copyright law, protection of trade secrets, and contract law. This will be expensive to do, and it will make enforcement complex (though also giving enforcement efforts lots of scope).
How will this affect software companies? Clearly, Bilski should give patent trolls some pause. (Not that companies like NTP are dissuaded. NTP just filed suit against Apple and Google, among others things claiming infringement of their e-mail-on-mobile-devices patent.) Software companies like Oracle and Salesforce now being sued by (depending on your point of view) greedy patent trolls or inventors who have had their rights trampled on by greedy software companies should feel that they have more ability to defend themselves than they did.
The one thing we won’t see is more justice. While people are trying to figure out what a patentable business process is, you’re going to all the overreaching, ambition, greed, arrogance, foolhardiness, self-delusion, and self-righteousness that you might have seen had you been in alive in the days of the Gold Rush.
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.
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.
January 20, 2010
I argued in the previous post that SAP’s new, “two-tier” pricing system for maintenance offers customers less choice than meets the eye, and commentators like Dennis Howlett agree.
So why did they bother? If one offering is “good support for a fair and reliable price” and the other offering is “less good support for roughly the same price (only no one will really know for six years)” why would anyone pick the latter? And why would SAP risk a public relations nightmare when the people who pick the apparently lower-cost alternative find that they’ve been snookered?
Is it just that SAP needs to offer the enterprise application version of “small coffee,” the coffee size that nobody ever orders, but you need on the menu, so people will order medium?
The question is particularly salient because SAP has data that, one could at least argue, shows that Enterprise Support really is better.
This data comes out of a program embarked on last summer, sponsored by SUGEN (SAP User Group Executive Network) and SAP. In this program, companies were put on Enteprise Support, and the benefits thereof were measured in 11 benchmarks and the sum of those benefits added into something called the SUGEN KPI Benchmark Index. SAP had vowed not to raise the cost of Enterprise Support until this program showed that a gain in the Index that gained justified the increased cost of Enterprise Suppory.
SAP reported the results at the Influencer Summit last December, which I attended. According to the numbers they showed me, the SUGEN KPI benchmarks had indeed been achieved.
These numbers were disclosed to me on the condition that I not repeat them until the full results were published, and while I’ve been given informal permission to speak about them, I will try to respect this request.
I think, though, that I can convey a fairly accurate idea of what is going on without actually citing the numbers.
Before I can get to this, though, I need to explain something about the program and the expectations that people had for it. When SAP first announced a new, improved class of support at an increased price, which all customers were required to use, many customers thought that this was just price-gouging. They didn’t believe that SAP’s across-the-board price increase for maintenance would be accompanied by any benefits. When SAP started hearing from these customers, they were clearly taken aback, since the executives in charge of this new support program clearly did (and do) believe in its benefits.
So SAP (and SUGEN, the customers’ self-appointed representatives) agreed to put the question to an empirical test.
Now anybody reading the press release about this program or anybody attending the journalist session at last May’s Sapphire (as I did) would believe that this test would be done along traditional social science lines. A representative sample of the SAP customer base would be given the opportunity to take advantage of Enterprise Support, and the benefits would be measured.
After attending that session, I told my client base (people who are professionally interested in tracking what SAP does) that it was impossible for this program to show so much benefit that it would justify the across-the-board increase. The reason was simple. To get the available benefit from Enterprise Support, a customer must get and install a software product called the Solution Manager and must then do a lot of process documentation and process modification. A representative sample of SAP customers simply wouldn’t include very many customers who had done all this installation, documentation, and change, because the total amount of work was considerable, and most customers weren’t going to do it, at least not any time soon.
Isn’t it sort of squirrelly, expecting Enterprise Support customers to get software, install it, and then do a fair amount of work before they get the benefit that SAP promised them? Well, yes, but it isn’t quite as squirrelly as it sounds.
At the Influencer Summit, Uwe Hommel, the person behind this idea, expressed it roughly this way. A lot of customers don’t really run support as well as they could. The Solution Manager provides them with a framework for the practices that they should be using, plus it enables SAP support personnel to give better, more accurate, and faster help, because the Solution Manager gives them better information about what was going on at a customer site. It would be nice if SAP could wave a magic wand and improve support without any effort from the customers. But that just can’t happen. All we can do is provide a framework.
As far as Hommel is concerned, what SAP is saying is roughly what the trainer at the gym offers. “We’ll make you better, bigger, stronger, and leaner, but of course you have to do your share.”
Fair enough, of course. But that’s not actually what SAP said. SAP actually said something more like, “You need to do support better, and to do it better, you’ll need a trainer and you’ll have to put in some effort, but oh, by the way, you have to pay for the trainer whether or not you actually get around to going to the gym.”
Perhaps the oddest thing about the test that SUGEN and SAP ran is that both parties pretended that SAP had said the first thing and not the second.
You see this, for instance, in the way they [SUGEN according to Myers, below] chose the subjects for the test. Rather than choosing the representative sample of the customer base that I was told they would choose, they asked for volunteers to apply for the program. 140 customers did apply; of those, only 56 were chosen for testing. This, of course, simply guaranteed that the test would not prove what SAP wanted it to prove, that the price increase was justified. At best, it would prove that those customers who decided to go to this metaphorical trainer would get some benefit from it.
So, did they get some benefit?
Well, um, uh, sort of.
As I said above, SAP and SUGEN agreed before the test that there were 11 areas where benefit might be provided. The areas ranged from the obvious things–fewer outages, faster problem resolution, and fewer problems–to the less obvious, but still important things, like more efficient CPU utilization and better use of disk storage.
In the actual test, the benefits of Enterprise Support was measured in only 6 of these 11 areas. The areas chosen had to do with total cost of operations (use of CPU and storage), the cost/effectiveness of managing patches, and the extent to which customers used SAP’s current software effectively. Clearly, this made things harder for SAP, since they were trying to prove benefit, but the benefit was actually measured in less than half the areas where benefit might be available.
Nevertheless, SAP thinks that it succeeded, and technically they did. They measured benefit by giving the SUGEN Index an arbitrary value of 100. The way I understood it at the session, the aim was to show that the increased benefits at least offset the roughly 7.6% price increase in 2009. [According to Myers, below, the actual aim was 4%].
Both aims (what I thought was the aim and what Myers said was the aim) were actually achieved. The benchmark index dropped by 6.89 percentage points. Even though only 6 benchmark areas were measured, the benefit achieved did offset the 7.6% increase (at least within 1 percentage point).
There is, however, a little, tiny, “but.”
All the benefit was achieved by massive improvements in only two out of the six areas: storage utilization and number of failed changes. (A “failed change,” is an attempt to install a patch which fails.) In all the other areas that were measured, the average improvement was very small.
Both of these measure appear to me to be one-time-only improvements. Take, for instance, storage utilization. If you have one of those awful Windows machines, and your disk is sluggish, you can run a utility that compacts your disk and frees up disk space. You’ll show massive improvement in storage utilization. But running this utility once is not the sort of thing that justifies a permanent yearly increase in maintenance costs. Yes, you can do it next year, but it won’t show the same level of improvement, because you gained most of the benefit the first time you did it. The same thing goes for reducing failed changes. Changes in process (and use of the Solution Manager, or Sol Man) can reduce this number a lot. But once you’ve made the changes, further reductions aren’t really available.
I certainly hope that somebody from SAP is reading this; if you are, you’re probably upset, because you’re saying to yourself, “Well, the benefit is permanent; for the rest of time, people will have fewer failed changes and use less disk space.” [Myers does in fact argue this. See below.] You are, of course, right. But you’ll have overlooked the larger question: does helping people to a one-time improvement justify a permanent, yearly price increase. That is hard for me to see. If Enterprise Support promised to bring these kinds of improvements in regularly, then it would be OK to pay more for it regularly. But this test doesn’t show that these regular improvements will be forthcoming.
In any case, it’s all moot now. SAP has scrapped the SUGEN benchmark process. In a way, it’s a shame. This is one of the few times that any enterprise application company has ever tried to run a systematic test of whether its software and services work as advertised. And the results of this test are very interesting. In some areas, the software and services don’t seem to work; the benefits are minimal. In other areas, though, they work very well indeed; the benefits are startling. Who woulda thunk it?
At the very least, shouldn’t SAP keep going with this, so it can go back and fine-tune its software, figure out why some benefits aren’t forthcoming and do something about it?