Todd Biske: Outside the Box

Archive for the ‘Twitter’ Category

Rob Koplowitz of Forrester recently posted, Why Tibbr Matters. He provided some examples of where an activity stream across a network like Tibbr could add value, and some examples where it couldn’t. I responded with a comment and I wanted to elaborate on my comments here.

Activity streams tied to your company that are available through tools like Chatter, Yammer, and Tibbr have potential for adding value, but there’s some big barriers that must be overcome. In my experience, I’ve used email, Sharepoint and other other internal portals, and Yammer inside of a corporate setting, and there’s two simple objectives that these tools should have, at a minimum:

1. Moving information from the privileged few to a broader audience.
2. Making new information available that previously wasn’t.

On the first item, a challenge that probably every organization has is getting the information to the right people. The information exists, but it only spreads through word of mouth or to people that the information holders think need to be aware of it. The twitter model is the right approach for addressing this, by allowing people to follow people or topics of interest (either via saved keyword searches or hashtags), rather than having to wait until it is explicitly sent to them. In order for this model to work, however, all information must be public. As soon as private, directed messages come into play, that information is now hidden. I don’t see this as the bigger of the two challenges, however, as at least the information exists, it’s just not getting everywhere it needs to go.

The second item is the greater challenge. If there is information that simply isn’t being communicated, there is no tool that is going to magically make that information appear. The more information sources you have participating in the network, the greater potential you have for getting value out of that network. Why does everyone join Facebook? It’s the network with the greatest participation, and therefore, the greatest potential value. There’s a catch-22 here, because you want participants to get value quickly, so they stay in the network, but once you get over the hurdle, the growth will come. So how do we do this?

In a corporate setting, the participants are not just your employees. The participants must include your systems. This is why Tibbr is potentially in a good spot. Tibco’s background is not in collaboration or social media, it is in system integration. Unfortunately, all of the web-based request/response systems over the past decade have gotten us away from the asynchronous, event-based system design of the past. Even SOA tends to imply a request-response paradigm in most people minds, meaning I have to know what to ask for in advance. Both our systems and our people need to expose items of interest without any preconceived notion of who might be interested. Yes, we need to be cautious about signal to noise ratio, but I don’t think that problem is any different than trying to manage redundancy in an application or service portfolio. As part of your deployment process, get a list of the events/messages that are available, categorize them, and manage them effectively. If the Twitterverse can quickly come up with accepted hashtags, why can’t we do the same inside our corporate worlds?

Since I’ve previously asked for this year to be the year of the event, let’s do so in a way that allows these events to feed into our internal activity streams and social networking tools, and start getting real value out of these technologies.

In this, my first blog post of 2011, I’d like to issue a challenge to the blogosphere to make 2011 the year of the event. There was no shortage of discussions about services in the 2000’s, let’s have the same type of focus and advances in event’s in the 2010’s.

How many of your systems are designed to issue event notifications to other systems when information is updated? In my own personal experience, this is not a common pattern. Instead, what I more frequently see is systems that always query a data source (even though it may be an expensive operation) because a change may have occurred, even though 99% of the time, the data hasn’t. Rather than optimizing the system to perform as well as possible for the majority of the requests by caching the information to optimize retrieval, the systems are designed to avoid showing stale data, which can have a significant performance impact when going back to the source(s) is an expensive operation.

With so much focus on web-based systems, many have settled into a request/response type of thinking, and haven’t embraced the nearly real-time world. I call it nearly real-time, because truly real-time is really an edge case. Yes, there are situations where real-time is really needed, but for most things, nearly real-time is good enough. In the request/response world, our thinking tends to be omni-directional. I need data from you, so I ask you for it, and you send me a response. If I don’t initiate the conversation, I hear nothing from you.

This thinking needs to broaden to where a dependency means that information exchanges are initiated in both directions. When the data is updated, an event is published, and dependent systems can choose to perform actions. In this model, a dependent system could keep an optimized copy of the information it needs, and create update processes based upon the receipt of the event. This could save lots of unnecessary communication and improve the performance of the systems.

This isn’t anything new. Scalable business systems in the pre-web days leveraged asynchronous communication extensively. User interface frameworks leveraged event-based communication extensively. It should be commonplace by now to look at a solution and inquire about the services it exposes and uses, but is it commonplace to ask about the events it creates or needs?

Unfortunately, there is still a big hurdle. There is no standard channel for publishing and receiving events. We have enterprise messaging systems, but access to those systems isn’t normally a part of the standard framework for an application. We need something incredibly simple, using tools that are readily available in big enterprise platforms as well as emerging development languages. Why can’t a system simply “follow” another system and tap into the event stream looking for appropriately tagged messages? Yes, there are delivery concerns in many situations, but don’t let a need for guaranteed delivery so overburden the ability to get on the bus that designers just forsake an event-based model completely. I’d much rather see a solution embrace events and do something different like using a Twitter-like system (or even Twitter itself, complete with its availability challenges) for event broadcast and reception, than to continue down the path of unnecessary queries back to a master and nightly jobs that push data around. Let’s make 2011 the year that kick-started the event based movement in our solutions.

All content written by and copyrighted by Todd Biske. If you are reading this on a site other than my “Outside the Box” blog, it’s probably being republished without my permission. Please consider reading it at the source.

A succession of tweets between Forrester’s Gene Leganza and Clay Richardson along with Brenda Michelson of Elemental Links caught my attention this morning. At Forrester’s Enterprise Architecture Forum next week, Clay will be reviewing a few case studies for Social BPM. It’s too bad that I won’t be there, because this sounds very interesting.

I haven’t seen any definitions yet of what socially-enabled BPM is, so I thought I’d throw together my own thoughts. First off, let’s take two dominant social technology platforms, Facebook and Twitter. I’ve previously posted that an internal Facebook for the enterprise could be revolutionary for inter-company communication. I’ve also previously posted on the role of Twitter as an information bus. So, now combine the human-facing communication of either platform’s news/event stream, the application platform of Facebook, and toss in some process modeling, orchestration, and universal task management capabilities on top of it, and I do think you have socially-enabled BPM. What could be most compelling is if there’s a way to combine the communication features of the social technology platform for “ad hoc” processes with the more formally modeled and managed processes that are the strong suite of BPM platforms to get a better view (and hopefully better management) of the processes in the enterprise as a whole.

I look forward to hearing what others think about the case studies Clay will be presenting. This is definitely an emerging area where there are opportunities to lead the back and be revolutionary.

Update: Here’s two posts from Clay on the subject that he forwarded to me. It looks like my thinking is consistent with what he had previously written on the subject. The first is titled “Social Technologies Will Drive The Next Wave Of BPM Suites” and the second is titled “BPM Promises ‘Simplicity’ In 2010. Is This ‘Hope We Can Believe In’ Or Still A Pipe Dream?”.

Back in March of this year, I asked “Is Twitter the cloud bus?” While we haven’t quite gone there yet, Tibco has run with the idea of Twitter as an enterprise messaging bus and announced Tibbr. This is a positive step toward the enterprise figuring out how to leverage social computing technologies in the enterprise. While I think Tibco is on the right track with this, my pragmatist nature also sees that there’s a long way to go before these technologies achieve mainstream adoption.

The biggest challenge is creating the robust information pool. Today, the biggest complaint of newcomers to Twitter is finding information of value. It’s like walking into the largest social gathering you’ve ever seen and not knowing anyone. You can walk around and see if you overhear someone discussing something interesting, but that can be a daunting task. Luckily, however, there are millions of topics being discussed at any given time, so with the help of a search engine or some trusted parties, you can easily begin to build the network. In the enterprise, it’s not quite so easy.

When looking at information sharing, here are two key questions to consider:

• Are new people receiving information that they would not otherwise have seen, and are they contributing back to the conversation?
• Are the conversation groups the same, but the information content improved in either its relevance, timeliness, quality, preservation, or robustness?

If the answer to both of those is “no”, then all you’ve done is create a new channel for an existing audience containing information that was already being shared between them. Your goals must be to enable one or more of the following:

• Getting existing information to/from new parties
• Getting new information to/from existing parties
• Delivering more robust/higher quality information to/from existing parties
• Delivering information in a more timely/appropriate manner to existing parties
• Making information more accessible (e.g. search friendly)

The challenge in achieving these goals via social networking tools begins with information sources. If you are an organization with 10,000 employees, only a small percentage of those employees will be early adopters. Strictly for illustrative purposes, let’s use IT department size as a reasonable guess to the number of early adopters. In reality, a lot of people IT will jump on it, as will a smaller percentage of employees outside of IT. A large IT department for a 10,000 person company would be 5%, so we’re looking at 500 people participating on the social network. Can you see the challenge? Are these 500 people merely going to extend the conversations they’re having with the same old people, or is the content going to meet the above goals?

Now comes along Tibbr, but does the inclusion of applications as sources of information improve anything? If anything, the way we’ve approached application architecture is even worse than dealing with people! Applications typically only share information when explicitly required by some other application. How many applications in your enterprise routinely post general events, without concern for who may be listening for them? Putting Tibbr or any other message bus in place is only going to be as valuable as the information that’s placed on the bus and most applications have been designed to keep information within its boundaries unless required.

So, to be successful, there’s really one key thing that has to happen:

Both people and applications must move from a “share when asked” mentality to a “share by default” mentality.

When I began this blog, I wasn’t directing the conversation at anyone in particular. Rather, I made the information available to anyone who may find it valuable. That’s the mentality we need in our organizations and the architecture we need in our applications. Events and messages can direct people to the appropriate gateway, with either direct access to the information, or instructions on how to obtain it if security is a concern. Today, all of that information is obscured at a minimum, and more likely locked down. Change your thinking and your architecture, and the stage is set for getting value from tools like Tibbr.

In this blog on IT Business Edge, Dennis Byron discussed Facebook as an enterprise software company. His thoughts were based on a keynote address from Chris Hughes, co-founder of Facebook, given at the 2009 annual National Association for Multi-Ethnicity in Communications conference. Dennis stated that Chris indicated that Facebook is much more business friendly than what may have been the perception just two or three years ago. After reading it, it was my opinion that the position being advocated was the use of Facebook, as is, for corporate purposes. That already occurs today, but primarily as another B2C channel, used by marketing types. There are some pioneers out there doing more, but of the ones I’ve seen, it’s all about the customer/potential customer community.

In my opinion, viewing Facebook solely as a marketing/customer support channel is seriously limiting its use to an enterprise. The conversation should begin with an analysis of the communities that can be supported. Guess what? There’s a looming community with a very complicated social structure that exists within the walls of the company. Why can’t tools that are designed for enhancing communication and interaction between the social structures of society be applied within the walls of the enterprise?

Personally, I see this as having potential for a revolutionary change, rather than evolutionary change, in the way inter-company communication goes on and there’s a simple analogy to the world of SOA. Today, and even before the days of email, groupware, collaboration portals, etc., the primary model is still directed conversation. You’re either in the loop, or you’re not. To compare this to SOA, it’s a world where our focus is still on application A calling application B. What’s missing is support for undirected conversation. Combine SOA with EDA, and you have a much more powerful environment. The actions taken by application A and application B are events, and those events may be valuable to other applications. If those other applications have no visibility into those events, that value is left on the table. The same goes for our social interactions. If that information is kept private, there is value left on the table. You may counter, “It’s all out there in my SharePoint site,” but that doesn’t constitute an event-based system. While the information is there, it’s not conducive to searching, filtering, reading, etc. This is where an environment like Facebook has the potential to add much more than an email/IM/portal-based environment that is the norm today. The key is the news feed. It consists of messages from people (friends), but also from applications, coupled with more of the traditional collaboration tools of messaging, chat, file sharing, etc. While the Facebook news feed may not be quite as flexible as Twitter feeds, it’s clear that it’s headed in that direction. The key to success, however, is getting those events published. If applications don’t publish events, it’s hard to achieve the full potential of SOA and BPM. Add employees to that sentence, and it’s hard to achieve the full potential of the organization.

Unfortunately, asking a corporate enterprise to simply start using the public Facebook for these purposes is asking for too large of a leap. While I do think we will get to the point where the technology must allow the corporate communications to extend to parties outside the company, today, it’s still largely a private conversation. Requiring companies to fit their needs into the current consumer-driven, public environments is a big leap for old established companies. The right first step is an environment that packages up all the features of Facebook that are appropriate for a corporate environment and make that available initially as it’s own private world, but with a clear path to integration with the broader, public Facebook. This doesn’t mean that they’re installing it in their own data center, although that could be an option, it just means that it’s a walled garden for that company. It’s like the difference between Yammer and Twitter.

I’m looking forward to seeing more stories of companies leveraging social networking platforms inside their walls and then taking the next step of extending that to external communities as appropriate. I hope that we’ll see some case studies out of some large, established enterprises and not see adoption limited to the world of the new startups that begin with a culture built around these tools.