Is there beef behind SalesForce.Com?
I have been following Salesforce.com since its founding in the mid-1990s. Initially the company started by creating a contact management system which evolved into the sales force platform it offers today. Last month I attended a small dinner meeting in Boston hosted by Marc Benioff, Chairman and CEO of SalesForce.com, for some partners and customers. I met the Steve Pugh, CEO of CODA Financials, a subsidiary of Coda, a UK based developer of accounting software. I was intrigued that the company had built its new generation financial application on top of Salesforce.com’s infrastructure. In my next post, I’ll talk about Coda and why they made this decision. But before that I wanted to take a look at the Salesforce platform.
What is most interesting about Salesforce is that it intended to build a platform from day one. In my discussions with Marc in the early days he focused not specifically on the benefits of CRM but rather on “No Software”. If you think about it that was a radical concept ten years ago.
Therefore, It goes without saying that Salesforce has been a Software as a Service pioneer. For example, in June 2003 launched sforce, one of the first web services based SaaS platforms. It offered partners a published SOAP-based API. Rather than viewing Salesforce as an application, it views it as a “database in the sky.” It interprets this database as an integration platform. Likewise, from a customer perspective, Salesforce has designed its environment to “look like a block”. What does that mean? I would probably use a different term maybe a infrastructure blackbox.
Salesforce’s approach to creating its ecosystem has been incremental. It began, for example, by allowing customers to change tabs and create their own database objects. Next, the company added what it called the AppExchange which added published APIs so that third party software providers could integrate their applications into the Salesforce platform. Most of the applications on AppExchange are more like utilities than full fledged packaged applications. Many of the packages sold through the AppExchange are “tracking applications” for example, there is an application that tracks information about commercial and residential properties; another application is designed to optimize the sales process for media/advertising companies; still another package is intended to help analyze sales data.
But this is just the beginning of what Salesforce has planned. The company is bringing in expertise from traditional infrastructure companies like Oracle and BEA — among others. It’s head of engineering came from eBay. Bringing in experienced management that understands enterprise scalability will be important — especially because of Salesforce’s vast ambitions. I have been reading blogs by various Salesforce.com followers and critics. Josh Greenbaum, whom I have known for more than 20 years has been quite critical of Salesforce and has predicted its demise (within 18 months). He makes the comparison between Salesforce.com and Siebel. While any company that has risen as fast as Salesforce.com has will be a target, I do not believe that Salesforce.com is in trouble. There are two reasons I believe that they have a good chance for sustainability: their underlying SOA architecture and the indications that ISVs are beginning to see the company as a viable infrastructure.
So, what is the path that Salesforce is following on its quest for infrastructuredom (is that a real word — probably not). One of the primary reasons for my optimism is that Salesforce.com has a combination of traditional development through a procedural language it calls Apex that is intended to help developers write stored procedures or SQL statements. While this may disappoint some, it is a pragmatic move. But more important than Apex is the development of a standard XML based stylesheet interfaces to a service designed for use with Salesforce applications. This allows a developer to change the way the application looks. It is, in essence, the interface as a service. A third capability that I like is the technique that Salesforce has designed for creating common objects. In essence, this is a basic packaging that allows a third party to create their own version of Salesforce for its customers. For example, this has enabled Accenture to create a version of Salesforce for its customers in the health care.
But what is behind the curtain of Salesforce? First, Salesforce uses the Oracle database as a technique for serving up file pages (not as a relational database). But the core Intellectual Property that sits on top of Oracle is a metadata architecture. It is designed as a multi-tenancy service. Salesforce considers this metadata stack as the core of its differentiation in the market. The metadata layer is complex and includes an application server called Resin. The Resin Application Server is a high-performance XML application server for use with JSPs, servlets, JavaBeans, XML, and a host of other technologies. On top of this metadata layers is an authorization server. The metadata layer is structured so that each organization has a unique access to the stack. Therefore, two companies could be physically connected to the same server but there would be no way for them to access each other’s data. The metadata layer will only point to the data that is specific to a user. The environment is designed so that each organization (i.e., customer) has a specific WSDL-based API. In fact, the architecture includes the approach of access APIs through the WSDL interface. There are two versions of WSDL — one general and one for a specific customer implementation. If a customer wants to share data, for example, they have to go through the general WSDL interface.
Salesforce’s approach is to use XML based interfaces as an integration approach. It has used this to integrate with Google Apps. Salesforce has already begun partnering with Google around Adwords. This move simply deepened the relationship since both companies are faced with competitive threats.
The bottom line is that I think that Salesforce.com is well positioned in the market. It has an underlying architecture that is well conceived based on a SOA approach. It has created an ecosystem of partners that leverage its APIs and rely on its network to build their businesses. Most importantly, SalesForce.com has created an application that is approachable to mortals (as opposed to software gods). Companies like Siebel, in contract, created a platform that was complicated for customers to use — and therefore many purchased the software and never used it.
Salesforce.com is not without challenges. It needs to continue to innovate on its platform so that it does not get caught off guard by large (Microsoft, SAP, and Oracle) players who aren’t happy with an upstart in a market they feel entitled to own. They are also at risk from upstarts like Zoho and open source CRM players like SugarCRM. If Salesforce.com can collect more packaged software vendors like Coda to build their next generation applications on top of Salesforce’s environment, they may be able to weather the inevitable threats.