Not being a developer – my comments come from a business perspective. That might be anathema to most developer purists, but I sense that what we’re seeing with high level PaaS’ like force.com (and, for that matter, the other SaaS-based highly flexible platforms, is an uber-democratization of development that will prove even more revolutionary for developers and business than IaaS has been for operational teams within an IT organization. That’s the reason I started differentiating application PaaS (aPaaS) from infrastructure PaaS (iPaaS)

Let’s see how that works. With cloud, organizations no longer need to think about procuring, racking and stacking servers. Rather they obtain their server needs on a utility basis from a cloud provider (in the case of the public cloud at least). CapEx is removed, the need for large operational teams goes, and all of a sudden the ability to acquire server time moves from central IT, down to tech teams within a business unit. All fine and good so far, but let’s get to the next stage, PaaS.

In the old days, a business that wanted to, for instance, create a custom application that integrated with its ERP or CRM, would have needed to engage a developer with a deep understanding of both development languages and the hooks into the software package being integrated with. With aPaaS that is no longer the case. The platform itself is built upon the application and hence is already integrated with the core data the organization is trying to use. The language is easy enough for most business people to use and hence they do, creating applications at will.

This concept, of aPaaS being the catalyst for massive democratization, was well articulated in a recent post that went out on a significant limb by saying that “Force.com is the next Visual Basic”. Rather than an insult however, the author stresses that reactions to force.com replay many of the those that went alongside the introduction of VB a couple of decades ago:

• Most professional C++ programmers dismissed it. VB was a “toy language” or a “glue language” for components – not for serious software development.
• Increasing number of software engineers embraced the language because, to put it simply, when it came to desktop applications you could be an order of magnitude more productive in VB than in C++. It may not have had the stature and features of a “real” professional language, but it sure was profitable to work in it.
• VB was easy enough for anyone to use, so everyone did. Doctors, lawyers, students – millions of VB developers sprang up out of nowhere and wrote a lot of code. Much of it was very bad code, but that’s what happens when a bunch of amateurs get in the game. Entire book, magazine and training industries grew up to help them get better, and many of them did and built entire careers around the platform.

The very reason VB was productive is important to remember in light of the rise of PaaS generally and these high level aPaaS’ in particular. The original post detailed the traits that force.com shows that were so starkly on display at this year’s DreamForce:

• A web based GUI environment that provides a high level of abstraction for developing real applications that seamlessly integrate core features like database, email, reporting, the web, chat and mobile.
• An environment that lets you do a great deal without code, but provides the language and “hooks” that allow serious programmers to go much farther.
• A flood of non-programmers who are using the environment to solve real problems, and who are stumbling into actual programming.
• Lots of truly awful code being written, so there’s a huge need for training and a thirst for knowledge on how to do things correctly.
• A language and platform that doesn’t seem to get much respect from the “real” programmers doing Java, C# or other languages, even though the demand (and pay) for Force.com and Apex programmers is huge.

It is true that, just like VB being under powered for some applications and needing a product like .NET to fill the gaps for particular needs, so too does force.com have its limitations. We’re always going to see “real” developers do the complex stuff – just look at the amazing number of applications being built of Heroku, AppFog, EngineYard et al – but that’s not the key point here. The key point is that the number of people globally who are now developing applications is ballooning, while the number of so called “professional” developers remains fairly stagnant. The thing that allows this to occur is a democratization, an increasing utility and, yes, a return to the simplicity of the Visual Basic days. It may not be a “real” development tool, but it’s one that is changing the very essence of what development is.

Web site gone. API turned off. Customer data deleted. That’s a pretty abrupt post-acquisition shutdown

Anyway – the elegance or otherwise of the shutdown aside, this is a pretty interesting acquisition. I’ve long predicted that salesforce would move strongly into the area of analytics, partially to drive more value for its existing products. As I wrote in my pre-DreamForce post this year:

…I sense that the company is close to getting to the point where the mass of information on individual networks makes it difficult to use the tool in the largest organizations. I’ve previously said that it is through the intelligent use of analytics on Chatter data that Salesforce will be able to surface relevant content in a way which requires little user input. I’ve seen a number of third parties trying to solve this problem and I’d not be surprised to see Salesforce acquire one of these companies and signal its intention to move into this area

Alex Williams covered the company a few months ago and explained how the technology uses machine learning to build knowledge into software – essentially developers can build apps that can intuit what something is by looking at statistical patterns within the entire dataset. In doing so the service helped to fill in missing values within data sets – by extension it could be used to surface relevant content within a stream (Chatter anyone) to make services more useful. Essentially they’d democratized dataset analysis to drive analytics-type benefits in an automated manner. They create data out of patterns and in doing so provide a really useful service.

Or at least they did – since now the service has been permanently shuttered.

It’s not all bad though, there are a wealth of really interesting problem areas that the Prior Knowledge technology could be applied to within the salesforce stable – Chatter is, as I mentioned, an obvious example, but there are also applications across the entire product line, as well as potentially offering the technology as a service to application developers within Force.com, Heroku or Database.com. This will be an interesting one to watch develop.

A thorny, complex and time consuming process which is tied to all parts of the financial workflow. So with an acceptance that billing and subscription is an important problem-space, the interesting thing in Nelson’s announcement was that NetSuite were actively signaling an intent to move away from their previous strategy which saw them partner with best of breed billing and subscription services like Zuora and Aria and go it alone with their own product. It was only a year or so ago that NetSuite was happy to leave complex billing calculations to third party solutions like those from Zuora, and integrate the result that fell out of that calculation back into the core NetSuite product.

So what’s changed? NetSuite is pushing a story of high complexity of requirements, alongside insufficiently deep integration from third party solutions as the rationale for this move. COO Jim McGeever lays it on the line when he says that:

You cannot manage the full range of required functionality and integrate it it fully into the workflow without using a platform approach. We think this is a significant differentiator where customers want to automate the process but still demand as much flexibility as possible

In a briefing with McGeever he was quick to tell me that NetSuite, as an organization that makes its revenue from complex recurring transactions, lives the pain of this world every day. The experience with their own business helped them to design the product they’re going to sell to customers – they have to work with usage-based components, automatic choices and upselling day to day. What got interesting was McGeever’s contention that billing is in the middle of a bunch of different complex processes – with CRM, leads, quotes, sales order and fulfillment all touching the billing process. Given this, Netsuite’s stance that only a core product will really meet the needs of the market resonates. But in doing so NetSuite has a difficult diplomatic act. They’ve chosen to remain loyal to Aria, talking about it being an appropriate product for basic billings services, but have decided to burn their bridges with Zuora, indeed their pitch deck is length and includes a long list of reasons why Zuora isn’t up to the job – lack of flexibility, customizations, interoperability and analytics among them.

The messaging goes that a standalone product only really handles pure new business and billing models and doesn’t work with more traditional models of billing – in their mind standalone products are not giving these hybrid customer accurate revenue recognition. According to McGeever:

With Aria the problems relate to the nature of the beast, it couldn’t handle complexity but for simple use cases the integration with NetSuite would work. With Zuora however the marketing is way ahead of the product – the company has been over promising and in going public with their billing product NetSuite wished to combat falsehoods from other vendors. Basically the current partner offerings have been having difficult meeting requirements for financial process automation. Customer outliers take 80% of the time and Netsuite implementations with third part billing and subscription vendors were failing

McGeever also suggested that with Zuora in particular, their choice of building on the force.com platform limits the degree of customization available in the product. that’s an assertion that Zuora (and salesforce for that matter) would vehemently refute. Proof of the pudding and all that.

In one final slap of the competition, McGeever criticizes the trend towards percentage based pricing plans saying that NetSuite’s pricing (still to be announced) will not include any percentage based charges.

As with all of these vendor announcements, the inter-vendor politics are half justified and half theatre, but beyond the rhetoric, we are looking at a core bifurcation between best of breed and suite vendors. The suites would say that only a core offering will work deeply with the breadth of functionality that customers require, the best of breed vendors suggest that a suite provider can’t possibly deliver a world class product because of their lack of focus. The reality for customers will vary, but one thing is for sure, this space just got a whole lot more entertaining.

Key changes in this version focus around more strongly tying the financial aspects of an organizations operation to other areas – case in point customer support where FinancialForce is reacting to what they see as a move from pure customer support to enablement, and a corresponding introduction of monetized services through the customer support function. FinancialForce has built out functionality tied to the Service Cloud product to allow service agent initiated revenue;

• Case-to-invoice: charge for a logged case based on a fixed fee or based on hours recorded against a case.
• Case-to-credit: enables a customer service rep to initiate a credit memo directly from Service Cloud to immediately address and resolve customer complaints.
• Case-to-project: allows a service rep to initiate a new consulting engagement or project in FinancialForce PSA when the scope of a case goes beyond standard support

At a macro level – this is a good example of strongly tying together formerly disconnected business units. It makes Salesforce’s Service Cloud product more sticky, and gives FinancialForce a potential entry into new customer sites – mutual benefit at work. Another example of this strong tying together of disparate systems is giving an organization a stronger view of customer insights from a financial perspective. Within the CRM, FinancialForce is allowing the customer service rep to see credit and payment histories for individual customers – in this way FinancialForce believes it is selling organizations on a more engaged salesforce, and an ability to customize the engagement (and hence achieve more revenue) by delivering insights related to buying and spending histories.

This tying together is particularly interesting given a few other product developments that seem to be trending – we’ve seen ERP players more strongly offer revenue lifecycle products – in particular NetSuite strongly signaled this intention earlier in the year at their SuiteWorld event when they announced their subscription and billing services. Similarly Zuora, the billing and subscription vendor who have been recently messaging the predicted demise of ERP, crushed by more finely grained, and externally integrated offerings such as their own. FinancialForce is obviously sensing this change in tone and starting to build out the notion of a loosely coupled set of solutions that deliver a customer’s needs better than a suite product.

Finally FinancialForce is introducing a community element that is envisaged as a central meeting place for their customers. It is a tool set that is embedded within FinancialForce applications and allows users to log cases, self-service and suggest product enhancements. As FinancialForce grows, it’s an awesome way to reduce the cost of support for customers which in itself is beneficial. It’s also however a great way to build the stickiness of a product that suffers the fate of all financial applications – being seen as boring.

FinancialForce has a history of slowly and steadily working away at its product offering. It’s a somewhat invisible player – in equal measures helped and hampered by its high profile shareholder, salesforce. Regardless of its market visibility, FinancialForce has a loyal and committed group of customers. These deep integrations with aligned functions will only increase that loyalty.

Waqar made contact after seeing content I’d written about two other BI players, YouCalc (eventually acquired by SuccessFactors) and GoodData. Allena aims to use search techniques, alongside “computational technology” to allow users to create plain English reports for salesforce. Allena aims to produce a Google-like interface where a salesperson can type in a questions (for example “What are my sales?”) and have a report created in real time from salesforce data.

Plain English BI is an interesting space, traditional BI tools, and even some newer approaches to BI, take an inordinate amount of time to implement – I’ve heard reports of a six week implementation schedule for even lightweight use of one “cloud BI” vendor. GoodData was a company that aimed to solve this problem with its marketplace of prebuilt BI modules – I was very bullish on their chances but the SuccessFactors acquisition meant that we didn’t really get a chance to see how well the solution could work. I’m aware of other plain English BI approaches but they to generally require lots of work to get up and running – Allena aims to change this.

Allena isn’t creating a data warehouse, rather it uses the meta data to parse search queries, and then returns the report based on the live salesforce data. At this stage Allena is pre-launch, and the company is only currently working on standard data models to ensure their solution is as generic as possible. Over time however there is an intention to deliver the same sort of functionality over specialized data models from with Salesforce (and elsewhere).

Preview videos like the one below are always pretty exciting, but the reality often doesn’t quite live up to the promise. Allena is a very early stage company but one that looks really interesting. I’ll be following their progress over time. The video below is apparently created from a live product built on top of force.com and is being run across a handful of salesforce customers to trial.

Update #2 – I spent time with Workday during the event to get a deeper understanding of what the force.com part of this deal actually means. Essentially Workday will use force.com for customers who wish to make advanced customizations on their Workday instance, beyond that which is possible within Workday itself. Workday intends to implement this on an “as demanded basis” that is the data types and APIs which are most requested by customers will be the first to be created.

When salesforce announced their acquisition of Heroku at last year’s DreamForce, many claimed that it would spell the end for force.com as a platform. People failed to see how two platforms, albeit one focused on common data and the other on automating DevOps, could survive under the aegis of one company. These doubts seems to have been unjustified and much discussion has ensued about what I’m calling a bifurcated PaaS landscape. Theory however is one thing, proof is another.

Well today we’re seeing the proof of continuing value for force.com with the pretty massive news that Workday has chosen to use Force.com as their own development platform – in doing so they forego the potential benefits of creating a platform themselves (as, for example, NetSuite have done) but gain from the efficiencies and integration benefits of being part of force.com.

Not only have they decided to forego their own PaaS play in favor of utilizing force.com, but they have embarked on a social strategy that sees them adopt Chatter for their two million or so end users as a collaboration and communication tool.

Through the partnership, Workday will deliver:

• Salesforce Chatter and Workday Integration: Moving traditional workday processes into a real-time stream
• Custom Force.com App Leveraging Workday Data: Workday customers, partners and developers will be able to pull workforce data residing within their Workday application into Force.com to build custom apps

While this is a pre-announcement and actual functionality isn’t due to roll out for a few months, this feels very different from major partnerships announced at previous DreamForce events (VMforce for example). Workday had an analyst summit the day before DreamForce which, due to an unfortunate communication breakdown I was unable to attend. However in talking to folks who attended the event – Workday fully realize the momentum that salesforce has built and the benefits to be gained out of leveraging a common data model and development paradigm between the two applications.

It’s a very interesting partnership and one that raises a bunch of questions for other players – notable NetSuite and FinancialForce. For NetSuite it calls into question the strategy of creating their own platform, especially given the headstart that salesforce has within the enterprise. Time will tell whether a platform based around an ERP as opposed to a CRM has sufficient extra value to see it gain momentum despite force.com’s incumbency.

In the case of FinancialForce however, a financial application also built upon the force.com platform (and partially owned by salesforce) it signals something of a threat, especially given Workday’s stated ambition to move into more fully featured financial software – arguably a robust financial package from Workday that gives businesses the ability to create custom apps on force.com, ready to be integrated with salesforce obviates the value proposition that FinancialForce has enjoyed thus far.

No matter which way these partnership rumblings lead, today’s news is a significant fillup to the credibility of force.com and should keep the naysayers quiet for a while.

Last year I wrote a forward looking post with my opinions around what we could expect from the event. My picks were;

• Increasing attention to Chatter
• More flexibility around pricing
• Richer customization for lower priced versions of salesforce and force.com
• More moves to build the ecosystem

Overall I did OK with my projections – Chatter got amazing coverage at DreamForce 2011 and has continued to do so with high profile announcements around Toyota using Chatter internally. Pricing is still a point of contention, and with companies like Rollbase offering some pretty attractive options for salesforce users, salesforce needs to be careful to watch that they don’t get undercut by competitors. Potentially in response to this threat, salesforce inked a partnership with Intuit that apparently will see all QuickBooks’ four million customers offered a cut-down version of salesforce CRM. At the time I expressed some concern that this partnership was little more than vapor ware – significantly, despite the promise that this partnership would launch some actual product this (northern) summer, nothing has yet been released.

In terms of my ecosystem projection, the Heroku acquisition and the courting of the broader development community show that salesforce is serious about being a truly broad ecosystem provider – a list of their notable investments, acquisitions and hiring moves is instructive in this regard;

• Salesforce acquired Radian6 in order to integrate social media monitoring to it’s platform and application products
• Salesforce acquired Dimdim to add real time communications to it’s other social products
• Salesforce acquired Manymoon – a social productivity application
• Salesforce did the right thing and left Heroku alone to continue doing awesome stuff for developers
• Meanwhile Heroku CEO Byron Sebastian gets to be smart on both the Heroku and the force.com platform
• Salesforce hired Ruby Creator Yukihiro Matsumoto to join the Heroku team
• Heroku was broadened to support the Clojure language
• salesforce invested in ServiceMax a field service software vendor

So… looking forwards to this year’s DreamForce in a couple of weeks, what can we expect…

Less Vaporware, More Substance

Previous DreamForce events have seen recurring announcements of partnerships between salesforce and large enterprise vendors. As salesforce grows to scale, it no longer needs these “partnerships” to build credibility, rather it’s own credibility in the CRM space allows it to build alternative revenue streams through acquisitions or internal development – we’ve already seen this with the Radian6 acquisition, I expect another couple of similar announcements to be made at DreamForce – possibly in the helpdesk/service desk space. As for previously announced partnerships that delivered nbothing of substance (VMForce anyone?), hopefully we’ve seen the end of those.

An ERP Uber-Alliance

Very much one from left-field, but something I’ve been talking about (only partially tongue in cheek) for awhile now. I’d also be less than surprised if I saw some kind ultra alliance between one of the cloud ERP vendors – in some ways NetSuite would be a good fit (similar company stories, similar target markets, some similar approaches) but the conflict between salesforce’s CRM product and NetSuite’s own product would seem to big a barrier. Perhaps Workday can step up and fill this role? Either way despite doing Ok in the market place, FinancialForce, the financial solution built on top of force.com and partly owned by salesforce, isn’t setting the world on fire. I’d not be surprised to see salesforce cast an anxious eye in the direction of SAP and decide to fend off that risk by partnering with one of the more successful cloud ERP/financial vendors.

Uber PaaS Offerings

Already Heroku has broadened beyond Ruby on Rails with its support for Clojure, one slightly left field but eminently possible approach would be for salesforce to support .NET or Java on Heroku – this would close the loop in terms of enterprise development – force.com for developing apps using common business data, Ruby for its speed, agility and ease of use, and .NET or Java for it’s undeniable widespread enterprise adoption. There’s no end of potential acquisition targets or partners when it comes to PaaS enablement.

CRM Lite

Despite the announcement with Intuit, we’ve as yet seen nothing come either directly from that or indirectly from salesforce to answer the needs of businesses to whom salesforce pricing is prohibitive. I’m still picking that we’ll see something substantive come, but possibly not at DreamForce.

More people, More parties, More hyperbole

DreamForce is always a blast, and Marc Benioff is the voice of aspiration – the ultimate showman, he’ll not give up the opportunity to proclaim, statesmanlike, the coming of a new age – previously it was the Cloud, last year seeing that moniker gaining widespread adoption he introduced Cloud2 – who knows what this years term will be. It’s safe to say though, whatever tack he takes, there’ll be 30000 people in the Moscon center hanging off his every word… And the front rows will be taken up by commentators and analysts trying to gaze through the smoke to see the real story from the show.

Cross posted from ReadWriteWeb

One comment I hear regularly from Salesforce.com users (or potential users) are the concerns around the price, and lack of flexibility around pricing, of the Salesforce.com solution. It’s an issue that I predicted would see some movement at Dreamforce last year, but one that Salesforce.com has been mostly resisting. Part of the reason that it hasn’t had to adjust pricing is that Salesforce.com users are essentially locked in to the platform. For example, someone wanting to do some development testing work on a Force.com application has no option but to do it on Force.com itself.

The video below gives an intro to the Rollbase solution;

• Those working with business units who are utilizing a highly declarative platform to create process-oriented solutions
• Those creating standalone applications that want to avoid getting involved in systems administration

This approach is perfectly demonstrated by force.com and Heroku, two platforms from salesforce.com – one (force.com) that caters to the process-oriented needs of developers, the other (Heroku) that allows them to build standalone applications while forgetting about underlying infrastructure. It’s a concept that others are thinking about as shown in this excellent post by Dave McCrory.

Given this recent ruminating then, I was stoked to be able to take some time to sit down with Byron Sebastian, formerly the CEO of Heroku and now filling the dual roles of GM Heroku and SVP Platforms for salesforce. Unfortunately it was a tad windy down in Mission Bay so the audio quality of the video leaves a lot to be desired, however it is an interesting insight into how salesforce is thinking about it’s dual platforms.

When the Heroku acquisition was announced at DreamForce last year, many of us were parsing the deal from a perspective of integration between Heroku and force.com – after thinking about things recently I’ve started to think that we were coming to the issue from a simplistic perspective. Rather than needing a deep integration between Heroku and force.com, I believe salesforce has wisely identified these two distinct needs for PaaS and realizes that a dual play makes sense. So long as there is a degree of integration between the platforms to allow solutions, where necessary, to leverage the best aspects of both approaches, there is no real concern around keeping the two platforms distinct and separate – they both deliver specific requirements to two distinct use cases and customer types.

Sebastian discussed a bunch of things outside of this PaaS delineation (although his perspective on my theories is interesting to here). We also touched on the organizational issues for Heroku now that they’re part of the salesforce mothership. Not surprisingly Sebastian was very positive about how the combined organization works and the independence that salesforce allows Heroku to enjoy. He also pointed out he synergies that the combination brings, and the ability it offers Heroku to be having discussions with CIOs in organizations to whom they wouldn’t normally have access to an example of which is a recent partnership between Accenture and Heroku, something that would have been unlikely to occur before the acquisition.

I suggested to Sebastian that given the fact that salesforce now needs to answer he needs of two different customer types – the “suit and tie” business folks along with grass roots developers – that the necessity exists for events that tailor separately to both groups – I’d expect to see some specific developer focused events introduced from the Heroku side of the organization.

I’m looking forward to some exciting announcements rom Heroku in the months ahead – watch this space!

Video below of the interview – excuse the poor audio quality around the mid way point.

1. Traditional PaaS models (push your app to the PaaS and all the underlying stuff is taken care of). Examples – Heroku, Google App Engine, PHPfog
2. The Amazon model (package the PaaS but allow devs to get their hands on the underlying infrastructure). Examples – Amazon Beanstalk, Azure VMRole
3. Federated PaaS (a federated ecosystem at the PaaS layer). Examples Cumulogic and VMware CloudFoundry

I’m not sure the battle lines are quite so distinct, but hats off to Krish for trying to show the continuum that exists here. I wanted to specifically reflect on the recent changes that Heroku rolled out, and what it means for their future direction, especially given the fact that they’re now owned by staunchly enterprise focused salesforce.com. Some of the specific changes Heroku rolled out include;

• New process model with support for background processes
• Profiles for fine grained control over the processes
• Logplex, support for logs (not just the logs for apps but also for the infrastructure underneath)
• Automatic language detection upon deployment
• Full Node.js support
• Ruby 1.9.2 support
• Ability to configure language using Procfile
• Full process isolation for better security and performance

I spent some time talking with a friend who is deeply involved in developing on Heroku – his perception is that the new functionality is highly relevant to the technical critique they’ve been facing – specifically at an enterprise (read robust) level. In his words, the best way for a web app to truly scale is to introduce both caching and a worker queue – rather than just scaling by throwing more resource at it, far more efficient to better harden the architecture before simple upping the resource intensity. The ability to handle events, tasks and discrete quantities of work on a particular queue all helps drive the efficiency of an app BEFORE simply throwing more resource at it – fine grained control of prioritization answers the needs of developers who, be it through desire or necessity, want to deal with the inner workings of their application.

In his post, Krish contends that;

Heroku might be attractive for SMEs because of Salesforce’s push but I don’t see them making a big impact on the large enterprise segment

After talking with Abhinav Keswani from boutique development house Trineo I’m not so sure – the ability to specify functionality at a more granular level, the increasing robustness of a platform that ongoing investment by salesforce can bring, and the increasing uptake that the heightened awareness will no doubt bring will all prove to be factors that drive towards increasing enterprise adoption. It seems to me that this increased functionality sees Heroku play in both the traditional PaaS and Amazon models that Krish defined in his post – this fact should see Heroku become a popular choice.

I’m going to go out on a limb here and move on rom Krish’s PaaS categorization and suggest something different. I see the industry rapidly moving two distinct ends of the spectrum;

1. Infrastructure PaaS (iPaaS maybe?) which is where Heroku, Amazon and Azure play, is all about giving developers raw infrastructure but with the addition of modular and tunable functions. This is where things like message queues, different workers, data stores and the like come in. As Keswani pointed out, in the early days of PaaS there was this perception that it provided a sort of panacea, a “throw your app at it and it works – magic” approach. The reality is different and for hands on developers building in an infrastructure – centric way, a desire to delve deep down into the different infrastructural aspects its important.
2. Application PaaS (aPaaS?) is a force.com approach where the platform is very data centric and is really tuned around allowing developers to build data-centric applications and then have all the underlying infrastructure fully managed. Keswani gave me an example of an application that Trineo is building that strongly leverages this data-centric approach. While salesforce.com is quick to say hat force.com is way more than CRM customization, it’s a fair comment to say that force.com is about data-centric design, as opposed to nuts and bolts infrastructure.

So as I see it PaaS is going to move to these two distinct ends of the spectrum more and more in the time to come. The future, as my title said, is indeed bifurcated.