Platform Engineering: Building the Enterprise Developer Experience

Introduction

DevOps promised to unite development and operations, breaking down silos that slowed software delivery. A decade later, many enterprises find themselves in a new predicament: developers now bear operational responsibilities they lack time and expertise to handle well.

Platform engineering emerges as the evolution beyond DevOps chaos. Rather than expecting every development team to become infrastructure experts, platform engineering builds internal products—developer platforms—that abstract complexity while enabling self-service capability.

The Problem Platform Engineering Solves

DevOps at Scale Challenges

In theory, DevOps empowers developers to own their services end-to-end. In practice, at enterprise scale, this creates problems:

Cognitive Overload

Developers now need to understand:

• Container orchestration (Kubernetes)
• Cloud provider services (hundreds of them)
• Infrastructure as code (Terraform, CloudFormation)
• CI/CD pipelines
• Monitoring and observability
• Security and compliance requirements

This cognitive load slows development and increases errors.

Inconsistent Implementations

Without standards, each team builds differently:

• Different logging formats
• Different deployment approaches
• Different monitoring tools
• Different security postures

This inconsistency makes operations, security, and compliance harder across the organisation.

Duplicated Effort

Every team solves the same problems:

• How do we deploy to Kubernetes?
• How do we set up a database?
• How do we configure monitoring?

Multiply this across dozens or hundreds of teams, and enormous effort is spent reinventing wheels.

Governance Gaps

When anyone can do anything, ensuring compliance becomes challenging:

• Are security policies being followed?
• Are resources properly tagged?
• Are costs being tracked?
• Are approved patterns being used?

The Platform Engineering Solution

Platform engineering inverts the model. Instead of each team building everything, a platform team builds shared capabilities that other teams consume.

The platform team treats developers as customers, building products that make doing the right thing easy and the wrong thing hard.

Core Concepts

Internal Developer Platform (IDP)

An Internal Developer Platform is the product that platform engineering teams build. It provides:

Self-Service Capabilities Developers can provision what they need without tickets or waiting.

Golden Paths Opinionated, supported ways to accomplish common tasks.

Guardrails Automated enforcement of policies without blocking progress.

Abstractions Hiding unnecessary complexity while exposing necessary controls.

Platform as Product

The mental model matters: the platform is a product, developers are customers.

This means:

• Gathering requirements from developer feedback
• Prioritising features based on impact
• Measuring adoption and satisfaction
• Iterating based on usage patterns
• Documenting and supporting the platform

Platform teams that don’t think like product teams build platforms nobody uses.

Golden Paths

Golden paths are opinionated, end-to-end supported ways to accomplish goals. They’re not the only way—just the recommended way that the platform team maintains.

Example golden paths:

• “How to deploy a web application”
• “How to provision a PostgreSQL database”
• “How to set up monitoring for a service”

Benefits:

• Faster onboarding for new developers
• Consistent implementations across teams
• Reduced maintenance burden
• Easier security and compliance

Teams can deviate from golden paths, but they accept increased responsibility when they do.

Building an Internal Developer Platform

Capability Layers

A comprehensive IDP addresses multiple capability layers:

Infrastructure Provisioning

• Compute (containers, VMs, serverless)
• Databases and storage
• Networking and security groups
• Message queues and event buses

Application Lifecycle

• Code repositories and version control
• CI/CD pipelines
• Environment management
• Release and deployment

Observability

• Logging aggregation
• Metrics and dashboards
• Distributed tracing
• Alerting and on-call

Security and Compliance

• Identity and access management
• Secrets management
• Vulnerability scanning
• Policy enforcement

Developer Experience

• Service catalogues
• Documentation and guides
• Developer portals
• CLI tools and integrations

Technology Choices

Backstage (Spotify)

Open-source developer portal providing:

• Software catalogue
• Documentation aggregation
• Plugin architecture
• Tech Radar integration

Backstage has become a de facto standard for developer portals, with significant ecosystem momentum.

Kubernetes as Foundation

Most enterprise platforms build on Kubernetes:

• Container orchestration standardisation
• Rich ecosystem of tools and extensions
• Multi-cloud capability
• Strong community and support

However, Kubernetes complexity should be abstracted from developers—they should work with higher-level constructs.

Infrastructure as Code

Terraform or Pulumi for infrastructure definition:

• Version-controlled infrastructure
• Reproducible environments
• Drift detection
• Change management integration

Platform teams create modules that developers consume, abstracting provider details.

GitOps

Argo CD or Flux for deployment:

• Git as single source of truth
• Automated synchronisation
• Audit trail of all changes
• Easy rollback capabilities

Interface Design

How developers interact with the platform matters enormously.

Self-Service Portal

Web-based interface for common tasks:

• Browse service catalogue
• Provision new resources
• View documentation
• Monitor service health

Good for discovery and occasional tasks.

CLI Tools

Command-line interfaces for power users:

• Scriptable operations
• Integration with existing workflows
• Faster for experienced users
• Local development support

Essential for developer adoption.

API-First

Everything accessible via APIs:

• Enables automation
• Supports custom tooling
• Powers portal and CLI
• Integration with external systems

APIs are the platform’s foundation—other interfaces are built on top.

IDE Integration

Meeting developers where they work:

• VS Code extensions
• JetBrains plugins
• Language server support
• Debugging integration

Reduces context switching and accelerates workflows.

Implementation Strategy

Starting Point: Map Developer Journeys

Before building anything, understand current developer experience:

Day-1 Experience

• How long to set up development environment?
• What onboarding is required?
• How to access necessary systems?

Day-30 Experience

• How to deploy first feature?
• What obstacles slow progress?
• Where do developers get stuck?

Day-365 Experience

• What are ongoing pain points?
• What workarounds have developed?
• What creates friction with other teams?

Map these journeys to identify highest-impact improvements.

Phase 1: Foundation (Months 1-3)

Establish Team and Mandate

Platform engineering requires dedicated investment:

• Dedicated team (not side project)
• Executive sponsorship
• Clear mandate and scope
• Budget for tools and infrastructure

Build Core Infrastructure

Establish foundational capabilities:

• Kubernetes clusters (or serverless foundation)
• CI/CD pipelines
• Basic monitoring
• Source control and secrets management

First Golden Path

Choose one common developer journey and make it excellent:

• Deploy a web service
• Complete end-to-end support
• Documentation and examples
• Gather feedback and iterate

Success with one golden path builds credibility for expansion.

Phase 2: Expand (Months 4-9)

Additional Golden Paths

Based on developer needs, add paths for:

• Different application types (APIs, workers, scheduled jobs)
• Database provisioning
• Environment creation
• Monitoring setup

Developer Portal

Centralise discovery and documentation:

• Service catalogue
• Golden path documentation
• Team and ownership information
• Links to tools and dashboards

Consider Backstage or similar platforms.

Self-Service Capabilities

Reduce ticket-based provisioning:

• Infrastructure provisioning through portal/CLI
• Environment creation
• Access management
• Configuration management

Metrics and Feedback

Measure platform effectiveness:

• Time to first deployment (new developers)
• Deployment frequency
• Lead time for changes
• Developer satisfaction scores

Phase 3: Mature (Months 10+)

Advanced Capabilities

Sophisticated platform features:

• Cost visibility and allocation
• Compliance automation
• Advanced security scanning
• Performance optimisation tools

Governance Integration

Connect platform to enterprise governance:

• Policy as code
• Audit logging
• Compliance reporting
• Change management integration

Continuous Improvement

Ongoing refinement based on:

• Developer feedback
• Usage patterns
• Incident learnings
• Industry developments

Organisational Considerations

Team Structure

Dedicated Platform Team

Platform engineering requires dedicated staff:

• Full-time focus, not borrowed time
• Mix of infrastructure and development skills
• Product management capability
• Developer advocacy

Size Guidelines

Common ratios:

• Small orgs: 1 platform engineer per 10-15 developers
• Medium orgs: 1 per 15-25 developers
• Large orgs: 1 per 25-50 developers (efficiency improves with scale)

These vary based on platform scope and organisational complexity.

Skill Mix

Effective platform teams combine:

• Infrastructure/SRE background
• Software development expertise
• Product management
• Developer experience focus
• Security knowledge

Relationship with Other Teams

Development Teams (Customers)

Platform teams serve developers:

• Regular feedback collection
• Feature prioritisation based on impact
• Support and enablement
• Clear communication about changes

Security Team

Partner on security implementation:

• Security requirements in platform design
• Automated security controls
• Shared responsibility model
• Incident response integration

Operations/SRE

Collaborate on operational concerns:

• Monitoring and alerting standards
• Incident management integration
• Capacity planning
• Reliability engineering practices

Enterprise Architecture

Align on technical direction:

• Technology standards
• Integration patterns
• Reference architectures
• Governance requirements

Adoption Challenges

Resistance to Change

Developers accustomed to full autonomy may resist platform constraints:

• Demonstrate value before mandating adoption
• Start with willing teams
• Gather success stories
• Address concerns directly

Shadow IT

Teams may route around the platform:

• Understand why they’re going elsewhere
• Address gaps in platform capability
• Make the platform easier than alternatives
• Consider whether deviation is acceptable

Technical Debt

Existing systems may not fit platform patterns:

• Gradual migration strategies
• Support for legacy patterns during transition
• Clear timelines for deprecation
• Migration assistance and tooling

Measuring Success

Platform Metrics

Adoption Metrics

• Percentage of teams using platform
• Percentage of workloads on platform
• New projects starting on platform

Efficiency Metrics

• Time to first deployment
• Deployment frequency
• Lead time for changes
• Infrastructure provisioning time

Quality Metrics

• Change failure rate
• Mean time to recovery
• Security finding rate
• Compliance audit results

Satisfaction Metrics

• Developer satisfaction scores
• Net Promoter Score for platform
• Support ticket volume
• Feedback sentiment analysis

Business Impact

Connect platform investments to business outcomes:

• Faster time to market for features
• Reduced infrastructure costs
• Improved system reliability
• Better security posture
• Developer retention and productivity

Anti-Patterns to Avoid

Building a Ticket System

If developers still wait for tickets to be processed, you’ve built operations, not a platform. True platforms enable self-service.

Over-Abstracting

Hiding too much creates problems:

• Developers can’t debug issues
• Edge cases aren’t supported
• Platform becomes bottleneck

Find the right level of abstraction—hide unnecessary complexity, expose necessary controls.

Ignoring Developer Feedback

Platforms built without developer input fail:

• Features nobody wants
• Workflows that don’t match reality
• Low adoption and shadow IT

Continuous developer engagement is essential.

Mandating Without Value

Forcing platform adoption before demonstrating value breeds resentment:

• Prove value with early adopters
• Build success stories
• Address concerns before mandating
• Allow escape hatches for legitimate cases

Perfectionism

Waiting for the perfect platform delays value:

• Start with minimum viable platform
• Iterate based on feedback
• Ship improvements continuously
• Accept that platforms evolve

Conclusion

Platform engineering represents the maturation of DevOps for enterprise scale. Rather than expecting every developer to be an infrastructure expert, platform teams build products that abstract complexity while enabling capability.

Success requires treating the platform as a product, developers as customers, and continuous improvement as the norm. The organisations that build effective internal developer platforms will attract better talent, ship faster, and maintain higher quality than those that don’t.

The path forward: understand your developers’ journeys, build golden paths that make doing the right thing easy, and continuously improve based on feedback and metrics. The platform is never done—it evolves with your organisation’s needs.

Sources

1. Thoughtworks. (2024). Platform Engineering. Thoughtworks Technology Radar. https://www.thoughtworks.com/radar/techniques/platform-engineering
2. CNCF. (2024). Platforms White Paper. Cloud Native Computing Foundation. https://tag-app-delivery.cncf.io/whitepapers/platforms/
3. Gartner. (2024). Market Guide for Internal Developer Portals. Gartner Research. https://www.gartner.com/en/documents/internal-developer-portals
4. Spotify. (2024). Backstage Documentation. Spotify Open Source. https://backstage.io/docs/
5. Puppet. (2024). State of DevOps Report. Puppet. https://puppet.com/resources/state-of-devops-report

---

Strategic technology leadership for enterprise development organisations.