Presence Is Too Important To Leave To UC Vendors

Blogger: Mike Gotta

The title of this post might seem to be self-contradictory. After all, we associate presence as a foundational capability within unified communications. Indeed, several blog posts have recently highlighted the importance of presence as a core component of a UC platform while noting interoperability challenges across UC systems.

Interoperability in IP Telephony and Unified Communications

Today, companies worry about different vendors' PBXs talking to phones and to each other, as well as to applications such as contact centers. But the major bone of contention going forward into UC is presence and the need to "federate" presence engines.

Presence, not VoIP is the Foundation of Unified Communications

I do believe this was conventional thinking for quite some time but this “old school” thinking needs to stop or UC will take years to reach its potential. Also, it’s just flat out wrong. Presence, not VoIP, should be thought of as the foundation for UC.

Presence Plays a Part in Unified Communications

On the nojitter site recently, a couple of my fellow analysts wrote some interesting pieces about the role of presence. I completely concur with their assessments that presence is the foundation of UC. In fact, I believe that presence is one of only three or four elements that are necessary for a UC solution.

Many people consider presence to be a companion technology that goes along with instant messaging, telephony/VoIP, conferencing and mobile technologies. But if you are paying attention (and the posts above are well-worth reading), you can sense that people are beginning to believe that “presence” should be thought of as a topic in its own right – as a distinct and independent capability that augments other UC-related services rather than some type of sidekick that follows along.

For those that have followed my research in the real-time collaboration field here at Burton Group and from my Meta Group days, you’re aware that I’ve talked about presence as an independent architectural domain within UC for some time (circa 2004 as I best recall). I’ve also posted previously on this blog about the changing nature of presence and the need to fundamentally reset our assumptions.

While presence will remain a core element within platforms for unified communications, the social dynamics around presence require all of us to look beyond how presence is defined, packaged and delivered by UC vendors (e.g., Cisco, IBM, Microsoft). The benefits of “presence” span far beyond the boundaries of unified communications. In fact, presence is on its own convergence path with social networking trends.

What I hope people tracking the UC space begin to recognize is that presence is more about enabling social context and social connectedness than it is about communicating awareness of a particular communicate state. Today, the UC concept of presence can be thought of as a type of network “state record” – the presence of an entity is made available to subscribers of that entity’s presence (e.g., displayed on a “buddy list” or within a presence-enabled application). The subscriber is often made aware that the entity is online and has some glimpse into their ability to communicate (e.g., “in a meeting”, “out to lunch”, “away from desk”). Modern systems typically include a richer amount of information including a profile of that entity.

While this capability is incredibly powerful (leading people to talk about the benefits of presence-enabled applications and communication-enabled business processes), it is also inherently limited by its underlying assumption of “state” and dependency (for the majority of vendors) on SIP/SIMPLE for the underlying infrastructure. Rather than think it terms of a “state record” (or row) where we keep adding additional information fields for presence and profile data (columns in that row), we should be examining social networking trends and how other tools are attacking the presence problem (even though the term “presence'” is not often used).

Think In Terms Of “Social Presence”

Many consumer social network sites (e.g., Facebook, LinkedIn, FriendFeed, and Plaxo) allow members to share a chronological stream of information about their activities with other followers or with those within their social graph. The idea of a chronological stream – or multiple rows – has interesting implications to establishing a sense of someone’s presence over time. Seeing someone’s presence over time has a powerful cognitive impact on how people feel connected to each other and are contextual aware of each other’s activities. We just don’t throw more columns at the problem to keep enriching the state record. (Note: this is a conceptual explanation, presence handling is more complicated than rows and columns but I’m using it metaphorically to illustrate the point.)

The term “lifestream” is often used to define this type of presence stream solution. Each entry (“row”) highlights an activity that someone has decided to share in a public or semi-public manner (e.g., a blog post, social bookmark entry, music rating, travel movement or status update). A presence stream reflecting activities of that person can be displayed in multiple contexts. The complete stream or fragments of the stream can show up on that person’s blog, or on the profile page of their social network site. Elements of their lifestream can be combined with entries from other people to form an aggregated stream of information that provides a more social view of the activities of people they are following. This new type of presence model creates a type of social context and sense of connectedness that is not easily replicated in the UC world. 

The result of this type of aggregation of activities enables a type of social awareness that builds on principles originally associated with the UC concept of “presence”. The intersection between social networks and unified communications will form the basis for a hybrid approach perhaps best described as “social presence”. Social presence provides a broader sense of awareness of a person’s interactions and activities by blending information from a variety of applications, productivity tools, social network sites and communication platforms into a chronological stream. The “over time” perspective one gains provides a richer sense of someone’s “presence” than the state-record snapshot we have today in UC platforms. 

A social presence framework (illustrated below) might be modeled in the following manner:

Applications publish information fragments aggregated by a social presence component that centralizes the data. Correlation services analyze the information and package entries into an presence stream which is shared with subscribers. Blended group streams based on a collection of people being followed should also be supported. Applications could also subscribe to a “social presence” stream and contextually display that information as needed. What goes into this presence stream would be very open (e.g., blog posts, bookmarks, status messages, calendar events) in a way that mimics consumer counterparts (e.g., FriendFeed, Twitter, etc).

Vendors

UC-related presence would be included in this model as a subset but the overarching solution is unlikely to be delivered by a UC platform itself. My firm belief is that such a solution cannot be delivered by platforms designed (and biased) towards SIP/SIMPLE. I honestly believe that the underlying assumptions (all the way back to the protocol specifications) bias UC-presence towards communications (which is perfectly fine). A social presence platform may however be delivered by some of those vendors that are active in the social computing space (but they really do need to start thinking more creatively and not be afraid to sub-optimize the overall presence role of their own UC platform). That said – some vendors have a shot here.

Avaya (even though they are a UC vendor) took a bold step by adopting XMPP for its presence server. Feed syndication platform vendors such as NewsGator and Attensa could play a partner role for larger vendors. Jabber and Jive could play in this area as well given their XMPP centricity. (Note: My current thinking is that a social presence platform would rely on a combination of Atom/APP, XMPP and microformats).  Larger vendors such as IBM would have to break from its UC-centric thinking around presence as would Microsoft. For Microsoft however this type of move is almost unimaginable given the centricity of OCS around SIP/SIMPLE and Microsoft's reluctance to integrate and interoperate with other vendors on a level playing field when it comes to presence. Oracle remains a dark horse as does SAP, although ESME is a nice start (congrats BTW to the people involved in ESME and to Dennis Howlett who seems to be the proud mother at the moment). 

Conclusion

The UC evolution of presence will go along its maturity path and will remain critically important to many organizations (e.g., more intelligent/rich, integrated within business applications) but the original lofty vision of presence portrayed by UC vendors will transition to social networking platforms. Those vendors had their shot. But the foot-dragging on openeness/integration/interoperability along with narrow-minded thinking and competitive shenanigans more than justify these vendors being tossed out as far as being thought-leaders on where presence needs to go – presence is simply far too important to leave up to UC vendors.

Comments

[Blair Pleasant]

Mike:

I totally agree with you and I agree that social networking and UC and presence are all tied in together (I love your term social presence). I do have a concern about mixing social presence with business presence. Do I want my calendar information and status information available to someone who follows me because they want to hear what I have to say about UC, for example? And security can be an issue as well - people can know when I'm out of the country on a family vacation, meaning there's no one home guarding the house, except my cute little dog which they can see pictures of on my social networking sites. So I agree with the concept, but feel that it will require lots of rules, permissions, security settings, etc. that we have to think about.