Martin L. Griss, Laboratory Scientist, Hewlett-Packard Laboratories
Patricia Collins, Reuse Adoption Consultant, Hewlett-Packard Software Initiative
[Extended version of column to appear in Object Magazine, Jul 1995]
In this column, I focus on pilot projects in incremental reuse adoption. I have asked Patricia Collins, my colleague from HP's Corporate Software Initiative, to join me in discussing how successful reuse projects get started. At HP, reuse adoption is much more likely to succeed in the long run if the adoption begins with a small, focused project, then scales up incrementally.
When a software development organization resolves to adopt systematic reuse, they step up to a multidimensional engineering management task. Instinctively, many organizations decide they must tackle all of the dimensions simultaneously, intending to change dramatically to create, support, and utilize a reusable software base. Because everything is changing in parallel, they often do not know if they are making progress until they have either succeeded or failed (when the reusable software is integrated and delivered in a couple of products). Management patience usually runs out some time before the software base is implemented, some two to three years later.
The reason organizations initiate a single-stage revolution for systematic-reuse adoption is that they don't have enough reuse experience to know how to phase in the adoption with a roadmap of incremental changes that result in a revolutionary change in the way they develop software.
A roadmap for incremental reuse adoption keeps the focus on wide-spread, architecture-based reuse. The roadmap must address deliverables, technology, engineering processes, project management, and business management. The road map is complemented by an adoption plan for getting from the existing software design and implementation practices to practices based on a reusable architecture and other software assets.
Much has been written on selecting, running and expanding reuse pilots [1,2]. A pilot project provides real, reusable assets for application in business solutions. The incremental adoption approach has four fundamentals:
Successful reuse adoption is most highly correlated with incremental adoption within HP. Initially, the creators produce only a few high-quality assets, sometimes based on an abstract architecture or design pattern. A roadmap shows how that abstract architecture incrementally becomes a reusable architecture, and how the coverage for reusable designs and implementations increases.
Those initial assets are delivered to only a few pilot projects, along with support in integrating the assets with the rest of the product software. Many unexpected or unfamiliar issues can be encountered and addressed with less overall expenditure and risk with this kind of incremental reuse adoption. For OO frameworks, it is particularly important to understand what the utilizers' level of skill is in understanding and employing this new technology. Training is often required for creators and utilizers.
Early utilizers take the abstract architecture and available assets, and develop or reengineer code for the rest of the product architecture. In this case, the adoption plan must call out the sequence of components to be developed, as well as the plan for supporting new utilizers.
Beginning with a reusable architecture and a few assets is the adoption approach of choice when the organization is at a point where leveraging old software is an increasing risk, either to schedule or quality, or when the software will be significantly rewritten anyway (e.g. for new hardware platform, programming language, change in algorithms). Even with these motivations, the most frequent obstacle is making engineering resources available for the reusable architecture and asset development effort.
There is a great satisfaction in architecting a scaleable, extensible, portable, and otherwise rugged (flexible) software framework that provides core capabilities for a family of products. Starting with a clean screen and a set of constraints is still the task for which we engineers receive the most academic practice and recognition. In HP, many reuse efforts have begun with an intention to employ a new architecture and new components, in fact to deliver a framework that would provide 60% or more of a product's firmware or software.
Initially, utilizers needs are gathered and asset creators go off to produce the framework. When the framework is demonstratable, the creators return to the utilizers to begin the adoption process. Invariably, the divergence between the utilizers' current needs and what the creators finally deliver is so significant that the utilizers declare they cannot use the framework. In two HP reuse initiatives, OO frameworks were delivered to waiting utilizers, but they found the solutions too difficult to use even though they provided desired product capabilities.
In another organization, the creators set out to develop an OO framework that would provide the 70% of the software that was expected to be common to the next few years of products. They found two partner product-development projects as a way of piloting the framework. However, with the framework still in architectural investigation, it became clear that the overall organization wo uld not support committing the number of engineering resources it would take to design, develop and test that much new software in time to meet the product release requirements. Both OO and reuse aspirations had to be "compromised."
The revised framework adoption plan calls for continued work on the OO architecture, with reengineering of some existing non-OO software to be integrated with the new OO software. The first parts of the framework to be developed as new OO software are those for new product capabilities. In the interim, non-OO-based products will continue to be able to reuse or leverage the software that is being reengineered as the reusable architecture evolves.
Some creator organizations have piloted with a few components providing innovative product capabilities, based on the utilizers' existing (often, implicit) architecture. The utilizers value the technical innovativeness of the components and the ease of integration with their product software. This approach works when the various utilizers have similar product architectures.
In one organization, there was a natural unit of reusable software, with an industry-standard API. Many product lines were getting market pressure to provide this new industry standard. A small, centralized engineering team was commissioned to produce a single reusable implementation. To support effective utilization, the team developed an architectural abstraction for the software, in the form of an interface between the component and the rest of the software in any of the targeted products. Their deliverables included C code for about 5% of the product software, an architectural abstraction for integration support, and consulting for writing the product-specific interface.
Once this piece was delivered and stabilized, the small team began looking at possibilities within the architectural abstraction for additional reusable assets. Over time, the architectural abstraction is being refined to be a common architectural design, with software assets developed and supported by the central team.
The biggest challenge in the reusable component delivery pilot is ensuring that, over time, the organization does have a well-architected, reusable framework.
This is still an essential long-term goal because systematic reuse depends on a reusable architecture.
While it is much more difficult to maintain, evolve, and utilize software that is not explicitly architected for reusability, we have learned that the architecture can be initially incomplete, and that a significant number of existing components can be cost-effectively reengineered to fit this architecture and be packaged for reuse [3,4]. This is particularly useful for integrating a reuse approach with legacy software.
The chief challenge for the framework development team is not getting so linked with the single early adopter that the reusability of the architecture and the entire framework is seriously compromised.
There are formidable technical issues in designing a model for the specific architectural transformations. And there are equally difficult issues in designing the model for the organization's adoption of the series of architectural transformations. The adoption plan must show communications models, decision-making procedures, project planning, partnership strategies, roles and responsibilities, incentives and rewards.
Figure 1 - Incremental adoption
Incremental reuse adoption, summarized in Figure 1, is the best way to manage adoption risks. An essential part of incremental adoption is a pilot that offers a few highly-valued assets to a few early adopters who work with the creators as partners from the beginning. To ensure that the organization eventually has a truly reusable framework (which does not preclude framework evolution), a roadmap for architectural evolution and a companion development plan are essential.
In my next column, I will discuss reuse-oriented architectures, packaging and domain specific kits. Finally, Will Tracz's software reuse book is now available[5]. This is a humorous collection of essays, with many insightful guidelines on reuse practice.
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.