Tag Archives: communication

Marissa Mayer’s Yahoo! Mistake (It’s Not What You Think)

This post has been moved to http://www.forbes.com/sites/larryhawes/2013/02/28/marissa-mayers-yahoo-mistake-its-not-what-you-think/

Yammer Bangs On oneDrum

This entry was cross-posted from Meanders: The Dow Brook Blog.

Yammer logoYammer announced on Wednesday that it has acquired oneDrum, a UK-based provider of file sharing and collaborative editing tools for Microsoft Office users. Financial details of the acquisition were not disclosed. oneDrum’s technology and people will be integrated into Yammer.

In a briefing on the acquisition, Yammer CTO and Co-Founder, Adam Pisoni, stated that the deal was done to quickly accelerate movement toward Yammer’s primary strategic objective – to be the social layer, spanning key enterprise applications, in which its customers (and their extended business networks) get work done.

Yammer’s action is consistent with its strategy to release usable, but not ideal, functionality and then improve upon it as quickly as possible. Yammer introduced the homegrown Files component into its suite late last year. With oneDrum’s technology, Yammer will be able to improve its Files component by enabling syncing of files to desktop folders and mobile devices, as well as automatic sharing of new and updated files with other members of Yammer groups. As usual, Yammer seeks to occupy the middle ground, offering file sharing functionality that has some of the necessary enterprise-grade security and manageability that consumer Web services lack, while retaining as much ease-of-use as possible. Yammer’s ability to balance complexity and usability is what differentiates it from the majority of the other enterprise social software offerings in the market.

The current file creation and editing capabilities available in the Pages component of Yammer will be nicely complemented by the introduction of oneDrum’s ability to co-create and co-edit Office files (Excel and PowerPoint now, Word in development) with others. Many may interpret the addition of this capability, together with the added file sync and sharing functionality, as an indirect attack on Microsoft SharePoint by Yammer. Pisoni clearly stated that Yammer will continue to offer customers integrations with SharePoint, as well as with Box, Dropbox and other content repositories. He did, however, acknowledge that while Yammer is not intentionally targeting SharePoint, many of its customers see their Yammer networks negating existing SharePoint use cases.

Yammer’s real target appears to be email, which offers a single place where people may communicate, share content and get work done. Pisoni spoke about the symbiotic relationship between content and conversation in social networks, as well as the blurring line between content and communication. The former is clearly demonstrated by the frequency in which enterprise (and consumer) social interactions are anchored around a specific piece of content, whether that be a traditional document, blog post, wiki entry, status update, audio snippet, photo or video. The latter is evidenced by the growing enterprise use of blog posts, wiki entries and, especially, status updates to share content (and explicit knowledge) in small chunks, rather than waiting to gather it in a document that is distributed by email.

Pisoni’s assertion that the distinction between content and communication is blurring is interesting, but less persuasive. Much of the asynchronous communication within organizations is still only secondary to the content that is contained in attached (or linked) files. Corporate email use as a transmission mechanism for documents is a clear, common example. Yammer’s vision for decreasing email volume appears to involve using oneDrum’s support for real-time chat between individuals working together in an Office document (Excel and PowerPoint only at present) as a means to blend content and communication to help people get work done faster. It will be interesting to see if Yammer network members adopt this envisioned way of working as an alternative to entrenched communication and content sharing norms.

oneDrum was not well known in the U.S., as it was a very small vendor with a beta status offering. However, it appears that Yammer has made a good acquisition that will help the company, and its customers, address the changing nature of business organizations and work. The devil, of course, is in the details, so we will have to watch and see how well Yammer assimilates its first acquired company.

More on Microblogging: Evolution of the Enterprise Market

Following my post last week on the need for additional filters in enterprise microblogging tools and activity streams, I participated in an interesting Twitter conversation on the subject of microblogging and complexity. The spontaneous conversation began when Greg Lowe, a well-respected Enterprise 2.0 evangelist at Alcatel-Lucent, asked:

“Can stand alone micro-blogging solutions survive when platform plays introduce the feature?”

I immediately replied:

“Yes, if they innovate faster”

Greg shot back:

“is microblogging autonomy about innovation, or simple elegance? More features usually leads to lower usability?”

And, later, he asked a complementary question:

“is there a risk of Microblogging becoming “too complicated”?”

Is Greg on to something here? Do more features usually lead to lower usability? Will functional innovation be the downfall of stand-alone microblogging solutions, or will it help them stay ahead of platform vendors as they incorporate microblogging into their offerings?

One of the commonly heard complaints about software in general, and enterprise software in particular, is that it is too complicated. There are too many features and functions, and how to make use of them is not intuitive. On the other hand, usability is a hallmark of Web 2.0 software, and, if we make it too complex, it is likely that some people will abandon it in favor of simpler tools, whatever those may be.

But that dichotomy does not tell the entire story. Based on anecdotal evidence (there is no published quantitative research available), early adopters of Web 2.0 software in the enterprise appear to value simplicity in software they use. However, as a colleague, Thomas Vander Wal, pointed out to me yesterday, that may not be true for later, mainstream adopters. Ease-of-use may be desirable in microblogging (or any other) software, but having adequate features to enable effective, efficient usage is also necessary to achieve significant adoption. Later adopters need to see that a tool can help them in a significant way before they will begin to use it; marginal utility does not sway them, even if the tool is highly usable.

Simple may not be sustainable. As I wrote last week in this post, as enterprise use of microblogging and activity streams has increased and matured, so has the need for filters. Individuals, workgroups, and communities want to direct micro-messages to specific recipients, and they need to filter their activity streams to increase their ability to make sense out of the raging river of incoming information. Those needs will only increase as more workers microblog and more information sources are integrated into activity streams.

In the public microblogging sphere, Twitter provides a solid example of the need to add functionality to a simple service as adoption grows in terms of registered users and use cases. As more individuals used Twitter, in ways that were never envisioned by its creators, the service responded by adding functionality such as search, re-tweeting, and lists. Each of these features added some degree of complexity to the service, but also improved its usability and value.

In the evolution of any software, there is a trade-off between simplicity and functionality that must be carefully managed. How does one do that? One way is to continuously solicit and accept user feedback. That allows the software provider and organizations deploying it to sense when they are nearing the point where functionality begins to overwhelm ease of use in a harmful manner. Another technique is to roll out new features in small doses at reasonable intervals. Some even advocate slipping new features in unannounced and letting users discover them for themselves. Hosted deployment of software (whether on-premise or off-site) makes this easier to do, since new features are automatically switched on for people using the software.

So back to the original question; can stand-alone microblogging solutions fend off the collaboration suite and platform vendors as they incorporate microblogging and activity streams in their offerings? My definitive answer is “yes”, because there is still room for functionality to be added to microblogging before it becomes over-complicated.

Based on the historical evolution of other software types and categories, it is likely that the smaller vendors, who are  intensely focused on microblogging, will be the innovators, rather than the platform players. As long as vendors of stand-alone microblogging offerings continue to innovate quickly without confusing their customers, they will thrive. That said, a platform vendor could drive microblogging feature innovation if they so desired; think about what IBM has done with its Sametime instant messaging platform. However, I see no evidence of that happening in the microblogging sphere at this time.

The most plausible scenario is that at some point, small, focused vendors driving microblogging innovation (e.g. Socialcast, Yammer) will be acquired by larger vendors, who will integrate the acquired features into their collaboration suite or platform. My sense is that we are still 2-3 years away from that happening, because there is still room for value-producing innovation in microblogging.

What do you think?

Filtering Microblogging and Activity Streams

The use of microblogging and activity streams is maturing in the enterprise. This was demonstrated by recent announcements of enhancements to those components in two well-regarded enterprise social software suites.

On February 18th, NewsGator announced a point release to its flagship Enterprise 2.0 offering, Social Sites 3.1. According to NewsGator, this release introduces the ability for individuals using Social Sites to direct specific microblogging posts and status updates to individuals, groups, and communities. Previously, all such messages were distributed to all followers of the individual poster and to the general activity stream of the organization. Social Sites 3.1 also introduced the ability for individuals to filter their activity streams using “standard and custom filters”.

Yesterday (March 3rd), Socialtext announced a major new version of its enterprise social software suite, Socialtext 4.0. Both the microblogging component of Socialtext’s suite and its stand-along microblogging appliance now allow individuals to broadcast short messages to one or more groups (as well as to the entire organization and self-selected followers.) Socialtext 4.0 also let individuals filter their incoming activity stream to see posts from groups to which they belong (in addition to filtering the flow with the people and event filters that were present in earlier versions of the offering.)

The incorporation of these filters for outbound and incoming micro-messages are an important addition to the offerings of NewsGator and Socialtext, but they are long overdue. Socialcast has offered similar functionality for nearly two years and Yammer has included these capabilities for some time as well (and extended them to community members outside of an organization’s firewall, as announced on February 25th.) Of course, both Socialcast and Yammer will need to rapidly add additional filters and features to stay one step ahead of NewsGator and Socialtext, but that represents normal market dynamics and is not the real issue. The important question is this:

What other filters do individuals within organizations need to better direct microblogging posts and status updates to others, and to mine their activity streams?

I can easily imagine use cases for location, time/date, and job title/role filters. What other filters would be useful to you in either targeting the dissemination of a micro-message or winnowing a rushing activity stream?

One other important question that arises as the number of potential micro-messaging filters increases is what should be the default setting for views of outgoing and incoming messages? Should short bits of information be sent to everyone and activity streams show all organizational activity by default, so as to increase ambient awareness? Perhaps a job title/role filter should be the default, in order to maximize the focus and productivity of individuals?

There is no single answer other than “it depends”, because each organization is different. What matters is that the decision is taken (and not overlooked) with specific corporate objectives in mind and that individuals are given the means to easily and intuitively change the default target of their social communications and the pre-set lens through which they view those of others.

UPDATE (03/04/2010, 5:10pm Eastern): A commenter on this post at the Gilbane Group Blog made a really great point about how updates from Social CRM systems change the nature of activity streams. Here is his comment and my reply:

Why I Am Ignoring Google Buzz

Note: This post is purely personal opinion based on my preferences and work style. If your are looking for an analysis of Google Buzz based on methodical primary research, abort now.

I have heard many people say that their email inbox is the mother of all social networks. For me, however, email is  the antithesis of a well-built, functioning social network, because it is a communication channel, not a collaboration enabler.

I value my social networks because I can work with members of those communities to get things done. When I worked at IBM, a very large company, my email inbox was more of a proxy for the organizational hierarchy than an instantiation of my social graph. Too much of my email activity was about low value (or value-less) communications and interactions imposed by command and control culture and systems. When I needed to communicate something up or down IBM’s or a project’s chain of command, I used email. When I needed to get something done, I contacted collaborators on Sametime (IBM’s instant messaging product), the phone, or BlueTwit (IBM’s internal-only, experimental microblogging system). In short, the contacts in my large corporation email address book were more reflective of the organizational structure than of my collaborative networks.

That is precisely why Google Buzz is a non-starter for me. The Google Contact list on which it is based does not represent my collaborative network, on which I rely to get work done. Very few of the people with whom I collaborate are represented, because I don’t interact with them via email. At least not often. A quick analysis of my Google Contacts list shows that Google Voice usage contributes more actionable, valuable additions to the list than does Gmail. My Gmail inbox is filled with communications, not action items, and most of them are low-value messages from application and service vendors whose tools I have downloaded or use online.

Google’s design of Buzz demonstrates ignorance of (or disregard for?) the reality that many social interactions happen outside of email. Had I wanted to use my Google Contacts list as a social network, I would have imported it into FriendFeed months ago. Strike One.

I just mentioned FriendFeed, which was my primary social network aggregator for several months. One of the reasons I backed away from heavy usage of FriendFeed was because it became little more than another interface to the Twitter stream. Yes, it is easy to inject updates from other sources into the FriendFeed flow, but, in reality, the vast majority of updates cam from Twitter (and still do.)

I see the same thing happening with Buzz. Too many people have linked their Twitter accounts, so that everything they tweet is duplicated in Buzz. And Buzz doesn’t allow for integration of the vast number of information resources that FriendFeed does. Talk about low-value. Strike Two.

I have not taken enough swings at Google Buzz yet to have recorded Strike Three. So, for now, I have not turned Buzz off. However, I am ignoring it and will not experiment again until Google provides integration with more external social networks.

In the meanwhile, I am still looking for a social tool that blends contacts and information streams from many sources, but lets me filter the flow by one or more sources, as desired. That would allow me to work both formal organizational and informal social networks from the same tool. Gist is promising in that regard, but needs to be able to capture information from more sources with corresponding filters. Hopefully, someone will read this post and either point me to an existing solution or build it. Until then, I will have to continue using multiple tools to communicate and collaborate.

FINRA Affirms Regulation of User-Generated and Social Content

In a Regulatory Notice released earlier today, the Financial Industry Regulatory Authority (FINRA) opined that brokerage firms and their registered representatives must retain records of all communications related to the broker-dealer’s business that are made through public blogs and social media sites, such as Facebook, LinkedIn, and Twitter.

“Every firm that intends to communicate, or permit its associated persons to communicate, through social media sites must first ensure that it can retain records of those communications as required by Rules 17a-3 and 17a-4 under the Securities Exchange Act of 1934 and NASD Rule 3110. SEC and FINRA rules require that for record retention purposes, the content of the communication is determinative and a broker-dealer must retain those electronic communications that relate to its “business as such.”

Brokerage firms will now be required to archive and make discoverable business-specific content produced by their employees. They will also have to establish and maintain procedures that ensure a supervisor has either approved an interactive electronic communication before it is posted, or that a “risk-based” method of post-communication review exists and is exercised.

“While prior principal approval is not required under Rule 2210 for interactive electronic forums, firms must supervise these interactive electronic communications under NASD Rule 3010 in a manner reasonably designed to ensure that they do not violate the content requirements of FINRA’s communications rules.

Firms may adopt supervisory procedures similar to those outlined for electronic correspondence in Regulatory Notice 07-59 (FINRA Guidance Regarding Review and Supervision of Electronic Communications). As set forth in that Notice, firms may employ risk-based principles to determine the extent to which the review of incoming, outgoing and internal electronic communications is necessary for the proper supervision of their business. “

In addition, FINRA’s guidance states that all organizations under its purview must establish and communicate social media usage guidelines for their employees, and that those individuals must also receive employer-provided training on those guidelines.

“Firms must adopt policies and procedures reasonably designed to ensure that their associated persons who participate in social media sites for business purposes are appropriately supervised, have the necessary training and background to engage in such activities, and do not present undue risks to investors. Firms must have a general policy prohibiting any associated person from engaging in business communications in a social media site that is not subject to the firm’s supervision. Firms also must require that only those associated persons who have received appropriate training on the firm’s policies and procedures regarding interactive electronic communications may engage in such communications.”

FINRA’s guidance marks the beginning of a new era for financial services companies and their use of external social media. However, the Financial Services sector is not the only one that will be subject to regulation of communications made via blogs and other types of social software. An IBM Senior Product Manager related last week at Lotusphere that IBM customers in the Healthcare and Utilities industries were also beginning to ask about the management of user-generated and social content.

If your organization is currently required to comply with regulations pertaining to the use of email and instant messaging for business communication, expect to see similar requirements placed on your management of external blog and social media site posts in the near future. At some point, it is likely that these regulations will also be applied to internal communications conducted via enterprise social software.

Google Wave Protocols: Clearing the Confusion

wavelogoToday is the long-awaited day when 100,000 lucky individuals receive access to an early, but working, version of Google Wave. I hope I am in those ranks! Like many people, I have been reading about Wave, but have not been able to experience it hands-on.

Wave has been a hot topic since it was first shown outside of Google last May. Yet it continues to be quite misunderstood, most likely because it is such an early stage effort and most interested people have not been able to lay hands on the technology.

The confusion surrounding Wave was highlighted for me yesterday in a Twitter exchange on the topic. It all started innocently enough, when Andy McAfee asked:

Andy1

To which I replied:

Larry1

That statement elicited the following comment from Jevon MacDonald of the Dachis Group:

Jevon1

I am not a technologist. I seek to understand technology well enough that I can explain it in layman’s terms to business people, so they understand how technology can help them achieve their business goals. So I generally avoid getting into deep technical discussions. This time, however, I was pretty sure that I was on solid ground, so the conversation between me and Jevon continued:

Larry2

Larry3

Jevon2

Larry4

Now, here we are, at the promised blog post. But, how can Jevon and I both be correct? Simple. Google Wave encompasses not one, but several protocols for communication between system components, as illustrated in the figure below.

wave_protocols

Figure 1: Google Wave Protocols (Source: J. Aaron Farr, http://www.cubiclemuses.com/cm/articles/2009/08/09/waves-web-of-protocols/)

The most discussed of these is the Google Wave Federation protocol, which is an extension of the Extensible Messaging and Presence Protocol (XMPP). However, Wave also requires protocols for client-server and robot server- (Web service) Wave server communication. It is also possible, but probably not desirable, for Wave to utilize a client-client protocol.

Jevon was absolutely correct about the XMPP protocol enabling server-server communication in the Google Wave Federation Protocol. The Draft Protocol Specification for the Google Wave Federation Protocol lays out the technical details, which I will not explore here. XMPP provides a reliable mechanism for server-server communication and is a logical choice for that function in Google Wave, because XMPP was originally designed to transmit instant message and presence data.

It turns out that the Google Wave team has not defined a specific protocol to be used in client-server communication. A Google whitepaper entitled Google Wave Data Model and Client-Server Protocol does not mention a specific protocol. The absence of a required or recommended protocol is also confirmed by this blog post. While the Google implementation of Wave does employ HTTP as the client-server protocol, as Jevon stated, it is possible to use XMPP as the basis for client-server communication, as I maintained. ProcessOne demonstrates this use of XMPP in this blog post and demo.

Finally, there is no technical reason that XMPP could not be used to route communications directly from one client to another. However, it would not be desirable to communicate between more than two clients via XMPP. Without a server somewhere in the implementation, Wave would be unable to coordinate message state between multiple clients. In plain English, the Wave clients most likely would not be synchronized, so each would display a different point in the conversation encapsulated in the Wave.

To summarize, Google Wave employs the following protocols:

  • XMPP for server-server communication
  • HTTP for client-server communication in the current Google implementation; XMPP is possible, as demonstrated by ProcessOne
  • HTTP (JSON RPC) for robot server-Wave server communication in the current Google implementation
  • Client-client protocol is not defined, as this mode of communication is most likely not usable in a Wave

I hope this post clarifies the protocols used in the current architecture of Google Wave for you. More importantly, I hope that it highlights just how much additional architectural definition needs to take place before Wave is ready for use by the masses. If I had a second chance to address Andy McAfee’s question, I would unequivocally state that Google Wave is a “concept car” at this point in time.

Postscript: The heretofore mentioned possibilities around XMPP as a client-client protocol are truly revolutionary. The use of XMPP as the primary communication protocol for the Internet, instead of the currently used HTTP protocol, would create a next generation Internet in which centralized servers would no longer serve as intermediaries between users. Web application architectures, even business models, would be changed. See this post for a more detailed explanation of this vision, which requires each user to run a personal server on their computing device.