Making sense of Salesforce.com
Some software, some risk
The Salesforce.com marketing pitch at the recent Dreamforce Europe was wearying at times but it is not complete nonsense. Chief executive Marc Benioff spent the first hour of his keynote reiterating what he has said 1,000 times before about "no software".
The "no software" slogan is deceptive, since Salesforce.com is a software platform. Benioff deliberately conflates multiple issues, including zero software deployment, cloud availability, and outsourced hardware maintenance.
The core of the model is multi-tenancy. One entity (Salesforce.com) takes responsibility for your hardware and application server. Multiple entities (including you) get shared use of those resources, financed by a subscription.
Benioff: cloud conflation?
Originally this was a single CRM application. Now it is called a platform (known as Force.com) since you can build many types of application on that platform. Is this "software as a service", or just a web application? It is both, especially since Salesforce.com publishes a SOAP API and claims to be the largest users of SOAP in the world.
I asked Adam Gross, vice president of developer marketing, whether the platform can also support REST. The answer is not really; you can create your own REST API to some extent, but authentication must be done through SOAP.
Developers can customize Salesforce or write their own applications (which is really the same thing) either by simple configuration, or writing code in APEX, which is a language created especially by and for Salesforce. Under the covers, I understand that Salesforce runs on Java and Oracle, (an upgrade to Oracle 10g is due later this year) so your APEX code ends up as Java byte code and queries Oracle. This is hidden from the developer, though.
One of the interesting features of Force.com is that you can develop entirely online. You can also write APEX code in Eclipse. There is a sandbox facility for testing. Another idea is to create mashups, which use web services to combine Salesforce applications with other web applications (just as Salesforce itself does with Google documents).
CRM and ERP blues
The next version of the Salesforce.com platform, available shortly, includes Visualforce, a tag-based syntax for creating a custom web user interface. Visualforce uses a model-view-controller pattern.
The Salesforce.com model has several attractions. It has inherent advantages. For example, hosted applications make more efficient use of hardware than on-premise servers. Another advantage is that rolling out a Salesforce.com implementation is easier than introducing something like SAP.
There is no hardware aspect to worry about, and the application is usable out of the box. Some of the customers I spoke to talked about failed or arduous implementations of SAP or Siebel systems.
Hands up anyone who's responsible for a system with a reasonable number of users that's never, ever had an outage?
Okay, look. I'm biased. I work in the on-demand field (recently moved into the cloud from the on-premise model) and I have to say, the kool-aid is actually pretty damn' tasty.
SaaS/PaaS isn't a panacea; there are certainly situations where it isn't the best approach, but they're the minority. Quite a tiny minority. I also saw Benioff's speech, and the part that struck me most was when he asked for a show of hands from small, medium and large organisations. Roughly the same number of hands showed for each category. How many platforms can you name that work this well for the entire spectrum of client companies from tiny startup to global multinational? That's some serious scalability.
And, on the uptime issue, Salesforce are happy to publish their uptime stats and planned outages (which, as much as possible on a spherical world, are kept outside business hours) for all to see. Probably because they're actually pretty encouraging.
Check 'em out yourself if you like: http://trust.salesforce.com/trust/status/
We all no they have outages, but the issue is scheduled downtime.
Yes 2am EDT may be fine for a US customer, but no good fo EU customers, who are finding that as they get into work, they have no systmes for a few hours.
Nice article, except for one line where you say
"For example, hosted applications make more efficient use of hardware than on-premise servers"
I think that's a huge generalisation and certainly not true, just because the hardware is on your premises or not.
You could argue that the efficient use of the hardware is no longer the subscribers problem, but of course it is, because if salesforce do a poor job you'll end up paying more.
The other problem is of course if the company goes tits-up or gets sucked dry by some legal argument you can't easily take your toys and play elsewhere.
Finally, they've got you by the short and curlys once you've migrated to their platform. At least with SAP you could stop paying for support while you migrate away. In fact you could stop paying full stop and fight them in the courts if they upset you enough, while you're application continues to run. With salesforce they can always pull the plug.