To be blunt, my justification for attending the Salesforce.com conference last week had little to do with, well, Salesforce.com. More precisely, the Salesforce.com application. While my past includes hands on exposure to CRM and SFA applications, my present duties do not include coverage of same. [1] So why fly all the way to San Francisco, for the third time in as many weeks? I’ll let Marc explain it:
In a completely different domain, Salesforce.com is also taking a Level 3 platform approach — Salesforce now provides quite sophisticated ways for users and developers to create and upload code and program the Salesforce platform from a browser.
Salesforce provides a Level 3 platform both because it lets users easily customize Salesforce to do whatever they need, and also because it definitively trumps the criticism they historically got from packaged software vendors like Siebel who accused Salesforce of not being as adaptable as a piece of software you install on your own servers.
You probably don’t see this in action much — unless you’re a Salesforce user — but they’re doing really interesting work in this area and getting great results.
In other words, it’s the platform, stupid.
As Marc elaborates – read the whole thing, it’s brilliant – talk of platforms is all the rage these days. We have OS platforms, virtualization platforms, browser platforms, developer tooling platforms, mobile platforms, publishing platforms, social computing platforms, hardware platforms, hardware-as-a-service platforms, and – like Salesforce.com – software-as-a-service platforms. Everywhere you look, someone’s pushing a platform.
Which is, of course, nothing new. Everyone always wants to be a platform. Probably because the tactic worked so unbelievably well for the largest software company in the world that the DOJ and EU were forced to get involved. On a list of problems for a software company to have, that’s counterintuitively a good one: it means, essentially, that your platform has been too successful.
As Adam says in “What is the Platform?”
When I was at Microsoft, the prevailing internal assumption was that:
1) Platforms were great because they were “black holes” meaning that the more functionality they had, the more they sucked in users and the more users they had the more functionality they sucked in and so, it was a virtuous cycle.
2) To get this functionality, they had to be as extensible as possible so that extensibility, not ease of development was the priority for the API’s.
3) Since the rest of us often found aforesaid API’s complex/arcane, and since the rest of us built the “apps” that the corporations used, there needed to be a layer above the API’s called a Framework which hid the complexity and provided a kindler simpler gentler programming paradigm. (Think VB or MFC)
4) If everyone who could code could use this Framework, then they would build a plethora of applications locked into the platform and, hey presto, “stickiness”. Thus building an IDE and a Framework was the sine qua non of a platform even if it lost tons of money.
But as Adam notes, the world today is not the world as it was. If you read the piece, you’ll see that he’s betting on “services,” and – naturally – I’m inclined to agree. And while the navigation from current state to future state is likely to be hideously awkward (see Dilemma, Innovator’s), it’s a good bet that Microsoft does too. Or is anyone going to argue that Ozzie was handed the keys for a different reason?
To ground the discussion, let’s consider what the word services actually means. That, after all, is the interesting question. Not to mention the reason that I think the Force.com brand launched at Salesforce.com might ultimately supercede the Salesforce.com parent that spawned it – but let’s come back to that.
For Adam, services are browser based, mass market, and predicated on “access to community, collaboration, and content.” Setting aside the three C’s for the moment, it’s worth emphasizing the “mass market” bit. If you’re going to build a platform, then, your ultimate ambition should be DOJ intervention. Or, if you prefer, falling just short of that. That’s real mass market. That’s real volume. And volume will win far more often than it doesn’t.
The web doesn’t, of course, guarantee volume. But the lack of it probably does preclude it. You can have the web and no volume, but volume without the web? Not likely. Hardly an original assertion, we have to start somewhere.
The logic, then, should be simple: platforms contenders need volume, ergo platform contenders will be built on – or at least around (e.g. Skype) – the web. This assertion is certainly born out by recent history, not to mention recent valuations.
One of the keys for anyone with platform ambitions, then, will be buying or building the infrastructure required to support the necessary volume – the critical mass that incents the virtuous cycle of participation that is characteristic of successful platforms. The big guys mostly have this down, red shift challenges notwithstanding. It’s the little guys that are likely to have trouble.
As we often say when speaking with small software as a service (SaaS) vendors, the good news is that your potential customer pool is infinite. The bad news is that your potential customer pool is infinite. Scaling, as anyone who’s tried it knows, is difficult. Harder for some things than others, but always hard. In a piece from December of ’05 entitled “Scalability: Damned if You Do, Damned if You Don’t,” I said the following:
One interesting question that I’m beginning to ask from all of this: is it even possible for smaller players to scale competitively? As good as the del.icio.us, FeedLounge, et al guys are codewise – and many of them are very, very good – there’s the non-coding aspects of scalability to consider. Networking, hardware, etc require capital investments that can be onerous when bootstrapping, and it’s a simple fact of life that the smaller guys don’t benefit from the economies of scale that say a Google or a Yahoo will. They buy hardware piecemeal, and get run-of-the-mill bandwidth deals, all of which adds up to high entry costs.
But might there be an opportunity there? Might there be an opportunity to aggregate lots of these Web 2.0 (for lack of a better term) services in one place, and offer them an affordable, scalable infrastructure? Maybe. There are lots and lots of hosts out there, but are there any that provide specific expertise in scalability? None that I’m aware of.
As true today as it was when it was written? Not quite.
Scalability is still hard. But the weapons with which smaller would-be platform players can attack the challenge of volume are far more numerous. For just the reason I predicted: a few players have seen the opportunity for aggregating the smaller players, almost like a co-op. Which, as an aside, is a model that could have relevance for smaller technology firms in the near future.
The most elemental of these weapons is bare bones hardware-as-a-service (HaaS); rather than buy and build your own infrastructure, you rent it from larger players that can realize economies of scale on both the purchasing and management fronts. Think Amazon’s EC2/S3 or Joyent’s Accelerators. You’re given a basic hardware and OS base to build from, and after that you’re on your own. While the model has its drawbacks, it’s my belief that it will become increasingly compelling as more competition lowers prices and increased refinement of the technology lowers barriers to entry.
One level up from that, then, we have Salesforce.com’s recently announced Force.com offering, which they suggestively refer to as “Platform as a aservice.” It’s distinguished from HaaS by way of several additional assets that you can draw upon: a preexisting, managed database, UI framworks, browser based design tools, and so on. The question Salesforce.com would like to ask would be ISVs is simple: if you don’t want to manage your hardware and OS, why would you want to manage the rest of it? It’s more economical, they argue, to leave that to them.
Which indeed it might be, depending on your situation. Certainly there’s interest: Salesforce claims that better than 44 thousand applications run on their platform now, and that customers have made 18.7 billion calls into their APIs.
The catch is that, like Windows before it, you’re writing into a single, proprietary platform and a proprietary API. With, notably, a custom language. The question to be determined, then, is whether the benefits – making the majority of a given infrastructure someone else’s problem – outweigh the risks of lock-in. Those writing to Windows could soothe their concerns on this point by reminding themselves that the operating system in question virtually owned the market. Those writing to Force.com will not have the same assurances, but to what extent the virtually infinite audience promised by the web mitigates those concerns remains to be seen.
If Salesforce.com can effectively make that transition, however, from a mere SaaS provider to a SaaS platform, it seems inevitable to me that Force.com as a brand would eventually eclipse its parent. It’s far too early to see how things will yet play out, but with Salesforce throwing its hat clearly in the platform ring along with Amazon, Google, et al it should be fun to watch.
The $64,000 question, though, is whether or not hardware, operating system, and general system players can afford to not play in this space. Are you content to be a mere arms supplier to the next generation platforms, or do you need a platform of your own? Virtualization is already disintermediating the hardware; HaaS and now Salesforce.com’s PaaS take that one step further. The risks – and rewards – are potentially immense.
Disclosure: Salesforce.com is not a client, but they did comp T&E for last week’s conference. Nor are Amazon, eBay, Google clients. Joyent is not a client, but its founder host a personal website of mine gratis.
[1] Huge thanks to Stephen Naventi and the folks over at Outcast for proactively realizing that and scheduling me accordingly.
