How to create great digital platforms for developers

How to create great digital platforms for developers

[post-meta]

The modern history of software development is one of platformization. By abstracting complexity behind self-service APIs, we make it possible for teams and organizations to move fast – and innovate even faster. When Amazon launched their first cloud service, it was based on its internal platform. As the company went through astronomic growth, these systems were made reusable, self-service and fit for public use.

Amazon Web Services is a testament to platforms’ power in solving technological challenges and scaling a business. Other organizations seek to imitate some of this success at a smaller scale: internal platforms are often positioned as a cornerstone of an organization’s IT landscape.

On paper these initiatives make sense, but in practice they often fall short of expectations. One reason they fail to become success stories lies in the fact that they were not developed as customer-centric solutions: in short, they fail to meet the needs of developers.

In this post, we take an opinionated look at what makes a good platform, what is necessary for a great platform and how we can stimulate the creation of such platforms.

What makes a good platform

A good platform will consider several dimensions, often specific to your organization. But in its barest essence, a good platform allows autonomous teams to go faster. Some of the criteria that a good platform will meet are self-service, abstraction and composability.

Martin Fowler describes a good platform as one that enables autonomous teams to move fast, naming self-service a key defining characteristic of a good platform.

A good platform always abstracts something. Exactly what and how much depends on the type of platform. Digital platforms either abstract underlying complexity (such as hardware virtualization) or combine several services that are used together.

This abstraction exists in creative tension with another aspect, that of composability. By splitting the platform up into components it becomes possible for a developer to use what is needed and possibly extend it with others.

What makes a great platform

A great platform goes beyond a list of checkboxes: it attracts participants by creating value and speaking in a language they understand. This is a difficult thing to get right. The most effective way to do so is to put developers front and centre and work backwards from their needs.

It is not uncommon for organizations to work backwards from capabilities and attempt to design a platform that can do everything. The tendency to do so comes from a good place: by centralizing common concerns it becomes possible to reduce risks and costs. Such initiatives seemingly follow all the rules of what makes a good platform, but often fail to live up to the high expectations.

That is because a platform can tick all the boxes, but fail to satisfy its users on every single one as well:

  • A self-service solution that requires submission of tickets fails at eliminating interdependencies.
  • An abstracted service that requires deep knowledge of the underlying process (read implementation) fails to meaningfully abstract.
  • Similarly, a platform that introduces multiple unique layers of abstraction fails to simplify.

The goal of a platform is to make difficult things simpler, and it is here that many platforms struggle to find their audience – arguably because they didn’t start with one in mind.

Working backwards

We can apply this brand of thinking on a fictive platform, to see what it would mean to work backwards. When we fail to do so, we end up with platforms that do not solve the right problems and therefore fail to become the success stories we wish for.

For illustrative purposes, we will use a simplified example of an organization that requires teams to run containerized web applications. Since every team has been (re-)implementing similar patterns of load-balanced containers on shared compute, it has been decided that everyone will standardize on Kubernetes with a default set of instructions in the form of Helm Charts. Kubernetes empowers developers to implement these specific patterns in a reusable manner.

Was doing so the correct decision? Maybe, but to understand whether the platform will be great requires asking the right questions. So, what is the user experience we want developers to have on the platform?

Now imagine we bring up the courage and ask them. It seems that most teams are not infrastructure specialists, and would prefer to program web applications instead of orchestrating deployments. Ideally, they want to provide the platform with a code artefact and receive a fully hosted and scalable web application back.

It hardly matters which technology you pick here, as the solution is found by meeting the platform users with the right level of abstraction. Instead of exposing a Kubernetes cluster, the platform is much more likely to succeed if developers receive an API to deploy new applications. Whether or not those applications run on a centrally managed cluster is irrelevant to the developer.

Is abstracting everything away always the best approach? Hardly, some platforms are fairly complex, just look at AWS. But the example here was chosen intentionally: in many cases such a simple process is the experience developers wish for. And when it is not, working backwards will allow you to figure out what is.

How to stimulate great platforms

Why do many internal platforms fail to be developer-centric? Much of it is due to the monopolistic position platforms enjoy within the company: if there is only one mandated option, then no incentives exist to rigorously pursue a better experience. It is here that organizations can make a disproportionate difference to their success by applying a few principles:

  • Do not mandate a solution. If it truly solves a problem, it will find an audience.
  • Stimulate competition between platforms and accept that platforms can co-exist.
  • Measure platform success by how well it empowers developers to do more.

Tying everything together can be more art than science, but hopefully this short perspective will assist you on your own journey towards building great platforms.

Dick Eimers