The FinOps Open Cost and Usage Specification (FOCUS) is a groundbreaking initiative to define a common format for billing data that empowers organizations to better understand cost and usage patterns and optimize spending and performance regardless of which cloud, SaaS, or on-premises services you use. As the new “language” of FinOps, FOCUS enables practitioners to collaborate more efficiently and effectively with peers throughout the organization and even maximize transferability and onboarding for new team members, getting people up and running quicker.

FOCUS adoption has been wonderful to see. In the 5 months since FOCUS 1.0 was announced, we’ve seen FOCUS adoption jump to 30% of all cost and usage exports! And with the many benefits, it’s no surprise that people are jumping in to learn about what FOCUS is and how it can help them streamline their FinOps practice. If you’re not in that group, then here’s your chance to dip your toes in the water…

Over the coming months, I will walk you through each column, explain how to use them, and help you transition your knowledge of the historical schemas (e.g., actual and amortized cost details). 80% of what I cover will be cloud agnostic, so feel free to share this series with those working on AWS, GCP, or OCI cloud platforms, as the constructs will be the same for those FOCUS datasets as well. And if they manage multiple clouds, even better, because all 3 providers joined us by implementing FOCUS earlier this year.

But let’s get into the details…

What is FOCUS?

I already gave you the “fluffy” description of what FOCUS is. But if I break it down to the bare essentials:

FOCUS is an open specification that defines the
columns, types, and values for cloud, SaaS, and on-premises billing data.

And the next question many people have is, “So, FOCUS is only for cross-cloud scenarios?” Not at all! FOCUS is for everyone! I can’t stress that enough. Many organizations using Azure will have transitioned from one account type to another. Some even have active EA, CSP, and MCA contracts. But even if you only have one account type, there’s still immense value from leveraging the shared knowledge across the industry, across cloud providers and tools, for how to manage, optimize, and maximize ROI of your cloud investments. Standardizing on a common “language” brings many benefits from onboarding and execution to collaboration and beyond.

And if all that isn’t enough, I can tell you that FOCUS is the best version of our cost data today. It’s smaller, cleaner, and more complete. To learn more, see FOCUS benefits.

How does FOCUS differ from native schemas?

You’ll find many similarities between FOCUS and native cost details schemas, but I do want to call out 2 big differences.

First, FOCUS covers both actual (“billed”) and amortized (“effective”) cost in one dataset. But that doesn’t mean it’s bigger. FOCUS data is actually 30% smaller than actual and amortized cost data combined. If you’re processing both actual and amortized cost data today, this alone is one nice benefit as you’ll save on both storage and compute costs with a smaller dataset.

Second, FOCUS puts all costs in the billing currency. If you’re using an Enterprise Agreement account, this is exactly what you’re used to, so that’s no change. If you’re using a Microsoft Customer Agreement or Microsoft Partner Agreement account outside of the United States, then you may be familiar with the fact that some accounts may be “priced” in one currency (e.g., US Dollar) and billed in another (e.g., Euro, Yen, GB Pounds). This offers some additional pricing stability as currency fluctuations happen over time but does require a bit of extra thought as you evaluate prices in one currency and two costs to represent each currency. Either way, FOCUS aligns everything to the billing currency for simplicity. This just means prices in a FOCUS dataset may not be the same currency as your native schema dataset, depending on the billing address.

How is FOCUS smaller than native datasets?

If you were to count, you’d find 79% of Microsoft’s FOCUS dataset is the same or comparable columns to native columns and 21% are new concepts to clarify FOCUS datasets or cover new scenarios, typically aligned with the future direction of FOCUS. While a few native columns were removed, each row of FOCUS data is generally larger than the native schema equivalent. The difference comes in when you evaluate the rows you’ll see in actual and amortized datasets together.

Actual cost includes all usage, purchases, and refunds – everything you’re billed for.

Amortized cost includes everything except commitment discount purchases and refunds. Instead, the cost of commitment discount purchases is amortized or spread across each of the resources that used the commitment discount, which simplifies chargeback reporting immensely.

If you analyze actual and amortized datasets, you’ll likely find that 99% of the rows are the same in both – with the exception of cost being 0 or not for the SKUs covered by commitment discounts. But you can’t answer all questions with just one of the datasets, so your only option is to export both datasets and use them independently. This results in a huge duplication of data that you end up paying additional storage and compute costs for.

FOCUS removes the duplication by giving you everything from the amortized cost dataset plus the commitment discount purchases and refunds. The key is creating separate BilledCost (actual) and EffectiveCost (amortized) columns to differentiate between what’s billed on an invoice and what is amortized for chargeback purposes.

Altogether, this results in about 30% smaller data size compared to actual and amortized cost datasets together.

What are the main concepts in FOCUS?

As this is an introduction to the series, I’d like you to be able to walk away with a high-level picture of the conceptual “entities” that make up a FOCUS dataset:

Services are the highest-level offerings providers make available. Services are comprised of one or more resource types.

Resources are deployed by engineers interested in using a specific capability of the service. Resources use SKUs to perform distinct functions of the service.

SKUs represent billable goods and services. They can represent something tangible, like a software license, or something intangible, like compute services or other core functionality needed to accomplish tasks. SKUs have specific, agreed-upon prices defined by the billing contract or amended with commitment discounts.

Billing contracts outline the relationship between the provider and the organization, including the agreed upon (“contracted”) unit price for each SKU, which may include credits and negotiated discounts.

Commitment discounts represent an additional agreement where the organization “commits” to consuming a specific amount of certain SKUs within a predetermined period (e.g., hourly) over an agreed-upon term (e.g., 1 year). In return, the provider offers a reduced unit price for the SKUs; however, any unused amount within each period will be charged for the duration of the commitment term.

Charges represent the logging of SKU usage and purchases at the agreed-upon (contracted) price point after factoring in all discounts. Charges are the rows in the FOCUS dataset.

These concepts are no doubt familiar to most. FOCUS isn’t defining anything new, but instead attempts to establish common terms to get everyone on the same page, regardless of what cloud, SaaS, on-premises, or other tools and services they use.

What next?

By now, you should have a basic understanding of what FOCUS is, how it differs at a high level from the native cost details schema, and an idea of the conceptual entities that make up FOCUS. Over the coming weeks and months, I’ll introduce you to a set of columns and concepts to help you become more proficient with FOCUS data. And if you’re new to cloud cost and usage data, well, your timing couldn’t be any better to get started on the right foot!

Next, I’ll explain the 4 different cost columns defined in FOCUS 1.0 as well as the corresponding extended columns included in the Microsoft FOCUS dataset. These are arguably the most important columns in the dataset, given the primary purpose is to understand the charges included in the invoice.

Stay tuned!