Salesforce.com’s announcement Monday that it would open up its proprietary Apex programming language to customers and other developers marks an important turning point for the company. It’s been clear, at least since the announcement of its AppExchange software marketplace a year ago, that Salesforce’s ambitions go well beyond providing a simple customer relationship management system. With Apex, those ambitions come into clear focus: Salesforce doesn’t want to be your CRM supplier; it wants to be your data center. It wants to underpin and run all your enterprise applications, while giving you the tools to customize them. Its original slogan “Success, Not Software” appears to be morphing into a new one: “Innovation, Not Infrastructure.” That phrase appears, in fact, in the press release announcing Apex (though it’s spoken by an AMR researcher).
Last year, I questioned Salesforce’s decision to run its software-as-a-service application on its own infrastructure rather than have that infrastructure hosted by a hardware utility. Now, I understand the rationale for the decision: the infrastructure is the product. While Salesforce’s move opens up new opportunities for the firm, it also dramatically widens the competition it will face. Everyone from Microsoft to Google to Amazon is moving into the business of being an infrastructure utility. And, in an age of standardization, it will be interesting to see how customers react to the idea of running their enterprise applications in a private language. Is Salesforce the SAP of the SaaS world – and is that a good or a bad thing?
Dan Farber reports that venture capitalist Mark Gorenberg views Apex not just as a turning point for Salesforce but as a watershed for corporate computing in general. Gorenberg “hailed Apex as the most significant announcement since Sybase announced stored procedures. In effect, Gorenberg said, stored procedures led to the change from mainframe to client/server computing. ‘Apex will be the big tsunami for a new platform for applications,’ he concluded.” That’s a bit of an overstatement, but what Salesforce is doing is certainly part of a big tsunami in business computing, a tsunami that does indeed mark the transition away from the client-server age into what I’ve called the third age of IT. At the center of that age will stand not the PC but the utility-class data center, providing companies with at once greater efficiency and greater flexibility.
UPDATE: In another post, Dan Farber interviews Salesforce’s tech guru Parker Harris, who goes deep into Apex’s technical details. Meanwhile, Sinclair Schuller makes the case against what he terms the Apex “handcuffs.”
Re: third age of IT.
I think you’re probably right about the trend, but is this really a new development? If the first age of IT was mainframe-driven, Age 1.5 (sorry) was the heyday of bureau processing – outsourcing IT before it had been insourced. Back in the 1980s I worked for a company which couldn’t run to a full-sized mainframe, and one of the corners they cut was payroll – the company logo on our payslips said ‘ADP’. How big a difference is there between running your payroll on ADP’s systems (which are going strong, incidentally) and running your ERP on Apex’s?
Phil,
Not much conceptually but a lot practically. Running payroll was essentially a batch process. Now, it’s possible to go the ADP route with a lot more, transaction-intensive applications. It’s interesting that ADP has purchased Employease, a leading SaaS supplier for HR programs.
Also interesting is that many people say that security concerns will prevent companies from hosting their data on another firm’s computers, yet the broad acceptance of ADP’s service shows that companies actually have little problem offloading very sensitive data – on employee salaries and bonuses – to a trusted outsider.
Nick
Nick,
I agree with your general industry assessment re: infrastructure productization. The commoditization of infrastructure is a driving component of SaaS that goes hand in hand with enablement technologies and ‘platforms’.
However, I still raise questions about Salesforce’s true aspiration to do just that with Apex. To note, a comment from Kingsley Joseph of Salesforce re: extending functionality beyond that which Salesforce.com makes available:
“You can continue to use our API and build apps on your platform of choice.”
Essentially this means that if, as a vendor, you want extended or custom functionality… you’ll need to foot your own infrastructure anyway. Which seems to defeat the purpose of providing a hosted platform in the first place. Sure, it’s extensibility on the service side via external API calls… but much of the value is of loss to the vendor if that custom functionality requires their own platform, and infrastructure, anyway.
Apex seems like a step towards something that has yet to be introduced – a complete, and open, on-demand application hosting platform on a hosted infrastructure.
Matt, simply because you can doesn’t mean you have to. I’m sure there will be a few things that won’t be possible in Apex on day one that you will need to have hosted, but the vision is to take it at least to the point where we can do app development on it internally. My opinion is that most apps will not need anything more than Apex code to make them work.
My bet is SF started feeling that a significant portion of its prospects (if not current customers) aren’t satisfied by the hosted and/or purely customizable solutions. Initially they targeted a market of not too fastidious customers, those that can get by with predefined processes and configurable (but not customizable) solutions. But the more customer appetite grows (both for more sophisticated processes and more complex integration) the more obvious is a need in letting them develop what they want.
Getting wide acceptance among partners and building a real ecosystem (and here kudos to SF!) is impossible without equipping the developers with sufficient tools and mighty means they need. To let build new applications on top of an infrastructure one needs to remove a barrier of lacking skills.
So today they “simply” widen AppExchange by opening Apex and pursue a short-term target – build an ecosystem of developers. But tomorrow it’ll allow SF to sell inhouse solutions built on their infrastructure (and hope to have enough partners and consultants to support new projects). The slice of big enterprises which for various reasons can’t afford SaaS applications for some pieces of their core business is huge to not dream about that.
Would Microsoft’s development tools (Visual Basic, C# et.al.) be popular if Microsoft could see every line of code that was written? At least in a business setting, no matter what efficiencies the tools brought, Independent Software Vendors would stop using these tools overnight if using them implied intellectual property was disclosed!
When using On Demand platforms like Amazon EC2, technologies like obfuscation and encryption can be used to hide software code from the platform provider. These are the same tools used to protect code installed on customer site.
As an On Demand BPM service provider, I cannot imagine storing our intellectual property in clear-text on Salesforce.com’s servers.
Nick,
SFDC has built a solid salesforce automation business, and for that they deserve a strong p/e ratio. I reckon that the rest of the story is mere puffery. There is a whiff of the Commerceone marketplace story to appexchange.
More here.
http://theotherthomasotter.wordpress.com/2006/10/13/apex-and-appexchange-full-of-sound-and-fury-signifying-nothing/
(disclosure: I work for that German software company that MB has threatened to destroy because he thinks it is an innovation free zone)