Is Platform Engineering the Missing Layer for Hybrid Enterprise Operations?
How platform engineering aims to address hybrid complexity by acting as a control plane above a vast and varied infrastructure
The growing complexity of enterprise applications across cloud and on-premises platforms is creating challenges around how those systems work together consistently. Observability asks how teams can see what is happening across services, and site reliability engineering asks how teams can use that information to keep services reliable. Platform engineering takes the next step, asking how teams can build and operate them consistently.
A developer building an application in a hybrid environment may need to navigate AWS, Kubernetes, application programming interfaces (APIs), databases, identity and security controls, as well as core enterprise systems. Infrastructure teams, meanwhile, may need to repeatedly address the same provisioning and governance challenges.
Platform engineering aims to address this complexity by acting as a control plane above the infrastructure, Srinivas Chippagiri, senior member of technical staff at Tableau, tells TechChannel.
“Developers shouldn’t necessarily have to understand every aspect of it,” Chippagiri says. “The platform may be running on IBM Z, Kubernetes, EC2, or any managed cloud provider. So the platform should expose certain high-level capabilities. For example, it needs to deploy an application, maybe a database or any core API access, but behind that, the platform team can encode certain organizational standards, for security, for deployment, or resilience.”
Golden Paths Through Hybrid Complexity
In large enterprises, platform engineering has to balance developer autonomy with the controls needed to operate systems safely. Developers want speed and flexibility, while IT teams need to maintain security, compliance, cost controls, reliability and consistency.
“The important part is not trying to fit everything in one bucket,” Chippagiri says. “Instead, try to standardize the developer experience and the governance model while allowing the underlying execution to remain optimized for both workloads, on-prem and cloud.”
An internal developer platform (IDP) can bridge the gap by establishing “golden paths,” which are pre-approved patterns that enable developers to build and deploy applications without repeatedly having to solve the same infrastructure and operational problems.
For example, a developer might request an AWS environment through a self-service portal, which the platform can then provision automatically with the appropriate controls in place.
“There needs to be a curated set of paths,” Chippagiri says. “So, for example, instead of saying, ‘Hey, here’s a bunch of AWS things that you can do, take it and do whatever you want,’ there needs to be an approved pattern, such as controlized APIs, or event-driven services, or even a managed database with batch workloads.
In a hybrid setup, golden path could combine AWS infrastructure, Kubernetes environments, API connectivity and governed access to mainframe systems with identity and access management (IAM).
“As part of that, we need to also keep in mind reusable templates, like CI/CD workflows, and infrastructure as code, and of course the observability and security control that basically come with it,” Chippagiri says. “Once you have those standardized paths… they also need to include IAM encryption, tagging, networking and backup.”
Enterprises in regulated industries such as financial services would also need to include certain FinOps concepts or MLOps concepts, Chippagiri adds.
Building Organizational Alignment
Platform engineering can provide a common technical foundation, but technology alone cannot resolve the organizational complexity of working in hybrid environments.
Phil Christianson, chief product officer at Xurrent, sounds a note of caution. “I’ll be upfront: I’m skeptical of platform teams, and it comes from having run them. My concern isn’t the idea—it’s that platform teams drift from business impact more easily than almost any function I’ve ever managed.”
Without clear coordination, the platform team can become another silo that increases fragmentation in an organization. And growing AI adoption is changing the equation.
“The classic justification was reuse economics: Build something once, so every team doesn’t reinvent it. But in the age of AI, when code is cheaper to produce than it’s ever been, that ‘build it once for everyone’ argument gets a lot weaker—it’s genuinely easier now for a team to just do it themselves,” Christianson says. “And the moment a platform team loses the thread back to a business outcome, it stops reducing work and starts inventing it.”
Platform engineering and SRE aim to address different parts of the same operational challenge. SRE sets out principles for how reliability should work, while platform engineering can make those practices repeatable across cloud, Kubernetes, APIs and core systems like IBM Z or Power.
But platform engineering does not automatically fit between service management, SRE and IT operations in a hybrid environment.
“I’d resist slotting it in as a fourth discipline sitting alongside the other three, because that framing is exactly how it goes wrong,” Christianson says. “Platform engineering isn’t a peer function competing for territory—it’s an enablement layer whose entire reason to exist is to take toil off the teams already doing the work.”
Mainframe, cloud, security and development teams often have different tools and priorities, and a platform designed around excessive or incompatible controls can create friction rather than remove it.
“It only fits if there’s a real, repeated pain that multiple teams genuinely share,” Christianson explains. “In a hybrid environment that pain is usually the seams: the handoffs between cloud and on-prem, the inconsistency in how environments get provisioned and governed across both. That’s a legitimate place for a platform team to earn its keep. But if you’re standing up the function first and then hunting for a mandate, you’ve already inverted it.”
Successful platform engineering is about the organization rather than the technology, requiring defined users, clear ownership, measurable outcomes and continuous improvement, supported by the executive level.
“There has to be a product owner who is accountable to business outcomes, not to technical elegance. That person needs named internal customers, adoption metrics, and—critically—the authority to say no to work that doesn’t ladder up to an outcome,” Christianson says. “Most platform drift I’ve seen traces back to the absence of exactly that role.”
A platform only succeeds if developers want to use it.
“It has to be self-service and pull-based, not mandated through force. The healthiest signal a platform can have is voluntary adoption,” Christianson points out. “If you’re compelling teams onto it through policy rather than winning them on value, you’re papering over the fact that the thing isn’t actually easier to use. With AI coding… teams would rather do it themselves.”
Platform Role Expands With AI Adoption
The role of platform teams is expanding as enterprises scale up their use of AI across departments and applications.
“Platform teams are now absorbing GPU capacity in terms of governance for it. For example, quota management, spot versus reserved allocation, the cost attribution of it,” Chippagiri says. GPUs are expensive and often constrained, requiring platform teams to help manage the resources required to run AI workloads by determining who can access GPU capacity, which workloads to prioritize and how to monitor and control usage.
“This is particularly important for mainframe-heavy enterprises because data governance and then compute becomes more important for those kinds of applications,” Chippagiri notes.
This extends the platform role from enabling application development to governing access to increasingly specialized infrastructure.
“We need to work on the governance aspect of it,” Chippagiri says. “There’s AI governance that’s coming into IDP as an afterthought. They [need to] extend the same level of importance that you need for traditional applications to AI as well.”
As AI workloads become part of mainstream enterprise IT, platform teams can be an effective link between developers, infrastructure and governance, provided they reduce complexity rather than create another layer and keep closely aligned with measurable business outcomes.