Architecture harmonisation: component-centric

R&D organizations are typically hesitant to invest in changes that have no obvious, short-term return on investment. Although harmonisation of the product architectures is of importance in the long term, due to the reduced integration effort, it is also an effort-consuming activity with no immediate pay-back. Consequently, at this stage in the adoption process, effort should be directed towards creating product family components.

Organization: mixed responsibility for product teams

It is difficult to present a general preference for this dimension as it is preferable to have a component team developing the first product family components. However, obtaining the management support for creating a component team is typically difficult, due to the scarceness of R&D resources. The main risk of the recommended alternative is, obviously, the prioritization by the product teams. The aim should be to assign the responsibility for component development to product teams that have an immediate need for incorporation of the product family components in their product.

Funding: “barter”

Similar to the decisions dimensions already discussed, the main challenge is to achieve the early successes with minimal changes. In the case where different product teams decide to share responsibility for the development of shared components, it is preferable to initially achieve agreement based on estimations that can be made part of the normal product development budgets. If substantial organizational support is available, a taxation model can be considered.

Shared component scoping: only common features

Assuming product teams have shared responsibility for components and products, the least intrusive approach is to have product teams implement the features needed by their own product, leaving extension points for likely future extensions. The next product team that requires use of the product can extend the first version of the shared component with its requirements. The main challenge in this model is one of discipline, i.e. each product team is responsible for maintaining the general applicability of the shared component.