{"id":1210,"date":"2021-03-02T10:00:56","date_gmt":"2021-03-02T10:00:56","guid":{"rendered":"http:\/\/janbosch.com\/blog\/?p=1210"},"modified":"2021-03-02T10:00:57","modified_gmt":"2021-03-02T10:00:57","slug":"what-it-means-to-have-a-platform","status":"publish","type":"post","link":"https:\/\/janbosch.com\/blog\/index.php\/2021\/03\/02\/what-it-means-to-have-a-platform\/","title":{"rendered":"What it means to have a platform"},"content":{"rendered":"\n
\"\"
Image by Ioannis Ioannidis from Pixabay<\/figcaption><\/figure>\n\n\n\n

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\u2019ll discuss three types: platforms for reuse, for DevOps and for ecosystems.<\/p>\n\n\n\n

Initially, the primary role of platforms was to share commodity \nfunctionality between different products in a product line or portfolio,\n ie a platform for reuse. The train of thought was that if we could \navoid each product team building the same functionality over and over \nagain, it would allow for higher R&D efficiency as the product teams\n could work on the product-specific, differentiating functionality \nwhereas the platform team would serve all product teams.<\/p>\n\n\n\n

Having done work on software product lines for the better part of 25 \nyears, it\u2019s clear to me that this simple argumentation can work, but \nthat there are many ways to mess up the benefits platforms can provide. \nEspecially the coordination cost between platform and product teams and \nthe difference in priorities between them can cause so many \ninefficiencies that the benefits of reusing functionality can easily be \nnullified.<\/p>\n\n\n\n

My main lesson about platforms for reuse is that the focus shouldn\u2019t \nbe on (perceived) efficiency but on speed. Product teams should focus on\n maximizing speed and where a platform can help to move faster, then, by\n all means, use a platform, but where the platform slows product teams \ndown, it should be dropped like a hot potato. Making the use of the \nplatform optional for product teams drives the right priorities for the \nplatform team as well. advertorial \n<\/p>\n\n\n\n

During the last years, the meaning and use of platforms shifted \nbecause of the increasing adoption of continuous deployment of software \nto products in the field. When product software was released maybe once \nor twice a year, it was entirely feasible to spend a significant amount \nof manual effort on customizing the latest version of the platform \nsoftware for a specific product and integrating it with the latest \nversion of the product-specific software. When the release frequency \ngoes up, however, the amount of manual effort required becomes \nunfeasible. This leads to platforms for DevOps. Here, the platform is \nthe superset of the functionality in all products and the software for \neach product is automatically derived through configuration of the \nplatform software.<\/p>\n\n\n\n

When it comes to platforms for DevOps, the main challenge I\u2019ve seen \ncompanies struggle with is the transition from customization to \nconfiguration of software. Especially in the automotive industry, OEMs \ntend to demand all kinds of customizations that, truth be told, often \nadd little business value. If it really isn\u2019t possible to avoid \ncustomization in all contexts, the ambition should be to define an \ninterface between the platform and the customization software that \nstrictly separates them. This allows for the independent evolution of \nthe platform software in products deployed in the field.<\/p>\n\n\n\n

The third type, which many aspire to have but few have realized, is \nan ecosystem platform that customers, partners and third parties can \nextend through a set of APIs. For their own purposes, to serve verticals\n not served by the platform provider or to provide solutions not covered\n in the platform for a broad audience. Every company I interact with \naspires to provide the iPhone of their industry, but operationalizing \nthis ambition is a hard, up-hill battle in most cases.<\/p>\n\n\n\n

The typical tension in companies aspiring to provide an ecosystem \nplatform is between that nascent platform and the existing product \nbusiness. A software ecosystem needs scale, meaning that the same \u2018apps\u2019\n are deployable in as broad an installed base as possible. This requires\n that each product in the portfolio provides the standard ecosystem \nAPIs, which limits the autonomy of product teams. In addition, the \nprevalent product mindset focuses on including as much useful \nfunctionality in the product as possible whereas a platform mindset \nrequires us to yield certain domains of functionality to the ecosystem \nto make sure that partners and third parties have a sufficiently \nappealing business case.<\/p>\n\n\n\n

Platforms are great but discussions easily get confusing when different platform definitions are used without the participants being aware. I\u2019ve 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.<\/p>\n\n\n\n

To get more insights earlier, sign up for my newsletter at <\/em>jan@janbosch.com<\/em><\/a> or follow me on<\/em> janbosch.com\/blog<\/em><\/a>, LinkedIn (<\/em>linkedin.com\/in\/janbosch<\/em><\/a>), Medium<\/a> or Twitter (<\/em>@JanBosch<\/em><\/a>).<\/em><\/p>\n","protected":false},"excerpt":{"rendered":"

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 … Read more<\/a><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"generate_page_header":"","footnotes":""},"categories":[8,10],"tags":[],"_links":{"self":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1210"}],"collection":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/comments?post=1210"}],"version-history":[{"count":1,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1210\/revisions"}],"predecessor-version":[{"id":1212,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/posts\/1210\/revisions\/1212"}],"wp:attachment":[{"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/media?parent=1210"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/categories?post=1210"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/janbosch.com\/blog\/index.php\/wp-json\/wp\/v2\/tags?post=1210"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}