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.
As the Salesforce.com customer base grows - it is currently 41,000 customers and 1.1 million subscribers - it becomes a more attractive target for third-party software vendors. You can market a custom Salesforce application through the official AppExchange, or create your own on-demand application and sell it to your own subscribers.
What, then, are the main reservations? Well, Benioff apparently has not read Wired editor-in-chief Chris Anderson's essay on "Free". As a customer, you have to be willing to pay Salesforce.com a per-subscriber annual fee forever.
As a third-party vendor, you have to be willing to pay Salesforce.com a proportion of your revenue forever. Custom objects, custom language, custom UI tags: it won't be easy to move away. This is proprietary lock-in reborn for the web.
Second, if you use any hosted application platform you lose control. If you find yourself needing some new feature that the platform doesn't implement, you have to ask nicely and wait in hope, or find some way to implement it using a mash-up or APEX code.
If you can't wrest the performance you want from the platform, you can't upgrade the hardware or introduce a stored procedure: it is what it is. As an example, I heard users complain that the security system is insufficiently fine-grained. Improvements are coming, but they have to wait.
Third, you have to trust Salesforce.com with your data, and trust it to stay available. If you run your business on Salesforce.com, and it goes offline, you may as well all go home. Now, arguably the guys at Salesforce.com will work as hard or harder than your in-house team to keep systems up and running, and in most cases have more resources to work with, but nevertheless, it is a matter of trust.
Fourth, this is mainly a web-application platform, though you can make offline applications or desktop applications using the API. The core user interface is functional rather than attractive, and I saw lots of flashing screens and browser messages saying "waiting for na5.salesforce.com".
Visualforce AJAX components will help. In practice, though, business users do not care that much provided they get the results they want. Still, it's a point worth noting. Microsoft argues that "software plus services" delivers a better user experience. The rejoinder is that "software plus services" removes key benefits of the software as a service model.
In the end, it comes down to a business case. It should be possible to sit down and calculate whether a move to Salesforce.com for some part of an organization's IT provision will cost money, or save money. The people I spoke to at the show though it worked for them.
This article originally appeared in ITWriting.
Copyright © 2008, ITWriting.
A freelance journalist since 1992, Tim Anderson specializes in programming and internet development topics. He has columns in Personal Computer World and IT Week, and also contributes regularly to The Register. He writes from time to time for other periodicals including Developer Network Journal Online, and Hardcopy.