Four years ago, the success of Internet based social networking tools such as Facebook, Twitter, Foursquare and LinkedIn inspired us to start helping organisations socialise their workforce using Internet-proven paradigms such as blogging, micro-blogging, wikis etc. We’ve seen and helped organisations adopt a wide variety of tools, covering the entire social networking spectrum, from micro-blogging services such as StatusNet, ‘socialised’ content management systems such as Alfresco, to out-of-the-box social network offerings like Elgg.
Many large organisations now have either a “one-ring-to-rule-them-all” enterprise social network or a range of social platforms that are typically unconnected, as departments have independently implemented their own social strategy. As we have witnessed on the Internet, typically these enterprise social platform become silo’s of information.
Fortunately, a range of standards are emerging that should enable these systems to share information more readily.
Several years have passed since the incarnation of the federated social web movement. The last time we surveyed such platforms the lead players were Diaspora, Appleseed and BuddyCloud; these and other federated social platforms aim was to give control back to their users.
With concerns over privacy and data ownership, the federated social web seeks to standardise a set of core APIs and protocols to allow a user to choose their social platform provider, control their privacy, own their data and yet still share openly across platforms.
While the efforts of those calling for a federated social web, have yet to gain any significant user base on the Internet, in the enterprise at least, where privacy is a clear requirement, their efforts are certainly being noticed.
As noted above, most organisations have a mixture of enterprise software, and possibly several social tools. In order for the full benefits of this social capital to be realised, these systems need to interact. This interaction is also required across enterprise boundaries.
The federated social web movement has helped define several protocols that enable such interaction. Here are just a few:
Recently we have used the ActivityStrea.ms protocol to realise basic interoperability between systems for one of our clients.
An activity feed (or stream) is a list of chronologically ordered events, collated in a given context (commonly actions performed by a user or group of users). This paradigm, which has become very popular on the Internet, is seen as an effective way of conveying information to a user.
The Activity Streams protocol specifies a common format for describing activities which have occurred on a system. By establishing a standard format, it becomes possible for other systems to consume a published feed of activities, without the need for bespoke (system specific) code to interpret them.
Activities defined by the Activity Streams protocol consist of an Actor, Verb, Object and Target. Together, these elements can be combined by a consumer into a readable sentence in a format similar to that used in activity feeds found on the Internet:
Jonny wrote a Blog Post on Surevine’s Blog
On the face of it, this doesn’t seem too dissimilar to the features offered by RSS or Atom activity feeds. However, Activity Streams is designed to describe activities from the outset, and the specification contains a richer data model. Common examples of this additional data include multiple URLs, author avatars and content tags. Some of these can be seen in the JSON example below:
{
"published": "2011-02-10T15:04:55Z",
"actor": {
"url": "http://example.com/jonnyh",
"objectType" : "person",
"id": ”tag:example.com,2012:jonnyh",
"image": {
"url": "http://example.com/jonnyh/avatar",
"width": 250,
"height": 250
},
"displayName": “Jonny Heavey"
},
"verb": ”comment",
"object" : {
"url": "http://example.com/site/surevine/Document_1.txt",
"id": ”tag:example.com,2012:surevine/Document_1.txt"
},
"target" : {
"url": "http://example.com/site/surevine",
"objectType": ”site",
"id": ”tag:space.com,2012:surevine",
"displayName": ”Surevine Site"
}
}
This granular breakdown of activity metadata makes it easier for machines to interpret the event. As a result, the protocol provides much greater flexibility in terms of how the activities are consumed and represented by clients. This is beneficial when surfacing activities in multiple systems with a variety of user interfaces. Furthermore, Activity Streams is an extensible protocol, meaning custom properties can be set for an activity if required.
In contrast, AtomPub and RSS only provide a human-readable title or summary property to represent the activity, which is far less flexible in terms of machine interpretation.
The specification currently has two implementations: JSON and AtomPub. These are the carrier protocols used to encapsulate the Activity Streams data into feeds. As JSON and AtomPub are both widely supported, the integration of Activity Streams into applications should be straightforward for most organisations.
Traction for ActivityStream’s seems to have peaked, or perhaps folks are just regrouping? Several high profile backers (Facebook, BBC & others) of the standard seem to have withdrawn their support for the protocol without much in the way of a public announcement explaining the reasons.
Despite this, we are aware of several big-name organisations still using the protocol in their products / systems. Examples include SAP StreamWorks & Jive, both of which are enterprise social networking solutions. Some systems (such as Jive) provide support Activity Streams by virtue of their adoption of the OpenSocial container (which itself supports Activity Streams).
We are also aware of many other enterprise social networking products (including Yammer, Salesforce Chatter and VMWare SocialCast) which provide bespoke event feeds. These provide a very similar feature set to Activity Streams, but aren’t compliant with the standard. As a result, these applications are far less interoperable with other systems. If the application vendors had instead supported Activity Streams, their applications would be able to interact with each others at very little cost, whilst providing great value to their customers.
Within organisations, there aren’t the same commercial interests conflicting with the desire to share information amongst applications. In fact, it’s often the case that organisations want to be able to share as much information as possible with users, as they are all working towards the same goals.
It appears as though the enterprise social network vendors understand that there is a desire from organisations to improve the information flow through their IT infrastructures, and that the activity stream paradigm plays a key role in that distribution. However, they need to appreciate the value that the standardisation provides and adopt Activity Streams, instead of reinventing the wheel to the detriment of everyone involved.
Whilst the applications mentioned above support the publishing of ActivityStream feeds, most offer no support for ingesting external enterprise feeds. This is a pattern of adoption we have seen with Activitystrea.ms: many systems are publishing feeds (cf. RSS) but not supporting ingestion and aggregation from other external sources.
In order to benefit fully from the ActivityStrea.ms protocol, these systems must not only produce feeds, but also consume them.
In addition to this, there is also a lack of client support from many of the mainstream ‘feed reader’ applications such as Google Reader and Tweetdeck, though perhaps this is not as surprising given the general lack of support ActivityStrea.ms currently has on the Internet.
It seems as though there is a genuine requirement in enterprise scenarios for applications to share information, and the ActivityStrea.ms protocol is perfectly suited to this for user (and system) events. The protocol has seen reasonable uptake in the enterprise sector, specifically in terms of publishing support, which is a good start. However, client support / feed consumption is vital improve benefit to the end users.
It is our belief that the winners in the enterprise social network space will be those platforms that adopt these standards fully, as they will be able to provide the greatest value to customers.
Hopefully use of ActivityStrea.ms in the enterprise space can generate some momentum around the specification, and gradually encourage wider adoption amongst applications on the Internet. This may have already begun, with the announcement that the newly launched social network App.net will support ActivityStrea.ms.
