Last month I argued that most enterprises have funded the agent layer properly and left the delivery tier underneath it unowned, and that the gap is structural rather than technical. By delivery tier I mean everything between the CMS and the customer: the environments, the pipelines, and the infrastructure that serves every request. I ended by saying I wanted to put a number on what leaving it unowned costs. That piece is here if you missed it: Everyone Bought the Agent. Who Owns the Infrastructure?
The cost of an unowned delivery tier is not a future risk. It is current spend, running through your P&L this quarter, and in most organizations it is larger than the CMS license that took three months to negotiate.
It does not appear as a line item because nobody issues an invoice for it. It gets paid in engineering weeks, in manual review cycles, in incident hours, and in customer journeys that never completed. A CIO cannot see it on a cost report. A CFO cannot see it in a contract. So it never gets approved, challenged or defended. It just gets absorbed, every month, by whoever is standing closest to it.
The industry data shows a version of this. Flexera's 2026 State of the Cloud Report puts self-reported waste on IaaS and PaaS at 29%, the first increase in five years, from a survey of more than 750 cloud decision makers. Waste and unowned are not the same thing, but in practice they usually describe the same situation: capacity somebody provisioned, nobody is accountable for, and everybody keeps paying for.
When a board asks what an organization's digital platform costs, the answer usually comes back as a small set of clean numbers. CMS license. Cloud consumption. The SI contract, if one is still running. Those are easy to produce because somebody issues an invoice for them every month. Those numbers also get governed. They are benchmarked, challenged by procurement, renegotiated at renewal and reported to the board. Attention follows the invoice.
The rest of the cost has no invoice. It sits inside salaries, inside elapsed time, and inside outcomes that never happened. That does not make it smaller. It makes it unmanaged, because nobody decides about a cost they cannot see.
Let me put rough numbers on it. A platform team of eight engineers, with a third of their week focused on delivery tier upkeep instead of improvement. That is between two and three full-time engineers, permanently, before a single security review or incident. Annualized at a loaded cost, in most enterprises that is already past what the CMS costs for the year.
Nobody is hiding this. It simply never gets totaled, because no report anywhere in the business is titled "What it costs us to run the delivery tier". The people who can see it are engineering managers, and most of them stopped raising it a while ago, because nothing changed when they did.
Across the enterprise stacks I have looked at in the past year, the unrecorded spend collects in four places, roughly in order of size:
Only the first of those gets discussed as a resourcing issue rather than an infrastructure cost. The other three are usually not costed at all.
I am not going to hand you an industry benchmark, because in my experience the only number that shifts a budget conversation is the one from your own delivery tier. When I do this with a customer we are after a single figure: what the tier costs to run for a year. It goes on one page next to the annual CMS license, because the license is a number the business already accepts, and standing the running cost beside it is what gets it the same attention.
Three questions get me close enough, and the answers usually take an afternoon.
I multiply the first answer by a loaded day rate, annualize it, and set it beside the license. In most organizations I have done this with, the running cost is the larger of the two.
It will not be precise, and it does not need to be. It needs to be defensible enough to support one specific ask: a budget line and a named owner for the delivery tier, funded as its own commitment, not out of whatever is left after feature work. Without a number, that request competes with a roadmap item and loses. With one, it becomes a comparison between money already being spent without control and the same money spent with an owner and an SLA attached.
None of this is caused by anyone being careless. It is caused by sequencing.
The CMS gets selected on features, on roadmap, on the demo. Infrastructure gets treated as an implementation detail to be resolved afterwards, usually by the SI, usually inside a fixed scope that ends at go live. Ownership of running the tier then falls to whoever is standing closest when the project closes.
By that point you have spent the only leverage you had. During a selection you have competing vendors, an open scope, a budget that has not been allocated yet, and a procurement function whose job is to turn expectations into written commitments. That is the window in which you can get an SLA that covers the delivery tier, not the CMS alone, get the running cost priced into the business case instead of discovered eighteen months later, and get a name attached to it.
After signature, none of that is available. The contract is set, the architecture is set, and the ownership conversation happens internally with no money attached and nobody across the table to ask. Every one of the four costs above starts accruing from that day, quietly, for the life of the platform.
The infrastructure decision was always going to be made. Leaving it until last is what makes it expensive.
Managed infrastructure is starting to appear on vendor price lists alongside the CMS itself. Sitecore added Dataweavers Arc to its commercial line up earlier this year, and it is not the only vendor moving in that direction.
When infrastructure appears on the price list, it enters the proposal, the business case and the procurement process at the same time as the CMS. It gets an owner, a budget line and a signed commitment while you still have leverage.
That holds whoever you buy from, and it holds if you decide to own and resource the tier yourself. The decision has not changed. Only the timing has improved.
Plenty of the organizations we work with have a Microsoft Azure Consumption Commitment (MACC) they are not on track to use. That is money already promised to Microsoft and not yet turned into anything.
If the delivery tier runs in your own Azure tenant and the offer is sold through the Azure Marketplace, that spend can draw down against the commitment rather than opening a new line of funding. The specifics are worth checking with your Microsoft account team, because eligibility turns on how the offer is listed and purchased.
Funding the tier is otherwise treated as new money, which is the hardest kind to get approved. Committed money pointed at something that already needs doing, in an environment you already govern, is a far easier case to put to a CFO, and another reason to have the conversation during selection.
If you are running a selection now, or renewing, these five belong in the proposal, not in implementation.
That list is what we built Dataweavers to do. It holds regardless of who runs the tier for you, and it is a fair test to put to us or to anyone else.
Two questions test whether any of it has been priced, and they are for the meeting where the proposal gets a decision, not the technical evaluation.
If the second is hard to answer, that is the finding. You are not deciding whether to spend money on the delivery tier. You are deciding whether to spend it deliberately, with an owner and an SLA attached, or to keep spending it in engineering time, review cycles and lost conversions where nobody has to approve it.
Next month I want to get into what good looks like operationally, because once the tier has an owner and a budget the next argument is about what you should reasonably expect it to do.
Every cost in this piece exists because a specific accountability is missing, and the quickest way to find which one is to lay the stack out and mark who signs for each layer.
We put together a reference that does exactly that: the layers of an enterprise delivery tier, what the SI, the CMS vendor, the cloud provider and your own team are each genuinely accountable for, and where the gaps usually sit. If you are trying to size that cost, the gaps on that map are where the unrecorded spend is going.
Who Owns What: A Responsibility Map for the Enterprise Delivery Tier