Implementing Web 2.0 Inside the Castle Walls

All the buzz about Web 2.0 and Enterprise 2.0 is exciting and good for theoretical discussions and all, but how do you actually go about doing something about it?

In response to one of my previous posts zyxo commented that Enterprise 2.0 is not just Web 2.0 inside the firewall. True. It is certainly not just implementing technology, for sure. But it is also more than just thinking differently. It is acting differently and managing knowledge differently. And that change is impossible using the traditional business applications that are built on old assumptions about security, ownership, and usage. So at some point you must tactically bring social software into the mix.

As I mentioned before, process is extremely important when you bring social software in-house. It is the process that needs to change or adapt for web 2.0 to have any impact on the business. (It won't do any good if you switch from SharePoint to wikis if no one knows its there or cannot access it due to security restrictions.)

On a more tactical level, you need to understand what usage you expect and what you don't, so you can manage the technology and its content. You need to identify success criteria so you can tell whether you are succeeding in solving a problem or not. At the same time, you don't want to apply so much control you squelch the inherent viral nature of the technology which requires users trying and learning for themselves.

More importantly, you are operating in a microcosm -- the scope of your company employees -- rather than the entire web universe. This significantly reduces the elemental power of many web 2.0 technologies and in some cases may make them totally ineffectual.

There are five ways of making the shift to web 2.0 technologies inside the firewall. (Actually, I have only seen three or four "in the wild", but there are additional options you might want to consider.) Needless to say, the most common option is not necessarily the most effective:

• Build it and they will come -- this is the process-less option. Set up a web 2.0 technology inside the firewall and let people use it as they will. This is quite common with blogs, bookmarking, and wikis. The problem is, as mentioned before, there is no way of telling if these technologies are succeeding at solving a business problem. A more inherent problem with this approach is that if your users are already using the same technology outside the firewall to manage their links, their friends, or whatever, why would they use an internal version and then have to maintain both? And if they aren't using the technology outside, what would drive them to use it inside? There is no impetus to use the service for new users and a deficit for existing users. The service tends to sit idle or be used by only a few enthusiasts.
  
• Replicate what succeeds on the web -- otherwise known as "Wikipedia inside the firewall". If it worked outside, it should inside as well, right? Well, not quite. Many times the first thing a company does with a wiki inside the firewall is try to create an internal wikipedia. Why? What information do they expect to collect here, that isn't readily available outside the firewall already? And do you have the enthusiasm for maintaining business-related content that the maintainers of Wikipedia have? Ditto blogs. Follow the external model where anyone can have a blog. Many get started, few stay alive. Why? Because, quite frankly, there are usually several other, well established, channels for sharing information within a corporation and the blogs create an alternative, competing signal.
  
• Define a process and pilot -- This is the traditional business approach: define what the technology should be used for, who should use it, and run a pilot to test it. The only problem here is that most web 2.0 technologies are dependent on a critical mass of users to be effective. Five people editing a wiki or three people blogging is not necessarily going to tell you much about the potential of these technologies. Also, because these technologies often offer new usage models (rather than computerizing existing processes) it is easy to miscalculate what processes will actually benefit from their application.
  
• Establish a service and solicit trial cases -- This is a combination of #1 and #3. I have never seen this done, but it seems like a reasonable approach. Have IT establish an internal service, then ask the business groups to propose pilots (i.e. processes to apply the service to). This will have a better chance of exposing innovative applications of the technologies to business cases and would require the declaration of the business process that it is being applied to.
• Extend existing services/processes using web 2.0 technology -- I have not personally seen this in use elsewhere (except where we are doing it ourselves) but most of the current success stories of web 2.0 inside the firewall -- such as IBM's Fringe -- involve extending or integrating existing services or applications with web 2.0 technology. Fringe adds tagging and rating of people that is integrated into an existing white pages application, as I understand it. This is possibly the most likely approach to succeed because the existing application provides an inherent process, an established audience and user base, and linkage to familiarize users with the new capabilities.

Linking web 2.0 technologies to existing systems has another benefit -- it justifies their existence. For example, social tagging inside the firewall vs. social tagging outside has little to recommend it, and a number of drawbacks. A smaller audience, less flexibility to grow and extend features, simply less exposure and name recognition than public services... On the other hand, tie that tagging to how the corporate intranet search works (automated favorites, improved relevance, best bets, etc.), and users will start to see the direct impact of their use of the internal service as well as having the service in front of them on a regular basis when they search.