You're on IBM Cloudability: It Gives Finance and Engineering One View of Cloud Spend. Data Workers Owns Whether the Pipelines That Spend Runs Are Right
Running IBM Cloudability for showback and forecasting? Keep it. Data Workers keeps the data pipelines behind your spend and your Business Mappings right, ties Snowflake credits to dbt models and sends every fix to its owner, behind approvals.
Your FinOps team runs IBM Cloudability, from Apptio, an IBM company. Billing exports from AWS, Azure and Google Cloud land there next to Snowflake and Databricks connectors and AI usage by model and token type. Business Mappings turn tags, account IDs and services into your own dimensions: cost center, business unit, product. Cost Sharing spreads the shared lines, and showback goes out on a schedule finance trusts. Budgets & Forecasts, now with Intelligent Forecasting, give engineering leads a number to plan against. Rightsizing finds the savings, Savings Automation runs the commitment program on autopilot, and IBM Kubecost covers the clusters. Cloudability gives finance and engineering one view of cloud spend. Data Workers owns whether the data pipelines underneath are right, behind approvals, including the ones that feed Cloudability its own mappings. The two jobs meet whenever a chargeback is only as good as the table behind it.
Key takeaways
- •Cloudability keeps its job. Business Mappings, showback, Budgets & Forecasts, anomaly detection, rightsizing, Savings Automation and IBM Kubecost stay with your FinOps team. Data Workers works with Cloudability from day one.
- •Data Workers keeps the data pipelines right. It checks keys, nulls and row counts in Snowflake, watches the baselines your team records, and reads the dbt manifest and orchestrator runs on ADF, Airflow, Dagster and Prefect.
- •It traces the readers before anyone reruns. dbt manifest lineage and context-graph notes show which models, Cloudability feeds and Power BI reports sit on a table that went wrong.
- •Fixes go to owners, behind approvals. dbt changes are drafted as diffs for the model owner, and reruns are queued through your orchestrator after a named person approves.
- •Every fix leaves a receipt with the checks, the lineage, the approver and, where the fix touches cost, the Snowflake credits per dbt model.
- •Start with a pilot on one domain, read-only first, and climb from L0 manual toward L4 autonomous.
IBM Cloudability is the one view of cloud spend. Data Workers keeps the pipelines behind it right.
Cloudability answers what the cloud costs, who owns each dollar and what next quarter looks like. Data Workers answers whether the data under that answer is right, who reads it and who signs off on the repair. They become one question when a showback depends on a table a pipeline builds.
Teams with hundreds of accounts often generate Business Mapping statements from their own systems rather than hand-edit rules after every reorg. Cloudability's API exposes /v3/business-mappings for that, and its rules engine works like a case statement: each billing line runs through the statements in order, and once a rule matches, processing stops.
Here is one such company. Workday holds the org: cost centers and the managers who own them. An Azure Data Factory pipeline, pl_workday_daily, copies the Workday cost center report into Snowflake raw_workday at 01:30. A dbt Core project builds snap_cost_centers (a dbt snapshot with the check strategy), then dim_cloud_account_owner, which maps about 900 AWS accounts and Azure subscriptions to the cost center of their owning manager, then bm_cost_center_statements, one Business Mapping statement per account. At 05:00 a second ADF pipeline, pl_cloudability_bm_sync, pushes that model to the Cost Center dimension in Cloudability through its API. FinOps publishes the weekly showback in Power BI on Fridays. The team baselines statements per run with monitor_metrics and has recorded the sync, the Cloudability dimension and the Power BI report as context-graph notes. This is an illustrative example.
| Time | System | What happens |
|---|---|---|
| Wed 20:00 | Workday | The Q4 reorg goes live. Cost center CC-4410, Data Platform, is retired and split into CC-5120 and CC-5130. The same managers now own the new cost centers. Workday's report stops listing inactive cost centers |
| Thu 01:30 | Azure Data Factory | pl_workday_daily copies the report into Snowflake. CC-4410 is simply absent |
| 02:00 | dbt Core and Snowflake | The nightly build runs. The snapshot uses the default hard_deletes='ignore', so CC-4410 stays marked current. Its manager now owns two current cost centers, and the 31 accounts that manager owns get two rows each in dim_cloud_account_owner. Every dbt test that exists passes |
| 05:00 | ADF and Cloudability | pl_cloudability_bm_sync writes 931 statements to the Cost Center dimension, sorted by cost center code. For the 31 accounts, the CC-4410 statement comes first, so it wins |
| 05:20 | Snowflake | Data Workers' scheduled run_quality_check on dim_cloud_account_owner, scoped to the key column cloud_account_id, fails uniqueness: its distinct ratio drops to 0.967, below the 0.99 threshold. The monitor_metrics baseline on statements per run flags 931 against a steady 900 |
| 05:24 | dbt | trace_cross_platform_lineage walks the manifest from dim_cloud_account_owner back through the snapshot snap_cost_centers to the source raw_workday.cost_centers |
| 05:28 | dbt, ADF, Cloudability, Power BI | blast_radius_analysis returns bm_cost_center_statements and mrt_cloud_budget_owner from the manifest; the context-graph notes add the 05:00 sync into Cloudability's Cost Center dimension and Friday's Power BI showback |
| 05:30 | Microsoft Teams | A card goes to the data-platform channel for the model owner, the FinOps admin and the HR data owner: the failed check, the lineage and a query to run that lists cloud_account_id values with more than one current owner row |
| 07:40 | Snowflake and Cloudability | The analytics engineer runs the query: 31 accounts, one manager, CC-4410 and a CC-51xx code for each. No model changed this week, so the cause is in the snapshot, not the logic. The FinOps admin confirms in Cloudability that October spend for those accounts sits on CC-4410 and the new cost centers show none |
| 07:55 | GitHub and Spellbook | Data Workers drafts the fix as a diff for the model owner: set hard_deletes='invalidate' on the snapshot so a cost center that leaves Workday closes, add a dbt unique test on cloud_account_id with error severity so the statements model can't build on duplicates, and a one-time update the owner runs to close the CC-4410 row. The approval request goes to the analytics engineering lead by email |
| 08:30 | Spellbook and Snowflake | The lead approves in Spellbook. The model owner runs the one-time update and merges the diff |
| 08:35 | Azure Data Factory | Data Workers queues a run of the team's pl_cost_center_refresh pipeline with trigger_adf_pipeline, as approved: the dbt build for the three models, then the sync activity |
| 09:10 | Snowflake and Cloudability | The run completes. run_quality_check passes uniqueness and nulls on dim_cloud_account_owner; statements are back at 900. Cloudability applies the updated statements to October's billing data on its own, so no reprocessing request is needed; September was mapped before the reorg and stays as it was |
| Fri 09:00 | Power BI and Spellbook | FinOps publishes the showback with October month to date on CC-5120 and CC-5130. The receipt holds the failed and passing checks, the lineage, the diff, the approver, the one-time update the owner ran, the ADF run, and the Snowflake credits of the rebuild traced through the dbt query tags |
Nothing in Cloudability was wrong. The rules engine did what its documentation says: first match wins, and changes apply to the current month automatically. The dbt snapshot did what its default says too. The gap sat between them, in a pipeline nobody watched as a cost system, and it would have put a quarter's first showback on a cost center that no longer exists. Data Workers caught it from a key check, traced it through the snapshot, named the owners, drafted the fix and queued the rerun after approval. The context graph keeps the note that this model feeds Cloudability, for the next reorg.
| Job | What IBM Cloudability does | What Data Workers does |
|---|---|---|
| Cost visibility | Billing from every cloud plus Snowflake, Databricks and AI usage, in one view | Reads AWS Cost Explorer (monthly cost by service) and Snowflake credits per query and dbt model, for the receipt |
| Allocation | Business Mappings, Cost Sharing and showback by your dimensions | Keeps the tables and pipelines that feed those mappings right, with key and null checks and the baselines your team records |
| Planning | Budgets & Forecasts and Intelligent Forecasting | Makes sure the data owners behind each budget line come from a correct table |
| Savings | Rightsizing, Commitment-Based Discounts and Savings Automation | Checks the data side of a change your team ships, and drafts the data-side fix |
| Impact | Shows which team owns the spend | Traces models, feeds and reports through the dbt manifest and context-graph notes |
| Recovery | Re-applies mappings to the current month; reprocessing for history | Queues the rerun through your orchestrator after approval, then re-checks |
| The proof | Reports, dashboards and the showback finance signs | A receipt per fix: checks, lineage, approver, run and credits per model |
Why doesn't IBM Cloudability just do this itself?
Because Cloudability is built around the bill. Its unit of work is a cost line item: vendor, account, tag, business dimension. It maps every line at ingestion, forecasts from history and recommends what to buy or resize. Where it acts, it acts on cloud commitments and resources, through Savings Automation and Kubecost, and its Governance checks run inside HCP Terraform before deploy. That focus is right. A FinOps platform that also edited the dbt models and pipelines it reads from would carry the liability for every number those pipelines feed, across systems it doesn't own.
Knowing that dim_cloud_account_owner comes from a dbt snapshot that keeps deleted rows current by default is data-engineering knowledge. Fixing it crosses Workday, ADF, Snowflake, dbt and the Cloudability feed, each with its own owner. A FinOps platform is measured on allocated, forecast and saved dollars; the data team is measured on the number being right. Data Workers is built for that second job, on top of the FinOps platform you already run.
Every tool owns a slice. Data Workers covers the whole lifecycle
IBM Cloudability owns its slice: one view of cloud spend for showback and forecasting. Each point tool adds another console, contract and handoff. Data Workers covers the whole lifecycle with one context, one approval flow and one audit trail.
| Stage | Data Workers | IBM Cloudability | Why we scored it this way |
|---|---|---|---|
| Catalog & Context | 9 | 5 | Business Mappings turn tags, accounts and services into the company's own dimensions: rich cost context. Data Workers joins tables, lineage, runs, owners, quality and usage in one graph. |
| Analytics & Insights | 8 | 7 | Dashboards, reports, unit economics and Conversational Insights (preview) explain spend to finance and engineering. Data Workers answers questions about the data itself and checks the numbers behind them. |
| Data Quality | 8 | 1 | Cloudability measures what resources cost, not whether rows are right. Data Workers checks keys, nulls, row counts and baselines and takes failures to the cause. |
| Observability & Incidents | 8.5 | 4 | Anomaly detection and budgets flag spend that moves, with Jira, PagerDuty and Datadog hooks. Data Workers detects, diagnoses and fixes data incidents across systems, with a receipt for each. |
| Pipelines & Ingestion | 8.5 | 1 | Cloudability prices the infrastructure pipelines run on. Data Workers reads orchestrator runs, queues reruns after approval and reviews pipeline changes before they merge. |
| Schema & Migration | 8 | 1 | Cloudability sees accounts, resources and tags, not schemas or models. Data Workers reviews model changes from the dbt manifest, assesses impact and plans migrations in approved waves. |
| Governance & Access | 8.5 | 4 | Cloudability Governance (public preview since Nov 2025) checks cost policy in HCP Terraform before deploy; roles govern who sees which spend. Data Workers dry-runs grants, applies approved Unity Catalog changes and drafts the rest for owners. |
| Security & Privacy | 8 | 4 | Cloudability reads billing exports and vendor connectors with credentials you grant. Data Workers keeps a receipt for every data change and proposes masking for its owner. |
| Cost / FinOps | 8 | 9.5 | Cloudability's home stage: allocation, showback, budgets and forecasts, rightsizing, Savings Automation for commitments and token spend by model. Data Workers ties Snowflake credits to dbt models and checks the data behind a chargeback. |
| MLOps & Models | 7.5 | 2 | Cloudability tracks AI and GPU spend, not model or feature health. Data Workers keeps the training and feature data under models healthy. |
How IBM Cloudability and Data Workers work together
Your people stay in Cloudability, in Teams and in Claude, Claude Code or Cursor. Spellbook Data Catalog (in preview) is where the data team looks: each finding, diff and approver, with approval requests in Slack or email and alert cards in Teams. Underneath, Data Context Wizard keeps one governed context graph, the Data-Agents Swarm (20+ specialist agents) does the work, and the Autonomous Data-Conductor runs each fix behind per-domain guardrails.
What Cloudability keeps. Business Mappings and Cost Sharing, showback, Budgets & Forecasts, anomaly detection, rightsizing, Commitment-Based Discounts, Savings Automation, Cloudability Governance and IBM Kubecost, plus the newer AI work: Conversational Insights (preview), and token spend visibility feeding IBM Apptio AI Value & ROI (announced in public preview on Aug 6, 2026, with general availability planned for Q3 2026). Data Workers connects to Cloudability over its API today. Feeds your team writes into Cloudability, like the mapping sync above, stay your pipelines; Data Workers checks the data they send.
What Data Workers reads. AWS Cost Explorer natively: monthly cost by service, with the forecast. With your Snowflake credentials the Cost Savings & Data Cleanup agent reads warehouse metering and per-query attribution and decodes the dbt node from the query tag, so credits trace to the dbt model wherever dbt sets query tags: the layer below Cloudability's warehouse line. On BigQuery it sums recent job bytes into an account-level total. Each action's model cost is computed from its tokens. Around the bill it reads the dbt manifest, Snowflake checks through run_quality_check, monitor_metrics baselines and orchestrator runs on ADF, Airflow, Dagster and Prefect, among 50+ connectors. Agents get one governed view through explain_table, trace_cross_platform_lineage and blast_radius_analysis. Workday and Power BI connect over their APIs or MCP servers today.
What Data Workers changes. Business Mappings, budgets and commitments stay with your FinOps team. dbt changes and warehouse settings are drafted as diffs for their owners; reruns are queued through your orchestrator after a named person approves. One-time corrections, like closing a snapshot row, are drafted for the owner to run; deletes are always the owner's. Your data stays in your systems; the hosted Conductor sees workflow metadata only.
Setup. Clone the open-source repository and add start-agent.sh entries to your client config, as the client setup docs show.
// Example: .mcp.json for Claude Code
{
"mcpServers": {
"dw-quality": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-quality"]
},
"dw-context-catalog": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-context-catalog"]
},
"dw-incidents": {
"command": "/path/to/dataworkers-claw-community/start-agent.sh",
"args": ["dw-incidents"]
}
}
}List the tools with /mcp in Claude Code, then ask "Which models feed our Cloudability Cost Center mapping, and do any accounts have two owners today?"
One mapping feed, L0 to L4. The ladder is set per domain, so the FinOps data domain can sit at a different level from marketing data.
- •L0 manual. Someone notices a cost center with no spend after showback goes out.
- •L1 observe. Data Workers checks the mapping tables after each build, reports failures with lineage, and logs what each action would have needed.
- •L2 propose. It drafts the dbt fix and the rerun; the owner approves first.
- •L3 act reversibly. For proven classes, such as rerunning the mapping refresh once its keys check out, it queues the step, re-checks and records.
- •L4 autonomous. For a scoped class in one domain, it runs the loop end to end and posts the receipt.
More on safety, approvals, who owns the agents, autonomy levels, where your data goes, integrations, Data Workers on AWS and on Snowflake. Siblings: Ternary, CloudZero, Vantage, and for this incident's data side Azure Data Factory, Power BI and Microsoft Teams.
What changes for your team
FinOps teams lose time on the data under the bill: the mapping feed that broke after a reorg, the week spent reconciling whose spend is whose. With Data Workers, those jobs run on autopilot at the level you set.
- •Cloud spend. Snowflake credits per dbt model and the AWS Cost Explorer line by service sit on the receipt, next to the checks.
- •Incidents. A broken mapping feed arrives traced, with its readers and owners named.
- •Data quality. Owner and mapping tables are checked on keys and nulls after every build, against the baselines your team records.
- •Audits. Each fix links the approver, the checks and the run, so the showback has a paper trail.
- •Migrations. Each wave is planned with its checks; the owner signs off before it closes.
- •Access. Grants a fix needs are dry-run first and approved by a named owner.
The FinOps lead guide and the platform engineer guide cover the people side.
Keep IBM Cloudability, or consolidate?
Keep IBM Cloudability if you love it; Data Workers works with it from day one. Many teams consolidate once Data Workers runs that slice too.
Nothing here replaces Cloudability's allocation, forecasting or Savings Automation. What teams consolidate is the glue: hand-written checks on the tables that feed mappings, spreadsheet reconciliations after a reorg, and email threads about who approved a finance pipeline change. Building it yourself? Calling an API or MCP server is the easy part; the checks, approvals and receipts are the work. See also FinOps for data platforms and FinOps for data engineering.
The case for your CFO
The outcome: every chargeback in Cloudability rests on data that is checked, traced and owned, so showback lands on the right cost center the first time, even after a reorg.
The risk story is plain. Data Workers changes nothing in Cloudability. It checks the data, traces the readers and drafts each fix for its owner; reruns are queued through your orchestrator after a named person approves. Unanswered requests expire and escalate, never auto-grant. No agent can promote its own work. An org-wide stop halts all autonomous dispatch. The agents run in your infrastructure with your credentials; your data stays in your systems, and the hosted Conductor sees workflow metadata only. Zero migration.
Why now: FinOps is moving onto AI spend and AI-driven forecasts, and both are only as good as the mappings and tables underneath, built by pipelines that change every week. The first win is one domain, read-only, with checks on the tables that feed Cloudability. The ROI guide shows the math, the model cost guide covers what the agents cost to run, and the flat-fee explainer covers pricing without a usage meter.
The sentence to repeat upstairs: "Cloudability tells us who spends what; Data Workers makes sure the data behind that answer is right, with an approver and a receipt for every fix."
Getting started
Start with a pilot. Pick the domain where a wrong chargeback costs the most, such as the tables behind Cloudability showback, connect Data Workers read-only to Snowflake, AWS Cost Explorer, the dbt project and your orchestrator, add key checks and a statements-per-run baseline, and let them run through one showback cycle before turning on the first fix class. The pilot path and plans are on the pricing page, and the pilot is credited in full against the first year.
FAQ
Does Data Workers connect to IBM Cloudability? Over Cloudability's API today. The feeds your team writes into Cloudability stay your pipelines; Data Workers checks the data they carry and queues their reruns after approval.
Does Data Workers replace Cloudability's allocation or forecasting? No. Business Mappings, Cost Sharing, showback and Budgets & Forecasts stay in Cloudability. Data Workers keeps the pipelines underneath right, including the tables your mappings come from.
Does Data Workers buy commitments or rightsize resources? That is Cloudability's job, through Savings Automation, rightsizing and Kubecost. Data Workers drafts data-side changes, such as a dbt model or a warehouse setting, for owners to apply.
Cloudability already ingests our Snowflake costs. What does Data Workers add? Cloudability shows Snowflake cost by warehouse and its tags. Data Workers traces the credits to the query and dbt model behind them where dbt sets query tags, and checks the data those models produce.
How does Data Workers notice a broken mapping feed? From key and null checks with run_quality_check on Snowflake (uniqueness is measured as the distinct ratio of id columns) and the baselines your team records with monitor_metrics, such as statements generated per run. Your dbt tests keep running as before.
What about Databricks and BigQuery costs? Cloudability covers both in its spend view. Data Workers sums recent BigQuery job bytes into an account total; its per-model attribution is for Snowflake, built on dbt query tags.
Sources
- •IBM Cloudability product page, https://www.apptio.com/products/cloudability/ (checked Oct 3, 2026)
- •IBM Cloudability Savings Automation, https://www.apptio.com/products/cloudability-savings-automation/ (checked Oct 3, 2026)
- •Apptio, next-generation FinOps solutions: Cloudability Governance in public preview, Kubecost 3.0 generally available (Nov 4, 2025), https://www.apptio.com/company/news/press-releases/apptio-unveils-next-generation-finops-solutions-designed-to-redefine-how-cloud-leaders-manage-and-optimize-investments-in-the-ai-era/ (checked Oct 3, 2026)
- •Apptio, Conversational Insights (preview) and Cloudability Intelligent Forecasting (Jun 16, 2026), https://www.apptio.com/company/news/press-releases/apptio-unveils-conversational-insights-and-new-suite-of-ai-powered-capabilities-to-translate-complex-technology-spend-into-measurable-business-outcomes/ (checked Oct 3, 2026)
- •IBM, Apptio AI Value & ROI, public preview, GA planned Q3 2026 (Aug 6, 2026; no GA announcement on the Apptio news page as of Oct 3, 2026), https://www.apptio.com/company/news/press-releases/ibm-introduces-apptio-ai-value-roi-to-close-the-gap-between-ai-spend-and-business-results/ (checked Oct 3, 2026)
- •Apptio news index, https://www.apptio.com/company/news/ (checked Oct 3, 2026)
- •IBM Cloudability docs, Business mapping (first match wins; changes apply to the current month; reprocessing for history), https://www.ibm.com/docs/en/SSVCLNQ/cloudability/admin/business-tags.html (checked Oct 3, 2026)
- •IBM Cloudability docs, Business Mappings End Point (/v3/business-mappings), https://www.ibm.com/docs/en/SSVCLNQ/cloudability/api-v3/business_mappings_endpoint.html (checked Oct 3, 2026)
- •IBM Cloudability docs, Connect Snowflake, https://www.ibm.com/docs/en/SSVCLNQ/cloudability/admin/connect-snowflake.html (checked Oct 3, 2026)
- •IBM Cloudability docs, Connect Databricks (cost and usage data), https://www.ibm.com/docs/en/SSVCLNQ/cloudability/admin/connect-databricks.html (checked Oct 3, 2026)
- •IBM Cloudability docs, Business Metrics in Cloudability, https://www.ibm.com/docs/en/SSVCLNQ/cloudability/admin/business-metrics.html (checked Oct 3, 2026)
- •dbt docs, snapshot configuration (
hard_deletes), https://docs.getdbt.com/reference/resource-configs/hard-deletes (checked Oct 3, 2026) - •Data Workers agent swarm repository (origin/main): AWS Cost Explorer read (monthly cost by service, forecast), Snowflake metering and query-tag attribution, quality checks, baselines, lineage, ADF pipeline trigger, approvals (checked Oct 3, 2026)
- •Data Workers client setup docs, https://dataworkers.io/opensource-docs/client-setup/ (checked Oct 3, 2026)