The Impending Enterprise 2.0 Software Market Consolidation

Talk about a trip down memory lane…  Another excellent blog post yesterday by my friend and fellow Babson College alum, Sameer Patel, snapped me back a few years and gave me that spine tingling sense of deja vu.

Sameer wrote about how the market for Enterprise 2.0 software may evolve much the same way the enterprise portal software market did nearly a decade ago. I remember the consolidation of the portal market very well, having actively shaped and tracked it daily as an analyst and consultant. I would be thrilled if the E2.0 software market followed a similar, but somewhat different direction that the portal market took. Allow me to explain.

When the portal market consolidated in 2002-2003, some cash-starved vendors simply went out of business. However, many others were acquired for their technology, which was then integrated into other enterprise software offerings. Portal code became the UI layer of many enterprise software applications and was also used as a data and information aggregation and personalization method in those applications.

I believe that much of the functionality we see in Enterprise 2.0 software today will eventually be integrated into other enterprise applications. In fact, I would not be surprised to see that beginning to happen in 2010, as the effects of the recession continue to gnaw at the business climate, making it more difficult for many vendors of stand-alone E2.0 software tools and applications to survive, much less grow.

I hope that the difference between the historical integration of portal technology and the coming integration of E2.0 functionality is one of method. Portal functionality was embedded directly into the code of existing enterprise applications. Enterprise 2.0 functionality should be integrated into other applications as services (see my previous post on this subject.) Service-based functionality offers the advantage of writing once and using many times.  For example, creating service-based enterprise micro-messaging functionality (e.g. Yammer, Socialcast, Socialtext Signals, etc.) would allow it to be integrated into multiple, existing enterprise applications, rather than being confined to an Enterprise 2.0 software application or suite.

The primary goals of writing and deploying social software functionality as services are: 1) to allow enterprise software users to interact with one another without leaving the context in which they are already working, and 2) to preserve the organization’s investment in existing enterprise applications. The first is important from a user productivity and satisfaction standpoint, the second because of its financial benefit.

When the Enterprise 2.0 software market does consolidate, the remaining vendors will be there because they were able to create and sell:

• a platform that could be extended by developers creating custom solutions for large organizations,
• a suite that provided a robust, fixed set of functionality that met the common needs of many customers, or
• a single piece or multiple types of service-based functionality that could be integrated into either other enterprise application vendors’ offerings or deploying organizations’ existing applications and new mashups

What do you think? Will history repeat itself or will the list of Enterprise 2.0 software vendors that survived the impending, inevitable market consolidation consist primarily of those that embraced the service-based functionality model?

Sharing, Markets, and People at Defrag

Defrag will be taking place November 11-12, in Denver. The conference is unusual in its focus — “accelerating the ‘aha’ moment”. The event brings together people from a number of technology domains, mixes them well, and incubates interesting ideas about high-level technology trends, patterns, practices, applications, and tools. It is a conference that I have been interested in attending, but have never made it. Thankfully, that is about to change.

I will be at Defrag this year, not only as an attendee, but also as a Discussion Catalyst. A what?! Well, essentially, my job will be to facilitate discussion on four divergent, yet related, points of view regarding a single topic. The session that I am leading is on Sharing, Markets, and People. The table below lists the presenters and their points of view on the topic.

Following this series of ten minute presentations, I will facilitate a discussion with the entire audience that examines commonality and conflict between the ideas expressed by the presenter. Think of it as moderating a panel where the entire audience is on stage and actively participating. Fun!

The session should be great, and I am really looking forward to the entire conference. If you are not yet committed to attending Defrag, you should seriously consider doing so. You can still register here. If you will be attending, please be sure to say hello while we are together in Denver for a couple of intellectually stimulating days!

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.