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.
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.