Recently, I participated in a discussion set in the automotive realm. At some point, the conversation turned to platforms. After a while, I realized that there were several definitions of platform getting mixed up. Having worked with platforms since the 1990s, it has been really interesting for me to see how the very notion of platforms has evolved. Here, I’ll discuss three types: platforms for reuse, for DevOps and for ecosystems.
Initially, the primary role of platforms was to share commodity functionality between different products in a product line or portfolio, ie a platform for reuse. The train of thought was that if we could avoid each product team building the same functionality over and over again, it would allow for higher R&D efficiency as the product teams could work on the product-specific, differentiating functionality whereas the platform team would serve all product teams.
Having done work on software product lines for the better part of 25 years, it’s clear to me that this simple argumentation can work, but that there are many ways to mess up the benefits platforms can provide. Especially the coordination cost between platform and product teams and the difference in priorities between them can cause so many inefficiencies that the benefits of reusing functionality can easily be nullified.
My main lesson about platforms for reuse is that the focus shouldn’t be on (perceived) efficiency but on speed. Product teams should focus on maximizing speed and where a platform can help to move faster, then, by all means, use a platform, but where the platform slows product teams down, it should be dropped like a hot potato. Making the use of the platform optional for product teams drives the right priorities for the platform team as well. advertorial
During the last years, the meaning and use of platforms shifted because of the increasing adoption of continuous deployment of software to products in the field. When product software was released maybe once or twice a year, it was entirely feasible to spend a significant amount of manual effort on customizing the latest version of the platform software for a specific product and integrating it with the latest version of the product-specific software. When the release frequency goes up, however, the amount of manual effort required becomes unfeasible. This leads to platforms for DevOps. Here, the platform is the superset of the functionality in all products and the software for each product is automatically derived through configuration of the platform software.
When it comes to platforms for DevOps, the main challenge I’ve seen companies struggle with is the transition from customization to configuration of software. Especially in the automotive industry, OEMs tend to demand all kinds of customizations that, truth be told, often add little business value. If it really isn’t possible to avoid customization in all contexts, the ambition should be to define an interface between the platform and the customization software that strictly separates them. This allows for the independent evolution of the platform software in products deployed in the field.
The third type, which many aspire to have but few have realized, is an ecosystem platform that customers, partners and third parties can extend through a set of APIs. For their own purposes, to serve verticals not served by the platform provider or to provide solutions not covered in the platform for a broad audience. Every company I interact with aspires to provide the iPhone of their industry, but operationalizing this ambition is a hard, up-hill battle in most cases.
The typical tension in companies aspiring to provide an ecosystem platform is between that nascent platform and the existing product business. A software ecosystem needs scale, meaning that the same ‘apps’ are deployable in as broad an installed base as possible. This requires that each product in the portfolio provides the standard ecosystem APIs, which limits the autonomy of product teams. In addition, the prevalent product mindset focuses on including as much useful functionality in the product as possible whereas a platform mindset requires us to yield certain domains of functionality to the ecosystem to make sure that partners and third parties have a sufficiently appealing business case.
Platforms are great but discussions easily get confusing when different platform definitions are used without the participants being aware. I’ve tried to provide some structure here. For most companies adopting DevOps, the product-centric way of working is no longer feasible and a platform-centric approach is required instead. This has great advantages but calls for a careful strategy and way of operating as there are several pitfalls in the road ahead.
To get more insights earlier, 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).
