What Microsoft Fabric means for your semantic models: New options and approaches
IN FABRIC—LIKE POWER BI—IT’S ALL ABOUT CHOICE
…and choosing the best approach for your specific scenario, needs, resources, and way-of-working.
Semantic models are integral to Microsoft Fabric. They use and are used by many of the different workloads. In Fabric, there’s more items that can connect to and consume your model—such as semantic link in notebooks. Because of these new options and tools, your model is exposed to additional types of users who will use it in different ways. As such, it’s important that you make good models that you manage well throughout their entire lifecycle.
To help you do this, Fabric provides several new tools and features that you choose from when you develop and manage your model. Examples of impactful changes are as follows.
Semantic Link in notebooks: Consume and manage semantic models from notebooks by using PySpark or Python. Semantic link opens up the semantic model for programmatic analysis and automation of tasks.
Direct Lake storage mode: Connect to delta tables stored in OneLake to query it directly. Direct Lake promises performance benefits particularly for teams that struggle with DirectQuery or who have very long refresh times of exceptionally large import models.
Git integration for Fabric workspaces: Connect a Fabric workspace with an Azure Repos Git repository to sync TMDL metadata (either in a Power BI Projects .pbip file or managed separately by using Tabular Editor). This lets you perform source control and streamline deployment of models.
Goblin tip:
Most teams can benefit from the new notebooks and semantic link in Fabric. These tools can broadly apply to many different scenarios and use-cases, as you'll see in these articles.
In this article, I explain how you should approach these choices, and what they mean for the models that you build and manage. In three follow-up articles, I’ll illustrate these choices by describing three real-world scenarios. In each of these scenarios, there’s a different team who manage semantic model in Power BI today, and who will migrate that model to Fabric. We’ll look at the choices that these teams make, why they made them, and what the result is for their workflow. None of these scenarios reflect an advised/endorsed or reference architecture; none of them are ideal, yet each of them represent a valid approach to get value from a semantic model.
The purpose of this article is twofold:
1. To explain the importance of a semantic model in Fabric.
2. To emphasize that there's many equally valid approaches to build and manage a semantic model. You should choose what's most important is you choose the right options for your scenario.
This article is intended to be informative; I'm not trying to sell you Fabric or endorsing a tool, feature, or approach.
VIDEO ARTICLE
The video version of this article series is available in several videos which you can find here.
FABRIC PROVIDES MORE CHOICE
Making a good model is all about making the right choices during its development and lifecycle. You make these choices throughout the development process at many different stages. You already had to make these choices with Power BI, and now, Fabric provides you with additional options.
By using these options when you need them, your semantic models have the potential to deliver more value to more people. However, just because there’s new features and approaches does not mean that you need to use them all for your scenario.
CHOOSE WHAT BEST FITS YOUR SCENARIO
You should choose these new options and use these new features when they can alleviate a pain you have now or in the near future. Alternatively, they might provide an opportunity to improve the value of what you already deliver today.
What’s most important is that you select the options that best fit your needs, workflow, skills, and available resources. You can and should be aware of what options are out there, including their various use-cases, limitations, and considerations.
For instance, features like Direct Lake or Git integration bring many new interesting possibilities. However, migrating to Direct Lake means that you have to learn new ways of managing and optimizing your model. There’s many new considerations when you manage a Direct Lake model, from managing fallback behavior to DAX query times when data is paged out of memory. Additionally, Git integration doesn’t support all item types or items that use sensitivity labels. You might still opt to use import or DirectQuery storage modes or perform source control by using other methods, which can be perfectly valid approaches if that’s what you need or want to do.
A Goblin warning about features in public preview:
Many of the new features in Fabric are in preview. When you use a feature in preview (as opposed to one that is generally available, or GA) it means that there can be some unexpected issues, which Microsoft support might not promptly address.
There's a culture of promoting and endorsing preview features in the Microsoft community. For example, I often discuss using the Power BI Projects (.pbip) file format, because it lets you track changes and improve productivity for some tasks with minimal risk. When you consider a new feature, check first whether it's in preview and factor that into your decision about whether to use it or not. You should find this in the official Microsoft core documentation about the feature. You should also put the feature through testing yourself before using it.
Preview features shouldn't be avoided; they can deliver value when used responsibly. However, the typical advice is not to use preview features for a production solution.
THREE EXAMPLE SCENARIOS
In the next three articles, we’ll examine three examples of teams that go from managing their semantic model in Power BI to Fabric. These teams, their models, and their needs are completely different, as you’ll see. This means that they make different choices for what to use and how they use it. Again, none of these teams reflect an advised or endorsed approach; this is simply what works best for them, today.
Goblin tip:
Come back to this article on or after March 23rd for the video version, which will contain specific examples and demonstrations for each of these scenarios.
SCENARIO 1: DATA SCIENTISTS IN A SMALL BUSINESS TEAM
This team are a small group of analysts embedded in a demand planning team. They help that team with supply chain and inventory reporting. These analysts don’t have much experience with Power BI, and are more comfortable using various data science tools. Unfortunately, however, they don’t have access to organizational architecture, and are forced to perform much of their analyses locally. The way that this team works today provides a lot of headaches for the central IT team, who try to oversee and govern their Power BI environment.
Today, this business team struggles to use and get value from Power BI with their skills and way of working. They hope that Fabric will provide them more flexibility and agility to support their needs.
SCENARIO 2: ANALYSTS SUPPORTING MANY SALES TEAMS IN A REGION
This team are a decentralized group of analysts who deliver reports and models for sales teams across their region. They are more experienced with Power BI than the first team, and have a pretty structured workflow. For instance, they are using OneDrive for version control. This team has defined a clear, structured process to check in and check out files, and use OneDrive Refresh to sync .pbix files to the workspace. However, they struggle with the performance of their model refresh and their DAX. They also regularly have issues with their updates disrupting business reports.
Today, this team delivers value with Power BI. They wonder whether they should migrate their model to Direct Lake and start using Git integration, though they don’t know anything about Git or source control.
SCENARIO 3: ENTERPRISE BI TEAM
This team are a centralized BI team who deliver models and reports for consumption throughout the organization. They use Power BI together with Azure DevOps and external tools such as Tabular Editor to manage their model. They use Tabular Editor and Azure DevOps for their model so that they can save their model as a .bim file to track and manage changes and also work collaboratively. They deal with large models (billions of rows and high complexity). However, this team finds their current process complicated and difficult to manage. They are looking for a way to better scale their models and how they manage them.
Today, this team struggles to scale Power BI. They hope that features in Fabric will help them with their enterprise scenarios and needs.
TO CONCLUDE
There’s many new choices and options for you to get more value from your semantic model in Microsoft Fabric. However, it’s not necessary to use these features if you don’t need to or want to. You should make choices that best suit your specific scenario; your needs, workflow, skills, and available resources. Ensure that you’re aware of the available options, their use-cases, and their limitations, but don’t just use them because they’re there.
