After writing Is Salesforce.com Wrong to Love Ruby?, based on public statements and my own knowledge of Ruby, I had the pleasure of interviewing Ariel Kelman, Salesforce.com’s VP of Product Marketing, and Byron Sebastian, CEO of Heroku. I tell Byron’s story in the first of this pair of articles, Why Byron Sebastian Still Thinks the Enterprise Software Business Model Is Dead.
In this article, we use the Heroku acquisition as a way to reimagine what Salesforce.com is all about. The crux of what I have to say is this: Salesforce.com accepts the points I made in my original article.
The company doesn’t expect that Ruby developers will suddenly focus on business applications. Salesforce.com also admits that its core object model, which is focused on people, opportunities, tasks, and related concepts, covers a smaller amount of business activity than those offered by NetSuite’s SuiteCloud platform or by SAP Business By Design.
Salesforce.com accepts these points because it doesn’t see my criticisms as weaknesses. The play for Ruby is ahead of the current business market.
Ariel Kelman points out that Ruby use is driven by startups and marketing departments, which are creating sites and applications that have the need to go farther and faster and to be more social and mobile than traditional platforms used by IT.
Kelman argues that eventually IT departments will recognize the power of Ruby and use it. When they do, Salesforce.com will have the most business-friendly way to use Ruby, one that delivers Ruby as a Platform-as-a-Service, but which is connected to a mature ecosystem of business software components like Chatter, Force.com, and Database.com--unlike something like Engine Yard, another Ruby platform player.
And, of course, a Ruby offering that has millions of users of its core application, Salesforce.com, who know how to use applications in the Salesforce.com style. Ariel Kelman says expanding the size of Salesforce.com’s object model is not a goal.
Kelman argues that it is far better to create exactly the object model you need rather than to start from a standard object model, no matter how vast it is. Kelman points out that no standard model will be exactly what you want for most applications.
The argument here is that the value of a standardized, reusable object model is overrated. Salesforce.com has an object model for people, opportunities, tasks, and various other CRM related concepts. The approach Salesforce.com has taken is to make it easy to add objects to its object model and then to create easy-to-use, configurable software around that model using the rest of the Salesforce.com and Chatter platform, customized by code using Force.com or Ruby.
When I took a step back and thought about the implications of Kelman’s arguments, I realized that Salesforce.com was playing a fundamentally different game than the other major software companies. They are essentially ceding development of specific applications to their ecosystem.
The name of the game at Salesforce.com is platform-level lock in, both for developers seeking to create applications and for IT staff seeking to fill whitespace with custom applications.
Kelman puts it this way, "Our approach at salesforce is to give developers choice, so they are open to choose the technologies to build the apps their end users need. Our core Force.com technologies are powerful options for IT and ISV devs seeking to quickly build and deploy enterprise cloud applications. This is why we partnered with VMware to create VMforce, because developers were asking us for an enterprise-grade Java cloud platform. And why we recently acquired Heroku, and announced Database.com."
The ins and outs of this strategy start a whole new discussion, not one we will address today. There you have it in a nutshell; for the extended disco version, read on.
What Salesforce.com Used to Be About
I’ve been using, watching, and writing about Salesforce.com for many years. My analysis of what the company has accomplished has been published in several of my Forbes.com JargonSpy columns, listed at the end of this article.
My analysis is as follows:
- The first major accomplishment of Salesforce.com was proving that the SaaS model can work at scale. Unlike other analysts, I reject the notion that the multi-tenant architecture is the only way to do this. Multi-tenancy may be the way that Salesforce.com chose to implement the SaaS model, but it is a sideshow with respect to the most important audience, the end-user
- Salesforce.com’s biggest accomplishment, which I assert is the key to making SaaS work at scale, is not the architecture of the application infrastructure, but the easy configurability of the software. All complicated systems have to deal with the problem of the airplane dashboard, which is the challenge of allowing hundreds of settings to be monitored or changed. Salesforce.com conquered this problem. People who are not experts can make changes such as adding a field or adjusting a pick list. People who are moderately skilled can customize the software in significant ways. I don’t know of another business application that meets this level of ease of use. There are many other design and engineering achievements, such as the meta data model and the ability to version APIs, but configurability is the crowning achievement
- Salesforce.com’s smartest decision was focusing on CRM as its first application. Most people come to CRM with a similar set of requirements. The flow of leads to contacts to opportunities to orders with the ability to attach tasks all around and send email based on templates to one or many people is a common pattern. Of all the possible CRM functionality, most businesses want the same 20 percent. For ERP, most businesses want a different 20 percent. Selecting CRM also benefits from the way that small- and medium-sized businesses focus on people. ERP is not the most important app in most smaller companies; the apps that track clients are. If Salesforce.com had focused on ERP, it would never have gotten the traction it now enjoys. This focus on people made Salesforce.com the de facto center of the universe for social media applications. Every single one of the large vendors of social media suites that I have ever seen includes an integration with Salesforce.com in their demonstrations
- Salesforce.com was also wise to create its own custom development language, Apex, which can be considered a Java hybrid. The company realized that to perform at the highest levels, it would need complete control of the way that the programming language was rendered into executable code. I don’t know if this was forced on the company or if it was a design decision from day one. I will try to find out in subsequent research
- Finally, exposing a rich API has made Salesforce.com a hub not only for social media but also for marketing applications. All of the advanced marketing technologies like Eloqua and Marketo use Salesforce.com as a hub for customer information. Many of these technologies use Salesforce.com as a way to talk to each other
So, for all these reasons, Salesforce.com can charge and protect a high per-user license model compared with competitors such as the open source based SugarCRM, which covers much of the same functional footprint, but has a much smaller market share.
Why Salesforce.com Doesn't Expand its Data Model
With that background in mind, let’s look at why Kelman doesn’t care about the size of the object model that Salesforce offers. I haven’t figured out a way to systematically measure functional footprint, but when I do, I would love to compare the SAP Business Suite, Oracle’s collection of business-focused applications, special purpose applications like Talend or Workday, and Salesforce.
What I expect to find is that SAP is in the lead in terms of the breadth of its data model and the automation built on it. Oracle will, I suspect, have lots of coverage, but a less coherent whole.
The special purpose applications will be narrow in breadth of data model and deep in functionality. The central question is the value of standard business applications. The value in my view rests on configurability.
The easier it is to configure an application to make the standard functionality match your needs, the better and more valuable the business application is. What we don’t know is if it is possible to be both configurable and standard.
Salesforce.com wins the configurability race and has chosen not to focus on creating standard business software. The companies in its ecosystem are doing that.
For example, FinancialForce.com is an ERP system based on Force.com. Salesforce.com has invested in this product, and the reasons why will make a good story for later. But so far, the Force.com applications are niche players, not general purpose apps.
SAP and Oracle are more powerful than Salesforce in terms of standard functionality, but to configure these applications, you must be an expert. SAP is working hard to change this and has offered some genuine innovations in configurability in its SAP Business by Design SaaS-based Business Suite.
Oracle wants to change the conversation in a way that gives up on creating a comprehensive unified business suite. Oracle has lot of apps, many of which overlap. Its message is essentially pick what you want of our apps, use the other ones you have, and use our Fusion integration technology to integrate the whole shootin’ match into coherent business processes.
I’m not ready to give up on the promise of standard business applications for areas where requirements are well understood and have strong commonality. What we may be learning about software is that this space may be smaller than first realized.
This is exactly what Salesforce.com is betting on. From talking to Kelman, I got the impression that Salesforce.com figured this out after considering where to go from CRM. I’m guessing here, but I suspect that after the cash really started flowing and Salesforce.com could move in any direction it wanted, it evaluated plans for extending its CRM application to other areas and decided to skip it in favor of building out Force.com. I would guess that this decision was made somewhere between 2002 and 2004.
As I say in my original Forbes.com article, most money spent on business software is spent on niche applications, with standard software accounting for about a third of total spending. Salesforce.com’s strategy is to focus on making it really easy to fill white space with SaaS-delivered, configurable software featuring whatever data model you choose to create.
For developers, the play is to use Force.com to make products. For IT departments, the play is to use Force.com as a platform to fill white space with custom apps that can be quickly adapted into strategic and differentiating assets.
And once you decide to do this, you will be hooked, and it will be hard to live with a less satisfying environment. Salesforce.com used the act of building SaaS-based, configurable CRM to understand the new world of software, one that over time may actually kill the enterprise software business model.
Salesforce.com is a SaaS-based application platform company. So, if we think of Salesforce.com as a stack with a CRM application on the top half and the platform on the bottom half, we see that the company’s focus is primarily on the bottom half.
An arrow leading out of CRM goes to the ecosystem, which is responsible for creating standard business software on the Salesforce.com platform. Despite its token investment in FinancialForce.com, Salesforce.com is out of that business.
Chatter might be considered standard business software, but I would call it a platform for social networking rather than an application. I have a modest proposal to reflect this vision of Salesforce.com. The company should change its ticker symbol from CRM to CDP, that can stand for Comprehensive Development Platform or Cloud2 Development Platform. Force.com, Database.com, and now Ruby are all part of where the company is focusing, which brings us back to the real reason Salesforce.com bought Heroku.
The Real Reason Salesforce.com Bought Heroku
Salesforce.com bought Heroku as a form of developer marketing and as an insurance policy. The developer marketing angle is aimed at getting the energy of the Ruby development community focused, to the extent it can be, on using the Salesforce.com platform and possibly on joining the ecosystem of developers of niche business applications.
Salesforce.com isn’t expecting this to happen overnight, but it is expecting to get some flow of attention and some new applications out of it. It also represents a challenge to NetSuite’s SuiteCloud and SAP Business By Design.
Salesforce.com hopes that Ruby support makes these platforms seem old. Heroku is an insurance policy against Salesforce.com having its platform ever seem old. It is only the first payment. Other payments will come when a plausible general purpose mobile app infrastructure comes along.
I would check out EachScape if I were at Salesforce.com. I also think that app platforms are going to have to deal with big data and machine data before too long.
So it would not surprise me to see a company that has some sort of functionality that has the ability of Splunk or Pervasive’s DataRush to explore and capture important insights and events in machine data. The platform will eventually need better business intelligence capabilities.
QlikView’s ability to create dashboards fits right into Salesforce.com’s platform approach. The world is becoming more real time. Operational intelligence will become a big market, and I suspect that Salesforce.com will eventually add a complex event processing engine’s ability to create networks for pattern and event recognition.
Salesforce.com may choose to build some of this stuff instead of buying it. But Salesforce.com will not be caught napping and will not add something to its platform that decreases its signature configurability?
One warning sign that Salesforce.com should take note of is Google's experience in promoting Python. Google App Engine could be considered similar to Heroku. It was originally powered by Python, which may not be as sexy as Ruby, but has an enthusiastic developer community.
Google doesn’t have many things that Salesforce.com has, such as a large community of business application users and a proven model for making easy-to-use configurable software, but it does have its own Database.com equivalent. But the wave of exciting Python-powered applications written on Google App Engine has yet to impress us.
The other point to take note of is that we are not living in a world with a vacuum of relevant technology for cloud, mobile, and social media development. Java filled a vacuum for a language to handle network aware distributed applications. Ruby is not filling a vacuum as much as trying to win a race, a long race in which all the other players never really give up.
What a Reimagined Salesforce.com Means for CITOs
While Salesforce.com has made a fortune by allowing business to run end-arounds the IT department and buy software directly, the company’s success in the future depends on CITOs. To have the widest, deepest, and longest lasting market, Salesforce.com wants to convince CITOs that the world is now safe for software development again.
Whenever a new need comes up, using a platform like Salesforce.com should be considered to fill white space. When CITOs look at the price tag for this approach, the battle will begin.
Will it be cheaper to pay for Salesforce.com user licenses, to develop a competency in some other collection of cloud-based infrastructure, or to use more traditional development tools?
There is a lot to think about here. Already Salesforce.com has achieved one thing. It is extremely interesting to be a CITO today given the challenges Salesforce.com is throwing at us.
JargonSpy Columns on Salesforce.com
Salesforce.com's Secret Sauce explains how configurability is the most important achievement of Salesforce.com.
The Enterprise Software Race suggests that Salesforce.com will seek to expand its functional footprint and enable others to do so with its platform. A New Open-Source Model For SaaS points out that open source provides an interesting migration path from SaaS. The Great Software Showdown explains that vendors face tough choices in deciding on a delivery model.