Traditional thinking is that platforms are about efficiency through reuse. Product teams get a bunch of functionality for free from the platform and only have to build the remaining product-specific functionality. The interesting thing about software reuse is that it’s been extremely successful at the inter-company level. The amount of software that’s being reused through operating systems, commercial software products, the open-source community and software ecosystems is phenomenal. Compared to the situation in the 1990s, when I came of age in the software community, it’s incredible what we’ve accomplished.
For many companies, however, the sharing and reuse of software developed in the context of the company itself, ie intra-organizational, still proves to be a challenging and uphill battle. The conceptual idea is to develop a platform that all product teams can use to build their respective products. The reasoning is that by focusing on building common functionality only once, we can save development effort by sharing this common functionality through a platform.
In practice, unfortunately, the interface between products and the underlying platform tends to be incredibly complex and tends to result in a situation where the platform slows everyone down. There are several reasons for this, but the main one is that software is different from mechanics. Although the functionality in the platform might be common, very often product teams find out that they need a different flavor or that some part is missing. The product teams need to request this functionality to be developed by the platform team, which often gets overwhelmed by all the requests. The consequence is that everyone waits for the slow-moving platform team.
This is a specific instance of a generic pattern I see time and again: when companies focus on efficiency, the consequence tends to be that everything slows down. Whether it’s approval processes, bottlenecks, reviews or coordination problems, the behavior in service of efficiency tends to put hurdles and delays in the ways of working, causing delays everywhere.
To address this, we should design platforms and the ways of working around platforms to maximize speed. Speed to get new functionality out to customers. Speed to extend the platform with the functionality required by products. Every activity and use case should be designed for speed. To achieve this, there are at least three strategies I’ve seen companies use in practice.
First, make the use of the platform optional. In many traditional platform setups, product teams are forced to use the platform and this tends to make the platform team prioritize its own efficiency over the efficiency of the product teams. By making the platform optional to use by product teams, the priorities of the platform team tend to change in favor of serving the product teams.
Second, allow product teams to change the platform code. In traditional software development, only the team responsible for a software asset can make changes in it. However, with the increasing adoption of continuous integration and test, it’s much less risky to let others touch the code as their mistakes are captured immediately. As platform teams tend to be overloaded with change requests, allowing the product teams to make the changes in the platform code that they urgently need can remove the bottleneck in development.
Third, it’s possible to do away with the product/platform dichotomy altogether by creating a configurable product base where the superset of all functionality is in one code base and each product simply becomes a configuration of that superset. This will be the topic of the next lesson.
When companies focus on speed, interestingly, efficiency is a side effect. To gain speed, teams tend to look for ways to automate and in other ways reduce the amount of time needed to accomplish various outcomes. The consequence is a significant increase in efficiency. The takeaway is that focusing on efficiency slows you down and focusing on speed makes you more efficient! So, focus on speed and get everything else as part of the deal.
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).
I would be very interested to hear about organisations where the product teams were actively changing platform code, and how those organisations manage that process in order to minimize the technical debt incurred.
Are there any examples of this?
Hein, if you email me I can get back to you with examples.
We allow for product teams to change the platform code, but this has resulted in bloated platform and fuzzy boundaries & ownership. Would be interesting to know how other companies have solved it.
Best website to read manga online is https://readmanga.re
This design is wicked! You certainly know how to keep a reader amused. Between your wit and your videos, I was almost moved to start my own blog (well, almost…HaHa!) Wonderful job. I really enjoyed what you had to say, and more than that, how you presented it. Too cool!
Hello, i feel that i noticed you visited my blog so i came to “return the desire”.I’m attempting to to find issues to improve my website!I suppose its ok to use some of your ideas!!