The Numbers Behind the Self-Service Business Case What the IDC White Paper Actually Says
Half of enterprise AI workloads already run on-premises or in private cloud. Nearly a third of organisations have repatriated a quarter or more of their workloads in the past year. If you're trying to fund a self-service platform, these are the numbers to put in front of the board.
Most architects I work with don't have a technology problem when it comes to self-service private cloud. They have a funding problem. The platform capability exists, the design is sound, and the business case gets stuck at the point where someone senior asks why this matters now rather than next year.
A new IDC white paper, sponsored by Broadcom and published in August, gives that conversation some external numbers. Worth reading if you're building a case, and worth knowing the shape of even if you aren't.
The Bottleneck It Names
The white paper's framing is one most platform teams will recognise immediately: ticket-driven infrastructure provisioning is the operational bottleneck standing between developers and AI delivery. Developers want runtime environments, databases, and AI frameworks on demand. Manual approval queues turn what should be a same-day request into a multi-week wait, and the software development lifecycle stretches accordingly.
That's not a new observation. What's useful is having it stated in a document you can hand to someone who controls budget, rather than having to make the argument from your own frustration.
The Numbers Worth Citing
• On average, 49.9% of organisations' AI workloads already run on-premises or in private cloud. Not planned. Running.
• Nearly 30% of organisations have repatriated more than a quarter of their total workloads from public cloud to on-premises infrastructure over the past twelve months.
• The top driver for that repatriation is the integration of AI capabilities that require on-premises execution, at 39.6%, followed by control over data security.
Two of those are more useful than they first appear. The repatriation figure gives you a directional argument this is happening at scale, not as an outlier. And the driver breakdown matters because it reframes repatriation as an AI-enablement decision rather than a cost-cutting one, which lands very differently in an executive conversation.
One disclosure worth making when you use these: the white paper is Broadcom-sponsored, which IDC discloses openly. That doesn't invalidate the research, but if you're putting it in front of a sceptical audience, say so before someone else does. A cited number you've disclosed the sponsorship on is stronger than one you haven't.
The Metrics Framework
The more practically useful part of the paper is the framework it gives for measuring a self-service platform once you've built it. It splits into three groups, which maps neatly onto how most boards actually think:
• Business metrics time-to-market, SDLC cost reduction, and application revenue. This is the language your CFO and business unit leaders use.
• Technology metrics security posture, DORA metrics, and reduced vulnerabilities. This is what your CISO and engineering leadership will ask for.
• People metrics platform adoption rates and time-to-first-commit, as evidence that developers are actually using the internal developer platform rather than routing around it.
That third group is the one most platform teams skip and the one that decides whether the platform gets a second round of funding. A self-service platform with excellent uptime and low adoption is a failed platform, and adoption metrics are the only thing that surfaces it early. Instrument for it from the start rather than trying to reconstruct the story a year in.
How This Connects to the Design Work
The business case and the design are the same conversation from different ends. The metrics above only get good numbers if the design decisions behind them were made deliberately the tenancy model, the quota approach, whether the catalog covers workloads that already exist rather than only new ones, and whether anyone walked the consumer experience before tenants did.
Which is to say: the paper helps you get funding, but the funding buys a platform that only delivers those metrics if the provider and consumer sides were both designed on purpose. Part 61 covers that side of it, and the design gaps checklist covers what commonly gets missed.
Sources
White paper reference: IDC White Paper, sponsored by Broadcom, Self-Service Private Cloud as the Engine for In-House AI and Application Innovation, #US54784226, July 2026.
Related coverage in this series: Part 61 on adopting and consuming VCF 9.1, and the Design Gaps Checklist on what commonly gets missed in the design.
