I have written a great deal about the rise of streams — also called microblogging, activity streams, and other names — and the application of streams in the business context, but yesterday’s ‘Microsharing’ panel at the Enterprise 2.0 conference demonstrated that there is widespread disagreement, confusion, and even antipathy about streams in business. So I thought I would collate a few thoughts into something resembling a business case for streams, and throw it out there. (Note that this is also a dry run for a section of the upcoming Microstreams In Business research report: see www.stoweboyd.com/research.)
What Is A Stream And How Is It Different?
One thing Marcia Conner might have wanted to do yesterday might have been to actually define what a stream is.
A ‘stream’ is the implementation of a social model of interaction, relationship, and communication. Social tools are generally based on the idealization of social networks, in which people connect to other people in many ways. John might connect with Mary, who also connects to Ahmed, but John may not know or connect to Ahmed.
Streams are based on directed networks, where John ‘follows’ Mary but Mary may not ‘follow’ John back. This is derived from the public blogging model, where authors publish their work freely and anyone may choose to read those works, or to subscribe to a feed from that blog. In a sense, streams are an extension, or advance, on the basic publiching model of blogs. This is why some have chosen to call streaming ‘microblogging’, focusing on the similarity of publishing involved, and making a distinction between long-format blogging and short-format ‘microblogging’. This distinction may not be the most productive one, especially in the business context.
So, streams are based on directed networks that emulate or parallel social networks. Relative to any user, there are upstream contacts (those that the user follows, ‘following’), and the downstream contacts (those that are following the user, ‘followers’). Note that a follower can be followed, as well.
Streaming tools have two sides, too, matching the directional nature of their structure:
Sending — This is the collection of features that support a user in the creation and publishing of a stream element. As a simple example of the posting side of things, consider the an editor for Twitter like Tweetdeck that allows a user to type characters, create retweets, shorten URLs, embed photos, and so on.In the business context, users can post a wide array of different sorts of message types, depending on the tool’s ability to support them. For example, a user might post a structured request for a meeting to one or more downstream contacts by name, or using other features — hashtags, defined project names, user lists — to bring the request to the attention of specific individuals.
Receiving — The set of features that help a user make sense of the aggregated stream of posts from all those that she follows. This can include search, filtering, and expansion of post elemenst, like displaying an image that is embedded as a shortened URL. The receiving side also includes the ability to learn more about the individuals behind the posts, and to create or modify relationships with them, such as following a user you have discovered by a retweet made by one of your upstream contacts.
There are a number of other aspects of the streaming model that bear examination, and which may vary across implementations:
Profiles — Generally, users create profiles with bits of information, like name, physical location, and whatever else is socially or contextually relevant. This may include the user’s followers and following, which makes the social network accessible, a node at a time.
Gestures — Actions that users take other than actively posting can also be pushed out to the stream, like posts. So, when a user decides to follow (or unfollow) another that social gesture can be streamed. Likewise, users may indicate that they ‘like’ (or ‘dislike’) users posts. In a similar way, in a business context, more structured posts can be implemented, like appointments to meet, and acceptance of a request to meet is another sort of social gesture.
These are the basic elements of the open stream model, and given a wide variablity of understanding about it and experience with it, it is always helpful to lay it all out so that we can share terms and avoid confusion.
How Is This Different From Email, And Does That Matter?
Email is not predicated on social networks, except to the extent that the users of email are networked. The premise is that there is a universe of individuals (and perhaps named groups) to who messages can be directed. And they can send messages to you, if they know your email address.
Like streams, email has sending and receiving contexts, but there is no notion of writing an email message without addressing it to a specific list of people.
Email is addressed, stream posts are released.
Email is private, and the distribution of messages is determined by the author at the time of writing. Individuals may decide to block my messages, but they can’t opt to see all of them. This means that the effective use of the information in the message is based on the premise that the author knows who should read it.
Streams are public (within some defined ‘public’), and the distribution of messages is determined by the actions of all the members of that public. Individuals decide who they will follow, and the collective streaming of information is the result of the affiliation of all the members of the public.
In the context of business, this means that email is selective: the author selects who should read the message. Streams are elective: the eventual recipients of messages elect to receive them. And this election is principally based on the individual, not the topic, per se, although different tools may implment that very differently.
Relative to email’s selection orientation, streaming is based on the premise that individuals might be more effective if they can elect to receive information flows that are potentially useful to them, and therefore, they should be able to make the determination for themselves as to what are the best sources of information.
Looking at this as a ‘wisdom of the crowds’ sort of issue, it is more likely that information will be best distributed within any given group if each person can decide what information sources are likely to provide good information for themself, rather than leaving it up to the sources of information to decide who should have access to it. This is the argument for openness in open societies, as well, and it has an immediate and obvious analog in the workplace.
So, whenever the discussion comes around (once again) about how we already have email, and that all this streaming malarcky is nothing new, please remember that the models are quite different, and at least in some ways are an inversion of each other. Email is inherently more centralized and top-down, while streaming is inherently more distributed and bottom-up.
When we hear arguments against streaming in the business context they are often the same arguments that are made against distribution of decision-making and the value of top-down controls. I won’t go into the counter to these arguments here — they are out of scope — except to point out that bottom-up and distributed business organization is often linked to agile and resilient businesses, ones that are more likely to thrive in challenging and fast-changing circumstances.
Last Thoughts: What We Can Learn From Corporate Email
We are at a juncture in the rise of streams which is similar to the rise of corporate email. People today don’t recall the controversy about adopting corporate email in the ’70s and ’80s, and then again, web-based email in the ’90s.
One lesson to learn is that ROI studies will be asked for prior to roll-out. However, later on, when the entire company and then the world has shifted to email, senior management will realize that there is no return to a pre-email or pre-stream world, and therefore most companies will simply opt not to calculate whether the return was realized. It will be moot. (See Lee and Sproul, Connections, for a detailed examination of this around corporate email.)
The second lesson is interoperability and standards. Corporate email led to a a Cambrian explosion of email products that were largely non-interoperable. It took years to get different systems to intercommunicate, so large companies often had three or more unintegrated email solutions, based on acquisitions, or different groups in different countries making differently local decisions.
We need to start thinking about interoperable streams, from the outset. For example, I have been advocating interoperability of the tumble blog model for some time, which is a specific subset of the more general streams model. Since we have some much innovation going on, this is likely to turn out to be like the SQL standard, which was the intersection of the leading implementations of the SQL model of databases. At any rate, businesses looking to roll out streams in their companies should definitely put pressure on the vendors to commit to interoperability in the next few years, before this gets away from us.
