10 Learnings About Platforms
Having worked with platforms for the better part of three decades, I have seen the notion of platforms evolve over time and today we can distinguish at least three main goals that companies have for platforms, i.e. platforms for reuse, platforms for DevOps and platforms for an ecosystem.
The platform for reuse was the original proposition of software product lines. The idea was that a portfolio of products contains significant common functionality and we should bring all the common functionality together in a platform that the product teams can use to build their products faster and more efficiently. The perceived benefits of sharing resources and lower cost are certainly real, but in practice it turns out that there are lots and lots of ways to negate all the benefits of platforms. This especially happens in companies where the leadership does not understand how software platforms are fundamentally different from mechanical or electronics platforms.
The use of platforms for DevOps is a newer phenomenon driven by the increasing cost of manual configuration and customization of products built on top of a platform when releasing the product software more frequently. We can accept significant manual configuration, customization and testing effort when we release software once or twice per year, but if we push it out every month or more often, this becomes unacceptable. Platforms for DevOps include the superset of functionality of the entire product portfolio and each product is basically a subset created through automated configuration and test. That allows companies to frequently release new versions of the software without the associated release cost.
Third, the holy grail of platforms is to provide a software platform to a two- or multi-sided market where 3rd parties develop solutions on top of the platform and customers of the platform enjoy a rich ecosystem of solutions that increases value and stickiness significantly, making it virtually impossible to dislodge the platform provider from the comfortable perch. The challenge is that achieving this position is incredibly hard, even if the destination is very attractive.
Unfortunately, in my experience, most companies have a rather confused and contradictory strategy around platforms that is a mix of all three aforementioned types of platforms. In this post, I intend to share some of my learnings after working with platforms for many moons that I hope provides some benefit and informs the discussion. So, here goes …
- Platforms should focus on speed, not efficiency: Traditional thinking is that platforms are about efficiency. Product teams get a bunch of functionality for free from the platform and only have to build the remaining product specific functionality. In practice, 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. 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 functionality required by products. Every activity and use case should be designed for speed. When doing so, interestingly, efficiency will follow.
- Avoid the platform/product dichotomy: Over the last years, I have 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 avoid the tension and frustration that many organizations experienced, trying to align product and platform teams, deciding where to build functionality and struggling with increasing the frequency of release.
- Balance architecture and continuous integration/test: A clean architecture with strong interfaces and decoupled functionality is great in that it simplifies testing because you can push most testing to the component and subsystem level and minimize system level testing. In practice, however, the architecture is always suffering from architectural technical debt and no matter what decomposition you choose, there will always be functionality and quality requirements that have cross cutting consequences. Consequently, we need to balance architecture work and investment in continuous integration and test. The architecture helps engineers avoid mistakes in the first place and continuous integration and test catches introduced errors early so that the cost for fixing these is minimal.
- Don’t integrate new functionality too quickly: Every product and platform requires innovation to stay relevant. Unfortunately, the nature of innovation is that many, if not the majority, of innovations fail to deliver the expected outcomes and should not be introduced into the platform or product. The good news is that the few innovations that are successful more than pay for all the failed ones. As most innovations fail, we should be careful to incorporate new functionality directly into the platform or product. Instead, it is better to first experiment and confirm with customers that the functionality adds value by “bolting on” the innovative functionality and keeping it at the other side of an API. If the innovation proves successful and a hit with customers, we can then plan the deep integration in the product or platform. If it isn’t successful, we can easily ditch the functionality as it never got integrated in the first place. This avoids bloated products and platforms that contain tons of non-value adding functionality.
- Distinguish customer-unique and customer-first functionality: There will always be functionality requested by customers. Some of this functionality will be useful for more customers and the customer initially requesting it was simply the first to ask for it. Other functionality is so specific to the unique context of the requesting customer that it will never be used by others. Although it is fine to incorporate customer-first functionality into the platform and then generalize it to other customers over time, we should be very careful to include customer-unique functionality. Ideally, we should provide that functionality outside the platform, using an API, or decline the customer request. If we do decide to incorporate it, we should ensure that it makes financial sense as the majority of costs related to software are accrued after the initial development of the functionality.
- Control platform variability: Most of the platforms I have been involved in have thousands, tens of thousands or even more than a hundred thousand variation points. The complexity resulting from this is phenomenal and it causes significant extraneous costs when adding features and when testing the platform. Many variation points have dependencies on other variation points, resulting in a combinatorial explosion of configurations that often cause post-deployment issues as it is impossible to test all variations. Platform variability needs to be carefully controlled, meaning that variation points that no longer provide sufficient business value need to be removed and new variation points introduced only when the business case, including all the secondary cost, is significant.
- Constantly optimize commodity for TCO: Platforms have three layers of functionality, i.e. innovative and experimental functionality, differentiating functionality and commodity functionality. The latter category tends to constitute the vast majority and tends to gobble up 80–90% of the R&D resources. In order to ensure we can invest sufficient R&D resources in innovation and differentiation, we need to continuously look for ways to reduce total cost of ownership of commodity functionality. We can do this by replace bespoke functionality with commercial or open source components, simply removing functionality, freezing functionality, meaning that we stop accepting change requests, etc.
- Instrument your platform for data-driven decisions: Edwards Demming, the American who helped Japan rebuild itself after the 2nd world war, famously said: In God we trust; all others must bring data. This is still a lesson most companies have not fully incorporated. Also around platforms, there are many decisions that get taken without much evidence, purely based on beliefs and earlier experiences by key decision makers. One reason is that often the data is not available and hard to collect. For instance, most companies that I work with can not answer basic questions concerning feature usage in their platform. How do you prioritize R&D resources if you don’t even know whether the features you already have built are even used? Hence, platforms need to be instrumented to facilitate data-driven decisions and should be easily extensible with new instrumentation when required.
- Be careful to open up to 3rd parties: Every platform company I have worked with would love to open up their platform for third parties and get “free” functionality extensions. In my experience, if something sounds too good to be true, it typically is and this is no exception. 3rd parties often put constraints on the platform such as requiring interface stability, requests for functionality that helps them, rather than your customer, etc. Also, the 3rd party has an inherent ambition to build differentiating functionality themselves and push the platform into commodity as much as possible. Consequently, opening up should be based on a carefully crafted strategy and initially be driven by experiments that allow you to shut down the initiative if the consequences are not as desired.
- One ecosystem platform stakeholder at a time: Ecosystem platforms serve, by definition, two- or multi-sided markets. Getting a multi-sided market to the ignition point where the ecosystem fuels itself without constant investment by the platform provider is extremely demanding and expensive. Rather than trying to build all sides of the market simultaneously, the better approach is to build the market one stakeholder category at a time. In practice, this means first building up a customer base of sufficient proportions based purely on the platform functionality and only then opening up to building up a second stakeholder category.
Concluding, platforms represent a powerful concept that, however, can be incarnated in a variety of different ways. It is critically important to understand what you are looking to accomplish with the platform and to drive incentives accordingly.