Redefining Knowledge Management

Earlier this week I asked the question; “whatever happened to Knowledge Management?” The bottom line answer to that question is that perhaps the reason this once emerging field within IT has seemingly disappeared is due to the fact that it was never properly defined in the first place. This follow-up post is dedicated to examining the philosophical question more closely and trying to draw some clearer distinctions between Information, Data and Knowledge Management. This examination in turn will then support another follow-up post where I’ll attempt to characterize what a more succinct Knowledge Management framework might look like.

Before I start, I’ll try to give some rationale as to why this ought to matter. Just because Knowledge Management wasn’t properly defined before and has largely dropped off the map within IT, doesn’t mean that it isn’t needed. There most definitely needs to be something that transcends the practice of Data Management – but before we go too deep here, let’s take a another stab at defining some of terms we’re referring to…

Information Management – This has been a catch-all term for quite some time now. Information Management could be viewed synonymously with Information Technology and thus represents an aggregate of many non-related IT technologies. There is no unifying expectation behind this term nor is it necessarily even directed at data per se. The best way to describe Information Management might be as the top level of the Taxonomy – the superset into which all other IT-related practice should fit.

Data Management (DM) – As I alluded to in the previous post, Data Management is much more focused on the operational aspects of a variety of directly and indirectly related technologies. The DMBOK (the Data Management Body of Knowledge) has taken pains to classify this more precisely through a fairly wide-ranging taxonomy, covering everything from Data Architecture & Governance to Metadata Management. Perhaps the one common denominator across all of these areas is the expectation all of the capability is either resident upon or associated with systems that house and manage data. This includes both structured and unstructured data. The DMBOK also addresses the lifecycle aspect of those capabilities, which is why it includes Data Architecture, Development and Governance.

If we look at these two definitions again, despite the likelihood of some overlap with Business Intelligence or Analytics, we might consider these terms bookends enclosing Knowledge Management, with Information Management being the top-level umbrella for all IT capability and Data Management being the foundation upon which KM capability is derived.

So that brings us back to the question, what makes Knowledge Management different than the lower-level Data Management capability categories? This of course requires us to consider the difference between information / data and knowledge. An analogy might help to illustrate the question better; one of my favorite history reads is Shelby Foote’s History of the Civil War. When writing this 3 volume masterpiece, Foote spent years examining the complete archives of official records North & South – hundreds or perhaps thousands of volumes. He synthesized all of that into a somewhat concise timeline (concise being a relative term here in that each of the volumes is around 700 pages long) and was able to both educate us and tell an extremely complex story in what appears to be a very logical fashion. In this analogy, the historical archives represent data, collected from various sources during the war and the resulting book utilized an analytic process to transform a large quantity of source information into a more compact set of Civil War Knowledge. By that analogy, then I’m insinuating that KM is both a process and product – one that rests above another foundation. Knowledge Management then must necessarily be concerned as a field or practice with both the transformative creation of Knowledge (from source data or information) as well as its effective dissemination, application or exploitation.

Let’s examine now what the key characteristics that Knowledge Management ought to consist of:

1.      The ability to aggregate source data and add value to it. As mentioned previously, this is a very near approximation to the practices of BI, Analytics and perhaps even Data Science. An open question here might whether we’d consider a Data Warehouse or Data Lake a knowledge source or a data source. I tend to think of them as the latter.

2.      The ability to extend individual analysis to collective analysis and assimilation. This is an important consideration stemming from the observation that Knowledge in general has always been considered more of a collective than an individual enterprise. While individuals may attain, create or otherwise possess knowledge, knowledge is not bound by those individuals and indeed if it is kept secret to some extent it no longer qualifies as knowledge in the traditional sense of the term.

3.      The ability to collect information from many sources and not just aggregate it, but integrate it in meaningful ways. Data Integration is also included in the DMBOK, but again it may be construed to have a more operational focus in that context. For example, the focus in data management integration may be more about interoperability whereas with KM the focus is directed more towards answering complex questions.

4.      The ability to derive new meaning from existing source information. This can occur with Data Science and perhaps Analytics as well, and I tend to think that those practices fit better within the realm of KM than DM. Again, the distinction from DM here may be the expectations associated with the analysis – the idea being that each organization eventually develops its own unique perspective – both of itself and of its industry. That perspective is based on both experiential (a posteriori) and defined knowledge (a priori) synthesized from available sources and assimilated based on filters or needs unique to the organization.

5.      The ability to harness Artificial Thought or Intelligence to add further value and perspective to source information. This is where Knowledge Management merges with other topics I’ve been discussing recently – it is also the area of greatest potential for KM. And necessarily, this combination implies that AI or AT belong as part of KM – perhaps the most important part as this is we might expect the greatest value add to occur. One sticky question that this combination raises though is the notion as to whether machine Thought or Intelligence can add enough value to turn data into Knowledge, my feeling is that the answer here is a qualified yes – qualified because the expectations driving that transformation are still pretty much derived from humans.

Back in the old days of the early 2000’s, there was a flurry of debate back and forth between the relative value or application of OLAP versus OLTP within the Analytics realm. That debate has largely subsided, but it provided us with a partial preview of the differences between DM & KM in general. If we were to distill those differences into a single thought, it might be this – Knowledge Management extends us beyond ordinary operational concerns and begins to imply some level of organizational awareness. As such, it clearly builds upon the lower tiered architectures to do more – just what can be done has hardly been tested yet. Also, in the early 2000’s there were early efforts in the military realm to create Common Operating Pictures or Data Fusion Centers. These have since evolved some and become particularly important in the context of Cyber Security. Here too, Knowledge Management is a more fitting description of what we’re trying to achieve – in this case the synthesis of potentially billions of data sources to discover hidden patterns. Some might think this is actually a discussion of Big Data – but it really isn’t. Big Data belongs squarely within the realm of Data Management as it merely another data management platform with little if any expectation as to how that data might be transformed into something else (despite all of the hype to the contrary).

We’ll wrap up this post in the series with an updated definition for Knowledge Management:

Knowledge Management (KM) is a field of practice within Information Management that builds upon a foundation provided by Data Management capabilities. KM adds value to source information in both a collective and subjective manner, helping to create unique organizational perspectives and insights through assimilation of source data into directed or targeted types of knowledge.

In my next post in this series, I will explore the architectural boundaries for the next generation of Knowledge Management capabilities.

Copyright 2017, Stephen Lahanas