Architecture

It still is that the Infra team/ IT department would dictate architecture based simply on what was to be puchased and linked together. For example, if we were to puchase Sharepoint LMS, then sharepoint LMS would enable file sharing etc.

System Architecture is important to any knowledge management effort - but only insofar as technology provides the REACH - not the richness. So all that technology can do is to capture and hold data and information. I think we need to constantly keep reminding ourselves that IT systems cannot create knowledge - early and enduring attempts at AI in the 80s/90s and DSS in the 90s/2000s will provide justification for what I am saying.

The RICHNESS is provided by Information Architecture. Definitions abound - but the simple connecting piece between System Architecture and Information Architecture is Taxonomy - or in simpler terms, how content is managed. I continue to be stupified by the attempts of techologists to explain that the platform will self-organise for the user.

When the Taxonomy is in place, then we can start talking about Knowledge Architecture, which despite what some might regard as a overarching concept that binds both infra and systems, is an extended and detailed attempt at linking process to workflow, and skills to practice. If those in our team refuse to talk, then we are going to have very little success with managing knowledge.

Very simply, if we do not build the practice field on the ground, and ensure that it is sustained by process, and supported by systems, then the premise and promise of knowledge management is not attainable. This is KNOWLEDGE ARCHITECTING.

However very little is available on information architecture - because it is the bread and butter of anyone who dares call themselves KM consultants, and much lesser still, in knowledge architecture - simply because it is so context sensitive.

Best Practice stops here.