14.5 What Makes Software Product Lines Difficult?

It takes a certain maturity in the developing organization to successfully field a product line. Technology is not the only barrier to this; organization, process, and business issues are equally vital to master to fully reap the benefits of the software product line approach.

The Software Engineering Institute has identified twenty-nine issues or "practice areas" that affect an organization's success in fielding a software product line. Most of these practice areas are applied during single-system development as well, but take on a new dimension in a product line context. Two examples are architecture definition and configuration management.

Architecture definition is an important activity for any project but, as we saw in the previous section, it needs to emphasize variation points in a software product line. Configuration management is also an important activity for any project but is more complex for a software product line because each product is the result of binding a large number of variations. The configuration management problem for product lines is to reproduce any version of any product delivered to any customer, where "product" means code and supporting artifacts ranging from requirement specs and test cases to user manuals and installation guides. This involves knowing what version of each core asset was used in a product's construction, how every asset was tailored, and what special-purpose code or documentation was added.

Examining every facet of product line production is outside the scope of this book, but the next section will examine a few of the key areas to give a flavor of the qualitative difference between product line and single-system development. These are issues that an organization will have to face when considering whether to adopt a product line approach for software development.

ADOPTION STRATEGIES

Getting an organization to adopt the product line approach is in many regards like any other technology insertion problem. How to solve it depends on the organization's culture and context.

Top-down adoption comes when a manager decrees that the organization will use the approach. The problem here is to get employees in the trenches to change the way they work. Bottom-up adoption happens when designers and developers working at the product level realize that they are needlessly duplicating each other's work and begin to share resources and develop generic core assets. The problem here is finding a manager willing to sponsor the work and spread the technique to other parts of the organization. Both approaches work; both are helped enormously by the presence of a strong champion-someone who has thoroughly internalized the product line vision and can share that compelling vision with others.

Orthogonal to the issue of in which direction the technology will grow is the question of how the product line itself grows. Here there are two primary models.^[1]

^[1] These models were identified by Charles Krueger at a recent Dagstuhl workshop on software product lines (www.dagstuhl.de).

In a proactive product line, an organization defines the family using a comprehensive definition of scope. They do this not with a crystal ball but by taking advantage of their experience in the application area, their knowledge about the market and technology trends, and their good business sense. The proactive model is the most powerful of the two product line growth models, because it allows the organization to make the most far-reaching strategic decisions. Explicitly scoping the product line allows you to look at areas that are underrepresented by products already in the marketplace, make small extensions to the product line, and move quickly to fill the gap. In short, proactive product line scope allows an organization to take charge of its own fate.

Sometimes an organization does not have the ability to forecast the needs of the market with the certainty suggested by the proactive model. Perhaps the domain is a new one. Perhaps the market is in flux. Or perhaps the organization cannot afford to build a core asset base that will cover the entire scope all at once. In this situation, a reactive model is more likely. Here an organization builds the next member or members of the product family from earlier products. With each new product, the architecture and designs are extended as needed and the core asset base is built up from what has turned out to be common-instead of what was preplanned to be common. The reactive model puts much less emphasis on upfront planning and strategic direction setting. Rather, the organization lets itself be taken where the market dictates.

Knowing the various adoption models can help an organization choose the one that is right for it. The proactive model requires an initial investment but less rework than the reactive model. The reactive model relies exclusively on rework with little initial investment. Which model should act as a guide for a particular organization depends very much on the business situation.

CREATING PRODUCTS AND EVOLVING A PRODUCT LINE

An organization that has a product line will have an architecture and a collection of elements associated with it. From time to time, the organization will create a new member of the product line that will have features both in common with and different from those of other members.

One problem associated with a product line is managing its evolution. As time passes, the product line-or, in particualr, the set of core assets from which products are built-must evolve. That evolution will be driven by both external and internal sources:

External sources

- New versions of elements in the line will be released by their vendors, and future products will need to be constructed from them.
- Externally created elements may be added to the product line. Thus, for example, functions that were previously performed by internally developed elements may now be performed by elements acquired externally, or vice versa. Or future products will need to take advantage of new technology, as embodied in externally developed elements.
- Features may be added to the product line to keep it responsive to user needs or competitive pressures.
Internal sources

- It must be determined if new functions added to a product are within the product line's scope. If so, they can simply be built anew from the asset base. If not, a decision must be made: Either the enhanced product spins off from the product line, following its own evolutionary path, or the asset base must be expanded to include it. Updating the product line may be the wisest choice if the new functionality is likely to be used in future products, but this capability comes at the cost of the time necessary to update the core assets.
- If the product line assets are changed, even if the organization is in a position to issue a "recall," replacing old products with ones built from the most up-to-date version of the asset base does not mean that it should do so. Keeping products compatible with the product line takes time and effort. But not doing so may make future upgrades more time consuming, because either the product will need to be brought into compliance with the latest product line elements or it will not be able to take advantage of new functions added to the line.

ORGANIZATIONAL STRUCTURE

An asset base on which products depend, but which has its own evolutionary path, requires an organization to decide how to manage both it and product development. Jan Bosch [Bosch 00b] has studied product line organizational models and has identified four types.

Development department. All software development is concentrated in a single unit. Each unit member is expected to be a jack-of-all-trades in the product line, doing domain engineering or application engineering when and as appropriate. This model appears in small organizations and those that provide consulting services. Although it is simple, with short communication paths, having a single unit has a number of distinct drawbacks. Bosch wrote that it probably works only for units of up to 30 people (and that sounds high to us) but in very small organizations whose product lines are commensurately small, it can be a viable starting-out approach.
Business units. Each business unit is responsible for a subset of the systems in the product family, which are clustered by similarity. Shared assets are developed by the units that need them and made available to the community; collaboration across business units to develop new assets is possible. This model has variations depending on how flexible a business unit can be in developing (or modifying a shared asset). With no constraints, the products tend to diverge on their own evolutionary paths, negating the product line approach. Responsibility for particular assets is assigned to specific business units, which must maintain their assets for use by the entire product line. Other business units are required to make use of these assets. Bosch estimates that this model could apply to organizations with between 30 and 100 employees. It suffers from the obvious risk that a business unit will focus on its own product(s) first and the good of the product line will take a back seat.
Domain engineering unit. A special unit is given responsibility for the development and maintenance of the core asset base, from which business units build the products. Bosch writes that when organizations exceed 100 employees, communication channels among separate business units become untenable and a focusing channel to a central shared asset unit becomes necessary. In this model, a strong and disciplined process becomes much more important to manage the communication and to ensure that the overall health of the product line is the goal of all parties.
Hierarchical domain engineering units. It may pay to regard hierarchically a product line that is very large and/or very complex. That is, the product line may consist of subgroups that have more in common with each other than with other members of the product line. In this case, a domain engineering unit may turn out shared assets for the product line at large, and another domain engineering unit may turn out shared assets for the specialized subgroup. This example is of two levels, but the model could be extended indefinitely if the subgroups have specialized sub-subgroups, and so forth. Hierarchical domain units work for very large product lines, built by very large organizations. Their main disadvantage is the tendency to bloat, reducing the organization's responsiveness to new needs.