Tiptoe Carefully or Dive Right In?



Paul C. Clements

This library item is related to the following area(s) of work:

Software Product Lines

This article was originally published in News at SEI on: February 1, 2004

So you’ve decided to launch a product line. You’re ready to define its scope, start working on its requirements definition, craft the architecture, build the core assets, come up with the concept of operations, unveil a new organizational structure, and all the rest. You’ve envisioned how your technical and managerial staff is going to turn out this product line, maintain and improve it daily, and bring home all the productivity and time-to-market gains that made the business case such a delight to read.

But there’s a snag. Presumably the staff is busy doing things now, things that are making your organization a profit or carrying out its mission. Probably they’re building products, products with hard deadlines–“hard” having the double meaning of difficult to meet and difficult to change–and products with a targeted market segment and customer base that you cannot just breezily dismiss in the name of progress.

So if your staff is busy right now, who’s going to build the product line? Put another way, if you re-direct your staff to start building the product line, what’s going to happen to all those products whose delivery has already been promised?

This problem has two solutions. To solve it, all you need to do is pick one of them. The choice is almost like deciding what to do when faced with a swim in cold water: Do you tiptoe carefully, submerging one body part at a time, or do you dive in and get it over with?

The “dive in” solution is to say that giving up or delaying products in progress is the price to be paid for all of the business gains that the product line will afford your organization. During the product line’s “incubation” period while core assets are being built and production plans put in place, the organization conducts no other business, and to the cost of the product line is added the opportunity cost of missing out on the profits, market share, and customer goodwill that other products might have brought in. This solution is fairly Draconian, but there are situations where it makes sense, and we have seen it used to good effect by several organizations both large and small. If your lead time on the planned products is long or their number is few, then you might be able to turn them out as part of your new product line anyway. If you can outsource their production, this might also provide a way out. Or if you have a funding source that will see you through the lean times of product line start up (such as an R&D budget), then this approach might be viable.

The disadvantages of this approach are, of course, the money and market lost on the interim products. But the advantages are considerable. First and foremost, this approach provides the shortest path to the product line paradigm. Everyone in the development organization comes on board at once, is in synch, and shares in the experience of adopting the product line approach. And the time between product line launch and the first delivery of a member of the product line is minimized. The organizational disruption is broad, but happens all at once and is over as quickly as it can be.

The “tiptoe carefully” solution is to stage the adoption of the product line. You can assign a small team to define the product line’s scope, craft the product line architecture, plan the construction (or purchase) of the software core assets, and define product line operations and processes. And then, once the planning and design infrastructure is in place, this small team can be augmented to start building or accumulating the core assets. While this is going on, the bulk of the organization is still busy carrying out the business of releasing products the old-fashioned way.

This approach has several advantages. First and most obvious, it lets the organization continue to release interim products. Second, each core asset that becomes available is validated by the first few products that adopt it, thus providing every asset with a built-in pilot project or two of its very own; this can increase asset quality. Third, the few-products-at-a-time approach lets the organization adopt the new paradigm in a staged manner, reducing the potential disruption from an all-at-once adoption strategy. However, there are dangers. First, small teams may produce small results, and expecting a small team to produce all of a product line’s core assets and operational processes is unrealistic. Second, if the organization has not fully committed to a product line approach, it is tempting to regard the team as a sideshow set apart from the real business of the organization. Product line starvation through neglect is a real possibility. The team needs to grow, be given resources commensurate with its growing responsibilities over time, and be staffed with the highest quality people from the product-building projects–which, of course, will make the product managers shriek in protest. Third, if there is resistance to the product line idea within the organization, this staged effort will prolong the agony of the paradigm shift. It will give the naysayers time to (at worst) entrench themselves in the old ways and find subtly subversive tactics to resist the change. And fourth, there is a danger that the core assets may be designed with only the early products in mind and founder when applied to subsequent products.

And the approach comes with a cost. The cost is delaying the full benefit of the product line approach until the product line has fully blossomed. The cost is the lower productivity and the higher time to market that could have been remedied with a more aggressive approach.

The incremental approach usually works best if the organization has many products in the delivery pipeline with relatively low lead times, and cannot afford to simply shut down production until the first product line member is ready to be released.

So how does the incremental approach work? Members of one organization we know staged their product line adoption as follows:

  • They formed a small steering group to define the product line scope and craft the architecture for the product line. The architecture, not surprisingly, was a layered one. The bottom-most layer provided portability across the variety of hardware platforms that were included in the scope. The next layer up provided a set of services that were common across products; that is, every service in this layer would be used by at least two products in the intended scope.
  • They identified three upcoming products that would become the first pilots to use the product line’s core assets. These products had sequential delivery dates with gaps of six months to a year in between.
  • For component-design work, they staffed the software architecture group with part-time members of those three products’ development teams and members from other product groups in the organization.
  • They began implementing the software in the lowest layer of the architecture, the portability layer, targeting its completion to accommodate the schedule of the first pilot product, which used it.
  • Once this was complete, they began to implement services in the second layer that the second pilot would use. And the second pilot, then, was able to use the whole portability layer, and those parts of the common-services layer that they needed and that were ready in time.
  • Finally, they completed the common-services layer, and the third pilot was able to use all of that.

Figure 4. Phasing in a four-layer architecture

Figure 4 illustrates this approach. This organization staffed and resourced its steering group at near-starvation levels, but its fundamental approach was sound. There was some discomfort among product line “purists” that the products weren’t really members of the product line, because they were not compelled to use the full set of core assets. But in fact, they were members. Each one used a shared set of core assets–just not the same set. But more important than wrangling about definitions is to observe that each product was better off for using the available core assets than it would have been otherwise. Even the first pilot product, which used the fewest of the core assets, gained portability across hardware platforms, something it would not otherwise have enjoyed. And it became a member of the product line family, in that the support of that part of its software was the job of the core assets group, and this product joined a supporting suite of products using that layer. Once the product line is established, each of the pilot products can be reengineered to come into full alignment with the product line and adopt those core assets that were not yet ready. Developers of each product must make a business case for the product either fully joining the product line fold, or continuing its prodigal ways.

Whether you dive in all at once or step in lightly and carefully, deciding how to turn out your first products is one of the first decisions you’ll have to make when launching and institutionalizing a product line. Once you’re in, the water will feel much better.

About the Author

Dr. Paul Clements is a senior member of the technical staff at Carnegie Mellon University's Software Engineering Institute, where he has worked for 8 years leading or co-leading projects in software product line engineering and software architecture documentation and analysis.

Clements is the co-author of three practitioner-oriented books about software architecture: Software Architecture in Practice (1998, second edition due in late 2002), 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 authored dozens of papers in software engineering reflecting his long-standing interest in the design and specification of challenging software systems.

He received a B.S. in mathematical sciences in 1977 and an M.S. in computer science in 1980, both from the University of North Carolina at Chapel Hill. He received a Ph.D. 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.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us



Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.