Vocabulary for Platform Engineers

Platform engineering has emerged as one of the most important disciplines in modern software organisations. Platform teams build the internal tools, workflows, and infrastructure that enable product developers to ship faster and more reliably. The field has its own vocabulary — much of it borrowed from Team Topologies, DevOps, and developer experience (DevEx) practice.

This guide covers the essential terms you need to participate in platform engineering conversations and write clearly about platform work.

Core Concepts

Internal Developer Platform (IDP)

An Internal Developer Platform (IDP) is a self-service layer that abstracts away infrastructure complexity and allows developers to provision, deploy, and manage their applications without needing deep infrastructure knowledge.

“Our IDP lets developers spin up a new service in under ten minutes, including the CI/CD pipeline, monitoring, and database provisioning.”

“We’re building out the IDP incrementally — starting with deployment automation, then moving to self-service database creation.”

Note: IDP is sometimes confused with Internal Developer Portal (also IDP). The portal is the user interface for the platform; the platform is the broader set of capabilities.

Developer Portal

A developer portal is the web interface through which developers interact with the internal platform — discovering services, provisioning resources, reading documentation, and monitoring their applications.

“The developer portal centralises everything a developer needs: service catalog, runbooks, deployment status, and cost dashboards.”

“We use Backstage as the foundation for our developer portal.”

Self-Service

Self-service means developers can complete infrastructure and tooling tasks without opening a ticket or waiting for a platform team member to act manually.

“The goal of platform engineering is to make infrastructure self-service — developers should never need to ask us to provision a database.”

Paths and Standards

Golden Path

A golden path (sometimes called a paved road) is the opinionated, supported, and recommended way to build and deploy services within an organisation. It is not a mandate — but it is the path the platform team makes easiest to follow.

“Our golden path uses TypeScript, GitHub Actions, and PostgreSQL on RDS. Teams can deviate, but they own the maintenance of anything off the path.”

“We invest heavily in the golden path so that following best practices is the path of least resistance.”

Paved Road

Paved road is an alternative term for golden path, emphasising that the recommended approach is smooth and well-maintained:

“If you stay on the paved road, the platform handles observability, scaling, and security patching automatically.”

Service Catalog

A service catalog is a registry of all internal services — showing ownership, documentation, dependencies, and operational status.

“The service catalog shows that the payments service is owned by Team Bravo, runs on two instances, and has a 99.95% availability SLO.”

Team Topologies Vocabulary

Team Topologies is a widely-referenced book and framework for organising engineering teams. Its vocabulary has become common in platform engineering discussions.

Stream-Aligned Team

A stream-aligned team is focused on delivering value along a single product or user journey. Most product teams are stream-aligned.

“The checkout team is stream-aligned — they own the entire customer checkout experience end to end.”

Platform Team

A platform team provides internal services to stream-aligned teams to reduce their cognitive load.

“The platform team provides deployment tooling, observability stacks, and developer environments so that product teams don’t have to build these themselves.”

Enabling Team

An enabling team helps other teams adopt new capabilities or practices — coaching rather than doing.

“The security enabling team ran workshops to help product teams implement threat modelling in their design process.”

Cognitive Load

Cognitive load is the mental effort required to work effectively. Platform engineering aims to reduce the cognitive load on product teams.

“Every infrastructure decision a product developer has to make is cognitive load we’ve failed to absorb as a platform team.”

Developer Experience (DevEx)

Developer Experience (DevEx or DX)

Developer experience is the overall quality of the experience developers have when building, testing, deploying, and operating software within an organisation.

“We measure developer experience through quarterly surveys and track metrics like time-to-first-commit for new engineers.”

Shift Left

Shift left means moving a practice (typically testing or security) earlier in the development lifecycle.

“Our platform shifts security left by running SAST scans automatically on every pull request, rather than waiting for a security review before release.”

DORA Metrics

DORA metrics (from the DevOps Research and Assessment programme) are four key measures of software delivery performance:

• Deployment Frequency — how often you deploy to production
• Lead Time for Changes — time from code commit to production
• Change Failure Rate — percentage of deployments that cause incidents
• Time to Restore Service — how quickly you recover from failures

“We track DORA metrics quarterly. Our deployment frequency is now 12 times per day, up from twice per week before the platform investment.”

Practical Phrases for Platform Engineers

• “The goal of this feature is to reduce the cognitive load on stream-aligned teams.”
• “We’ve defined the golden path for deploying a new service — documentation is in the portal.”
• “Self-service database provisioning is available via the IDP — no ticket required.”
• “We’re measuring the impact of this change on DORA metrics.”
• “Teams that deviate from the paved road own the operational consequences of that decision.”

Platform engineering vocabulary is evolving quickly, but the terms above are stable enough to serve as a foundation. Using them precisely will help you write clearer design documents, speak credibly in architecture reviews, and communicate the value of platform work to leadership.