Email has been and unfortunately continues to be the killer app in the collaboration space. It provides the ability to not only communicate thoughts but also to transfer ownership of responsibilities and to maintain a "paper trail".
I believe we are finally reaching a tipping point in regard to the maturity and ability of social software to not remove or replace email but instead to co-opt it. Facebook has sent the first shot over the bow of this space through their native integration of email (http://blog.facebook.com/blog.php?post=5344177130).This of course is not Enterprise ready software but the use case is powerful.
Since most organizations are not willing to limit or remove email it must instead be integrated in the overall usage model. Platform users/consumers must be able to integrate email for what its good for - asynchronous messaging. By incorporate the functionality - not just as a seperate app (even if given a footprint in the product) but as a truly integrated application the email paradigm can finally be overthrown.
Message was edited on April 28, 2013: Kelli Glass, Cisco Collaboration Community Moderator, modified this post as part of the community restructure. I moved the post, assigned a new category, and added tags for greater ease in filtering (no change to content).
The evolution of email in the enterprise will definitely involve its alignment with enterprise social software (ESS). ESS has some great features that will certainly support enterprise productivity, but the one feature it lacks is ubiquity. This is where email currently "wins". By integrating email into ESS as you describe here, we can begin to get the benefits of email and ESS together. In time pure-play email functionality will become a niche feature, supporting the type of activity it was intended for, direct private asynchronous communication.
One question that comes to play here is how to achieve this transition. Simply dumping all your email into the ESS activity stream will result in the same junk mail and noise we currently see in our inbox. The hope is that the more powerful functionality and context available in ESS systems will allow for better filtering for the inbound email stream.
Finally, and maybe, most importantly is the core concept you are presenting here, the creation of the single activity stream. When we get to the point where all of our active information flows through a single point, which we can then filter, sort and search, will we see real improvements in the effectiveness of enterprise social software systems.
It will also be interesting to see how the move to a hosted environment for email, such as the recent reports about the GSA moving to Google, will affect this space. Certainly it ties in with the notion of the need for mobility. We may indeed be reaching the tipping point, but we cannot ignore having to deal with email and integrating with it given the large use of email .Having an integrated email and calendar "client" in your ESS framework is one way to remove a barrier to adoption of ESS. It is difficult to use an ESS framework like Cisco Quad without also having email and calendar integration (which it provides). From a practical matter, we also need to account for a hosted model when performing email integrations with Cisco Quad and other collaborative frameworks and tools. Security, for instance, will be an issue in those integrations in the cloud - whether the ESS itself is hosted in the cloud or just OnPrem.
Perhaps it isn't just the integration of functionality that should be considered.
I think the integration of closed communication with select individuals (aka email) is not the only mechanism for transitioning people to a fully collaborative environment for sharing information. Another way is to create widgets to take an email thread (most emails that are forwarded, replied to, and sent have a history chain built in) and convert it to a discussion thread that is added to a community in the collaboration platform. There are some intricacies for "Permission to Share" - for example obtaining approval from appropriate parties before publishing in a community - but that is a business policy decision and not a technology issue.
I am suggesting more than a cut and paste approach - something akin to spoofing a real exchange in the collaboration space that then allows others to chime in and keeps the email bound informed of the ongoing conversation. It does two things 1) Shares the conversation with more people and 2) Helps makes those comfortable with email more comfortable with collaboration. This approach is especially useful when the email is trying to find the answer to essentially public domain information like the latest regulatory changes, hardware and software compatibility, corporate standards, etc.
This transition is not too different than the transition from analog to digital for over the air television broadcast signals - we just need to allow for those using the older approach to access the new approach and start realizing the benefits.