[ Up ] [ PISA ] [ Composition/Integration ] [ Domain Eng. ] [ Product Lines ] [ Certification ] [ Early Artifacts ] [ OO & DA ] [ Org. Principles ] [ Add. Info. ] [ References ]

Introduction

A product line is a group of related systems that, taken together, address a specific market segment. Product lines are most efficiently built from a common set of reusable assets: domain model, requirements, architecture, software components, test plans, project schedules, tools and environments, etc. A product line built in this way epitomizes planned and systematic reuse.

This working group explored the issues—technical, organizational, and market—associated with successful fielding of a product line from a common asset base. Experience reports were shared where available. The group’s discussion centered around terminology, experience reports, success factors, risks, architecture, and change management. Each will be discussed in turn.

Terminology

The group agreed to distinguish between a product line, which is a set of related systems that together address a market segment, and a product family, which is a set of related systems that are built from a common set of core assets. Thus, a product line is a market- or customer-driven concept, whereas a product family is a technology- or implementation-dependent concept. A product line need not be built as a product family (i.e., from a common set of core assets) although in the context of a reuse conference this type of product line is what we agreed to consider. Conversely, a product family need not be a product line (i.e., addressing a particular market niche).

What is the difference between a product line and a domain? Borrowing from the Domain Analysis working group, we agreed that a domain was a specialized body of knowledge, an area of expertise. Thus, it is an intangible thing, unlike a product line or product family, each of which is a specific set of actual (or envisioned) products.

Lingering confusion was cleared when we compared product lines and domains. There are:

• Product lines that encompass more than one domain—An automobile product line requires expertise in engines, suspension, interior design, and the like.
• Product lines that are synonymous with domains—"Relational databases" describes both a body of knowledge (domain) and a set of products (product line).
• Product lines that form a subset of a domain—Cellular phones form a product line wholly contained (in addition to other product lines such as pagers) within the domain of wireless communication.

Further, these terms are dependent upon the context in which they are used, as they are hierarchically recursive. One organization’s product (e.g., a GUI widget) may be but a single component in the product of an organization building large systems. Either may be built in a product line.

Experience Reports

Paul Clements presented the first case study. CelsiusTech Systems is a Swedish company that builds shipboard command and control systems for many navies around the world [BC96]. In December of 1985, they landed two major contracts simultaneously. Realizing that they could not possibly complete those contracts one at a time, they adopted a product line strategy as the only way to fulfill their company’s obligations. Today, CelsiusTech has fielded over 55 variations of their basic system on several different classes of ships, including submarines. A typical system has 15-30 nodes on a local area network, 30-70 CPUs, and 100-300 separate Ada programs of 1-1.5 million lines of Ada code. CelsiusTech reports around 80% verbatim reuse from system to system, delivery times an order of magnitude less than before, whole systems integrated by one or two people, reduced staff levels, and increased reliability, predictability, and customer satisfaction.

Jeff Poulin presented the second case study, an organization for a management information system product line at Lockheed Martin. It resembled the CelsiusTech organization in that there was a group responsible for maintaining the reusable assets, and this group is separate from the groups responsible for fielding individual products. Overseeing both the reusable asset group and the product groups is an architect with the authority to ensure products conform to the architecture, and the responsibility for evolving the architecture in response to change. A separate group is responsible for configuration management, maintaining a small number of versions of each of the assets.

For the third case study, Ernesto Guerrieri explained his company’s approach to product lines, which is to deliver product "kits" to customers. The domain is software for institutions of higher education: student information systems, alumni development, financial management, and human resources. A kit includes all of the documentation and configurable software with which a customer can produce a product to satisfy his particular requirements. Domain analysis forms an explicit front end to the process of producing a kit (which is equivalent to defining a product line). Using this product line approach, the company’s customers can receive a delivered system within about a month.

Success Factors

Different organizations will take different paths towards successful development and deployment (marketing) of a product line. The group spent time trying to enumerate what the discriminating factors were that would affect an organization’s approach or chances of success.

Organizational factors included the assets in hand: architectural skills, domain knowledge, transition champions, legacy software and artifacts, the source of funding, and whether there is a group aligned with no single product that has sole responsibility for the reusable assets.

Product factors include whether the reuse across products is large- or small-grained, and how challenging it is to build each product.

Domain factors include the stability of the application domain, the number of products that will populate the product line, the variability between individual products, the new technologies that are on the horizon, the life cycles of the products, and whether the domain features stable and well-defined architectures.

Market factors include the required time to market, and the size of the customer base.

Risks

Risks associated with product line development identified by the group include:

• Complacency—a product line defines a boundary of accommodated variation, and this box may turn into a box around the organization’s thinking.
• Over-restriction—a competitor may offer a product that varies in ways not accounted for by the product line, which may lure customers away.
• Expense—experience has shown that cost and time-to-market of early products in a product line may be higher than normal. Training costs may also be higher.
• Wrong generality—the first product, aiming to be general, may meet the first customer’s requirements poorly. Or, if the organization fixates on the first system in an attempt to prove the concept by making the first system work at any price, that first system may result in an approach that is not general enough.

 

The Role of Architecture and Architects

A product line cannot exist without an architecture. The architecture forms the basis for product line evolution. It is an expression of the commonality across products assumed by the product line designer(s). It is also at the very least a de facto expression of the variability that the product line encompasses. Every architecture divides all changes into three classes: (a) changes that are confined to a single component; (b) changes that affect several components; and (c) changes that affect the architectural underpinnings. Hence, an architecture that is successful in the context of a product line is one in which the variation across the products falls into the first or second class. Further, an architecture should make it so that the cost of a change (producing a variant) is proportional to the value of making that change as well as the likelihood that the change (variant) will be required.

The importance of architecture implies the importance of having a central architectural authority to hold tightly to the reins of the product line. A hierarchical arrangement is the norm, where there is a chief architect who retains authority, but who has a staff that helps promulgate policy and brings important matters to his or her attention.

Managing Change and Variation

Configuration management and version control are key issues that must be addressed carefully and rigorously in order for the product line to succeed. CM is more complicated in a product line context for two reasons:

1. A change must be considered not from the point of view of a single product, but in terms of keeping the changed component usable by all of the products that currently employ it; and
2. It is more likely to be necessary to maintain separate versions of reusable components, as opposed to simply supplying the most recent one, as may suffice in one-at-a-time development.

What happens when a request for a variant is outside the boundaries of the product line? Rejection or renegotiation of the request is certainly a possibility, but often this is not the desirable response. Impact analysis can be done to gauge the extent (and cost) of the change. As noted in the previous section, the product line architecture will determine how hard it will be to make the required modification(s). A business analysis can be done to determine the value of the new variant, perhaps in the context of anticipated market shifts where the variant might be of value beyond the specific customer who requested it. Then, as before, the cost and value can be compared. Thus, the concept of "outside the product line" really is a phrase without operational meaning. Ease of change ranges over a spectrum; it is not a boolean property. The required change(s) may be quite easy (e.g., via parameterization that is already in-place), somewhat hard (e.g., a component will have to be replaced), or very hard (e.g., the entire architecture must change).

Summary

Intellectual control seems to be a key to successfully developing a product line. An organization must achieve intellectual control over the domain(s) involved—deep domain knowledge is considered a crucial success factor—as well as over its own goals, plans, assets, and capabilities. Product lines strongly resemble conventional system building in many ways, especially when building a system with changeability in mind, and especially when building a system using reusable assets. However, there are important differences having to do with process, organizational structure, customer interfaces, and technical issues. An organization must be aware of the key issues if it hopes to successfully develop a product line and enjoy its considerable benefits.

[ Up ] [ PISA ] [ Composition/Integration ] [ Domain Eng. ] [ Product Lines ] [ Certification ] [ Early Artifacts ] [ OO & DA ] [ Org. Principles ] [ Add. Info. ] [ References ]