FOCUS has no row for your datacenter — and that's the real hybrid adoption blocker.

Why FOCUS goes quiet at the datacenter door

The FinOps Open Cost and Usage Specification did the hard, unglamorous work of agreeing on what a cost column means across providers. Before FOCUS, "cost" might be unblended, blended, amortized, or net-of-credits depending on which CSV you opened. FOCUS 1.1 fixes that with a defined set of columns — BilledCost, EffectiveCost, ListCost, ChargeCategory, ServiceCategory, ResourceId, and the rest — and a conformance program that the major clouds now publish against.

But every one of those columns assumes an upstream billing system that emitted a charge. That assumption holds for AWS, Azure, GCP, and OCI. It collapses for the three cost categories that define a hybrid estate: owned hardware that was capitalized years ago, colocation contracts billed as a flat monthly facility fee, and SaaS purchased as an annual seat block. None of these produce a per-resource, per-hour billing export. FOCUS has no opinion on them because there is no source file to ingest.

This is not a flaw in FOCUS. It is a scope boundary. The problem is that practitioners treat the boundary as if it were a wall — they normalize the cloud, ship a beautiful unified dashboard, and footnote the datacenter as "not yet in FOCUS." In a 60/40 cloud-to-on-prem estate, that footnote is 40% of the money.

The two failure modes, and why the second is worse

When teams do try to bring on-prem into their FOCUS dataset, they fail in one of two ways.

Failure mode one: omission. The datacenter simply never enters the dataset. Reports are technically clean and completely misleading. Any allocation that compares team A (cloud-heavy) to team B (on-prem-heavy) is structurally biased toward making the cloud team look expensive and the on-prem team look free. I have watched real chargeback disputes get resolved in the wrong direction for exactly this reason.

Failure mode two: lump-sum injection. Someone takes a $90,000 server purchase and writes it into a single month's BilledCost with a made-up ResourceId. This feels like progress and is actively destructive. Every month-over-month trend now has a $90,000 spike that no engineering decision caused. Every unit-economics metric built on monthly cost is wrong for that month. And because the row used BilledCost rather than an amortized EffectiveCost, it is semantically lying about what FOCUS says that column means.

Omission gives you an incomplete picture. Lump-sum injection gives you a picture that is confidently wrong, which is worse, because people act on it.

Use the columns the way the spec already uses them for commitments

Here is the insight that makes the whole problem tractable: FOCUS already solved amortization — for cloud commitments. When you buy a three-year Savings Plan or a Reserved Instance up front, a conformant export does not put the entire prepayment in one month's EffectiveCost. It records a ChargeCategory of "Purchase" for the cash event and then emits amortized "Usage" rows over the commitment term. You reuse that exact pattern for a capitalized server.

Map an owned asset to FOCUS columns like this:

Now your trended reports use EffectiveCost and see a smooth $2,500/month, exactly as they would for an amortized RI. Anyone who needs the cash view queries BilledCost and sees the $90,000 land once. The two columns tell two true stories instead of one false one. Add power, cooling, rack, and a loaded ops-labor allocation as additional amortized rows against the same ResourceId and you have a defensible fully-burdened unit cost — the method I laid out in the CapEx-to-OpEx piece, now expressed in spec-conformant columns.

Colocation: a facility fee is a shared cost, not a resource

Colo is its own shape. You do not own the building, but you pay a flat monthly fee for power, space, and cross-connects that covers many workloads at once. The mistake is treating the whole invoice as one undifferentiated line. A colo facility fee is a shared cost that needs a driver, the same way a Kubernetes cluster's cost needs a driver to split across namespaces.

Synthesize one FOCUS row per consuming workload, with EffectiveCost derived from an allocation key — power draw per rack unit is the most defensible, kW-hours is the gold standard if your PDUs are metered. Set ChargeCategory to "Usage", ServiceCategory to the closest match (often "Compute" or a custom facility category), and carry a x_AllocationBasis tag recording which driver you used. If two teams later dispute the split, the driver is the answer, not a meeting.

Flat-fee SaaS is a unit-economics problem in billing clothing

SaaS is the category most teams forget belongs in FOCUS at all — and it is often the fastest-growing line in a hybrid estate. A $480,000/year observability or data-platform contract arrives as one number. FOCUS wants daily or hourly granularity. So you synthesize it: divide the annual commitment into a daily EffectiveCost of roughly $1,315, set ChargeCategory to "Usage", and — this is the part that matters — attach a denominator.

A flat fee with no denominator is just a number you cannot manage. With one, it becomes a unit cost you can trend and challenge:

Once that unit cost exists in the same dataset as your cloud and on-prem rows, the renewal conversation changes. "We pay $480K for observability" invites a shrug. "We pay $0.63/GB ingested and 40% of that volume is debug logs from one service nobody reads" invites action. The whole point of dragging SaaS into FOCUS is to make flat fees behave like the variable costs they secretly are.

The one rule that keeps the dataset trustworthy

Every row you did not get from a real billing export must be flagged. Carry a custom x_CostSource column with values like cloud-export, synthesized-onprem, synthesized-colo, and synthesized-saas. FOCUS explicitly allows provider- and practitioner-defined columns prefixed with x_, so this is conformant, not a hack.

This flag does three jobs. It lets a skeptical finance partner reconcile only the synthesized rows against contracts and POs. It lets you quantify how much of your "unified" picture is measured versus modeled — a healthy hybrid dataset might be 70% export-derived and 30% synthesized, and you should know which. And it gives you a clean migration path: the day a colo provider or SaaS vendor finally ships a usage API, you swap the synthesized rows for real ones and the flag disappears for that source. Without the flag, you can never tell what is real, and the entire dataset inherits the trust level of its least defensible row.

FOCUS gave hybrid practitioners a shared language. It did not give us a parser for the half of the estate that never speaks in invoices. That part is on us — and done with discipline, it is a few hundred synthesized rows a month, not a platform project.

Subscribe to the Hybrid FinOps brief for practitioner methodology updates, including a FOCUS column-mapping worksheet for on-prem, colo, and SaaS spend.