Software Product Lines

In a mature industry, cost pressures keep increasing and timelines become more challenging. Improving efficiency and reducing time to market becomes a matter of survival for any organization in such an industry.

Applying Software Product Line principles in a product development organization will help the organization achieve increasingly challenging business goals. But beware, the journey is tough and long and it requires some major changes in the organization.

Software Product Lines is not a new concept. It is a popular topic in software engineering academia and several papers exist on the concept of product lines. Software Product Lines were formalized by the CMU SEI [2], and they define a Software Product Lines as,

“A set of software-reliant systems that share a common managed set of features satisfying a particular market or mission area, and are built from a common set of core assets in a prescribed way.”

Several organizations have successfully rolled out product lines and have benefited immensely from the increased efficiencies. The Product Line hall of fame maintained at http://splc.net/hall-of-fame/ gives you a list of some of these. The Linux Kernel and Android are successful product lines.

Learning from several successful product lines, in [1], SEI defines a framework that will help you as a practitioner to identify the key activities and process areas when you want to set up a software product line. The framework defines key three essential activities of Core Asset Development, Product Development and Management, and 29 practice areas to address Software Engineering, Technical Management, and Organizational Management topics.

My goal is not to repeat the content that is already presented in the material from SEI, instead, it is to give you my understanding of the essence of a software product line. This hopefully whets your appetite and gets you interested enough to learn more and figure out how you can apply these principles in your organization.

What is a Software product line trying to achieve? What is the fundamental problem you need to solve? I will attempt to answer these two questions in the remaining part of this article.

What is the software product line trying to achieve?

At the end of the day, it all boils down to money. A software product line attempts to reduce the overall cost of developing a product, by amortizing development cost of features across several products in the product line. This amortization not only results in cost reduction, but also improved quality and shorter timelines and a host of other advantages, but the benefits can be reaped only after successfully setting up the product line, which usually needs additional investment.

I find the most elegant representation of this in [1]. The total cost of developing n1 products in the product line is given by the formula,

Where,

• Corg is the organizational cost.
• Ccab is the cost to develop a core asset base of reusable assets
• Cunique(pi) is the cost to develop a feature unique to a product
• Creuse(pi) is the cost to reuse a feature that already exists in the core asset base for a product. Reuse doesn’t come free so we shouldn’t assume it is zero even though it is much less than if the feature has to be developed from scratch for the product.

Product Line Concept (without org. cost)

Corg is a cost that is inherent in the organization and may be related to aspects such as the size, geographical locations, type of industry, etc. Even though this term may be influenced in some ways by other terms in the equation, for the sake of this discussion we assume that this is an independent cost that we cannot control.

Cost reduction is achieved by increasing the Creuse term and reducing the Cunique term. Of course, being able to reuse a feature relies on the fact that that feature is available in the Core Asset Base. We do not assume that reuse is free as there are costs involved in understanding and configuring a re-usable component. For a ballpark, a 10% reuse cost is a fair assumption.

Developing a feature as a core asset base is more work than if we were to develop the same feature in the context of a product. In the core asset base, more care has to be taken to align with a common architecture. The component that supplies that feature may also need to support additional variability so that it can be configured as applicable to the product needs. A 50% overhead is a fair assumption for this.

Experience has shown that overall benefits start somewhere between 2 and 3 products. Any lower than this number of products, the cost of setting up the Core Asset Base overshadows the benefits of reuse in the products.

What are the core assets? We might be inclined to think of these only as software or source code. However, the percentage of effort spend in actual software development is actually not a large percentage of total effort. There are several other areas where reuse can be exploited. In a product line, any potential reusable asset is called a Core Asset. The broader the core-asset base the more the organization benefits from the reuse of those core assets. Core assets can be,

1. Requirements
2. Architecture documents and models
3. Software
4. Test assets
5. People. Yes, people are probably the most important core assets that you want to reuse in multiple products.

Anti-Software Product Line patterns

If you say that you are running a software product line and find yourself doing any one of the following for any core-asset, then you need to reconsider your understanding of a product line.

1. Only focusing on building reusable components. If your strategy is to build a library of software libraries or components and then publish it for other parts of the organization to use, you are not fielding a product line. This results in opportunistic reuse. In a product line, reuse needs to be planned and enforced. You enforce it by specifying the architecture within which these components will be reused and enforce that all products use the same architecture.
2. Clone-and-own. If your reuse strategy relies on building one product first and then using that as the starting point on which the next product is built and so on, this is not a product line. This is just a variation of the first point where reuse is opportunistic. In a product line, the core assets and the products are treated as a whole. If you use the clone-and-own mechanism for any core asset, you will not be able to benefit from product lining.
3. Releases and version of single products is not a product line. A product line must support multiple versions of multiple products simultaneously.
4. A set of technical standards is not a product line. Technical standards are just input constraints to the product line.

Implementation challenges

The framework described in [2] defines 29 practice areas that different aspects of the product development organization. The practice areas point you towards what you should consider but don’t really say how. To be fair, it is not really the scope for it to specify “how”, as the implementations may differ vastly across industries and organizations.

I list here some of the recurrent challenges we faced once the potential core assets were identified. These are,

1. The core assets need to reside in a single line of “development”. Depending on the type of Core Asset, you will need sophisticated variability mechanisms to maintain a single line of development.
2. Since the core assets need to reside in a single stream, you need to develop configuration mechanisms so that you configure the core-assets for different products.
3. Branching is not a variability mechanism. In fact, branching is clone-and-own. If you plan to make a long living branch for any of your core assets it means that you haven’t solved the variability problem. Branches are to be used in configuration management as a mechanism to freeze before major releases or the final releases. Development on a branch should be with an intention of pushing the changes back to the mainline as soon as possible.

Well established variability mechanisms exist to manage variability in source code. You will face bigger challenges in managing variability for your other core assets like requirements, architecture models and test assets.

Ask not what the platform can do for the product; ask what the platform should do for the product.

Organizations that follow a platform approach usually create a separate organization to develop platform assets. This is a great approach, but be aware of some of the problems you may face while doing this.

If product line principles are not considered when setting up a platform, the platform boundary is defined as “all that is common”. Unfortunately, the definition of “all that is common” is always changing.

As new products get added to the product line, many new features may require modification to the core assets. If the platform boundary is too rigid, these changes will be made in the scope of the product and this results in clone-and-own and reduced reuse. What situation can cause the platform boundaries to be rigid?

One major reason is that the platform doesn’t support variability. Variability not only in terms of building the right design with the right variations and extension points but also variability in terms of being able to allocate budgets from the product bucket to the platform bucket. Doing this right requires a change in processes and culture within the product line.

The key is to be able to identify the variations and to be able to push them down so that the variability is addressed at the right layer, architecturally and organizationally. The platform should embrace variability that is imposed on it. This is harder than it seems if the variability in platform is constrained by organization structure, processes and culture.

Summary

I covered here some of the key ideas I feel are important to grasp when transforming into a product line organization. All the 29 practice areas are important and in all of these you will find some variation of the core ideas presented here.

References

1. Bockle, G & Clements, P & Mcgregor, John & Muthig, Dirk & Schmid, Klaus. (2004). Calculating ROI for Software Product Lines. Software, IEEE. 21. 23–31. 10.1109/MS.2004.1293069.
2. Clements, P. C., Northrop, L. (2001). Software Product Lines: Practices and Patterns. Addison-Wesley.