Whatever Happened to Knowledge Management?

Information Technology is a dynamic field, one often driven by buzzwords and fleeting trends. Sometimes these trends continue for decades, other times they fade somewhat quickly. One trend that experienced that fate seems to be Knowledge Management (KM). I recall first hearing about it in the early 2000’s and at that time it seemed to encompass several classes of subordinate technologies including but not limited to the following:

• Document Management
• Content Management
• Search technology (various)
• Business Intelligence (A.K.A. Decision Support or Analytics)
• Metadata Management
• Learning Management

It also tended to include more specialized tools such as knowledgebases or FAQ generators and it potentially seemed to include more integrative content-focused technologies such as Wikis. For a time KM seemed poised to also include a wide range of Semantic technologies as well. However, in the last two years or so in particular, the term Knowledge Management has seemingly dropped off of the map. I was wondering to myself why this may have happened and whether anything in particular had replaced it.

To be sure, there are a couple of related trends that have dominated the IT landscape in the past two or three years; the most significant of those being Data Science & Big Data. However, neither of these seems to fulfill the role KM was being groomed for over the previous decade. In fact, in some ways these more recent trends have become much less specific in regards to their expectations or scope (which has actually become a problem for both of them). This situation may actually help to explain what happened to Knowledge Management - perhaps the original scope was too expansive? But was it just a scope issue?

I want return again to the core or implied premise associated with Knowledge Management, that there ought to be some sort of enterprise-wide ability to help unify all of these knowledge related functions or processes and resources. The problem with this premise is related to the scope, in that there isn’t one product group of technologies associated with it, but rather a fairly large set of technologies – some of them not closely related at all other than in a philosophical sense – in other words that they could be construed as part of a larger knowledge ecosystem. So, we seem to be missing an industry impetus, but we also seem to be lacking any sort of agreed upon knowledge process or framework that would necessarily help to tie all of these diverse technologies together. This latter problem takes us deep into the heart of the larger philosophical question which KM seemed to be begging – e.g., what is the difference between information and knowledge? That isn’t an easy question to answer – and in some sense parallels my recent discussion on Artificial Intelligence versus Artificial Thought. In fact, AI could even be considered as part of KM depending on how you look at it.

So back to the tough question, what makes data or information become knowledge? Is that dependent on adding value to the data or information though specific types of processes or is it merely in the integration and analysis of such source data that the source transcends itself to become knowledge? Or is knowledge only something we can consider in a collective sense; with the sum total of all data assets being knowledge potential of some sort? These types of questions may have been raised during the years that KM was discussed actively but I think never properly answered.

You might have noticed from my initial list of related technologies that I seemed to have left out Data Management or Information Management. Either of those could potentially be considered to be part of a knowledge management framework – however the reason I left them out is that for those fields, there is a much better operational understanding of how those type of technologies work. In fact, the view from with one of these areas, Data Management overlaps quite a bit with some of what I’ve attributed to Knowledge Management (one need only look at the DMBOK to see this illustrated). Thus Data Management as a trend has continued (for decades now), primarily concerned with operational maintenance of a number of unrelated technologies without the implied necessity to integrate it all into something transcendent across the enterprise.

What if we did wish to settle the deeper question though, regarding the differing expectations between operational management of source data and knowledge exploitation? It is now 2017, are we in a position to define an integrative knowledge framework and if so what would the philosophical foundation consist of? Moreover, would coming up with this type of framework help to redeem the dimming trends of Big Data and Data Science? I think it’s worth trying to answer the question and also worth taking a shot at defining the missing knowledge framework. I will tackle both parts of this problem in two upcoming posts…

Copyright 2016, Stephen Lahanas

Read More

The Strange Case of SharePoint

In 1998, I was working on a project for the US Air Force; we were assigned to deploy the first iteration of the AF Portal. This was part of a larger project called GCSS-AF (Global Combat Support System); specifically, our portion was referred to as the Headquarters Information Program or HIP.  I always liked that acronym.

We were viewing the problem through the lens of managing n-tier architecture layers. The presentation layer was divided into what we'd consider "Services" these days and consisted of:

• Collaboration
• Security
• Portal Personalization

As part of our preliminary analysis and architecture effort, we were tasked to evaluate the various COTS (Commercial Off-The Shelf) software that was available to handle these capabilities. This is how I was first introduced to "Site Server." For those of you who might remember, Site Server is what SharePoint used to be referred to during the 1990's (SharePoint first appeared as a product name in 2001). In many ways it was quite similar to what exists in SharePoint today with the primary exception that it had a variety of e-commerce features that were later split out into what has now become Microsoft Commerce Server.

SharePoint began life as Site Server

As we progressed on our project, we zeroed in on collaboration-related capabilities and split off a sub-project called CWE - or Collaborative Work Environment. At the time, there were quite a number of commercial portal platforms to choose from and the DoD hadn't made a 100% commitment to Microsoft as yet (both as a desktop application and as a network management platform). Some folks were concerned about security, others about flexibility if we became too deeply dependent on one vendor and of course we had the immediate concern as to whether we could find a platform that would meet our Collaboration requirements.

I was very optimistic that we'd find the right tool and that adoption would progress rapidly and smoothly. Some older program managers on the project though kept warning me that the user base wasn't ready for the cultural implications of something like SharePoint. I dismissed those warnings as pessimism, at least at first. Why wouldn't users want to take advantage of document management, elimination of shared drives, the introduction of online meetings and more. Tools like Webex were just beginning to become well-known at this time and we had a list of synchronous and asynchronous features we were hoping to deploy. Site Server seemed strong on document management yet fairly weak in most other areas of collaboration so despite some early positive feedback was dropped from our evaluation.

Fast forward 10 years or more. After deploying many types of collaboration and portal tools, the DoD is moving to standardize on guess what, SharePoint.  One might well wonder what happened; even more interesting, SharePoint is enjoying a resurgence in corporate environments as well. Has the solution improved so radically over the years? Why did this happen?

I have used SharePoint off and on all during the last decade and despite there being some gradual improvements, it's not the killer collaboration app we were thinking about back in 1998/1999. The question that's puzzled me is whether my mentor back in 1998 was right; are large organizations culturally unprepared for true virtual collaboration and if so what form will it really need to take to be adopted? Right now it seems as though we're facing two somewhat different paradigms for collaboration - sort of a SharePoint versus Facebook showdown. Maybe we could define the contrast between the two approaches as informal (social media based) vs. formal collaboration. Can these be combined and how long does it take to acclimate complex organizations to really use tools like this?

Does Mark Zuckerberg use SharePoint at Facebook, good question...

These are questions that are immediate and pertinent to most large organizations today. I've sat in meetings on this very topic at three different commercial clients over the past two years and of course as noted previously the federal government is viewing collaboration as a service and looking (at least for now) at the formal, SharePoint paradigm to facilitate those services. So, why do I call this a strange case - 14 years later - with minimal improvements SharePoint won a battle I thought it had soundly lost while dozens of more interesting products bit the dust during the interim. Often times a product itself is a secondary consideration to process and process is very often dependent upon organizational culture. Even though most of us view the emerging technical products and trends we hear about in the media as overnight phenomena, they usually in fact involve years of behind the scenes acclimatization with similar products or technologies (many of which are soon forgotten).  SharePoint has the unique distinction of developing its own unique trend-line that after a decade finally led to its mass adoption...

Copyright 2012, Semantech Inc. All rights Reserved 

Read More