If the cost, time, and quality benefits of software product line approach are significant, then why is this method for building a product line portfolio not getting the attention it supposedly deserves? Some of the most cited obstacles to product line adoption are investment, development processes, and inadequate knowledge/talent.

Linda Northrop, in her SEI paper, Software Product Line Adoption Roadmap, cites the following as some of the barriers to the adoption of the product line approach – when building product portfolios:

"The development of the product line infrastructure – including new practices, processes, and tool support – also requires investment. Many organizations struggle when it comes to allocating the necessary start-up funds. And unfortunately, cost isn’t the only impediment to product line adoption. Other barriers can also prove challenging and, in some cases, insurmountable”, cites Northrop.

Incompatible development processes, lack of necessary knowledge and possibly talent, cultural resistance, lack of management support, incompatible acquisition practices, lack of disciplined management and development practices, lack of a product line vision, lack of a product line adoption plan, lack of a product line champion, and unrealistic expectations are among the many other roadblocks that organizations face, continues Northrop.

SEI defines a software product line 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."

Additionally, Northrop offers an alternative approach to work around these challenges. This alternative also supports SEI's Product Line Practice Initiative as a substitute to the generic product line approach. The Factory Pattern method, according to Northrop, will help organizations manage risks and promote a higher return on investments when building product lines.

Factory pattern, with an emphasis on the latter word, revolves around the idea of familiarity and commonality. Most development projects and intensive engineering environments establish common contexts, identify common problems and solutions, and work with common software designs and architecture.

The product line roadmap has twenty-nine practice patterns that are needed for the mastery of the software product line approach. However, many organizations have a hard time institutionalizing these practice patterns as a collective whole. On the other hand, the assembly line, phase-based approach is a more attractive alternative. Technology managers and project sponsors, specifically, can appreciate the assembly line-like process - which roughly constitutes of the following:

  1. Choosing what products to build
  2. Building and managing the “assembly line” - as well as the production process - and its corresponding team
  3. Training of the organization or communicating to the organization about the proper use of the assembly line
  4. Designing the product parts that will roll down the assembly line to form a specific product at a later date
  5. Putting the finished parts together to form the product
  6. Monitoring the progress and production process - and addressing the appropriate issues as necessary – in order to keep the organization on course.