Reuse in Product Line Engineering
The idea of reusing systems and software engineering assets – such as requirements, designs, source code and test cases – has long been the leading candidate for discontinuous improvements in engineering efficiency and quality. The field of Systems and Software Product Line Engineering (PLE) has focused on lucrative opportunities for reuse within a family of similar products or systems.
Reuse in concept is simple, clear and powerful. Reuse in practice, however, has been messy, muddled and anemic. The problem is, the things about reuse that seem obvious don't work, and the things about reuse that work aren't obvious.
This has resulted in many different engineering organizations predictably taking the same ruinous path to failed reuse and PLE initiatives, while consistently overlooking the readily available path to reuse and PLE breakthroughs. Not only has this inhibited the field of systems and software PLE, but it has also unnecessarily stunted the growth and advancement of entire companies and industries.
This contrast in perspectives on reuse – the seemingly obvious things that don't work versus the things that do work that aren't so obvious – can be succinctly stated as: Reuse is an Event, Sharing is a Journey.
Reuse is an Event
Central to the least effective forms of reuse in PLE is the idea that reuse is an event. Unfortunately this is also the intuitive first impression most people have about PLE, and this misperception sticks. The classic example is when an organization creates a library of reusable core assets for a domain. The reuse event occurs during application engineering, when someone finds and reuses a core asset from the library for a new or enhanced product or system.
The reuse event provides 100% reuse on day one, but 0% reuse every day after that. After N different reuse events from a library asset, there are N copies of the asset, plus the one in the core asset library. Enhancements, variations or fixes on any of these N+1 copies results in divergence rather than reuse. To reconcile and consolidate this divergence requires a level of manual effort that is proportional to N2. That is, a change to any of the N+1 copies must be reconciled with the other N copies, or N+1 times N.
Now, the problem with treating reuse as an event becomes apparent.
Sharing is a Journey
Key to the most effective forms of reuse in PLE is the idea that sharing is a journey. Reuse in this case is not an event experienced in isolation, but rather an odyssey embarked upon with others over time.
The sharing approaches to reuse in PLE are generative in nature, where shared PLE assets are automatically compiled, assembled or otherwise configured into systems through some type of abstract feature-based specification. The classic examples in PLE are feature-based product line configurators that select and configure from a supply chain of shared product line assets based on the specification of features and capabilities that are needed or not needed for any particular product or system.
In contrast to reuse events, sharing is long term, and that is what enables success.
Reconsider the previous example of maintaining N different systems that use the same asset, but this time through sharing rather than reuse events that create N different copies. Enhancements, variations and fixes are now done once in the shared, pre-generator form of the asset, so that the N users can all automatically regenerate the new and improved asset, using their previously created feature-based abstract specification.
Without the feature-based abstraction, automation would not be possible. Dramatically better than the N2 cost with copy-based reuse events, the evolution and maintenance of the shared asset is now centrally coordinated for all N users, so there is a linear N cost for the initial use of the asset and a linear N cost for evolution and maintenance. This provides very efficient lifetime amortization through cost sharing across the N products and it allows N to grow very large.