Posted by Dale Mead on August 11, 1998 at 19:28:36:

In Reply to: Profile of the Ideal Knowledge Manager/Architect posted by Yogesh Malhotra on August 07, 1997 at 08:41:38:

When one puts out their concept of an "ideal" Organizational Knowledge Architect (as I will below), it has to be strongly influenced by their perception of how an OKA actually functions in an organization. Because the term remains more than a little undefined, I suspect that each individual holding such a position tends to develop the position to their own talents. The comments below are based on my own positions as a Knowledge/Information Architect and the talents I see in the ideal. Other manifestations of this job may have different needs.....

The original thread asked:

What is the ideal profile of a senior Knowledge Executive such as a Chief Knowledge Officer (CKO) or the Organizational Knowledge Architect?

I see some significant differences in the profile of an ideal CKO and OKA.

A CKO needs to be able to take an appropriate place among the other CxO level individuals in the organization. This means a span of control appropriate to that level. It means maturity and corporate experience. It means organizational and people skills. A CKO needs to understand knowledge and information management the same way that a CIO needs to understand IT, a CFO needs to understand accounting, a COO needs to understand manufacturing. They need to be able to see the big picture, to hire the right people below them, to have a good feel of when to trust the direction that these people are doing the right thing and when to give guidance.

In my company, the CKO is a VP over a 200 person organization which includes a Knowledge Management group as well as groups like Educational Services, Pre-sales technical support, competitive intelligence, and process analysis.

An Organizational Knowledge Architect, I think, is a different beast. An architect needs considerably deeper understanding of the details and constraints. Compare with the need of a traditional architect to specify stainless steel vs. zinc coated screws for a deck. Any kind of design work requires knowledge of the details.

An architect also needs to be able to gather user requirements; evaluate those needs with respect to available technologies, resources and existing environment; choose the best solution; design it; and, if necessary, oversee the development. This implies that the architect must be skilled at listening to needs and elicting information and able to have those discussions at all levels of the corporation. They must be able to mediate between competing needs, evaluate the value of solutions to the corporation, and design to meet the overall goals of the organization.

I agree with others here that divide up the skill set into technology, business, and communication.

The technology skills are needed because you can't really separate the communication of knowledge from the underlying technology medium. While the architect needs to focus on current and near-future technologies, we can't ignore older technologies and we can't limit our scope to traditional IT technologies.

The architect needs to be able to look into the future and divine the technology directions that need to be planned for. An architect needs to be able to pick the winners at reasonably long range. Does an emerging technology meet real needs? Will those problems still exist when the technology is mature? Does it do a lot of "hand waving" around the hard parts? Is it deployable in any reasonable (i.e., customer acceptable) manner? Etc. The architect needs to be comfortable playing with new technologies; reading standards docs, research papers and bof presentations; and so forth. They need to be able to contribute to the advanced technology community in a way that gives them entre to the early discussions of new ideas.

The architect needs to have detailed understanding of current technologies, particularly those currently in use in their environment, and how those technologies are deployed. You have to know it for design reasons. You also need to know it because situations arise with some frequency that call on you to do something like sniff Ethernet packets or telnet to a nntp server or figure out how a piece of hacker's code is working so you can defend against it. There is also the matter of maintaining the respect of the coders that are executing your designs. If you have specified that the results of a certain database query will appear on a web page, you had better know how to write that SQL if you had to and you better know how those results are going to make it onto the web page.

The Knowledge Architect also needs to be able to work with the "keepers of the technology." Creating great, new, cutting edge tools doesn't mean anything if you can't get them implemented and there can be lot of reasons why they may not be. Technology environments in major companies are complex and lots of issues need to be resolved before embarking on projects. IT professionals tend to think a lot about support and maintenance issues, not just how cool the project is.

A OKA also needs to know the business. They need to understand how business operates. They need to understand their industry and the competitive environment. They need to understand how their specific business works; how it is positioned in the industry; how it relates to channel partners, vendors, etc.; what its corporate culture is. They need to understand the major corporate information flows: the product development lifecycle, the sales-fulfillment flow, etc.

The architect needs to understand the information needs of the different parts of the business and how they differ. We need to know who the producers of information are and where the real demand that information is. We need to know who shouldn't see information and at what points in the information lifecycle information should be accessable to different audiences.

They need to understand the legal implications of information flow including complying with copyright laws, handling non-disclosure information, preserving intellectual property rights, complying with export laws as they apply to information, maintaining appropriate records and audit trails, and many other issues.

Several comments have mentioned "Communications" as a key area of expertise. My concern is that many different disciplines believe that they "own" communications. One only has to look at some of the bitter discussions between the Cognitive Psychology community and the Graphic Arts people or the Library Science types vs. the IT organizations that appear on the various newsgroups. The truth is that no single discipline, including the one commonly labeled "Communications," has a lock on this subject. Personally, I draw heavily on theory generated from the education community, library/information science, cognitive psychology, graphic arts and multimedia, literature, marketing, and epistomology. My experience is that all of these disciplines (and probably others that I am less aware of) have unique and important contributions that shouldn't be ignored.

Specific skills that I use almost daily include: data modeling, usability testing and heuristic analysis, graphic design, classification/categorization development, project management, technology skills mentioned above, and mediation.

---

Follow Ups:

---

Click Here to Post Follow Up in New Forums

    Knowledge Management Think Tank (New)

  

 Subject: 

Message: