Adopting Product Line Engineering in Your Organization
For any technology that asks an organization to change the way it does business, organizational adoption (the processes and steps needed to introduce and successfully use the technology) becomes an issue.
A prerequisite for successful adoption is clear motivation. Many organizations adopt Product Line Engineering (PLE) because they have encountered the “wall” where their engineering capability is swamped by the engineering complexity of their portfolio. For these organizations, changing the way of doing business is a matter of survival, which is highly motivating. Other organizations move to PLE, and establish a PLE Factory, for competitive advantage or to increase their bottom line. These organizations are surviving, and here the improvement goals should be made explicit and socialized among the technical staff and management, so that everyone understands the purpose of the disruption and can track its progress.
Successful organizational adoption of PLE often involves three stages or tiers, shown in the illustration.
Tier 1 concentrates on incorporating the PLE Factory configurator into the organization, and beginning to use it to define a feature model and a shared asset superset for the product line.
Tier 2 concentrates on re-engineering the products’ assets into a collection of shared assets with variation points. In this tier, new roles specific to PLE are defined and filled, roles that move the engineers away from product-specific responsibilities and towards asset-specific, product-independent roles.
Tier 3 allows the organization’s management to steer the portfolio in strategic directions by defining products with new features or new feature combinations to, for example, enter a new market where the organization’s ability to produce new products quickly and efficiently will give it competitive advantage.
The mastering of tiers need not be sequential; organizations can begin building capabilities in each tier together. Further, adoption can be incremental, and need not happen all at once. Under a principle known as “incremental return on incremental investment,” each step towards complete adoption brings commensurate benefit.
Incremental steps can include:
- Engineering variation points into some, but not all, shared assets right away. For instance, an organization might choose to convert its requirements base into shared asset form, but defer its source code, test cases, and other assets until later.
- Engineering variation points into the assets that support some products, but not all. For example, an organization might choose to embed variation points into its product assets that support the most widely sold products in the portfolio.
- Engineering variation points into the assets to support a subsystem that is widely used across the portfolio.
The increments can be as small or large as the organizational context will permit. Full benefit comes with full adoption, but at each step of an incremental approach the organization will be better off than it was before, and better off than if it chooses to do nothing.