Martin L. Griss, Laboratory Scientist
Hewlett-Packard Laboratories
Palo Alto, California
griss@hpl.hp.com
[Extended version of column which appeared in Object Magazine, May 1995]
In this column, I focus on reuse process and organization. Experience with successful reuse efforts shows that reuse is most effectively practiced when the asset creation process is managed and staffed separately from asset utilization.
The software reuse community has learned that successful systematic reuse requires attention to a variety of non-technical issues which must be addressed before technology such as objects and libraries can be effective. Two of the most important issues are the software processes to be followed, and the structure and management of reuse organizations. A reuse process makes explicit guidelines that will ensure successful reuse, such as separating reusable asset creation from asset utilization [1,2] . Effective reuse requires significant organization changes, typically spanning several teams within the company. Such sweeping changes can only be accomplished with informed and explicit management leadership.
The software engineering community has stressed the importance of a well defined software development process. Since no single software process model is ideal for all situations, several standard (macro-process) software lifecycles are used as frameworks into which detailed (micro-process) elements are plugged. The micro-process describes specific roles, activities, methods, metrics, responsibilities and deliverables of the developers and managers.
The process for creating reusable software is different enough from the process of developing products with reusable software that distinct lifecycles for each process are needed. Several reuse-oriented macro-process frameworks have been defined to support this separation. Some work well with OO-method derived micro-process elements, augmented with domain engineering features to capture a range of asset variability during asset creation, and with support for design of products around a repository of reusable OO assets[3]. Incremental and iterative processes seem to match the capabilities of OO reuse well. Watts Humphrey has recently described a customizable reuse-oriented personal software process[4].
Figure 1: The reuse process
For this column I use a simple reuse process model, loosely based on the comprehensive Conceptual Framework for Reuse Processes (CFRP)[5]. To make explicit the reuse-enabling guidelines, the model has four distinct process elements, shown in figure 1:
Create: This process provides reusable assets appropriate for the utilize
process. Assets may be new, reengineered or purchased, and of various
kinds, such as code, interfaces, architectures, tests, and tools.
Activities include inventory and domain analysis of existing
applications and assets, assessment of utilizer needs, market and
technology trends, and architecture and component definition and
construction.
Utilize: This process reuses assets to produce products (applications or
systems). Activities include the examination of domain models and
assets, the analysis of product requirements, the adaptation of assets,
the development of products, and the specification of proposed
components.
Support: This process supports the overall reuse process, managing and
maintaining the asset collection. Activities include the certification
of new assets, classification for library storage, matching utilization
needs with the assets, providing usage support, and collecting feedback
and defect reports.
Manage: This process constrains and controls the other elements. It must
plan, initiate, resource, track, prioritize, coordinate and improve the
reuse process. Activities include setting priorities and schedules for
new asset construction, resolving conflicts when needed assets are not
available, establishing training, and setting direction. Coordination
can span many levels - within each create and utilize project, across a
set of utilizers, and up to the management of a complete
"producer-consumer system" of projects.
Specific metrics are needed to manage the creation, support and utilization of reusable software, helping utilizers understand the value of the assets, and helping creators prioritize investments.
In a reuse organization operating according to the above process, there is tension between product development objectives (especially capabilities and schedule) and asset development and evolution (especially long-term reusability and quality). Ideally, all members of an organization have a shared reuse mindset, allowing them to operate from knowledge of the process and desired balance between product and reuse objectives. However, in practice, reuse only succeeds within a structure with separate creator and utilizer teams, and high-level management leadership and support.
I have found that the most effective reuse organization structure has four distinct kinds of teams, corresponding to the process elements shown in figure 1:
One or more creator teams who produce reusable assets to meet the current and future needs of the utilizer teams.
Several utilizer teams who reuse assets to construct products.
A reuse management team, usually led by a single manager, often assisted by a reuse steering committee of managers (shown by an [M]) and other stakeholders from the other teams. They ensure that the overall process proceeds efficiently, that the construction and support of new assets is funded , and that conflicts between the goals and schedules of the different groups are resolved.
A support team manages the assets, provides utilizer support and training, does some maintenance of assets and provides coordinated feedback on problems. They ensure that compatible assets are delivered to meet utilizer needs and assist with some adaptation consistent with reuse objectives.
This model can be used as a framework to set up your specific reuse organization, merging or embedding some functions into combined teams. We[1,2,6] and others have studied several reuse organizations at HP, AT&T, Verilog and other companies[7]. An analysis of 10 HP reuse organizations discusses in detail specific benefits and risks of four different structures[6]. Each of these is a variant of the 4-team model.
There are several issues that compete as an organizational structure is set up. Each structure favors some stability and connectedness aspect at the expense of some another. The reuse management team and process must be vigilant to ensure appropriate balance. While some structures appear easier to establish initially, they are less effective if their creators and supporters do not have full-time, visible and official responsibility for reusable assets alone.. Ideally, a single manager is able to coordinate interactions between teams. Whether creators and utilizers are in the same organization or not, they need leadership empowered to help meet both product objectives and organization-wide reuse objectives. If the managers of the other teams do not report to the reuse manager, or a manager close to the reuse effort, some other mechanism is needed to resolve priority and conflict issues, and provide funding for asset creation and support.
In one specific HP situation, the creators were a distinct team (the PL "Platform") in one product line organization, PL1. Their targeted utilizers included product teams in PL1, and also product teams in other product line organizations, PL2, PL3 and PL4. Initially, PL1 managers had strongest control over the PL platform team. To remedy the imbalance, senior managers implemented a strategic steering committee, composed of project managers from each stakeholder project in PL1-PL4 and the Platform project. In addition, each product line organization provided staff and funds to the Platform team as a way of paying for the assets and support. (The platform team were both creators and support). Nevertheless, because PL1 managers were not rewarded for Platform reuse results, they periodically redirected the Platform team resources to meet PL1 product needs, at the expense of PL2-PL4 needs.
On one hand, if creators are embedded as members of product teams or report to the product team manager, they too often get redirected to assist with urgent product construction at the expense of asset creation.. On the other hand, independent asset creation teams can easily neglect their responsibility to meet the needs of utilizer teams. They may then prioritize their efforts to produce assets, libraries and tools that are poorly matched to needs, even though technically excellent. Perceived as "overhead" or "unresponsive," they get frustrated and either leave the organization, or try to become as "independent vendors" to sell the assets or make their own products.
As illustrated, reuse efforts can fail in a variety of ways without appropriate structure and informed managment. The process and organization must assist a manager in anticipating and detecting these situations soon enough to correct an imbalance.
Organization issues such as structure, process and management are critical factors in reuse-oriented product development. In practice, it is important to separate creator teams from utilizer teams. It is very risky to require a product team to work on a critical deadline-driven product and, at the same time, to produce reusable assets for others.
Papers and panels in the 1994 3rd International Conference on Software Reuse discuss several of these and issues (see also the summary in Software Engineering Notes[8]). My next column will discuss how to incrementally start a reuse program with pilot projects.
Thanks to HP reuse colleagues, Patricia Collins and Marty Wosser, for valuable contributions.
Martin L. Griss is a senior Laboratory Scientist in Hewlett-Packard Laboratories, Palo Alto. He leads the Reuse Engineering project, researching object-oriented reuse and distributed instrumentation kits. Known as HP's "reuse rabbi", he previously managed the Software Reuse Department, was Director of the Software Technology Laboratory, and led a HP Corporate Engineering project to introduce software reuse into HP's software development processes. Before coming to HP, he was an Associate Professor of Computer Science at the University of Utah. He received a Ph.D. in Physics from the University of Illinois in 1971, and a B.Sc from the Technion, Israel in 1967. He may be reached by email at griss@hpl.hp.com, by FAX at +1 415-857-8526, or by mail at HP Laboratories, 1501 Page Mill Road, Palo Alto, CA 94303-1126, USA.