Benioff: Where ASPs (and Larry Ellison) got it wrong

It was a total fallacy to believe that enterprise applications were fit to be delivered using the ASP model. The software simply wasn't up to it.
Written by Phil Wainewright, Contributor on

I couldn't resist the temptation to reminisce about the early days of on-demand application vendors — or ASPs as we called them at the time — when I met with Salesforce.com's founder and CEO, Marc Benioff, last week.

Salesforce went live on February 22nd of 2000, which was pretty much the peak of the ASP bubble."On demand is a marriage, traditional client-server software is a one-night stand" Two or three extremely challenging years followed from that moment. There were quite a few big changes that the survivors had to make to their original assumptions, including a move away from the 'cookie-cutter' mentality of the early years to build in the extensive integration and customization capabilities that customers demanded. Was there ever a time, I wondered, when Benioff and his team wondered if it was ever going to work out?

"Like in any tough entrepreneurial pursuit, there's always times when you're wondering, is this the right thing or not?" he told me. "We had to make a lot of tuning to the business model, to the technology model, to get these things right, to get this thing to work."

Prior to founding Salesforce, Benioff had worked at Oracle, whose CEO Larry Ellison had his own ideas about the ASP model. As well as a founding investment in Salesforce.com, Ellison backed two other ASP ventures. For the small and mid-sized business market, he funded a startup led by ex-Oracle VP Evan Goldberg, which now thrives as on-demand business applications vendor NetSuite. To serve larger enterprises, he had Oracle set up its own internal hosted applications division, which now goes by the name of Oracle On Demand. The Ellison vision was clear-cut: pay-as-you-go, multi-tenant, cookie-cutter applications for the SMB sector; conventionally licensed, single-instance, highly customized applications for Oracle's traditional enterprise customer base.

"Turned out, a lot of what Larry was saying was wrong," said Benioff. "The most important thing [we learnt] was, [we had to make sure] the customer was successful. Nothing was more important than making every user and every customer totally successful. And we had to come up with a new term for it — we call it 'adoption'. Adoption means that the user really adopts our technology and that they really embrace it and it becomes part of their ecosystem that we monitor and we manage it and we pay attention to it and all of these things.

"At Oracle, we signed a deal and we ran away as fast as we could. On demand is a marriage, traditional client-server software is a one-night stand. It's two different ideas."

Nowhere was that difference in pedigree more evident than when it came to actually delivering reliable on-demand services that met live customer requirements. One of the foundations of the mainstream ASP model was the belief that, by virtue of their core competence in managing enterprise applications, they would be able to deliver live applications that simply worked better than those operated by customers themselves. The belief was founded on the fallacy — widely promoted (then and now) by software vendors — that it was a lack of skill and resources at the average customer that made the enterprise application stack so difficult to manage and use successfully. The truth was that the vendors did not have a clue just how unfit for the task their software really was. It was the unfortunate lot of pioneering ASPs to make that discovery through bitter experience, whereas on-demand pureplays like Salesforce.com set out to write code from the ground up to do the job.

"People did not realize we had to write a lot of code," said Benioff. "We're not talking about small amounts of code any more. We're talking about seven years of code.

"People were trying [back in 1999/2000] to get entire businesses going with no code at all. They were trying to repurpose client-server code that didn't extend to the scale and the reliability and failability and usability and all these things that it did not have. That's the fundamental difference. People just wanted to get going.

"That's the Corio's and USinternetworking's and all these crazy companies who were like, 'Oh yeah, we're going to create utilities, and what we're going to do is, we're going to take all of this stuff that's built as this single-tenant, non-scalable architecture that's unbelievably hard to use, and roll it out as a service like Amazon.

"It was incongruent. Amazon, eBay [were] written from the ground up to be multi-tenant and shared and so forth. Why did we think that somehow the enterprise technology would be any different? I just think those people were incredibly naive. Or they really just were not software people. The reality is they were not really software developers so they did not really know."

Footnote: It strikes me there's an interesting parallel with that early ASP experience in the rush of today's Web 2.0 startups to market with their mashup applications. People are once more trying to "get entire businesses going with no code at all." Except that this time they're at least starting with the right architecture. What they lack is the enterprise credibility. What goes around, comes around, but always with a different twist.

Editorial standards