Advantages. The main advantage over the first two alternatives is that no product-specific versions of the component are developed, so none have to be replaced. This reduces the development as well as the maintenance effort required for the new features.

Disadvantages. The concern one may have is that the product family R&D staff has to predict future requirements that the products themselves, being close to their markets, have not yet started to implement. There is, consequently, a high degree of uncertainty. This may cause certain investments to be invalidated, due to changing requirements.

3.2 Architecture harmonisation

The second dimension that we discuss is the level of software architecture harmonisation between the products that the organization strives for.

3.2.1 Component-centric

The first model that the organization may decide to use is to forego all architecture harmonisation and to only develop shared components. As the integration of these components in the products will be more effort consuming, the organization needs to find a balance between the responsibilities of the component team versus the product teams with respect to facilitating and achieving component integration.

Advantages. The obvious advantage is that no effort has to be invested in architecture harmonisation. Secondly, the product teams maintain their relative freedom and are not required to achieve consensus over architectural issues.

Disadvantages. The component integration cost per product is often relatively high, reducing the benefits of a software product family approach. This may lead to organizational tension between the component team and the product teams. The product teams may demand from the component team to better prepare their component for integration in the products. The component team is concerned with the effort associated with preparing the component for inclusion in each product and generally not inclined to give in to the demands of the product unit.