Outdated distinction: platform vs product

Few words get as much attention and excitement in the software-intensive systems industry as “platform.” One of the reasons is that it has several, quite distinct meanings that often are ignored or forgotten in the process. Everyone supports “the platform initiative” while failing to understand that we mean different things.

In my view, there are three fundamentally different interpretations of “platform.” First, the original use was concerned with capturing the common functionality between products. In this case, the different product teams would use the platform as a basis on which they would build their differentiating functionality. This is a perfectly viable approach that was followed for decades and that led to the concept of software product lines, which are still in use at several companies.

With the advent of DevOps in the software-intensive systems industry, the limitations of the traditional platform approach started to show. Imagine a sizeable portfolio of products, all based on the same platform, adopting DevOps. In this case, every product team has to prepare a new release of their product-specific software every two to four weeks. Although feasible, we’ll often encounter a situation where multiple products need to implement the same functionality. Although we could theoretically ask the platform team to build the common feature, in practice, we see that many product teams have made design decisions that make it difficult to expose the common feature without significant overhead.

Instead, we’re better off adopting an alternative approach to platforms, which I refer to as the superset platform approach. In this case, the platform contains the superset of all functionality offered by all products. Consequently, each product becomes a configuration of the platform. Organizationally, this means that we don’t have product teams anymore, as all development takes place in the context of the superset platform. As a consequence, from the perspective of R&D, the distinction between the platform and a product disappears as there really are no products anymore.

This doesn’t mean that the company stops selling different products. To customers, we may still present a portfolio of distinct products with different capabilities and price points. In fact, we can even increase the portfolio to millions of different products, as every product is simply a configuration of the superset platform. Once we reach this stage, we can even allow for mass customization where each customer or user can select his or her own preferred set of features and functionality.

Of course, in practice, there often are constraints between different features that need to be captured in a feature model. For example, selecting an extensive set of software features with the cheapest, lowest-end hardware will typically not work, so there will be constraints that automatically select the suitable hardware in that case. Similarly, selecting certain options will often invalidate others. However, the combinatorial explosion of features will typically allow for millions of product configurations. In this case, the best way to present the superset platform to the customer and monetize it is a business decision and isn’t constrained by R&D.

Once the company has adopted a superset platform approach and has reached a significant market share, there often are requests from customers and third parties to build functionality on top of the platform. In this case, we move to the third type of platform: the ecosystem platform. Here, the company provides a set of APIs that allows others to build functionality on top of the superset platform.

In my experience, this often starts with customers who want to build specific extensions that serve their purposes. As many of them lack the necessary technical skills internally, they hire contractors or consultants to do the work for them. Once these contractors have developed similar functionality for multiple customers, they sense a business opportunity and start to build standard extensions that customers can buy. Over time, this can grow into a rich ecosystem of extensions on top of the platform.

Of course, the platform and its third parties live in a coopetition context. On the one hand, the extensions make the platform more sticky to customers and, assuming they’re offered through a marketplace and a fee is charged for each sale, they can provide a relevant revenue source for the company. On the other hand, the platform needs to continuously extend itself and include new functionality to avoid being commoditized. This means that the platform cannibalizes the functionality in the extensions and brings it into the platform. This balance needs to be carefully managed by the platform company as it can easily alienate the ecosystem partners.

Platforms exist in at least three types: the shared-functionality platform, the superset platform and the ecosystem platform. It should be obvious by now that the moment we adopt a superset platform approach or an ecosystem platform approach, we don’t have products anymore. At least not from an R&D perspective. Instead, every product that’s offered as such to customers is a configuration of the platform. As every company that adopts DevOps will most likely need to move to a superset platform, the distinction between platform and product is disappearing and is rapidly becoming outdated. To end with a quote from Bernard Kelvin Clive: “Don’t beg for platforms; build your platform.”