Platform lesson #2: Avoid the platform/product dichotomy

The traditional view on platforms is one where the platform provides generic functionality used by multiple products in a portfolio and family. These products can then simply take the platform as a lego brick and build their product-specific functionality on top of it. Like software from external providers, you simply integrate the platform as a component in your product and you’re good to go.

The reality is rather different. As the platform is company-internal software, it’s much easier for the product and platform teams to build significant interactions and dependencies that are beneficial in the short term but easily increase coordination costs in the long run. Also, external software is typically not concerned with the application domain in which you’re operating whereas the platform is – deeply. That causes deeper interfaces between platforms and products through variation points, extension interfaces, optional components, and so on.

The result can easily be a situation where an overloaded platform team, receiving requests from multiple product teams, deprioritizes functionality until a product team is ready to partner on the development and the interface between product and platform can be established collaboratively. This then delays the introduction of innovative functionality that products desperately need but the platform team doesn’t prioritize.

This is based on a fundamental implication of platforms: you need to decide on the scope of the platform and draw a line between the platform and the rest of the software assets. In many ways, this is an artificial line from a company perspective as you need the functionality anyway and it doesn’t really matter where it lives. It can be in the platform with the advantage that every product has access to it, but it may require more R&D effort as the functionality may need to be constructed more generically. It may be implemented on the product side, which may be faster but with the disadvantage that other products may need the same functionality later.

The boundary between the platforms and the products built on top of them isn’t a static one but is continuously floating, shifting and evolving. It’s also subject to company politics as product teams have a vested interest in having the platform team take on functionality on its backlog as they’ll get it ‘for free.’ This causes the platform team to be wary of requests by their customers, the product teams, as they never know if it’s real generic functionality that this product team just happens to be the first to request (a customer-first feature) or if it’s a ‘customer-unique feature’ that only this product will require. The first is good to incorporate in the platform, even if only one product uses it for now, whereas the latter should stay in the product-specific code. The amount of time that can be spent on these questions can be quite phenomenal.

A second challenge with maintaining the boundaries between products and the platform is the rigidity of resource allocation. The platform and each of the products will have a team associated with them and the resources can’t quickly be moved around. So, if one of the products or the platform has high-priority requirements to meet, the team is on its own and can’t easily get help from the other teams.

The third challenge is that although many R&D teams have worked hard to develop a build and test pipeline for themselves, it often is hard to include the platform in this infrastructure. The consequence is that moving towards DevOps or even just more frequent releases is more difficult as the latest versions of the platform and the product software tend to be integrated late in the process, leaving most of the testing until the integration and release testing stages. As the interface between the product and platform tends to be wide and complex, this typically results in many issues being found late in the process.

To address these challenges, over the last years, I’ve increasingly become convinced that for most companies, the best approach is to create a platform that contains the superset of all functionality in the product portfolio. Each product can then be derived from the platform using automated configuration. This avoids the tension and frustration that many organizations experience, trying to align product and platform teams, deciding where to build functionality and struggling with increasing the frequency of release.

This of course removes the need to separate between product and platform teams as all teams are concerned with adding functionality to the “superset platform.” It also removes the challenges of integrating build and test pipelines as all software is in the one source code control system. And it brings more benefits as the company typically realizes that instead of selling a limited portfolio of products, the configurable platform can be used to create hundreds, thousands or even millions of product variants at virtually no or at least very low cost. This then allows the company to provide mass customization of its product portfolio, resulting in a situation where customers can request close to “engineered-to-order” or bespoke products while the company still has a product and platform-centric cost structure where the R&D costs are amortized of many customers and product instances.

The dichotomy between product and platform that often is present in platform organizations causes all kinds of challenges that can be remediated by removing that dichotomy through the adoption of a superset platform (I’ve also referred to this as a “configurable product base”) where the platform contains the superset of the entire product portfolio. That then allows for the automated derivation of products by selecting a subset of the functionality for inclusion in the product. The build and test toolchain can automatically create and test each product continuously to ensure that the entire portfolio is at production quality at all times. It also allows the company to offer a much broader set of products or a much more configurable product so that each customer can to a large extent get the product he or she wants.

The blog is going on Christmas break and will be back in the middle of January.

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).