Building Internal Developer Platforms Teams Actually Use

A Reference Architecture and an Adoption Framework for Enterprise Platform Engineering

Siri Chandana Chava

Sr. Cloud Architect

Independent Researcher, Tennessee, USA

Abstract
Internal developer platforms have become one of the most common ways large organizations try to deliver software at scale, and yet a great many of these efforts never earn the adoption they were built for. The reason is rarely technical. Teams tend to treat a platform as an infrastructure project and declare it finished at launch, when in fact its success is decided afterward, by whether engineers choose to route their work through it instead of building infrastructure by hand, which they can always do without asking anyone. This paper takes that competition seriously and treats the platform as an internal product whose users are free to walk away. It offers four things. The first is a way to measure adoption in terms of outcomes rather than activity: golden path coverage, time to first deploy, the share of requests served without a human, and the failure rate of changes that ship along the supported path. The second is a reference architecture, organized as five loosely coupled planes and built deliberately as a thin layer over capabilities the organization already owns, with version-controlled configuration as the single source of truth. The third is a complete golden path workflow, shown with the actual configuration that implements it, that carries a service from creation to a running and observable state through reconciliation rather than manual steps. The fourth is a set of adoption tactics and a catalog of the failure patterns that quietly kill platforms. The paper closes by asking when a platform is worth building at all, and where the limits of the approach lie.

Keywords: Platform engineering; golden paths; Devops; self-service infrastructure; Enterprise; cognitive load; GitOps; software delivery