Over the past months, I’ve been engaging with many clients with regards to Microsoft Fabric. Many clients had a somewhat hesitant approach given Fabric was still in preview and they did not want to bring their (entire) data estate to Fabric. Since last week, Microsoft launched Fabric as General Available during the annual conference Microsoft Ignite, so no reason to hold back anymore! Right?

You thought so? Well, there is more that comes to the table other than only the status of the platform. For example, also the governance around the product. Architects and administrators having different thoughts about the platform, or the lack of controls over the workloads that can be used by their end users. Who is allowed to build lake houses or warehouses? Or notebooks to do further transformations?

In this blog I will share my perspective on these thoughts and try to compare it to the way of working that has been proven successful with Power BI over the past years.

Hesitant thoughts

When Fabric first launched as a public preview, back in May 2023, the default tenant setting for Fabric was disabled. Many organizations where happy with this new default as before with other settings the tenant administrators experienced situations in which newly rolled-out features were enabled by default, which might not always fit their organizations governance and compliance standards.

After a short while and people get used to the fact that Fabric was out there, the default setting changed from disabled to enabled, for all those tenants that did not adjust the setting yet. In other words, each tenant administrator should have switched the toggle on and off or add a security group to the setting to keep it disabled at that point. At all times the administrator was in control of their tenant configurations, to align feature usage and adoption with enterprise architectures and all other interests.

Where the aim of Fabric is to bring the powerful analytical tools to the masses, there are organizations struggling and being hesitant to enabling the full capability of Fabric. I’ve come across a few of them which all show typical patterns and similar reasons to not enable Fabric at this point. Below I will highlight a few of the arguments they raised (of course all anonymized).

Enterprise architecture
Customers’ enterprise architecture defines their data platform in other technology than Microsoft. Therefore, they aim to keep all their data central in our enterprise data platform and don’t want to have newly build warehouses and lake houses in Fabric. Power BI, as part of Fabric, is only used as reporting tool on top of the enterprise data platform. Finer controls to define which artifacts can be used and what not are missing in the Fabric tenant settings is an argument often raised.

Lack of governance and oversight
Another reason that came forward multiple times, is the lack of oversight when it comes to integration with data management and governance tools. Typically, the customers raising this argument have data governance tools other than Microsoft Purview. They prioritize this oversight to keep track of where data is being used in- and outside of the platform to keep it safe and secure. Tracking lineage for example, is an important part of that.

Adoption
Another often raised argument is the adoption of new technology. Users might not be ready for all this new tech and not tech-savvy enough to work with pro-tools like Fabric offers. Users should slowly get used to the power of the tools they have at their disposal and follow trainings and comply to best practices before users are allowed to take full advantage of Fabric.

The counter arguments and aiming for solutions

Let’s put one thing out there before I continue. I’m not writing this blog because I think above arguments are wrong. I’m also not aiming to judge anything or anyone here. Let’s put that up front. The only thing I have to admit, is that arguments like the above are often raised out of misunderstanding and feeling a lack of involvement and control. I could think of various reasons why the sentiment is this way. Below I will explain a few of my thoughts in this area.

Are the controls where they should be?
The admin controls for Fabric are put in the hands of (former) Power BI Service administrators, which now have been named Fabric administrators. They can toggle-on/off features and decide who can use what, but now for a wider scope than they used to do. Architects might feel they are by-passed in this setup as they feel the controls should be in their hands.

Personally, I think the truth is in the middle. Power BI architects and administrators are familiar with the SaaS platform that Power BI has been over the past years. Fabric is built on top of the same foundation and familiar concepts like workspaces come along. At the same time, artifacts in Fabric like Notebooks, warehouses, lake houses, not even talking about Spark settings that come on capacity and workspace level.

In all fairness, the data platform folks and Power BI folks should connect together more often. Don’t try to reinvent the wheel by coming up with entirely new governance around workspaces when you’re coming from a data platform background. Similarly, coming from a Power BI background, don’t try to tell the data platform folks what it takes to configure spark pools, load libraries etcetera. But instead, make use of the knowledge you already have in your team(s), let each and everyone do what they’re good at. That means that everyone should be open for new opinions and insights, while it should never be the goal to change everything. Together you have to make compromises and extend the administration team.

What is really the difference?
Then there was that architectural standpoint, where they typically don’t want to have all sorts of additional lake houses and warehouses being created if their enterprise data platform is outside Microsoft technology.

Honestly, I think the architects have to face reality in this scenario. What is really the difference between taking a copy of your enterprise data platform to a Power BI Dataset (semantic model – I should say) versus having the data in another artifact. Nothing if you ask me at least. The fear often lies within the danger that users might transform data and join together with other sources which might lead to wrong results. Though, that is exactly what users can do in Power BI as well. So again, what is really the difference?

Looking at the potential of Fabric, you’re don’t have to take copies of your data when you set it up correctly. Of course you can, but you don’t have to! Redesign your architecture and make use of the potential of shortcuts and mirroring capabilities to bring your data into Fabric, setup security and reuse the data from a single copy in different solutions. Let users do ad-hoc analysis in notebooks for the more tech-savvy users, or leverage the potential of visual queries and Power BI Semantic Models for the lesser gods.

Is Fabric not providing the oversights, or is your tool not ready for it?
When you look at data lineage and data management, we should not underestimate the importance of this topic. Lineage in Fabric is limited to artifact level, but you cannot trace on table or column level what is being used where. It is what it is, but has this really been different with Power BI in the past? Or are we just forgetting about that because we had lineage in order for the data platform, but we now stretch the self-service area a bit further due to which it becomes a problem? You tell me ;).

If the native lineage view in the workspace is not enough to get your started, what you can do? The scanner API might be the way to go for you! It is out there for a while already as part of Power BI. But given Fabric workspaces and Power BI workspaces has become one, the scanner API also provides insights in all other Fabric artifacts. Next to that, the Fabric REST API, also offers Admin APIs that allow you to explore all Fabric artifacts in a tenant.

I do admit that more fine-grain insights are needed on the long run. Though, when alternative tools are used to take care of data lineage and management, often the tool is not ready for Fabric yet. It’s not a Fabric problem, but more on the other side. The APIs are there to provide insights and build the integration.

CoE / BICC as central team
Adoption is definitely a good aspect to take into account when you’re release a new tool / platform like Fabric. A Center of Excellence (CoE) or Business Intelligence Competence Center (BICC) if you will and should play a key role in this. Take the users on a journey during through Fabric, show them the potential and organize in-house show & tell sessions. Even consider setting up training and let your users follow the Microsoft Guided Learning for Fabric to become more aware of all the powerful tools they have at hand.

Of course, you don’t have to open up Fabric for the entire organization yet. Enable Fabric for a small group in the organization for example to gain some first experiences rather than holding back. Maybe even consider a growth-path where users first have to complete the guided learning or even the recently announced Fabric certification DP-600 before they can make use of the full potential of Fabric.

Having a CoE playing a role like this, is not a one-off. It is a continuous responsibility where frequent activities have to be organized, guidance has to be provided and support to be offered in order to have a successful implementation and adoption.

Final thoughts

Of course, there are still gaps in what Fabric offers and what you might want to have within your organization. However, now is the time to start embracing Fabric if you ask me. The argument of the preview state is behind us and all other arguments can be overcome if you ask me. Logically, not everything will be perfect, but when time goes by, things will improve! Especially given the fast-paced development of Fabric over the past months and that will continue going forward in monthly release cycles, just like Power BI has always done over the past years.

In the end, governance across your entire platform is key to make sure your data is secure, reliable and stable. To make sure users make decisions based on the right data, implement endorsement with a set of policies and guidelines about when something is promoted or certified. From a security perspective, think about applying mandatory sensitivity labels to all artifacts to help secure your data wherever it goes, whatever artifact is used even outside of Fabric.

It all comes down to having a good conversation. Listen to each other’s arguments, but most important be open for the concerns, ideas and suggestions! One thing for sure, do not continue to hold on to what you’re familiar with and fits in your comfort zone. Otherwise, you will be easily overtaken by reality! Fabric is there, drive innovation within your organization by giving your users powerful tools to do their data analysis and reach a competitive advantage!

I’m curious to hear more from you! What are the challenges you run into when enabling Fabric? What concerns do you have or hear in your surrounding?