.png)
Microsoft describes three approaches to how MS Fabric and Power BI content is owned and managed and most people meet them as a tidy diagram: enterprise BI (Corporate BI) at one end, business-led self-service at the other and managed self-service in the middle. Microsoft presents them as a spectrum, a range you sit somewhere along rather than a set of steps. I agree with that, up to a point. Also, I want to be super clear, I am adding my own thoughts into this, from my own experience working with real clients. So yes, I may go away from what the documentation says, and where I do, I do it on purpose.
After years of doing this work, a single team does not land on the spectrum at random. It climbs, earning the next step rather than jumping to it. So the honest version is this: across a whole organisation these approaches operate as a spectrum, but for any given team they tend to build like a ladder.
Also, in the official Microsoft documentation these are referred to as strategies, but I refer to them as the deployment approaches. Why? Maybe I am still stuck on the original terminology from years back, but I hope it also shows you, the reader, that I have been living and breathing this for many years.
Summary
We have three deployment approaches: enterprise BI (Corporate BI), managed self-service and business-led self-service. They describe who owns and manages the semantic models, and who owns the reports, not three separate ways of running the platform. Microsoft treats them as a spectrum that an organisation operates across, often in several places at once, which is fair. In practice a team usually starts at Corporate BI to lay the foundation, moves up to managed self-service when it is ready, and only reaches business-led self-service when there is a real need and the foundation can support it. Business-led is not the goal, and not every team should get there, so tread carefully about moving there too quickly.
Key takeaways
- The three Power BI deployment approaches differ on one thing above all: who owns and manages the semantic models, and who owns the reports.
- Microsoft frames them as a spectrum with no hierarchy. At the level of a whole organisation, that is true.
- For a single team they behave more like a ladder. You climb when the foundation is ready, not because the next rung sounds more mature.
- Business-led self-service is not the target. Some teams should stay on Corporate BI or managed self-service, and that can be the right call.
- Governance does not disappear as you move up, it changes shape. With Microsoft Fabric, the same three approaches now apply at each layer, from the lakehouse to the report, not just once per team.
The three Power BI deployment approaches
Before the spectrum-versus-ladder argument, it helps to be clear on what the three actually are. They are not three products, thee features or three licences. They describe who owns what:
Enterprise BI (Corporate BI)
Semantic models and reports are both owned and managed by a central data team, whether that is the BI team, another data team or IT, it really depends on the organisation. This is the most controlled approach: it offers the most governance and the least flexibility and it produces a single version of the truth, because one team maintains the data and one set of definitions. The business are pure report consumers here, opening what is built for them and making decisions from it. The trade-off is speed, since every change goes through the central team.
Managed self-service
Semantic models are still owned and managed by the central data team, but more flexibility is now offered to the business. Report development is enabled on top of the underlying certified semantic models, inside the right guardrails, so think of one trusted data layer with self-service reporting built on it. It balances governance and flexibility, and for most organisations it is the practical middle ground. The business are report authors here, building on certified models they do not own, which lets people answer their own questions without every team inventing its own version of revenue.
Business-led self-service
Semantic models and reports are both owned and managed by the business. This is the least strict governance and the highest level of flexibility. It is decentralised and bottom-up: teams connect their own data sources, build their own semantic models and dataflows, and publish their own reports, with the central data team setting tenant-level guardrails and maintaining the wider governance rather than building. This can vary for each organisation. The business are owners here, from the data to the report. It is the most demanding approach, because the people doing it need real data modelling skill and a clear sense of ownership, and it needs to be considered carefully.
A spectrum, not a hierarchy: how Microsoft frames it
Microsoft does not present these as a ladder. In the Fabric adoption roadmap they are described as three valid strategies that an organisation operates across, often several at once, with no hierarchy and no one-size-fits-all. The roadmap's phrase for managed self-service, discipline at the core and flexibility at the edge, captures the idea nicely.
That framing is right. A large organisation really does run all three at once: Finance on tightly governed Corporate BI, a data-literate commercial team on business-led self-service, and most of the business somewhere in managed self-service in between. No single approach is better than the others in the abstract. The right one depends on the team, the data and the risk.
A ladder in practice: how teams actually move
Here is where I add something to the spectrum picture. While an organisation spreads across all three, an individual team usually travels through them in order. It starts at Corporate BI, where the foundation is laid. It moves up to managed self-service once that foundation is solid and the appetite for self-service is real. A smaller number go on to business-led self-service.
Both things are true at the same time. The spectrum describes where everyone sits across the organisation. The ladder describes how a given team gets there. I have rarely seen a team handed full business-led self-service from a standing start and make a success of it. The ones that thrive climbed to it.
Before and after Fabric: the same approaches, more to own
For most of the time I have been doing this, the approaches were simple to explain, because in a Power BI world only two artefacts really mattered: the semantic model and the report. So enterprise BI, managed self-service and business-led came down to who owns those two things, and that single dividing line, the model versus the report, did all the work. It is still the clearest way to teach it, and for most Power BI conversations it is the right level to pitch at.
The reason it stayed that clean is that everything upstream of the semantic model lived somewhere else. The warehouse, the data preparation, the data science work, all of it sat outside the Power BI service, often in another portal and owned by another team. They were genuinely separate workloads, so when you talked Power BI governance you could draw a box around the model and the report and treat the rest as someone else's estate.
Microsoft Fabric changes that in one specific way. It pulls those upstream workloads inside the same tenant, the same workspaces and the same permission model as Power BI. The lakehouse, the warehouse, the pipeline, the dataflow and the notebook are no longer outside in another portal, they are items sitting next to your semantic model and report, with OneLake underneath. This is exactly why Microsoft does not frame that roadmap page around reports and semantic models. They deliberately widen content to mean any data item: a notebook, a lakehouse, a dataflow, a semantic model or a report.
So here is the honest version, and this is my interpretation more than the documentation's. The three approaches have not changed at all. What has changed is the number of things the ownership question now applies to. It used to be a question about two artefacts. In Fabric it becomes the same question asked about a much longer list.
The bit I would add, that the docs leave you to work out, is this: the three approaches now apply per layer, not per team. A single team can sensibly be business-led on its reports, managed self-service on the semantic model, and strictly enterprise on the lakehouse that feeds it, all at the same time. The safe answer also trends more central the further upstream you go, because the skills, the blast radius and the cost of getting it wrong all rise. Business-led self-service over a report is a reasonable thing to hand a capable team. Business-led self-service over a lakehouse and a pipeline is a much bigger ask. So Fabric does not just multiply the artefacts, it raises the bar for how far up the ladder a team can safely climb for each one.
That is the real shift. Before Fabric, one ownership question, two artefacts, usually one approach per team. With Fabric, the same three approaches, but asked separately at each layer of the stack, and the right answer leaning more central the deeper into the data you go.
Start at the bottom: what Corporate BI gives you
Before the foundation is in place, a Power BI environment tends to look the same everywhere: duplicate semantic models, inconsistent metrics and conflict over which number is right, no clear ownership, and no controlled way of moving a change from development to production. People do not trust the figures, so they build their own, and the duplication gets worse.
Corporate BI is where you fix that. A central team owns the data, the semantic models and the workspaces, and produces reliable data with one agreed set of definitions. It is not the exciting part, but it is the part everything else stands on. I wrote about why this matters in the overview of the whole framework and in Don't Rush the Foundations.
Moving up to managed self-service
Once the foundation holds, managed self-service is usually the next rung, and for most organisations it is where you want to live. The central team keeps the certified semantic models and the security, while the business builds reports on top. Done well, it lifts adoption, because people can answer their own questions quickly, and it takes pressure off the BI team, because not every request becomes a ticket.
This is a big topic in its own right, so I have given it a dedicated blog: Power BI Governance: Balancing Control and Self-Service for Adoption.
Business-led self-service is not the goal
This is the point I most want to land. Business-led self-service is not the top of a ladder you are supposed to reach, and it is not a maturity badge. It is the right approach for some teams in some situations, and the wrong one for plenty of others.
Some teams should stay on Corporate BI, because the data is sensitive or the numbers are too important to hand over. Many should settle happily into managed self-service and never go further. Moving to business-led self-service is a decision you make when there is a genuine business need and the team is ready for it, not a destination everyone is marching towards.
Governance does not disappear in business-led
It is tempting to think business-led self-service means the central team steps back and the rules relax. It does not. The governance questions do not disappear, they change shape: who is allowed to build a semantic model, whether those people understand data modelling, ownership and security, who holds the right permissions, and what happens to data quality when more hands are involved.
Business-led self-service does not mean off you go, build whatever you want. It means a team can take on more ownership because the foundations, the processes and the people are mature enough to carry it. You usually have to widen your champion programme too, beyond report authors to model designers, data owners and data stewards, so the new ownership has support behind it.
How to know you are ready to climb
So how do you tell a team is ready for the next rung? A few signals, drawn from what tends to work in practice:
- The foundation is solid: agreed definitions, certified semantic models, and change control so an update moves safely from development to production.
- The business need is real: people are asking for the flexibility to answer their own questions, rather than being handed it because it sounds good.
- The people are trained: the ones doing the building actually understand modelling, security and ownership, not just how to drag fields onto a canvas. Knowing your way around Power BI Desktop is not the same as knowing how to build something others can trust, and that gap is exactly what proper Power BI training is for.
- The support is there: a place to ask questions, champions to lean on, and someone watching how it is being used.
If those are in place, climbing is sensible. If they are not, you are not enabling self-service, you are handing your problems to more people.
How Metis BI helps
Working out which approach a team should be on, and whether it is ready to move up, is a lot of what we do. Self-service can lift adoption and take real pressure off the BI team, but open it up too early and you just spread weak foundations to more people, faster. The judgement of when and how far matters as much as the tooling. So we start by assessing where your teams actually sit today, then give you practical, prioritised recommendations: what to fix before you open things up, and how far up the ladder each team should go. It tends to help two kinds of organisation, those planning a Power BI rollout who want to get the sequence right, and those who have already turned on self-service and found it is not quite working as they hoped. If that sounds like you, our Power BI and Microsoft Fabric governance assessment is the right place to start.
The spectrum and the ladder are not in conflict. The spectrum tells you all three approaches are valid and that a large organisation will run several at once. The ladder tells you how any single team should travel through them, one rung at a time, earning the next. You do not move up because the next approach sounds more mature. You move when the need is real and the foundation underneath can carry the weight.
This blog builds on the foundations I set out in Power BI Governance: The Foundations Matter More Than Ever, the overview of my Leeds talk on Power BI governance.
.png)
.png)