I’m attending the Cloudforce conference in London to catch up on what’s new with the Salesforce.com platform. CEO Marc Benioff was on good form, with a fun slide in his keynote presentation saying “Beware of the false cloud” – this was a jab at private clouds which he considers lack the advantages of a multi-tenanted public cloud platform like, you know, Salesforce.com. He has some justification – operating your own cloud is clearly a significant IT burden to carry – but that is the price of freedom. His company continues to report impressive growth. The theme this year is Salesforce.com Chatter, a Twitter-like service embedded into the platform, for which there are just-announced mobile clients (Apple iOS, Blackberry, Android coming) as well as integration with the web UI and programmable platform.
Chatter is reducing email usage for adopters, apparently; Benioff says by 40% in his own company. Another of its advantages (aside from general social media goodness) is that users cannot attach documents directly, but only links to documents – pass by reference not by value – which is a better approach to collaboration. Of course you can do this in emails as well, but people habitually do not. It makes you think – maybe the likes of Outlook should do this by default, saving no end of space in corporate mailboxes. Or perhaps we should just use Chatter instead.
But what about the developer angle, the Force.com platform that lets you build custom applications? I attended a session on the subject. There was a comment from partner Nimbus which caught my ear – the speaker said that they avoid writing custom Apex code wherever possible, and generally find ways to use the platform’s built-in features instead. His rationale: “You will have to live with that code for ever”. It is another angle on declarative programming, in which you declare your intentions and let some underlying engine transform them into actual code. The advantage is not only ease of development, but also that improvements in the engine can enhance the application without any need to rewrite code.
I asked what is new and what is coming in the Force.com platform. Chatter is one element; one of its key features is that applications can “chat” as well as individuals. Another theme is workflow tools, and integrating the technology acquired with Informavores, which is being rebuilt on the Salesforce.com platform as Visual Process Manager. In tune with the remarks from Nimbus, there is also an effort to reduce the need for Apex code and to offer guided steps that business users can apply without the need of a development specialist. Another focus is scalability – “people are starting to use the platform in ways that we didn’t think of” – which mean back end work to handle their demands. Finally, there is the joint development with VMWare called VMForce that lets you run Java with full access to the Force.com API.
Thanks for the good summary on force.com
When I read the comment on “generally find ways to use the platform’s built-in features instead… You will have to live with that code for ever” I had a visual back-flash of the good old BAPI development in SAP. SAP provided a language to create custom BAPIs that programmers could use to implement custom APIs, and advised companies to keep the base SAP functionality as standard as possible. Since custom code would ‘live forever’ the less custom stuff you’d add, the less risky future upgrades would be. The problem there was that this greatly limited the freedom of customization to keep risk under control (and reduce maintenance costs).
When you say that “The advantage is not only ease of development, but also that improvements in the engine can enhance the application without any need to rewrite code.” doesn’t this also mean that you will be dependent on the speed that salesforce makes those improvements? With this sort of declarative programming where you use the platform’s building blocks to create your custom apps, the main benefits of the custom app gets a little skewed. Yes, you can create custom apps, but you should try using what the platform already has, since extending it with your own code might make it difficult to maintain…
what’s your take on this?
Cheers
Michel