At a Glance
Centralized platform teams eventually become bottlenecks as adoption scales, revealing that the real constraint is the delivery model, not the tooling.
Leading organizations are decentralizing execution while embedding governance into tooling, enabling teams to move fast without losing control.
Success depends on treating platform engineering as an operating model, separating ownership from control, and designing for scale beyond central teams.
Decentralized infrastructure delivery is emerging as the next phase of platform engineering maturity. While most enterprises have invested in internal developer platforms and Infrastructure as Code, the real challenge now is scaling ownership without creating new bottlenecks.
The shift is not about tools, but about redefining how infrastructure is delivered, governed, and owned across teams.
The Real Problem Isn’t Terraform. It’s the Delivery Model.
What makes the Adidas case study instructive isn’t the technology stack — it’s the clarity with which they identified that the bottleneck was structural, not technical. Raw Terraform, left to scale across dozens of teams, produces remote state sprawl, inconsistent provider configurations, boilerplate duplication, and a tight coupling between code and deployment that makes every change a cross-team coordination exercise.
Their response was to separate infrastructure into three layers: reusable modules as building blocks, stacks as deployable business-aligned units for development and staging, and consumption stacks as lightweight production configurations that reference approved, versioned stacks without containing any Terraform logic themselves. This separation is the key design decision. It lets development move at full speed in non-production environments while keeping production deployments stable, predictable, and auditable.
Autonomy Without Alignment Is Just Fragmentation
The harder lesson in any decentralization effort is that distributing ownership without distributing guardrails creates worse problems than centralization ever did. Platform drift, inconsistent quality, fragmented tooling, and ungoverned access are all downstream consequences of autonomy without structure.
The Adidas team addressed this by embedding governance into the developer workflow itself rather than layering it on top as a review process. A custom CLI wrapping Terraform enforces naming standards, tagging policies, provider versions, and resource constraints automatically. Functional roles — developers, consumers, and framework owners — are defined independently of team membership, so permissions and responsibilities scale with the model rather than depending on who happens to sit on the platform team. And critically, all deployments flow through CI/CD pipelines, making the repository the single source of truth for what’s actually running in production.
What This Means for Enterprise Platform Strategy
The Adidas example reflects a broader shift that Gartner, the CNCF, and the DORA research have all been pointing toward: platform engineering is moving from a team function to an operating model. The question is no longer whether you have a platform team. It’s whether your delivery model can sustain growth without creating a new centralized bottleneck.
For engineering leaders evaluating their own infrastructure delivery model, the signal from this case is clear. Centralization is the right starting point — it builds the standards, the modules, and the institutional knowledge that a decentralized model later depends on. But treating centralization as the permanent state is a mistake. At a certain scale, the platform team must shift from executing infrastructure changes to maintaining the system that enables others to execute them safely.
The organizations that navigate this transition well share three traits: they separate what can be changed from who can change it, they embed governance into tooling rather than process, and they treat decentralization as an organizational design problem — not a Terraform problem. The tools are table stakes. The operating model is the differentiator.
