Having worked with platforms for the better part of three decades, I’ve seen the notion evolve over time. Today, we can distinguish at least three main goals that companies have for them: 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 that we should bring together in a platform the product teams can use to build their products faster and more efficiently. The perceived benefits of resource sharing 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. This especially happens in companies where the leadership doesn’t 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 efforts 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 the functionality of the entire product portfolio, with each product basically being a subset created through automated configuration and test. That allows companies to frequently release new versions of the software without the associated release cost.
The holy grail is to provide a software platform to a two or multi-sided market where 3rd parties develop solutions on top of it and customers 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’s a mix of all three types of platforms. I want to share some of my learnings after working with platforms for many moons. I hope my insights provide some benefit and inform the discussion.
1. 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 often is 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 them 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. When doing so, interestingly, efficiency will follow.
2. Avoid the platform/product dichotomy
Over the past years, I’ve become increasingly 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 avoids 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.
3. 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 with continuous integration and test, we can catch introduced errors early so that the cost for fixing them is minimal.
4. 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 most, innovations fail to deliver the expected outcomes. 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’s 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 into 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.
5. Distinguish customer-unique and customer-first functionality
There will always be functionality requested by customers. Some of it 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’s 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.
6. Control platform variability
Most of the platforms I’ve 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 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’s 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 need to be introduced only when the business case, including all the secondary cost, is significant.
7. Constantly optimize commodity for TCO
Platforms have three layers of functionality: innovative and experimental functionality, differentiating functionality and commodity functionality. The latter tends to constitute the vast majority and gobble up 80-90 percent of the R&D resources. To ensure we can invest sufficient R&D resources in innovation and differentiation, we need to continuously look for ways to reduce the total cost of ownership of commodity functionality. We can do this by replacing bespoke functionality with commercial or open-source components, simply removing functionality, freezing functionality, meaning that we stop accepting change requests, and so on.
8. Instrument your platform for data-driven decisions
Edwards Demming, the American who helped Japan rebuild itself after World War II, famously said: “In God we trust; all others must bring data.” This is still a lesson most companies haven’t fully incorporated. Also around platforms, many decisions get taken without much evidence, purely based on beliefs and earlier experiences by key decision-makers. One reason is that often the data isn’t available and hard to collect. For instance, most companies I work with can’t 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’ve already 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.
9. Be careful to open up to 3rd parties
Every platform company I’ve 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, and so on. Also, 3rd parties have 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 aren’t as desired.
10. 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 do it 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.
Platforms represent a powerful concept that can be incarnated in a variety of ways. It’s critically important to understand what you’re looking to accomplish with the platform and to drive incentives accordingly.