Livadata

Fresh out of SQLBits 2025, having just delivered my session on Friday afternoon, I thought it would be a good time to recap on the blog why I chose to focus on this topic this year.

People who work with me know me as a specialist and advocate of Power BI Governance. At Dufrain, my team have designed a framework that allows us to quickly assess the health of an organisations Power BI maturity, implement critical fixes, and define remediation plans. We do this across People, Process and Technology. When I say “Power BI Governance”, I think the first thing that will come to mind for people will be workspaces, access, sensitivity labels, deployment processes. All of this is great, but none of it really means anything without understanding the People element of the BI team first.

I look at 3 key areas within People: Are Roles Defined? Is there a Centre of Excellence Thriving? Is Training & Upskilling a Focus? Starting with roles, there is an expansive list of job titles in the data sphere. This is not about recommending 10 new hires in order to be a leading BI team. It’s about identifying the hats that need to be worn in a BI team, defining their remit, and then making sure the right people in the team are wearing those hats.

This visual articulates the range of roles that we should consider, and how these might manifest in a small IT team of 3, versus a large organisation’s federated data culture. For example, I note 4 admin roles. In some teams, one person might be all of these. What’s important here, is not taking the most senior person and lumping them with every privilege available. It’s about identifying the nature of these admin roles and granting the right people the explicit remit. Let’s take Pipeline Admins – my view is that if you are early in rolling out a deployment process and using Fabric Deployment Pipelines, you should limit this role to a small number of trusted people. Their remit is then to control the flow of change to production, ensuring peer review and testing is complete and adhered to. Capacity Admins – if you are a multi-capacity organisation – particularly if this is for geography reasons – it may be the right organisational fit to delegate Capacity Admin to regional teams to empower them to manage their own performance. Particularly if that area of your organisation is paying for their own capacity! It’s about assessing the responsibilities of that role, assessing the maturity and capability of your organisation, and aligning as such.

BI Business Partnering is another one I like to call out. This is a role I don’t always see explicitly defined, but where I do it works very well. A common challenge we see clients face is how to get away from their backlog mountain of tickets and change requests, stop firefighting, and start proactively delivering value for the business. One key to this for me is championing a technical person whose role is focussed on being as close to the business as possible, understanding the challenges they face and what will make their lives easy. Sit with them when they are crunching numbers in Excel and truly understand what they need in a way they can rarely articulate in a ServiceNow report request. This role can often be combined with people management responsibilities, and so large BI teams can see BI Managers taking on this role. What I have seen work very well, is BI teams defined as 3 functions: BI Business Partnering, BI Engineering, and BI Visualisation.

This brings me on to my key point: how do we get all this right, in a Fabric world?

Fabric presents a massive opportunity to revolutionise the way we operate with data. In the short term, I am seeing cultural challenges with what it looks like to adopt. In the past, many organisations kept engineering teams here, and analytics teams there. I’ve worked with some organisations where they barely know each others names never mind have any regular comms! In the days of SQL Servers here and Power BI Platforms there, there’s an argument this is ok. (I would not make this argument – my view is that BI teams are a vital part of the data modelling process. And no – giving the BI team a reporting schema and leaving them to it is not the answer). However what we see with Fabric, is the engineers and BI teams are now existing in the same platform. The same environments. A key question arises: who owns a Fabric platform? For many organisations, BI teams have owned the Power BI tenant and capacity for years. They are now faced with ever changing tenant settings that are often outwith their core skill set to manage, and demands to share capacity ownership. The renewal process taking place this year from P SKUs to F SKUs is accelerating this debate. So what’s the answer, hand over the keys to engineering? Well if you know me at all, you’ll know my answer to that!

BI teams on the mid to advanced scale of maturity have years of experience managing this platform, optimising it and governing it. My view, is that organisations need to enable collaborative design forums to review governance plans, undertake shared Fabric Adoption initiatives, and design processes that identify BI tenant settings (can people export to excel?) engineering / architecture tenant settings (enabling preview features like user defined functions and SQL Databases), and shared tenant settings (who can create new workspaces?).

I also spoke in my session about how BI teams can get started with Fabric. It’s easy to feel overwhelmed with the sheer amount of content out there, and pressure to keep up. My advice is:

• 1. Pick your use case. Don’t spend forever trying to ingest all your data sources and perfectly transform and model them before anyone has any use out the thing! “Doing Fabric” is exciting to us techies, but it won’t always be exciting enough to get budget from your business. Think of a business value focussed scenario, covering a thin slice of your data world, and just deliver that at first.
• 2. Unpick that Power BI Tech Debt… let’s not be taking those naughty Power BI models that have grown arms and legs with 50 Power Query steps and spaghetti schemas and just repointing to a new source. If you’re about to share a capacity between your engineering and BI workloads, it’s time to optimise. Often these legacy models are only how they are because of gaps in engineering accessibility, whether that be cultural or technical. No need to spend days going down the rabbit hole of what your models are doing now – identify your metrics and attributes (the ones you actually use that is!), the data sources that feed them and any critical logic, and start with that.
• 3. Choose appropriate Fabric Architecture. There are many blogs out there debating the “right approach” to design Fabric solutions. Notebooks or Dataflows? One workspace or Three? Medallion or something else? My only input on this, is that for your first use case – all that matters is it’s accessible to your team. If your team don’t know PySpark but are Power Query whizzes, get those Dataflow Gen 2’s out and have a ball. If you want to productionise and scale your work later, you can work with engineers to repurpose your proof of value into Notebooks.
• 4. Augment your use case. There is more exciting Fabric functionality out there than you can shake a stick at. My advice is to get stuck in and have a go. See what works and what doesn’t. Take what is relevant to your teams and progress with that. Data Activators alerting and insight driven actions are very impressive. Purview is developing quickly to make Data Quality and Governance easier than it ever has been. Azure AI Foundry is (terrifyingly) impressive and accessible. Real time Analytics. Translytical Features. The list could go on!

I’ve uploaded my slides right here if you want to see the full material, and when the SQLBits sessions hit YouTube likely later in the year I’ll update this blog with a link.

I’ll close off here by saying SQLBits really is a fantastic conference. Four whole days of community led content, I took so many notes away on new Databricks to Power BI Architecture patterns, Power Query error handling functions I’d never seen, and Responsible AI principles and practices.

SQLBits 2026 has already been confirmed for April next year – and until then, you’ll find me blogging hopefully more regularly here at Livadata!