Avoiding Pitfalls In Incremental Product Line Adoption

The advertised benefits of product lines (PLs) in cost reduction, time to market and quality are hard to ignore; however, the push for PLs comes after you already have multiple disjointed software products. At that point, you know you need an organized software platform, but reworking your existing product can be daunting and difficult to fund.

Fortunately, you can adopt an incremental approach to PLs that allows progress even though your business constraints do not allow you to stop ongoing product development efforts. This approach also affords you greater flexibility while your organization learns a new way of working.

Be aware that significant pitfalls can plague your incremental PL adoption. The incremental approach is not a free license to make shortcuts; many of the basic steps for PL adoption activities are still critical.

To get the most value from product lines, your development activities need to be mature in multiple dimensions. We recommend regular measurement of your product line maturity using the Family Evaluation Framework, (FEF), described by van der Linden et al [1] which identifies five maturity levels for each of four dimensions of product lines: Business, Architecture, Process and Organization.

Furthermore, PL engineering best practice calls for a two-lifecycle development model. The first lifecycle relates to domain engineering, which focuses on your long-term strategic needs, and creates and maintains core reusable assets. The second lifecycle, application engineering, uses the core assets and supplements them with the effort needed to build your finished products.

Business Pitfalls

To ensure PL success, you still must start with a shared understanding of the PL scope, success criteria, and the likely value to the business. Consider the following guidance on PL architecture maturity: 

• Communicate the vision.
• A Concept of Operations document and a PL Charter are recommended.
• Define the Funding model.
• Identify how you intend to support the strategic investment required.
• Provide visible executive sponsorship.
• PLs require significant change. You should not expect success without consistent executive sponsorship.
• Stay connected with the market.
• All markets change. You must reflect the changing business drivers into your PL architecture.
• Don’t attempt a PL for a totally new market segment, because the course corrections will probably be too wild to allow the PL to yield enough value.
• Manage cultural change.
• Understand that shifting from a product-centric business model is a significant cultural change for your employees.
• Model and track the business value.
• Develop a data-driven business model that predicts and tracks how you perform against your expectations.
• Use the Family Evaluation Framework to measure your PL maturity in the Business, Architecture, Process and Organization areas and chart your progress to your goal level.

Architecture Pitfalls

The PL architecture is fundamental to the internal coherence of the PL and, hence, to its business success. Getting the architecture right is crucial. Attempting to get the architecture fully defined up-front is intrinsically hard, since it appears to require an omniscient perspective on all possible needs for variability across the PL scope - both now and in the future. Consider the following guidance on PL architecture maturity:

• Assess the architecture distance between your existing system and the required PL architecture goal.
• Migrating to a PL is only cost effective if the delta from the current architecture is not larger than the cost of a re-write.
• Don’t try to span too large a scope of applicability too quickly.
• With a larger scope come more complex and burdensome variability mechanisms.
• Keep consistent management and funding support over time.
• Be aware that the required migration work in refactoring does not always show visible progress to management.
• Maintain alignment between your business needs and the PL architecture’s quality attributes.
• Define your approach to variability, as well as defining the specific variability mechanisms used by your PL.
• Drive for loosely coupled components.
• Build in support for loosely coupled components as an early step of the migration.
• Use design patterns involving brokers, service lookup, dependency injection and inversion of control to achieve optimum decoupling.

Process Pitfalls

Because products produced from a PL have an element of co-dependency, maintaining common development processes is crucial.  

• Realize that sophisticated change and configuration management is mandatory and central to PL management.
• Unmanaged and unrecorded change is a recipe for disaster within a PL.
• Recognize that the lifecycle speed of domain engineering is necessarily slower than application engineering.
• In particular, you must ensure careful review of domain engineering development activities, since the consequences are likely to be widespread and long-lived.
• You must pay particular attention in coordinating the plans for application product development with the domain PL development so that products still come to market on time.
• Look for the low-hanging fruit (elements that have very low variability) for inclusion as early core assets. 
• Use some technically non-controversial assets with simple variation mechanisms to pilot the planning and integration processes between domain and application-specific components.
• Plan for early and efficient verification of PL core assets.
• Don’t leave PL asset verification until first use in an application.
• Planning for how the variation is to be tested should begin up front and in parallel with the development of the PL architecture.
• Verification is arguably the single largest area from which the return on the investment in a PL can be realized.

Organization Pitfalls

The success of a PL initiative is fundamentally affected by the way the people involved collaborate. When migrating to a product line approach, an organization is usually undertaking a significant cultural change. Keep in mind the following guidance on PL organizational maturity: 

• Don’t think that you have to start by forming a new (and separate) management organization.
• Consider starting out by first forming a flexible team structure that may evolve into an organization.
• Forming a team is typically much faster than forming an organization and uses only existing management responsibilities.
• Shift the whole organization to a PL approach as a coordinated whole.
• Forming an organization early on tends to create an artificial us-versus-them divide between the domain engineering and the application engineering projects.
• Separating the domain engineering function from the realities of instantiating products can result in an Ivory Tower syndrome.  Even if the domain engineers do good work, if it is not actually used in product then it is effort wasted 
• Avoid asking individuals to straddle between domain engineering and application engineering.
• The personnel needed for product lines are often those with the deepest knowledge and expertise. You can have difficulty attempting to share key people between the long term strategic view and the pressing and urgent tasks associated with existing product commitments.
• Align measures and incentives with the distinction between domain and application engineering functions.
• For example, measuring SLOC per man month may be appropriate in application engineering, but in domain engineering it might be better to measure the number of successful integrations of a core asset.
• Specify who is to be the lead PL architect as early as you can.
• In addition to being knowledgeable and experienced, it is important to provide early both technical and personal leadership to support the cultural changes involved. 
• Strongly encourage the PL efforts to work through integration issues with the application engineers.
• Allow time for developing testing frameworks, test tools, stubs, and simulators that will ease the integration effort.
• Align the PL with evolving customer needs.
• As customer constraints and needs shift, so must the PL architecture. Plan for change.

Conclusion

For organizations migrating to PL engineering, an incremental adoption strategy has distinct advantages over a big-bang approach. Experience has shown, however, that incremental PL adoption also has common pitfalls. The following guidance will help you navigate around the most common associated pitfalls. 

1. Ignore non-technical issues associated with product lines at your peril, since they are at least as critical as technical considerations, especially in the initial stages of building a successful PL approach.
2. Leverage the large body of PL best practices for software PL engineering, but pay particular attention to early verification strategy development.
3. Plan only to move step by step through each level of maturity described in the FEF BAPO model and assess your organizations maturity level at regular intervals.
4. Keep your approaches simple to achieve early successes with simplified approaches. Be prepared to learn and adapt as you roll out the PL initiative into your organization.

For more information visit www.foliage.com

References

[1] Van der Linden, F., Schmid, K. and Rommes, E. (2007). Software Product Lines in Action: The Best Industrial Practice in Product Line Engineering. Springer.