Knowledge Reuse - Insights from Software Reuse

We are moving towards an economy where competitive advantage will be determined by knowledge. In their knowledge management strategies, many companies currently aim to encourage knowledge reuse. In this paper, we examine insights drawn from a related field — software reuse — for their relevance to the emerging field of knowledge reuse. We first examine different types of reuse: components, patterns, frameworks and general principles. We then evaluate different kinds of reuse activities. Finally, we discuss lessons from cultural issues in software reuse. Introduction There is a widespread consensus that we are moving towards an economy where competitive advantage will be determined by knowledge rather than by access to raw materials and cheap labor [Liebeskind, 1996]. Business processes are becoming more and more knowledge-intensive while the time given to an organization for creating or acquiring knowledge is becoming more limited. Organizations are forced to create more knowledge in shorter time period. As a response to this demanding environment, some companies have created new positions such as “Chief Knowledge Officer” whose mission is increasing the knowledge base of their workers so that everyone can make better decisions [Carrillo, 1997]. Knowledge management is “getting the right knowledge to the right people at the right time so they can make the best decision” [Hibbard, 1997] — or “an attempt to put processes in place that capture and reuse an organization’s knowledge so it can be used to generate revenue” [Dash, 1997]. As implied in these definitions, one of the ultimate goals of knowledge management is “reuse of knowledge” through sharing of knowledge among the members. Thus, shedding light on knowledge in the reuse perspective is needed. In the software engineering area, valuable “reuse” experience already exists in the form of “software reuse”. Since software can be thought as a type of codified knowledge, investigating the efforts for software reuse and understanding what is relevant to knowledge reuse could provide valuable insights for knowledge reuse. In this paper, the insights from software reuse are discussed. Software as Codified Knowledge One of the primary reasons of implementing knowledge management efforts in large companies is to promote sharing of codifiable knowledge such as transfer of best practice and customer/market information [Dash, 1998]. Codifiable knowledge is a primary target of knowledge management because it is feasible and easier to share than less codifiable and tacit knowledge. This paper therefore focuses on codifiable knowledge. Software has many similarities with codified business knowledge. First, both are accumulations of rules for works. The are often represented in an event-action format such as: "If event X occurs then perform action Y". Secondly, different software often needs exactly identical components, for example, sorting algorithms and user interface components, in several different contexts. Similarly, companies need identical knowledge such as guidelines for action or document templates in several different contexts. Thus, opportunities for the reuse of software as well as business knowledge clearly exist. Thirdly, there might be multiple alternatives such as algorithms in software and ways of solving a problem in business, that have the same goals but are different in approach, efficiency and/or effectiveness. Thus, it is likely that the quality of software or business knowledge can be improved by selecting better software or knowledge components. From a knowledge management perspective, software can be considered as “a special type of knowledge that is captured and frozen into a specific representation format (text or binary code) ”. Types of Reuse Although there is no internationally recognized standard for how software reuse should occur [Rada and Moore, 1997], there have been many efforts to make software reuse more efficient and universal. There are three different levels of reusable software components [Tibbetts and Bernstein, 1998; Johnson, 1997] – components, frameworks, and patterns. Components are “black box” pieces of software that can be plugged into a program with minimal modification efforts. Frameworks are libraries of