Back in June the guys in cubes at Guy in a Cube were joined by Daniel Otykier and Marco Russo for a live stream on YouTube. Daniel is the creator of Tabular Editor, a powerful tool for developing Analysis Services Tabular data models and Power BI datasets. Marco is one of the Italian Data Models behind SQLBI.com, and is a recognized expert on tabular development and DAX.
This special live stream was a Q&A session with Daniel and Marco about the then-new announcement of Tabular Editor 3, an improved and expanded paid version of what had previously been a free, community-supported too. I watched the stream to learn what the excitement was all about, and to see if there were any off-topic questions I could answer in the chat.
Quite a few questions came up where the term “desktop hardening” was part of answer. Questions like this one:
I strongly encourage you to watch the live stream replay for the questions and discussion. Daniel does an excellent job of describing how Tabular Editor uses Microsoft’s Tabular Object Model library to modify tabular data models, and some of the complexities of what’s allowed or not allowed depending on where a given tabular model is located – and I’m not going to attempt to replicate his wisdom here.
What I am going to do here is talk a little about “desktop hardening,” which is a term I’ve heard hundreds of times in meetings and work conversations, but which I discovered is practically undefined and unmentioned on the public internet. The only place where I could find this term used in context was in this reply from Power BI PM Christian Wade… and if you don’t already know what “desktop hardening” is, seeing it used in context here isn’t going to help too much.
Here is my definition of desktop hardening:
Desktop hardening is the internal shorthand used by members of the Power BI product team to describe a broad set of ongoing investments to expose the full contents of the Power BI Desktop PBIX file format as a supported public API.
There are a few things worth picking apart in this definition. Let’s start with “public API,” and let’s start by clarifying I don’t mean “REST API” or “.NET SDK” or anything of the sort. In this post I’m using the broadest possible definition of the term API, which to me is “a set of functionality that can be accessed programmatically.” More on this below.
As this excellent post from API Academy highlights, a public or “open” API “is an interface that has been designed to be easily accessible by the wider population of… developers” and that “opening an interface to external developers can significantly add to the management and security challenges associated with publishing APIs. For example, with many third-party client apps active in the field, it can be very challenging to ensure that interface updates do not break application functionality.”
Conversely, “Private APIs can significantly reduce the development time and resources needed to… build new systems that maximize productivity and create customer-facing apps that extend market reach and add value to existing offerings.”
In my experience, a private API can be updated with minimal or moderate effort. By definition it’s only being called by developers in your organization, so if you need to make a change you let them know and they update their client code. On the other hand, updating a public API is very complicated and very costly, especially when there are legal and/or regulatory requirements that need to be met. When updating a public API you need to worry about a thousand different things, from documentation to backward compatibility. These considerations make every aspect of maintaining the API slower, more complicated, and more costly. Forever.
Now that we’ve looked at the “public API” part of the definition, let’s also look at the “Power BI Desktop PBIX file format” part.
The Power BI Desktop authoring tool uses the PBIX file format, which is implemented similar to the Open XML format introduced in Office 2007. Each PBIX file is basically a Zip archive that contains a set of folders and XML and JSON files. Each PBIX file contains the tabular data model, reports, Power Query mashups, and related metadata for the a Power BI solution. MVP Gilbert Quevauvilliers of FourMoo explored the contents of the PBIX format if you’re interested in taking a closer look.
Now let’s look at the “ongoing investments to expose the full contents” part of the definition.
As of today, only a limited number of operations on the tabular data model in a PBIX file are supported for write operations. These operations were exposed as part of the Power BI team’s addition of external tools support to Power BI Desktop, and are documented as part of the docs for external tools.
Today if a given operation isn’t on that list, it’s not supported for use by any client other than Power BI Desktop. If you edit another part of a PBIX, directly it might be OK, but it might not – your edit might make the PBIX unable to be opened by Power BI desktop. And even if a given operation might work today, it might not work tomorrow. That’s how private APIs work – the API owner can make changes at any time, and any client application or process that relies on the unsupported private API may be broken.
I should also point out that the scope of desktop hardening isn’t limited to external tools like tabular Editor. It also includes:
- The ability for Power BI Desktop to accept dataset definitions that include features that currently cannot be built in Desktop, such as Partitions and DetailRows.
- The ability to download a dataset defined or modified using the XML endpoint in the Power BI service as a PBIX file or PBIT template.
- The ability for Power BI Desktop to accept dataset definitions that are produced as part of a git workflow or similar process where a developer might programmatically “merge” changes from multiple branches.
The Power BI team has a goal to provide a public API for everything in the PBIX file (that’s what “desktop hardening” means, remember?) but it’s a long-term goal. You can keep an eye on the public roadmap at https://aka.ms/PBIReleasePlan, but I expect the full vision of desktop hardening to be delivered incrementally over time, rather than in one big release. Desktop hardening isn’t a feature – it’s a bunch of related features and non-feature investments. Because of the ongoing implications of having a public API, it’s important to do things right, and the complexity of this effort cannot be overstated.
That brings us to the final part of the definition I want to explore: the term “desktop hardening” is an “internal shorthand” used by the product team. This isn’t a term that is ever likely to show up in official Microsoft documentation, but it’s become part of the team vocabulary, and has unfortunately leaked into public community conversations as well… sort of like an unsupported API.
I hope that the next time you hear someone talking about desktop hardening you’ll have a better idea of what this term means, and I hope that the next time you hear someone asking about it you can direct them to this post.
 Back in June when I started writing this post, which might give you an idea of how my 2021 has been going.
 Think about it. “Marco” and “Alberto” have become mononyms not unlike “Fabio”. Also, they’re all Italian, they’re all absolutely beautiful people, and their names always come up when you’re talking about modeling. Seriously, I’m right and you know that I’m right.
 Guy in a Cube live streams are usually more “ask me anything” Q&A sessions rather than focused on a specific topic, and there are always more questions than there’s time for answers. Adam and Patrick were kind enough to make me a moderator of their channel, so I do what I can to help out.
 Foolish enough.
 This is where I add the standard disclaimer that although I am a Microsoft employee and a member of the Power BI CAT team, this is my personal blog and all information here is my opinion and does not necessarily reflect the views of my employer or any of my cats, etc., etc.
 Somewhere an engineering manager is screaming and/or crying as they read this. Updating private APIs can indeed be complicated and costly – just not when compared with updating a public API of similar scope and complexity. When you’re building, shipping, and maintaining software that is used by millions of people around the world, nothing is actually simple.
 Thanks a million to the engineering manager who took time out of his busy day to provide constructive criticism on an earlier draft version of this post, and to let me know that he felt my definition was too constrained, and that my examples were too sparse. This list of additional examples is based on his feedback – thank you, Akshai!