Everyone loves to own a platform and use it to their advantage, either internally or externally. The notion of a platform communicates a perspective where there’s a fundament that we and others can build on top of. Without having to do all the hard, boring work ourselves. Instead, we can focus on that which is differentiating.
As many have experienced in their professional lives, the platform notion is severely overused in most companies. In software alone, there are at least three different interpretations: the commonality platform, the superset platform and the ecosystem platform.
The commonality platform relates to the basic notion of software product lines. The idea is that it captures the common functionality between the products in a product portfolio. Each product can then use the platform and build the product-specific functionality on top of that.
Of course, in most product portfolios, there are features and functions that are present in some but not all products. When these are incorporated into the platform, it requires the introduction of variation points that allow specific features to be activated or deactivated depending on the product using the platform. Many traditional platforms suffer from a very large number of variation points that can easily become unwieldy and hard to manage.
As the name indicates, the superset platform includes the superset of all functionality by all products in the portfolio. Each product simply becomes a configuration of the functionality present in the platform. Similar to the commonality platform, the superset platform contains variation points to allow for the configuration of each product.
With the growing adoption of DevOps, the superset platform is increasingly becoming the optimal approach for companies as, compared to alternatives, it provides the most efficient way of creating each product-specific software configuration. Of course, this requires configuration tools to automate the derivation of products but also automated tests to ensure that each product is working as it should, also after extensions to the superset platform.
With the enormous success of companies like Apple with the iOS ecosystem and Google with Android, everyone and their brother are now looking for ways to have others build solutions on top of their platform. In practice, the ecosystem platform is by far the hardest to accomplish as it requires us to create a two or multi-sided market.
In creating these multi-sided markets, there’s the notion of the ignition point where the number of players on each side is sufficient to generate enough activity to keep the market going without active involvement of the platform provider. Reaching the ignition point, however, is a hard slog for many companies that easily consumes large amounts of resources and funds.
To avoid wasting vast amounts of resources on a failed attempt to build this market, my recommendation to the companies I work with is to focus on one stakeholder, typically the customer, and do everything we can to maximize their number. When that’s successful, rather than us having to recruit complementors, they’ll start to knock on our door asking to be let in. At that point, the time has come to put some attention on that stakeholder group as well.
In addition to the above interpretations of the platform in a software engineering context, the term is also used in other contexts. For instance, companies may use customer support platforms where customers can answer each other’s questions rather than relying solely on customer service staff. In marketing, many companies seek to establish a platform where prospective customers meet existing customers around specific problems and challenges that our offerings provide an answer for. And the list goes on.
As with the earlier posts in this series, my point isn’t to claim that platforms don’t exist but rather to encourage you, dear reader, to ensure that everyone in the conversation has the same understanding of the concept to avoid misconceptions, inefficiencies and tensions. Each type of platform has its own characteristics, in terms of investment needs, risks, challenges and mitigation strategies.
For companies working with commonality platforms, the highest-priority activities are the following three. First, you should start moving to a superset platform in preparation for adopting DevOps. Even if your customers are currently not interested in getting your software more frequently and claim that they’re happy with your yearly release, this will change sooner rather than later and it will take quite a bit of time to transition the platform from a technical perspective.
In addition, many companies that use commonality platforms also support various customer branches. The cost and inefficiency of maintaining all these branches for both products and specific customers are vastly underestimated. It’s only once you’ve brought everything into one superset platform that you realize how much waste was created by the old approach.
Second, surprisingly many companies still rely to a significant extent on manual testing for quality assurance. This may have been acceptable when software releases were infrequent, but with DevOps becoming an industry best practice, it’s critical to reduce and remove the dependency on manual testing and build up the infrastructure for automated testing. The ambition has to be to always be at production quality.
Third, when the company and the product portfolio are successful, there will be external parties interested in adding specific extensions to some of your products. This development has numerous implications that go beyond the scope of this post, but when it happens, you need to have an agreed-upon strategy for opening up. One strategy is, of course, to decline opening up, but you’ll be surprised how creative external developers can be. I know of cases where third-party developers inserted themselves between the software and the operating system layer to intercept calls and add functionality at that point.
As the last post in the series, the notion of a platform also is a poorly understood concept that has many associated interpretations. Consequently, any discussion on platforms easily leads to confusion, frustration and tension unless we’re exceedingly clear on the definition we’re using. Due to digitalization and the increasing use of DevOps, we need to change the way we work with platforms. This includes transitioning to a superset platform approach, establishing an automated test infrastructure that covers all products in the portfolio and defining a clear strategy for when others come to us, asking for us to open up our platform for their purposes. And, to end with a quote from Mitchell Baker, “The web as a platform is the most powerful platform we’ve ever seen.”
Want to read more like this? 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).
