Timo Lindström, CEO, DB Pro Oy & DB Pro Services Oy.

Microsoft Fabric is one of the most interesting platform options to have come along in a long time. Unified analytics, real-time data streams and AI integration – all in one package.

However, one question keeps cropping up in Fabric projects, the answer to which has not been considered at a sufficiently early stage: who ensures that the data is actually in Fabric, that it is correct, and that it is there on time?

Fabric does not replace SQL Server — it integrates with it

This is the point where many Fabric projects run into difficulties. Fabric is an analytics layer, not a transaction layer. SQL Server remains the database for operational applications. Fabric uses its data for analytics and AI workloads.

This means that the condition of the SQL Server environment has a direct impact on the Fabric’s operation. An overloaded or incorrectly sized SQL Server slows down the flow of data into the Fabric. Out-of-date data in SQL Server appears as out-of-date data in the Fabric, more quickly and on a larger scale than before.

Modernisation without first ensuring the building is in good condition is like painting a new coat of paint over a rotten wall.

Data Responsibility in the Fabric Project

In Fabric projects, a great deal of attention is paid to architecture and technical implementation. However, data governance is often left unaddressed. Here are a few questions that need to be answered before implementing Fabric:

  • Who owns each data source that feeds into Fabric?
  • How do we know when data is late or incorrect?
  • Who steps in when the data stream is interrupted?
  • How is data quality validated before it appears in the analytics tool?

The correct order in Fabric projects

Before migrating to Fabric, it is worth ensuring at least these two things: that the SQL Server environment is correctly sized and that the data models are well-documented and clear. This will not delay the Fabric project, but will ensure its success.

We have experience of hundreds of data platform migrations. In most cases, we find that projects take longer and cost more when these matters are only addressed when forced to do so by problems, rather than being planned systematically at the start of the project.