Platform engineering should have a product focus, as developers are customers, Daniel Bryant said in his talk Platform Engineering for Software Developers, Architects, and the Rest of Us at GOTO Copenhagen. They must provide composable, self-service capabilities, golden bricks rather than rigid golden paths, so teams can move quickly while maintaining consistency. Success is measured through adoption, developer experience, and business outcomes such as deployment frequency and change failure rate.
Bryant recalled how he went from classic Java development into more service-oriented architectures. Having to learn more things, his cognitive load went up. Then microservices happened, which brought a lot of baggage for him:
My cognitive load shot through the roof. It was a lot of stuff to learn to get code shipped. I wanted a bunch of tools I could mix and match, but I was stuck on how to build an interface for these tools to code, ship, and run.
A platform is a sociotechnical thing, Bryant said. They are building self-service APIs, tools, and service knowledge into a compelling internal product, where the goal is to deliver product features at a higher pace with reduced coordination.
Bryant mentioned three goals that platforms aim for:
- Go faster: platform teams need to provide "everything as a service" to help rapidly and sustainably deliver value to end users
- Decrease risk: teams need to automate manual processes in reusable components
- Increase efficiency: you need to manage and scale your digital platform and resources as a fleet
You have to treat the platform as an internal product, not an internal project, Bryant mentioned. That means understanding developer workflows, identifying friction, and measuring adoption and satisfaction:
If developers avoid the platform, that is feedback in itself!
If the platform makes the right thing easy to do, developers will choose to use it. Platforms increase efficiency by having the right abstractions. The goal is to reduce cognitive load and enable fast flow. Each team must own their flow of value, Bryant said. This is true for developers as for the platform team. It breaks down when you, as a developer, have to raise a ticket:
You’re waiting for someone to give you a database or open a port. Your flow of value is disrupted.
Platforms can facilitate collaboration by providing services. The key things with "x as a service" are low cost, clear boundaries, and focus on the provider’s service adoption and the consumer satisfaction, Bryant said.
Bryant encouraged thinking about golden bricks rather than golden paths. A path as a single way to do things can become a golden cage. You build your own golden path, the right way to do something, by assembling the bricks. Composable capabilities let teams move quickly while maintaining safety and consistency.
To frame platforms for the C-level, you also want to have metrics, Bryant said. He focuses on adoption, experience, and outcomes, drawing heavily on the work of Camille Fournier and Ian Nowland:
Adoption shows whether teams are actually using the platform. Experience includes factors such as provisioning time and developer satisfaction (which are part of the SPACE and DX Core 4 frameworks). Outcomes are connected to business impact through (DORA-like) metrics such as lead time, deployment frequency, and change failure rate.
These metrics help identify friction and guide improvement, Bryant said. The goal is to help teams deliver value faster, more safely, and more efficiently (and, where appropriate, at scale).
Bryant warned to watch out for leaky abstractions. Developers come to depend on leaky abstractions, and when you want to change the implementation of the platform, you can’t.
We have to build platforms as a product that serve internal customers, the developers, Bryant said. Ensure that they are user-friendly and genuinely solve the team’s problems. If you are a developer, demand that product focus, he concluded.
InfoQ interviewed Daniel Bryant about the relationship between platforms and software architecture.
InfoQ: How does your platform architecture look?
Daniel Bryant: As I started my career as a software architect, I like to think in terms of layers with clear boundaries.
Infrastructure orchestration manages compute, storage, networking, and other lower-level services. Platform orchestration coordinates higher-level (and often business-specific) capabilities, including DBaaS, CD pipelines, application buildpack services, and nested components such as environments-as-a-service. On top of that, application teams consume these capabilities via self-service APIs, CLIs, or UIs.
The critical principle is the separation of concerns. When platforms mix infrastructure, platform logic, and application concerns without respecting boundaries, they become fragile and hard to evolve. Clear interfaces allow each layer to evolve independently as the organisation grows.
InfoQ: You mentioned that platforms and software architecture are symbiotic. What do you mean by that?
Bryant: Platforms shape how software is built, and software requirements shape how platforms evolve.
If a platform provides reliable abstractions, teams can focus on business logic. If it doesn’t, teams work around it, creating fragmentation.
This relationship means platform teams must stay closely aligned with developers. Good platforms provide stable interfaces that allow implementation to change without disrupting applications. This enables both the platform and the software built on it to evolve safely over time.