Effective Platform Engineering with Ajay Chankramath

About Ajay Chankramath

Ajay has 3+ decades of technology leadership experience and is currently the CEO of platformetrics. He is the co-author of Effective Platform Engineering. His current interests are around improving developer productivity using domain-driven platform engineering.

The Definition of Platform Engineering

Platform engineering has been discussed for over a decade, yet confusion around its definition hasn’t gone away.

Our definition at Thoughtworks of an engineering platform was a system that can bring together the infrastructure governance, operational technologies, and all those things so that your development teams can actually use it and make things better. And the platform engineering is a craft that produces those engineering platforms. But then this question came up: Is this replacing DevOps? Or is this actually going to be a new name for something else? Has platform engineering already sailed? Is DevEx the new thing?

The confusion often starts when people ask whether platform engineering replaces DevOps, SRE, or developer experience. It doesn’t. DevOps is best understood as a cultural paradigm, not an organizational structure. That culture is enabled by concrete capabilities—those capabilities are platform engineering. The same applies to developer experience and SRE: both rely on platform-level abstractions to work at scale.

Platform engineering sits at the center, enabling all of them.

Backstage is not the Platform

One of the most common mistakes organizations make is equating platform engineering with a piece of software. Backstage is the most visible example. Teams adopt it and declare that they now “have a platform.”

This framing is fundamentally wrong.

Backstage is a framework for building a developer portal. It is not a platform. It is not even a portal by itself—it is a framework for creating one. Developer portals play an important role, but they are only one surface area of a much larger system.

The same confusion exists around the term “IDP.” Internal developer portals and internal developer platforms are frequently used interchangeably, even though they represent very different things. Portals are interfaces. Platforms are backend capabilities.

Thinking of platform engineering as a tool leads to shallow implementations that look good on the surface but fail to deliver real value.

The Seven Planes of an Engineering Platform

A useful way to understand platform engineering is to break it down into planes.

Two of these are foundational and non-negotiable: networking and security. If an organization doesn’t deeply understand how its systems connect or treat security as a first-class concern, nothing built on top will be reliable.

Beyond those foundations, the next layer is the runtime plane—containers, Kubernetes, and execution environments. This is often where platform discussions start, but it shouldn’t be where they end.

Then comes the governance and compliance plane. CI/CD pipelines are frequently lumped in here, but that’s a mistake. Pipelines belong to developers. The platform’s responsibility is to make pipelines safer, faster, and easier to operate—not to own them outright.

On top of that sits the developer plane: IDEs, repositories, and developer portals. This is where tools like Backstage belong. Think of this as the frontend.

Behind it is the internal developer platform—the backend that orchestrates environments, policies, and workflows.

The final two planes are what truly differentiate modern platforms. Observability must span all planes, not just applications and infrastructure, and it must be tied back to business outcomes. And perhaps most importantly, platforms must be treated as products, with users, feedback loops, analytics, and lifecycles.

Without a product mindset, platforms inevitably become brittle internal tooling that developers work around rather than rely on.

The ROI of Platform Engineering

Measuring that value requires looking beyond activity metrics and focusing on transformational patterns.

One such pattern is the idea of golden paths—standardized, well-paved workflows that make the right thing easy. You don't want to create golden cages, but create the golden paths with escape hatches.

Another pattern is orchestration. This is the brain behind platform engineering. Translating developers’ intent to the infrastructure activities that actually make sure that they build something. 

A third pattern is contextualization. I've been working on this idea of domain-driven platform engineering. Contextualization is the place where you can, as a developer working in a certain domain like financial services or healthcare, interact with the system through that domain's APIs as opposed to having to go figure out Terraform for something or Kubernetes for something else. Developers don't need to know all of those things. They can, but they don't need to, and they shouldn’t have to because they have better things to worry about. So, being able to contextualize that domain APIs.

Finally, there is supervised AI. Automation without guardrails quickly becomes dangerous. The goal is not human-in-the-loop everywhere, but clearly defined supervision—sometimes by humans, sometimes by platform controls.

The way to see the ROI is to identify the actual business value or a KPI for each of these patterns.

But those KPIs should be put in context; just because there are 25 KPIs tracked doesn’t mean an organization gets value from platform engineering. Platform engineering only delivers value if it changes outcomes.

Domain-Driven Platform Engineering

Most platform efforts break down because they fail to align with business domains.

Domain-driven platform engineering connects engineering platforms to industry and product domains.

When a developer says they want to deploy a payment system or a healthcare workflow, the platform should understand the implied requirements: compliance, security, operational characteristics, and observability needs. Developers shouldn’t have to manually stitch these together.

This approach bridges a long-standing gap between business intent and operational execution.

How Much Should Developers Know About the Platform?

Not every developer needs to understand every implementation detail of the platform. But they do need to understand the concepts and the reasoning behind them.

Experienced engineers often resist new platforms because they’ve seen “standardization” turn into constraint. That skepticism is justified. The way forward is not to argue engineering purity, but to frame platform decisions in terms of business outcomes.

If standardization helps teams ship better software faster and more safely, it earns trust. If it doesn’t, developers will route around it.

AI in Platform Engineering

A recent study on The State of AI in Platform Engineering mirrors what we’ve seen in the DORA 2025 report: the dam has broken.

Nearly nine out of ten engineers are now using AI in their day-to-day work. At this point, it’s no longer a question of whether engineers should be using AI; it’s already happening. 

Most of that usage today is still concentrated in code generation, but a more worrying trend is emerging as well: teams are starting to “vibe code” their infrastructure. That’s a disaster waiting to happen. Those are the things where we need to go back to the basics, saying, Let's not start with agentic automation, with your fragmented infrastructure idea; let's not start with these uncontrolled resource consumption activities. Let's go back to those four things - the golden paths, your control planes, your domain APIs, and having supervised AI.