- 1.0 Introduction and Overview
- 2.0 The Nature of Technology Transfer
- 3.0 The Technology Transfer Process Model
- 2.0 The Nature of Technology Transfer
- 3.1 Establish Contact
- 3.2 Identify Opportunity
- 3.3 Execute Project
- 3.4 Use Capability
- 3.2 Identify Opportunity
- 4.0 Mechanisms & Controls
- 4.1 Matchmaker
- 4.2 Discussion and Logging Tools
- 4.3 Web Based Project Materials
- 4.4 Checklists
- 4.5 Project Workrooms
- 4.6 Temporary Badges
- 4.2 Discussion and Logging Tools
- 5.0 Conclusions
- 6.0 References
1.0 Introduction and Overview Research in technological fields is not fully effective until it is put into practice, but with rare exceptions researchers and practitioners live in different worlds. To bridge these worlds, the National Science Foundation has promoted the creation of Industry-University Cooperative Research Centers (IUCRC's) which bring together universities and industrial organizations. Affiliate companies in these centers select and fund university research projects that they believe may help solve problems of importance to their organizations.
But while the IUCRC model brings universities and industry together, the problem of technology transfer remains. Typically, IAB representatives are from large corporations and represent a large number of potential end-users within the organization. For example, the US Army Research Laboratory (ARL) Software Technology Branch (STB) is an affiliate of the Software Engineering Research Center (SERC). ARL/STB has one representative on the SERC Industrial Advisory Board (IAB) who attends regular SERC meetings. One of ARL/STB's prime customers is the U.S. Army Information Systems Command (ISC) who provides communications and information services to the Army. The ARL/STB attendee often brings a customer representative from ISC. However, ISC has nearly 20,000 civilians and soldiers in a dozen nations around the world whom are engineering, acquiring, installing, operating, and maintaining the Army informations systems. Getting these "end-users" involved in research efforts is difficult for these SERC attendees.
The Virtual Software Engineering Research Center (VSERC) project is a research effort to address this problem. World Wide Web technology provides an opportunity to greatly extend the range of contacts between university researchers and industrial users. The VSERC metaphor is that an employee at an affiliate company can use the web to "visit" the SERC's virtual building, in lieu of an expensive business trip. Here he or she can find out about ongoing activities, visit researcher and project offices, browse reports, view demonstrations, and join discussions about current and potential projects. If there is a particular project of interest, they can enter a work room in which they can work together with a researcher on a specific research application.
Figure 1 - The VSERC Virtual Building Metaphor
Some areas of the VSERC building are open to all, but others are restricted to affiliate employees and researchers. Access to each work rooms will generally be restricted to just one affiliate company.
VSERC is being designed from process models that describe the way the Software Engineering Research Center currently operates. This document presents the process model that has been used in designing the VSERC project offices. The model does not attempt to describe all research center processes, nor the many processes involved in actually carrying out a research project. It focuses instead on the technology transfer activities which attempt to take research into practice. Supporting these activities is the fundamental purpose of a VSERC project office.
The project office process model uses a simplification of the IDEF (Integrated DEFinition) Methodology developed initially by the U. S. Air Force. In IDEF each activity is represented by a box with inputs, controls, mechanisms and outputs. Mechanisms include anything that is used to help get a task done, while controls are used to initiate or guide the execution of a process.
Figure 2 - An IDEF Activity
The mechanisms chosen for the VSERC are fairly conservative; generally HTML pages or HTML-generating scripts which will facilitate keyboard-based researcher-user interactions at a distance. More advanced Web possibilities such as interactive audio and video would be desirable to support technology transfer, but are not widely available at this time.
2.0 The Nature of Technology Transfer
SERC has an ongoing project called "Spotlighting the Code" that is attempting to transfer a technique called "software reconnaissance" to SERC affiliates and at the same time to explore the processes of technology transfer in research centers like SERC. The software reconnaissance technique is a fairly simple method of helping software maintainers understand old code by analyzing traces of program execution [WILDE.95]. Its potential applicability is very wide, which makes it a good test case to see how technology transfer can benefit from the use of the Web to communicate with many distant sites simultaneously. The process model presented in this report is largely based on experiences working with several SERC affiliates in this project, and most specifically on experiences at the U.S. Army Information System Engineering Command and its subordinate organization, Software Development Center - Huachuca.
Studies of the diffusion of innovations [ROGERS.83] and our own experience show that the technology transfer process:
- Has a strong personal component. Innovations are often transferred through friendship networks which engender some degree of personal confidence. "Champions" of a technique emerge and promote its adoption within an organization.
- Tends to be full of surprises. An innovation winds up being changed or adapted in ways not anticipated by the original inventor. "Re-inventions", or complementary innovations are needed to make a technique completely effective.
- Involves a dialog. There are ongoing discussions between inventor and user to clarify the technique and the real nature and constraints on each application.
- Has many pitfalls. Potential users have many concerns and constraints; the introduction of the new technology is rarely their highest priority, so delays are frequent and technology introduction may be sidetracked.
We have found examples of all these phenomena in the Spotlighting the Code project. Programmers at two affiliates have enthusiastically adopted the technique while others have been indifferent or hostile. Several affiliates have proposed innovative applications of the technique to domains that were unimagined by the university researchers. The university-developed tools needed to be adapted to handle, for example, multi-process systems and unfamiliar programming language dialects that were not anticipated in academia. And affiliate programmers with whom working relationships had been established suddenly changed jobs as their work was abolished or reorganized.
Thus the process model described in the next section is somewhat unusual because of the uncertainties intrinsic in technology transfer. It attempts to show the sequence of steps involved in going from a researcher idea to, at least, a demonstration of a technology at an affiliate site. In some cases, the process may represent an entire SERC project, but more frequently a single project will have several affiliate interaction sequences with each one including some or all the steps shown. A large proportion of the interaction sequences do not go all the way through the process since affiliate priorities change and research results may point to different applications than originally anticipated.
A single step such as Execute Project might last a few days or several years; it could involve either simply demonstrating a developed technique as it currently exists, or major adaptations of the technique to meet a specific affiliate need. The end result of the process may also vary. For example, if the customer of the technology is a research group within the affiliate company, the final stage may simply be a report. If the customer is an actual end user, then it may be necessary to provide more polished tools and some training or hand-holding.
Thus, the model presented in the next section is less a classic process model than a flow of activity of a typical researcher-affiliate interaction in a center such as SERC. We believe that it is, however, specific enough to allow us to define the Web-based mechanisms that VSERC will need to provide to support such interactions.
3.0 The Technology Transfer Process Model The following sections describe the basic steps of the process model. In each step, we also mention the VSERC mechanisms that we have been developing to support each step. More complete descriptions of each mechanism are given later.
Figure 3 - A Technology Transfer Process Model
First we should identify the major participants in the model:
- Researcher: The university faculty member who is responsible for the specific project or technology to be transferred.
- Customer: A potential end-user of the technology in the affiliate organization.
- IAB Representative: The affiliate employee who represents the affiliate on the Industrial Advisory Board of SERC. This person is responsible for coordinating and promoting interactions between SERC researchers and the affiliate organization.
- Management: Managers in the affiliate organization who may need to approve the use of affiliate resources in technology transfer activities.
3.1 Establish Contact
A SERC researcher is referred to a potential Affiliate Customer. The input to this step is typically a researcher with an idea and the output is a potential researcher-customer match.The main channel for making these contacts is, at this time, the IAB Representative. Researchers call the representative to describe potential projects and make presentations of different kinds such as poster session, project proposal presentations, and SIG sessions at the SERC biannual meetings.
The difficulty is that IAB representatives may not (and usually do not) know all potential applications within their organization. Representatives are often extremely busy with other responsibilities aside from SERC. Oftentimes, they cannot attend all of the regular SERC meetings. In general, the communication channel between researchers and affiliates is thus constrained.
On the other hand, knowledgeable IAB representatives can often make unexpected connections between a researcher's formulation of an idea and the needs of the affiliate. Several of the most interesting variations of software reconnaissance were suggested by IAB representatives.
We propose three VSERC mechanisms to supplement the current methods of making initial contact:
- Project materials (concept descriptions, abstracts, presentations, demonstrations) will be made available through the Web to affiliate personnel who enter the Virtual Project Office (VPO).
- Busy IAB representatives who spot a possible match between a project and a company problem will be able to automatically send a message to a colleague and create a "temporary badge" to let the colleague view a specific project without having to apply for a password and step through the usual VSERC entrance screens.
- A "matchmaker" tool will allow potential customers to describe their problem and allow researchers to describe their capabilities. Potential matches will be identified automatically.
3.2 Identify Opportunity
A definite opportunity for research and/or technology transfer is identified. The input to this stage is one or more potential researcher-customer matches. The output should be a defined opportunity:- A specific researcher, specific customer, and specific topic are identified.
- Any necessary resources have been identified. If SERC resources are indicated, then a project proposal has been prepared, and possibly even approved. Any needed affiliate resources have been requested and, at least in principle, committed.
- All relevant SERC administrators, affiliate IAB representatives, and affiliate managers are informed and "on board".
Some intensive interaction is generally needed to see if there is a real opportunity for research and technology transfer. While this interaction may occur at the regular IAB meetings, it is likely to require a visit to the affiliate site for more intensive discussions. In this step, many of the most interesting variations on the initial concept appear and the research idea often changes substantially. If a true opportunity is identified, it becomes important to make sure that all relevant affiliate managers are "on board" and that any resources that the affiliate might have to provide (such as data, personnel time, travel, etc.) have been committed. SERC administrators also need to be kept informed so that they are aware of what researchers are doing and can address any problems that arise.
The primary problem is communication among the many participants. The main VSERC proposed mechanism are discussion and logging tools that allow the Web to be used to discuss issues and keep a history of participants, committments, ideas, etc. A useful control is a simple checklist to remind researchers and IAB representatives of the steps that have been found necessary for successful interactions.
3.3 Execute Project
The project is actually executed. The input is a defined opportunity, as described previously. The output is, ideally, the creation of a technical capability for the affiliate so that the company can use the technology in the future. More specific results may include an enhanced software tool, endorsements from satisfied affiliates, SERC technical reports on the technology and on lessons learned in the transfer, and ideas for extensions or further research.The tasks involved in project execution are diverse, but they frequently involve testing the technology on a specific affiliate system or problem. The researcher and the customer exchange data and tools. The researcher assists the customer in running the tools. The customer reports problems for the researcher to fix and suggests applications or extensions to the technique.
The main problem is coordinating work at a distance. Visits are useful, but they are expensive of both time and travel budget. Much of the interaction should take place over the phone, by electronic mail, and through the Web. Interactions with a specific affiliate should not be publicly visible to others since confidential topics may arise.
The main VSERC support of this step will be the private "workrooms" in the project office. The project office makes available information about ongoing "workroom" interactions. The discussion and logging tools used for project identification will also be useful to keep all the participants informed of issues that have come up and of the status of the ongoing work.
3.4 Use Capability
The technological capability created by the interaction is utilized by the affiliate and other affiliates in future activities. This step has no clear outputs because it may continue indefinitely, even long after the specific SERC project has ended. The technology and tools created in the interaction may be used directly by the affiliate. Occasionally, commercial tools are marketed that incorporate the ideas generated in the research, making the research prototypes obsolete.The VSERC project office and the project materials it contains should continue indefinitely to be a resource for potential customers. The researcher may or may not be able to provide support after the end of the SERC funded stage of the project.
4.0 Mechanisms & Controls The VSERC mechanisms and controls that have been identified include the following:
4.1 Matchmaker
The Matchmaker utility is a tool designed to assist in the first phase of the technology transfer process within the domain of the virtual offices. This task is accomplished by allowing a user to locate offices of interest by forming a search query of keywords provided by the system. Once this query has been submitted, Matchmaker will then return an ordered list of potential matches which the user may then browse through as desired. A user may return at any time to submit additional queries.4.2 Discussion and Logging Tools
The discussion and logging tools provide similar Web capabilities. A discussion is focused on a specific issue or on exploring alternative solutions to a problem. Participants can use their web browser to view the comments of others, add additional comments, and, if appropriate, to vote to indicate their preferred solution.The logging tool would be somewhat simpler. Its main purpose is to keep a thread of messages tracking the history of a specific interaction between a researcher and an affiliate site. Since each pariticpant will typically be involved in many different activities, it can be hard to remember who said what to whom! Innumerable details need to be recorded, ranging from management approvals for the interaction to specific decisions as to the dates of a researcher visit. Technical diagrams and data may also be recorded. Participants may click on a button to add a new entry to the log. Eventually, we plan to add a notification mechanism to inform participants when is a significant log update.
4.3 Web Based Project Materials
The project office should provide links to Web-viewable materials on the project to inform potential users of the technology. The choice of materials would be at the discretion of the researcher, who can select whatever is needed to familiarize customers with this particular technology. Examples might include slide show presentations, tool demonstrations, technical reports and tool documentation, SERC proposals and status reports, etc.4.4 Checklists
A checklist has been prepared that we believe will be useful in defining opportunities and in actually executing the interaction. The main purpose is to ensure that avoidable problems that are known from previous projects do not hinder the process. The list checks that the project has been clearly identified, that Affiliate and SERC managers are informed, etc.4.5 Project Workrooms
A virtual "workroom" is created for each identified interaction. It contains the ongoing log showing the history of the interaction, the checklist, an interaction plan, and contact information on the participants.4.6 Temporary Badges
Temporary badges are an attempt to make it easier for an IAB representative or a researcher to provide access to the virtual project office. The normal entry into such offices by the VSERC building's front door, requires getting a password and then successfully following a sequence of links to the desired office. While this route is appropriate for people who are browsing several projects, it is rather long and error-prone for someone who wants to get quickly to a specific topic.An IAB representative or a researcher will automatically create the special temporary badge and give it to a colleague. The colleague will then go directly from the VSERC front door to the project of interest. The researcher and the IAB representative could be automatically informed when the badge is used.
5.0 Conclusions Since the first project offices are only now being created, our experience with these Web supports for technology transfer is still quite limited. We have generally found that IAB representatives are enthusiastic about the prospects for faster interaction that the Web technology would appear to permit, but we will have to wait and see how the tools are actually used in practice.
6.0 References [ROGERS.83] Everett Rogers, Diffusion of Innovations, The Free Press, New York, 1983.
[WILDE.95] Norman Wilde and Michael Scully, "Software Reconnaissance: Mapping Program Features to Code," Journal of Software Maintenance: Research and Practice, Vol. 7, pp. 49 - 62, January 1995.
Created: October 22, 1995, Updated: May 10, 1996 - 6.0 References