An Introduction to Product Lines

This month, I am going to introduce the concept of a product line. Next month, I'll discuss the benefits, some challenges, and some alternatives to a product line. Eventually we plan to let you know what we are doing in this area. Along the way, I also present several examples of product lines.

What is a product line?

If you are not familiar with the term, I expect you are at least familiar with the concept. A common example is a family of printers, such as HP's Officejet Pro All-in-One models. All the models print, fax, scan and copy. That is their common functionality. But they differ in important ways as well. Key differences include the size and number of paper trays, the size of the scanner (letter vs. legal), the support for wireless networking, the size of display, and their price. From a software perspective, they are more alike than different. But they do have differences, differences HP hopes will entice us to pay a bit more.

The same is true in automobiles. The differences between the DX, LX and EX models of a car are relatively few, but they are things that matter to us. So we pay for the upgrade.

From these two examples, and perhaps others you've been thinking about, a few key points emerge. First, a product line is used to create multiple products from some common or base functionality. A second point is that the products are not designed independently from one another. Rather, the whole product line is defined and designed together.

Our focus here, however, is not hardware product lines, but software product lines.

Software Product Lines

Time for a formal definition. According to the Software Engineering Institute, a software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying 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.

There are aspects to this definition I'm going to ignore right now, but the key elements are:

a set of multiple products
which share common features, and
which are developed from existing assets (libraries).

The first point is that a product line has multiple products, like the printers and cars. If you are making just one product, you don't have a product line. And continued evolution of a single product (rev 1, rev 2, ...) doesn't qualify either. You need multiple products at the same time.

Second, the products must be related. In our printer example, the printers do similar things, with specializations for various situations. The cars, likewise, provide transportation, but with different images or conveniences. In both situations, the various models are all being manufactured and sold at the same time.

Finally, products in a software product line are developed from common code shared by the members of the software product line. We'd think it a bit foolish if HP wrote all the code from scratch for each model of these very similar printers. In fact, I'd expect that all HP's ink-jet printers share some code, and all of HP's laser printers likewise share some code.

Product lines are a key architectural feature you want in your toolbox. Next month we will discuss different types and implementations of product-lines, and get more explicit about benefits and challenges of explicit product-line design.