Social Glass

Recent discussions at work have prompted me to re-iterate something very fundamental that often gets overlooked when it comes to Enterprise 2.0. An organization will never adopt a single social productivity tool. Knowledge will ALWAYS be scattered. We’ve come to accept this on the Internet where search engines make information on a myriad sites searchable, but for some reason organizations think they can get everybody to use “wiki X”, and that the search feature in “wiki X” will be good enough.

Stop.

As Dion Hinchliffe says (and as I have written before),

“Discoverability isn’t an after thought , it’s the core”

Organizations need to embrace the fact that their data will be federated. Sure, workers will put their documents in “wiki X”, but they’ll also put them on the file share, in content management systems, and on email servers. Data that cannot be found is useless. Enterprise search will unlock data and increase the propensity for information (and the knowledge workers who create it) to be discovered. Discoverability leads to recognition, and recognition leads to increased participation. Enterprise 2.0 must be approached holistically.

Clearspace doesn’t do this. Thoughtfarmer doesn’t do this. Mindtouch doesn’t do this. There is no “Enterprise 2.0 in a box” solution. Period.

I came across a post from Dion Hinchcliffe recently that talked about ideas for SOA architects in 2007 (ok, so it’s a year old). Dion talks about how Web 2.0 philosophies can be leveraged to enhance the effectiveness of SOA. The recommendation that stood out to me was “Deeply Embracing URI Addressability”, where Dion argues:

The hyperlink is the fundamental unit of thought on the Web and it should be in your service designs and (hopefully granular) schemas as well. Giving each discrete piece of information, every service, and all content a globally addressable URI instantly gives a service, and the data it carries back and forth across its interface, access to countless new consumption and reuse scenarios.

To illustrate how unique addressability might work, consider an organization that sells insurance to customers. Each customer is given an account number. The organization has an SOA strategy and decides to make use of REST (Representational State Transfer) to expose its information assets, including “customer” in an interoperable manner.

REST “strictly refers to a collection of network architecture principles that outline how resources are defined and addressed” (Wikipedia). It also makes use of the HTTP verbs POST, GET, PUT and DELETE (similar to database CRUD operations) to define what action to take on a given resource.

The insurance company develops a REST interface that sits on top of its CRM system. Customers become uniquely addressable by account number, as follows:

http://insuranceco.corp.com/customer/9886574

where “9886574″ represents the account number for a particular customer. A “GET” request (similar to READ on a database) to this URI might return the customer profile and claim history.

This is what Dion means when he says information should be uniquely addressable. Each customer has his own URI, which means behind the firewall other applications can reference a customer using this address. From here the possibilities are endless, where the intranet starts behaving like the internet. Information assets begin having inbound links, and this “democracy” so famously publicized by Google’s PageRank algorithm (where an inbound link counts as a vote) starts to apply not just to web pages, but to entities abstracted by services in an SOA (like “customer”). In this way information can be:

• Bookmarked in a social bookmarking system. Users include comments, like “Harry Young [customer 9886574] calls in every week and I’m tired of dealing him”. Users also tag these resources in the social bookmarking system, i.e. “disgruntled”, “customer”.
• Searched through an enterprise search engine. Adding “http://insuranceco.corp.com/customer/” to the seed of our enterprise search engine causes all customer information to be natively crawled and indexed.
• Referenced from wiki and blog posts.

As a blanket statement I’d say that any SOA architect should strongly consider exposing resources in this manner so that he can leverage the network effects and unintended uses that are achievable through unique addressability.  Good stuff Dion.

No, this is not another post about combining social bookmarking and enterprise search. Instead I wanted to highlight how the social dimension of enterprise search - the search terms people use and the links they click as a result - can add to the effectiveness of an enterprise search solution.

The idea is simple:

1. Capture “fruitful” search queries - queries that cause a user to actually click a search result.
2. Capture the link, title, query and timestamp for each search result a user clicks. This can be done by re-writing the URLs to post to the search application first before redirecting to the original link.
3. Display the number of times a document has been viewed (”views:5″, as is the case with the first document in the screenshot). Documents that are viewed more than others tend to be more helpful, and this information can be useful when determining what to look at.
4. Massage the search statistics so that popular search terms are displayed in a “Search tag cloud”. This lets the user knows what the enterprise is looking for and helps create stickiness.

“Rabble” is a simple proof of concept that we developed in Ruby on Rails, and we could probably do a lot more with it. It integrates to a Google Search Appliance on the backend, and I’ve discussed how to do this integration before.

Interestingly, much of the information captured by Rabble exists inside the search appliance, and yet there’s no API to access it. Hopefully such an API is on Google’s roadmap, as information about user behavior can go a long way toward adding a valuable social dimension to enterprise search.

Over at the FASTForwardBlog, Bill Ives highlights the value of combining enterprise search with social bookmarking.  Tom Mandel recently commented on my blog about this as well, and I’ve written about this topic a few times before.

I’ve recently posted a position paper about the business value of fusing search and social bookmarking, borrowing ideas from Andrew McAfee’s post on weak ties.  You can read it over at mike2.openmethodology.org by clicking here.

Enterprise Search (the first “S” in SLATES) has long been heralded as the mechanism companies can use as a gateway to discover knowledge assets buried across the organization. I’ve discussed this topic a few times on this blog. Most enterprise search solutions integrate (at the API level) to line of business and reporting systems, meaning users can benefit from these systems without having to actually access them (try searching for “GOOG” on google.com to see how this works). Users who may not have known these systems exist now benefit from them.

But what of the other useful statistics enterprise search solutions can offer? Below I cover a few ways in which search solutions can enrich the Enterprise 2.0 and knowledge management experience.

Trends

What’s hot? What are people within the organization interested in? What documents are viewed the most? These types of statistics help showcase the collective intelligence of the enterprise and provide valuable insight into what information assets are deemed valuable, or at least interesting, by the knowledge worker base. I can see an enterprise-ready application like Google Trends (see graph above) being used to analyze and provide this kind of business intelligence.

Correlation to Taxonomies

I discussed automated content tagging a few months ago, and search engines are certainly optimized to do this. They associate keywords (tags) to documents, and this inherently creates relationships between documents. So, from a knowledge management perspective, I can see tremendous value in enterprise search solutions providing business intelligence on the richness of information assets related to a corporate taxonomy (with an element in the taxonomy being treated as a keyword by the search engine). With such a solution an organization could automatically determine that, within its Information Management group, it has 1,745 knowledge assets across 7 business units and 6 countries pertaining to “metadata management”, for example.

Information Asset Age

Enterprise search solutions also store information about when a document was created or last modified. When combined with the correlation capability, this can be valuable information for a knowledge manager. For example, if an inquiry into information assets related to “web 2.0″ revealed that 75% of those assets were more than one year old, he’d know he’s in need of an update of knowledge about web 2.0.

Conclusion

Enterprise search vendors should take a serious look at packaging enriching business intelligence capabilities into their solutions.  Search engines have a wealth of information not only about information assets but also user patterns.  Why not expose this information?