I am hearing the words "Knowledge Management" more and more often.  It always seems to have a kind-of mystique about it … kind of like "oooooooOOOOoo" (a little spooky) "Knowledge Management" … "key to innovation" … "competitive differentiator" … "all ya gotta do is … Knowledge Management."

I have a friend, Alice Rigby, long since retired, who used to say, "every time I hear somebody say 'all ya gotta do is' … I put my hand on my wallet!"

Her point was, there clearly is nothing magic or mystical going on, no matter what people are saying.  The world is full of physical principles, laws of nature … and nothing is violating them, not even the most innovative new technologies or new technological concepts.  If you can't explain the physics of what is going on, then you are subject to the "silver bullet" syndrome.  You risk getting your expectations out of line with reality and are vulnerable to gross disappointment, if not despair.  And the more money you have spent, the closer to the despair end of the spectrum you are likely to be.

It probably would be prudent to define the "physics" -- the physical reality of "Knowledge Management" -- in order to avoid the "silver bullet" syndrome and maintain the opportunity to exploit the innovative aspects of this very good idea.

Here are my thoughts about the "physics" of Knowledge Management:

Granted, I am coming from an Enterprise Architecture viewpoint
and my thoughts will necessarily be biased to that view … and further,
I have a well-defined "Framework"^[1] in mind that puts definitive
specification around "Enterprise Architecture" … with that caveat,

I would argue that if you had made explicit, "all the cells of the Framework, enterprise-wide, horizontally and vertically integrated at excruciating level of detail," you would have the total, fundamental, "knowledgebase" of the Enterprise … because, if you can answer the six primitive questions (who, what, where, when, why, and how) about any subject (or object, for example, Enterprise), and if you can answer these questions from the perspective of all the primary roles within the Enterprise (that is, owner, designer, and builder … conceptual, logical, and physical), then you can derive any other answer to any other question you need to or would want to ask about the object (in our case, Enterprise) being described.

That is good, you might say, but it is limited to the descriptive information about the Enterprise itself … what about information/knowledge external to the Enterprise??  To that I would suggest that if you can't explicitly map the external information/knowledge to one or another of the Enterprise models, it is not relevant (that is, not relatable) to something about the Enterprise, and therefore, Enterprise-useless.  On the other hand, if you can explicitly map it to one of the Enterprise models, then the models are serving as a kind-of "schema" for storing the information/knowledge, which is vital if you ever want to find it (that is, the information/knowledge) again.  (I might also observe, if you can't find it, you don't have it!)

OK, that's fine, you say, but … what about information/knowledge in the minds of the employees.  To that I would suggest the same as for any "external" source of knowledge as above, even if you can get the information/knowledge out of the minds of the employees and onto some recording media (which has a number of social, political and technical challenges in itself), if you can't map that knowledge to one or another of the Enterprise models, once again it is not relevant (not relatable) to something about the Enterprise (there is no directly relevant schema) … plus you may well not be able to find it if you ever needed it.

That's OK, but … what about information/knowledge that does not lend itself to models, like text information/knowledge on documents or in books.  To that I would respond, the only thing that is making (data processing) records different from documents different from books is the length and degree of structure in the record.  The shorter the record, the more structure and the more constraints in recording the data but the easier for searching and analysis, lending itself to automation.  Conversely, the longer the record, the less structure, the less constraints in recording the data and the more difficulty in searching and analysis … that is, requiring human intervention.

However, in both cases, documents and books, there must be a "schema," if you are ever going to locate the data/information/knowledge after you record it.  For (data processing) records, the schema is called a data model; for documents, the schema is called the filing system; and for books, it is called the Dewey Decimal (or some other) system.  And, if you can't map the filing system for documents and the Dewey Decimal system for books directly to one or another of the Enterprise models, once again, it is not relevant (not relatable) to the something about the Enterprise, plus you are not likely to be able to find the information/knowledge if you ever needed it.

There is one more sticky little problem … you might say, "there is no way we are ever going to have all those Framework models, Enterprise-wide, horizontally and vertically integrated, at excruciating level of detail."  That is undoubtedly true … however, there are some portions of some models that are vital to know about (or have knowledge about) for the successful operation and/or survival of the Enterprise.  These are the ones you want to concentrate on making explicit.  Whatever models or portions of models that you do not make explicit simply bear some risk … and the risk is, information/knowledge relative to that portion of the Enterprise is not likely to be available if it should ever become necessary to know it.  And, I would suggest, there is no magic way to prevent this.  You are either going to have the models, or you are not going to have the models, and at the point in time you need the models (that is, when you need the information/knowledge), if you don't already have the models, it is probably going to be too late to build the models.  (You simply aren't going to know how that aspect of the Enterprise works.)

This brings me to my last point … Enterprise Knowledge Management.

If you want Enterprise Knowledge, somebody has to be in charge of plans and controls for Enterprise knowledge.  That is, somebody has to:

1. decide which models or slivers of models to build and which models or slivers of models the Enterprise is willing to risk leaving implicit, that is, risk not having information/knowledge about,
2. ensure the implemented systems (manual and automated) reflect the structure and intent of the explicit models or portions of models,
3. ensure the explicit models or portions of models are integrated - Enterprise-wide, horizontally and vertically,
4. ensure the explicit models or portions of models reflect the current reality of the Enterprise,
5. ensure the versions of the explicit models or portions of models are retained and maintained over time as they change,
6. ensure the explicit models or portions of models (information/knowledge) are made available or "distributed" to the appropriate parties,
7. ensure the filing system and the library system for internal and external information/knowledge are mapped to the models that have been made explicit,
8. decide which models or portions of models to continue to transform from implicit to explicit, adding to the total Enterprise body of knowledge over time.

I am trying to illustrate the point that Enterprise Knowledge Management is very, very closely tied to, if not the same as, Enterprise Architecture Management.

I learned this from observing how the Engineering and Manufacturing Discipline describes and manages knowledge about any complex engineering products.  For example, how do you think the airplane manufacturing industry was able to evolve from wood structured, cloth covered bi-planes of the Orville Wright days to titanium and composite rocket ships and moon modules of the Neil Armstrong days in a mere hundred years, when it took 7,000 years to get to the bi-planes?  They had learned not to start with a blank sheet of paper every time they design a new airplane … they were starting with the explicit, drawings, functional specs, and bills of material of previous airplanes.  They were re-using the knowledge and experience of previous generations, knowledge which was explicit and retained principally as structured models; drawings, functional specs, and bills-of-materials, etc., etc. (that is, airplane Architecture.)

The models of the Framework for Enterprise Architecture were directly derived from descriptive representations from Architecture and Construction (buildings) and Engineering and Manufacturing (airplanes).  For example, data models are the Enterprise bills of materials, functional models are the Enterprise functional specs, technology models are the Enterprise drawings, etc., etc.

There is strong precedent in older disciplines that knowledge about complex products (and by analogy, Enterprises) is captured in the descriptive representations (that is, Architecture, or, the set of explicit models) of the object which enables rapid evolution in sophistication and complexity of the product (in our case, Enterprise) being described.  For any information or knowledge to be relevant to the complex object, it has to be mapped back to the explicit representations (Architecture) of the object.

In short, there is very strong precedent in older disciplines that Enterprise Knowledge Management is very, very closely tied to, if not the same as, Enterprise Architecture Management.

This "physics" of knowledge management is critical to avoid the mysticism that leads to the silver bullet syndrome.  We desperately need to protect the Enterprise opportunity for Knowledge Management, that is, Enterprise Architecture, the reuse of the collective knowledge about the Enterprise required to innovate, to introduce much more complexity and sophistication and to precipitate much higher rates of (competitive) change.  We might as well start working on … "all those models, Enterprise-wide … Etc., etc."

References

[1]  See "The Framework for Enterprise Architecture (The 'Zachman Framework') and the Search for The Owner's View of Business Rules," Data Base Newsletter, Vol. 26, No. 1 (Jan./Feb. 1998), or visit web site at www.ZIFA.com for information on the Framework and a short article, “The Framework for Enterprise Architecture:  Background, Description and Utility." 

# # #