Software Product Lines
Framework Home
Product Line Essential Activities
Product Line Practice Areas
Software Engineering
Practice Areas
Technical Management
Practice Areas
Organizational Management
Practice Areas
Building a Business Case
Customer Interface Management
Developing an Acquisition Strategy
Launching and Institutionalizing
Market Analysis
Organizational Planning
Organizational Risk Management
Structuring the Organization
Technology Forecasting
Frequently Asked Questions

A Framework for Software Product Line Practice, Version 5.0

Next Section Table of Contents Previous Section

Launching and Institutionalizing

This practice area is about organizational change.

Change projects are undertaken to help organizations prepare themselves to adopt a new technology or a new way of doing business. These projects are highly dependent on the context of the organization; an invariant sequence of steps to execute the project is inappropriate. Successful change projects take into account not only the specific technology involved but also the human aspects of change.

Organizational change involves an assessment of the current state, an articulation of the desired state, and an assessment of the gulf between the two. After that, solution strategies for bridging the gulf can be crafted, tried out, and then scaled up. Lessons learned along the way can help refine your understanding of the current state, the desired state, or the intended solutions.

Aspects Peculiar to Product Lines

The change being launched and institutionalized is of course the software product line approach. This practice area is relevant whether an organization is starting a product line effort for the first time or trying to expand and/or improve the ongoing product line effort. Launching and institutionalizing a product line is somewhat different in that it is a practice area about applying the other practice areas, as appropriate to the needs and capabilities of an organization.

Launching and institutionalizing a product line differs in the particulars from other change projects because product line adoption involves technology and business change. Launching a product line is about the judicious and timely adoption of product line practices. By factoring in a characterization of your individual situation, the part of the product line effort you want to accomplish, the groupings of practice areas that meet your individual needs, and a dynamic view of how the practice areas in that grouping interact to help you accomplish your goals, you can bring the practice areas to bear on your situation most effectively.

The end game of product line adoption is to have an operational product line. A product line adoption plan must be created to describe how product line practices will be appropriately rolled out across the organization. Depending on the starting point of the organization, this plan1 may provide for the definition of processes, the initiation of practices, the selection and implementation of pilots, or the engineering of a product line. If the intention is that the entire organization will eventually adopt a product line approach, the plan should address the entire organization. For example, suppose that a chosen pilot project involves only one part of the organization that eventually will make the transition. After all, that is one of the benefits of a pilot project: it does not involve the entire organization, so missteps and early mistakes are confined to a small effort. What, then, do the other parts of the organization do while the pilot is underway? If they do nothing, it's business as usual for them, and in more than one organization we've seen, that has spelled trouble. Those people may feel left out and disenfranchised, and their support for the transition to product lines may suffer as a result. But an adoption plan that applies to the organization (a project, business unit, or corporation) as a whole may be the solution. Even if a group is not participating actively in the pilot project, its members can serve as reviewers, receive training, practice building a business case or scope definition, or be assigned process improvement activities to shore up their capabilities for when they will join the product line. A product line adoption plan–the result of the launching effort–is the master plan showing how all parts of the organization adopt product line capabilities, perhaps in a highly staged manner.

Institutionalizing product lines requires that the organization consistently use product line practices to achieve its business goals. Product lines become community practice. To do that, an organization must

Application to Core Asset Development

Launching a product line will, of course, kick off the core asset development effort, but more is required to ensure the proper organizational context for core asset development. Such activities as funding, training, and structuring the organization will likely be part of launching. In fact, a product line adoption plan may be one of the first core assets that an embryonic product line effort will develop.

Institutionalizing a product line involves improving the processes that are associated with building, maintaining, and evolving the core assets and making those processes part of standard organizational practice.

Application to Product Development

Launching a product line often involves choosing a pilot project or two with which to demonstrate the product line activities. (For information about choosing pilot projects, see the "Example Practices" section below.) These pilot projects should, if possible, yield marketable products, which will enhance the fidelity of the demonstration and subject the core assets used in their construction to real-life constraints. Institutionalizing a product line means making the development of products routine and predictable while still meeting the organization's product line goals. The achievement of this steady state is a signal that product line practice has, in fact, been institutionalized.

Example Practices

Launching and institutionalizing a software product line is a matter of orchestrating the activities of all the applicable practice areas over time. Your organization's specific launching strategy will be unique. However, many organizations have had success following the SEI Adoption Factory pattern in conjunction with a technology change model, such as the SEI Initiating, Diagnosing, Establishing, Acting, Learning (IDEAL) model. (This pattern and model are both described below.) Beyond that, the specific practices discussed below will suggest some additional approaches for bringing your organization up to product line speed.

Use the Adoption Factory pattern: Product line practice patterns deal with applying practice areas in a way that is most relevant to the organization's situation [Clements 2002c, Ch. 7]. Finding (or inventing) the appropriate patterns is, in many ways, the essence of launching and institutionalizing a software product line. The Adoption Factory pattern can serve as a generic roadmap for product line adoption [Northrop 2004a].

The phases and focus areas view of the Adoption Factory pattern in the following figure illustrates the dynamic structure of the pattern as three columns, corresponding to the temporal phases of product line adoption, and three rows, corresponding to the focus areas for certain patterns and practice areas. The three temporal phases are

1. Establish Context: which involves paving the way for product line adoption
2. Establish Production Capability: which involves developing the core asset base and the production infrastructure and managing those efforts at the project and cross-project levels
3. Operate Product Line: which involves using the core asset base to efficiently build products and monitor and improve the product line operation

The three focus areas are

4. Product: which involves those activities for defining and developing products and their common assets
5. Process: which involves the underlying processes and production infrastructure necessary to adopt a product line approach
6. Organization: which involves the management practices and activities necessary to adopt a product line approach and operate a software product line

Within each of the nine cells created by the intersection of a phase and focus area are the intuitively named subpatterns2 [Clements 2002c, Ch. 7] that make up the Adoption Factory pattern.

Adoption Factory Pattern Annotated with

Adoption Factory Pattern Annotated with Adoption Phases and Focus Areas

Other useful views include the practice area view, which shows the constituent practice areas associated with the subpatterns, the roles view, which describes the principal roles involved in each of the nine cells, and the outputs view, which describes the key artifacts produced.

Use the IDEAL model: In the technology change domain of process improvement, the IDEAL model has enjoyed wide success [McFeeley 1996a]. With some generalizations, the IDEAL model is also appropriate for the launching of a product line. As shown in the next figure, the IDEAL model is iterative, allowing the reevaluation of the changing organizational context as the technology change project proceeds. This iteration also makes the model applicable to launching a product line effort from different levels of product line sophistication and to improving or institutionalizing the product line effort. This iterative cycle may be executed as many times as necessary to achieve the desired organizational state.

The model consists of five phases, each providing a basis for the next phase, with the final phase feeding back to the beginning. The five phases are Initiating, Diagnosing, Establishing, Acting, and Learning:

The IDEAL Model for Technology Change

The IDEAL Model for Technology Change

Recognize that a given IDEAL iteration cycle may emphasize or de-emphasize a particular phase depending on the iterations that have gone before. For example, it is typical for more attention to be needed for the Initiating phase of early cycles than of later cycles. Specific details might be best determined by evaluating the risks associated with each phase, much as in the Spiral development model [Boehm 1988a].3

Use the Adoption Factory pattern and the IDEAL model together: As noted, the Adoption Factory pattern lays out the change that needs to occur when moving to a product line approach, but it lacks change management mechanisms and guidance about how to perform incremental adoption. On the other hand, the IDEAL model is a general model for guiding change but lacks product-line-specific guidance. These two models may be used effectively together when informed by contextual information about an organization (e.g., cultural aspects, degree of process discipline, and other particular strengths and weaknesses of the organization).

Below, we describe some ways in which the Adoption Factory pattern can be used within the phase sequencing of the IDEAL model. Note that not all these activities would necessarily occur in a single IDEAL cycle.

Use pilot projects: Pilot projects can be an important means of reducing risk and learning more about the organizational and technical issues associated with the product line effort. A successful pilot project can also be an effective means of building advocacy. A pilot should be viewed as a controlled experiment to test specific ideas or concerns.

Some criteria to consider when selecting a pilot include its

Use proactive, reactive, and incremental approaches: As noted in "All Three Together," organizations may choose to take a proactive, reactive, or incremental approach to product line adoption. As discussed, each approach has its advantages and disadvantages.

Use lightweight approaches at first: When initiating a product line effort, some organizations report success with using lightweight organizational structures and lightweight processes to support them. These lightweight approaches facilitate smoother transitions to product lines that can be changed quickly and nimbly as the organization learns what does and does not work for its particular situation. It is worth noting that this approach is a form of piloting. Clements and Krueger debate the advantages and disadvantages of lightweight and other approaches [Clements 2002b].

Use product line diagnostics: Before an organization can launch and institutionalize a product line capability successfully, it needs to know its blind spots. If it is lacking necessary expertise in one of the practice areas (especially one that tends to manifest itself early in the product line life cycle, such as scoping or requirements engineering), it is unlikely to make a successful (let alone smooth) transition to sound product line practice. However, by recognizing potential trouble spots early, you can focus judiciously on resources and shore up any areas of weakness that, if left untreated, would undermine the product line effort.

One instrument to help an organization identify problem areas is the SEI Product Line Technical Probe (PLTP) [Clements 2002c, Ch. 8]. This diagnostic identifies an organization's strengths and challenges in each of the product line practice areas. These results provide the grist for an adoption or launching plan, the first part of which will be to rectify any deficiencies in critical skill areas. Other product line diagnostics include the SEI Product Line Quick Look (PLQL), the Bosch Product Line Potential Analysis [Fritsch 2004a] and the European Union Information Technology for European Advancement (ITEA) Business, Architecture, Process, Organization (BAPO) evaluation [van der Linden 2004a].

Develop product line goals, objectives, and strategies: Technology change should be initiated not for its own sake but to support specific organizational goals. Thus, an early step in the technology change project is to establish an appropriate set of goals, which are validated by a supporting rationale. A set of objectives should also be determined to provide high-level, measurable indicators of progress toward the goals. Given a set of goals and supporting objectives, a number of different strategies are typically appropriate to the achievement of those goals. Presumably, one of those strategies is to initiate (or expand) a product line effort. Another strategy might be to build (or further mature) a software process infrastructure to provide a foundation for the product line effort. An internal workshop is an excellent vehicle for articulating and capturing the goals, objectives, and strategies that will serve as the foundation for building an adoption plan. As product line adoption proceeds, the organization should revisit those items and update them as necessary.

Use process improvement as a basis for launching and institutionalizing: Process discipline provides a foundation for product line practice. As indicated by the "Process Discipline" practice area's placement in the Establishing Context phase of the Adoption Factory pattern, it is likely to be in your organization's best interests to initiate a process improvement effort early in, if not prior to, your software product line adoption.

Many organizations use SEI Capability Maturity Model Integration (CMMI) for Development with Integrated Product and Process Development (IPPD) as the basis for their process improvement efforts [SEI 2006a]. While some of the process areas on the CMMI models provide a basis, there is always something extra required to transform a single-system-oriented process to an appropriate corresponding product line practice.

CMMI is certainly not the only model for process improvement; many organizations have adopted a Six Sigma approach [Brassard 2001a]. Originally developed in the 1980s by Motorola to address electronics manufacturing quality, Six Sigma has evolved into a philosophy, an improvement framework supported by a set of improvement tools, and a structured approach for business improvement. The philosophy of Six Sigma is to improve customer satisfaction by reducing and eliminating defects, resulting in greater profits. The Define-Measure-Analyze-Improve-Control (DMAIC) Framework is a means to improve existing processes and products.

With its "Plan, Do, Check, Act" roots, DMAIC has been described as a "weakness-based," tactical approach to getting to the bottom of a problem through quantitative means.

Practice Risks

The risks of launching a product line relate to misapplying the product line approach by either failing to institute beneficial practices or instituting practices that are not appropriate to the particular organizational situation. A poor launching and institutionalizing strategy will result in failure of the product line to meet its goals, very likely because the staff will fail to accept it as a way of doing business. Such a failure can result from

Further Reading

[Ardis 2000a]
Ardis and colleagues describe the steps that product line advocates took at Lucent.

[Boeckle 2002a]
Boeckle and colleagues recommend an approach for adopting and institutionalizing a successful culture of product lines in an organization.

[Bosch 2002a]
Bosch proposes a set of bellweather indicators of an organization's sophistication with respect to software product lines. These indicators can be used to set adoption ambitions appropriately and help produce a feasible launch strategy.

[Brassard 2001a]
Brassard and Ritter provide an easy-to-read, quick reference to the "art and science" of Six Sigma.

[Clements 2002c, Ch. 7]
Clements and Northrop describe 12 basic product line practice patterns that help effect a "divide and conquer" approach to launching and institutionalization.

[Clements 2002c, Ch. 8]
Clements and Northrop describe the Product Line Technical Probe in detail.

[Fritsch 2004a]
Fritsch and Hahn describe the Bosch product line diagnostics.

[Northrop 2004a]
Northrop describes the Adoption Factory pattern and its views and use in detail.

[Wappler 2000a]
Wappler from IBM Consulting Group focuses on a pilot project as a way to mitigate risks during launching.

[van der Linden 2004a]
Van der Linden and colleagues describe the BAPO product line diagnostics.

Next Section Table of Contents Previous Section


1 For a complex adoption, it is often better to address details in subordinate action plans.

2 "Process Discipline" is actually a practice area. This practice area is singled out because experience has shown that organizations that lack the ability to define and follow processes, even lightweight or agile ones, need to address that deficiency early in their adoption path.

3 Jones discusses how the IDEAL and Spiral models complement each other [Jones 1996b].

4 Linda Northrop summarized the results of applications of the PLTP during an experience report at SPLC 2005.