In the age of continuous deployment, B2B and B2C customers expect that the software in their product or system is updated frequently throughout its economic life. As a minimum, security updates need to be deployed, but also bug fixes and improvements or even entirely new functionality is expected to be added to products and systems out in the field.
An important implication of this is that the traditional way of building the software for embedded systems is no longer feasible. Traditionally, for each product development initiative a product team is created. The team is responsible for getting commitment on the requirements for the product, designing the product and developing it. Towards the end of the process, the product is tested and validated against the requirements. Finally, the product is released for manufacturing and shipped to the customer. Once this is accomplished, the team disbands and moves on to a new product initiative.
Of course, in most companies, products are not built from scratch, but rather are built on top of a platform. At least for the software in the system, the typical process is that the product team clones the platform code so that it owns its own copy that it can make the changes in that are required to meet the product specific code.
In fact, most companies evolve through a pattern as shown in the figure below. Starting from independent products, companies standardize infrastructure, introduce platforms and then adopt full fledged software product lines. However, most companies stay short of the final stage.
Figure: typical evolution of software-intensive systems companies
The challenge is that product teams up to now disbanded and moved on to the next project when the product or system enters the market. Maybe some maintenance and bug fixing would be required, but for that a separate maintenance organization was in place. When the company employs continuous deployment, the product team can not disband as the software in the product needs to continue to evolve as long as there are products operational in the field. And customers will want to receive new functionality and features that expand the capabilities of the product. Finally, in case the product or system is deployed as a service, the company itself may benefit from deploying new software to improve efficiency.
So, if each product created by the company needs a product team for as long as there are products deployed in the field, the number of product teams needs to grow continuously. For instance, assume a company that introduces 10 new products to market per year and each product has an economic life of 10 years. In the old model, assuming the R&D for a new product would take a year or less, the company could keep 10 product teams around that constantly worked on new products. In the case of continuous deployment, however, over the years, the number of product teams will need to grow to 100. For most organizations, this is an entirely unacceptable situation as the economics of their R&D would never support this many product teams.
It is clear that we need a fundamentally new setup: we need to move to the final stage of the evolution model: the configurable product base. As shown in the figure below, rather than creating product teams for each product, the teams build features, fix defects and refactor one single code base. Each individual product is automatically derived from this single code base.
Figure: configurable product base
The approach presented in the above figure allows the number of products to scale easily as the generation of product specific code as well as the quality assurance of this product specific code are automated. The engineers and architects work on the single code base and their efforts positively affect the entire product portfolio.
Although the approach requires a significant level of discipline and maturity of the organization, the benefits are enormous. In a world where we are moving towards continuous deployment, there really isn’t any alternative to this approach that addresses the evolution of functionality throughout the lifetime of the product except for scaling the R&D organization linearly with the number of products out in the field.
Concluding, we’re reaching the end of product teams, for all the reasons outlined in this article. Instead we’re moving towards portfolio teams that use automation to generate and continuous validate each and every instance of product specific software. Currently, I work with several companies to realize this transition in their organization as there are several aspects to this model that may not initially be obvious. Please do reach out in case you would like to learn more!
