Q&A

On-Demand Pioneer

Salesforce.com's Steve Fisher talks about development beyond CRM.

• By Barbara Darrow
• 02/01/2008

Salesforce.com Inc. burst on the scene nine years ago when it debuted the "rented" customer relationship management (CRM) and sales force automation applications that helped kick off the Software as a Service craze.

Since then it has opened up its portfolio with more development capability, starting with its API to allow developers to integrate its service with legacy applications, its Apex language and now its Visual Force user interface tools.

As senior vice president of the company's Platform Division, Steve Fisher leads the company's overall development platform efforts.

Now many Salesforce.com customers use those "Force.com" capabilities to write in-house apps that may have nothing to do with CRM. ISVs can also use the environment to develop applications to sell to 38,000 Salesforce.com customers. Redmond Media Group's former Industry Editor Barbara Darrow caught up with Fisher to find out more about life in the cloud as competitors like Microsoft ratchet up their CRM offerings, and the Force.com strategy going forward.

What is the Salesforce.com development tools and platform story?
Force.com is what we term our whole platform, and that's made up of a number of layers -- a database layer, an integration layer, a business logic layer, a UI layer -- all that you'd expect to build any application these days.

What's most unique about us is that we're "on-demand." In addition to having the business intelligence, database and other layers, we provide all the physical infrastructure that you need. We run all the servers, the networks, the storage; we provide disaster recovery and the backups; we do the monitoring and patch management.

We provide a higher-level abstraction that gives developers basically an on-demand database and on-demand application server. That allows you to build apps without having to deploy anything or run anything. That includes an on-demand development environment, as well as test environments and production environments, as well as the ability to package up that application and put it on our AppExchange directory if you want to sell it to our customers.

If I'm a .NET developer or manager at a company that's looking at an on-demand solution and I have C# skills, how much of that will transfer over to your environment?
Typically, if you're a .NET developer and you want to build an application, you have to think about what the sharing model is. What's the workflow engine? What are my international capabilities, what analytics, what kind of API do I want to expose? In Force.com, all of that is provided for you. Included are an analytics engine, a sharing model for security purposes, a workflow engine and an API that gets generated automatically from your data model. You get a Web Services API for free. All point-and-click. The vast majority, maybe 80 percent, maybe 90, maybe sometimes even 100 percent [of the application] is provided without coding. That's radically different from what most people are used to.

On the flip side, there will always be things you can't do with our point-and-click tools, places where the workflow engine will fall short, or the analytics engine falls short, or the ability to do custom business logic or UIs or page layout editing falls short, and that's where we provide things like our Apex programming language, which is a C#-like language. The syntax looks the same. The only real difference is that the database is sort of first class in the language.

For example, instead of sending a string to the ODBC driver, saying 'select ID comma name from opportunity' or whatever, you're actually coding against the database as well as creating your loops and conditions and variables and classes. It's very C#-like syntax [but] the database is first class and you use that to deliver that extra bit of functionality that isn't in the point-and-click tools. [It lets you do] things like custom triggers on the database: When a record gets created, updated or deleted you can now do custom code that fires as well as our standard code that executes from our workflow engines or standard transactions.

Similarly, we just introduced our Visual Force "user interface as a service" language for when our page layouts don't do all you want. Or if you don't want to use client-side technology like AJAX and Flex -- which we've supported for years -- you can use server-side UIs. It's a combination of a tag-based language similar to an ASP kind of language for .NET developers backed by Apex for custom user experience logic.

Is there a similar easy transfer of Java skills?
Maybe this is heresy, but my experience is there's not a lot of learning curve going back and forth from C#and Java, so Apex is designed to meet the needs of that style of developer: people who know object-oriented C-, C++-style programming. It's more like that style language, compiled languages, as opposed to Python, Perl. And obviously it's great for people with relational database knowledge. It's probably easier to program databases in our language. If you refer to a call that doesn't exist, you'll get a syntax error, not a runtime error, for example.

Your infrastructure runs on Oracle databases, so does a developer need to know the niceties of Oracle programming?
One of the hallmarks of our platform that differentiates it from other on-demand, quote-unquote platforms like what Amazon provides is we provide a higher level [of abstraction]. Yes, we use Oracle under the hood, Java under the hood, but no developer or customer ever sees that. We could replace Oracle with MySQL and no one would know. Or replace our Java application servers with .NET servers. We provide a higher-level abstraction where we define what database means using point-and-click tools to define tables and columns without having to go down to Oracle's command line for creating tables and columns. You just use point-and-click tools or you can define your schema in XML and we define that into an underlying definition that Oracle and Java understand.

Here's why that's important: In most traditional scenarios, if you go from .NET 2.0 to 3.0 or from Java 5 to Java 6 or Oracle 10 to 11, that's typically not a zero effort -- you may have to do a lot of testing and re-code some stuff.

On our platform, because we provide that separation between underlying infrastructure and what the developer sees, every release we do is a completely seamless upgrade. No code ever breaks. No customizations, no schemas ever break, no integration ever breaks -- and we do three to five major releases every year. You get the new functionality but your old stuff works.

Nothing ever breaks? Never say never.
That's our commitment. Now, I won't say we've never had a regression. We do a few things to stop that. We version every release, so if you have some Apex code written to one version or some API code written to one version, we build in compatibility layers for that version. So we know your code is version 10 and we'll execute that in version 10 even if we're 11. We have 50,000 automated tests that give us confidence in maintaining compatibility.

It's possible that we'll have a bug in the version 10 compatibility layer. That's possible -- we'll find that out and test it out. Those tests run every night.

I wouldn't say we've never had regressions or bugs, but from an architectural point of view, because of our use of versioning and the compatibility layer, there's no reason that we can't maintain that compatibility intact.

What's the model here for a developer who wants to develop on Force.com? Do they pay you a subscription fee or do you get a piece of the rental?
For an IT developer within one of our customers who wants to build an in-house app, maybe a customization of their Salesforce.com CRM application or something totally different, the model is that the users are subscribers to our service and pay the subscription fee. We have a reduced price for users who are only using our platform capability and not our CRM. That's for people within [organizations] building apps for themselves.

If you're an ISV and want to sell an app to our customers, then those users have to be subscribers and one customer can have a mix of both [types of applications], but those customers must be CRM or platform subscribers. The ISVs themselves don't pay us anything as long as users are paying for the platform -- the ISV can charge whatever they want on top of that. And they get all the revenue.

If you look at developers coming into your environment, are most coming from Java or .NET?
The earliest opportunity we had for developers was in 2003 with our APIs -- our Web Services API, which is automatically generated from a schema that gives access to data store and the Force.com platform from outside. It's primarily used for integration.

Of those who use our API about 50 percent are from Java and .NET, and of that total they are 60 percent .NET and 40 percent Java. The other 50 percent [overall] use Perl, PHP, Ruby, some crazy stuff. So it's an extremely diverse set of people.

For people who are building natively on our platform using Apex and Visual Force and workflow and analytics, the majority are Java and .NET, but again there are people from all walks of life.

How large a market can developers target if they join your world?
We have just over a million subscribers, and that's in over 38,000 customers, or companies that have bought our CRM product. [There are] a lot of free guys also, but the million users in 38,000 enterprises are paying.

"Of those who use our API about 50 percent are from Java and .NET, and of that total they are 60 percent .NET and 40 percent Java." Steve Fisher, Senior Vice President, Platform Division, Salesforce.com Inc.

Microsoft is prepping its self-hosted CRM and already offers partner-hosted and on-premise CRM. Why should developers look at Salesforce.com when Microsoft provides all three distribution models?
Titan is a CRM product. At one level, we have a great CRM application and our platform is used to customize and integrate it. But it's also used for things that have nothing really to do with CRM.

One thing, I think, is the Microsoft-hosted version doesn't exist yet. It's hard to bet on something that doesn't exist.

We're proven with a million subscribers, we do 135 million transactions a day and a transaction is requested from the user either as an API call or a page view. Over 50 percent are API calls, so we're doing 65 million Web services calls a day. There's a lot of proven scalability and performance. Each request is served in an average of 200 milliseconds. [We have] proven ability to go from small companies to large customers. We have Merrill Lynch with 25,000 subscribers, Citibank with 30,000. Our biggest is Japan Post with 60,000 subscribers and that's only as a platform -- they're not using our CRM.

Titan is also not focusing on being a platform. [It doesn't] have the tools we have. It's where we were three, four, five years ago.

But Microsoft will pitch its whole stack, plus CRM.
It'll be interesting. All the major players -- Oracle, Microsoft, SAP -- are saying, 'Yes, we have to go on-demand' and saying they have delivered. Unfortunately for the industry they haven't done a very good job. Microsoft hasn't delivered yet.

We think that's validating that on-demand is important for every developer within the enterprise or as an ISV. There are tremendous cost and time benefits for developers in this model and whoever has the best technology ought to win.