The FOCUS Problem Nobody Talks About (Until It Breaks Your Data)

Every FinOps capability eventually hits the same wall: billing data.

No matter what you are trying to accomplish, everything starts (and often ends) with cost and usage data. If that data is messy, inconsistent, or ambiguous, everything built on top of it suffers.

That’s exactly why FOCUS (FinOps Open Cost and Usage Specification) is so appealing. Its promise is bold and compelling:

Normalize cost and usage data across providers, reduce analysis effort, and let practitioners focus on higher-value work.

As someone starting a FinOps practice, that sounded like exactly what I needed.

---

Why I chose FOCUS (even with mostly AWS spend)

Even though most of our cloud spend is on AWS, I deliberately chose FOCUS because it checks all the boxes an engineer cares about:

• open source

• backed by the FinOps Foundation

• multi-cloud by design

But the real reason is more fundamental.

One of the core principles of FinOps is that teams need to collaborate. And collaboration starts with communication. You can’t collaborate effectively if everyone uses different terms to describe the same thing.

FOCUS solves this by providing a shared, defined, evolving lexicon.

---

The overwhelming part nobody warns you about

Here’s the reality check.

FOCUS 1.2 comes with 57 columns.

Fifty-seven.

Mandatory, conditional, recommended. Nullable, non-nullable. Relationships between columns. Constraints that only apply if another column is populated…

When you’re already trying to learn FinOps concepts, align stakeholders, and understand cloud billing… this is a lot to ingest.

To make sense of it, I created a FOCUS 1.2 diagram for myself. It turned out to be incredibly useful, so I’m sharing it.

---

The problem starts when theory meets reality

On paper, FOCUS is great.

The real problems appear when you leave the clean world of specifications and enter the muddy reality of data providers.

Not every provider can (or wants to) fully comply with the spec.

To their credit, the FinOps Foundation is aware of this. That’s why FOCUS-conformant data providers are required to publish:

• a Conformance Gap Report: Must include the FOCUS version, total deviation count, and known industry limitations (if any)

• a Column Mapping Reference: Must cover all FOCUS columns populated

In theory, this gives practitioners full transparency.

In practice… not always.

---

Let’s get our hands dirty

One of the features I was most excited about in FOCUS is the Service hierarchy.

As shown in the image, each ServiceName belongs exactly to one ServiceCategory and each ServiceSubcategory belongs to exactly one ServiceCategory.. This allows classifications like:

Compute → EC2 → Virtual Machines

That’s incredibly powerful for analysis and reporting.

So I did what any practitioner would do. I checked FOCUS 1.2 with AWS columns and confirmed ServiceSubcategory was listed. Connected to Athena and wrote my query.

And then…

Nothing.
Not a single value for ServiceSubcategory. Across the entire dataset.

---

“But the column exists… so what’s happening?”

According to the spec, ServiceSubcategory MUST NOT be null

But when I inspected the data more closely, I found the trick:

• the column isn’t null

• it’s populated with empty strings

Which “violates” FOCUS string handling guidelines:

Empty strings SHOULD NOT be used in non-nullable string columns.

What made this more confusing:

• ServiceSubcategory is RECOMMENDED, but it appears in the Column Mapping Reference, which MUST cover all FOCUS columns populated

• There’s no mention of this behavior in FOCUS 1.2 with AWS columns conformance gaps

If AWS doesn’t populate the column meaningfully, it should not be listed as populated or be clearly documented as a deviation,

The same issue appears again with ResourceType. It MUST NOT be null when ResourceId is not null, so AWS decided to populate with empty strings,

Again, undocumented.

---

Why this actually matters

Now imagine this at scale.

• different providers

• different FOCUS versions

• different (and sometimes undocumented) deviations

• columns that technically “exist” but aren’t usable

As a practitioner, this means:

• broken assumptions

• misleading queries

• fragile dashboards

• lost trust in the data

None of this shows up in the happy path diagrams.

---

Conclusion

Even with these gaps, this isn’t a dealbreaker for me.

FOCUS is still a huge step forward compared to working directly with raw, provider-specific billing data. As someone just starting a FinOps practice, having a shared structure and a common language already makes a big difference.

For FOCUS to really work in practice, I’m starting to realize that practitioners need to push data generators to:

• implement RECOMMENDED columns more consistently

• be clear when columns are technically populated but not practically usable

• provide clearer and more complete conformance documentation, as described in Publishing FOCUS Conformance Information

As a beginner, I rely heavily on this documentation to understand how the data actually behaves, not just how it’s supposed to behave according to the spec.

---

Have you run into undocumented FOCUS gaps in your datasets?