Knowledge is Good

Those over 40 probably recall the movie Animal House, the fictitious Faber College at which it is set, and the college’s motivational slogan, Knowledge is Good, which I’ll use as the theme for today’s post.

First off, let’s address the semantic one-upmanship that often features prominently in debates about knowledge. It goes something like:

• Data‘s not good enough, you need information
• Information‘s not good enough, you need knowledge
• Oh, knowledge isn’t good enough either, you need wisdom
• Gosh, what good is wisdom if you don’t have contentment?

This hierarchy is called DIKW in knowledge management circles. While the distinctions are pedantic, they are worth understanding (see this article or this history for more). As usual, however, I’ll take a more practical viewpoint in this post.

So let’s talk about the problem. I don’t know if this is knowledge management, information delivery, or contentment assurance, but how do you help someone who:

• Has a jammed M16A4 rifle and would like to repair it quickly, prior to engagement with an oncoming enemy?

• Is talking to a customer with a downed production website and wants to restore service immediately?

• Has just hit a flock of geese while flying a commercial airliner and lost the right engine?

• Needs to perform a complex repair procedure on a multimillion dollar PET/CT scanner?

This is what I’m thinking when I talk about knowledge management (KM) — which, I should note, is something I rarely do because, Government and Services aside, KM still suffers from negative connotations and perceptions in the marketplace (think Gartner’s trough of disillusionment).

Nevertheless, I consider myself a true believer in the idea of capturing and managing knowledge, which I’d argue is one of the few computer applications actually aimed at improving knowledge worker productivity.

(See this research paper or this presentation for interesting background on knowledge worker productivity. Read one of Tom Davenport’s books (e.g., Working Knowledge) for more general information on managing knowledge.)

But what typically goes wrong in knowledge management applications? Why does KM have a bad rap?

• Garbage in, garbage out (GIGO). I remember long ago when I ran the technical support case management system at Ingres and I found a case in the knowledge base where an engineer had diagnosed and “fixed” a backend system error through reformulating a query in our frontend, QBF. The “fix” had nothing to do with the source of the problem and its working was pure coincidence. Yet this “knowledge” was now codified in our system as a best practice. In reality, KM systems need mechanisms to ensure that people aren’t sharing urban legend as opposed to technical fact. If these aren’t in place, the system’s utility degenerates quickly.

• Excess content preparation. If it’s too hard to get content into the system, then most of an organization’s written knowledge will reside in documents on the file system and not in the KM system. Thus, in real life, people will fire up an enterprise search engine to go look for documents instead of using the KM system to go look for answers. Sometimes excess preparation is required as an over-reaction to the GIGO problem (e.g., only anointed ones can post). Sometimes, content preparation reflects a technical restriction because the KM system is designed for one granularity (e.g., answers to RFP questions) and knowledge is present at another (e.g., complete RFPs), and thus information must be decomposed, or shredded, to get into the system. In general, KM systems are major offenders when it comes to the “first step’s a doozy” problem that I discuss here.

• Non-participation by experts. When the experts in your organization boycott the KM system, it is doomed to fail. Boycotting can either be active (e.g., knowledge hoarding) or passive (e.g., laziness, skepticism). In most organizations knowledge is power and many people will feel that sharing knowledge reduces their power in and leverage over the rest of the organization.

• Information overload. Users of KM systems are not looking for potentially helpful information (as search engines typically return); they are looking for answers to specific questions. Therefore, unlike search engines, where “value” is often measured in volume — we found 10,000,000 documents about melanoma, isn’t that great? — in KM less is more. Patent examiners want one patent that eliminates a application. Doctors want one document with counterindications for amoxicillin. Pilots want one checklist for a gear-sideways abnormal landing.

Ironically, I think KM systems often fail because people try to build them using KM software. I believe that KM is simply another content application and that content applications are best built on XML content servers. Perhaps the best way to do knowledge management is not to purchase knowledge management software, but to build a content application on an XML content server instead.

What’s needed for success when you build that system?

• Fine-grained search. You want searches to return pinpoints of information, not links to documents. You want to write searches that resemble database queries in complexity and specificity. You don’t want simple Boolean expression searches that return 10,000 links to documents. You want complex queries that return a few paragraphs. This argues for DBMS with a complete query language with full-text extensions.

• Multichannel delivery. Doctors work in ERs. Scientists work in labs. Soldiers work in harm’s way. You want to be able to deliver information to whom it is needed, where and when they need it. This argues for XML as a knowledge-base format, because it’s device and delivery channel independent.

• Collaborative filtering. You want build a rating system into the content application, perhaps multiple rating systems. You might want to use e-Bay-style author feedback, Amazon-style star-ratings on content, Digg-style diggs and buries, Google-style (or Scopus-style) citation analysis, or official content certifications. This argues for a read/write DBMS, as opposed to index-only, read-only search engine.

Annotations. You want to enable annotations, such as comments or threaded discussions about comments, on the content. You want these annotations to be at any level of granularity (e.g., enabling discussion about an entire document separately from a discussion about a given paragraph in it). This argues for a read/write DBMS.

• Tagging. You want to use both taxonomy and folksonomy to tag and classify information, to enable people to find information using both search- and browse-style interfaces.

• People changes. You will need to change peoples’ attitudes and behavior towards the system. Knowledge sharing should be rewarded using the carrot, knowledge hoarding punished using the stick. People should be assigned, perhaps on a rotating basis, to periodically review, clean, and re-tag content. Competing systems, repositories, and search systems should be eliminated and consolidated in the knowledge base (provided they are within the appropriate scope). The KM system should be THE system of record for finding information.

I should mention that this isn’t a pipe dream. Most of our publishing customers sell information services that could easily be considered KM systems. jetBlue uses MarkLogic for electronic flight manuals which solve an important knowledge delivery problem. The US Army uses MarkLogic for a battle command knowledge system (BCKS), most definitely a KM application, which was described at a recent conference, here.

Whether you call it KM or not, as Shakespeare said: “that which we call a rose, by any other name would smell as sweet.”