Platform engineering

Why is everyone building a platform now?

Reading online, if you manage to make it through the mound of AI/Agent/Copilot posts, a lot of people are talking about building platforms.

I’m also guilty of this, having been part of ML, data and streaming platform teams in the last years. But was counts as a platform?

According to wikipedia: „Platform engineering is a Software Engineering discipline focused on the development of self-service Toolchains, services, and processes to create an internal developer platform“.

So platforms are not some super concrete thing, they are usually just something you write to be used by other engineers at your to help them build their products.

Often, the purpose is to reduce reduntant work, simplify operations due to more coordinated tech stacks and improve the developer experience.

Lessons from Ludwigshafen’s main railway station

Having grown up in Ludwigshafen am Rhein, I grew up having a huge, impressive, ugly and mostly deserted railway station at the edge of our medium-sized city.

It was built in 1969 to replace the existing station, which due to being a terminus, became impractical and outdated. Additionally, the rising city of Ludwigshafen wanted to have a representative station, part of it’s plan of a modern city called Projekt Visitenkarte.

So city planners and Deutsche Bahn went ahead and constructed a monumentally huge railway station with 12 platforms spread across three levels. For infrastructure reasons, as there were existing tracks and crossings at the desired location, the station was moved outside the city center.

Unfortunately, since Mannheim, a much larger city, has it’s railway station just 5 rail-minutes away, and since the new station was in the middle of nowhere, there wasn’t much use for the station as it was built. Today only 3 out of the 12 platforms are used. So what can we learn for platform engineering?

Just because something is practical for infrastructure reasons, it might not be what people need. Another parallel is that rivalries between departments can lead to competing platforms (e.g. Ludwigshafen vs Mannheim) which then have to be expensively consolidated later.

A look from the user experience (UX) perspective

Just because a platform is built for engineers and internal, it doesn’t mean one should expect them to all think and work like the platform engineers: You are not the user.

Finding out who the product is targeting is one of the most important parts of building a product: Find them and talk to them. People from different backgrounds and different teams have vastly different views and needs for your platform: Ask for feedback and try to provide a great developer experience for them.

Next, when shipping a full-stack application, we would never ignore the frontend and the same applies to platforms! The main frontend of your platform is your documenation: Find out how people use your platform and provide the documenatation which they need, alongside OpenAPI specs etc.

The more your documentation is tailored to your users’ needs, the more likely people will use it and keep it up to date. There’s nothing sadder than unread documentation which was only written to tick a box in a ticket.

Lastly, the better your connection to the developers using your platform, the better. Fostering a community of platform users through clear communication of bugs and fixes as well as regular exchanges can help a great deal to prevent developer frustration.

This also applies to positive updates: Celebrate your successes and talk about all your new features, which can increase acceptance and excitement for using the great platforms you will build.