I last talked to Byron Sebastian just after Heroku was acquired by Salesforce.com and wrote these two stories: Why Byron Sebastian Still Thinks the Traditional Enterprise Software Model Is Dead and Is Salesforce.com Wrong to Love Ruby?. I also wrote an analysis of why Salesforce.com bought Heroku, Direct from Salesforce.com: Why We Bought Heroku.
This week's conversation focused on how Heroku has grown, what is driving the growth, Salesforce.com's strategy, and how Heroku develops its APIs. Sebastian said that the six fold growth in apps on Heroku is driven by the high demand for social, mobile, and real time apps. He said Heroku's customer base of hard core Ruby developers has been supplemented by a large amount of new enterprise and systems integrators.
He is quite proud of ASICS app for the NYC marathon as an example of an app that has broken new ground in combining lots of real time data, community content, innovative features. Heroku fits in to Salesforce.com's strategy of offering customers and partners a data layer (through Database.com), an API layer (Through Force.com, Heroku, and other platforms), and a UI layer as a platform for filling white space on top of Salesforce.com's core applications for sales force automation, marketing, and social media.
Heroku is a key part of the mission of Salesforce.com to support development of social, mobile, and real time apps. In the last interview, Sebastian pointed out that each new generation of applications usually is based on a language suited to the task at hand. Ruby is the language for social media and mobility, in his view. Sebastian said that while the Database.com offering was mature and provided one way to get at all your data in the Salesforce.com platform, the offerings in the UI layer were behind the data layer and the API layer and were a major focus of development.
I'm going to write more about the data layer in Forbes.com as part of a series of articles on cloud-based data integration. Sebastian outlined the way that Heroku designs and perfects APIs. The really have an elegant process for getting an API right through an agile development process so they don't have to revise it once launched, which really angers users. I'm going to write this up for ProgrammableWeb as part of my new column on API strategy. If you are interested in this topic, please check out my new book: APIs: A Strategy Guide.