NEWS AT SEI
This article was originally published in News at SEI on: April 1, 2005
Leveraging core assets (software, designs, documentation, test artifacts, budgets and schedules, tools, and more) across a family of systems—instead of building each system separately—enables organizations to dramatically increase quality and reduce cost and time to market. But adopting a product line approach to software involves technical and business challenges. This is the second in a series of columns to answer some of the most frequently asked questions of organizations considering a product line approach.
"My organization is very small. Can we build a software product line?"
Of course. There is no reason a one-person software boutique cannot benefit from product line practices. Small organizations would be best served by lightweight versions of the practices. And some of the organizational and role changes that come with product lines may, in fact, be easier to carry out in a smaller organization. Case studies are emerging in which small start-up companies have understood that in, to field a number of different systems, their severe resource constraints compelled them to exploit all possible commonality among the systems. They used a product line approach to leverage their small staffs and budgets across a successful blend of products. An example of such a case study is documented at Salion, Inc. [Clements 02a].
"My organization is very large. Can we build a software product line?"
Of course, and there are many examples of success. The larger the organization, the more important it is to gain control over the costs and procedures for doing business and to effectively manage products. We have documented case studies of successful software product lines in large organizations also [Brownsword 96].
"How can I make my organization build software product lines when people are busy in their own stovepipes? I don't have enough influence to change the way the organization does business."
Nobody said it would be easy. It is necessary to make the business case for product lines and to find a champion above the level of all the stovepipe organizations. One of the primary missions of the Software Engineering Institute's Product Line Practice initiative is to provide the rationale needed to make the business case to potential champions. Having documented case studies and practices defined within the context of a well-defined framework makes the sales job somewhat easier. Also, there are many adoption strategies open to you. Find a part of the organization where people are open to cross-unit cooperation and begin building a small product line there. Incrementally increase the scope of the product line, and make sure you collect data to record the economies that you gain. The "Launching and Institutionalizing" practice area is especially relevant here.
"The Capability Maturity Model for Software V2 framework puts important aspects of product line practice at Level 4. Do I have to be at Level 4 before I can hope to field a software product line?"
No. But certain Level 2 and 3 practices are key, and successful product line practice does require a certain comfort level with process discipline. For example, an organization must have well-developed configuration-management and product-planning skills before it can successfully field a product line. Organizations that are at Level 4 can transition to product line practices with fewer risks, but the risks can be managed at lower maturity levels as long as they are identified and mitigated.
"What are the various economic motivations for a software product line?"
Many organizations that have started software product lines in recent years have done so out of economic necessity. They have found that they simply cannot continue to do business the old way and still be competitive. Chief among the economic benefits are reduced time to market, opportunities for mass customization, and lower unit costs. These factors are driven by greater productivity from scarce worker resources. Many organizations are finding that they simply cannot find enough qualified people to expand their business without embracing product line practices. In the area of acquisition, the government may commission a product line to eliminate wasteful duplication among programs or to enable it to assemble more cost-effective systems by more easily obtaining products from a range of vendors. See the "Building a Business Case" practice area for more information.
"How long before the approach pays off?"
That's a hard question to answer because it depends on too many organization-specific conditions. If you have decided to build products for which there is no market, then no matter how efficiently you build them, you will not make money. However, a slightly different form of the question can be answered: How many products are required before building them as a product line is more cost-effective than building them as separate systems? Here, emerging data shows that the answer is in the neighborhood of two or three systems. That is, if your product set is expected to be populated by three or more systems, then you're almost certainly better off to build them as a software product line than as separate systems. (See "It Takes Two," [Clements 02b, p. 226].)
"We're doing okay. Why should I change the way I do business and undergo the upheaval that a product line will bring?"
First of all, it's not a foregone conclusion that product line practice brings upheaval. Some adoption strategies prescribe starting small and growing incrementally. New technologies are emerging that are allowing companies to quickly extract and manage commonality among systems they've already fielded; these systems can form the foundation for a product line that can be expanded proactively over time. But no organization should begin to build a product line without understanding the costs and benefits. Realize that circumstances that motivate an organization are often based on long-term vision and not the status quo. You should ask yourself whether your competition is standing still. The choice to adopt product line practices should be a strategy to achieve specific business goals.
"Can you really be competitive in the marketplace with a software product line? Doesn't it take away your flexibility if you're locked into a product line and, say, an architecture?"
Competitiveness should be sharply increased. What is lost is unbounded variability. However, this is offset by a gain in the flexibility to produce quickly any product in the product line scope. You also gain responsiveness to user needs. The key steps are domain analysis and product line scoping. If domain analysis has captured the requirements of the application domain, the product line has been scoped commensurately, and the architecture reflects those needs, then new products can be brought to market far faster than before with minimal loss of flexibility in comparison to one-of-a-kind systems. However, a product line organization must beware of complacency and should always keep an eye on the emergence of new technologies, new user needs, and new opportunities that might compel a shift in the product line's scope to keep it vigorous into the future.
Brownsword, Lisa & Clements, Paul. A Case Study in Successful Product Line Development (CMU/SEI-96-TR-016). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.
Clements, Paul C. & Northrop, Linda M. Salion, Inc.: A Software Product Line Case Study (CMU/SEI-2002-TR-038). Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University, 2002.
Clements, Paul C. & Northrop, L. Software Product Lines: Practices and Patterns. Boston, MA: Addison-Wesley, 2002.
About the Author
Paul Clements is a senior member of the technical staff at the SEI, where he has worked for 10 years leading or co-leading projects in software product line engineering and software architecture design, documentation, and analysis. Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998; second edition, 2003), Evaluating Software Architectures: Methods and Case Studies (2001), and Documenting Software Architectures: View and Beyond (2002). He also co-wrote Software Product Lines: Practices and Patterns (2001), and was co-author and editor of Constructing Superior Software (1999). In addition, Clements has also written dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems. He received a BS in mathematical sciences in 1977 and an MS in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a PhD in computer sciences from the University of Texas at Austin in 1994.
The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.