Book Review: Architecting Power BI Solutions in Microsoft Fabric

I was pleased to recently get to review a new book by Nagaraj Venkatesan called Architecting Power BI Solutions in Microsoft Fabric . Nagaraj was an MVP for two years and now a cloud solution architect working for Microsoft.

NOTE: I reviewed the book while it was in preview.

I liked the way that Power BI was discussed for different personas: Business Users, Data Scientists, Administrators.

I was puzzled to see a requirement in the front matter for Angular 9, TypeScript 3.7, and ECMAScript 11. I couldn’t find any relevance to them in the book. Hopefully it will be removed before publication.

Power BI

The book starts with a quick coverage of using Power BI in the most common scenarios.

It was good to see him mention that Azure Analysis Services is another choice for a dataset. Most people from Microsoft seem to now ignore it. (I do wonder if it is already abandonware, even though it was a great product).

I really, really wish Microsoft provided an easy option to not prepend schema names when importing tables, rather than having to rename them later. In the book, there are examples with table names like ‘SalesLT SalesOrderDetail’. I never want to present that to a user.

While most people use Data Flows, they certainly aren’t the option that we use most. I would like to have seen other options discussed. SQL code can often lead to much higher performing transformations. Many transformations in Power Query and/or Data Flows are single-threaded.

Content

It was good to see Power BI Report Server discussed but what seemed to be missing was a discussion on just how limited that option is, even for simple reports. Most people are entirely underwhelmed when they try it, and it’s not the advanced features that are missing that leads them to that.

I’d like to see the content on Real-time datasets removed. For better or worse, they are deprecated (which is noted in the book).

It was good to see A SKUs discussed. Most books omit them.

I can’t agree with “Power BI datamarts are a powerful feature”. I’d say “Power BI datamarts have no future and shouldn’t be used”.

Writing and editing quality was overall good. I did see some minor typos like “Refere to”.

Licensing

I never know if discussing licensing is a good idea or not, given the rate at which it changes, but there was a good discussion provided on the current state of Power BI licensing. It’s already wrong though, given the announcements regarding CoPilot at this year’s FabCon. That also applies to the feature comparison chart which now also needs updates

I also understand the urge to put pricing in the book, but that’s something I really think should be omitted. It’s also already out of date.

Enterprise BI

There is a section called Designing Enterprise BI Solutions. It has 7 chapters. One is on semantic model security, but I would like to have seen many other security options discussed. For example, workspace identity is now a critical issue yet it’s not discussed.

I liked seeing a discussion on issues related to semantic models fitting into available memory. We spend a lot of time on optimizing models to reduce their memory footprint.

Naming is always a topic that leads to arguments, but I’m pretty anal about it. For example, I was ok with “product”, “customer”, and “store” being dimensions, but why then “Transaction_dtls” for a fact? Note the change of case, and the move to a group term rather than a singular term. Why not just “transaction”? Similarly, I’d like to see “Transaction_dtls-Agg” have a name that relates to what’s in it, and why, rather than how it’s implemented. And later, there’s a table called “transaction_table” with columns “Product_id”, “Store_id”, “Transaction_date”, “Units_sold”, and “SaleAmount”. Not for me, sorry. There’s just so much inconsistency there.

Datamarts and Data Stores

In “Deciding on an Intermediate Data Store”, the options are Dataflows and Datamarts. But this totally ignores the other common option which is some form of database or data warehouse. It’s hardly revolutionary to think that when you need to store data, particularly tabular data, that you might use a database. There are extraordinary tradeoffs that you make when you choose to put data in a data lake instead.

Datamarts annoy me. We spent years describing why we still used databases for underlying data warehouses, and Microsoft constantly told us we didn’t need one. Then they introduced Datamarts which are databases, but ones that are badly designed, and that you have little control over. Why not use a real one? Azure SQL Database is a great product. Datamarts have no future, and I think all the content about them would be best replaced with a gentle “just don’t use them” piece of advice. I was telling people they were a bad idea when they were introduced, and they’re still a bad idea, now even worse because they really just don’t have a future. In the book, it’s noted that they’re still in public preview. I can’t see them ever going to GA (general availability) because they just don’t fit with the directions that Microsoft seem to be heading in.

Fabric

The Fabric discussion follows the company line on why you’d use it instead of tools like Azure Data Factory (ADF), Azure SQL Database (ASD), Azure Analysis Services (AAS), etc. What isn’t mentioned, is that even though Fabric includes these abilities, it provides only a subset of the capabilities of the separate tools. For enterprise users, that’s a big deal. For example, ADF has far more sophisticated scheduling and parameter options than those in Fabric Data Factory. It also plays better with source control systems, than the clunky way that Fabric does.

It was good to see a discussion on scripting with TMSL for refreshes, etc. but the need to do this has been partially overtaken by the addition of a semantic model refreshing activity that has been added to Fabric Data Factory. I normally just use web activities to make REST calls, rather than needing to spin up python code to do this. That seems like an additional unnecessary layer, but perhaps ok if you want to do it from a notebook for some reason.

I was pleased to see partitions discussed. They are so powerful and an important aspect of most enterprise systems, yet they are so often ignored.

There are lots of mentions of the Vertipaq engine, and I understand why, but directions from Microsoft marketing seem to have replaced that term with XVelocity for the in-memory technologies.

Optimization and Integration

I loved the chapter on optimizing semantic models. It’s a great coverage of the topic, including the use of Vertipaq Analyzer within DAX Studio, and other tools. Similarly good to see the discussion on query folding, and on how to fix performance problems from the visualization layer.

I was surprised but pleased to see the discussion on integrating Power BI with Microsoft 365 tools. This is a useful area that is routinely ignored in most Power BI related books. Similarly, the discussion on integrating with both Purview and Defender was useful.

Summary

Overall, while there are areas that I would like to have seen covered, and areas where I see things quite differently to the Microsoft company line that is presented, this is a very good book.

8 out of 10

2025-04-16