Activity Streams: Moving Beyond Event Aggregation

When it comes to 2011 trends, I posted earlier on "Enterprise 2.0: A Transition From Destination Site to Platform Services". Rather than publish a short list, I wanted to take some time to explore each trend in more depth. In this post, I want to examine the topic of Activity Streams.

Trend: Activity streams will continue to be a much hyped capability within social platforms. However resulting “stream glut”, interoperability, and security-related issues will threaten benefits unless better user experience design, filtering, standardization, permission models, and back-end analytics are applied. 

Level of insight: Inconvenient truth beneath the hype. Note: As a disclaimer, I am a huge fan of activity streams and the work being accomplished by those involved in the activitystrea.ms effort. I'm also optimistic that the effort can be aligned and integrated into OpenSocial.

Detail:  The concept overall is compelling – activity streams allow applications to publish events that are captured by aggregators that serialize the items into a sequence of posts (listed in reverse chronological order, newest entry first). Often items include options for people to “like”, comment, or react to the item in some manner (rating). Aggregating events into a common stream enables people to easily subscribe (“follow”) a collective set of events from one or more publishers. There are many examples of “stream-based” platforms in the consumer market (e.g., Facebook, Twitter) although FriendFeed is often cited as the reason for a standardized approach. FriendFeed harvests information from a variety of sources (music, photos, status messages), forcing the company to develop/maintain custom integrations for many different publishers and slowing down the ability to add new publishers. A common integration framework based on standard interfaces and formats would enable solution scalability and allow publishers to be added more quickly. The enterprise faces the same situation. Benefits to subscribers (or to the organization at large) include greater productivity, better collaboration, and improved situational awareness. Situational awareness also includes the ability for subscribers to “self-synchronize” with the people or systems they are following based on information signaled to them in the stream. Activity streams can also mediate social networking and community building.

Activity streams also have an interesting intersect with identity. Depending on how someone sets up publishing of their own personal activity stream, the meta data shared about themselves creates a sense of presence enabling others to be aware of their actions. (Note: In fact I have often talked about activity streams representing the next generation of the “presence” capability we associated with enterprise Instant Messaging systems.) A person’s activity stream can contain meta data about their thoughts (via status messages), travel, documents, tasks, participation in social network sites, or contributions to communities. A steady stream of this information observed over time can create a type of peripheral awareness (or ambient intimacy) for those “following” that individual. That type of insight to someone’s actions also provides a means for organizations to move beyond the type of declarative identity we see on a person’s profiles within a social network site (e.g., hobbies, interests, skills, expertise). Activity streams can:

• Reinforce the claims made on a profile by showing that competency being performed
• Amplify the strength and currency of those claims by showing how those competencies are being performed (and possibly attested to by others)
• Add additional identity insight by showing attributes not contained on the profile at all

Potential benefits however are not just accrued by people-centric activity streams. Applications of all types can also generate activities into a stream to keep people aware of system events (e.g., a new sales win, an urgent alert of some sort). As the enterprise considers how activity streams can be leveraged, we see interest in role-based streams and process-related streams. The idea is that we can improve both productivity and collaboration needs by making events more visible and allowing people to take action more effectively (sometimes collectively) based on that level of event transparency (especially when compared to how people rely on their e-mail inbox for much of this type of group notification and work coordination).

Implications: However, the level of irrational exuberance in the market regarding activity streams deserves a pragmatic examination:

As more people and applications create events published into a common stream, the resulting volume and velocity by which events “stream by” can cause people to miss something relevant. Of course, you can “follow” people and applications but the more you follow, the closer you move to the original state of too much information flowing by. People end up spending a fair about of time scrolling up and down searching for things they might have missed. Depending on the way activities are aggregated, there may be limits as to how much information is actually kept around to enable historical review. You might be limited to events over a small time period, or just to a certain number of entries. The main point is that activity streams can become just as messy and burdensome as an inbox. 

The answer some will argue is better filtering – a more advanced way to organize and view an activity stream. By creating virtualized views, or specific streams, we can reduce the “noise” and enable people to watch the activities that are most relevant to them. This is an accurate assessment and a very valid need. However not many solutions that I’ve seen offer enough options in this area. Additionally, simply adding filters solves only part of the problem; the user experience needs to also improve the way that activity streams are delivered and can be acted upon by people – the activity stream event should not be seen as an end-point but as a social object that can be further manipulated (e.g., tags), curated (e.g., people may want to bookmark or “save” an event for later reference), or shared (e.g. a notification to a colleague that creates a collaborative action). 

Activity streams will also need to respect the permission models associated with the event being signaled from a publisher. How those security aspects are applied and coordinated with the source system is another area where I do not see enough work being done in the market. There are benefits to sharing sensitive information to people in authorized roles via activity streams as long as policies are enforced. Since items in a stream are likely to also become “social objects” (further manipulated by subscribers as described earlier), it is important to consider the needs for activity streams to be monitored and archived (e.g., for compliance reasons).

There is also the possibility that activity streams will be collected in some type of store within the system aggregating events from various publishers. This scenario reinforces the need for security coordination with source system since the data within the activity stream item might need to have access controls similar to those of the “system of record”. A centralized event store does offer benefits. While much of the current discussion on the value of activity streams focuses on its “immediacy”, there is a latent opportunity for back-end analytics to run against the store to offer more retrospective analysis. This type of business intelligence functionality can correlate activity stream items over time to infer patterns, make recommendations, or signal interesting situations. In many ways, there is a complex event processing aspect to activity streams that also needs to be explored more fully. 

Below are some key points to consider:

• Initial activity stream efforts by solution providers often aggregate events only within their own platform and likely based on their own APIs
• Efforts to aggregate events from external systems may be done via proprietary APIs by vendors seeking to leverage its own existing API ecosystem
• Publishers (unless systems delivered by the same activity stream aggregator) will likely support those internal APIs initially
• Specialized vendors will leverage the lack of interoperability and standards support by larger platform vendors to provide an "overlay" model that aggregates activities from multiple sources
• Pressure to support standardization will come from customers wanting to avoid activity stream silos
• Activity stream solution providers who see interoperability and standardization as a competitive advantage will support activitystre.ms and OpenSocial aggressively

If there is a key take-away from this post, it’s that everything mentioned above reinforces the need for interoperability and standardization. Without both, there will be isolated aggregators embedded within multiple enterprise platforms (portals, collaboration, social) with no effective way for organizations to federate events across these activity stream silos. Source systems, or activity stream aggregators or IT staff, will have to write to multiple proprietary APIs to publish events into each silo. Strategists will have to resort to specialized solutions that act as an “overlay” to different enterprise platforms that are competing on the idea of being the single activity stream solution. Without an architected approach, solutions will not scale and become unmanageable as additional publishers create an unsustainable integration overhead to maintain.

Comments

[JasperWestaway]

Very interesting article. We have an activity stream in our beta product (http://oneDrum.com) for co-authoring MS Office docs.

The trouble we've found is that it is:

1. Very noisy (editing and status notifications).
2. Too disconnected from the 'presence' of other users (why respond to a thing if you don't know if they are online).

So we're toying with the old idea of a dashboard, a single view that:

1. Tries to be clever in the measurement/definition of 'activity' e.g. is this a topic for which I have implicitly/explicitly expressed an interest recently (as opposed to a mere time ordered sequence of events).
2. Overtly separate lists of activities I am directly connected to, from those going on around me.

Clearly the goal here is to get the 'right' activities in front of users. And yet... and yet... it's rather crude .. but then so are activity streams.

The amount of data in front of us will increase by orders of magnitude; open standards will accelerate that trend. We really need the mechanisms in place to automatically interpret the stream and relate them to our actual activities.

[Charlie Davidson]

Mike, thanks for the thought leadership on this issue. We have been focussed on the elements that are needed in the middle layer of this solution architecture i.e. acquire, organize, refine, deliver, socialize and analyze... the reinforcement of standards for inside the organization will be very important to everyone involved.

[twitter.com/PaulSweeney]

Great points. Love the "roll based" and "process" based views. :)