Collaborative Thinking

Thoughts On Salesforce & DimDim

Old habits die hard with this post. Real-time collaboration was one of my first research areas when I became an analyst – specifically web conferencing tools. Last week, when Salesforce acquired DimDim, I scanned a lot of the initial reports and analysis of the deal. Assessments fell all across the board in terms of its implications – some positive, some skeptical. However I have not yet caught an article yet that looked at the decision-criteria issues strategists will need to address. Below, I’ve outlined some of the those issues organizations should consider when this type of situation arises in the market:

Instant Messaging (IM) & Presence

Application vs. Infrastructure

 The industry views IM as an infrastructure service (rather than an application tool) and as a feature-set within a Unified Communications platform. An IM function within an application platform creates numerous overlap situations with existing IM and presence infrastructure (e.g., user experience, costs, security, help desk support, change management, development, etc). Decision-makers can allow for exceptions from IT standards (if they exist) when there is unique business value offered by an embedded IM/presence capability. However, the organization needs to realize that there is no displacement as a result – that is – nothing goes away with the addition of an application-specific IM/presence system.

Intranet Federation

There is no standard for how IM and presence platforms interoperate “behind the firewall”. Enterprise IM platforms do not naturally “plug and play” to exchange messages and share presence information. Integration requires vendor cooperation to deliver a supportable configuration. The implication to organizations considering an application-level IM/presence solution, is creation of a “walled garden” where users need to use two different IM/presence client experiences.

Internet Federation

There is a standard for how organizations can leverage gateways to interoperate with public IM systems (e.g., Yahoo, AOL, Google, Microsoft) and other external IM systems. Usually, organizations are looking for vendors to provide a gateway to act as a policy control and enforcement point. The reason for a gateway of some type is to apply security and compliance policies, as well as to control how the identity of internal users are represented to the outside world.

Records Management

In many situations, organizations need to monitor, log, audit, and keep for historical purposes, IM session information to satisfy communication, compliance or other regulatory policy. Often, IM/presence vendors work with third-party vendors that focus on this space to deliver an end-to-end archival and records management solution.

Application Integration

Organizations have come to expect IM/presence platforms to integrate with desktop productivity tools (office suites, e-mail clients). They also expect integration with enterprise portals. The ability to “presence enable” applications and offer a “click to IM/call/conference/etc” type capability is also a well-known requirement. UC platforms also need to offer a profile card of users that can be integrated and displayed across a variety of applications.

Web Conferencing

Many of the same collisions summarized above also occur in the area of web conferencing:

Web conferencing is considered part of a unified communications platform. Organizations likely already have a conferencing solution. Adding an additional capability that is embedded within a particular application creates overlap with existing investments (audio/video conferencing, VoIP) unless there is a compelling difference or specialized applications (e.g., e-learning/LMS integration).

Web conferencing vendors have been around for some time and many have added additional modules on top of their horizontal infrastructure to meet situational needs for sales, marketing, training, and other audiences. An application-specific solution can provide deeper integration with the processes owned by that platform but creates a tension with management desires to leverage existing infrastructure that is “good enough” for the majority of use cases.

Web conferencing vendors have had to integrate with office productivity suites, e-mail/calendaring clients and even with enterprise portals (“My Conferences”, “My Recordings” portlets). Users generally need browser and desktop integration to effectively organize and schedule meetings. Also, the ability to have pre/post workspace integration is also desirable so people can share information before and after the web conference. Application integration for campaign management or for customer service purposes can also be necessary depending on how the web conferencing system is used.

Social Tools

The newer area of opportunity for real-time collaboration is integration with social platforms. The focus of social software to-date has been mostly asynchronous (e.g., blogs, wikis, community sites). The natural progression of unified communication and social software is to converge in ways that makes sense (e.g., micro-blogging, activity streams). There are compelling hybrid use case scenarios emerging for a converged solution based on unified communications and social platforms that take advantage of mobility and social networking. However, such converged solutions do not eliminate the need for solutions to address many of the foundational issues outlined above – especially those concerning integration, interoperability, security, and compliance. In other words, you still need a architecture that is not biased by a particular application workload or collection of workloads. A "platform" approach (cloud or on-premises or both) needs to handle a broad array of business requirements.

Summary

In summary, this event represents a classic horizontal versus vertical debate. When application platforms “own” capabilities that are considered common services (infrastructure), organizations need to identify the unique business value of those features and determine whether that value is greater than the overlap and complexity caused by adding redundant capabilities. Are those capabilities locked into the application itself, or are they going to become broadly available (and if so, is the application platform designed to do so). It is rare that something "goes away" when an application platform takes on infrastructure capabilities. In some cases, it may. In other cases, it may not. However, vendor due diligence is required and hopefully the points above will help decision makers in that regard.

 

Untapped Potential: Facebook & XMPP

Excellent points - and disappointing that Facebook as not leveraged this opportunity more decisively. 

Happy birthday Facebook Jabber/XMPP chat vaporware

A year ago this day, Facebook announced ”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“. The news has been greeted positively in various places everywhere.

A year later, strictly nothing happened, and that silence has not gone unnoticed. Facebook has not even issued the slightest announcement, except a wishlist bug report comment by Charlie Cheever mentioning that “some people are working on this.  It will probably be done in a few months. Sorry the timeline isn’t more clear“.

» Happy birthday Facebook Jabber/XMPP chat vaporware

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.

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

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

Enterprise Twitter: Not Dismissive, Just Realistic

Dennis raised a credible perspective in a comment to my entry on "Enterprise Twitter". I thought I would respond in a separate post since I do not have a feed specific to comments and since his comment misinterprets my position:

1. I do track these products/services and I am aware that ESME is now a part of the Apache Incubator scheme.

2. I already subscribe to the ESME blog and have for some time.

3. These points also reflect comments I hear often from enterprise IT groups (architects, infrastructure planners, etc) concerning introduction of new messaging/communication tools. Since I tend to talk to a lot of these folks, I would consider my comments constructive actually for vendors in this space to consider.

4. I am not dismissing the enterprise Twitter space in a blanket fashion. That opening comment misrepresents my position. If you examine the recent post on Enterprise 2.0 Planning Considerations I specifically call out "Enterprise Twitter" as a space to watch in 2009. I am however not wearing rose-colored glasses when pointing out the hurdles these solutions will face as they emerge within enterprise environments. I do expect that vendors putting together unified communications and collaboration platforms will be forced to address the type of social messaging represented by tools such as ESME. I would point you to some thoughts I posted earlier regarding social presence as well. In turn, ESME and like tools will need to integrate (in some instances), and interoperate (in almost all cases), with UC platforms. I suggest you look at the recent IETF proposal sponsored by Cisco and IBM regarding intranet federation for IM and presence systems - that might be food for thought on integration and interoperability/federation even though these tools are not centric to SIP/SIMPLE.

5. It's easy to throw stones at IBM and Microsoft - and yes, there are aspects of those platforms that are proprietary - but they are deployed within large enterprise environments in a dominate fashion (in addition to Cisco). Microsoft does have an asset here with its Parlano acquisition and IBM does have options to open up Sametime to handle some behaviors demonstrated by "Enterprise Twitter" tools - so game on. Twitter-like tools will not have a free-ride without competition from existing messaging/communication vendors. 

6. It is nice to hear that ESME has multiple pilots - however, pilots come and go (especially given current economic conditions). Production deployments are a better yardstick. I'll be tracking this space in 2009 and look forward to analyzing and advising organizations on how this market evolves.

@Mike I respectfully disagree with your blanket dismissal of the enterprise Twitter space in the way you have. (Declared interest in ESME as you may already know.)

You might wish to know that ESME is now a part of the Apache Incubator scheme. That gives access to a lot of thought leadership in providing tools that are not wedded to proprietary platforms and access to enterprise class development skills.

Speaking personally (my colleagues might disagree) but I see little value in aligning to IBM for instance when they have their own solution in the works and tend to exhibit an 'only made here' attitude to solution selling.

We provided solid process integrations to SAP NetWeaver as part of the early alpha and despite your reservations, have pilots ongoing in a number of places, one of which we can mention is Siemens.

I'd be happy to get our business process and technology leads to provide you with a technical briefing if that works.

In the meantime, I'd refer you to the blog: http://blog.esme.us where you can keep tabs on what's happening.

Thanks for your attention.

Enterprise Versions Of Twitter (updated)

There are several emerging (e.g., ESME, Laconica (open source), OraTweet (Oracle), SocialCast, Present.ly, and Yammer, etc.) but so far, none address to my satisfaction the issues posed below (which I happened to post on the Present.ly support forum).

Directory, Archive/Audit, Security/Compliance / Enterprise / Discussion Area - Present.ly Support

Most IT organizations will treat "Twitter-like" tools as they do Enterprise IM products which will raise questions such as:

1. Directory integration
2. Policy management (including policies assigned to people in certain roles or groups)
3. Archive (for audit, compliane, records management, etc)
4. Security (access controls, etc)
5. Integration with anti-virus and content filtering tools
6. Integration with Microsoft Communicator and IBM Sametime
7. Application development (plug-ins, integration with productivity tools)

I know there's a lot here but these tools are going to be asked such questions by many IT groups, hosted or on-premise.

Directory, Archive/Audit, Security/Compliance / Enterprise / Discussion Area - Present.ly Support

I would add one more: 8. enterprise-class administration tools to support some of the above requirements.

The biggest adoption barrier for these types of tools will be similar to what organizations have to do with any communication method re: security, records management (e.g., e-discovery), compliance and other burdens placed on enterprise IM.

(Added after posting): One thing I forgot to mention - there will be a race of sorts between IM vendors/products and these social messaging tools. For instance, can Microsoft exploit its acquisition of Parlano and deliver it as a Twitter-like service within OCS and can IBM expand Sametime to emulate the application behaviors of Twitter-like tools. The rationalization will be along the lines of "workers already spend time in their IM client so why give them another communication tool and cause them to switch back-and-forth" or "let leverage the the infrastruction deployed which already handles the archival needs", etc etc...

BTW - no response yet from the vendor.

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!

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