The Ultimate Guide to Data Fabric

Most data teams now manage their data lifecycle with five or six separate tools, and the work of keeping those tools connected has become a job of its own.

A typical stack looks something like this:

• An ingestion tool to copy data out of the ERP and the CRM
• A transformation tool to model it in the warehouse
• A data observability or testing tool to check its quality
• A workflow scheduler to run the jobs in the right order
• A data catalog so people can find what exists
• Spreadsheets for the product hierarchies and budget targets that don't live in any source system

Each of those tools stores its own piece of the business logic and keeps its own record of what it did. None of them has the full picture of how a number on a dashboard was produced.

That gap shows up in ordinary, expensive ways. When an ERP upgrade renames a column, the load still succeeds, the transformation that depends on it fails overnight, and the finance dashboard is empty on Monday morning. When the CFO asks why revenue is different in two reports, answering means opening four tools and comparing logic by hand. Fivetran's 2026 benchmark of 500 data leaders at large enterprises found that pipeline maintenance takes 53 percent of engineering capacity, with an average of 4.7 pipeline failures a month that each take nearly 13 hours to resolve.

A data fabric is the industry's answer to that problem. Gartner describes it as a data management design concept rather than a product: one layer of active metadata describes every source, transformation, quality rule, and delivery point, and the system uses that metadata to build, document, and run the environment instead of people stitching the pieces together by hand. Because it's a design concept, nearly every data management vendor now claims to sell one, which makes the term almost useless when you're comparing products.

Three things have made the question more urgent:

• Artificial intelligence: In February 2025, Gartner predicted that through 2026, organizations will abandon 60 percent of AI projects that aren't supported by AI-ready data. Its survey of 1,203 data management leaders found that 63 percent either don't have the right data management practices for AI or aren't sure whether they do. An AI model that answers questions about margin or stock levels needs data someone can trace back to its source, with the transformations and quality checks on record, and that record is exactly what a split stack can't produce quickly.
• Consolidation: The largest vendors are building their own fabrics by acquisition. Salesforce completed its $8 billion purchase of Informatica in November 2025, and Fivetran and dbt Labs completed their merger in June 2026, after Fivetran had already bought Census and Tobiko Data. Buyers are now being sold combinations of products that were designed separately and are being connected after the fact, which is the same integration work a data fabric is supposed to remove.
• Small teams: Gartner observed that while data and application silos surged over the past decade, the number of skilled people on data and analytics teams either stayed constant or even dropped. The benchmark figures above come from companies with more than 5,000 employees. A mid-sized company with a data team of three or four people faces the same failures and the same AI expectations with far fewer people to absorb them, so every hour spent repairing a pipeline is an hour taken directly from new work.

Together, these have made data fabric a practical decision for mid-sized organizations: how do you give analysts and AI governed, traceable data without buying and connecting six separate tools, and without an enterprise implementation that takes a year?

This guide explains what a data fabric is, why it matters now, where most implementations go wrong, and how to build one in eight steps.

What a data fabric actually is

A data fabric is a way of designing data management so that every stage of the data lifecycle works from the same shared metadata. Ingestion, transformation, data quality, business-owned reference data, delivery, and scheduling all read from and write to one record of what the data is and what has been done to it, instead of each tool keeping its own.

Metadata is the information that describes your data rather than the data itself. For a single revenue table, it includes:

• Which source systems the rows came from and when they were last loaded
• What each column means and which business definition it follows
• Every transformation, join, and calculation applied between the source and the report
• The quality rules the table has to pass, and whether it passed them on the last run
• Who can access it, and which reports, data products, and AI models use it

Most organizations already have all of this metadata, but it's scattered across their tools. The ingestion tool knows where the data came from, the transformation tool knows the calculations, and the quality tool knows the test results, and nobody can see the whole record in one place. A data catalog can collect copies of that metadata so people can search it, which helps them find data, but the catalog only describes the environment, and changing an entry in it doesn't change anything else.

What makes a data fabric different is that its metadata is active. The system uses the metadata to generate the code that moves and transforms the data, to produce the documentation and lineage, and to work out what runs in which order. Take the renamed ERP column from earlier. In a data fabric, the change is made once in the metadata and carried through to every transformation and report that depends on that column, and the lineage shows exactly what was affected, instead of a job failing overnight and someone tracing the cause by hand the next morning.

The idea has been around for more than a decade. Forrester analyst Noel Yuhanna was one of its early proponents, and Forrester's 2022 Enterprise Data Fabric Wave evaluated 15 vendors. Gartner named data fabric one of its top strategic technology trends for 2022. The concept hasn't changed much since then. What has changed is the cost of not having one, now that AI projects depend on data that can be traced and trusted.

A few neighboring terms get used as if they mean the same thing, and the differences matter when you're comparing products:

• Data mesh: An organizational model in which business domains own and publish their own data products. It describes who is responsible for the data, while a data fabric describes how the data is managed, and many organizations use the two together.
• Data virtualization: A technique for querying data where it lives without copying it. Some data fabrics use it for specific cases, but on its own it leaves transformation, quality, and history to other tools, and every query adds load to the source systems.
• Data warehouse and lakehouse: The places where data is stored for analysis. A data fabric sits above the storage layer, and a well-designed one can deploy the same logic to more than one storage platform.
• Microsoft Fabric: A Microsoft product that combines storage, data engineering, and reporting on Microsoft's OneLake. It shares the name, but it's an analytics platform inside one vendor's ecosystem rather than a design approach. Our guide to Microsoft Fabric explains how the two relate.
• Data catalog: An inventory of metadata that helps people find data. A catalog can be one component of a data fabric, but it isn't a fabric by itself.

A useful test for any product sold as a data fabric is to ask what its metadata actually does. A data fabric uses metadata to build, document, and run the data environment, so a product whose metadata only records what other tools have done is closer to a catalog than a fabric, whatever the product sheet calls it.

What a split data stack actually costs

The cost of running the data lifecycle on separate tools rarely shows up as a single line in the budget, which is why most organizations keep paying it without ever adding it up. It's spread across four places, and each one grows as the business adds sources, users, and AI projects:

• Licenses and integration work: Each tool comes with its own license, and many are priced by consumption, whether that's rows moved, compute used, or seats, so the total bill grows with data volume in ways that are hard to forecast. On top of the licenses sits the integration work, meaning the scripts, triggers, and handoffs that pass data and job status from one tool to the next, which someone on the team built and now has to maintain.
• Maintenance: Every connection between tools is a point where a change in one place breaks something in another. A new field in the CRM, a renamed column after an ERP upgrade, or a changed API in a SaaS application means tracing the impact through several tools and fixing each one by hand, which is how a small request turns into a project that takes weeks.
• Errors that reach decisions: When quality checks run in a separate tool, they often run after the data has been transformed, and sometimes after it has already reached a report. Gartner research estimates that poor data quality costs organizations at least $12.9 million a year on average. A mid-sized company feels it as billing errors, month-end closes that drag on for days, and managers who stop trusting the dashboard and go back to their own spreadsheets.
• Proving what happened: Regulators and auditors increasingly expect organizations to show where data came from and what was done to it. Under the EU AI Act, Article 10 requires high-risk AI systems to be trained, validated, and tested on data that's subject to documented data governance practices, and the Digital Omnibus agreed in May 2026 moved those obligations to December 2027 rather than removing them. Our guide to EU AI Act data readiness covers the details. In a split stack, that record has to be assembled by hand from each tool's logs, so every audit becomes a project of its own.

The severity depends on the organization. For a company in a lightly regulated industry, a split stack is mainly a cost and speed problem: the team spends its time on repairs and the business waits longer for answers. For a company in financial services, healthcare, or the public sector, it's also a compliance risk, because the evidence a regulator asks for is spread across tools that were never designed to produce it together.

The difference is easy to see in organizations that moved their data lifecycle onto a single metadata-driven platform. Four Timextender customers give a sense of the scale:

• Vodafone Iceland cut billing data errors by 74 percent within 12 months and reduced its end-of-month processing from four days to three hours.
• Dacapo, a Danish stainless steel supplier, sets up new automation tasks in one to two days. Its CFO estimates the same work would take one to two months without the platform.
• Pandora now spends about 20 percent of the time it used to spend on data preparation, and new contractors are productive by the afternoon of their first day.
• Neuroth, an Austrian hearing aid specialist, completed its project about 70 percent below the cost of a conventional implementation.

That's what a data fabric is worth in practical terms, and it pays off in four ways you can take to a board:

• Changes in source systems are carried through in hours, instead of breaking jobs and waiting in a backlog.
• Errors are caught before they reach a report, an invoice, or an AI model.
• Audit and AI governance evidence comes from the system, instead of from weeks of manual work.
• The data team spends its time on new requests instead of on repairs.

None of that requires a bigger data team, only a data environment that keeps one record instead of six.

The six things a data fabric actually requires

Six things separate a working data fabric from a set of tools with a data fabric label on them. Each one is a place to check where you stand today, and each one is somewhere implementations quietly fall short.

1. Metadata runs the environment

In a data fabric, the metadata is the definition of the work itself, and documentation is one of the things the system produces from it. When a developer adds a new source table, maps its columns, and defines how it joins to the rest of the model, the system uses that definition to generate the code, create the tables in the target storage, and update the documentation, all from the same record. This matters because every capability later in this list depends on it: lineage, quality, portability, and orchestration only work automatically if the system has one complete description of what exists. An organization at an early stage keeps its logic in scripts and pipeline code and writes documentation separately, if at all. A mature one changes the metadata and lets the system produce everything else.

2. Business logic stays separate from storage

The transformations, models, and business rules your team builds are the most valuable part of the data environment, and they should not be tied to the storage platform they happen to run on today. When logic is written in one platform's native tools, moving to a different cloud or database means rebuilding it by hand, which can take months and is the reason many organizations stay on a platform long after it stops being the right one. When logic is captured as metadata, moving it is a matter of deploying the same definitions to new infrastructure. Komatsu Australia moved its full production environment to Azure SQL Database Managed Instance in under two weeks this way, cut costs by 49 percent, and improved performance by 25 to 30 percent.

3. Quality checks run inside the flow

Data quality rules belong in the same flow as integration, so data is checked before it reaches a report, an invoice, or an AI model. A rule might require that every invoice has a valid customer ID, that order quantities are never negative, or that daily sales fall within an expected range for each store. When those checks run in a separate tool after the fact, bad data has often already been used by the time anyone sees the alert. A mature data fabric profiles new data automatically, runs validation rules as part of every load, stops or flags records that fail, and keeps the results as part of the metadata record, so anyone can see whether a table passed its checks on its last run.

4. Business-owned data is governed like every other source

Every organization has data that doesn't come from any source system: product hierarchies, sales regions, budget targets, chart-of-accounts mappings, and customer segments. In most companies this data lives in spreadsheets maintained by finance or operations, and it feeds directly into the numbers executives see. When someone moves a store from one region to another in a spreadsheet, revenue by region changes in every report, with no record of who made the change or when. A data fabric treats this business-owned data as governed records, with defined owners, approval steps, and a history of changes, connected to the same metadata as everything else.

5. Lineage and documentation come from the system

When an auditor, a regulator, or the CFO asks where a number came from, the answer should be available in minutes, without anyone assembling it over several days from different tools. Lineage traces every figure back through each transformation to the source systems it came from, and documentation describes what each table, column, and rule means. In a mature data fabric, both are produced automatically from the metadata whenever the environment changes, so they're always current. Neuroth's head of data architecture services singled out the data lineage visualization as one of the things that impressed the team most during its project.

6. One orchestration layer covers the whole lifecycle

Ingestion, transformation, quality checks, and delivery have to run in the right order, and they have to respond when something upstream is late or fails. When each tool has its own scheduler, the team ends up managing dependencies by guessing how long each job takes and padding the schedule, which wastes time and still breaks when a load runs long. A single orchestration layer knows the dependencies from the metadata, runs each step when its inputs are ready, and can run across cloud and on-premises environments from one place. That's what makes frequent refreshes practical: Pandora makes its manufacturing and distribution data available every 15 minutes. Our article on traditional data pipelines vs. modern data flows covers the difference in more detail.

These six requirements depend on each other. Quality results, lineage, portability, and orchestration all work automatically only when the metadata in the first requirement is complete, which is why a data fabric assembled from separate tools struggles to deliver them, however good each tool is on its own.

Where most data fabric projects fall short

Most organizations that set out to build a data fabric end up with something that looks like one on an architecture diagram and behaves like the old stack in practice. The reasons are rarely technical incompetence. They come from reasonable decisions made under deadline pressure, by teams measured on delivering the next report rather than on how the environment holds up over five years. Six patterns account for most of the shortfall:

1. They buy the label instead of the capability

• The pitfall: They add a data catalog or a virtualization layer on top of the existing tools and call the result a data fabric.
• Why it happens: The term is a design concept, every vendor claims it, and a new layer on top is easier to buy and approve than a change to how the work underneath is done.
• Consequences: The catalog describes the same scattered logic it was meant to fix, the pipelines still break when a source changes, and the organization now pays for one more tool to keep current.

2. They start with the architecture instead of the decisions

• The pitfall: They design the full target architecture and choose tools before agreeing on which business decisions and data products the fabric has to serve first.
• Why it happens: Architecture work feels like progress, and it's easier to draw a diagram than to get finance, sales, and operations to agree on which questions matter most.
• Consequences: Months pass before anyone in the business sees a result, sponsorship fades, and the first data products that do arrive answer questions nobody was asking.

3. They build a new pipeline for every source

• The pitfall: They connect each new source with its own hand-built pipeline, or with a connector tool that lands raw data while the transformation, dependencies, and scheduling are built separately for each one.
• Why it happens: The first few pipelines are quick to build, and the cost only becomes visible once there are dozens of them and every source system upgrade breaks several at once.
• Consequences: Engineering time shifts steadily from new work to repairs, and knowledge of how each pipeline works ends up with the person who wrote it, which becomes a serious problem the day that person leaves.

4. They write the logic in one platform's native tools

• The pitfall: They build transformations and models directly in the tools of whichever cloud platform they chose, because that's what the platform makes easiest.
• Why it happens: The native tools are included, well documented, and fast to start with, and nobody is planning a move during the first project.
• Consequences: The logic can't move without being rebuilt. When prices rise, a better platform appears, or a customer contract requires a different deployment, the organization faces a rebuild measured in months, so it usually stays where it is.

5. They treat quality as a cleanup step

• The pitfall: They run data quality checks after the data has been loaded and transformed, often in a separate tool, and fix problems when someone complains about a report.
• Why it happens: Quality rules take time to define, delivery deadlines come first, and checks get added one at a time after each visible error.
• Consequences: Bad data reaches reports, invoices, and AI models before anyone catches it, and each fix is a manual correction that leaves no lasting rule behind, so the same errors return.

6. They try to build the whole fabric at once

• The pitfall: They plan a single program to connect every source, model every domain, and migrate every report before declaring the fabric live.
• Why it happens: Enterprise vendors and large consulting firms often scope projects this way, and a complete program is easier to approve as one budget line than a series of smaller steps.
• Consequences: The program runs for a year or more, the business changes faster than the plan, and a mid-sized data team spends most of that time on the project instead of the business's day-to-day requests.

Each of these is a reasonable response to short-term pressure, and each one adds work to keep separate pieces connected instead of removing it. Three questions are worth carrying into any data fabric conversation, because they expose most of these patterns early: Does the metadata run the environment, or only describe it? Can the business logic move to a different storage platform without a rebuild? Are quality, lineage, and orchestration part of the same flow, or separate tools that someone has to keep in sync? The next section turns those questions into eight steps.

How to implement a data fabric in eight steps

The steps below work with any technology, and the order matters, because each one depends on the one before it. They're written for a mid-sized data team that needs results within weeks, which means building the fabric one business domain at a time rather than all at once.

1. Start from the decisions, not the tools

Pick one business domain to start with, such as finance, sales, or supply chain, and write down the five to ten questions it needs answered: monthly gross margin by product and region, for example, or days of stock on hand by warehouse. For each question, note who asks it, how often, and which decision depends on the answer. Talk to the people who make those decisions, from the CFO to the operations managers, and rank the questions by business value. The top few become your first data products, the governed datasets the fabric will deliver first.

• Common mistake: Copying the existing reports one for one into the new environment, which carries every old workaround and inconsistency into the new fabric.

2. Connect your sources through one ingestion layer, not a pipeline per source

List every source the first domain needs, typically the ERP, the CRM, a few SaaS applications, and some files or APIs. Bring them all in through a single ingestion layer, where you set the scope (which tables) and the frequency (the schedule) for each source, and let the system maintain the load dependencies and incremental loading. Keep the raw data as it arrived, so you always have a traceable starting point when a number is questioned later.

• Common mistake: Building a separate pipeline for each source, or using a connector tool that lands raw data while the transformations, dependencies, and schedules are built elsewhere, so every change to a source breaks something downstream.

3. Capture business logic as metadata, not code

Define the mappings, joins, and calculations in one place, as metadata, and let the system generate the code from those definitions. That includes the rules that are usually only in someone's head or buried in a SQL script, such as "gross margin is net revenue minus cost of goods sold, excluding intercompany sales." Once a definition exists in the metadata, it's documented, it appears in the lineage, and it can be reused by every data product that needs it. This step is the one everything else depends on, because the quality, lineage, portability, and orchestration in the steps that follow all read from these definitions.

• Common mistake: Letting logic accumulate in scripts, notebooks, and stored procedures written by different people, which works until someone needs to change a definition and can't find every place it's used.

4. Model the data and build the semantic layer

Organize the data into a model the business can use. In most cases that's a dimensional model, with facts such as sales order lines or shipments, and dimensions such as customer, product, store, and date. Decide early how to handle history, for example whether a sale should be reported under the region a customer belonged to at the time or the region it belongs to now. On top of the model, build a semantic layer that gives tables, columns, and measures business names and shared definitions, so every reporting tool and AI assistant uses the same meaning of "revenue" and "active customer."

• Common mistake: Defining measures separately in each reporting tool, which is how the same metric ends up with two different values in two different dashboards.

5. Choose storage independently of the logic

Decide where the data will live based on cost, performance, data residency requirements, existing skills, and contracts. The options include a cloud data warehouse, a lakehouse, an on-premises database, or a mix of cloud and on-premises. Because the business logic is held as metadata, the same definitions can be deployed to whichever target you choose, and redeployed to a different one later if prices change, a better option appears, or a regulation requires data to stay in a particular location.

• Common mistake: Choosing the platform first and writing the logic in its native tools, which turns a future change of platform into a rebuild.

6. Build quality rules into the flow

Profile the first loads from each source to see the real state of the data: missing values, duplicates, and figures outside expected ranges. Turn what you find into validation rules that run as part of every load, give each rule an owner, and decide what happens when a record fails, whether that's stopping the load, holding the record for review, or flagging it and continuing. Make the results visible in the metadata, so anyone using a table can see whether it passed its checks on the last run.

• Common mistake: Treating quality as a cleanup job that happens after someone spots a wrong number in a report.

7. Govern business-owned data

Find the spreadsheets that feed your reports, such as product hierarchies, sales territories, budget targets, and account mappings, and move them into governed records with a named owner, an approval step for changes, and a full history of who changed what and when. Connect those records to the same metadata as the rest of the data, so a change to a hierarchy shows up in the lineage like any other change.

• Common mistake: Leaving this data in spreadsheets because finance or operations owns it, which leaves some of the most influential inputs to every report outside any control.

8. Orchestrate the lifecycle and expand one domain at a time

Run ingestion, transformation, quality checks, and delivery from one orchestration layer that knows the dependencies from the metadata, starts each step when its inputs are ready, and alerts the right person when something fails. Once the first domain is live and the business trusts its numbers, add the next one. Each new domain reuses the sources, dimensions, and rules already built, such as the customer and product dimensions, so the second domain goes faster than the first and the third faster again.

• Common mistake: Waiting to connect every source and domain before going live, which delays any business result by a year or more and gives the plan time to go out of date.

Done in this order, the steps produce a working data fabric for one domain within weeks, with lineage, documentation, and quality results that come from the system as it runs. The steps themselves are the same whatever technology you use. What changes is how much of the work your platform does for you, which is what the next section covers.

Our approach: one metadata layer for the whole lifecycle

Every failure described earlier comes back to the same root. The data fabric gets treated as something you assemble by adding tools: a catalog on top, a quality tool beside the pipelines, a scheduler to keep everything in order, all sitting on logic that's tied to one platform. Each new layer adds another set of connections someone has to maintain, and the scattered logic underneath stays exactly where it was.

The answer isn't a better tool bolted onto the same foundation. It's a different operating model, one where lineage, quality, and portability aren't projects you run but properties the system already has. Timextender is built on three principles that make that possible:

1. Metadata-Driven

• What it is: Business logic is separated from storage and captured as metadata. The platform records the structure, transformations, lineage, dependencies, quality rules, and definitions of every data asset, and then uses that metadata to run the environment.
• What it enables: Code, documentation, and lineage are generated from the same record, so they always match what's actually running. Because the logic is independent of any single storage technology, the same solution deploys to Microsoft Azure, including Azure Synapse, Microsoft Fabric, Microsoft SQL Server, Snowflake, and AWS without a rebuild.
• Why it matters for a data fabric: This is the shared metadata layer a data fabric depends on. A renamed column is changed once and carried through to everything that uses it, and a move to a new storage platform is a deployment rather than a rewrite.

2. Automation-First

• What it is: The platform generates production-ready code from that metadata using deterministic, rule-based automation. The same inputs produce the same output every time, rather than a large language model guessing at a pipeline.
• What it enables: Builds run up to ten times faster than hand-coding, because logic captured as metadata is compiled rather than written by hand, and every result is explainable and repeatable. You can show exactly how a pipeline was generated and reproduce it precisely.
• Why it matters for a data fabric: A mid-sized team can build and maintain a full data fabric without writing and repairing a pipeline for every source, and the lineage and documentation the fabric produces can be trusted because the code behind them is consistent.

3. Zero-Retention

• What it is: Timextender doesn't retain customer data beyond what's required to deliver the specific capability the customer enables. Data handling depends on the module and hosting model, and customers can choose to host modules in their own environment.
• What it enables: The amount of your data held outside your control stays small by design, and organizations with strict requirements can keep processing inside their own infrastructure.
• Why it matters for a data fabric: A data fabric touches every source in the organization, so how much data the platform itself holds matters. Keeping that footprint small makes security reviews, data residency questions, and vendor risk assessments simpler to answer.

Most approaches to data fabric give you part of this. Enterprise platforms cover the full lifecycle, but through a large set of products and an implementation that typically needs a consulting partner and many months, which a mid-sized team can rarely staff or fund. Virtualization and catalog layers add a view across the existing stack without changing how the work underneath is done. Point tools each do one job well and leave the connections between them to you.

Timextender covers the full lifecycle on one metadata layer, deploys to the storage you choose, and is implemented in weeks through a network of more than 200 partners in 95 countries. Timextender made that design decision when the company started in 2006: capture business logic as metadata, and let the system generate, document, and run everything built from it.

How the Timextender Data Platform delivers a data fabric

The Timextender Data Platform covers the data lifecycle with four modules: Data Integration, Data Quality, Data Enrichment, and Orchestration. Each module is available today on its own, they can be used independently or together, and we're bringing them together into a single platform connected by shared metadata, which will be deployable in the cloud or on-premises. Here's what each one does, and which of the eight steps it covers.

Data Integration

Timextender Data Integration is the core engine of the data fabric and covers steps 2 through 5. It connects to any data source through pre-built, fully managed connectors, with support for custom sources, and its ingestion layer lets you set the scope and schedule for each source while it maintains the load dependencies automatically. Every mapping, transformation, and calculation is captured as metadata, separate from the storage layer, and the platform generates the code from it. The same module builds the dimensional model and the semantic layer that reporting tools and AI assistants read from, and it deploys the whole solution to Microsoft Azure, including Azure Synapse, Microsoft Fabric, Microsoft SQL Server, Snowflake, or AWS. When a source changes, the change is made once and carried through the entire data flow in a few clicks, and documentation and lineage are generated from the same metadata.

Data Quality

Timextender Data Quality covers step 6. It monitors data continuously against validation rules built in a flexible rule designer, alerts the right owner when a rule is violated, and gives the team one view of every open data issue across the business, with responsibilities assigned and a full log of rule changes. Combined with Orchestration, it can hold back dependent processes when poor data quality is detected, so bad data stops before it reaches a report, an invoice, or an AI model.

Data Enrichment

Timextender Data Enrichment covers step 7. It gives business teams a spreadsheet-like interface for the data that doesn't live in the ERP or the CRM, such as sales targets, product categories, regional hierarchies, and mappings between systems. Users can capture this data from APIs, files, or manual entry, enrich and map it, and apply validation rules, while every change is stored in a SQL database, logged for audit, and governed. That turns the spreadsheets feeding your reports into controlled records connected to the rest of the platform.

Orchestration

Timextender Orchestration covers step 8. It coordinates workflows and dependencies across different technologies and environments from one place, runs each process in the right order, and makes troubleshooting faster when something fails. It can also schedule scripts and API calls to scale, pause, or start cloud resources at the right time, so compute is only running when the work needs it.

Connecting the fabric to AI

Two further capabilities put the governed data to work. The Timextender MCP Server connects AI tools and agents to your semantic model, so they answer questions from governed definitions instead of guessing at raw tables. Xpilot Analytics, generally available since the 26.3 release in September 2026, lets anyone in the organization ask a question of the data model in plain language and get back a chart or a number they can check.

What it looks like in practice

None of the organizations below set out to buy a data fabric. Each one had data spread across systems that didn't talk to each other, a small team, and a business that needed answers quickly, and each one solved it by running its data lifecycle on one metadata layer.

CRIM, public sector

CRIM, Puerto Rico's municipal property tax authority, faced intense public scrutiny over its billing and collections after Hurricane María. Its data was split across several Oracle and SQL databases, a separate billing application, and a geographic information system, with no integration between them, and the agency was collecting only 22 percent of its potential revenue. Working with partner Truenorth Corporation, CRIM connected those sources and built a data warehouse integrating billing, appraisal, and land registry data in 15 days. The analysis that followed identified more than $250 million a year in revenue recovery opportunities, including $117 million from correcting more than 117,000 undeliverable invoices. For a data fabric, the lesson is speed: connecting sources that had never been integrated took 15 days because the work ran through one platform, without a separate project for each system.

Formue, financial services

Formue, a Nordic wealth management firm with NOK 128 billion in client assets, needed to rebuild its client reporting with exactly one developer available. It deployed Timextender Data Integration on Snowflake, combining a portfolio management system, its CRM, and external market data from Bloomberg and MSCI. The first phase, a new data warehouse, data marts, and a dashboard for 140 advisors, went live in under three months, including the holiday period, and was built almost entirely by that one developer. When Formue later moved its CRM from SuperOffice to Salesforce, the change had no impact on the advisors' reports.

"We had a need to combine data, but we only had one developer." - Liv Bøstrand, Head of Data and Analytics, Formue

Nordisk Film, media and entertainment

Nordisk Film runs cinema chains, game studios, PlayStation distribution, and digital gifting across the Nordic region, and its old data warehouse only handled financial data. A four-person BI team had to serve every business area, and building a new data model meant weeks of SQL development. After moving to Timextender in three months, the team now has more than 200 data sources ready for reporting, builds new data models in hours, and manages financial reporting for nearly 50 legal entities with one person. Report development that used to take a month now takes four hours.

"We are only a small team of 4 people, serving each of the business areas within Nordisk Film." - Mikkel Hansen, Head of BI, Nordisk Film

DAS Italia, insurance

DAS Italia, a legal protection insurer with 13 million customers, was running on a legacy system so slow that a data extraction started on Friday didn't finish until Sunday, so staff began every week with data that was already two days old. With partner SDG Group, it replaced the system entirely and switched from weekly batch extraction to incremental loading. Demonstrations showed the new environment doing in two hours what had taken two days, and business users in planning and controlling can now view, analyze, and change data models without waiting for IT.

Taken together, these four show what a data fabric delivers for a mid-sized team: fragmented sources connected in weeks at CRIM, a full reporting platform built by one developer on Snowflake at Formue, more than 200 sources managed by four people at Nordisk Film, and a two-day refresh cut to two hours at DAS Italia.

Start by knowing where you stand

The first step isn't a procurement decision, it's a diagnosis.

• Find your starting point: Check your current environment against the six requirements in this guide, and ask the three questions from the section on where projects fall short. Does your metadata run the environment, or only describe it? Could your business logic move to a different storage platform without a rebuild? Are quality, lineage, and orchestration part of one flow, or separate tools someone keeps in sync? The honest answers tell you which of the eight steps to start with.
• Go deeper on the details: Our guide to data products covers what the fabric should deliver first, and 3 Guiding Principles for Building a Successful Data Fabric adds the design principles behind the steps.
• Start building: Request a demo to see the platform working on your own data, or find a partner with experience in your region or industry.

Check your AI readiness

Most data fabric projects today are judged by whether they make AI possible. The AI-Readiness Quick Check scores your data foundation across eight pillars in about three minutes and shows you the gaps most likely to keep AI out of production.

Get the metadata right, and every report, audit, and AI project that follows starts from data you can trace.