How to Build a Federated Knowledge Base

In my previous post I discussed one of the main problems of knowledge management: distributed knowledge.  I provided three options, of which I prefer the model for Federated Knowledge, to solve the problem.  Just like in a federal government, the independence of the states (or knowledge collaborators in this case) makes it easier to manage a much larger entity.

Building a federated knowledge base takes first and foremost collaboration.  All contributing parties need to agree to the basic rules and must follow a similar model: all of them must contribute equally to the endeavor for it to serve its purpose.  A governance body, or committee, composed of representatives of all affected parties, must collaborate to create the rules and regulations for its operations (yes, just like in congress).

Once the governing body is in place, the first step is to determine the strategy (four key components: Vision, Mission, Goals, and Objectives), the purpose, and set time commitments to make it work.  This document must be the same for all interested parties, and it must be agreed to by senior management, with an executive sponsor at each participating organization.

The fact that different organizations, each with their own challenges and problems, are coming together to work towards a common goal makes the joint infrastructure the key component of success or failure.

Of course, the implementation must have certain features that would make it valuable for the users.  The following list is the minimum set of requirements that any federated knowledge base must have:

Alerts – alerts work at the administrative level to notify of problem knowledge entries, answers with high scores but low readership, and other problems that may signal an incomplete or inconsistent knowledge base.  Given that knowledge is produced in different content management systems, a centralized alert system is critical to managing the value of knowledge.

Subscriptions – for users of the data, being able to subscribe to be notified when it changes is critical since they are not accessing the source for the knowledge directly.  A critical distinction must be made between subscriptions for specific items and entire knowledge bases.

KB Performance – considering that the data is housed in different places and must come together at the time of need, an equal platform or infrastructure in terms of performance will guarantee the execution of the joint knowledge base.  Consumers won’t just sit around waiting for one slow performing component; they will abandon the self-service solution and become phone users.

Taxonomy – Quite simply, a federated knowledge base that has different categories, classifications, meaning to terms, or even different synonyms cannot find the right information.  Parties in a federated knowledge base must adhere to the same taxonomy to classify and index their entries.

Autonomy – Even though there is a joint purpose in the building of the federated knowledge base, autonomy must remain for each member of the federation with respect to their internal policies, content management systems, and decisions on internal maintenance and governance.  Alas, there is a common agreement on how to operate the joint venture, but it must never supersede the internal organization and Standard Operating Procedures for any of the members.  However, one of the un-intended effects of being in a federated model is that the practices of any one organization can be improved by exposure to others in similar situations.

Collaborative – Working together towards the common goal of providing consumers an answer should make the different teams work together.  Collaboration between the teams could also be extended to collaboration with consumers, if community-generated content is part of the deployments at any of the partners.

Dynamic – As the needs from the consumers evolve over time, so will the need to populate, maintain, and improve the federated knowledge base.  Even something as simple as supporting community-generated content can wreck havoc in an inflexible system.  The rules and operating procedures for the federated knowledge base should be flexible enough to accommodate changes over time.

Local-Global – The old adage of “think global, act local” applies very well to these systems.  Anything than any of the partners or members will do with their knowledge management and knowledge bases is bound to affect the other members of the federation.  All changes must be thought at a global level, even though approval by all members is only necessary for those items affecting the federation, not the rest of the operations.

Of course, these are just the core guidelines and components that will make your federated knowledge base work.  The item above about dynamic and flexible systems also applies to your specific needs – these norms can be changed and altered to suit your individual needs and those of the other members of the federation.

What do you think?  What am I missing?

This is the second post in a six-part series of sponsored research I am doing with NoHold.  More goodies on federated knowledge bases coming soon!