clement13.net
Original photo: Ancienne caisse enregistreuse mécanique en laiton et acajou : compter ce que coûte et ce que rapporte
Description
Ancienne caisse enregistreuse mécanique en laiton et acajou : compter ce que coûte et ce que rapporte
Source
Alf van Beem · original page
Licence
CC0 Public domain
Original photo, unretouched. The background is a version of it stylised by the site.

Cost and Value Steering (Data FinOps)

Modern data platforms charge based on usage: compute capacity, storage, queries, per-user licenses. A data product can therefore see its cost grow without…

Guide≈ 7 min readCheckedCheck doneFacts, figures and references were checked against the sources cited in the page.Written with AI assistance; sources are cited at the bottom of the page. An error? Report it via clement13.net.Reading
On this page
  1. Why this theme
  2. What this theme measures
  3. The five levels
  4. Milestones by level
  5. Detailed reading by level
    1. 🟢 Level 1 — Opaque
    2. 🟢 Level 2 — Visible
    3. 🟡 Level 3 — Assigned
    4. 🟡 Level 4 — Steered
    5. 🔴 Level 5 — Arbitrated
  6. Partial achievement and rating
  7. Moving to the next level
  8. See also

Level: 🟢→🔴 · Theme code: FIN

Why this theme#

Modern data platforms charge based on usage: compute capacity, storage, queries, per-user licenses. A data product can therefore see its cost increase without anyone deciding anything: a model that gets bigger, a refresh changed from daily to hourly, a poorly written query on shared capacity. Conversely, poorly targeted savings can degrade service. FinOps (a discipline popularized by the FinOps Foundation) brings three ideas: make cost visible, assign it to who causes it, then optimize it in relation to value. This theme covers the financial management of the data product; detailed Power BI license and capacity costs are covered in BI matrix — Cost, Licensing, and Capacity, and expected value in VAL. Offers and pricing change quickly: always verify with the vendor (status 2026-10, not detailed here).

What this theme measures#

  • Axis: from cost ignorance to continuous value/cost trade-offs.
  • Key indicator: share of total cost assigned to a data product and an owner, and unit cost (per active user, per query, per refreshed TB).
  • Unit: % of assigned cost; cost per active user per month; budget/actual variance; value/cost ratio per product.

The five levels#

Level Short name Promise Typical indicator (orders of magnitude)
1 Opaque The bill arrives; no one knows what makes it up or why it varies. 0% of cost assigned
2 Visible Total cost is known and tracked by category (storage, compute, licenses, people). Monthly cost by major category
3 Assigned Each data product has a known cost and an owner accountable for it. ≥ 80% of cost assigned to a product
4 Steered Budgets, alerts, and optimizations are tracked; unit cost is compared to value; drifts are handled quickly. Budget variance < 10%; alert before overrun
5 Arbitrated Every dollar is arbitrated based on value: optimize, invest, or stop, continuously. Quarterly value/cost review; low-value products retired

Milestones by level#

ID Milestone Verifiable evidence
PD-FIN-1.1 The cost categories of a data project are listed (people, infrastructure, licenses, support). Dated category list.
PD-FIN-1.2 The platform bill is accessible to the team. Access to the billing tool or to a monthly export.
PD-FIN-1.3 An annual budget exists, even a rough one. Budget document.
PD-FIN-1.4 A data budget owner is designated. Name in the organization.
PD-FIN-2.1 Monthly cost by major category is tracked over time. Monthly table over ≥ 6 months.
PD-FIN-2.2 Significant variations (> 20%) are explained. Explanatory note for each variation.
PD-FIN-2.3 Unused resources (forgotten environments, obsolete tables) are identified. Inventory with a decision per line.
PD-FIN-2.4 People costs (development and maintenance time) are estimated by product. Workload estimate by product.
PD-FIN-3.1 The cost of each data product (compute, storage, licenses, time) is calculated. Cost table by product; written allocation method.
PD-FIN-3.2 A cost owner is designated per product and knows their level. Interview with three owners.
PD-FIN-3.3 A unit cost is defined (per active user, per refresh, per TB). Indicator calculated and published.
PD-FIN-3.4 Refresh and heavy-query costs are assigned to their authors or products. Measurement of compute chargeback.
PD-FIN-4.1 Budgets per product and overrun alerts are configured. Alert triggered and handled on a real case.
PD-FIN-4.2 A regular optimization cycle (monthly or quarterly review) produces measured savings. Report with quantified gains.
PD-FIN-4.3 Performance/cost trade-offs are documented (refresh frequency, aggregates, partitioning). Recorded decisions with before/after measurement.
PD-FIN-4.4 The value/cost ratio is calculated for key products (VAL). Value/cost table validated by a business third party.
PD-FIN-5.1 The portfolio is arbitrated based on value and cost: invest, maintain, optimize, stop. Product decisions over the last two quarters.
PD-FIN-5.2 Low-value products are retired and the savings confirmed. Retirement log and realized savings.
PD-FIN-5.3 12-month cost forecasting is based on usage and data volume growth. Forecast compared to actual each quarter.
PD-FIN-5.4 Optimization is integrated into development (cost estimated at design, checked in review). “Cost” section in design reviews.

Detailed reading by level#

🟢 Level 1 — Opaque#

  • Signs: “IT pays for it”; a bill increase is discovered at closing.
  • Gain: no monitoring effort.
  • Does not guarantee: staying within budget; you can't arbitrate what you can't see.
  • Difficulty: 1/5 · Effort: 1/5.

🟢 Level 2 — Visible#

  • Signs: a monthly table; variations are explained; forgotten resources are listed.
  • Gain: the first savings often come from a forgotten environment.
  • Does not guarantee: assignment or linkage to value.
  • Difficulty: 2/5 · Effort: 2/5.

🟡 Level 3 — Assigned#

  • Signs: a cost per product; an owner per product; a unit cost; heavy refreshes are assigned.
  • Gain: the discussion shifts from “it's too expensive” to “this product costs X for Y users.”
  • Does not guarantee: that cost is optimized (it is only understood).
  • Difficulty: 3/5 · Effort: 3/5.
🧪 Example

A semantic model refreshed every hour for 40 users, of whom 6 are active. Assigned cost: 3 days of compute equivalent per month on shared capacity. At level 3, the owner sees the number; at level 4, frequency is changed to daily after verifying usage does not require it (about 90% savings on this model's compute, order of magnitude); at level 5, the product is compared to its value and merged with another.

🟡 Level 4 — Steered#

  • Signs: budgets and alerts; monthly optimization review; recorded performance trade-offs; value/cost ratio calculated.
  • Gain: predictable spending; recurring savings without degrading service.
  • Does not guarantee: proper allocation: you can optimize very well a product that is no longer used.
  • Difficulty: 4/5 · Effort: 4/5.

🔴 Level 5 — Arbitrated#

  • Signs: quarterly value/cost review; confirmed retirements; reliable forecast; cost appears in every design review.
  • Gain: every platform dollar is justifiable.
  • Does not guarantee: value accuracy, always debatable (see VAL).
  • Difficulty: 5/5 · Effort: 4/5.

Partial achievement and rating#

Assess on the portfolio of the five most expensive products: a milestone is worth 1 if all satisfy it, 0.5 if most do, 0 otherwise. Savings milestones require a before/after measurement, not an estimate.

A “partial 5”: a quarterly arbitration led to two retirements (5.1 and 5.2 at 1), the 12-month forecast is done but differs from actual by 25% (5.3 at 0.5), cost is not yet a design review criterion (5.4 at 0).

⚠️ Pitfall

Saving at the expense of service: reducing the frequency of a refresh that a daily decision depends on. Symptom: savings observed, complaints. Remedy: every optimization consults the product owner and checks the SLA (EXP).

⚠️ Pitfall

Arbitrary assignment: splitting shared cost pro rata by number of users penalizes small useful products. Remedy: write the allocation rule and review it annually; a simple stable rule is better than illusory precision.

💡 Expert tip

The best indicator of a product to retire is cost per active user: a product with 40 registered users and 3 active users actually costs thirteen times more per head than its display suggests.

Moving to the next level#

Possible means (optional)

Transition Possible levers
1 → 2 Export the bill every month; list resources; appoint an owner.
2 → 3 Tag resources by product; choose an allocation rule; calculate unit cost.
3 → 4 Platform budgets and alerts; monthly review; cost dashboard by product (Project Metrics and Reporting).
4 → 5 Quarterly value/cost committee; expiration rule; cost criterion in design review.

Cross-cutting pitfalls: (1) False positive — 100% assigned cost but through an arbitrary rule. (2) Goodhart — minimizing cost pushes removal of test environments or controls (QUA). (3) Hidden cost — human cost (support, fixes) often exceeds platform cost; do not omit it.

🤖 AI

It summarizes a bill, spots cost anomalies, suggests query optimizations. It does not know business value and can recommend a saving that degrades a critical service; it also consumes capacity itself (tokens, compute): its cost belongs in the table, and its production uses must be budgeted.

See also#

✻ Written by Claude Sonnet 5.5