Salesforce Chatter Promises to Take Enterprise 2.0 to the Next Level

Salesforce.com today announced “a new secure enterprise collaboration application and social development platform”, called Chatter. While it will not be available until an unspecified date in 2010, Chatter will likely raise the bar for Enterprise 2.0 software, because of the promised ability to embed its functionality into other enterprise applications.

Chatter includes many of the social components that are the core of existing Enterprise 2.0 software offerings: Profiles, Status Updates, Feeds, Groups (Communities), etc. What is different — and significant — about Chatter is that any of those components can be integrated inside any existing enterprise application, including Salesforce CRM and the 135,000 custom applications built on the Force.com platform. In short, Salesforce.com will not make users collaborate through the Chatter interface; they will be able to leverage Chatter’s social functionality in the context of work that they are doing inside a CRM, ERP, or other enterprise system.

The ability to deploy social functionality as a service within an existing (or new) enterprise application is a game changer. To-date, only one other E2.0 software vendor that I am aware of (MindTouch) has been able to make that claim. Salesforce.com is the first proprietary software provider with a very large set of enterprise customers and third-party developers to offer social functionality as building blocks (services) that can be consumed in other, independent applications.

The Enterprise 2.0 crowd has been focused on adoption in 2009 and has recently begun to realize that integration of social functionality into existing and new enterprise applications and platforms will be key to increasing adoption (see my previous posts on this topic: Thought of the Day: September 17, 2009 and The Impending Enterprise 2.0 Software Market Consolidation). Salesforce.com’s announcement of Chatter begins to make that vision a reality, and at scale.

Two other aspects of Chatter demand attention. First, at a time when established Enterprise 2.0 software vendors are touting their ability to integrate with Microsoft SharePoint (see my previous post, Integration of Social Software and Content Management Systems: The Big Picture), Salesforce.com has chosen to provide integration with Google Apps instead. Salesforce.com will use the Google Data APIs to enable data communication between Chatter and Google Apps. This is hardly a surprise, given that cloud computing is core to both companies.

The other striking aspect of Chatter is its embrace of popular consumer social networking applications such as Facebook and Twitter. This occurs at a time when many organizations are blocking employee access to those tools for security, privacy, and productivity reasons. Salesforce.com already features bi-directional communication between its Force.com platform and Facebook, having launched the Force.com for Facebook developer toolkit a year ago. Now Salesforce.com is providing a similar developer toolkit for Twitter.

Chatter is an announced offering, not a shipping product. As such, it is already being compared to Google Wave in the collaboration market. However, Chatter is much more likely to make a significant impact in the E2.0 space, because Salesforce.com has always been focused on enterprise customers, while Google’s offerings started as consumer products and have only recently begun to slowly gain traction within enterprises. Google may bring Wave out of beta before Salesforce.com launches Chatter, but I expect that will make little difference as to which one sees better enterprise adoption in 2010. It is very likely that more organizations will understand Chatter’s value proposition of easily integrated social functionality.

Google Wave Protocols: Clearing the Confusion

Today is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on.

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

To which I replied:

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

I am not a technologist. I seek to understand technology well enough that I can explain it in layman’s terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

• XMPP for server-server communication
• HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
• HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
• Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee’s question, I would unequivocally state that Google Wave is a “concept car” at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.

Thought of the Day: September 17, 2009

Social functionality is best deployed when embedded in other applications and systems, not as social suites or platforms. Most organizations don’t realize that yet, but they will, once they experience the disconnect they’ve created between collaboration, content, and process applications.