Skip to content
Notifications
Clear all

Thoughts on the new FinOps Foundation's FOCUS data model? Will it help?

3 Posts
3 Users
0 Reactions
5 Views
(@crm_trailblazer_7)
Estimable Member
Joined: 3 months ago
Posts: 129
Topic starter   [#3011]

I've been reviewing the FOCUS spec since the 0.5 release. My blunt take: it's a necessary foundation, but the real test is whether the major cloud providers and SaaS cost tools actually implement it fully.

The promise is clear: a single, standardized schema for cloud cost data. Right now, trying to normalize cost data from AWS, Azure, GCP, and a dozen SaaS tools is a nightmare of custom mapping. If FOCUS gets real adoption, it could finally make multi-cloud cost analysis and benchmarking reproducible. No more vendor demos with cherry-picked, non-comparable metrics.

Key things I'm watching:
* **Provider Commitment:** Will AWS Cost Explorer, Azure Cost Management, and GCP Billing Export actually offer native FOCUS exports, or will we still need third-party transformers?
* **Granularity:** Does the model handle the complex tagging hierarchies and credit schemes in enterprise deals?
* **Tooling:** Will this just become another layer where tools like CloudHealth or Flexera add a "FOCUS view," while their underlying proprietary data model remains unchanged?

The schema itself looks solid for core cost allocation. Example from the spec:

```json
{
"lineItemId": "12345",
"billingPeriodStart": "2023-10-01",
"billingPeriodEnd": "2023-10-31",
"service": "AmazonEC2",
"costAmount": 42.50,
"costCurrency": "USD",
"usageAmount": 744,
"usageUnit": "Hours",
"resourceTags": [
{"key": "Environment", "value": "Production"},
{"key": "CostCenter", "value": "Sales"}
]
}
```

My verdict: It will help *only if* it becomes the lowest common denominator everyone is forced to support. Otherwise, it's just another well-meaning standard that adds to the noise. I'm not trusting a vendor's "FOCUS-compatible" claim until I can validate the data pipeline myself.


Show me the query.


   
Quote
(@lucasm)
Eminent Member
Joined: 1 week ago
Posts: 22
 

Completely agree on provider commitment being the big blocker. It reminds me of when OpenMetrics launched for observability, the spec was great but adoption lagged for years until the big vendors baked it in.

Your point about tooling is key. I can easily see some vendors just building a FOCUS-compatible facade over their existing models, which defeats the purpose of true standardization. We'd get the same messy mapping problems, just shifted one layer over.

Hope the foundation can push for more than just a spec, maybe some certification program for tools? Otherwise, it's just another nice document to collect dust.


Keep iterating


   
ReplyQuote
(@migration_mentor)
Eminent Member
Joined: 3 months ago
Posts: 26
 

Spot on about the mapping nightmare. We just spent three months building a unified view for a client on AWS, GCP, and Snowflake, and I'd say 70% of the effort was just coercing different invoice line items into a common shape. The schema's handling of credits and negotiated discounts is the part I'm most skeptical about - enterprise deals have so many one-off riders and custom terms that I worry any standard model will either be too rigid or leave a massive "other adjustments" bucket that defeats the purpose.

That granularity question you raised is key. If the spec can't accurately represent, say, how an Azure commitment is applied across a hundred dev teams with different tag schemas, then teams will still need their own logic on top, and we're back to square one. Real adoption means the providers have to ingest and output in this model natively, not just offer another CSV export option.


Always have a rollback plan.


   
ReplyQuote