Force.com, Amazon, Facebook: Different Tools, Different Jobs

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

In between Foo Fighters shows and Neil Young appearances, the folks from Salesforce.com threw together a pretty good conference, if I do say so myself. Good content, good attendance, and enough substance to their announcements to set me back weeks, coverage-wise.

But here we are, weeks later: I guess it’s time for the Q&A. So without further delay, a few questions and answers concerning the recent Salesforce.com conference.

Q: Before we begin, anything to disclose?
A: Salesforce.com is not a RedMonk client, but they comped T&E for the show.

Q: How was the attendance at the show? Rumor has it conference attendance is down across the board, and that conference venues are scrambling a bit as a result?
A: I’m not sure what the actual attendance was – I heard figures from 7K to 10K bandied about – but the show was well populated, economic end times or no.

Nor did the attendees I spoke with – largely developers and customers – mention any specific economic issues relating to the economy, apart from the general grumbling indulged in by most of the population at this point.

Q: Om says that Salesforce.com has jumped on the cloud bandwagon with both feet: do you agree?
A: Yes. Last year’s launch of Force.com was obviously the initial foray, product-wise, into that space, but this year’s event was heavily cloud branded. From the inflatable plastic clouds hovering peppered across Moscone to the keynote slide promising customers that there future was a great big arrow pointed straight up, Dreamforce (I still chuckle at that name) was all cloud, all the time.

Which is to be expected, frankly.

Q: Why is it expected?
A: Software-as-a-Service is yesterday’s news, while cloud is the new hotness. Sure, it will burn itself out as a marketing term eventually – much as SaaS did before it, losing its novelty and making the jump to the boring old mainstream. But in the meantime, it’s logical for Salesforce.com – a company that is off-premise in everything it does – to take two steps to the left, and hug the cloud brand tight to its chest.

That way marketing and PR wins lie.

Q: So you think that the branding was strictly marketing?
A: Not at all. Salesforce launched several new technologies at Dreamforce, all of which are at least vaguely cloud-like. And they are, along with Google, one of the notable providers of what I term a fabric cloud platform.

So while I do believe that they are somewhat unreasonably conflating SaaS – their primary product line – with the cloud, they certainly should be considered as a cloud player.

Q: What were the new technologies announced?
A: There were several, but for me the big takeaways were a.) the launch of Sites, and b.) the partnerships with Amazon and Facebook. The former got a lot of ink and is likely to be the more immediately relevant from a customer perspective, but the latter is far more important from a strategic perspective, in my view.

Q: Can you explain that a bit? What’s “Sites?”
A: Sites, properly termed Force.com Sites, is basically an offering allowing customers to host websites on top of Force.com. While web hosting might not seem terribly innovative as an offering – and it isn’t, although some of the integration pieces are nice – Sites is a nice complementary, cross-sell offering to Salesforce.com.

After all, if you’re content to outsource your CRM, do you really see value in hosting and maintaining your own web properties?

Q: What about the Amazon and Facebook integrations? What’s the significance there?
A: The joint partnership announcement is significant for a few reasons.

  1. It demonstrates some progress towards cloud heterogeneity and interoperability. It’s limited, of course, in that it’s a product of formal partnerships rather than organic standards, but still, it’s progress.
  2. It allows customers the ability to not reinvent the wheel. One of the beta customers for the Amazon integration demonstrated the ability to leverage image scanning and sharpening libraries, written in PHP, running on EC2, from the context of a Salesforce.com property. The alternative, absent the integration, would be rewriting the libraries in Apex, which would be a non-starter for most customers.
  3. It begins to bridge the consumer and enterprise worlds, by bringing together Facebook and Salesforce.com in interesting, creative ways. One example was a recruiting application that leveraged Facebook for distribution; the far more logical property for propagation amongst one’s circle of friends and acquaintances.
  4. It tacitly acknowledges Facebook as a de facto identity repository. This case was made by the claim that Facebook users trust that application with their identity and their privacy. Whether you consider that to be true or false, Salesforce.com’s partnership pushes it an important step closer to being reality. Facebook could wind up, if it’s lucky, being the de facto identity repository for one hell of a lot of people.

If you think that all of the above distills down to an acknowledgement that at present the different cloud and SaaS platforms have very different strengths and weaknesses, and are logical partners, you’re right.

At least to me.

Q: What did you hear from customers? Are they happy? Are they worried about that the language and database are proprietary?
A: Taking the last question first, surprisingly little. Or perhaps not so surprising, as the audience at a Salesforce.com conference is the definition of self-selecting, but there were very few concerns period regarding the nature of the platform. Which is one datapoint that seems to validate my earlier contention:

History has demonstrated to me quite adequately that enterprises, at least, are more than willing to lock themselves in if it solves a problem they have now quickly and cost effectively.

Some of the implementations on top of Force.com were extensive, both in complexity and in data volumes.

As for whether or not they’re happy, I’d say generally yes, but they do have recommendations for other customers.

Q: And those are?
A: Pretty much what you’d expect.

  1. Focus on the SLA, and lock-in predefined escalation paths for downtime
  2. Restrict access to the app store catalog to predetermined, authorized personnel
  3. Secure an executive mandate before proceeding: it’s not yet a “no one gets fired for buying Salesforce.com world”
  4. Start slowly, build incrementally, and change as little as possible

And so on. Nothing really surprising or unexpected.

Q: Anything else to add?
A: That about covers it here, I think. Questions? Something I didn’t answer? Drop me a line.

No Comments

Leave a Reply

Your email address will not be published. Required fields are marked *