The New Era of Power BI Dev: An Interview with Rui Romano

OK guys, firstly, thanks for having me – it means a lot…and let me start with a little bit of history.

I’m a former Power BI developer. I worked in consulting for about 15 years, starting as a developer and eventually managing data teams at a company called DevScope. I was also a Microsoft Data Platform MVP, and I became known for talks about Power BI hacks – tips and tricks that, luckily, aren’t needed so much anymore. These included things like version control with PBIX files, using internal APIs, and optimizing development through manual workarounds or community tools like pbi-tools or Tabular EditorI felt all the same pain points as any Power BI dev.

Exactly. I always had a dream of joining Microsoft – more specifically, the Power BI team. I’ve been working with Microsoft BI technologies since SQL Server 2000. I saw it all: Power Pivot, Analysis Services multidimensional, then tabular… and when Power BI came along, it completely changed the game.

What really excited me was the ability to spin up an Analysis Services model in seconds. I come from the days when just setting up the environment took one or two weeks. Clusters, hardware, configuration – the works.

So I fell in love with Power BI right from the start. Eventually, I got the opportunity to join Microsoft – first as part of the Power BI CAT team.

It’s technically part of the product team, but it’s more like the voice of enterprise customers within the team. It’s still a kind of consulting role – you talk to customers, understand their pain points, and bring that feedback directly to the product group.

I was lucky to join under Chris Webb – an amazing manager – and I got to work with legends like Phil Seamark, Adam Saxton, Patrick LeBlanc, Alex Powers, Matthew Roche, and many others. Honestly, it’s a dream team of Microsoft data professionals.

And especially Chris Webb – I think I told him this, but he was the first person I ever followed in the data space. His blog helped me a lot early in my career.

I really enjoyed my time on the CAT team, but when the opportunity arose to become a Product Manager working on features I’m truly passionate about – like Developer Mode, TMDL, PBIR, and Git Integration – I couldn’t pass it up. I’m now a PM on the Power BI team in Fabric, focusing on features to make the enterprise-grade pro developer successful with Power BI in Fabric.

I started on the Enterprise BI team with Christian Wade, and the goal was clear: make Power BI work for professional developers.

We’re talking about people who work in teams, who need CI/CD, version control, repeatable processes – people like I used to be. We want Power BI to support that developer persona in a real, first-class way.

Exactly. Power BI is – and always will be – a self-service tool. That’s its strength.

But that doesn’t mean devs should have to use external tools, hacks, or workarounds just to get things like source control or automated deployment.

And while we’ll never turn Power BI Desktop into Visual Studio – we came from that world – we aim to deliver a streamlined experience for users who prefer coding, while deepening integration with best-in-class development tools like Visual Studio Code.

We just need to do it without making the product intimidating or unusable for regular business users.

Now with TMDL and the new project file format, everything’s cleaner, more controllable. Can you tell us how it started – and what makes it so powerful?

Yeah, I’d love to talk about TMDL. One of my colleagues even joked on Twitter a while ago: “Find a partner that loves you the way @RuiRomano talks about TMDL.” And yeah – it’s true. It was love at first sight.

But I don’t want to take all the credit. One of the things I’m most proud of is that TMDL came from the community.

It was started by Mathias Thierbach, who worked super closely with the Product team as part of the Community Program. He was one of the main architects early on.

When I joined the team, TMDL was already in motion. My job was to help guide it safely to where it needed to go. It’s been a team effort – Microsoft and the community – and I’m really proud of that, especially coming from my own background as an MVP.

At its core, we needed a clean, readable, source control–friendly format for semantic models. JSON – the old format – just didn’t cut it. It was hard to read, hard to merge, and impossible to work with when it came to DAX and Power Query code.

You couldn’t just open it up, copy and paste a measure, or compare two versions easily. So one of the big goals was to fix that: better readability, better merge conflict resolution, and just a better dev experience overall.

Absolutely. TMDL isn’t just a format – it’s a language.

And that’s where it gets really exciting. Because it’s a language, we can build a whole code experience around it. In fact, we already have.

You can use Visual Studio Code with the TMDL extension we built – it gives you things like semantic highlighting, IntelliSense, tooltips, error diagnostics, fixing duplicate lineage tags… everything you’d expect from a real programming environment.

We’re getting there. Right now, it’s ideal for certain tasks – like adding a new table, creating a set of measures – where opening Power BI Desktop isn’t worth the time.

In the near future, I can see people using auto-snippets or templates to create entire semantic models in TMDL. The point is: it’s about choice.

If you’re comfortable in code, now you’ve got the tools to stay there.

That’s a huge part of why TMDL is such a disruptive shift.

We’re living in the age of GenAI, and one thing AI is extremely good at is working with code. If your semantic model is represented in code, then AI can help you write it, refactor it, repeat tasks, and more.

And because TMDL is readable, you can see what the AI is doing and instantly know whether it’s right or wrong and continue iterating.

So it’s not just about better source control – it’s about making you more productive as a dev in this new AI-driven landscape.

Yeah, let me unpack that a bit.

First, we actually shipped TMDL before PBIP – around April 2023. That initial version was for Analysis Services users working with tools like Tabular Editor. We added it as a serialization option in the TOM API.

PBIP came later, in June 2023, but even then, the model part was still saved using the older JSON-based BIM format.

Exactly. PBIP introduced two new things:

• The TMDL format for semantic models
• And the PBIR format for reports.

Before PBIR, reports were stored as a single JSON file called report.json, also referred to as PBIR-Legacy. This format was never officially supported or documented for making modifications. PBIR represents a significant advancement—it’s now fully supported to edit Power BI reports using code, and it’s backed by comprehensive documentation, including updated JSON schemas published monthly.

Now, when you save as PBIP, you get both: the model in TMDL, and the report in PBIR. And yes, this is source control–friendly, but that’s not the only reason this matters.

That’s exactly it. People see PBIP and developer mode and go: “Oh, this is just for versioning.” But it’s way more than that.

The PBIX file is still the default – and I think it always will be, because it’s easy. If I want to send you a report, I can just drop the PBIX in OneDrive or Teams. Done.

But PBIP is a different thing. It’s for pro devs who want to better collaborate with each other, to work with code, be in control, inspect what’s going on, reuse components, and build reusable templates.

Exactly. You can inspect a measure, a Power Query step – without opening Power BI Desktop.

That’s a huge productivity win. Especially with large files where Desktop takes a while to load. You can copy/paste code, pull in calendar tables, theme files, even template pages.

We see PBIP as a foundation for reusable, modular BI development – not just version control.

You’re absolutely right – and that’s where the hardening work comes in.

PBIP isn’t just “dumping files into a folder.” It’s a supported, code-based development model. And that means we’ve had to make Power BI Desktop OK with changes made by external tools or by hand.

That’s been a major investment: we’ve published schemas, built validation into Desktop, and now we’re working on opening even more scenarios.

For example, right now, if a semantic model has multiple partitions, Desktop can’t open it – that’s changing. With TMDL View, we’re making it possible to open and edit these models even if they include advanced features Desktop doesn’t have UI for.

Definitely. Today, if you use Tabular Editor to create a new table or edit Power Query code, things might break. But once we finish this hardening work, that goes away.

Power BI Desktop and external tools will coexist better, giving developers real flexibility and power.

Yeah, definitely. I named it Code, Collaborate, Accelerate because those three words capture where we are now in the evolution of Power BI development.

• Code is all about what we’ve just talked about. Power BI Desktop now opens up your entire project in a code-friendly format – TMDL, PBIR, PBIP. You can finally see and understand what’s under the hood.
• Accelerate is what happens once you’ve got that control. Now you can script things. You can automate repetitive tasks. You can apply patterns across many files. You can use AI to help you. That’s a big deal – especially for self-service users who suddenly find themselves maintaining 1,000 reports and need to change a logo across all of them.
• And Collaborate – that’s about bringing this all into a team environment. Using Git. Working with others. Building solid CI/CD pipelines. Power BI development has become collaborative in a way it never was before.

The point of the session is to show developers that there’s a new way to work – and even if you’re not a hardcore coder, knowing these capabilities exist can save you days of work or unlock totally new ways to build.

Well, first off, I’m always open to community and conference events – I try to say yes whenever I can.

It’s not always easy – I have three kids, and anytime I go somewhere I need to figure out the logistics back home. But this time, the timing worked out. And honestly, when you guys asked me to do the keynote, that really caught my attention.

I’m not the “big roadmap keynote” kind of person. I’m not going to do a sweeping overview of Microsoft Fabric from end to end. I’m focused – I care about the Pro Dev experience. And you told me that’s exactly what your audience wants – more depth, more advanced topics. That really clicked with me.

This is actually my first keynote ever, and I love the challenge. The conference looked well organized, good attendance, strong energy. It felt like the right fit.

Nope – and that’s on purpose!

I try not to research the food ahead of time. I like to arrive with no expectations, just go out and try what’s traditional. I did that once in Poland – loved all the soups – and then afterward I looked up what was in them and thought, “yeah, maybe I wouldn’t have tried that if I’d known.”

So I trust you guys to point me in the right direction. Just tell me what I should try, and I’ll be all in.