3.5.3 Encompassing component

The final model is where the component team aims to incorporate all product needs for the component in the component itself. In addition, the component team may take responsibility for (part of) the integration of the component in the products of their customers.

Advantages. Especially in the case where the component has a complex, e.g. real-time, interface with the rest of the product, this model is the most efficient as the component team has a better understanding of the behavioural characteristics of the component.

Disadvantages. The component team will typically need to be larger than in the earlier models, due to the service that it provides to the product teams. This may easily be viewed as inefficient by the organization.

3.6 Summary

As we discussed in the introduction to this section, organizations adopting or employing software product families need to decide what shared component to develop, how to organize their development and in what order the components should be developed. Due to the implicit manner these decisions typically are taken, organizations often experience problems due to mismatches between the actual and optimal model used.

We have presented five decision dimensions that based on our industrial experiences, we consider to represent the most important decisions that an organization should take. These dimensions are feature selection, architecture harmonisation, R&D organization, funding model and shared component scoping. In the figure below, these dimensions as well as the alternatives on each dimension are presented graphically.