The community has made tremendous progress in understanding the critical technology, methods, processes, and organizational factors that lead to effective architected, component reuse. There is of course much more we can do, but still, far too few software developing organizations see reuse or CBSE as the solution to the problems they have, nor do they practice component reuse systematically. Far too few schools teach much about reuse and components. A CBSE handbook, summarizing industry best practice and state-of-the-art, could be an extremely useful vehicle for moving us forward.

However, experience with such handbooks in the past suggests that we should think very carefully about who the audience(s) for the handbook are, how this handbook should be used, and how it should consequently be structured. I propose several additions and modifications to the strawman handbook outline, to clarify these issues, as well as incremental adoption, organizational and process maturity, and CBSE methods.

Keywords: software engineering, components, education, technology transfer, best-practice, architecture.

Over these years, I have had the opportunity to lead and/or work on three handbook projects, a book on architected reuse and component-based software reuse, and several related projects. These include:

1. A "systematic reuse handbook" workgroup at WISR-4 (Workshop on Institutionalizing Software Reuse) 1991, in which we created an outline and discussed a process for building the handbook, and transferring the knowledge. See wisr91-hand.txt for a summary of this workshop. Several alternate handbook structures were discussed, such as one based on reuse process framework, one based on independent modules, one based on incremental adoption, and one with different sections for different audiences.
2. A reuse handbook for use at HP, started in 1990 and evolved during 1991-1992, incorporating the WISR handbook outline, 1. above. In this project we envisioned a "loose leaf" customizable handbook, in the spirit of some time managers or process handbooks: the idea was that a reuse manager could customize a process handbook for his group, selecting only material germane to the current process, reuse, and architecture maturity of his organization. This handbook was used extensively inside HP in the period 1992 to 1995 to establish reuse pilots as part of a corporate reuse program. A training class to introduce the handbook was prototyped. The experience gained in this work, influence the content and structure of the book I subsequently wrote.
3. An architecture handbook workshop at OOPSLA 1994(?), led by Bruce Anderson. This included a structure for architectural styles, mechanisms, standard architectures and the beginning of design patterns.
4. A book on "Software Reuse: Architecture, Process and Organization for Business Success" with Ivar Jacobson, and Patrik Jonsson[jacobson97].. This book provides a holistic view of model-based component software development (using UML), covering a variety of organizational, management, technical, architectural, process and business issues, in a consistent framework.
5. A web-based reuse process guide, produced as part of a 1996 consulting engagement by the HP PSO (Professional Services Organization) OO and subsequently refined for HP use [griss1997].

My related work on the UML standardization effort, on reuse and process maturity models, on technology transfer for an architected, component based product line at HP, on model-driven management agents, and on software engineering standards, provided the many opportunities for thinking and writing about architecture, components, models, patterns, and knowledge transfer. I have produced many training slides, run workshops, produced many small briefing documents and templates.

I learned a number of things from the various handbook experiences above, which could be valuable in the proposed CBSE handbook effort, and the workshop itself.

Content is of course really important. We have lots of promising technology, methods, and guidelines that can be adapted from the reuse, architecture, OO and patterns community. But too little is taught systematically [bucci98], or practiced widely. As an example, we believe that we have a good understanding of how issues and choices in several areas could influence critical success or failure of architected, component reuse -- CBSE:

• Technology - OO; architecture; patterns; components; interfaces; generators; library systems and classification schemes; UML, �.
• Process - domain analysis, CFRP, DFR-DWR, incremental pilots, process, product and reuse metrics; process maturity models; economics, Catalysis, RSEB, �
• People: distinct create, reuse, manage, support organizations; architecture teams, explicit high-level management leadership; domain- and component- engineering skills; roles; �

As an expert in many of these areas, I can contribute to content in many sections of the strawman handbook, such as 1b -- "how does CBSE relate to similar fields ", 2a - "processes and methodologies", 2b - "organizational issues", and to many of the sub-sections of 3, such as "UML", "libraries", tool, etc.

A key learning from the HP handbook project, was the tension between size and usability of the handbook (partially addressed by a loose leaf approach). Another was the need to provide customized material to different groups. Another was the difficulty of keeping such a handbook up-to-date. And finally, the difficulty in getting groups to use such handbooks.

Thus an important concern for the handbook effort proposed is to discuss the goals and audiences(s)of the handbook and how we expect it to be used. This will certainly have an impact on the structure of the outline and mechanisms used for customization and adoption, if any.

Some other observations and suggested changes to the strawman outline:

• The preamble specifically mentions engineering handbook. Is the intent to exclude, or segregate management material, perhaps to later produce a management handbook for CBSE? Certainly material on adoption, organization, economics have a large management as well as process content. One idea would be to have a separate management section along with the engineering sections, or for each section to have the managerial implications as well as a technical implications.
• I would separate recommended processes and methods from the adoption section, 2. That is, I would collect managerial and adoption issues in one section, adding material on CBSE and process maturity models, the role of pilots etc.. I would then have a separate section, covering recommended CBSE processes and methods. For example, we should mention domain engineering (e.g., FODA, ODM, Synthesis), Catalysis, Rational Unified process, RSEB, etc., or least integrate these into a recommended CBSE processes for architecture, component design and component use. The CFRP (common framework for reuse process) could provide a useful source of process material. Alternatively, the methods could be considered part of technology or although that is not the current scope of technology in section 3 -- certainly methods and process are more than just notation and modeling languages.
• Section 4, could be more usefully structured to distinguish "best practice", "state-of-the-art", "advanced", "domain-specific" and "research" areas, much in the spirit of the Software Engineering Body of Knowledge [IEEE98].
• It is important to add a reference material, bibliography and some templates and tables.

Key outline elements of the HP reuse handbook (developed before the growing use of modeling, UML) are included in the appendix. Book also provides an interesting overall outline, separating architecture, process and management issues[jacobson97]. The knowledge captured in the CBSE handbook, as a component community best-practice consensus could be injected into the evolving software body of knowledge (SWEBOK)[IEEE98].

There are now many books on reuse, components and architecture, and a growing number of reuse courses, both at schools and from vendors. However, apart from the DOD Reuse technology roadmap [DOD96], and the SPC adoption guidebooks, there does not seem to be a community consensus on CBSE best practice, or how best to drive adoption. No one seems to be addressing this in the context of the new licensing and accreditation context.