Don’t build new platforms

During the last months, I’ve met with several companies that had an interesting common denominator: they were all building a new platform to replace a legacy platform and things weren’t going so well. The legacy platform often is decades old and has functionality in it that’s the result of hundreds of person-years of effort. And it typically forms the basis for a significant part, if not the entire, product portfolio.

When the new platform effort is initiated, the organization accepts that it will take some time (years) to build it to a point that it can replace the legacy platform. As stalling the product portfolio is unacceptable, there will be a continuous flow of development effort into the old platform to realize the features that are needed right now. This, of course, happens in parallel to the new platform effort. The consequence is that the goal for the new platform becomes a moving target as the legacy platform is continuously adding new functionality that the new platform will need to add as well in order to achieve feature parity.

There are three possible outcomes in this scenario. The first is also the worst: the new platform effort forever fails to achieve feature parity. As a consequence, no product line is willing to move over to it. At some point, there’s a change of management, the new platform effort is reviewed and the track record to date leads to an obvious conclusion: the new platform is canceled. The result is that the company is stuck with the old platform and has lost years of time and hundreds of person-years of R&D effort without any business benefit.

Second, the platform effort starts to be used by one product line and becomes the de-facto platform for only a part of the portfolio. For product management, the choice between building functionality for a product that’s here now or a potential product in the future very often falls in favor of the existing product. When this happens continuously, it results in the platform becoming increasingly optimized for the specific product line and getting further and further behind for the other product lines. This could be viewed as a way for one product line to hijack general R&D resources for its own purposes, which makes it very attractive as a strategy in companies with a strong focus on teams delivering in their own area of responsibility without maintaining responsibility for the success of the company overall.

The third situation is where senior R&D and business leaders understand these patterns and force the organization to abandon the legacy platform and adopt the new one. This often leads to significant tension as product lines are asked to put out new products with reduced feature sets. The discussion typically leads to many requests to perform “small” maintenance efforts on the old platform in response to customer requests and other, highly viable, reasons. In general, many in the R&D organization will fight for staying on the old platform as long as possible. In the worst case, the legacy platform will never be sunsetted and the platforms continue to exist next to each other for years or even decades.

The fundamental reason behind these scenarios is a mechanical mindset by leadership. The notion of having generations of platforms may make sense in mechanics and electronics (although these platforms would benefit from continuous evolution as well), but software is different. Our research shows that there’s no correlation between system age and the level of technical debt, meaning that new systems and old ones have similar amounts of requirements for technical debt management.

Rather than thinking in terms of platform generations, the focus should shift to a continuously improving platform with a constant flow of refactoring effort keeping it current from a technology and architectural perspective. Instead of allowing an existing platform to sink in the morass of commodity and irrelevance, organizations should look to continuously invest some percentage (10-25 percent) into the platform to ensure it never has to be replaced by a next generation.

Concluding, building new platforms to replace existing ones is a highly risky R&D initiative fraught with risks and challenges. Instead, commit to continuously investing a part of your R&D resources in refactoring your existing platform. The best platform is one that never has to be replaced because it’s always current and up to date. Because you committed to keeping it that way!