Reuse as a Knowledge Management Problem
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
As I read and talk to people about reusing objects, components, patterns, templates, and containers, I get a distinct impression about the underlying assumption behind these advances in technology: "we weren't very good at sharing small objects, so let's try sharing really big ones!" I would like to put a little different slant on the issue of reuse. It isn't a technology problem, nor is it a management problem (although both are important). Reuse is fundamentally a knowledge management (KM) problem, and over the last ten or so years, by packaging objects into components and components into templates, we've made the problem bigger, not smaller.
Consider for a minute the process of reusing a simple Java servlet. The transfer process might take fifteen minutes of searching for, analyzing, and making the decision to "reuse" the component. The savings might be eight hours of coding and testing time.
So if we benefit from reusing little components, then the benefits from reusing big components should be better, right? Let's hypothesize the reuse of an analysis pattern as part of an application development project. This pattern has the potential to save six weeks of work. However, even though we found this pattern and its documentation in our repository, we have several unanswered questions. Furthermore, John, our wiz-bang analyst, says he can whip together use-cases and a data model for our application in no time. It might take 15-20 hours of study and discussion to be able to effectively use the pattern after we ask around to find out whom to talk to — but there isn't a clue as to who the original writer was. We let John go ahead, thereby losing the opportunity to reuse and improve the pattern.
Objects, patterns, templates, and components are packaged (explicit) knowledge — the larger the package, the greater the encapsulated knowledge. The greater the encapsulated knowledge, the harder it is to transfer. Additionally, the more tacit (not explicitly expressed) the knowledge, the harder it is to transfer, as is the case with the analysis pattern in the hypothesis above.
Application development organizations that fail to understand tacit knowledge will repeat many of the mistakes made with methodologies and CASE tools. A common assumption in the past was that all relevant knowledge could be bundled up in nice, neat, easily accessible packages of "best practices" that practitioners could then "repeat." We are beginning to admit (we always knew it, we were just not willing to admit it) that the essence of problem solving, innovation, creativity, intuitive design, good analysis, and effective project management involves more tacit, rather than explicit, knowledge. By putting tacit knowledge in a principal role and cultivating tacit knowledge environments, KM can play an important role in application development, and particularly in reuse.
A second aspect of the explicit knowledge problem is the fallacy that documentation (explicit knowledge) equals understanding. We seek understanding in order to successfully reuse a component. However, the larger and more complex the component, the harder it is to gain the required understanding from documentation alone. Understanding, in this context at least, is a combination of documentation and conversation — conversation about the component and the context in which that component operates. No writer of documentation can anticipate all the questions a component user may have. Even if this were possible, the resulting documentation would be so extensive and cumbersome that potential users would simply develop their own component rather than wade through the documentation. Knowledge management systems that focus on gathering, recording, and accessing reams of "knowledge", at the expense of person-to-person interactions have proven to be expensive and less than satisfactory.
When we attack reuse as a knowledge management problem we begin to ask new questions, or at least look for different avenues for finding solutions to the problem. How do we go about finding the component we need? How do we gain confidence that the component does what we want it to do, and doesn't do strange things that we don't want? What is the distance (organizationally or geographically) between the component developer and users? Are there other people who have used this component that we could talk to and learn from? Do we have access to the author of this component? Have others found this component to be effective? How should we go about testing this component? How easily will this component integrate into our environment?
Out of the extensive literature on knowledge management one of my favorite books remains Common Knowledge: How Companies Thrive by Sharing What They Know, by Nancy Dixon (Harvard Business School Press, 2000). Dixon outlines factors that effect knowledge transfer: characteristics of the receiver (skills, shared language, technical knowledge), the nature of the task (routine, non-routine), and the type of knowledge being transferred (a continuum from explicit to tacit). Dixon then identifies five categories of knowledge transfer that she has observed, from Near Transfer ("transferring knowledge from a source team to a receiving team that is doing a similar task in a similar context but in a different location") to Serial Transfer ("the source team and the receiving team are one and the same"). Dixon then describes techniques that work well for each of these five types of transfer.
It is not the objective of this short article to describe the practices for knowledge transfer in detail, but rather to point out that merely coding a component and scratching out a few lines of documentation will rarely be enough to facilitate knowledge transfer. My second point is that while the body of knowledge on the subject of knowledge management can itself be difficult to wade through to find useful nuggets for improving reuse, it nevertheless offers important insights into the reuse problem.
An understanding of knowledge transfer issues will greatly accelerate actual reuse. For example, just understanding the different demands of Dixon's Serial Transfer (within a team) versus Expert Transfer (transferring explicit knowledge about a task that is done infrequently) can assist companies in increasing returns from their component reuse initiatives. Application development groups have often been called upon to install knowledge management tools and practices for other departments in their organizations. Maybe it's time we learn how to use these tools and practices ourselves.