Want to become a partner or sponsor, click here to schedule time to talk with the team.

FinOps & Beyond is what engineering, finance, and IT leaders read to understand FinOps, and what it means for operating models, accountability, and spend decisions.

I'm deep into a large consulting and advisory engagement, and I've mentioned it here before. This week I'm going to show the work that I have been doing in the first 3 months of the engagement.

Most of what I write is the argument. The client already knew FinOps was the right thing to do, and they understood the basics. What they didn't have was a process, reporting, or governance to back it up.

So my first move is getting the data right. Reporting comes next, then we show people what they're looking at, and only then do we go after the waste that has piled up. I believe that order matters. Waste hunting on bad data just starts arguments with peers that isn’t necessary.

What I care about most is leaving a system in place that outlasts me. This issue is about building the context that makes that possible.

Two things to know up front. 1) The client is multi-cloud, but we're starting with the largest estate. 2) Annualized spend on that one footprint runs from the millions to the tens of millions.

Two Tracks, Running at the Same Time

We're doing two things in parallel. We're rolling out new tags, and we've started getting monthly cost data in FOCUS format so we can begin reporting outside of Azure Cost Management.

[Personal Note - I'm not a big fan of the native Azure cost tooling. It's good for getting your bearings, and past a certain size it doesn't do much more. That's why the data needed to leave it.]

On tags, we reviewed the ones already in use, agreed on a standard, and documented it. Then we agreed to manage the tag keys and values in a CSV in GitHub, so we can version it and other teams can reference it. One source of truth, and a link answers "is that tag allowed?" (Issue 29 covers why I like to treat tagging as configuration.)

The hardest part was applying the new tags to existing resources, which took real partnership with the client to make sure we get it right. We are not aiming for 100%. We are aiming for 80 to 90%, because chasing the last 10% is where tagging projects stall, and 80 to 90% is enough to report from.

The pipeline is not fancy. Azure Cost Management exports the data on a schedule, in FOCUS 1.2 format, to a storage blob container. Fabric and Power BI build the data model and the reports on the current state of the estate. A native export, a container, a model, a report. That's it.

What did this all show us?

Unused commitments. Reservations not utilized
One business unit absorbing every cost for resources with no good tag or organizational ownership. The client already knew this. They didn't know the size of it, and that gap is exactly what reporting is for.
Effective cost rising month over month. That's cost after discounts and commitments are applied, so it isn't a pricing change. It's usage.

Why This Is Enough

The point is you need to start somewhere. A monthly export and a report is not a mature practice. It will not catch an anomaly on a Tuesday. It will not chargeback anything.

It will tell you what the estate looks like right now, which most organizations can't say. It will show where tagging is working and where it isn't. And it builds muscle memory. People learn to look at the report, argue about it, and ask for fixes. Tagging stops being a policy document and becomes something the team checks each month and gets embarrassed by in a useful way.

You can't build that habit on a tool you're still evaluating. You build it on something you can turn on this week.

And a standard FOCUS export means that when the customer eventually does evaluate tools, the data they bring is already in a shape every serious vendor can read. That is a requirement worth capturing (issue 31).

Two Kinds of Tag Rule

Something to know about the tagging rules that we set and documented. Not every tag gets the same strictness.

Some tags have to match on key and on value. Environment is the example: prod, nonprod, and nothing else. If someone types "Production" or "prd," the report splits one thing into three and the numbers stop meaning anything. Those values come from the list we are maintaining in CSV as config, and this list is the only source.

Other tags only have to exist. Application name is the example. We need the key to be present on the resource, but the value is whatever that application is called, and there is no clean controlled list for it yet. Forcing an exact value on day one would have meant weeks of arguing about names before anything got tagged. (Note - we are including value formatting as a strict requirement, to avoid issues like camel case lettering.)

Presence first. Then correctness. The strictness of tags buy you clean grouping. The key-only tags buy you coverage now and a cleanup list for later. Both end up in the report, and the report is how you find which ones to tighten.

The Standard Lives in a File

The tagging standard is a versioned CSV and lives in a repo. The file contains the key exactly as it needs to be and the value as it needs to be for enforcement. Other teams reference the file instead of a wiki page or a slide, where most tagging documents go to die.

I said in issue 29 that tagging is configuration, and the programs that fail kept the wiki page instead of the pipeline. This is the small version of that. A file with a version number can be diffed, reviewed, and rolled back. When someone asks "is that tag allowed?" the answer is a link, not a meeting.

Policy Keeps It Honest

The last piece is Azure Policy. It applies the standard to existing and new subscriptions and resource groups so the tags stay consistent as the estate grows. Without it, you get a clean report in month one and a messier one by month four.

Our approach to the policy is to modify existing at the subscription level. Once modified, we will then implement as a deny. All following the customer’s change control process.

This is the part that makes the first two work. The report tells you the truth. The CSV tells everyone what the truth is supposed to look like. Policy narrows the gap while nobody is watching.

The Job

Three moves. (Always three moves … must be something about this.)

Move One.

Turn on a monthly cost export in your cloud, in FOCUS format (and parquet file type for compression) if your provider supports it, to storage you control. Don't build anything yet. Just start collecting.

Move Two.

Write your tagging standard as a file with a version number, and mark each tag as "must match" or "must exist." Resist the urge to make everything strict.

Move Three.

Put one report in front of the people who own the spend, every month, on the same day. It doesn't have to be good. It has to be on time.

You need to start somewhere. Most organizations wait for the right tool, the right taxonomy, and the right executive sponsor, and spend the year with none of the three and no data.

Written with the help of AI. All the ideas expressed are mine and mine alone.

Subscribe

FinOps Directory

Give Me Your Opinion