14.1 Overview

A software architecture represents a significant investment of time and effort, usually by senior talent. So it is natural to want to maximize the return on this investment by re-using an architecture across multiple systems. Architecturally mature organizations tend to treat their architectures as valuable intellectual property and look for ways in which that property can be leveraged to produce additional revenue and reduce costs. Both are possible with architecture re-use.

This chapter is about the explicit, planned re-use of a software architecture (and other assets as well) across a family of related systems. When an organization is producing multiple similar systems and re-using the same architecture (and elements associated with that architecture), it enjoys substantial benefits that include reduced cost of construction and reduced time to market. This is the lure of the software product line, defined as

a set of software-intensive systems sharing a common, managed set of features that satisfy the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way. [Clements 02b, 5]

The vision is of a set of re-usable assets that includes a base architecture and the common, perhaps tailorable, elements that populate it. It also includes designs and their documentation, user manuals, project management artifacts such as budgets and schedules, and software test plans and test cases. As we will see, achieving this vision depends critically on establishing the correct scope for the product line.

When a product line has been successfully established, each re-usable asset is saved in a core asset base because it can be applied to more than one system and because re-using it will be cheaper than re-inventing it. Core assets ideally are designed with variation points-that is, places where they can be quickly tailored in preplanned ways. Within a successful product line, system building becomes accessing the appropriate assets, tailoring them as required for the system at hand, and then assembling that system. Any software developed for an individual product, if needed at all, tends to account for less than 20% of the total software. Integration and testing replace design and coding as the predominant activities.

Product lines are, of course, nothing new in manufacturing. Many historians trace the concept to Eli Whitney's use of interchangeable parts to build rifles in the early 1800s, but earlier examples also exist. Today, Boeing has one, as do Ford, Dell, and even McDonald's. Each company exploits commonality in different ways. Boeing, for example, developed the 757 and 767 transports in tandem, and the parts lists of these two very different aircraft overlap by about 60%.

Software product lines based on inter-product commonality represent an innovative, growing concept in software engineering. Every customer has its own requirements, which demand flexibility on the part of the manufacturers. Software product lines simplify the creation of systems built specifically for particular customers or customer groups.

The improvements in cost, time to market, and productivity that come with a successful product line can be breathtaking. Consider:

• Nokia is able to produce 25 to 30 different phone models per year (up from 4 per year) because of the product line approach.

• Cummins, Inc., was able to reduce the time it takes to produce the software for a diesel engine from about a year to about a week.

• Motorola observed a 400% productivity improvement in a family of one-way pagers.

• Hewlett-Packard reported a time to market reduced by a factor of seven and a productivity increase of a factor of six in a family of printer systems.

• With a family of satellite ground control systems it commissioned, the U.S. National Reconnaissance Office reports the first product requiring 10% the expected number of developers and having 90% fewer defects.

Creating a successful product line depends on a coordinated strategy involving software engineering, technical management, and organization management. Since this is a book on software architecture, we focus on the software architectural aspects of software engineering, but all aspects must work together for an organization to successfully create a product line.