Technical
Building Platforms Part 1: Platform as a Business Strategy
Naphat Sanguansin
How does one go about building platforms? As in most things, the place to start with is the why. In this blog post, I will argue the importance of defining a platform strategy and why platforms are necessarily a business strategy.
Building Tactically
Jane had a great new idea for a product and assembled a team of like-minded engineers to build it. They built the initial MVP based on well-known systems in the industry. They built a python web server, ran it on Kubernetes, and pulled in a relational database from a cloud provider. They launched the product to several very interested users. Things are looking up for Jane and her team.
As users started engaging, there was more urgency in needing to build new features very quickly. Some customers began giving requirements around running batch jobs and ML workloads, so one of Jane’s teammates looked around and decided to stand up Airflow. Users started hitting expensive routes more often, so Jane decided to pull in a Redis cache. At the same time, operational issues began to catch up to the team. Kubernetes required a complex upgrade, and another one of Jane’s teammates decided to stand up a second cluster to do it safely.
Finally, Jane came up for air and was surprised by what she saw. Her product’s architecture had gotten very complicated. The team had taken dependencies on highly complex systems like Kubernetes and Airflow. The team was burnt out and spent most of their time keeping the system up instead of building features for their customers.
When in the trenches of building a product, it is natural to focus on the immediate problem at hand to get features out to customers quickly. Do we use GCP Spanner or AWS Aurora? Should there be a monolith or many services? What is the most secure way to implement authentication? Focusing on these kinds of questions is building tactically. The pitfall of building tactically without an overarching strategy is that it can result in systems that one may not have intentionally signed up to depend on and run and do not contribute meaningfully as a business differentiator. Put simply, the end state of the systems is not business-aligned.
Platform as a Business Strategy
There are many definitions of a platform, and many may not agree on when exactly a set of systems become a platform. For this post, I will use “platforms” to refer to any underlying systems that back a tech-enabled product. Because the need exists, you will have to set up something to fulfill it. Whether you run a multi-cluster Kubernetes setup or rely on Heroku and Netlify, you, intentionally or not, have a platform.
Building a platform involves defining a set of workflows and implementing or buying the primitives that back them. As the previous section demonstrates, defining a strategy for building platforms is essential in guiding these tactical decisions. Defining a platform strategy in your organization can be the difference between incoherent and intentionally designed systems that meet your business needs. As Cristóbal García García and Chris Ford from Thoughtworks put it,
“When well executed, a platform strategy promises to reduce costs and allow product development teams to focus on innovation.”
At the crux of defining a platform strategy is time in some form, such as a clock on a wall, time saved through headcount adds, etc. Platforms take time to build, with the promise to return back time in the future in the form of efficiency. Because the single most crucial variable is the tradeoff of time, the most significant stakeholder in how platforms are built is the business. The business funds the building of platforms and ultimately has the most to gain or lose from them. The platform strategy, therefore, must be a business strategy.
Going back to the story from the previous section, there were a few possible strategies Jane could have decided on. Jane could choose to invest in the serving stack, knowing the user growth will continue to spike. She could decide that her team’s ML talent is a differentiator and choose to double down on an ML platform to make it easier to experiment with models. She could decide to avoid any internal investment altogether, buy where possible with the intention to rebuild when her company finds product-market fit, and invest in a larger team at that time. These are all valid strategies. The deciding factor amongst all options is understanding what is business-aligned. Weighing potential benefits to the business against the cost of building will help Jane properly decide how a platform should be built.
Conclusion
Platforms must work for the business goals and objectives. Anything less results in systems that eventually hinder the business by taking away valuable mindshare and resources; these systems should not exist. To make sure that your team does not fall into the trap of building platforms tactically, you must define a platform strategy that is business aligned.
Once you have defined a platform strategy, the next steps are to define guarding principles to help your team execute the strategy. In Part 2 of my Building Platform series, I go into defining these principles in detail.
