Core point Showback does not fail because the spreadsheet is ugly. It fails when app teams, finance, and platform owners cannot explain why a number landed where it did. Once trust is gone, every discussion turns into a debate about the math instead of a decision about what to fix. |
High-level outline
Why trust matters more than perfect precision in shared cost allocation
Three failure modes that make a showback model collapse under scrutiny
What a trusted allocation model needs before finance ever publishes it
The MODEL checklist for reviewing shared service rules
A practical Azure example for platform, app, and overhead cost buckets
What to fix in the next 30 days if your current model is already under fire
The real problem
Most teams talk about showback as if it were a reporting exercise. It is not. It is a trust exercise dressed like a report. If the people paying the bill cannot follow the path from raw cost to final allocation, the model will get challenged every month, and every challenge slows down action.
That matters because shared Azure costs are messy by default. Hub networking, firewalls, shared observability, backup platforms, container platforms, identity tooling, and security services often sit outside a single application boundary. Someone has to decide how those costs are split. The moment that decision feels arbitrary, the showback model stops being a management tool and starts being background noise.
The goal is not perfect precision. The goal is a model that is fair enough to defend, simple enough to run, and transparent enough that engineers and finance can both trust it.
Failure mode 1: the mystery bucket
This is the classic move. A large pool of shared cost gets dropped into a line called platform, common services, or overhead. The report technically allocates the money, but nobody can answer the next question: what is actually inside that bucket?
When teams cannot see the cost sources, they assume the model is hiding waste, double-counting, or pushing someone else’s bill into their lane. That assumption spreads fast, especially when the bucket includes a mix of hub networking, backup, monitoring, support services, and one-off exceptions.
Fix it by breaking shared spend into named service families with plain-language definitions. Platform network is one family. Observability is another. Security tooling is another. Backup and recovery is another. Give every family an owner, a source scope, and a rule for how it gets split. If a cost pool is too broad to explain in one minute, it is too broad to allocate cleanly.
Failure mode 2: the driver has no causal logic
A model can be transparent and still be weak. This happens when the driver used to split cost has little connection to how the service is actually consumed. Equal split across subscriptions is the usual offender. It is easy to run, but it rarely reflects reality.
If a central Log Analytics workspace is charged back evenly across ten apps, the heavy talkers get a discount, and the quiet apps get punished. If shared firewall cost is split by headcount instead of connected environments or traffic class, teams will question the logic the second they compare the bill to their real footprint.
Good drivers do not need to be perfect, but they need causal logic. Monitoring cost should usually follow data volume, table ownership, or workspace consumption patterns. Backup cost should usually follow protected instances, storage consumed, or policy tier. Shared platform cost might follow namespace use, node pool consumption, or app count only if those choices mirror operational load. The key question is simple: can a reasonable engineer hear the rule and say, yes, that makes sense?
Failure mode 3: no versioning, no review, no evidence
Even a decent model drifts. New services appear. Apps move. Shared platforms get re-architected. Tags improve or fall apart. Cost pools shift between subscriptions. If the allocation logic changes without versioning, review dates, and a visible owner, trust erodes again.
This is where many showback efforts quietly break. The first version gets built during a cleanup push. It works for a quarter. Then exceptions pile up, teams change, and nobody is sure whether the current report still follows the original rules.
Treat the allocation model like an operational control, not a one-time spreadsheet. Version the rules. Record why each rule exists. Keep the source query or export path. Define a review cadence. Require named approval when a driver changes. That does two things: it keeps the model honest, and it gives you evidence when someone challenges the output.