Collaborative Thinking

Introducing Cisco "Wave Connect"

OK - so that product/service does not exist yet. But it could. When Cisco analyzed the Google Wave announcement, and all the surrounding media buzz, it could have quickly stated that it planned to extend its WebEx Connect platform to support Wave once it proved viable in the market. Cisco could leverage its Jabber acquisition (people, technology) and come out with Wave Connect as an extension of WebEx Connect. Wave Connect would provide all the underlying XMPP infrastructure for Wave federation. Cisco could also offer its WebEx Connect "cloud" to third-party Wave application servers. Cisco could also then turn around and leverage its XMPP and SIP resources to bring the XMPP/Jingle world into unified communications - offering its third-party cloud tenants that additional competitive differential. It might also be able to tweak its WebEx Node for ASR 1000 Series routers to bring Wave into the enterprise.

Just thinking out loud... I might be off on some of the technical nuances - but conceptually - interesting.

Persistent Group Chat in Office Communications Server R2

In August, 2007 Microsoft announced its intent to acquire Parlano. Parlano's leading product, MindAllign, delivered "persistent group chat". After the acquisition was completed, Microsoft has kept quiet on exactly how it would adapt Parlano's technology and deliver it as part of Office Communications Server (OCS). With OCS R2 launched in February 2009 that mystery has been resolved:

• Persistent Group Chat - Downloadable Data Sheet
• Persistent Group Chat - Downloadable PowerPoint (Features Overview)
• Persistent Group Chat - Interview With Demo 
• Persistent Group Chat - Official OCS R2 Launch Video
  • Note: Select "Breakout Sessions" from the top menu, then select "Introducing Group Chat in OCS" 

I've been studying the intersection of real-time collaboration and unified communications with social computing (specifically: social networking, social messaging, and activity streams). As I reviewed some of the above materials recently, I jotted down a list of thoughts which I'm sharing below:

From The Downloadable Data Sheet:

1. Is the name “group chat” really the right label? If you are currently an OCS client and have deployed Office Communicator, do you already believe that you have "group chat"? If so, has Microsoft created a hurdle that it needs to overcome in terms of explaining what Persistent Group Chat (itself a mouthful), what applications are possible, and the business case for deploying this new capability? 
2. Why do I need a “specialized client” for group conversations? I can understand the need for a dedicated client for someone who "lives" in this type of application but it seems that organizations will want a "lite" version that extends from MOC for the casual user.
3. Is the “chat room” metaphor something to build on? Or does it create other problems? The concept of chat rooms is not new (you can go back to IRC, AOL, etc). But will management see this as a waste of time? Or as another communication tool that needs monitoring, audit/logging, etc. Would it be better to think of these tools as a real-time version of a async workspace (ala WSS). So, persistent group chat is to OCS as WSS is to SharePoint... 
4. Does the “auditorium” metaphor begin to touch on a similar capability as MOLM? Live Meeting has an auditorium metaphor (as do other web conferencing tools) yet there does not seem to be any alignment or integration between the two - should there be? Could these types of chat rooms compliment Live Meeting as a better back-channel?
5. Does the federation capability (internal/external) require additional edge server considerations? It just seemed to be a gap in the materials that fully explained this concept.
6. Sharing documents in chat rooms. Where are the docs coming from (local PC, from SharePoint)? Am I creating another document island where storage and content management are going to be a concern?
7. Features: It would be nice to have an RSS feed capability (maybe I missed it)? It would also be nice to have a Web Part for inclusion into SharePoint and other application contexts. It would also be nice to have people in chat rooms linked to their MySite profiles (which begins to take Persistent Group Chat into the community and social networking area). 
8. It was not clear in the materials how the archival process works - basically, how much of SharePoints ECM capabilities are leveraged (or not)? 
9. The real question overall - how does persistent group chat relate to "Enterprise Twitter” (social messaging, micro-blogging)?

Downloadable PowerPoint:

1. Some similar questions as above came to mind re: chat history – where does it intersect with Microsoft's ECM/records management efforts? Is this information searchable – how (via SharePoint, FAST, etc? 
2. Will there be a browser client? For Office Communicator, Microsoft also delivered Communicator Web Access. Is there (should there be) a CWA like front-end for persistent group chat?
3. Is the Group Chat server part of the enterprise pool itself? It just wasn't clear in the diagrams.
4. The deck talks about federation - but it isn't clear how much work I need to do for federation of persistent group chat and the normal federation work an organization would have to do for OCS in general (for IM and presence). Are they complimentary, different? What are the impacts to edge servers?
5. In some ways, when the OCS team talks about discussions in group chat - the parallelism between real-time and async collaboration comes to mind. I would hope that the two teams are working together from a user experience perspective - setting up forums (real-time or async) are different approaches to conversation and how people work together - they should have some similar contexts in terms of user experience and application behavior. But - two teams - two products - probably not as much cross-functional alignment as I would want to see... 
6. I would like to see some more details information on REST or JSON or Atom/AtomPub interfaces so that developers could build their own extensions and front ends. If you look at the level of innovation around Twitter and other web sites due to Adobe AIR...

Video Interviews:

1. I can't help but wonder as I watch the videos whether this technology has been eclipsed by social messaging / micro-blogging / activity streams. Maybe eclipsed is too harsh - but it seems like there are different architectural models now.... perhaps group chat rooms hang off of a social messaging stream. 
2. I also begin to wonder about how other applications post events into the "room". If I had a persistent group chat room dedicated for data center ops for instance, could a system management tool post into the chat stream? If so - then I begin to think about the touch point between activity streams and these type of tools...
3. I was hoping to see support for the type of nomenclature that Twitter supports (@, RT, d, hash tags, follow, etc) – the conversational dynamics are similar...
4. Rooms I belong to – that, and other information, should show up in my MySite Profile (linking community and social networking).
5. It would be nice to associate chat rooms with WSS spaces, wiki spaces, etc ... again, people ebb-and-flow from sync to async to sync, etc.
6. It would be nice to see a workflow escalation scenario. Can you auto-create a persistent group chat room and provision it with people on an event basis (e.g., business application event)?
7. Finally, analytics to mine, report, analyze these rooms would be nice to see.

That's it ... just a note-taking brain dump while reading/watching.

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.

UC And Web 2.0 / Enterprise 2.0

Over on the Enterprise 2.0 blog, Irwin Lazar discusses whether UC and Web 2.0 are "friend or foe"? Here are some of my thoughts. Deeper commentary can be found here: Turning Instant Messaging and Presence Upside-Down & Inside-Out.

Unified Communications	Web 2.0 / Enterprise 2.0	Synergy
Instant Messaging, Persistent Group Chat	Social Messaging / Micro-blogging	IM will remain more point-to-point. Social Messaging will take-on Persistent Group chat features. IM will replace direct messaging in enterprise social messaging tools.
Presence, Rich Presence	Activity Streams, Geolocation	Presence will remain but will focus on people's availability for communication. Activity streams and Geolocation will become the focus of more advanced rich presence efforts.
"Buddy List"	Social Graph and "Follow"	The concept of a private buddy list will be surpassed by social graph and "follow" features in social networking platforms.
Directory-based Profiles	Social Network Site Profile	UC will not be the focus for user profiles and will instead leverage profiles from social networking platforms.

The obvious opportunity for UC vendors is to augment Web 2.0 / Enterprise 2.0 by adding click-to-call, click-to-conference, presence awareness, etc. If UC vendors could get their heads out of the SIP/SIMPLE world, then they could possibly make a run at social messaging (which will likely involve XMPP, Atom/AtomPub, microformats, perhaps portable contacts, etc). But existing vendors such as IBM and Microsoft have so much already invested - that I don't see them being able to turn around their respective mindsets. Cisco perhaps because they need to do something to disrupt the market and their XMPP asset (Jabber) could play a strategic role in a Cisco-based social messaging tool (or they acquire someone). I also don't see enough cross-team synergy on the Microsoft side between SharePoint and OCS. The OCS team is heavily focused (obsessed perhaps) with cracking the code necessary to dominate the telephony space. The social aspects of UC are just not critical enough to have them signficantly alter their course I imagine. IBM is trying to keep Sametime relevant in a traditional collaboration and UC market - Lotus Connections is IBM's social play. The Connections team is adding capabilities related to Activity Streams - so I expect some awkward positioning to come out of IBM as they balance two teams with different strategic goals. Avaya remains a dark horse on the fringe I suppose. No other major player in the UC space really matters when it comes to this UC/Web 2.0/Enterprise 2.0 intersect. The expertise location idea has been around since the late nineties (Tacit, etc). So it's not really all that "new" - tagging and some techniques are causing people to take a new look, but issues related to profiles are numerous and often over-sold as an expertise "silver bullet" by vendors.

UC and Web 2.0: Friends or Foes?

At this week’s VoiceCon conference I had the opportunity to moderate a panel discussion featuring Cisco VP & CTO of UC, Joe Burton, and IBM Lotus UC and Collaboration Services U.S. Leader Peter Fay on the role of Web 2.0 in an enterprise UC architecture.

Enterprise 2.0 Blog » Blog Archive » UC and Web 2.0: Friends or Foes?

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.

First Take: Microsoft Business Productivity Suite Online - Communications Online

Microsoft announced this week (Monday, March 2, 2009), that its Business Productivity Online Suite (BPOS), was available for trial in 19 countries. It disclosed Office Communications Online would be available in April 2009. I wanted to share some thoughts on the unified communications aspect of the strategy.

What this is:

• Primarily (overwhelmingly for that matter), this initial offering will be about hosted instant messaging (IM), presence and web conferencing.
• Support for Communicator Web Access (CWA).
• Support for group chat and other features outlined on the slide below.
• Support for some peer-to-peer functions (e.g., file transfer, audio, video) should be expected but there will be some constraints (refer to the footnote on the graphic below). It might be the case that audio/video is supported only from Internet locations using a VPN (e.g., remote workers).

What this is not:

• This is not about hosted unified communications or even hosted OCS. It is better to think about this initial effort as "more LCS-like than OCS-like".
• For example
  • the web conferencing component within OCS is not available - instead, organizations need to use Office Live Meeting
  • there is no support for IM/presence federation in the initial version (again, just hosted IM/presence for intranets)
  • there is no support for integrating with existing telephony (e.g., Avaya, Cisco), or other conferencing systems

Recommendation:

• It's hard to really identify a reason for a large enterprise to be interested in the initial release of Communications Online. If you have made the decision to deploy OCS - the loss in capabilities is so massive at this point, that it seems best to wait for a future release before any full commitment.
• There may be situational use cases, so I would pay attention for "exceptions to the rule" and "opportunities to learn". For instance, an organization just looking for real-time collaboration with no immediate plan to pursue a full-fledged UC effort - or offering this to a particular worker segment while other worker segments are provisioned for OCS - might be possible scenarios, but that raises lots of integration questions.
• If you need web conferencing, you can get Live Meeting today independent of BPOS. There does not appear to be tremendous synergies with Communications Online. My guess is that Microsoft went with Live Meeting because the OCS version of web conferencing has a limit of around 250 participants, and perhaps there were technical issues. Longer term, I think Microsoft has to rationalize Live Meeting and OCS web conferencing as the collide in the cloud. And don't forget about Shared View, the Live offering for small-scale conferencing.

Questions:

• Questions to ask now
  • Live meeting is managed in parallel to OCS today - using Intranet Portal - how does the management happen under Communications Online - do organizations need to manage the IM/presence system in parallel (still) with Live Meeting?
  • Do users need to belong to a single SIP domain? If you have multiple SIP domains, what are your options? How are SMTP and SIP domains associated with each other?
  • Is there a limit on the number of presence contacts on the buddy list? There maybe a limit of 250.
  • If you are presence-enabling applications that are not hosted, how does Microsoft enable presence icons to appear in lists and Web Parts in those applications that are not hosted?
  • If users elect to add email distribution lists to their buddy list, are there limits on the size of those distribution lists? There may be constraints with lists over 100.
  • How does Communications Online handle mobile device scenarios (e.g., escalate from IM to phone call)?
  • Double-check me on federation - Microsoft indicated that it is not supported but I would ask - how can an organization federate Communications Online with other external systems (business) and public IM providers?
  • I would ask lots of questions on provisioning and directory/address book synchronization - especially if you have split environments (an on-premises OCS and Office Communications Online) or hybrid environments (Communications Online but Exchange and/or SharePoint on-premises).
• Questions for the future
  • Once the web conferencing component of OCS is made available within Communications Online - it begs the question - what is the future of Office Live Meeting? At some point - what's the sense of having both Live Meeting and Communications web conferencing?
  • Once the other components of OCS are moved to the cloud, then what happens to all those protocols OCS is based on? Remember, OCS was never designed to be a cloud system - it was always designed to be on-premises. I assume since group chat is supported that the IM conferencing server is now hosted but the other components (telephony conferencing server, A/V conferencing server, mediation server) will eventually be migrated as well. Microsoft right now will do HTTP/HTTPS tunneling, sending all traffic (i.e., PSOM, SIP) for Communications Online via port 443. But will that hold true when you start thinking about SRTP - will there be a performance overhead with tunneling? How will integration with other UC vendors be handled - if I have Avaya or Cisco - how will a hosted OCS interoperate with non-hosted versions of those tools? There seems to be a very rapid complexity curve when you start moving more UC capabilities to the cloud. You also need to think about global implementations - how will Microsoft handle complex enterprise pools (multiple pools perhaps in some cases)?
  • There's also the perimeter design question - right now - you need to think about various edge servers in an OCS deployment - if OCS capabilities become completely cloud-based - then what happens to the services that currently are provided by the HTTP Reverse Proxy, the Access Edge Server, the Web Conferencing Edge Server, and the A/V Conferencing Edge server? Does Microsoft simply hide the perimeter issues internally or do clients still have some role to play? And, how does federation work then with a totally hosted solution?

Source: Microsoft

Announcement:

Microsoft Online Services Available Worldwide: Microsoft signs agreement with GlaxoSmithKline to deploy Exchange Online, SharePoint Online, Office Communications Online and Office Live Meeting for employees worldwide.

Microsoft Online Services Available Worldwide

Microsoft signs agreement with GlaxoSmithKline to deploy Exchange Online, SharePoint Online, Office Communications Online and Office Live Meeting for employees worldwide.

Related Links

Microsoft Resources:

• Microsoft Business Division Virtual Presskit

• Microsoft Online Services team blog

• Microsoft Online Services Web site

HANOVER, Germany — March 2, 2009 — Furthering its commitment to deliver communications and collaboration software as enterprise-class services, today at CeBIT 2009 Microsoft Corp. announced that the Business Productivity Online Suite, part of Microsoft Online Services, is now available for trial to businesses of all sizes in 19 countries. In addition, Microsoft will release Microsoft Office Communications Online, for instant messaging and presence, and the Business Productivity Online Deskless Worker Suite, an extremely economical e-mail, calendaring and collaboration service for the occasional user.

“These services open up new possibilities for businesses to control costs while continuing to enhance the productivity of their employees,” said Stephen Elop, president of the Microsoft Business Division. “Customers can save between 10 percent and 50 percent in IT-related expenditures as a result of deploying Microsoft Online Services.”

Software-Plus-Services Strategy Reaches Worldwide

Exchange Online and SharePoint Online are available for trial in Austria, Belgium, Canada, Denmark, Finland, France, Germany, Ireland, Italy, Japan, Netherlands, New Zealand, Norway, Portugal, Spain, Sweden, Switzerland, the United Kingdom and the United States. Organizations worldwide will be able to trial and purchase the entire Business Productivity Online Suite, including Office Communications Online, in April.

In addition, Microsoft is committed to providing opportunity for a global ecosystem of partners that will sell, customize and provide consulting, migration and managed services for Microsoft Online Services customers around the world.

Microsoft Online Services Available Worldwide: Microsoft signs agreement with GlaxoSmithKline to deploy Exchange Online, SharePoint Online, Office Communications Online and Office Live Meeting for employees worldwide.

Enterprise Twitter: Clarity Amid The Hype

Some good points in this post from Adina Levin (Socialtext). For the most part I agree but we're still in the phase were vendors are hyping the benefits and not being transparent regarding some of the "non-fun" aspects of making these systems acceptable for large enterprise environments. I don't address the conflict these tools will have with enterprise IM/UC systems but that's another decision organizations will have to address - and will UC vendors respond in a "good enough" fashion to keep these tools from gaining any type of long-term traction.

Links to real identities and work activity

With public Twitter, people use nicknames. Many people add a profile link that identifies who they are in the real world. Many do not, and tweet pseudonymously. In a business setting, the signal is tied to the user's real-world identity, derived from their company directory entry and business activities. You can navigate from a signal to a profile, and discover a lot about the person in their work context. A significant part of the value the people get from enterprise social software is finding the smart and plugged-in people in their organization. Microblogging helps discover the interesting people, and the links to rich work-context profiles reveal more about what the person does and what they know.

Agree. Within an enterprise, any type of "Twitter" system will be linked to directory systems in much the same way as e-mail and instant messaging systems are linked via address book synchronization techniques.

Agree. The profile aspect is very important - it becomes a way for people to "peel away the layers" of a conversation thread to find out more about someone, perhaps read other posts by that individual, look at their tags/bookmarks, and so on. The risk here though is the proliferation of profiles. If people have to create and maintain half a dozen different profiles of themselves - chaos will ensue and people will lose interest in maintaining their profile data. Yes, someone could come along with a synchronization model but that's neither here nor there right now. Profile proliferation should be a top concern of enterprise architects and others involved in social software strategies.

Disagree. This is not micro-blogging. Within the enterprise, this will be viewed as a messaging system. If you want to consider micro-blogging as a messaging system then I'm fine with that - but Twitter-like applications are going to be defined as a type of communication system (which will trigger all sorts of other issues related to logging, audit, compliance, e-discovery, etc).

Sharing links in the intranet

With public twitter, one of the common usage patterns is to share links. Well-informed, insightful people scan the news, and share interesting tidbits with their followers. This valuable pattern on the public net gains power inside an organization. People can share links and commentary about to documents they are working on, for example, a marketing plan or a budget. And they can share private commentary about public links. For example, there can be a company-private discussion about a move by a competitor. Enterprise microblogging allows users to share links to private content, and to share private discussion about public content.

Agree. Permission models will be a fundamental requirement and will be a source of competitive differential for vendors entering this space. This is another reason why profiles themselves need to support multiple layers of permissions so people only see profile attributes that they are allowed to see. This also raises the issue of logging/audit/compliance. If these messages are sent/received by people already under communication policies that have their messages logged for audit/compliance reasons then Twitter-like systems absolutely will have to support similar capabilities. If not, then third-party vendors need to step-up. If there is no support for these capabilities - these tools will go nowhere in certain organizations, or there deployment will be limited.

Confidentiality

The main difference between Twitter and enterprise microblogging is confidentiality. You're not sharing information with the big wide world, only with your colleagues. As in personal life, confidentiality frees people to share more openly about nonpublic topics. Of course, people need to be still cognizant about what they share, as they do in meeting rooms or around water coolers. Inside an enterprise, microblogging has a different balance of transparency and privacy than email. With email, your message is visible only to the people you choose to send it to. With enterprise microblogging, the recipient chooses who to follow, and whose messages to see. This provides useful "ambient transparency" in an organization, for example spreading useful knowledge about products in development and customer relationships. Enterprise microblogging is more private than public Twitter, and more transparent than email.

Agree in part / disagree in part. In most companies, employees should have no expectation of privacy when it comes to email. Virtually all companies state so in their usage policies. Yes, there is the perception of privacy and employees can rightly believe that only under extenuating circumstances will their email be read - but privacy is something that will be determined by various laws (e.g., privacy regs) and company policies. Even with that, email can be forwarded so the common recommendation is "don't write in email what you wouldn't want to see public". Yes, e-mail is not transparent - that I agree with - email information and conversations are horribly fragmented, disconnected, difficult to leverage, etc. But Twitter-like systems are also difficult to follow - the tools so far do not do a great job of isolating conversation threads, manage/filter messages over time, etc. On top of this - do we really think that companies will have wide-open conversation spaces without applying permission models that limit access rights based on a variety of business reasons?  I don't disagree with the concept of transparency - but you have to consider policies related to role, separation of duties, security, confidentiality, intellectual property, compliance and so on. There are very good reasons to have bigger walled gardens within enterprise organizations - and some organizations will be much more public than others - but we do get back to addressing barriers encountered by other messaging tools.

BTW - many (if not all) of these concerns and issues apply equally to "activity streams". The need for activity streams to support permission models, and comply with logging/audit/compliance/discovery requirements should be pretty clear. For vendors offering "Twitter for the Enterprise" or "Activity Streams" - making sure you support security (permission/access controls), identity, and records management requirements has no down side.

SocialText

UC And ROI: Round2: IBM's Truth And Fiction Example

John Del Pizzo from the IBM Sametime team responded to my post - but, I'm not persuaded by the counter-arguments.  

Point 1

He dinged us on:

"...the total cost of ownership is not clearly outlined, a reasonable TCO model would establish a timeline (say 3 years) and include the total costs, including various weighting factors for planning, operational support, integration costs, help desk, change management, and so on."

As I helped work up these estimates, I'll take the heat for this one. While our goal for the Lotusphere keynote was to provide concrete examples of how Sametime could pay for itself within a year, we did not set out to provide an exhaustive TCO model. We have to leave something for folks like Mike to do. :-) But... if you were at the keynote, you may have noticed that our composite Renovations, Inc example was followed by one from a German manufacturing firm. They provided data on their 3 year costs including things like education and support. Their return was 9 times costs. So, while Renovations, Inc was not a full TCO, I'd argue the composite return of 3.5 times costs was actually fairly conservative. Of course, your milage may vary and you should examine the TCO in light of your specific organization.

Round2: A fair point. The more specific example is appreciated but that doesn't really excuse IBM from portraying an incomplete / inaccurate argument. I would have preferred to eliminate the simplistic example then and stick to a testimonial that reflected a real-life situation. I think real scenarios always trump fabricated illustrations. Saving the time on the over-simplistic demo would have allotted more time to dive more deeply into an actual use-case.

Point 2

On replacing the licensing fees of a hosted web meeting service with Sametime:

I dislike this example because IBM fails to accurately portray the total cost of ownership for an on-premise implementation of Sametime vs. a SaaS solution.

To an extent, this is the same issue as above. Yes, there are costs associated with running your own infrastructure versus outsourcing it. However, the point stands that you can pay for the software licenses, hardware and a full-time administrator with what you would save by eliminating 1000 Webex Meet Me licenses - in year one. And since you don't have to "rebuy" Sametime every year - maintenance fees are only 20% of the purchase price - the savings go up dramatically in the out years. AND you get a full unified communications platform with an extensive range of capabilities above and beyond only online meetings. I'm not saying that the hosted model isn't attractive for some - just that there are scenarios where it makes more sense to own the infrastructure.

Round 2: The argument is still incomplete though - are all situations handled with only one administrator - how are complex ST implementations that require placing components of different servers handled - when is more than one admin needed and what about the other support people (help desk, system engineering, networking, server support, change management, etc? Clinging to the notion that all you have is license cost and one administrator is very simplistic. You also have costs incurred when major releases need to be evaluated and an infrastructure upgrade scheduled. I realize the sensitivity concerning WebEx since a good number of ST shops use ST for IM but other vendors for web conferencing - but we need to be a bit more accurate here.

Point 3

On using Sametime to IM enable a support site to reduce the number of calls.

This example is a stretch for me - a big stretch - most customer-facing applications on web sites that are handled by call centers do not use off-the-shelf generic IM products. They typically use real-time collaboration tools that are included within their call center suites and/or CRM applications. The reason is that call centers do a lot of multi-channel management so you do not want someone involved in an IM chat to appear available to handle a phone call or email response. You need to integrate on-hook/off-hook signaling, integrate with other customer response management tools (telephone, web, e-mail, IM, etc). IBM is correct that organizations should be looking at these tools - but incorrect that they should look at IBM and Sametime

Sorry, Mike but I have to completely disagree with you here. We specifically included this scenario because we have customers who use Sametime for exactly this purpose. How long have we been talking about the benefits seen by companies like Celina Insurance? Or a large financial services firm that is using Sametime on their loan website? In the latter case, they integrated Sametime with a partner application to route the IM to the next available agent and are evolving the implementation to connect to their telephony system to show onhook/offhook status. This way IM's wont be routed to someone already on the phone. I probably get this question once a week from our sales teams... so clearly companies are thinking about extending their web sites and call center applications with Sametime.

Round2: Sorry - you made my point. You need to add in the cost of the partner application or the customized integration into the e-Service/CRM suite that the customer is using if you want to be accurate. Implementing ST as a silo, without the integration into the multi-channel interaction management environment of large enterprise call centers is a huge oversight in the IBM argument. You need to include those costs before you can address any potential savings. And if you include those costs - how does that compare with the native real-time capabilities found in leading call center applications that address e-Service. IF those costs had been included - I'd be fine. Presenting them in a way that dodges those issues is disappointing in many ways.

Point 4

The "time saved" argument is one that has been used over and over again to justify technologies ... if you save someone 10 minutes it does not mean they will take that 10 minutes and apply it to real work. The more structured and directed the activity is (e.g., call center) the better that argument resonates. But the more discretionary the work, there a greater chance that the person will just chat with a co-worker, go grab a coffee, etc.

This is the one Mike brought up twice, so I'll address it last. (And I really got a kick out of his example of what people would do with all their new-found free time.) But... we didn't go near the productivity gain potential in the Renovations, Inc composite example. While nearly every customer I've ever spoken to has told me that the productivity gains are the reason Sametime is such an invaluable tool, the gain is usually difficult to quantify ahead of time. So for Renovations, Inc, we stuck to what could be quantified with a reasonable degree of certainty before an implementation. I'm not sure why we got two thumbs down for an argument we didn't use.
Beyond that minor detail, I'm afraid this line of reasoning wouldn't hold water for me anyway. Perhaps we should go back to using typewriters because word processors have led to too much golf? Seriously, though, IBM has documented that it closes its books 3 days faster every quarter because of Sametime. While they maybe hard to quantify beforehand, productivity gains should not be dismissed when it comes to Unified Communcations & Collaboration software.

Round2: I will match your argument with 10+ years of being in the analyst business and talking to multiple hundreds of clients that consistently point out that "time saved" is over-rated because it is often very difficult to prove real savings. Yes, you can identify time freed up - vendors are right to make that claim - they fall down on assumptions regarding how that time might be re-applied. Too many variables in some situations. For instance, in those situations where work/workers are transactional or semi-transactional (structured task workers), then you can indeed get pretty close to converting "time saved" into real efficiencies because those activities will have metrics to substantiate it. If that is the case - then you can make that point and be well-received. But once you get to what people refer to as "knowledge work" - (e.g., people re salaried, are paid regardless of time saved; or where the work/tasks have a lot of flexibility in how they get done and over what time period; or where work is not really output-driven - then the time saved argument is pretty weak. It can get a project approved - that happens a lot - but when you go back to look for the savings - it's like chasing vapor. You can be somewhat flippant in your response, but it just shows a very weak understanding on the part of IBM regarding the challenge of measuring productivity. You can go back to many industry efforts that have tried - economists and folks in the educational arena. It's a tough intangible to measure. Fortunately, IBM is not alone - Microsoft made the same grandiose claim around its OCS R2 launch. It's a very common approach - and vendors should be called on it.

The Sametime Blog

Avoid Profile Potpourri

Connectbeam is one of those first-movers in the market that often gets overlooked but they continue to do some creative things (see below). While initially identified as a social bookmark system for the enterprise (an "internal delicious"), the company has done a credible job of expanding the conversation beyond a tooling discussion. In a broader context, issues related tagging and bookmarking lead to more business-centric conversations on the benefits from user-led information discovery, filtering and allowing people at a personal and group level to self-organize information. While some activities around tags/bookmarks might be directly related to a work activity, there are community interactions made possible that enable informal information sharing, personal learning and ad-hoc group formation as people connect to one another.

However, (you knew there had to be a "but" coming...) - as I read the post below, it brought up a topic in my mind that strategists should be concerned about and that is the emergence of isolated profile components within a lot of the tools associated with "Enterprise 2.0". Already you can see vendors on the market (blog, wikis, feed syndication platforms, social bookmark systems, etc) all coming out with their own profile component. In parallel - vendors in the unified communications space also have their own versions of rich profiles.

It's understandable - people want to have a richer understanding of their fellow employees and vendors want to differentiate their products from competitors - profiles help meet those needs. Often these profile components are also associated with additional benefits such as expertise location and community-building. There are clearly applications that can be built around profiles but the proliferation of profiles embedded in a proprietary way across multiple products should raise critical questions: (1) how many profile engines does an enterprise need, (2) how will we systematically populate multiple profiles efficiently, (3) how will we persuade workers to create/maintain multiple profiles, (4) how do profiles link to underlying collaboration, content, communication infrastructure and finally, (5) how should organizations align profile subsystems within social networking platforms with their identity management infrastructure.

The three major players right now for social network sites within the enterprise are: IBM (Lotus Connections), Jive (Clearspace), and Microsoft (SharePoint). IBM and Microsoft are also major UC vendors but the profile functions in their UC products are not aligned with profiles in their social computing products. There are of course other vendors that have social networking capabilities - some focus on more vertical applications while others have more of a suite or take on an overlay approach. But none really have the completeness of what I would consider needed for a Tier 1 player right now. (Note: I would expect Oracle  and Cisco to more clearly define their respective solutions and profile direction in this area at some point.)

Each of these vendors (IBM, Jive, Microsoft) have profile modules. Yet none have clearly articulated how organizations should view the relationship between its profile engine and identity management strategies within the enterprise. None have really addressed interoperability and federation techniques developers and vendor partners should use across products that all have their own profile component (e.g., perhaps based on hCard). 

So - while the post below from the folks at Connectbeam is interesting and the solution worth a look - I would caution people on the profile feature. I would recommend that when you do your vendor evaluations - carve a section out for profiles and look at the bigger picture. You might avoid some messy integration and user adoption issues down the road. 

The Connectbeam Social Computing Blog: Putting the Social into Microsoft Outlook

Connectbeam Social Profiles Integrated into Microsoft Outlook

Through Spotlight Connect for Outlook, employees' Connectbeam Social Profiles are embedded into every internal email. Here's a screen shot of this integration:

What we've put in this profile is the following:

• Contact information, synchronized with LDAP or Active Directory
• Expertise - as created and managed by each employee
• Projects - as created and managed by each employee
• Recent Activity - content created across different social software apps plus bookmarks
• Employee profile toggling - click another email recipient name, see their profile

The social profile makes it easy to see what colleagues are doing and what they know, all at a glance from the Microsoft Outlook inbox.

The Connectbeam Social Computing Blog: Putting the Social into Microsoft Outlook

UC And ROI: IBM's Truth And Fiction Example

I caught a couple of blog posts on the IBM Keynote for UC (Lotusphere Message: Yes There Is a UC ROI) and then one on the Sametime blog (see below). A few good tips and examples but also some "buyer beware" tactics that folks should be aware of. Overall - I give IBM 3 Thumbs-Up and 5 Thumbs-Down:

The ROI of Unified Communications & Collaboration

Let's take a company - we'll call them Renovations, Inc. - with 5000 users.

On average - using suggested retail prices,  it would cost approximately $450K to purchase 5000 Sametime licenses including maintenance, two hardware servers, pay someone to plan and install the software and servers, and pay an administrator to maintain the system.

Thumbs-Down: The concern I have here is that the total cost of ownership is not clearly outlined, a reasonable TCO model would establish a timeline (say 3 years) and include the total costs, including various weighting factors for planning, operational support, integration costs, help desk, change management, and so on. IBM is being very selective (almost dismissive) of the costs to introduce, deploy, and maintain the system. 

Let's talk about the potential savings that Renovations  could realize in just one year. These figures are based on our experience from similar deployments as well as IBM's own measured cost savings. By using IM or voice chatting, we have found that users can, on average, eliminate 5 telephone calls per day. At an average rate of .02/minute and 4 minutes / call, Renovations could save $480K annually.

Thumbs-Up: It's important to note here the different between channel switching (from telephone to IM or VoIP chat) vs. time-saved by reducing phone calls. The example is correct in that there are some costs associated with telephones (and international calls as outlined below) that can be avoided if you use another communication channel. That's a real opportunity for business and IT strategists to consider.

Thumbs-Down: The "time saved" argument is one that has been used over and over again to justify technologies and for the most part - these arguments rarely deliver the level of demonstrable savings promised. Using the soft productivity argument might get the project approved - but it may not always result in benefits people can actually measure. The reason is that if you save someone 10 minutes it does not mean they will take that 10 minutes and apply it to real work. The more structured and directed the activity is (e.g., call center) the better that argument resonates. But the more discretionary the work, there a greater chance that the person will just chat with a co-worker, go grab a coffee, etc.

Anyone who travels internationally knows how expensive it is to use your hotel or mobile phone. If you spend 5 days on your international trip and make just 1 hour of calls a day, with international roaming rates, you will spend over $380 per trip on phone calls.  If instead you use Sametime to make your calls over your WiFi connection, you can avoid these international fees. In the case of our Renovations example, if only 5% of their employees make one international trip per year, that would equate to over $95K in savings a year.

Thumps-Up; Good example - there are real cost avoidance opportunities in this type of scenario.

If 1000 of the employees in Renovations  are using hosted conferencing services, like WebEx Meet Me, which charges $39/user/month, you'd be spending $470K a year. You could eliminate these recurring charges by using Sametime's emeetings…and pick up a whole lot of incremental capabilities.

Thumbs-Down: I dislike this example because IBM fails to accurately portray the total cost of ownership for an on-premise implementation of Sametime vs. a SaaS solution. So I actually would take this statement as vendor posturing.

And let's not forget that e-meetings can save you travel costs as well. We found in IBM, we spend on average around $1100 per person per business trip, which is in line with industry averages. If Renovations converted just 130 meetings during the year to online meetings, eliminating the need for an average of 3 people from traveling per meeting, they'd save over $445K annually.

Thumbs-up: Using web conferencing to reduce travel expenses is a very well-known best practice. Organizations should be looking at how they are approaching web conferencing and how that decisions aligns with where they are going with UC.

And if you operate a call center, it costs on average $10 to handle a single customer call. If Renovations cut 50 calls/day by presence and IM enabling their website, they would save up to $120K.

Thumbs-Down: This example is a stretch for me - a big stretch - most customer-facing applications on web sites that are handled by call centers do not use off-the-shelf generic IM products. They typically use real-time collaboration tools that are included within their call center suites and/or CRM applications. The reason is that call centers do a lot of multi-channel management so you do not want someone involved in an IM chat to appear available to handle a phone call or email response. You need to integrate on-hook/off-hook signaling, integrate with other customer response management tools (telephone, web, e-mail, IM, etc). IBM is correct that organizations should be looking at these tools - but incorrect that they should look at IBM and Sametime.

If you add up all these potential savings, it equates to over $1.6M in one year alone…all from an initial investment  of $450K for Sametime. ... And remember, these are undiscounted retail prices. That's 3.5X the initial investment…and the ROI just gets better and better in year 2 and beyond... And we haven't even gotten into the productivity savings.

Thumbs-Down: Productivity savings are very difficult to prove. As I mentioned up above - the more transactional and structured the work environment, then time saved arguments can actually be proven in many instances. When information/knowledge workers are involved, there's more leeway in how work is done making productivity a difficult thing to prove. We can pontificate on the productivity savings coming from UC - they make for nice project proposals. But it's very difficult to prove the "because of this, therefore that" impact on real operational savings and impacts to the bottom line.

The Sametime Blog