10 learnings about platforms

Having worked with platforms for the better part of three decades, I’ve seen the notion evolve over time. Today, we can distinguish at least three main goals that companies have for them: platforms for reuse, platforms for DevOps and platforms for an ecosystem.

The platform for reuse was the original proposition of software product lines. The idea was that a portfolio of products contains significant common functionality that we should bring together in a platform the product teams can use to build their products faster and more efficiently. The perceived benefits of resource sharing and lower cost are certainly real, but in practice, it turns out that there are lots and lots of ways to negate all the benefits. This especially happens in companies where the leadership doesn’t understand how software platforms are fundamentally different from mechanical or electronics platforms.

The use of platforms for DevOps is a newer phenomenon, driven by the increasing cost of manual configuration and customization of products built on top of a platform when releasing the product software more frequently. We can accept significant manual configuration, customization and testing efforts when we release software once or twice per year, but if we push it out every month or more often, this becomes unacceptable. Platforms for DevOps include the superset of the functionality of the entire product portfolio, with each product basically being a subset created through automated configuration and test. That allows companies to frequently release new versions of the software without the associated release cost.