Missing Pieces: The Activity Stream Aggregator

Industry discussions on the value of activity streams have been going on for a few years. The concept is pretty straightforward. Social network sites (e.g., Facebook, Twitter, LinkedIn in the consumer space as well as many enterprise social software vendors) display a chronological list of human-readable content fragments that describe actions taken by people and applications. For example, in Facebook this capability is referred to as a News Stream. Typically, an activity stream lists status updates from the people in your social graph as well as from applications you have given permission to publish into your stream. That permission might be direct, or indirect (e.g., a “like” gesture results in a subscription subsequent updates).

Promised benefits are many. Some industry experts go as far as to claim that activity streams represent a new type of “inbox” that will replace e-mail. Other experts claim that activity streams enable work to be more “observable” enabling a new type of ambient intimacy (being able to safely watch from a distance without being directly involved in that activity). Industry strategists also position activity streams as an important mechanism for extending an individual’s social graph as well as a means people can leverage to mobile their social network connections (e.g., by posting a question into the activity stream). There is also an argument that activity streams represent a new type of “social presence” that extends presence concepts linked to unified communications (e.g., a person’s activity stream gives people a richer mental model of what someone is doing over time that presence indicators and status messages within IM clients). Activity streams are becoming an integral part of any discussion on the enterprise social graph. Mining the data store containing the sum of all activity stream items is being discussed as an opportunity for organizations to discover interesting work patterns.

What I’ve listed above is illustrative and not meant to be a finite list of possible benefits. What I’ve tried to point out though is that while there are real and significant affordances enabled by activity streams, there is some risk that as an industry, we are portraying activity streams as a panacea to whatever problem ails you as an organization. It also masks discussion of the key architectural component needed, the activity stream aggregator, which will help make the credible benefits of activity streams a reality.

Why do we need to think about an activity stream aggregator? It’s not because of where are today in the industry. Today, every enterprise SNS solution in the market aggregates activity stream items that originate within its own environment. Few, if any (none that I’m aware of), implement a standardized framework for aggregating activity stream events that occur externally (proprietary API’s don’t count). This is where the industry is heading. To succeed, there is a need for a common collection of mechanisms that enable a standardized means of aggregating activities that occur outside a particular SNS. This gap is actually what ignited work to define an industry standard (originating in the consumer space) called “activitystrea.ms”.

What drove interest in standardizing activity streams in the consumer market is linked to FriendFeed (acquired by Facebook in 2009). FriendFeed was a popular aggregator that harvested information from a variety of social sites (music, blogs, photos, status updates, etc) and expressed that information in a common format. Two design and architectural issues created a scaling challenge for FriendFeed. First not all sites offered a public interface (e.g., RSS) that resulted in construction of custom connectors. Second, a formatting process was necessary to render activity stream content in the uniform manner.  Building custom connectors clearly creates a scale issue (e.g., development time, maintenance, etc) and the lack of a common risked some loss of context and fidelity of the original content. The activity streams standard emerged to alleviate these barriers and improve interoperability between providers of social network sites and various content providers that wanted to publish into the activity stream of multiple SNS’s. 

The same activity steam dynamic (interoperability between enterprise SNS’s and internal content providers (e.g., CRM, ERP, and HRMS systems) exists today. However, the market has been slow to respond. The activitystrea.ms standard is still not widely implemented by enterprise social software vendors as well as not widely adopted by various content providers. Some of the delay could be attributed to maturity of the standard and/or competitive pressures (vendor desire to own the enterprise activity stream), but more likely we’re faced with a “which came first – the chicken or the egg” dilemma. Until content providers support the standard why should enterprise social software vendors implement the standard? Conversely, until enterprise social software vendors implement the standard, why should application vendors make their content available via activitystrea.ms? And in either situation, there is a competitive aspect that cannot be avoided – especially if that vendor is both an application/content provider and offers it’s own SNS (it can be argued that there’s some short-run advantage by being a walled garden initially). Additionally, there are valid concerns regarding security and compliance that might slow down “opening up” of certain content being published into an activity stream.

Right now, it seems like there will be a slow progression towards interoperable standards-based activity stream aggregators. Right now I see 5 major inflection points to track:

• Level 1: Enterprise SNS-specific activity stream aggregator

Where we are today.

• Level 2: Enterprise SNS + consumer activity stream aggregator

Blending in select content from consumer sites (Twitter, LinkedIn, etc).

• Level 3: Vendor-specific, portfolio-wide activity stream aggregator

Standards-based activity stream interoperability across all application and infrastructure products within a single vendor.

• Level 4: Enterprise-wide activity stream aggregator

Application content providers can all publish to various internal SNS’s and any enterprise SNS can aggregate activities from any application content provider.

• Level 5: Enterprise-wide + external business entity activity stream aggregator

A federation model emerges that enables activities to be shared across business boundaries (e.g., supply chain, etc).

On top of all this – which will take time, so clearly we are at the beginning of a long journey – we will need to deal with other important capabilities within activity streams such as filtering. I also believe that we will see “designer streams” emerge that are purpose-built for either certain audiences or specific business processes. Lastly, the data store aspects of activity streams (including security and compliance needs) and the integration of activity streams into the enterprise social graph (both topics not covered in this post), will gain higher visibility and importance as we mature beyond where we are today (Level 1).

Thoughts? 

Comments

[Alan Lepofsky]

Hi Mike. I've been doing a lot of research on this for a report on activity streams. I agree with your observations above. There are big vendors working on stream aggregation as well as startups such as http://bottlenose.com/. I'd love to chat with you about this in more detail.

[Martin Böhringer]

Thanks for this article! I agree that activitystrea.ms has still a long way to go. In fact, industry support for it seems to slow down. Therefore Hojoki, our new startup which has launched 4 weeks ago, goes the way of using proprietary APIs to aggregate activities. Our own data model bases on activitystrea.ms. I would say that Hojoki supports your level 4 scenario for teams using our supported apps (Dropbox, Google Docs...). See http://hojoki.com

[Social Designer]

Thank you for the detailed information on activity streams. Doing research on best practices and found your blog.

**Martin, loving the design for hojoki.com ...award wining for certain.
Checking out both sites now.

;)
Sandy
http://megastarmedia.com