Collaborative Thinking

Bowling Alone: The State Of Enterprise Instant Messaging

Instant messaging has not taken off in the enterprise as have other communication tools, such as e-mail. At one time, IBM quoted that Sametime had around 20 million seats and Microsoft has said that it has around 10 million seats of Enterprise IM deployed. This number might be off a little - but compared to e-mail for instance - deployment of enterprise IM has been disappointing given that the technology has been around for about a decade.

So it begs the question - why hasn't IM been more broadly deployed across the enterprise?

One of the older reasons I used to hear from clients years ago was the question of "need" - e-mail was already deployed, and e-mail messages arrived in "near time", so what was the extra value (i.e., ROI) of having IM as another communication option? I haven't head that reason as much in recent years, but it was a fairly common refrain at one time.

Other clients I talked to discussed the hidden up-front costs associated with IM related to security and compliance. While security and compliance issues clearly apply to e-mail as well - in many instances, e-mail had already been deployed across the enterprise. With IM, these issues added to the criteria strategists had to include before they made initial the go/no-go decision. (Again, we're back to cost/benefit analysis and ROI factors.)

More recently, enterprise IM has become part of a broader discussion on unified communications (UC). The reason that IM was not viewed as a necessity for some organization was the fact that it was so disconnected from other communication tools. As an integrated component within a UC platform, it was thought that enterprise IM would finally become a reality.

While enterprise IM has made headway, you still can't but wonder why there is so little excitement around that type of interaction model to improve communication, information sharing and collaboration?

Identifying some of blocking factors (e.g., business case, ROI, security, compliance, integration with UC) are pieces of the puzzle. However, I now believe that the most compelling reason why enterprise IM, has not taken off as expected can be traced to Twitter, and how it has gained widespread popularity. We are now seeing “Twitter clones" (sometimes called micro-blogging or social messaging) targeting the enterprise and it would not surprise me if these tools outpace enterprise IM adoption over the next 3-5 years.

Enterprise IM is not very social - at all (thus the "bowling alone" metaphor). You have a “buddy list” that sits on your desktop for most of the day, and on many days, nothing much at all happens. You see people's presence indicator change from green to yellow to red, or you see their status message change - and maybe if you're lucky someone will actually IM you, or you might IM them. However, for the most part, IM serves a very functional purpose – you use it when you need to contact someone. O f course, there are exceptions - IBM has demonstrated how IM can be used for large-scale jam sessions. A company Microsoft acquired (Parlano) had a nice application for persistent group chat (now a component within OCS R2), that was popular in the financial sector. Still, those situations are the exception and not the rule for most organizations.

I will not go as far as to say that enterprise IM is dead. In fact, for direct real-time communication it will continue to serve a very valuable service. Enterprise IM should be viewed as a functional component with UC platforms. That is a very good trend - people's IM experience will benefit from the richer type of telephony, conferencing, and presence integration found within UC platforms.

Enterprise versions of Twitter are not going to eliminate the need for IM and UC platforms (or e-mail for that matter). Micro-blogging/social messaging tools do however fulfill a user need that enterprise IM/UC platform providers have chosen to ignore, or to support poorly. If Twitter has demonstrated anything, it’s that people enjoy a more openly social and communal experience. As I outlined in an earlier post, UC And Web 2.0 / Enterprise 2.0, social messaging tools actually augment UC platforms and UC platforms have good reasons to integrate with social messaging tools.   

I wonder why UC vendors have been so slow to recognize this trend. To me, the synergies and gaps are obvious. Yet, UC providers have been laggards when it comes to this emerging space (micro-blogging/social messaging). IBM's Lotus Connections team is implementing something close to Twitter in an upcoming release (one might argue that it is closer to activity streams/FriendFeed than Twitter) - but still - at least it's in the ballpark. But IBM's Sametime team still is trying to figure out the different between IM/UC integration and micro-blogging/social messaging/activity streams as indicated by this recent post, Are you confused about how Sametime relates to Connections?.

That inability to sense and respond to market inflections from unexpected sources is one of the problems dominant vendors always seem to have. When vendors and product teams are locked into their solution so deeply that they cannot pivot and attack their own assumptions (sometimes because the disruption is not understood clearly), they miss an opportunity to respond and innovate. In this case, the source of innovation came from another IBM team (Connections). But customers will want capabilities being delivered by the Connections team to expand over time and if the two teams fail to coordinate roles and responsibilities, overlaps might be difficult to explain. 

But IBM is no different than other vendors. Who will deliver micro-blogging/social messaging from Microsoft? The OCS team or the SharePoint team? Will Cisco try to extend its own UC platform anchored around SIP/SIMPLE to address micro-blogging/social messaging or will it push the reset button and acquire/build a tool that more closely mimics a Twitter or FriendFeed model? Vendors that become so enamored with their own products and fail to follow where customers lead them might also find themselves - well - bowling alone.

Turning Instant Messaging and Presence Upside-Down & Inside-Out

I've posted a lot recently regarding enterprise social messaging ("Twitter for the enterprise"):

Twitter in the Workplace

Social Messaging & Socialtext Signals: Before We Get Too Excited...

Twitter Compared to IM, Email and Forums

Enterprise Twitter: Clarity Amid The Hype

Enterprise Versions Of Twitter (updated)

Microblogging In The Enterprise

I've also used the term "social presence" when discussing twitter-like tools and their intersection with unified communications:

More Thoughts On Social Presence

Presence Is Too Important To Leave To UC Vendors

Social Presence: Time To Push The Reset Button

Trivial Pursuits To You Is Ambient Intimacy To Me

Right now, enterprise instant messaging is dominated by IBM and Microsoft. There is some enterprise IM that is based on XMPP (namely Jabber), but not enough to disrupt the market from its current duopoly (i.e., IBM and Microsoft). Presence is also dominated by IBM and Microsoft. The need for better intra-domain presence integration and interoperability is clear - but at the end of the day - communication vendors will not be well-positioned as the "master" presence system. That position will still go to IBM and Microsoft. Although Cisco has a broader collaboration arsenal than Avaya given its WebEx Connect efforts - at best, that places competitive pressure on IBM and Microsoft in a somewhat traditional way. SaaS, in-and-of-itself is not a sustainable barrier or competitive differential for Cisco.

So should Avaya and Cisco "give up" any notion of disrupting the IM/presence trend within the enterprise? The door I believe is just about shut but there is a card worth playing - and that card could be enterprise social messaging. Yes, Cisco could do some interesting things with Jabber and its XMPP infrastructure - especially in the consumer world where XMPP is more widespread. And Cisco could have the best shot at aligning SIP/SIMPLE and XMPP/Jingle than other vendors. But that's not significantly disruptive, at least I don't see it as such.

But if Avaya or Cisco were to (1) acquire an enterprise social messaging vendors (e.g., Socialcast, Yammer), and/or partner with a vendor vendors offering those tools (same list but now add Socialtext and others), and/or build their own (e.g., based on Apache ESME or Identi.ca), they could actually "turn instant messaging and presence upside-down & inside-out. For Cisco, this type of strategy might also have synergies with its EOS platform.

Read Twitter Compared to IM, Email and Forums where I outline some of the differences between Twitter and IM. But some of the quick hits are: 

1. The "follow" concept in Twitter is much more powerful than the buddy list model in IM which hides important community and social networking information.
2. The open conversation flow helps reduce the "tunnel vision" impact we often have within the enterprise (see Avoiding Communication Tunnel Vision).
3. The "re-tweet" capability helps people (acting as boundary spanners in some cases) proliferate interesting information to different social circles.
4. The open conversation provides a level of situational awareness that people can benefit by - it helps them self-synchronize with a conversation flow if they need to involve themselves in an activity.

Yes - there are concerns related to information overload, attention management, etc - but I don't see them as showstoppers.

What if Avaya and Cisco shifted slightly from talking only about communication-enabled business processes and discusses the benefits of socially-enabled business processes (via social messaging, social presence, social networking, etc)?

What if Avaya and Cisco added "click to call", "click to conference" and presence capabilities to enterprise social messaging tools? What if social messaging tools have real-time collaborative options for sharing screens, or whiteboards?

What if Avaya and Cisco offered a gateway/proxy solution that connected public tools like Twitter to enterprise social messaging tools? This model exists for IM and presence today - are some concepts transferable?

Could IBM and Microsoft do this as well? Sure - but it's a bit harder since they would have to deliver something that undermines current market share. And the underlying architecture of these systems are not easily updated to support social messaging. Microsoft could do something with the technology acquired from Parlano (persistent group chat was part of the OCS R2 release) but Microsoft's focus is so heavily on telephony that it's hard to see this capability causing them too much concern. The "law of big numbers" keeps them focused on OCS and its VoIP maturity.

What about Jive and its Ignite platform? Sure - Jive is "that other XMPP vendor" - but do they want to go down this path? It might distract them from the headway they are making with Clearspace - but clearly they could follow in the footsteps of other vendors bringing social messaging to the enterprise.

What about Oracle? Sure, internally they have a similar solution called Ora Tweet, but I don't see this type of effort on their radar screen in the short run. Ditto for SAP although the ESME project has roots in the SAP ecosystem.

Vendors trying to compete with IBM and Microsoft in the UC space need to change the conversation when it comes to instant messaging and presence. Enterprise social messaging is one way to get people to think of real-time communication differently.

Facebook IM Integration

First thought: If Meebo can integrate with XMPP systems - why can't Microsoft? Note: This is not the first time I've picked on Microsoft (and others) for ignoring XMPP-based IM.

Second thought: Why hasn't IBM integrated with Facebook's XMPP-based IM system?

Third (and last) thought: Given Cisco's acquisition of Jabber and efforts with WebEx Connect - you would imagine integration with Facebook as well.

I assume that Facebook might need to do something on its end to enable federation but if enterprise IM systems federate with consumer IM platforms (e.g., Yahoo!, AOL) then why not consumer social networking platforms that have embedded IM capabilities?

meeblog » Blog Archive » MySpaceIM, Facebook Chat, and Meebo!

It’s been a while since we added support for a new IM network. In fact, aside from our first Community IM network Flixster a month or two ago, the last networks we added were Jabber and Google Talk on September 19th, 2005.

Over the course of the day, we’re rolling out support for not one, but TWO new networks: MySpace and Facebook.  These are two of the biggest social networks in the world, and we’re sure many of you use them on a daily basis.  So click that “sign on to more accounts” link and let us know what you think! We’re always hard at work trying to create the best user experience possible, so please let us know about any problems you have or suggestions for improvements.

meeblog » Blog Archive » MySpaceIM, Facebook Chat, and Meebo!

Cisco Announces Definitive Agreement to Acquire Jabber

This is a bold move by Cisco (given it's commitment to SIP) to expand industry thinking around presence as well as expanding its thinking around real-time applications given the type of development capabilities made possible with XMPP. 

So suddenly, I see both Avaya and Cisco as the new thought-leaders when it comes to presence (especially in regards to "social presence").

Microsoft and IBM are locked into yesterday's view of presence and where it needs to go.

Question: What will Avaya do since they OEM'd their XMPP capability based on Jabber's platform.

The solution will show up first in the WebEx world (e.g., Media Tone Network, WebEx Connect) and then follow with an on-premise implementation.

Federation will emerge as well between the cloud/SaaS world and on-premise implementations.

Given XMPP's use within the government and financial sectors, this move will also help Cisco expand its customer relationships with those organizations.

(added after original post)

Involvement with the XMPP Standards Foundation will provide Cisco with opportunities to grow the community and partner ecosystem interested in XMPP from both an open source and open standards perspective.

XMPP support will also help interoperability with Google as well as with other vendor's in the collaboration and social software space that leverage XMPP (i.e., Jive Software, Twitter).

Overall, the move continues to help Cisco build-out a platform and ecosystem for both its UC and evolving collaboration/Web 2.0 efforts.

SAN JOSE, CA -- 09/19/08 -- Cisco (NASDAQ: CSCO) today announced its intent to acquire privately held Jabber, Inc., a provider of presence and messaging software. Based in Denver, Jabber will work with Cisco to enhance the existing presence and messaging functions of Cisco's Collaboration portfolio.

The acquisition will enable Cisco to embed presence and messaging services "in the network" and provide rich aggregation capabilities to users through both on-premise and on-demand solutions, across multiple platforms including Cisco WebEx® Connect and Cisco Unified Communications.

"Enterprise organizations want an extensible presence and messaging platform that can integrate with business process applications and easily adapt to their changing needs," said Doug Dennerline, Cisco senior vice president, Collaboration Software Group. "With the acquisition of Jabber, we will be able to extend the reach of our current instant messaging service and expand the capabilities of our collaboration platform. Our intention is to be the interoperability benchmark in the collaboration space."

Jabber provides a carrier-grade, best-in-class presence and messaging platform. Jabber's technology leverages open standards to provide a highly scalable architecture that supports the aggregation of presence information across different devices, users and applications. The technology also enables collaboration across many different presence systems such as Microsoft Office Communications Server, IBM Sametime, AOL AIM, Google and Yahoo!. Jabber's platform leads the market in system robustness, scalability, extensibility and global distribution.

The Jabber acquisition exemplifies Cisco's "build, buy and partner" innovation strategy to move quickly into new markets and capture key market transitions. In addition to internal software innovations, Cisco actively employs investments in, and acquisitions of, other companies to support its software strategy; recent purchases include industry leaders WebEx, IronPort, Securent and PostPath.

The transaction will be accounted for in accordance with generally accepted accounting principles. Financial terms of the transaction are undisclosed. The acquisition is subject to various standard closing conditions and is expected to be complete in Cisco's first half of fiscal year 2009. Upon completion of the acquisition, Jabber employees will become part of the Cisco Collaboration Software Group (CSG). CSG is part of the recently established Software Group, consisting of Cisco's major software businesses; including the IOS network operating system, network and service management, Unified Communications solutions, policy management, and SaaS offerings.

About Cisco Systems

Cisco (NASDAQ: CSCO) is the worldwide leader in networking that transforms how people connect, communicate and collaborate. Information about Cisco can be found at http://www.cisco.com. For ongoing news, please go to http://newsroom.cisco.com.

Cisco, the Cisco logo, Cisco Systems, Cisco WebEx and IOS are registered trademarks of Cisco Systems, Inc. in the U.S. and certain other countries. All other trademarks mentioned in this document are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. This document is Cisco Public Information.

Cisco Announces Definitive Agreement to Acquire Jabber

More Thoughts On Social Presence

There were two notable comments to my earlier post (and cross-post) on the concept of social presence and the role (or non-role) of UC vendors.

Blair brings up a direct concern (security) and an indirect concern (surveillance). Both are credible issues. Any social presence platform would clearly need to include a policy management component that would integrate with security and identity management systems within an enterprise to support authentication, authorization and related demands (e.g. logging, audit, archival, and records management). An enterprise would require the capability to impose certain policies on a social presence platform to satisfy governance, risk, compliance or other demands. Additionally, any such system would have to have a permission model with access controls that enable people to manage their own “presence”. But I don’t see this as any more of a roadblock than what we expect from other tools – not just those related to UC but also those related to social software in general (e.g., e-mail, calendar, blog and wiki platforms). So while a valid comment, it applies equally to existing tools almost universally. In fact, I point out the need for such functionality in a recent most on microblogging within the enterprise. To be clear – yes – any social presence platform will need to be secure, integrate with existing infrastructure, and support some type of federation model for interoperability with the external world.

The inferred point regarding surveillance is more interesting and properly points out the social dynamics involved as we share “lifestreams” of information about ourselves as we go about our activities. In a blog entry posted in April of this year (Participatory Surveillance: Co-mingling Intimacy & Exposure), there are pro and con arguments that are equally valid concerning how people interact in a mediated public space. Some people will feel very comfortable while others will become rather nervous as they are “followed” by people they may not know – even if they are other employees. Such a concern reinforces the need for controls that allow users to limit their visibility, to filter what they share or to even block someone from tracking them. But – other people and groups may find such capabilities quite valuable in terms of improving shared situational awareness and enabling people to self-synchronize with the conversations or activities of others. There’s no right or wrong – just the need for a social presence platform to include controls that each person can customize how much or how little they wish to expose.

The last point regarding “business presence” vs. “social presence” I believe is more of a contrived debate. The term “social” is often inappropriately equated to “play” or to “waste of time”. Organizations will tell me “we’re pursuing corporate social networking” or “we prefer to user the term ‘professional networking’ rather than social networking”. I don’t mind if people want to label something differently but to a great extent “it is what it is – no matter what we call it”.

What is “business presence”? Are we going to limit presence only to the meta-data status of someone (on the phone, in a meeting, etc)? Is business presence going to be limited to some set of formal states?

What are "corporate/professional networks"? Relationships are hugely influenced by underlying social constructs. Our desire to understand the social aspects of how work gets done and how people leverage informal connections has been a long-sough goal of those involved in knowledge management, organizational development, learning and other initiatives related to community-building.

We should drop the notion that there are not social aspects to business. Artificial labels are necessary at times (i.e., business presence, corporate or professional networking). However we should acknowledge that work is a social environment and we need to catalyze those social dynamics to support business strategies that help drive growth and innovation.

Comment from earlier cross-post

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.

Blair Pleasant
President and Principal Analyst, COMMfusion LLC Co-Founder, UCStrategies.com

Dave felt that I was perhaps too hard on UC vendors. I disagree. Clearly federation is a challenge - especially intranet federation. And yes, we can move the food around on the plate and do a better job with the current presence model. But the bigger problem is "that vision thing". Once large vendors get to a point where they have a product in the market for some time (IBM), or are building a product that targets a given market that they have long sought to enter (Microsoft), there is reluctance to push the reset button and take a fresh approach if that approach impacts the existing product. UC-presence will continue down its current trajectory (remember, I'm not saying that UC-presence is not valuable - just that it is limited and can only be advanced so far).

Other vendors (Cisco, Jabber) also seem entrenched in this narrow view of "presence". If a vendor wanted to disrupt the status-quo, I would imagine that delivering a social presence platform might be an interesting way to open up new dialogs with business and IT decision makers and get some media attention as well. It will be interesting to see if a project associated with SAP (called "ESME", which stands for "Enterprise Social Messaging Experiment") gains traction in this regard. 

What UC vendors should find the strength to admit (and Avaya is the first one to arrive at this point) is: (1) presence is much broader than how UC has defined it, (2) presence needs to be an independent capability with open interfaces to a variety of different applications, (3) SIMPLE has become an inappropriate standard for the next generation of presence, and (4) social networking trends are foreshadowing where presence needs to go.

I expect IBM and Microsoft are going to protect their current investments, will try to position "rich presence" as defined within the UC world as actually being "social" and come up with tactical ways to bridge it to social networking trends. Right now, neither is offering a "vision" of presence beyond the products they wish to sell. I expect Microsoft to continue to limit integration and interoperability of its proprietary "rich presence" services with other vendors. IBM will play better with others - but it's still about Sametime and not a step towards social presence as I see it evolving.

I would hope that UC vendors are getting ideas from folks like Attensa, NewsGator,  RSSBus or Gnip; leveraging work being done at Project Rome or Apache Abdera - and learning how to exploit microformats as well. These are some of the core elements I feel are necessary to deliver a social presence platform that works with existing UC platforms but is not tied down by the presence baggage of those systems.

Comment from earlier post

Excellent points!

Perhaps you were a tad too hard on UC vendors for doin' a what comes natural in using UC-centric presence models. Application-specific presence isn't the cardinal sin - lack of (presence and other) federation is the real problem.

Presence information is valuable and adding custom presence states that are appropriate for specific applications can add great value to a solution.

For example, for UC applications, it might be useful to have presence states that differentiate between speaking on the phone handset versus the speaker. This distinction is useful because more care must be taken speaking on a call that is being broadcast over a speaker. But if this custom presence state doesn't follow open standards and can't be published to other systems, its utility becomes vanishingly small.

It is gauche to design closed-system communications offerings (and social networking services, collaboration applications, etc.) which can only work for people within the walled garden system.

Once enough of the market understands how useful presence is, systems with non-standard, unfederated presence models will have to get with the program, or be left behind.

Dave

Disclosure: I'm employed by Jabber, Inc., a company that has so much belief in the Power of Presence(R) that the phrase is our company tagline and a registered trademark.

Dave Uhlir
Jabber, Inc.

Microblogging In The Enterprise

It was inevitable that Twitter-like services would emerge targeting a business audience. While the term “microblogging” is frequently used to describe these platforms, they could also be considered as a derivative of group chat and instant messaging platforms as well. Within the enterprise, it is highly probable that IT organizations will classify these tools as messaging platforms (I would BTW). As a messaging platform, these tools would have to support security, logging, audit and archival functions to satisfy regulatory, compliance and records management demands.

These requirements might “ruin the party” about how people foresee microblogging taking off within the enterprise – but better to plan for such features now, and push vendors to deliver those functions, than ignore some basic blocking-and-tackling issues that inhibited rollout of enterprise instant messaging.

In fact, the other debate that will go on internally within enterprise organizations will be the overlap between microblogging tools and instant messaging tools that support group chat. Will existing instant messaging vendors (i.e., IBM and Microsoft) support Twitter-like capabilities as an extension of their existing UC platforms – or – will there be a sustainable market opportunity for new entrants to deliver such messaging tools to an enterprise audience?

Microsoft acquired Parlano some time ago which could be extended to be a “Twitter for the enterprise”. IBM’s Sametime already has large-scale broadcast and group chat capabilities as well. But, as my earlier post on social presence outlined – will UC vendors/product teams (who seem to have a narrow view of the world when it comes to social networking), expand their platforms (e.g., beyond SIP/SIMPLE) to support concepts related to social presence as well as concepts related to microblogging? Or will they continue to prioritize their own products as the be-all-end-all hub for these types of applications?

A Myriad of Microblogging Options…

The media event, which ended Wednesday night in San Francisco, has ironically been very high profile on Twitter, the platform famous for originating ‘ambient intimacy’, Other microblogging platforms with traction amongst users include Plurk, Pownce, indenti.ca and Jaiku, with more options popping up practically daily.

…..

ESME is interesting because it focuses on real world application of Twitter style functionality in the SAP ecosphere. From early feedback the Vegas SAP TEchEd crowd didn’t go wild over this innovative project unlike Yammer’s reception in San Francisco, the reality is most internal enterprise people don’t understand the utility of this type of communication yet.

Yammer has a business model that allows rapid uptake of their service, which is anchored around urls. So if your company is arracanis.com for example those with @arracanis.com email addresses can join Yammer. If the owners of arracanis.com want any centralized control over this social network talking about their business they need to pay Yammer…

…..

The bigger challenge – completely understood by early business Twitter adopters such as @zappos - is making a standardized micro blogging platform as intuitive to use as email or the telephone for business users.

For smaller ad hoc business uptake Twitter, Yammer and other services will fill a gap, but there is still a need for a secure internal service that will carry sensitive communication. The ESME’s of the world are working towards that, and it’s a communication and training battle…

A Myriad of Microblogging Options… | Collaboration 2.0 | ZDNet.com

Presence Is Too Important To Leave To UC Vendors

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.

IM Standards: Vendor's Are In A Different Reality

How many years have we been talking about interoperability standards for IM and presence? Why has the SIP/SIMPLE specification evolved so slowly? Why are vendors implementing their own versions of “rich presence” vs. working through the standards process (SIMPLE specifically)? Why do vendors find it so difficult to aggregate and federate presence in a fair and bi-directional manner without trying to gain an advantage by not sharing its extensions (Microsoft appears especially guilty here)? Why does Sametime cling to its proprietary protocol internally? Why does Microsoft not support XMPP in its gateway? Why do most communication vendors (e.g., Cisco) find XMPP so radioactive?

I think the Avaya/Jabber partnership should be specifically called out. Avaya really should be congratulated on its effort to shear off presence into its own server and aggregate both SIP/SIMPLE and XMPP. That is such a breadth of fresh air…

Seriously … the situation is an embarrassment to the industry. I wish vendors would stop whining or try to explain it away and “just do it”.

Michael Osterman posted an interesting piece today on Network World, "Standardizing instant messaging protocols". Basically, he makes the point that technology adoption increases rapidly after an industry settles on a single standard. And he wonders if the fact that we have two standards for IM interoperability, SIP and XMPP, has held back the overall market.
It's an interesting thought. And just to fact check the article, Sametime supports both XMPP and SIP in our Public IM Gateway. (Mike only included us in the SIP camp.)

The Sametime Blog

What does Facebook's support for XMPP mean to the enterprise?

If you are a enterprise organization rolling out instant messaging and presence platforms from IBM or Microsoft, then the roadmap that Facebook revealed does not alter what is going on behind the firewall all the much. Organizations involved with unified communications based on SIP/SIMPLE are not going to significantly change their minds or direction because of Facebook per se.

But, a couple of points are worth mentioning. First, this announcement adds further credibility to XMPP as a worthwhile standard that IT architects and infrastructure planners should be aware of - and actively monitor. Second, XMPP should become a core requirement for organizations implementing gateways that federate their internal instant messaging and presence systems with public networks and other platforms (such as Facebook). Third - not only is Facebook supporting XMPP but Twitter is also aligned with XMPP. There have also been on-and-off discussions on possible synergies between XMPP and Atom/AtomPub. Perhaps at no other time has XMPP looked so interesting to so many different audiences.

For IBM, I would expect someone from IBM's unified communication and collaboration team to realize that this is a great marketing opportunity. At some point, I expect IBM to aggressively pursue interoperability between Facebook's XMPP system and the Lotus Sametime Gateway. 

For Microsoft, this news presents them with a problem - they are in a position that is almost impossible to defend. There is absolutely no technical reason why the current Microsoft gateway does not support XMPP today. It is simply a political decision (in my opinion), by the folks at Microsoft as they compete with Google. Granted, GTalk does not have the market share of other public networks (Yahoo!, AOL), but even so, the strategy is clearly not customer-focused at all.

While promoting anything that helps Google might be difficult to accept, Facebook's implementation of XMPP might prompt Microsoft to reconsider. Facebook has a credible install base and its position as a leading social network site, (coupled with Microsoft's partnership with Facebook on other fronts), might likely persuade the company to finally support XMPP within its IM/presence gateway. Such a move I believe would be well-received by many of Microsoft's customers.

Using Facebook Chat via Jabber

Right now we're building a Jabber/XMPP interface for Facebook Chat. In the near future, users will be able to use Jabber/XMPP-based chat applications to connect to Facebook Chat to:

• Communicate with their friends
• See which of their friends are online and view their profile pictures
• Set their statuses

Users can securely authenticate and authorize applications to connect to Chat on their behalf and send messages to their friends just like they can on Facebook.

Facebook Developers | Facebook Developers News

The New Out-Of-Office Message: Twitter and FriendFeed

I was e-mailing a vendor contact as part of a document review process and received this "out of office" message. I think it's perfect. I've cleaned it up a bit below but I think this is a sign of things to come - don't push away, simply redirect:

I'm at the <insert name of event or business trip> between <dates> and will have delayed access to e-mail. If you have an extremely urgent issue, then call me directly at <cell phone info>.

If you want to keep track of me, then follow me via Twitter at http://twitter.com/<name> or via FriendFeed at http://friendfeed.com/<name>.

Out-of-office replaced by shared situational awareness.