Tag Archive for 'Force'

Salesforce and Google integrate some more

Since the beginning of the year Salesforce’s Tour de Force event has been touring the world. The Tour de Force events are all about the Force.com platform as a service, leaving Salesforce’s CRM offering for discussion at the Dreamforce conference. Today’s stop on the tour was the home town stop of Silicon Valley so had a bit more importance to it. The Tour de Force is coming to Australia later in the year but dates haven’t been announced yet.

The keynote from CEO Mark Benioff was live blogged here by the new TechCrunchIT blog and is available to watch here.

The key announcement today was the Force.com Toolkit for Google Data API’s. Earlier in the year we saw the first steps of integration between Google and Salesforce with access to Google Docs from within Salesforce. This was supported by some 3rd party addons to help with user provisioning between both services and adding buttons within Salesforce to associate Google Docs with a particular account or contact or open Gmail when viewing a contact. At the time there were also new code examples on the Force.com wiki of using Google’s Data APIs.

So what makes today’s announcement different? The previous Google Data integration was using Google’s javascript API’s. Javascript operates client side and the browser was the middle man between Salesforce and Google data. Today’s announcement takes away the middle man and enables server to server communication between Salesforce and Google’s servers. This is being implemented by new methods in Salesforce’s server side Apex programming language.

The initial Google API’s available are:

  • Google Documents API
  • Google Calendar API
  • Google Spreadsheet API
  • Blogger API
  • Contacts API
  • Google Data Authentication

The Toolkit will expand to incorporate more of Google’s offerings and has been issued under the open source BSD license.

So what to make of this? From a technical point of view it’s cool, but we have had SOAP and REST integration between websites for a while. From an alliance point of view it’s about establishing a combined threat against Microsoft. Salesforce is a becoming a big player with market cap today of 8.75B (having just overtaken Sun Microsystems 8.71B). It’s a longer term move that won’t bring about immediate results. Salesforce serves big companies while Google’s enterprise offerings currently are more suited to small companies. This alliance is about working towards a convergence that might not be realised for another 2-3 years but would you want to be Microsoft when it is?

PaaS from a bookkeeping app? Think beachheads….

Breaking news from Intuit that they are launching a cloud computing offering to compete with Force, AppEngine, Amazon etc.

Intuit is the creator of Quickbooks (think 3.6million users for their bookkeeping offering) and it would seem that this offering is all about creating applications wrapped around Quickbooks (a la Force does with Salesforce) and creating, in essence, a complete SMB offering.

It’s sounding interesting - a very rough split could see Force take enterprise users, Intuit the SMEs and Amazon/Google the consumer market (although that’s a little simplistic and it is very early days yet).

Bob reports that early customers are working on things like;

  • Customer Service
  • Employee Scheduling
  • Existing software vendors looking to add new modules
  • Solution providers looking to move from 1:1 custom work to converting their domain knowledge into applications so they can sell products 1:Millions

I’ll be keen to read the thoughts of the likes of Apprenda about this - is it a threat or simply further validation of PaaS

PaaS - monolithic or segmented stacks…

An excellent post over on SaaS blogs locks at two possibilities for PaaS. One is very vertical in nature (AppEngine, Force etc) providing all the various layers needed for the offering (library layer, delivery layer, compute layer). The other is much more horizontal in nature where, say, a vendor provides the compute layer but do so very broadly.

Sinclair contends that the latter, more decoupled topology is favourable in that it minimises the risks involved in breaking out one sub-optimally performing layer.

Conceptually speaking there would seem to be something to be gained from going with the vertical topoloy, mnimising relationships, points of contact building efficiencies. I also however understand Sinclairs concerns about the risk of a monolith.

Interesting discussion