Software product families have found broad adoption in the embedded systems industry. During recent years, however, the trends of convergence, end-to-end solutions, shortened innovation and R&D cycles and differentiation through software engineering capabilities have led to a development where organizations are stretching the scope of their product families far beyond the initial design. As an illustrative example, mobile phones have, over the last decade, evolved from basic devices aimed primarily at the voice and SMS use cases to a rich set of mobile devices ranging from mobile multimedia computers to mobile enterprise devices. Contemporary mobile devices support a broad collection of use cases including taking still and video pictures, playing music, watching television, reading email, instant messaging, and so forth. In response to the enormous increase in the features required from mobile devices, the demands on the software present in mobile devices have increased similarly.
One can identify three main trends driving the embedded systems industry, such as convergence, end-to-end functionality, and software engineering capability. The convergence of the consumer electronics, telecom, and IT industries in fact leads, for many companies, to a portfolio of increasingly diverging devices. The second trend is that many innovations require the creation of an end-to-end solution and possibly even the creation or adaptation of a business ecosystem. The consequence for most companies is that where earlier, they were able to drive innovations independently to the market, the current mode requires significant partnering and orchestration for innovations to be successful. The third main trend is that a company’s ability to engineer software is rapidly becoming a key competitive differentiator.
Due to the convergence trend, the number of different embedded products that a manufacturer aims to bring to market is increasing. Consequently, reuse of software is important and the typical approach employed in the embedded systems industry is to employ the notion of a software product family. Software product families have, in many cases, been very successful for the companies that have applied them. Due to their success, however, during recent years one can identify circumstances in which companies are stretching their product families significantly beyond their initial scope. This occurs either because the company desires to ship a broader range of products due to, among other factors, convergence, or because the proven success of the product family causes previously unrelated products to be added to the family. This easily causes a situation where the software product family becomes a victim of its own success. With the increasing scope and diversity of the products to be supported, the original integration-oriented platform approach (described in the next section) often used to create the software product family increasingly results in several serious problems in the technical, process, organizational and, consequently, the business dimension.
This article analyzes the aforementioned problems and presents alternative approaches that are better suited for broad-scoped product families. Failing to adjust the product family approach, including the architectural, process, and organizational dimensions when the business strategy is changing creates several challenging problems that can be viewed as symptoms of this approach. This article discusses the key symptoms, the underlying causes for these symptons as well as solutions for realigning the product family approach with the business strategy. Both the problem analysis and the proposed alternative approaches are based on experiences from a variety of companies that the author has worked with during the last decade. However, for reasons of confidentiality, no specific references can be provided here. The experiences all originate from the embedded systems industry and the results discussed in this article should be considered in that context.
Integration-Oriented Approach: Problem Statement
The integration-oriented approach to a software product family can be defined as: it exhibits a strict separation between the platform organization and the product organizations; component teams develop and evolve a (set of) component(s) and deliver these for integration in the platform; the platform organization delivers the platform as a large, integrated and tested software system with an API that can be used by the product teams to derive their products from; and product teams create products by adding product-specific code on top of the platform.
The problems and their underlying causes that one may observe when the scope of a product family is broadened considerably over time include, among others, the following:
- Decreasing complete commonality: The (relative) number of components shared by all products is decreasing, reducing the relevance of the common platform.
- Increasing partial commonality: The (relative) number of components shared by some or most, but not all, products is increasing.
- Overengineered architecture: Although no product needs support for all business and technical qualities, the architecture of the platform is required to do so and, consequently, needs to be overengineered to satisfy the needs of all products and product categories.
- Cross-cutting features: Especially in embedded systems, new features frequently fail to respect the boundaries of the platform. Depending on the domain in which the organization develops products, the notion of a platform capturing the common functionality between all products may easily turn into an illusion as the scope of the product family increases.
- Maturity of product categories: Different product categories developed by one organization frequently are in different phases of the life cycle, putting conflicting demands on the platform, for example, resource efficiency versus easy extensibility.
- Unresponsiveness of platform: Especially for product categories early in the maturation cycle, the slow release cycle of software platforms is particularly frustrating.
Due to the convergence trend, the number of different embedded products that a manufacturer aims to bring to market is increasing.
Beyond the Integration-Oriented Approach
This article is concerned with analyzing the challenges of broadening the scope of a software product family and discussing alternative approaches to address these challenges. Here, two approaches are discussed: the hierarchical product family and the composition-oriented approach.
Hierarchical Software Product Family. One scenario in the evolution of a software product family is that the product family naturally develops into a limited number of clusters of products. These clusters can subsequently be used as product categories and, assuming the size of each cluster and the amount of revenue generated are sufficient, business units can be made responsible for each product category. In this case, the logical approach is to organize the set of reusable components as well as the architecture of the product family in a hierarchical fashion. Thus, the functionality and features that are shared by all products in all product categories is developed as a platform by a shared R&D team. This platform is used as a basis by each business unit to build a software product family, again consisting of an extended architecture and a set of reusable components. Using the reusable product family artifact, the business unit can rapidly and easily develop new products and evolve new ones. For example, the basic product family artifacts may provide a basic operating system, graphics system, and data management system. The next layer of product family artifacts may add more domain-specific functionality such as multimedia support.
Composition-Oriented Method. The second approach discussed here is the composition-oriented method. As the two approaches discussed earlier are decomposition-oriented, this approach is fundamentally different in the architectural, process, and organization dimensions. The architectural approach is based on architectural principles, design rules, and design constraints, rather than on a structural architecture. This means the components are not arranged in a static structure, but rather are freely composable. Compositionality is achieved through adherence to the architectural principles. The process dimension is not organized around the periodic releasing of a pre-integrated and tested platform, but rather architectural and component evolution is performed based on the requirements of evolving and new products that are part of the product family. Finally, although most product family approaches assume a separate organization responsible for domain engineering, the composition-oriented approach does not require this (nor does it exclude it). For example, when using this approach, a product team would define the architecture for the product, select reusable components that match the architecture, extend reusable components that almost match the architecture and build product-specific components where no reusable components are available.
Comparison. The three approaches discussed in this article are summarized and compared in the table here. Each approach has a specific area of applicability. As discussed earlier for the case of the integration-oriented approach, applying an approach outside its area of applicability typically leads to several problems. Because it is difficult for most organizations to replace an approach to software reuse that has been very successful in the past but has lost its applicability, alternative approaches are presented here so organizations can, in a more explicit and objective manner, select the best approach.
A broadly scoped product family requires a different approach than the traditional integration-oriented approach proliferated in many embedded systems companies.
Related Work
Two approaches that can be considered as alternatives to the integration-oriented approach that traditionally has been used frequently in the embedded systems industry are examined here. These alternative approaches are important because successful product families may broaden their scope considerably due to their success and this requires a conscious adjustment of the overall approach to software reuse. Although discussing these approaches in this context is a contribution of this article, the approaches themselves have been discussed by other authors.
The paper by Toft et al. [3] discusses the approach taken by Hewlett-Packard’s printer division where extensive sharing of software for the firmware of their products was achieved without the creation of a central domain engineering unit. A second author that has been promoting the notion of product populations and the consequences for the way software development is performed is van Ommering [1]. These concepts were further explored in a later publication jointly with the author of this article [2].
Conclusion
Software product families have received broad adoption in the embedded systems industry, as well as in other domains. Due to their success, product families at several companies experience a significant broadening of the scope of the family. A broadly scoped product family requires a different approach than the traditional integration-oriented approach proliferated in many embedded systems companies. If the organization fails to adjust its approach, one can identify several problems that may result from this, including unresponsiveness of the platform, difficulties related to dealing with cross-cutting features and architectural challenges due to the need for overengineering.
To address these concerns, two alternative approaches to software reuse have been presented here: hierarchical product families and the composition-oriented approach. The problems associated with these approaches have been assessed and alternative approaches that are better suited for broad-scoped product families have been described. Studying the identified problems in more detail and evaluating the proposed alternative approaches more carefully is a goal of future work in this area. In addition, potentially further alternatives can be developed, especially approaches that cross organizational boundaries and/or involve the open source software community.
Join the Discussion (0)
Become a Member or Sign In to Post a Comment