%last changed 1/4/94
% Schlumberger Laboratory for Computer Science
% arango@austin.slcs.slb.com
% 8311 North RR 620, Austin          Tel: 1 (512) 331 3735
% TX 78726-0015, USA                 Fax: 1 (512) 331 3760
% --------------------------------------------------------
%
%Scope:  Working group participants will start by sharing any experiences
%(positive or negative) in reuse technology transition, including any
%lessons learned.  We will try to identify the key issues that make
%technology transition difficult, possibly through the use of an IBIS
%structure.  The working group will then attempt to develop recommended
%strategies for use in various contexts (e.g., intra-company,
%inter-agency, etc.), with special attention to risk factors in the
%technology transition process and suggested risk mitigation
%approaches.  As a general guiding point, this working group will avoid
%more often than not), and focus on implementable transition
%strategies.
%
%Goals: o Share reuse technology insertion experiences
%       o Identify key technology insertion issues
%       o Develop context-sensitive insertion strategies
%       o Avoid idealistic and unrealistic approaches
%------------------------------------------------------------------------
%Date: Thu, 11 Nov 93 12:10:02 CST
%From: arango@austin.slcs.slb.com (Guillermo Arango, Schlumberger, Austin)

%Participants:
%        Tarek Abdel-Hamid, Naval Postgraduate School
%        Guillermo Arango, Schlumberger
%        Sidney Bailin (chair), CTA Inc.
%        David Chao, US General Accounting Office
%        Richard Conn, The MITRE Corp.
%        Marilyn Gaska, IBM Federal Systems Company
%        Ware Meyers, IEEE
%        Ruben Prieto-Diaz, Reuse Inc.
%        Donald Reifer, Reifer Consultants
%        Larry Smith, US Air Force.


The meeting of the Technology Transfer (TT) group started with a discussion
of reuse TT experiences in the participants organizations. Clear
differences in management approaches, scope of the efforts, and funding
styles between industry vs. government organizations was apparent. A list
of issues was identified:
\begin{itemize}\itemsep -3pt
  \item Does Reuse require special approaches to TT?
  \item How is it done (in the cases where it works well)?
  \item Who pays for TT?
  \item How to speed it up?
  \item How do we develop advocacy?
  \item How do we measure success, ROI in TT?
  \item Who are the customers, targets, users?
  \item What do we transfer?
  \item What drives TT?
  \item What are the roles of people in the TT process?
\end{itemize}
Given the time constraints, only the first three issues were discussed in
some detail.

\subsection*{Does Reuse Require Special Approaches to TT?}

Is there any reason to think that the TT process applied to other
technologies may not apply to Reuse? Participant opinions were divided.

     Those who argued for the need of a special TT approach pointed out
that reuse is not a ``technology''. It involves the application of
well-established engineering principles--the application of best principles
and practice, case-based reasoning--to software engineering activities. In
the established engineering communities, reusability is part of the
culture, like the principles of physics or mathematical notations. That
culture is propagated through educational programs, training, engineering
standards, codes of practice, and so on. Following this argument, rather
than investing on technology transfer, we
should invest in education and on consolidating good ``software engineering
theories'' and ``domain-specific theories'' that could serve as a reliable
foundation for the profession (by analogy with physics, materials science,
structural analysis, and so on).
Having redefined the TT problem as one of (i) building reusable theories and
(ii) teaching people good engineering, the group could not agree on the
question of how to reliable build  reusable theories (i.e., What is the
scientific method?). Software engineering research and the practice of
domain analysis will continue to produce many of these. Practical
validation and market needs will probably drive a Darwinian process of
selection/evolution as it has happened to computer architectures,
programming languages, design notations, and so on. An interesting question
not addressed by the group was: How could we speed up the
selection/evolution process?

    Those who argued against the need of special TT approaches justified their
answer on the observation that ``good'' TT approaches used by other
disciplines do not seem to depend on what is being transferred but on:
\begin{itemize}\itemsep -3pt
   \item the structure of the organizations participating the transfer,
   \item funding schemes,
   \item the products or processes to which the technology applies,
   \item the economics of the markets of those products or processes, and
   \item the level of sophistication of the user community.
\end{itemize}
Do we have any ``good'' processes that could be shared?  A number of known
processes (e.g., IBM, HP, ICASE, SPC, Schlumberger, DSRS) were proposed as
possible candidates. Those processes, however, are customized to the
conditions listed above and have not been validated extensively.

    The discussion touched briefly on ``What is transferred in Reuse TT?''
There was agreement that the two major components of the transfer are: (i)
systematic processes for building on what exists, and (ii) methods and
tools for building reusable software and for assisting in reusing it.


\subsection*{How is it done (in the cases where it works well)?}

The consensus on this issue was refreshingly crisp and down to earth: ``You
can take the horse to the water but ...''  The common denominator of all
successful experiences is {\bf pull}. Successful TT takes place when there is a
{\bf pull} from the receiving users. This factor dominates all other factors.

Based on this observation, Reuse TT approaches should first:
\begin{enumerate}\itemsep -3pt
  \item Identify pull, or
  \item Generate pull
\end{enumerate}

Only then, attempt to transfer the technology.

To identify {\bf pull} requires first identifing who the users are. (We
distinguish between Users--those who will ultimately apply the reuse
technology-- and Customers--those who pay for it.) These distinction helps
account for critical difference in perceptions and interesting politics.
Most successful transfer cases appear to be driven by  {\bf grass roots}
efforts. To identify and encourage such movements is a powerful means to
facilitate the introduction of reuse technology. Participative software
process improvement programs offer a good framework for creating and
identifying opportunities.

Pull can be stimulated by using techniques such as TQM, the SEI Capability
Maturity Model, ISO 9000 certification process, or the Malcom Baldrige
Award.
Interestingly, we do not seem to be exploiting one of the most common
techniques used to generate pull in our economy: marketing. The marketing
community has developed a number of analysis tools and communication tools
to:
\begin{itemize}\itemsep -3pt
   \item identify opportunities--who are the users, what are their perceptions
                and needs, what is the source of their buying power,
   \item measure ROI, and
   \item generate pull for products and services.
\end{itemize}

These are key aspects of TT. There is a wealth of experience and techniques
used by the marketing community that we have not even started to exploit
for the transfer of technology.

A first lesson that we can learn from marketing, is that marketing does not
come for free. It is quite expensive. Many TT projects fail precisely
because they did not identify the extent of the investment needed to make
TT work. Schemes for funding marketing projects can also be applied to TT
projects.


\subsection*{Who Pays For TT?}

The group discussions would repeatedly come back to the point of ``Who pays
for it?''  Funding is a central issue in TT. First, because TT does not
come for free. Second, because funding patterns drive how the organizations
participating in the process operate and how the process is managed.

There are a number of funding schemes that are appropriate in different
organizational settings:
\begin{itemize}

\item   If TT is structured using a marketing strategy then it is traditional
        that marketing (thus TT) gets paid by the customer. If customers have
        been persuaded that sufficient value is delivered, they will pay for it.
        A number of joint-venture schemes are possible to facilitate mixed
        funding between sources and recipients of technologies.

\item   When government organizations are involved, the TT process is not
        regarded as a money-making operation. The  goal is to recover only
        the operational costs. Government organizations act as third-party
        funding sources to ``prime the pump.'' The issues are: how to determine
        time-to-recover of costs and how to recover the costs. Schemes that
        are applied or may be applied shortly involve: subscriber fees for
        users of code libraries, fee-for-service-rendered contracts, transfer
        TT project to external ``technology brokers''
        who are profit-and-loss groups.

\item   Some organizations become TT agents by transferring a technology as
        value added to their own products or services. An example, is the
        access and use of the Internet made available to students by
        universities as value added to their own educational services.

\item   In industry, internal R\&E laboratories usually have TT
responsibilities.
        The funding of such organizations has a substantial influence on
        what, when, and how technology is transferred. A number of different
        ``tax schemes'' are used to fund such groups. Central funding at the
        corporate level encourage longer-term technology development rather
        than technology transfer. Funding from distributed sources close to
        the profit-and-loss centers makes their managers more aware of
        R\&E expenditure and more demanding about ROI. These schemes tend to
        encourage TT over technology development and  shorter-term projects.
        Funding groups have a strong influence about what gets transferred,
        to whom, and how the process takes place. Mixed schemes enable
        trade-offs between investing in technology development and TT.

\item   In the US a number of Consortia with industry or mixed
       industry-government membership (e.g.,  MCC, SPC, SEI) have been in
  operation for many years. The results have been mixed. These groups appear
to have succeeded in TT (in Reuse as well as other software engineering
        domains) only in those cases where they operated
        very closely to the users.

\item   In Europe, the EEC has funded for more than a decade a number of
        government and government-industry funded cooperation projects (e.g.,
        ESPRIT, ESSI, EUREKA). By and large these programs have succeeded
        in creating networks of collaborators and  multiple channels for
        technology transfer between partners. Several projects have focused
        on Reuse (e.g., Knosos, Reboot, MACS). The ROI, however, is not easy
        to determine.
\end{itemize}
A conclusion from the analysis of funding schemes suggests that successful
TT projects tend to be those where the customer (funding source) and the
users of the technology being transferred are close and share objectives.

The old saw, ``when there is a will there is a way,'' also applies to Reuse
TT. Many successful TT projects take place without official funding, with
participants working out of their own initiative, on their time, in
skunk-works mode. Such projects are usually carried out through the
collaboration of networks of individuals sharing common professional
interests. The Internet has a very positive effect in supporting the social
processes key to the development and operation of such groups.

\subsection*{Recommendations on TT}

There was consensus on the following key recommendations:
\begin{enumerate}\itemsep -3pt
   \item Identify and use existing pull or generate pull.
   \item Position customer as close to the user as possible.
   \item Benchmark what we have: methods, tools, TT Schemes.
   \item Reuse successful TT from other disciplines, in particular,
         borrow principles and techniques from marketing.
\end{enumerate}

