salesforce.com, force.com, database.com, data.com, heroku.com — notes and context
As previously noted, I attended Dreamforce, the user conference for my clients at salesforce.com. When I work with them, I focus primarily on database.com and related businesses. I’ve had to struggle a bit, however, to sort out the various pieces, and specifically the differences among:
- salesforce.com. This is the parent company, and the runaway leader in the SaaS (Software as a Service) enterprise application market, especially in the area of CRM (Customer Relationship Management).
- force.com. This is salesforce.com’s application development stack split out for other SaaS vendors to use, both inside and outside the CRM segment. It can be referred to as a PaaS offering (Platform as a Service). force.com relies on a proprietary salesforce.com language called APEX, which has a strong stored procedure/ database trigger orientation.
- database.com. This is the database part of force.com, spun out separately in general availability as of Dreamforce two weeks ago.
- data.com. Also launched at Dreamforce (and based, if I understand correctly, on an acquisition), this is a provider of 3rd-party data you might use as inputs to your CRM systems.
- Heroku. Another salesforce.com acquisition, Heroku is in essence a PaaS competitor to force.com. Heroku is focused on Ruby and Java, and supports a number of DBMS, SQL and NoSQL alike.
- AppExchange. This is a marketplace for things designed to integrate with salesforce.com (and perhaps also apps built on force.com). The latest claim is that there are 1200+ AppExchange offerings.
- The complete set of SaaS apps built on force.com. A 2008 white paper refers to 47,000 organizations being “supported” by force.com. Recently I’ve heard a figure just under 100,000. I’m not clear as to what that metric measures — aggregate users of SaaS apps built via force.com? Clearly there are a lot of SaaS apps built on force.com, with actual customers, but I don’t know how big “a lot” is. (Perhaps a salesforce.com person could chime into the comment thread with some clarity.)
The pricing for force.com and database.com is clearly designed for enterprise SaaS applications whose users will be inside customer organizations. If you want to do something public-facing, prices are prohibitive without a special deal. That’s the bad news. The good news is that salesforce.com says, publicly and privately, that it’s indeed open to cutting such volume pricing deals.
When I talked with CTOs and the like at some Dreamforce-exhibiting SaaS vendors, on the whole they seemed very happy with force.com. The one repeated complaint was that force.com imposed unpleasant rate limits (e.g., number of API calls). Working around those limits involves unnatural acts of coding, phones calls to helpful salesforce.com staffers to get the limits raised, or both. When I talked with salesforce.com cofounder Parker Harris, he seemed painfully aware of the problem, and indicated that relaxing the limits is an important technical goal.
The other force.com weakness I uncovered was expected — while it may be great as long as your application matches its implicit assumptions, there are some things it can’t easily do. This has been a recurring issue since database-oriented 4GLs (Fourth-Generation Languages) came around in the 1980s. For example, one firm wanted a Flash UI — I’m not sure why — and went outside force.com for that part of the application.
Related link
Comments
2 Responses to “salesforce.com, force.com, database.com, data.com, heroku.com — notes and context”
Leave a Reply
[…] salesforce.com, force.com, and database.com use exactly the same database infrastructure and archite…. That’s the good news. The bad news is that salesforce.com is somewhat obscure about technical details, for reasons such as: […]
[…] salesforce.com, force.com, database.com, data.com, heroku.com – notes and context (dbms2.com) […]