Contentation Re-considered

Contentation Re-considered

Stéphane Croisier  //  Sharing ideas on the future of (Open Source) WCM, Portals, ECM and Social Software. Product Strategy Manager at Jahia (www.jahia.com). Follow me on Twitter: http://twitter.com/scroisier

Dec 14 / 4:21am

Some thoughts on the future of enterprise information streams (Part 1/2)

Everyone knows about the growing importance of status updates (microblogging) and other types of activity streams at least on public-facing social networks such as Twitter and FaceBook. Information streams are now also rapidly gaining some momentum in the Enterprise world and aim to become one the next communication pillar companies will have to rapidly integrate as part of their IT strategy. Indeed with Gartner predicting that 80% of social software platforms will include enterprise microblogging as a standard feature by 2011, there no doubt about the future durability of such a tool.

As a consequence there is nearly no one single week where a new “Twitter/Facebook for Enterprise” is not launched on the market or that a traditional business application is not getting “socialized”.

But enterprise-based information streams are also bringing their plethora of direct and indirect problems:

1)      Web-based only user experience

Most of the E20 offerings are currently only web based. They still rely on the old portal paradigm: “build and they will come”. However all professional users of some public-facing networks are using today a Rich Internet Application not the web-based channel any more. Does it mean that every enterprise application will soon have to offer its own social client? Let’s hope this won’t be the case.

2)      Lack of enterprise-grade content infrastructure for E2.0 tools

The current ultra-fast peace of innovation in the E20 world and the focus on the end-user experience rather than on the back-end content infrastructure could cause some problems in the future. Shadow IT is sometimes necessary but not everything is crappy in the traditional Enterprise Content Management world. Strangely one of the key essential pieces of the E2.0 infrastructure puzzle is vaguely defined and often under-considered in RFP: the underlying Social Graph Server. It will be interesting to guess how this one will evolve in the future years.

3)      Lack of unification among all your heterogeneous information streams

Social desktops (e.g., Tweetdeck, Seesmic,…) are now acting as your new federated information broker. They connect to all your various accounts on all your various social networks and consolidate everything into one single information dashboard. However federating several connectors and dispatching the information into different “columns” does not mean unification of all your information streams into one single chronological river of information. Beside most if not all social decks are currently not E2.0 ready. This means that a typical business worker has to multiply the number of social clients by the number of E20 tools his company plans to implement. Not an ideal situation.

4)      Multiplication of logins, social networks and other workarounds on the social Web which won’t be possible in a E2.0 context

There are lots of “workarounds” going on on the social web which are just impossible to exploit on an as-is basis within the context of a company. For example you can usually easily create on the Web as many logins as you want to either better split your audiences (e.g.: family vs business), or to manage your verbosity-level (e.g.: one account for regular followers and one account for special events) or to better manage multiple languages (e.g.: one login for English and one for French followers). Most of us are also using different social networks according to the manner we want to privately or publically broadcast our content updates. Managing multiple accounts on multiple public-facing social networks is today a common practice… which will most of the time be impossible to redo within the boundaries of your company: an employee usually has one single LDAP/AD credential.

5)      Information Overload and other Signal-to-Noise Filtering Issues

Lots of people are mentioning that email is an old crappy system full of spammers and of useless time-consuming emails they should digest for nothing. As far I am concerned I could exactly say the same from any social networks. Moving information overload from one system to another will simply not help employees improve their signal-to-noise ratio. Other improved ways of consuming content should be envisioned.

So let’s now investigate these five points in more details and bring in my personal thoughts.

1) Push your information streams on all possible channels

Forget the web as being the only exclusive content consumption tool. But rather think of it as an excellent transport protocol.

Social networks clearly simplified the creation and subscriptions to information channels compared to old-styled mailing lists. But as Danah Boyd mentioned it during the last Web2.0 conference: with the barriers to distribution collapsing, what matters is not the act of distribution, but the act of consumption”. And I am personally not sure the traditional web browser is the best media to consume all your information streams from an efficient manner.

Mark Fidelman also highlighted this point:

Luis Suarez also wrote a blog post few days ago about it: “[Posterous] still allows you to share your knowledge and collaborate with other knowledge workers in an open, public and social space by bypassing the main issue that is stopping us all from adopting these social tools in the first place even more: The Web Browsers.

As soon as you start to leverage any public or private social networks and to target “professional business users” you generally rapidly need to plan the adoption of some RIA or mobile based tools.

These new content consumption trends could generate quite a lot of problems for all traditional enterprise applications which are trying to get social. Getting social is not as easy and as simple as only being able to support such or such activity streams standards (e.g: OpenSocial or Activitystrea.ms) and to render such streams on some web pages. It is mainly about being sure that end-users will be able to rapidly consume, digest and interact with them as part of their daily life throughout the devices they prefer (RIA; Mobile; Email digests; RSS Readers, Tablets;…).

New generation of social desktops (Tweetdeck, Seesmic and similar) are doing an amazing and incredible jobs to help public-facing communities get the best from their social networks (including now with their mobile editions). But they failed to get hooks into companies and to best leverage existing E20 platforms. This is now becoming urgent that such social desktops also start offering some enterprise connectors or at least support the most basic activity streams standards.

The knowledge worker currently needs at least one social deck to manage his public-facing social networks and another one to deal with his private social networks. The situation is even worse if the company is using different E2.0 products each of them provided with its own “social deck”. I do not include all the other E2.0 applications which are also generating some kind of activity streams but without leveraging any RIA clients at all.

Your employee might then certainly want to avoid having to manage this fast proliferation of all these different social decks which are all globally providing exactly the same sets of features. I am personally not convinced that the main mission statement of server-side applications is to develop and distribute such social decks. So it would be great to see such public-facing social desktops also starting investigating the E2.0 space. Money is there and we need some vendor-neutral RIA clients which could aggregate and consolidate all the activity streams generated by all the newly socialized WCM/ERP/CRM/SoCo servers.

2) The social graph server war is just beginning

I already wrote a blog post about the risk to rapidly see emerge a large number of heterogeneous neither federated nor unified activity streams within your company private environment a few months ago.

On the public web, this federation problem was initially solved by FriendFeed. More recently Cliqset released its new FeedProxy initiative. Each Social Desktop also started to support such or such connectors towards such or such social networks and to centralize the management of all your various accounts.

But do we really want to manage this plethora of connectors and of non-compliant activity streams in the enterprise world? Not necessarily. So we could then question if a company needs not first to envision and consider how to standardize and federate all its present and future information streams before reaching the current web chaos. This includes of course all the user profiles and their social relationships which you do not want to redo on every E2.0 sub-application your company will acquire.

Currently most customers are still selecting an E2.0 solution solely based on users-oriented grid of features. They should however not forget that the adoption of a new microblogging feature, even if it sounds like a pretty basic feature at first glance, is often synonymous with the introduction of a whole new underlying social graph server which will control all your different profiles and relationships within your company for the next years. The control and the ownership of this underlying social graph server is one of the next major battles that every IT software company currently tries to control. This Social Graph Server will rapidly become the centerpiece and heartbeat of your company social ecosystem: the IT company which will control your social graph will be able to gain some significant competitive advantages in all your future IT decisions.

So make sure to not only evaluate your new E20 software tool only from an end-user perspective. You either rapidly risk to see emerge a multiplication of user profiles and sub-social graphs within your company which you won’t be able to consolidated any more or at least to have to deal with a new generation of vendor lock-in scenario: migrating all your company social relationships from one platform to another risk to be tricky.

Today nearly every E2.0 solution is embedding its own social graph server with its own user profile management features. One could then question which IT server should be in charge of managing such data within your company. Is it the mission of the new generation of E2.0 players to provide such a piece of infrastructure à la FaceBook Connect? Will we see the commoditization of a new type of “Extended Virtual Directory and Social Graph Servers” either promoted by existing back-end systems such as Active Directory+Sharepoint or by actors such as Radiant Logic? Or will we see the emergence of a new open source driven de facto standard alternative?

What is sure is that the Social Graph war is just beginning. From an IT perspective, do not forget to take a look at the big picture and to question yourself about how you want to manage and evolve your social graph in the future and which sub-system(s) will be in charge of it.

3) One Unified Information Hub but associated with Contextual Content Reuse

Proliferation of communication channels and of various social hubs is probably not so critical for public-facing social networks because most of them tend to target different audiences or simply because Facebook and Twitter are now prevailing over all other social networks. This situation might however rapidly evolve with the rapid socialization of multiple verticals (e.g: a soccer social hub directly powered by the FIFA) or more local (e.g: your local TV or radio web site) social initiatives.

In all the cases, on the enterprise side, the situation risks to rapidly evolve from a different if not negative manner. As an employee you now generally have to deal with more and more information streams. You usually have to catch up with all your public-facing activities. You also certainly have to follow your official enterprise twitter. Recent upgrades of your more traditional business application (be it your new social ECM, WCM, ERP,…) is now also bringing additional information streams to monitor. And meanwhile you still have to check your good old-fashioned email and perhaps also your Instant Messaging system. So does it still really make sense to have one distinct public social deck (or two if we include the mobile version), another one for your private network (and yet another one per Social XYZ Server) and finally one for your email client? Certainly not.

Monitoring all these different sub-systems could rapidly become painful and inefficient. This does not include the fact that it also becomes quite probable that a conversation will start on a channel and will rapidly spread out on your WCM Intranet blog and on your CRM chatter. will be perhaps commented via traditional emails or will be cross-referenced in some instant chat transcripts. This is then quite clear that, as a business user, you do not want to recompose such a distributed discussion thread manually.

So there is clearly today a need to merge and federate all communication channels into one single universal information hub. All this “(near) real-time web” hype is a distraction from the reality of our life: Nobody (excepted perhaps a financial broker) has the time nor interests to stay connected in real time to all his subject matter experts.

However everybody has to deal with more and more sources and different types of information.

Danah Boyd mentioned: “When consuming information through social media tools, people consume social gossip alongside productive content, news alongside status updates. Right now, it's one big mess. But the key is not going to be to create distinct destinations organized around topics, but to find ways in which content can be surfaced in context, regardless of where it resides”.

Two different important points to address here:

1)      No distinct destination but one single information hub mixing all your information streams

2)      Contextual-driven content reuse and consumption trend

Let’s start with the first point:

A) Your Next Unified Information Hub

You currently do not only want some level of content federation either by type of social networks or by type of content, but you also want some level of information aggregation. Generally speaking you only want to monitor one single river of information not plethora of different activity streams.

I know that I will certainly upset more than one who are already betting on the future death of the email, but I personally do not find that there are so much differences between an email client and a microblogging desktop or between an email and a status update.

Both are bringing some unique advantages and could be mutually leveraged upon in order to converge towards what could become your unique unified and federated information hub.

Are you for example seeing a lot of difference between such a “social dashboard”:

Fig 1: A Social Deck by Sobees

Versus such an old mailing lists-driven one?

Fig. 2: MarkMail Mailing Lists-focused Information Dashboard

Email clients became such a common communication system that they had to slow down their peace of innovation. Large enterprises could not afford to upgrade all their systems on a monthly basis as it is still currently the case for all free social decks. So recently email clients are looking like “laggards” or “dusty” while social desktops are suddenly looking like “innovators” and “cool”.

But finally are they not the same beast? Fundamentally speaking what is the difference between a tweet including a shortened url pointing to a blog post and an email with a meaningful title and a body you can access when clicking on it? One might even say that the situation is even worst than before in term of ease of use as you now first have to post a blog entry before being able to send your teaser (vs your email’s title) to your targeted audience.

Of course email is suffering from a lot of issues including:

1)      The content silo effect: once your email was sent to your audience it could hardly be reuse as part of your company collective intelligence. But could we really attribute this problem to the email servers? Are you sure your newly acquired “Twitter for Enterprise” is more open and standardized than your existing SMTP server? Could we impute the lack of a email archiving system to turn your email server into a shareable knowledge base only to your email server?

2)      Meaningless titles: Activity streams are bringing one key substantial advantages (among many others of course): they forced the adoption of meaningful and concise teasers which could drastically ease a more rapid way of consuming information. But here again it would be quite interesting to see results from a company which could have enforced the twitter-kind of 140 character taxonomy to its internal email+mailing lists policy?

Fig 3: No Meaningless titles any more. Ever!

On the other hand activity streams are also suffering from different problems including among others:

1)      No threaded discussion view: the first criticism you get from social networks newbies is usually: “How hard it is to follow a discussion”. But here again this is more a problem of poorly designed user interfaces rather than some technical constraints. Most of the Social Platform API allows you to get the ID of the parent status update. So it should be possible to rapidly regenerate a hierarchal or nested view of all this data.

2)      The second issue you get from end-users is generally: “If I take one week holidays, how can I catch up with my activity streams?” This is of course related to the lack of built-in archiving system and poor local indexing feature which are still making the strength of your email system. But how much time do you give to the IT industry before seeing some built-in archiving and indexing features appearing in your social deck?

So are we not finally assisting to the convergence of emails, status updates, RSS feeds and any other forms of information streams trough a new more optimal manner of rapidly consuming data through “teasers”?

Fig 4: Towards an ideal unified multi-source information teaser?

Title fields are indeed omnipresent. We could then perfectly imagine that the new universal 140 char constant could be adjusted to all kind of “title” fields (or added as a new alternative title field) as part of your email server, your bug reporting ticketing system, your articles in your enterprise blog, etc…as a new generic universal teasing mechanism which could become “tweetable”.

But the convergence will not stop here: how much time until we see all social deck being integrated with your IM status (which is by the way already the case in Gmail so why is it still not the case in my social deck?)? How much time before assisting to a merge between your RSS reader and your activity streams (the PubSubHubbub was developed for this reason, isn’t it?)? Do you really want to consume your next Google Wave blips only from within the poorly designed Google web interface?

So bit by bit your social deck is adding additional federated connectors to help you better digest all your various information streams. Or the opposite will happen and your email client will become your next social decks? For example check this blog post on some propositions to enhance Firefox Thunderbird or check some social integration as part of the new MS Outlook 2010 Social Connector. But finally who really cares which system will prevail!

Fig 5: New MS Outlook 2010 connector

I then think that we are assisting to the beginnings of the next generation of federated, socialized and multi-source information hub.

But what about the second topic:

B) Contextual Content Reuse

The context of a status update, an email or any other chunk of information is becoming more and more important.

Firstly not all information updates are mainly or only related to a time-based context which is still usually the main navigation and classification criteria in all the aforementioned information proxies. As an end-user you perhaps do not want to consume such data elsewhere than within a given context. This context could obviously be a topical group but it could also be a more innovative context such as a geolocalized area (such or such information updates will only be available in a certain geographical area).

Secondly it is also about content discovery. You do not want to come back and forth to your main information hub each time you want to consume your next content item. You also want to navigate within all your content sources from an horizontal manner based on the extracted “meanings” associated to the current context. These cross-references could of course be managed from a traditional and manual manner (manual cross-references, static menus or constant tags) but we are also assisting to the rise of new semantic algorithms which can dynamically recommend to you some context-aware reading suggestions.

The new Feedly suggestion box is a good example of such a context-aware content consumption model which can automatically extract the current “meanings” of your current article and suggest to you other related items which belong to the various sources of information you have access to.

Fig. 6: Some dynamically generated context-aware suggested readings by Feedly.

This combination of a chronological and unified information hub associated with some dynamically generated context-aware related items should make a pretty ideal, easy to use and convenient manner of consuming information from a more efficient manner for the next years.

4) Management of Your Mosaic Identity and other Facetted Information Streams

In a recent interview Ray Ozzie was correctly pointing one of the biggest problems of social networks today: the correct management of your mosaic identity.

STEVE GILLMOR: But isn’t the use case for each individual person more around figuring out what the people that you communicate with and are interested in, what they think is important rather than trying to analyze a volume of information which guaranteed is going to be irrelevant?

RAY OZZIE: I think they’re both important to different people in different mixes. How I’m interested in things that happen in my family or my close knit family is going to be a certain priority. My colleagues will be a certain priority. The larger Microsoft will still be a higher priority than what’s going on in some of the feeds that I might subscribe to or individuals that I might follow in Twitter, and it’s not an absolute of one being more important than the others for every individual.

J Allard describes it as mosaic identity; we each have different facets, and it’s hard to make generalizations about what’s important to one person or another. My son is really into gaming, and so he follows a certain community very, very well. Even though it’s a public thing, he doesn’t want to miss anything. Whereas my public stuff, I’ve just got such overload, I can’t pay attention to what’s going on out there as much as in the circles that I just have to do.

Similar to dynamic facetted search, facetted information streams will also become more and more important in the future. But what is finally a facet on a status update?

According to the activity stream definition An activity is a description of an action that was performed (the verb) at some instant in time by some actor (the subject), usually on some social object (the object). An activity feed is a feed of such activities.

In the current draft spec, you can perform such actions as Post, Share, Save, Mark as Favorite, Play, Start Following, Make Friend, Join and Tag Object. An Object could be an Article, Blog Entry, Note, File, Photo, Photo Album, Playlist, Video, Audio, Bookmark, Person, Group, Place or Comment. These actions can have such contexts as Location, Mood and Annotation.

Let’s now try to see concretely how we could apply it:

a) Topical social filtering and dynamic groups

One of the currently most well known facets is certainly the “Hashtag” which is available on Twitter and let end-users subscribe to one single topical facet without having to subscribe to all the “posters”.

The trend in the E2.0 world is currently to instantly and dynamically create sub-topical groups (it was called spaces a few months ago) based on such user generated hashtags. You can get a good idea of it by watching the latest demonstration of the future incoming Salesforce Chatter application.

However in an enterprise context these UGC tags and their associated dynamic groups could rapidly raise questions about the uniqueness and the whole lifecycle of such topical tags and groups which could be instantly created by any knowledge worker.

Are their scopes similar to some Google Wave blips (mainly around a discussion)? Or are they related to one of your company longer mid-term event or project? Should they become permanent? What if someone now wants to re-launch a second group with the same name in one year or so? Should such informal discussion groups be archive? What are their associated “file plans”? Who will be in charge of deleting such topical groups? Or merging two of them if they are too closely related? How are they linked to your current company ontology?

Such questions are certainly less critical on the public-facing social web which can pretend to be more “flexible” but this could generate quite a lot of questions in an enterprise-grade environment. And most E20 tools are still today only partially answering to all these questions.

b) Metadata-driven social filtering

You do not only have now UGC topical filters, you also have more and more associated metadata provided along each status update.

We are of course used to the basic standard metadata (e.g: date and time of your status updates, client being in use to post your status update; relations with the parent item in case of a reply;…). But we are also assisting to the apparition of more and more new automatically or manually added metadata such as geolocalized information, social ratings, relevancy or prioritization factors or other various kinds of annotations.

This extra-information will let integrators generate some new facetted oriented activity streams which could not only be filtered according to the classical chronological order but which could also be displayed and drilled down according to different axis.

Fig.7: Example of a facetted activity stream on Notrehistoire.ch developed with the Hyperweek social platform.

Similar to more traditional Business Intelligence hypercubes, facetted activity streams should allow us to enter a new age of Information Intelligence at least on real-time web updates.

c) Permissions based Social Filtering

In an enterprise context we usually have to deal with some more complex authorizations schemas: not everybody is entitled to access to all status updates on all topics even if they are considered as being one of your “friend”. This obviously also applied to the notion of groups.

As mentioned in the introduction most companies will not have the opportunity to install different social networks with only slight differences on the manner they dispatch information to their audiences. Different models exist on the open web (e.g: the Public Twitter; the (not so) private (any more) FaceBook; LinkedIn Groups;…) with different 1:1; 1:many; Many:many subscription and delivery schemas. You usually want all of them as part of your next E2.0 strategy.

Such privacy schemas are perfectly understood from social media early adopters but I personally doubt this is the case for most of the existing workforce. Usually the introduction of an E2.0 strategy aims to empower the productivity of your business workers and not to slow them down. So make sure you will not have to spend hours of training to explain to them the differences between sending an internal “public tweet” or how to restrict it to a certain audience. Such privacy settings could rapidly become counter-intuitive. Make sure to clearly understand how they work and how you can apply and customize them in your next E2.0 system.

d) From a cold information push to a hot actionable item

Finally one of the most recent trends is to not only consider an activity stream as a cold way to push data to certain followers but to let them take actions on it.

In an enterprise context this often comes back to new integration challenges. For example you may want to associate a status update with your Calendaring server in order to ease the scheduling of a meeting or with your ERP system in order to ease an order.

Fig. 8: Merge of Shared Calendaring/ToDo features through an activity streams by mixin.

We should also see the emergence of better mashup integration throughout your microblogging mechanism letting you not only consume data but also rapidly interact with other third party systems. Such a trend already started with Google Wave and the capability to attach gadgets to any one of your blips. It should rapidly come in the enterprise world as companies will try to couple the new generation of their enterprise mashup servers to their E20 initiatives.

As usual the initial microblogging idea was really easy to learn and user. This is one of the main reasons of its fast adoption rate. But as the technology matures, needs evolve and complexity increases. Imagine if you now had to enter some ACL, contexts, tags and categories, mashups and all other kind of additional metadata on every status update you generate: your usage of such a tool risks to rapidly vanish. So one of the main challenges for the future will be to try to keep this simple Web2.0 kind of user experience while still being able to provide enough data to the underlying systems to help it better exploit all the different facets of your mosaic identity.

Check the second post for the end of this article (max Posterous post limit reached!)

0 comments

Leave a comment...