Platform lesson #1: Platforms should focus on speed, not efficiency
Image by Gerd Altmann from Pixabay

Platform lesson #1: Platforms should focus on speed, not efficiency

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?[email protected] or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).

Markus Brodén

R&D Cloud Software Manager

1 年

Wow, imagine if I've read this some 5-10 years ago, I wonder what kind of fantastic things we could have created. "make the use of the platform optional" and "design ... the ways of working around platforms to maximize speed."

Paul Ng, FIAA CERA

Chief Partnership Distribution Officer

2 年

Thanks for sharing. This matter has occupied my mental space for the last year as I wonder how the relatively slow moving IT infrastructure build can adapt to the quick evolving business or consumer needs (notwithstanding the matter that we actually understand these needs). I suspect in the immediate short to mid term, there will always be these interim fixes as hopefully one day infrastructure build velocity catches up

回复
Niels Nijs

Full stack Agile and Lean Six Sigma Enthusiast | People Enabler | MBA

2 年
回复
Jonas Falk

Director Cybersecurity

2 年

Interesting article and I tend to mostly agree. However I believe the "not mandatory" platform is a bit over simplified. The platform team does not automatically become more customer oriented just because the platform is not mandatory. Furthermore, not choosing the platform, would result in significant maintenance costs for the product teams. Product teams should use the platform, develop the product, release it and then go on to the next product development and enjoy the benefit from the platform being frequently updated and released. If not choosing the platform, the product teams will end up in an expensive maintenance situation for years for each product.

Nesredin M.

System Architect (PhD)

2 年

Could this hypothesis explain the fact that buying premium software services and products tend to speed up things? Eventually more efficient? Although cheaper, the effort spent for opensource and free software is often enormous and sometimes stressful.

回复

要查看或添加评论,请登录

社区洞察

其他会员也浏览了