As an industry we’ve been talking about platforms for a very long time. Everyone thinks they need one but many people don't know why. Perhaps more concerning, many organizations build them and then don't realize the value they expected. This trend was reinforced by the recently published Technology Radar — Thoughtworks’ biannual look at the tech landscape — where the number of entries we looked at for our platform quadrant was markedly down.
What is going on here? Have organizations tired of platforms? Is the problem with a true lack of value, perception or misaligned expectations? It’s probably a mix of all three.
What’s in a name?
One of the biggest challenges is that the word platform has become so widely used as to be unhelpful on its own. How do we then build platforms that solve business problems and create value for our organizations?
There’s also the issue of bias. By that, I mean what we each assume is meant by the name platform. For example, I work mostly with developers. I did a very non-scientific informal poll on Twitter asking what people thought of when I said the word platform.
As you can see the majority thought of the foundational platform. However, if I had asked the same question to a business audience, they likely would have chosen the platform business model. And If you don’t address this difference early in the process of building a platform, expectations about what you’re building are almost certain to be poles apart.
Back in 2017, Thoughtworker Peter Gillard Moss identified three basic types of platforms from a technology perspective. The fact that this article is four-years old and still highly relevant at the time of this writing demonstrates the struggle many organizations have in understanding the types of platforms. As Peter correctly points out, there’s a wide variety of thinking about what a platform is from a technologically standpoint. You can reference that article for more details but the high-level description is as follows:
Foundational technology platform:
Put simply, this is a system that we deploy applications to. In this way of thinking, we could say that an operating system is a platform. Whether it's Windows, Linux, or Mac an operating system provides access to things like the file system, the ability to calculate time, the ability to drive our user interface and such like.
If you think about a public cloud platform, it is doing the same thing. For example AWS has S3 for file storage and several database options and several scheduling options. Google Cloud and Azure offer the same things but with their own unique feature sets.
Digital business platform:
A digital business platform builds on the foundational platform by adding APIs that enable external participation. So, for example, if you’re a bank you might have an API for calculating interest. Teams developing applications can use your API instead of doing their own calculations.
Offering/service platform:
At the top end of the scale we have the platform business model. The purpose of this type of platform is to connect producers with consumers. For example if you look at Airbnb, they don’t own any buildings. They connect owners with people who want to rent space. This business model has almost uncapped potential, as the go-between does not have to worry about supply chain or physical liabilities.
The intended use
One of the biggest misconceptions is that an organization will have a single platform. One place where all applications are deployed, one place where all business facing APIs exist, or one place to connect consumers and producers. This is almost always false.
Neal Ford likes to say, when talking about software architecture, that the more reusable something is, the less usable it is. For platforms, what this often means is that a one-size-fits-all solution will end up not solving some of the specific use cases for an individual business unit.
In addition to the fact that there are many types of platforms from a technology perspective, there are also a lot of different intended use cases. For example, an organization might have a data platform which is intended to solve specific business problems by making APIs which expose information available. That same organization could have a platform which has the primary purpose of customer relationship management. At the foundation, these could be very close to the same technology.
The expected use of a specific platform also has a dramatic effect on the tools that might be used. For example there are specific build, test and deploy tools for machine learning. These tools will have much in common with those built to build test and deploy applications but they will have key differences.
Platform building for value
Perhaps the most important aspect to getting the value you expect is aligning expectations. It’s important to have a solid understanding of what it is you're trying to build, what business problem you're trying to solve, and what value that has to the organization.
Technologists will often say things like “it will make it easier for me to deploy applications". While this is certainly an important and reasonable feature for a foundational technology platform, it is not in and of itself a business value. What does deploying applications easier mean to your business? Can you cut down cycle time? Can you increase market share by beating your competition? How can you quantify this?
You also need to recognize that different types of platforms satisfy a particular segment of your organization but not others. This can lead to the rebirth of functional silos: you have platforms for data, platforms for machine learning, and they don't play well together. When designing these platforms, organizations need to focus on how they will interoperate. So it's not just how my machine learning platform makes new models and generates data, it's how I can make that data available to my other platforms in a way that is useful.
In the next two pieces of this three-part series, I’ll be looking at how to build and how to run successful platforms.