Ligérium
FR EN
Book a call

Explainer

Data Mesh explained to a CFO

Decentralising data without losing control: a principle finance departments have practised for years. A jargon-free explanation, with the right questions to ask before investing.

Sébastien David 8 min read

Your CIO or data team keeps talking about "data mesh". The term sounds like yet another technical buzzword, and the budget request that comes with it deserves to be understood. Good news: if you run a finance function, you already know the essence of the model.

The problem data mesh sets out to solve

For years, the dominant model has been this: a central data team collects data from across the company into a single repository (a data warehouse or data lake) and produces analyses for everyone.

That works as long as the company stays simple. Then requests pour in from every department and the central team becomes a bottleneck: lead times grow, data is misread by people who don't know the business that produces it, and no one is clearly accountable for its quality.

In finance terms

Imagine a single central team having to produce the reporting for every business unit on its own, with no controllers in the field. The figures would arrive late, and no one could really explain them.

The core idea: how your financial control is organised

Data mesh, formalised in 2019 by Zhamak Dehghani, proposes distributing responsibility for data across business domains, while keeping shared rules and tools.

That is exactly how a decentralised finance function works: controllers in each business unit, a common framework (chart of accounts, closing calendar, standards) and group-level consolidation. No one suggests removing local controllers, or letting each subsidiary invent its own chart of accounts.

The four principles, in finance language

1. Domain ownership

Each business domain (sales, logistics, HR…) is responsible for the data it produces, because it understands it best.

In finance: each business unit owns its figures. Headquarters doesn't recompute a subsidiary's revenue.

2. Data as a product

Shared data is treated as a product: documented, reliable, with a named owner and quality commitments (freshness, accuracy).

In finance: the consolidation package. Standard format, submission date, consistency checks and an accountable signatory.

3. A self-serve platform

A central team provides shared tools (storage, security, catalogue) so each domain can publish its data without rebuilding everything.

In finance: the group ERP and consolidation tool. Every subsidiary uses them; none builds its own.

4. Federated governance

A few shared rules (definitions, security, GDPR, interoperability) are agreed together and applied everywhere, ideally automatically.

In finance: accounting standards and the group procedures manual. Defined centrally, applied locally, audited.

What it changes for the finance function

Figures that have an owner

"Which margin figure is the right one?" The question finally has an answer: the domain that produces the data is accountable for it, under a shared definition.

Faster decision-making

Business teams publish their own data; the central team is no longer the mandatory route for every new analysis.

Clearer costs

Every data product has an owner and known users. It becomes possible to allocate platform costs and measure the value created, domain by domain.

Built-in compliance

Rules (GDPR, access rights, traceability) are enforced by the platform rather than checked after the fact, which makes audits easier.

The costs and risks to face squarely

Data mesh is neither free nor for everyone.

  • It is an organisational change before it is a technical project. You need data owners in the business, dedicated time and an executive sponsor.
  • The initial investment comes before the benefits. The shared platform and governance must exist before domains can publish their data.
  • The risk of silos is real. Without firm shared rules, each domain creates its own definitions, and you end up with the very mess you wanted to avoid.
  • There is a critical size. With few domains and a small data team, decentralisation costs more than it returns.

What about SMEs and mid-sized companies?

Let's be honest: a full data mesh is rarely justified in a mid-sized company. Several of its principles, however, are useful from day one, and inexpensive:

  • name an owner for each key dataset (customers, products, sales);
  • write a shared definition of the KPIs reviewed by the executive committee;
  • treat shared datasets as products: documented, checked, with a stated quality level;
  • choose tools that will let you decentralise later, if growth justifies it.

That is often the best approach: adopt data mesh good practices without taking on the full organisation, then evolve with the company.

Five questions to ask before investing

  1. What concrete problem do we want to solve: lead times, reliability of figures, costs?
  2. How many business domains actually produce and consume data?
  3. Who, in each domain, will own the data, and with how much time allocated?
  4. Which shared rules will be non-negotiable, and who will enforce them?
  5. How will we measure success in twelve months?

In short

Data mesh applies to data what finance has practised for years: local accountability, shared rules, reliable consolidation. If the answers to these five questions remain vague, start with an assessment rather than a platform.