There are so many things that I could write about Dreamforce that I have had to quickly conclude that it won’t all fit into one column, and I will be writing about it for some time to come. I bet I am not alone. Here are some ideas that I thought were important, however.
The big announcement was Apex, Salesforce.com’s programming language that will soon enable developers to customize any aspect of the on-demand service or applications built on it.
What Apex Is
Apex reminds me of a mini-computer programming language. The minis were never known for slick displays. Most of the applications I used ran in teletype mode, meaning that a line of text scrolled up from the bottom of the screen to prompt the user to do something. The programming language was really a data manipulation language that let developers control flat files or hierarchical databases to add, change, or delete data items or whole files. SQL came along later and did the same thing for relational data.
At its core, Apex is like one of those languages. You are not going to use Apex to build a CAD system or to build the next great UI. Frankly, that’s what other parts of Salesforce.com’s development platform are for. In the new Salesforce.com paradigm, you use graphical tools to build applications that behave in a well defined way within the on-demand service. The programming language is only used when you want to alter the behavior of the system as it relates to data.
So, for example, you might build a screen with a standard button that executes specific functions, but the functions supplied do not meet the full needs of your organization. In Salesforce.com’s world, Apex would be used to customize the functionality associated with the button. Apex is therefore rather limited, and that’s a good thing. Developers can use Apex to change the behavior of their applications relative to data, period.
Salesforce.com tells me that the changes will be associated with the application and upgradeable along with everything else when Salesforce upgrades the service. They tell me that developers will not be able to build things that could crash the service. It sounds logical, but the proof of the pudding is in the eating and that means wait until Q1 ’07 to see it live.
What Customization Means to On-Demand
Salesforce took its on-demand service about as far as you can go, given there was no facility for true customization of the applications. Until the Apex announcement, you could extend applications, build small applets or even large applications, but you had to accept the limitations imposed by an environment that, while it let you configure to your heart’s content, wouldn’t let you do something truly custom. Now you can, and that is the difference, and it is significant.
When Apex is released, it will provide the missing piece that on-demand needed to be fully competitive with traditional application development, and that will have profound implications for the industry.
As with every other aspect of on-demand, it will represent an order of magnitude reduction in the cost of application development. It means more people will be able to afford to build and sell applications commercially, and it means that more new applications will enter the market. When costs drop like that, the existing order gets shaken pretty violently.
Just as the rapid acceptance of the World Wide Web layer on the Internet spawned the dot-com boom, this development could spawn a similar but less explosive boom. You might call it an echo of the original boom in the same way that the children of the baby boom generation carry that same designation today.
Making a Case for On-Premise
Order of magnitude cost reductions also pose an interesting problem for established, traditional software companies. If comparable functionality can be built and delivered on-demand for a small fraction of the cost of traditional business applications, then conventional software companies are now going to have trouble explaining how they deliver value at much higher price points. There might be valid reasons for sticking with expensive on-premise solutions, but justification will need to be made on a case-by-case basis to increasingly skeptical boards of directors who will be looking to redeploy assets within a budget.
There are two responses that I can see conventional software companies offering. The first would be to deny the importance of the announcement. It makes a certain amount of sense to deny the importance of Apex and on-demand — after all, the only thing we have so far is an announcement. We need to see the product. But if the product arrives as advertised, denial will not be an option anymore. Companies with vast investments in enterprise software will need to scramble to make their products into on-demand solutions. That won’t be quick or easy, and enterprise customers won’t likely want to make a wholesale swap overnight, so look for a transition state to exist that could last for a decade or more.
The example I always look to in a case like this is mainframe computing. Mainframes have survived from the green-screen era, through client-server, and well into the Internet era, but the direction of their market share has been down for years. Conventional software will travel a similar path because some applications are simply too big to move, or their owners are in the middle of the depreciation cycle and can’t abandon the investment.
On the other hand, and this is the scary part, the decline of on-premise software might mirror the decline of mini-computers, which came to a faster and more violent end.
But Wait, There’s More
Perhaps the most far reaching announcement was the fact that Salesforce.com is opening an incubator for emerging companies. There were 157 partner vendors on the Dreamforce show floor and many of the applications on display were pretty cool. All of the vendors had built on-demand applications that enhance the functionality and usability of the primary service. Each of those companies represents an investment in capital, other resources, and time for entrepreneurs with good ideas that they want to bring to market. When Salesforce.com opens its incubator (in a former Siebel building on Route 101, ironically) it will effectively move some of that entrepreneurship in-house.
The importance for entrepreneurs and competition alike is that an incubator industrializes innovation and new ideas, and solutions come pouring out rather than dribble into the economy. The pace of innovation in on-demand is about to accelerate.
The incubator sounds like a cool idea. If you can come up with US$20,000 for a year, you can get your own cubicle, free access to the Salesforce.com on-demand development tools, and you can try to make your dream come true. Salesforce.com is not stopping there, either. The incubator will also offer emerging companies help with things like capital formation, marketing strategies and more. I expect the incubator will be one of those things that drives adoption of the model as well as a bunch of new ideas.
At the beginning, I said I would have to write more than one piece on Dreamforce and I plan to. This piece is already too long and we’ve only scratched the surface.
Denis Pombriant runs the Beagle Research Group, LLC, a CRM market research firm and consultancy. Pombriant’s research concentrates on evolving product ideas and emerging companies in the sales, marketing, and call center disciplines. His research is freely distributed through a blog and Web site. He is working on a book and can be reached at firstname.lastname@example.org