The Failure of Knowledge Management
How a misunderstanding about logic dominates IT thinking, when we should be thinking space and time…
Knowing things, as an individual, is the most important part of being alive. Where do we get food and find kin? How do we navigate the terrain? How can we repeat procedures that are successful and avoid repeated others that aren't? We learn, and learning is often a lengthy process. The more times we rehearse or learn a lesson, the better it sits with us and the more we trust its validity. But how does knowledge scale to a group, a company, an institution, even a country? In a world of database thinking and URLs, this is one of the least well understood questions in modern IT.
Knowledge is formed from memories — that much is clear. It can exist within us, and it can be encoded into the environment around us as representations of learning, as hardware (writing or books, roads, and structures) or as software (processes, habits and culture). Memories are everywhere, not only in our brains — indeed, the bulk of memory is outside our minds; but having memories at hand is not the same as knowing something. This is the great misunderstanding about knowledge and its management. A memory has to be assigned meaning — was it something to trust or a note to distrust? Is this literal or metaphorical? Is it a personal experience or a second hand rumour?
Making knowledge useful and easy to consume has never been easy. We have books and television, lectures and practical training courses, but they don’t take away the pain of learning. If it were simply a matter of keeping records, we would never have to send anyone to school. The idea that one could somehow download knowledge as a modular data file persists throughout the IT industry in particular. In order to assimilate knowledge, we first have to become aware of what there is to know, then we have to build a relationship to fragments that make up learning. Is it about solving a problem, making furniture, knowing what to eat, or guessing the future?
The world is dynamic and formed from interacting processes. Capturing what we know of the world is about the kind of process journey we make through it. If we try to separate things without the journey context, they lose meaning — meaning that can’t be replaced by inference. Learning is for explorers not for museum curators.
The computing and software industry takes a typically naive view about knowledge management. Surely there must be a simple piece of software that one could run (some kind of database) that could keep all our knowledge and therefore make us smarter, by taking away the burden. It’s a nice idea, fuelled by interest in database technology, but of course it misses the central point — knowledge is not about collecting things, it’s about knowing things. That’s something that humans need to do for themselves.
When I envisaged the CFEngine company in 2007, I didn't believe it would be possible to sell configuration management as a business model. After all, CFEngine had already dominated the scene for more than a decade. It was free to download and ubiquitous. Configuration was a seemingly solved problem. My own thought was this: it's fairly easy to build, configure, and automate the running of large computer systems — but, understanding the monster you've created is another thing altogether. CFEngine would source its income from managing the knowledge about systems. It seemed like a good idea, but alas no one else was thinking in those terms. Industry analysts at Gartner and Forrester has partitioned the market, from the 1990s, into configuration and monitoring. You were either one or the other — you couldn't be both, or even a bridge between the two. It all changed when the web generation began to dominate the industry, and The Cloud emerged as a new way of thinking for many. Two American competitors, Puppet and Chef, made waves with their savvy sales techniques and venture capital persuasive methods to change that perception. Puppet appealed to the older system administration culture, and Chef targeted the web programmer generation and dragged CFEngine back into the core business of configuration, so that I eventually left the company as it ceased to be for any purpose I was interested in.
Expert systems, libraries, and museums
We write books not to eliminate the need for learning, but as a short cut to expedite learning — as a way to promote someone else's ideas and expose ourselves to them in a coherent way — hopefully to form our own.
By using someone else's curated knowledge, to tell a particular point of view, we hope to find a quicker path to assimilating their journey and experience for systematic training. Books curate efficient and tidy summaries of what we might need to know, but they aren't unique last words. They are particular renditions of personal stories, whether they are novels or text books on physics. That makes the process of learning from past experiences hopefully more efficient, perhaps slightly shorter, but it doesn't eliminate each person's individual journey. Knowledge is a process, just as applying knowledge is a process.
During the 1990s, AI researchers built “expert systems” to capture information and make it systematic. These were more than simple archives. They used the idea of taxonomies and ontologies to organize facts and data records into specialized subject indices. Expert systems are based on the idea of a library or museum, tailored to a specific subject. A library, with a good indexing system, should be a place to accumulate learning, no? If we separate concerns, the specialized contents for specialized contexts must surely make it easier to answer the questions as an expert does.
A warehouse makes inventory systematic, but it doesn't necessarily make it easy to assemble something from parts stored separately. We might keep table legs and tops close by, but screws in a different department. When we need to build a table, it takes effort to find all the related pieces.
Libraries and systematic storage alone don’t help us. Mere tidiness is not in itself a useful property and separation of concerns makes not an expert but what was ungraciously called an "idiot savant", before it was politically incorrect to do so.
By amputating one context from another, and arranging similar things to form a neat garden of tidy characteristics, we completely miss out on the seemingly random semantic connections that bring about our valued associative thinking.
In schools, we force ourselves to rehearse and repeat, if only by rote, i.e. into building a relationship with knowledge — so that we can make friends with subjects and ideas, and learn to trust them. Ultimately, it's the random "small worlds" associations that bring perspectives associated with expertise.
Trusted knowledge, taxidermy and friends
Today, expert systems in the old sense are typically frowned upon, because they’ve been exposed as little more than fancy databases. If you don't know what you're looking for, you'll never find anything that you couldn't find without the so-called expert. We need to have a question to get started. Experts can never replace schooling — the process of learning, of building trust.
A basic database requires a precise lookup key to retrieve some data (we need to know the proper name of something). Seeking knowledge in an encyclopedia or in a museum is like searching for a bride by looking through the telephone directory (remember those?). There is no question of relevance, because relevance is secondary to the key-value relationship, or the data model. Recognizing this problem, the simple list of the White Pages telephone directory led to Yellow Pages or service categories, i.e. what can I do for you? Now one can look up a bride who is a plumber or an electrician!
Placing specimens in storage containers, or alphabetic filing cabinets, makes them easy to search for by some category, but is no guarantee of usefulness, no matter how many subdivisions we envisage — because categories overlap. Is my sibling a sister, a daughter, or a mother? Is she Caucasian, Irish, Christian or Red Head? Classifiers are not trivially exclusive. Which room should we place a thing into?
A computer disk file system is a similar kind of database, with an additional hierarchy of directories and sub directories, for collecting similar things in one place (e.g. by taxonomy). Symbolic links were later invented to overcome their shortcomings and provide cross references by name, but searching a filesystem to find an answer is still a laborious process — unless you already know it like a friend, unless you actually planted every piece of information yourself and watched it grow into a garden of your own making. Newer graph databases allow multiple cross referencing, if used carefully, but they share the same problem.
In the 1990s, databases and expert systems were developed into Topic Maps (another typological approach to mapping out subjects by proper name, i.e. keyword and category). Instead of keeping a living experience in a glass jar (taxidermy) as a museum database would, Topic Maps try to add an index from a description of what things are. The simplest case is to use a taxonomy of types (a hierarchy of proper names) to organize the collection of records, by placing them at known locations in a map. This is also known as the famous "is a" relation much touted in Object Orientation.
Classification by type is a basically flawed idea: placing things into mutually exclusive categories in order to make them unique only works in the smallest of contexts. The technique became very popular in the nineteenth century, with biologists. For example, let's divide the animal kingdom into things that fly and things that don't fly. Okay, birds and non-birds. Oh, but then we find peacocks and dodos that are birds but which can't fly. All right, that was wrong, but what about things that lay eggs and mammals that suckle their young — oh wait, what about the platypus? And so on.
Every attempt to simply categorize complex forms will inevitably fail or lead to as many categories as there are things. Categories are only useful if they are generalizations of an idea — the problem is we tend to use them as laws to be obeyed rather than patterns to be noted.
Web crawlers have eventually been designed to scan documents for keywords by which to search. Keywords, are not data types, they are merely attribute labels of explanatory data. Writing classifying characteristics on the jar of a specimen, or on a legend in your museum is more useful than keeping a specimen hidden in a room you don't know about that secretly implies the character.
Today, we have more sophisticated tools for searching by class. Artificial Neural Networks enable a new way to index searches by dimensional reduction of episodic process fragments into classes, but the facts behind the scenes are still just frozen snapshots based on a particular set of biases. Is that captured knowledge?
Perhaps, we're getting closer. The tooling has become better informed, but the "knowledge" is still prepackaged and it's still elsewhere, and still unfamiliar to the user. Why should we trust anything that we haven't striven for ourselves?
The Semantic Web project famously developed a similar kind of map called the Resource Description Framework (RDF), around the same time of Topic Maps were being developed. This was a rather clumsy approach to linking documents with metadata, by ontology. HTML/HTTP could reference documents, but the ordinary web has no index. RDF is based on subject identifier triples, and a heap of hierarchical bureaucracy to reference online documents, but it doesn’t understand classification of ideas. The idea of logical Ontologies was developed in OWL (Web Ontology Language) to try to make a logical taxonomy of the organizing principles for classifying ideas. Topic Maps and RDF+OWL approach the issue in basically the same way, but with very different technologies.
In both cased, the naming of containers is the approach taken to organize data. This is called data typing in computer science. Programmers use data types (e.g. int, float, string, etc) to classify data. Abstract types add to these representations to offer more meaning (e.g. Book, Table, UserData), but these are in the context of a particular computer program. They don’t work in a different program. Linking together the types into a world view is the goal of Ontology.
It's not logical
In my crueller moments, I like to say that these approaches to knowledge manage management have been mostly failures. Nonetheless, many companies invest huge amounts in effort to use the standard tools — to what end? The effort that goes into making a giant map of information, and trying to name everything, might help the person who does it — but probably no one else. Those who start out cold, with a question, seeking enlightenment may learn nothing.
What's wrong? The key mistake lies in trying to program knowledge using logic. Logic is brittle and uncompromising, but knowledge is all about interpretation. You can't impose a taxonomy or even an ontology onto others — it's something you grow into, like your skin. Even biologists have given up on the taxonomy of phylogeny, and now focus on underlying combinatorics of keyword labels called genes. Even these have no unique interpretations. There is no universal map, no complete and unambiguous directory.
If your basic vocabulary is different, or your experience is another, then you can’t read someone else’s map.
Imagine trying to read a geographical map of terrain made by an animal with infrared vision, and labelled in a different language. How do you navigate roads and find your house if a map only shows you what's hot and cold?
Knowing something like a friend
We wouldn't claim to know someone having met them only once, so why do we claim to know something after reading about it once?
The key to knowledge is relationship — personal relationship. It takes time, maybe years to really know someone, their strengths and weaknesses, their reliability, whether or not we can trust their character — so that we know how to use them to help us in our own struggles. It's the same with books. Parroting something from a book is not the same as knowing the subject. Even remembering what is in the book takes several visits, but even then we don't know it. We need to repeat and revise to learn what it means in our own context. We need to get used to its style — how does the book use language? We need to know whether a source is a friend or enemy, whether it will help or harm.
Knowledge is “to know something like a friend”.
Knowing something is like knowing a person. We know what we mean when we say we know a person. We have words like acquaintance versus friend or even family to describe levels of knowing people intimately.
Naively, this is not the case when it comes to computers. In computing, we assumed that “saved” or “committed” to a database is the same as knowing. If only that were true! We are too fixated on logic in computing. We believe it has an equivalence with truth. It doesn't.
Psychologist Robin Dunbar proposed that human knowledge is based around the process of knowing through relationships, with his social brain hypothesis. He showed that the size of the neocortex in primates is proportional to the size of social groups they inhabit. Moreover, the more intimately a social group knows itself, the smaller it has to be, because it costs effort to know someone. The famous Dunbar numbers suggest that we may only know a handful of people well, but can keep ties with a hundred or so.
We can add this factoid to this the study of London Taxi drivers, whose hippocampi (a region of the brain associated with memory) are found to be larger than the average population, as they’re required to learn names and locations of streets of London, along with route maps. Our model of experts is similar — built on allowing someone (our metaphysical journey guide) to go through the pain of learning so that they know something intimately. Then, when the rest of us need to know about that subject, we can ask their advice and get a short cut to the answer we seek. Their effort is used by proxy to make our own learning more focused.
Combinatorics
We’ve learnt something fundamental from the biological world, which is that virtue of digital composition of information (recall genetics). Symbolic fragments form language. Language is the structure that comes from a symbolic memory representation. It helps communication and provides efficient structures for describing and recalling process (storage and retrieval are also communication processes).
Language is process, and process is about how we explore in space and time. The fundamental approach to knowledge is by applying principles of process in space and time. But that aspect forms the beginning of another separate story. If you can't wait for the answer, you might try exploring the potential knowledge in this book:
Summary
I once worked with a company that built a knowledge management product. Their product was built on principles that they didn’t use themselves! They would collect bits of company knowledge as recipes or HOW-TOs in a wiki, often duplicated by different titles. They would keep what they want to communicate to customers in a separate documentation system. Their product code and programmer documentation was kept in a version control system (github), etc. Every user had their own knowledge base, because no one could figure out how to use anyone else's.
Why couldn’t they maintain one system? Because the different users were just collecting information, like magpies. They were forced to do it by management, but they didn’t like the system and didn’t use it. They didn't even read it again themselves on a regular basis, so their documentation was a just mausoleum, a graveyard for text — a waste of time and space. How many of the thousands of photos you’ve taken will you ever look at again? How will you find the small few you want to see amongst the ballast of the dead weight majority? When people needed the knowledge in those documents, they didn’t know how to find it, so it was easier to invent something new each time instead. This led to a divergence of methods. How can we avoid these mistakes?
The purpose of sharing is not standardization, centralization, or even consensus. Those things don't happen by imposing limits, they can only be achieved by voluntary cooperation. The purpose of singular central standards is to document the calibration of intent that results from a social process of cooperation. It can't be forced, so it's not about imposing control or even saving cost. Knowledge is fundamentally individual, it has to work by voluntary cooperation of everyone involved. Knowing inventory is different from knowing a machine, is different from knowing an army, is different from tracking the progress of mating turtles, is different from knowing the weather or the state of the planet…, and so on.
It takes a lot of effort to build a story that we trust. An expert can tell us all the things they can think of that might be related to what we want to know — but that's not the same as telling us what we need to know or how we need to know it, because someone else's idea will not have the same context or history as our own. Knowledge is about trust in the journey we take to learn something. Knowledge may involve things and ideas, but its how they interact that matters. If we don't trust an explanation, we don't feel comfortable; we don't say we understand it. Only when we feel happy with a explanatory narrative (an emotional response) do we claim understanding. So, in the end, effective knowledge amounts to individual satisfaction.
The agility of organizations comes from their ability to move from process to process. Is there a single knowledge representation that can support any kind of process. That's not quite the right question to ask, because extracting knowledge from a representation is itself a process. The question is: how should we invest in remembering what we've learned versus retrieving what we've learned. If we want access to information to be quick, we should optimize for retrieval. If we want the information to be universal, in some sense, we should expect to have to work harder to access is in a form that's suitable for a specific task.
Maintaining coherence of purpose is the unavoidable work involved in learning. It can't be avoided. It can't be automated completely. It changes when our purpose changes. Nevertheless, there are some things we can do to make shared process more efficient.
Remember, a map is not knowledge, nor is the landscape it's based on — not until you know it, like a friend. Knowledge is rehearsal and intimacy.
If you would like help succeeding with knowledge management, contact me for consulting at contact@chitek-i.org
