SmoothSpan Blog

Phil Wainewright’s Digging Beneath Salesforce.com’s Platform Hype is all about how there didn’t seem to be much beef involved in the long series of keynotes about Force, the new name for the Salesforce platform.  Phil concludes that this had to be done because Salesforce needs to convince the Thought Leaders out there that it is more than just a CRM company.  I take away a different conclusion about the lack of substance.

As LucidEra’s CEO Ken Rudin says:

Trying to move from on-premise to on-demand is not just an exercise in relocation of software. On-demand is much more than that. It’s about making a solution that is easy to set up and easy to use.

The italics are mine.  For “easy to set up”, let’s substitue “easy to customize”.  Rudin waxes eloquent about how hard conventional software like Business Objects and SAP is to customize and how this difficulty is not a function of which data center the software is located in.  If you take a product that’s hard to customize and host it, you do not have SaaS, you have SoSaaS (Same Old Software As A Service).  That ain’t all bad, and it is better than conventional software for a variety of reasons, but it isn’t what we really wanted which is to radically improve the platform concept by making it a lot easier.

My problem with Salesforce is I am having a terrific amount of trouble seeing Force as any easier a customization mechanism than what the SAP’s and Oracle’s have to offer today.  Come to that, it’s hard to see it as an easier platform for creating new applications either.  Don’t take my word for it, have a look at the AppEx Language Reference.  That book gives the following description of the advantage offered by using AppEx versus conventional languages:

These client-side programs, typically written in Java, JavaScript, or .NET, grant organizations more flexibility in their customizations. However, because the controlling logic for these client-side programs is not located on Apex platform servers, the clients are restricted by:

• The performance costs of making multiple round-trips to the salesforce.com site to accomplish common business transactions

• The lack of transactional control across API requests

It goes on to say:

Using syntax that looks like Java and acts like database stored procedures, Apex Code allows developers to add business logic to most system events, including button clicks, related record updates, and custom s-control displays.

So, we get a bit better performance and we can make multiple API requests within a single transaction. All this is done using a language that looks like Java.  Folks, I have to tell you, that isn’t revolutionary and the esteemed On-premise Big Boys will tell you their platforms do the same.

VisualForce offers very little new as well.  First of all, it isn’t a visual tool, it’s a tool for creating visual changes.  It uses a tagging language not unlike ASP or JSP to make those changes.  It is cool that you can open a little source window below your app when working on it, and it’s great that the look and feel of Salesforce can finally be customized, but once again, this has all been available for the other players for a long time.

Force confirms what a lot of folks in Silicon Valley have been saying for a long time: the tremendous success of Salesforce.com is part their own stupendous efforts, and part that their domain is tailor-made for SaaS.  It is tailor-made because it requires little customization.  SFDC got to 900,000 seats without much of a platform, and they’ll get much further as well.  Their platform is assured a certain amount of success for those who wish to use it as a way to build more components to tie to Salesforce or as a way to extract sales leads from the vibrant Salesforce ecosystem.

Delivering an order of magnitude simplification for customization is extremely difficult to do.  Lots of innovation is required.  Most SaaS vendors opt for just not letting their users perform much customization.  It’s surprising how often this works.  It gives customers a reason to accept “no” and keep their project simpler.  This gets them value that much sooner and often the customizations are never missed.

Whether the Force platform becomes a major strategic driver by being the foundation for many applications that have nothing to do with Salesforce will be a function of how well the hype works and how quickly they are able to add functionality to give that platform the advantages it lacks today.  What they won’t have going for them is the natural domain:  platforms are all about customization and just hosting them isn’t enough to make them compelling.  That’s not a bad thing at all.  Owning a platform that works around CRM and adjacent spaces is still extremely valuable.  It just doesn’t catapult Salesforce into the position of radical expansion beyond CRM.