Product lines differ from ad hoc reuse in the granularity of components reused and the different products reuse is applied to. To explain, in ad hoc reuse, you can reuse inside the same system, reuse between different versions of the same system, or reuse a library or component. In product lines, this is not the case, reuse is planned and enforced by identifying which parts of the system will remain constant and which will vary, and design the system architecture to support multiple products which share the constant part.
Scoping defines what systems the organization predicts to build within a product line and what systems it can’t. Thus, the scope defines the products that their point of commonality can generate economies of scale (reduce cost). A scope will aid the organization to predict if the system can be built within a product line, and how much a product is specialized in a product line, and how much follows the line’s strategy. It also describes the market segmentation and type of users.
Commonality is the core asset base that doesn’t have to be changed from product to product in the same product line. Variability is the ability of the core asset base to provide mechanism to build the components that vary from one product to another in the same product line, without having to change the core asset base.
The decision to follow a product line approach can affect the organizational structure. The organizational structure is reflected in software development because it defines the stakeholders and assigns responsibilities to employees. This means that managing the system’s architecture and the core assets should be assigned to the right organizational unit. Choosing a particular line approach can involve changing the organization structures so that they can build products from the core assets that meet business goals and strategy.
Software Architecture in Practice, Second Edition, by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003