Sometime last year, I had a discussion with senior leaders of an automotive tier-1 supplier. I explained to them that if we’re serious about moving towards DevOps in automotive, their customer-project-centric approach would have to change. A typical car model is developed for three to four years, then manufactured for around seven years and the OEM is obliged to provide software support for it at least eight years after the last car runs of the production line. Assuming the tier-1 supplier supports 10 OEMs and each OEM has 10 car models in production, the traditional way of working would mean the company would need 100 teams to continuously evolve and validate the software for all car models in the field for more than 15 years per model.
This situation is the case for every company with a portfolio consisting of a range of software-intensive products. Even if you could organize the work such that each product team pushes out software updates every two to four weeks, the cost of this approach would be so prohibitively high that no business model can support this.
The solution to this conundrum is, in my view, the superset platform. This is built on a single codebase that contains the superset of all functionality in the product portfolio. The software for each product is simply a configuration of the code in the single codebase, rather than its own codebase. In addition, the platform is complemented with a continuous integration and test infrastructure that ensures that each product in the portfolio is always at production quality.
The advantages of the superset platform approach aren’t limited to better support for a DevOps setup. One major benefit is that it allows for much better governance of resources across the portfolio. In the situation where each product has its own associated R&D team, each team will focus on delivering the most value for its product. However, from a portfolio perspective, this easily results in a situation where one team lacks the bandwidth to do important work for its product while teams associated with other products are busy with less important work. Pooling all the resources in one organization supporting the superset platform allows for the allocation of resources in line with the company’s top-level priorities. A second benefit is that features developed for one product can easily be provided in other products in the portfolio as well.
As with everything in life, the superset platform also comes with a few challenges. The primary challenge for most companies is to develop proper mechanisms for managing the variability in the platform to allow for the proper configuration of products. However, there are well-defined solutions and tools available for addressing this. Second, the overall platform will be larger and more complex than the codebase for each individual product, meaning that you’ll need to ensure stronger architectural oversight. In my experience, however, the advantages of the superset-platform approach, especially in a DevOps context, significantly outweigh the disadvantages.
Adopting continuous value delivery as part of the digital transformation requires us to adopt DevOps as the vehicle for delivering software-based value. When adopting DevOps, a traditional product-centric approach rapidly becomes infeasible. Instead, we need to adopt a superset-platform approach where all products are automatically derived from a single, common codebase and automatically tested to allow for low-effort continuous deployment. It’s yet another perfect example of one of the key tenets of Agile: if it hurts, do it often!
Like what you read? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
