From the toolbox to the data landscape

Anyone who has set up a data platform in recent years will be familiar with the ritual: you start by selecting tools. Which database for the central warehouse? Which ETL tool for the pipelines? Which visualisation solution for the reports? The first few weeks are dominated by evaluations, licence negotiations and architectural diagrams — even before a single data record has been transferred.

This approach has its own logic. It’s familiar, it provides structure, and it produces a tangible result early on: a technology stack.

But it also contains a fundamental flaw in reasoning. Due to the technological focus, data usage is highly likely to remain an ‘IT issue’. Questions regarding the benefits for business processes and the contributions to corporate strategy have to be clarified later – the use cases that are then often only ‘sought out’ for the new data platform.

The problem with the ‘tool-first’ approach

A central data warehouse, a unified ETL platform, a shared BI layer — that sounds well-organised. In practice, however, it often results in something quite different: a monolithic bottleneck managed by a small central team that is then responsible for all data requirements across the company (‘the silo’). Marketing waits for the analytics team. The analytics team waits for IT. IT is waiting for capacity and has to prioritise.

The model doesn’t scale — neither organisationally nor technically. And it ignores a crucial question: who actually knows the data best?

In most companies, it’s the business units themselves. The sales team understands the semantics of the CRM data. The logistics team knows what a ‘completed delivery’ really means. The central data team usually doesn’t.

On top of that, a new cohort of ‘inexperienced staff’ – the ‘agentic workforce’ – is emerging and needs access to more high-quality data, but has little experience in spotting data errors.

A paradigm shift in platform development

• Previously: Technology selection as the first step
  Today: Data domains and teams as the starting point
• Previously: Centralised DWH team as the bottleneck
  Today: Distributed ownership, decentralised responsibility
• Previously: Uniform ETL for all domains
  Today: Each domain delivers its own data product
• Previously: Business unit as data consumer
  Today: Business unit as data owner
• Previously: Platform as a technology stack
  Today: Platform empowers the organisation

Data Mesh – the concept behind the transformation

The term ‘Data Mesh’, coined by Zhamak Dehghani, conceptually summarises this transformation. Instead of collecting and managing data centrally, data is organised along business domains. Each domain owns its data, maintains it and makes it available as a data product — with clear interfaces, defined quality standards and a team that takes responsibility.

That sounds convincing. Implementation has been the problem so far. This is because the model places high demands: each domain needs its own infrastructure. Governance becomes complex. The central platform must simultaneously empower users and provide guidelines. Without the right tools, Data Mesh ends up as an organisational idea with no technical home.

Microsoft Fabric – a platform as an operating system

This is exactly where Microsoft Fabric comes in. Fabric is not a collection of tools that you licence as a bundle. It is an integrated analytics platform that brings together all capabilities — from data ingestion, through transformation and storage, to visualisation and AI — under one roof. The key difference is that all the necessary technologies are available to data teams and can be used within a defined governance framework. There’s no need to procure them, integrate them or maintain them separately.

This fundamentally changes the initial question. Instead of ‘Which tool do we use for X?’, the question becomes ‘What domains do we have, who are their customers, and what do they need?’.

Microsoft Fabric — a SaaS platform with all the tools a data team needs – data acquisition, storage, processing, modelling, consumption and ML/AI utilisation

What changes in practice with Fabric

In a Fabric environment, for example, the sales data team works in its own workspace. It models its data in the Lakehouse, transforms it using Dataflows or Spark notebooks, and publishes a curated semantic model — the data product — for customers within the organisation. The marketing team consumes this product, combines it with its own campaign data, and in turn delivers insights to senior management.

No team has to wait for a central infrastructure team to create a new schema or start a pipeline. No architecture board has to decide whether to introduce another tool for the new use case. The capabilities are easy to use — governance, security and compliance are managed centrally and consistently via Microsoft Purview, whilst operational responsibility remains decentralised.

This is the organisational principle of a flexible, federated data platform.

Teams think differently when the question is framed differently

When a domain team knows it doesn’t have to procure the infrastructure itself, the discussion changes fundamentally in the first few weeks of a project. The focus is no longer on technologies and trying to fit requirements into existing tools, but on the data users: Who needs what? How often? To what standard? What decisions should the data enable?

These questions lead to better data products — because they are conceived with a view to moving from business requirements to a suitable implementation. Based on business needs, not on technical tools. And the capabilities simply provided by the platform lead to faster results. Architectural decisions no longer take weeks, but just hours.

Governance without centralisation

A valid objection: if every domain manages its own data, chaos looms. Different definitions, incompatible models, uncontrolled data access.

Microsoft Fabric addresses this with a concept that can be described as ‘federated governance’. Centralised policies — data access controls, classifications, compliance rules — are defined once and apply across the entire platform. Within this framework, each domain has operational freedom. The central function sets the framework; the teams work autonomously within it, whilst remaining transparent for the sake of shared governance.

The OneLake approach in Fabric also ensures that data is not physically replicated in an uncontrolled manner. There is a logical persistence layer — with domain-specific areas, but a shared underlying structure and shared discoverability. As data is always managed solely within the context of a workspace by its team and the tools used there, there is no such thing as data without an owner.

Fabric forms a ‘data usage layer’ within the organisation, providing a central point of contact without forcing the mandatory migration of all existing, established solutions and data pools. Instead, so-called ‘shortcuts’ allow data to be ‘populated’ directly from its existing storage locations, whilst ‘mirrors’ enable a ‘zero ETL’ connection to an automatically managed replica in Fabric for databases.

The actual transformation

It would be short-sighted to describe Microsoft Fabric as ‘the tool that enables Data Mesh’. The actual transformation is organisational in nature. Fabric creates the technical conditions that enable organisations to start thinking in terms of domains and products — rather than tools and projects.

This means that data teams, which previously waited reactively for requests, become producers of domain-specific data products. Business departments, which had delegated data as an IT issue, take on responsibility. And the platform itself ceases to be a bottleneck — because it is large enough to support many teams simultaneously.

This fundamentally changes the approach to adopting a data platform. Instead of ‘Which technology should we choose?’, the focus shifts to ‘Which domains do we have, which teams are we empowering first, and which data products deliver the greatest value to their customers?’.

That is a better first question. And it leads to better platforms.

And this marks the start of the fundamental discussion on developing a data strategy that contributes to the corporate strategy – the path to a data-centred organisation!

Cost planning: from licence Tetris to a single budget

An often underestimated aspect of the traditional ‘tool-first’ approach is its cost complexity. In practice, a modern data platform made up of individual components means: different licensing models for each tool, separate cloud infrastructure costs for compute and storage, operational costs for monitoring, patching and scaling — and all this for a landscape that is constantly growing and whose usage is difficult to predict. The finance team asks for the budget for the coming year; the answer is, at best, an estimate with a wide margin of uncertainty.

Added to this is the scaling problem: when a new domain is introduced, it requires its own infrastructure. When a project enters the pilot phase and the volume of data suddenly increases, additional resources must be ordered — involving lead times, approval rounds and often unplanned extra work. When a project ends or a team is downsized, licence costs still remain because contracts are still running.

Microsoft Fabric turns this model on its head. As a SaaS platform, cloud infrastructure and operations are already included in the price — no separate Azure infrastructure budget, no DevOps costs for platform maintenance, no surprises in the bills due to uncontrolled resource usage. What remains is a single control metric: Fabric Capacities.

The capacity model isn’t rigid, however. Fabric offers the concepts of ‘burst’ and ‘smoothing’ to cushion short-term load peaks — such as when a domain team starts a large load job or reporting is at its busiest at the end of the month — by temporarily increasing compute usage, without the need to immediately book more capacity.

The platform smooths usage over time. The result is a fixed, predictable budget that still allows for flexible and varying usage patterns, rather than permanently maintaining oversized capacity to cater for every peak load.

For budget planning, this represents a fundamental simplification, as the question is no longer “How many licences for which tool in which tier?”, but “What capacity size do we need for our usage profile?”. Onboard new domains without signing new contracts. Start and finish projects without having to manage leftover licences. And when the platform actually grows, there is a single lever — more capacity — rather than a jumble of individual decisions.

Cost structure comparison

• Traditional data platform: Separate licences per tool & vendor
  Microsoft Fabric (SaaS): A single capacity unit covers all workloads
• Traditional data platform: Cloud infrastructure & operations charged separately
  Microsoft Fabric (SaaS): Platform operations included in the SaaS price
• Traditional data platform: Growth = new contracts & negotiations
  Microsoft Fabric (SaaS): New domains utilise existing capacity
• Traditional data platform: Peak loads difficult to plan for & idle costs
  Microsoft Fabric (SaaS): Burst & Smoothing: Peaks are buffered
• Traditional data platform: Budget with a large uncertainty buffer
  Microsoft Fabric (SaaS): Fixed, predictable budget — flexible usage

Conclusion

Microsoft Fabric marks a genuine paradigm shift in the design of data platforms — and this transformation is taking place on two levels simultaneously. At the technical level, the ‘domain-first’ principle replaces the traditional tool-oriented approach: it is no longer the technology that determines the structure of the platform, but the business domains, their teams and their data products. At the economic level, the capacity model replaces the complex web of licence and infrastructure costs with a single, predictable control variable.

These two changes are interlinked. A domain landscape that grows and evolves requires a cost structure that scales with it — without generating new contracts, new infrastructure and new operational overheads for every new domain. This is precisely what Fabric achieves: the platform scales both organisationally and technically, because both rest on the same foundation.

This does not mean that all previous challenges disappear. Data quality, governance and empowering teams are not platform issues — they remain organisational tasks. What Fabric removes is the need to tackle these tasks under the additional burden of a fragmented tool landscape and an unpredictable cost structure.

The crucial question when getting started with Fabric is therefore not a technical one: it is an organisational one. Which domains do we have? Who is responsible for which data? Which data products deliver what added value to which customers? Anyone who can answer these questions has everything they need to get started with Fabric. The platform is ready — the real work begins in the whiteboard room, not in the tool evaluation meeting.