Platform Engineering Maturity for CDEs
The CNCF maturity model applied to cloud development environments - investment, adoption, interfaces, operations and measurement - and what separates teams that get value from AI from teams that do not.
The Model, and Why It Fits This Problem
Five aspects, four levels, and no score at the end.
The Platform Engineering Maturity Model, published by the CNCF TAG App Delivery, describes platform capability along five aspects: Investment, Adoption, Interfaces, Operations and Measurement. Each runs through four levels named Provisional, Operational, Scalable and Optimizing. Deliberately, it does not produce a single number. You sit at different levels on different aspects, and the useful information is in the mismatch between them.
A cloud development environment is an unusually good fit for this framework because a CDE is not really a tool purchase, whatever the procurement paperwork says. It is an internal platform with users who have opinions, a support burden that never ends, and an availability requirement that grows quietly until the day nobody can work without it. Most CDE programs that stall do not stall on technology. They stall because the organization bought a product and never built the operating model underneath it, and the maturity model is a reasonable way to find that gap before it finds you.
| Aspect | 1. Provisional | 2. Operational | 3. Scalable | 4. Optimizing |
|---|---|---|---|---|
| Investment | Voluntary or temporary | Dedicated team | As product | Enabled ecosystem |
| Adoption | Erratic | Extrinsic push | Intrinsic pull | Participatory |
| Interfaces | Custom processes | Standard tooling | Self-service solutions | Integrated services |
| Operations | By request | Centrally tracked | Centrally enabled | Managed services |
| Measurement | Ad hoc | Consistent collection | Insights | Quantitative and qualitative |
Aspect and level names are the CNCF TAG App Delivery's own. The application to cloud development environments below is ours.
Each Aspect, Applied to a CDE
The questions that actually distinguish the levels in practice
Investment: who is actually paying for this?
The CNCF question is how staff and funds are allocated to platform capabilities. For a CDE the honest test is what happens when the person who championed it changes teams. Provisional looks like two enthusiastic engineers maintaining workspace templates in the margins of their real jobs, funded by nobody, with the cloud spend buried in some other team's budget. Operational means a named team with allocated headcount. Scalable means the CDE has a roadmap, a product owner, and a budget line of its own rather than a share of someone else's.
The distinction that matters most for CDEs specifically is between funding the compute and funding the people. Organizations routinely approve a substantial cloud bill for developer workspaces and then decline the two engineers needed to keep templates current, which produces the worst outcome available: expensive infrastructure that nobody maintains, degrading steadily until developers quietly go back to their laptops. If your CDE has a five-figure monthly cloud spend and zero dedicated headcount, you are at level one on Investment regardless of how much money is involved. See cost analysis for modeling both halves.
Adoption: mandated, or chosen?
The CNCF progression runs Erratic, then Extrinsic push, then Intrinsic pull, then Participatory - and that sequence is the single most useful thing in the model for CDE programs, because it names the trap. Extrinsic push is a mandate. Somebody senior decreed that all development moves to the cloud, and compliance is enforced rather than earned. It is a real level, it is above erratic, and organizations that stop there produce measurable resentment and a thriving shadow estate of local development that nobody admits to.
Intrinsic pull means developers choose the platform because it is genuinely better than the alternative - faster to start, more compute, no dependency archaeology on a Monday morning. Participatory means the developers using it are contributing templates and improvements back. The diagnostic is simple and uncomfortable: if you removed the mandate tomorrow, what fraction would stay? An organization that cannot answer that has not measured adoption, only compliance. A mandate is sometimes necessary - regulated environments where source code cannot sit on a laptop have no choice - but it should be treated as scaffolding, not as an achievement.
Interfaces: self-service, or a ticket queue?
This is where CDE programs most often reveal themselves. The level-one pattern is custom processes: every new workspace type is a bespoke conversation, and getting a GPU or a different base image means finding the right person. Level two is standard tooling - a repository of templates, consistent, but still requiring someone to run something on your behalf. Level three, self-service solutions, is the one that changes developer behavior: a developer can provision, resize, and destroy an environment without asking permission or waiting on anyone.
The test is latency, not documentation. If the wiki says self-service but the GPU workspace still needs approval from a capacity planning team, the interface is a ticket queue wearing a portal. Level four, integrated services, means the CDE is not a separate destination at all - it is reachable from the developer portal, the repository, and the CI system, and provisioning a review environment for a pull request is the same action as provisioning a development one. Related reading: developer portals and ephemeral environments.
Operations: a product, or somebody's side project?
The CNCF framing asks how platform capabilities are planned, prioritized, developed and maintained. For CDEs the sharpest question is about failure. When the control plane is down at nine in the morning, who is paged, and does that person have an agreed response time? A CDE crosses a threshold the moment developers cannot work without it, and most organizations cross that threshold without noticing. Before it, an outage is an inconvenience. After it, an outage stops the entire engineering organization, and the platform has become production infrastructure whether or not anyone has updated the runbooks.
Practical markers of the upper levels: a documented on-call rotation, upgrade paths tested before they are applied, image and template updates on a schedule rather than on discovery of a vulnerability, capacity headroom for the Monday morning surge, and a tested answer for what happens when a region is unavailable. See high availability, disaster recovery, and runbooks.
Measurement: does anyone know whether it helped?
This is the weakest aspect in most CDE programs, and the one where the model earns its keep. Level one is ad hoc - somebody asks how it is going and gets anecdotes. Level two is consistent collection, which for a CDE means workspace start times, utilization, cost per developer, and failure rates gathered on a schedule. Level three turns that into insight: knowing that the ninety-fifth percentile start time is four minutes and that this is the reason a particular team is not using the platform.
Level four is quantitative and qualitative together, which is the part teams skip. Utilization data will tell you that a team stopped using the platform. It will not tell you why, and the why is almost always something no dashboard captures - a debugger that does not attach, a latency that makes the editor feel wrong, a workflow that assumed a local file system. DevEx metrics covers instrumenting both halves without it turning into surveillance.
Why Maturity Became the AI Question
Two independent research programs pointing at the same variable
Platform maturity separates AI outcomes
Puppet by Perforce, State of DevOps Report: Platform Engineering Edition 2026, published July 2026. 820 technology professionals surveyed worldwide.
- 73 percent of mature platform engineering organizations say platform maturity was a critical or significant factor in their AI success, against 44 percent of less mature organizations
- 66 percent are applying AI in infrastructure workflows, but only 31 percent report fully autonomous operations
- Organizations with formal governance report 94 percent trust in AI, against 51 percent among those relying on ad hoc approaches
Disclosure: Puppet sells infrastructure automation, and the finding that platform maturity matters is commercially convenient for them. Note also that "mature" here is self-assessed by respondents, so the comparison is between organizations that believe they are mature and organizations that do not.
Read the reportAI amplifies what is already there
DORA / Google Cloud, State of AI-assisted Software Development, September 2025. Nearly 5,000 respondents.
The report's central claim: "AI's primary role is as an amplifier, magnifying an organization's existing strengths and weaknesses." It found a positive relationship between AI adoption and delivery throughput, and a continuing negative relationship with delivery stability where robust control systems are absent.
Read alongside the Puppet figures, the two independent programs converge on an awkward implication: the variable that predicts whether AI helps you is not which model or tool you chose. It is the quality of the delivery system the AI output flows through. That is a platform maturity question, and it is the reason this framework is worth the hour it takes to work through honestly.
Read the reportThe CDE-specific consequence is concrete. Agents generate more change, more concurrently, and they need somewhere isolated to run it. An organization at level one on Interfaces cannot give an agent a workspace without a human in the loop, which removes most of the point. An organization at level one on Operations discovers that agent workloads have made the control plane load-bearing at exactly the moment nobody owns it. The honest reading of the productivity evidence is that maturity is the multiplier, and its sign can be negative.
What Maturity Models Cannot Do
Stated plainly, because the failure mode is predictable
A maturity model is a self-assessment instrument, not a measurement
Nothing in this framework is measured. Every level is a judgment made by people with a stake in the answer, usually the people who built the platform, frequently in the same week they need to justify next year's budget. A team can honestly place itself at level three on every aspect and deliver nothing developers value. The model surfaces questions worth asking; it does not answer them, and it produces no evidence.
Level four is not the goal
A forty-person engineering organization has no business at Operations level four. Managed services with a dedicated on-call rotation for developer workspaces is the right answer at a scale most companies never reach. Aim at the level your size and risk actually justify, then stop.
The gaps matter more than the scores
Level three Interfaces with level one Measurement is the most common and most dangerous shape: a genuinely good self-service platform that nobody can defend when the budget is questioned, because nobody collected the evidence that it worked.
It becomes a target
The moment levels appear in a performance conversation, the assessment stops describing reality. If you run this exercise, keep it separate from anybody's objectives, and let the team assess itself honestly rather than aspirationally.
It says nothing about whether developers like it
Every aspect can be satisfied by a platform that developers tolerate rather than choose. Adoption is the only aspect that even gestures at this, and it can be satisfied by a mandate. Ask the users directly; the model will not do it for you.
It is not a sequence
You do not have to advance every aspect in lockstep, and trying to is how a platform team spends a year on internal process while the actual complaint - a four-minute workspace start time - goes unaddressed.
The evidence for it is correlational
Mature organizations report better AI outcomes. They also tend to be larger, better funded, and better run in general. No published study isolates maturity as the cause, and the surveys reporting the association are published by vendors who sell maturity.
Running the Assessment Without Wasting a Day
Four steps, and one rule about who is in the room
1. Place yourself on all five, quickly
An hour, not a quarter. The first instinct is usually right, and precision here is false anyway. Write one sentence of evidence beside each level you claim; if you cannot, you are a level lower than you think.
2. Have developers assess it separately
Run the same five questions past a handful of users who do not work on the platform, without showing them the team's answers. Where the two assessments disagree is the most valuable output of the whole exercise, and it is usually Interfaces.
3. Fix the lowest aspect, not the easiest
Platform teams gravitate toward the aspect they enjoy, which is usually Interfaces, because it is engineering. The binding constraint is more often Investment or Measurement, and neither is fixed with code.
4. Reassess on a fixed cadence
Twice a year is enough. The value is in the delta and in what you predicted last time, not in the absolute placement - which is why writing down the evidence in step one matters more than the level you assign.
One organizational rule is worth stating explicitly. If the answer to "who funds this platform" is nobody in particular, no amount of work on the other four aspects will hold. Investment is the aspect that decays silently: a platform can run for a year on the goodwill of two engineers and look healthy right up until one of them leaves. If you are early enough that this assessment is a planning exercise rather than an audit, team structure and pilot programs cover getting the funding question settled before the platform is load-bearing, and build vs buy covers the case where the honest conclusion is that you should not be operating this yourself at all.
Related Reading
Working the individual aspects up a level
Platform Engineering
The discipline underneath the model, and what running a platform as a product actually requires
Build vs Buy
What your Investment and Operations levels imply about whether you should be self-hosting at all
The AI Productivity Paradox
The evidence behind the amplifier finding, read honestly and with its limits stated
DevEx Metrics
Moving the Measurement aspect off level one with numbers and interviews together
Team Structure
The staffing shapes behind the Investment aspect, and who owns the platform when nobody volunteers
Developer Productivity Engineering
Treating feedback speed as an engineering problem once the platform is operationally sound
Risk Management
What changes once the CDE becomes production infrastructure that engineering cannot work without
Migration
Sequencing the move so Adoption reaches intrinsic pull instead of stalling at a mandate
Sources and Citations
Every figure on this site with its publisher, year, and link, including the ones we decided not to use