Enterprise Platform Engineering

Platform engineering as a discipline has crystallised over the last few years. The terms — internal developer platform (IDP), paved road, platform-as-a-product, developer experience (DevEx) — now have widely shared meaning. The pattern is no longer experimental; it is the operating model that distinguishes enterprises whose engineering organisations scale from those that bottleneck on shared infrastructure work.

This piece is a practitioner view of what platform engineering actually requires in regulated enterprise estates, where the value comes from, and what mistakes recur often enough to be worth flagging.

The problem platform engineering solves

In a mature enterprise, every application team needs the same things: a cloud landing zone, a CI/CD pipeline, an observability stack, a secrets management solution, a deployment runtime, a security baseline. Without a platform team, each application team builds (or buys, or assembles) their own. The result is operational drift across the estate, repeated effort, inconsistent security posture, and engineers who spend more time on infrastructure work than on the business logic that justifies their existence.

A platform team operates the shared infrastructure as a product, with application teams as the consumers. The platform team owns the runtime; the application teams consume it through a defined contract.

This is not novel as a pattern. What has crystallised is the discipline: how the platform team operates, how the contract with consumer teams is defined, how the product mindset is enforced, and how the platform evolves over years.

The platform-as-a-product mindset

The single most important commitment in platform engineering is treating the internal platform as a product. This means:

The platform has users. Application teams are users; their needs, their feedback, their adoption are first-class concerns of the platform team.

The platform has a roadmap. Capabilities are prioritised, sequenced, and shipped intentionally. New capabilities are rolled out with the same discipline as commercial product launches — communication, documentation, support.

The platform has a feedback loop. User satisfaction is measured. Quarterly user surveys, structured feedback channels, adoption metrics on new capabilities. The platform team responds to feedback.

The platform has a vision. What is the platform trying to enable? What does success look like in twelve months? In three years? The vision is articulated and communicated.

Teams that treat the platform as infrastructure produce platforms that meet the literal request and miss the underlying need. Teams that treat the platform as a product produce platforms that user teams actively recommend to colleagues.

The DORA research has documented this; the practitioners building real platforms have lived it. The product mindset is the differentiator.

The paved road

The phrase "paved road" describes the standard, well-supported, opinionated path that the platform provides. A team using the paved road gets the deployment pipeline, the observability stack, the security baseline, the operational runbook — all pre-configured and supported.

The paved road has properties:

• It is opinionated. The platform team makes choices on behalf of consumer teams. You cannot please everyone; pick the choices that fit the majority and accept that some teams will need variations.
• It is golden, not mandatory. Consumer teams can choose not to use the paved road. The path remains available; they just operate off it themselves.
• It is complete. A team using the paved road can ship a service to production without making infrastructure decisions. The pipeline, the deployment target, the secrets, the observability, the security posture — all are provided.
• It is monitored. The platform team can see how the paved road is being used, where it fails, where consumer teams hit friction. The road improves based on observation.
• It evolves. New patterns get added to the road; old patterns get retired. The road's lifecycle is part of the platform's lifecycle.

The estates that maintain a strong paved road have most of their consumer teams using it most of the time. The estates that don't have consumer teams routinely going off-road, building bespoke infrastructure, and creating the operational drift the platform was meant to eliminate.

The platform team's service contract

The contract between the platform team and consumer teams is explicit. It defines:

What the platform provides. Specific capabilities, with documented SLAs. The deployment pipeline is available with X uptime; cluster upgrades happen on Y cadence; the observability stack retains data for Z days.

What consumer teams are responsible for. Application code, application configuration, application observability instrumentation, application security posture. The boundary is clear.

How consumer teams onboard. A documented process — usually a self-service portal entry, a few configuration choices, and a guided first deployment. The onboarding cost should be hours, not weeks.

How consumer teams escalate. Channels for support questions, bug reports, feature requests, and incident escalation. The channels are staffed and responsive.

How the platform changes affect consumers. New capabilities are announced in advance. Breaking changes have published timelines. Deprecations follow a defined policy. Consumer teams are not surprised by platform changes.

The estates that have a written, lived service contract operate cleanly. The estates that don't operate through perpetual ambiguity about who is responsible for what.

The capabilities the platform actually provides

In the regulated enterprises we work with, the platform typically provides:

• A cloud landing zone with the right network, identity, and security posture for the organisation's compliance requirements
• Deployment runtime — usually Kubernetes (AKS, EKS, GKE, OpenShift) with the relevant operational tooling
• CI/CD pipeline with security scanning, testing harness, deployment automation
• GitOps deployment through ArgoCD or Flux, with the appropriate environment promotion model
• Observability stack — metrics, logs, traces, and dashboards
• Secrets management through a managed secrets service with rotation discipline
• Service mesh for service-to-service mTLS, traffic management, and observability (where the workload justifies it)
• Developer portal through Backstage or equivalent, providing self-service access to all the above
• Documentation and golden-path templates for common service shapes

The list is consistent across organisations. The implementation choices vary by cloud provider and team skill set; the underlying capabilities are largely standardised.

The developer portal as the surface

The internal developer portal is the practical interface to the platform. Backstage has become the dominant choice; alternatives include Port, OpsLevel, and various platform-vendor offerings.

The portal provides:

• A service catalogue of every service in the estate, with ownership, documentation, dependencies, observability links
• Self-service templates for creating new services with the paved road pre-configured
• Documentation integrated into the catalogue so each service's docs are at its catalogue entry
• Operational visibility — links to dashboards, recent deployments, on-call rotation, incident history
• Scorecards measuring service compliance with platform standards (instrumentation, security, documentation, ownership)

The portal is the surface through which platform engineering presents itself to consumer teams. A weak portal makes the platform feel like an obstacle course; a strong portal makes the platform feel like a productivity multiplier.

The mistakes we keep seeing

Recurring failure patterns:

Platform team treated as infrastructure team. No product mindset, no roadmap, no user research, just a queue of tickets from consumer teams. The platform doesn't evolve; it accumulates one-off requests.

No opinion on the paved road. Trying to support every possible choice produces a platform with no clear path; consumer teams build their own paths, defeating the purpose.

Mandatory paved road that has friction. Forcing consumer teams onto a path that doesn't work for them produces resentment and shadow infrastructure. The road must be genuinely better than the alternatives.

Platform team disconnected from consumer teams. Quarterly steering committees and survey reports, but no working contact. The platform team learns about consumer friction late, if at all.

Platform stack that became its own legacy. The platform was built three years ago with technologies that have moved on; consumer teams want to use newer patterns; the platform team is reluctant to invest in modernising the platform itself. The platform becomes the bottleneck.

Documentation that is theoretical. The docs explain what the platform can do but not how to actually use it. Consumer teams cannot self-serve; they fall back to asking in chat. The platform team's support burden stays high.

What we recommend

For an enterprise standing up platform engineering:

1. Commit to the platform-as-a-product mindset from Day 1. Roadmap, user research, feedback loops, vision.
2. Hire or appoint a platform product manager. The role exists for a reason; without it, the platform tends to be infrastructure-led.
3. Define the service contract explicitly. What the platform provides, what consumer teams provide, how the boundary is policed.
4. Build the paved road for the most common service shape first. Get one shape excellent before adding variations.
5. Adopt a developer portal. Backstage if you have engineering capacity to operate it; commercial alternatives if not.

For an existing platform team that has accumulated friction:

1. Survey the consumer teams. Where is the platform actually getting in their way?
2. Identify the friction patterns. Some are platform-process problems; some are platform-technology problems; some are platform-staffing problems.
3. Pick the highest-friction pattern and address it as a discrete project, with the consumer teams who experience it as stakeholders.
4. Re-establish the service contract if it has drifted from reality.

Platform engineering is one of the highest-leverage investments available in a maturing enterprise engineering organisation. The platforms that produce real productivity gains are the ones built with product discipline by teams that take consumer experience seriously. The platforms that don't are the ones that produced documentation, dashboards, and disappointment.