FRAMEWORK — Governing Principles for Power BI at Scale

Apply at any stage

These principles apply to any Power BI project at any point in its lifecycle: greenfield, mid-flight, or inherited. Pick the one that addresses the issue you have today.

Built for every role

Principles span Developer Architect Operations. Each group is positioned for its primary audience without excluding the rest.

A living framework

These principles evolve. From practice, from the platform, and from community contributions. If you have implemented this at scale, share what you learned.

Most Power BI environments are failing the same way.

After a decade across enterprise analytics programs, the same failure patterns keep appearing. Different industries, different team sizes, different budgets, same failures. They are predictable. They are preventable.

FRAMEWORK exists because the problems are structural, not technical. The platform is not the problem. The absence of governing principles is.

⚡

Model sprawl

Every workstream builds its own version of the same data. Subtly different metric definitions. No single source of truth. Nobody knows which one is correct.

🔒

Security as an afterthought

RLS is bolted on after reports are already in production. Page hiding compensates for missing row-level security. PII appears in reports without documented access controls.

🗄

No version control

.pbix files stored in SharePoint folders. No change history. No way to review what changed or why. One bad save away from losing weeks of work.

👻

Orphaned content

Reports refresh on schedule for months after the developer who built them has left. No owner. No documentation. Users can’t tell if they’re current or stale.

Not a methodology. A set of governing principles.

A small set of clear principles, in service of teams that have to keep enterprise BI running.

FRAMEWORK is a set of governing principles for enterprise Power BI, drawn from running production estates over a decade. The intent is to make decisions explicit and transferable, so the next person who inherits an environment can understand what was decided and why.

Most enterprise BI deployments fail in the same predictable ways. Model sprawl. Page-level security workarounds. Reports refreshing on schedule six months after their owner left. The platform isn't the problem. The absence of governing principles is.

You can apply this incrementally. Pick the principle that addresses your most urgent issue, apply it, move to the next. There is no required starting point and no end state.

Vendor-agnostic

No dependency on a particular Fabric SKU, gateway model, or third-party tool. On-prem, cloud, and hybrid all fit.

Opinionated by design

Each principle makes a clear call. No "it depends" without a decision framework. Soft governance gets enforced by nobody.

Living document

Currently v1.0. Evolves with the platform, particularly around Fabric, TMDL, and the .pbip format.

Practitioner-to-practitioner

Written from the perspective of building and running production environments, with the operational detail that role demands.

Core Principles

Git and .pbip are the source of truth. If Git and the Power BI Service disagree, Git wins. A .pbix is a binary. It cannot be diffed, reviewed, or meaningfully version-controlled.

Finite models. Infinite reports. A finite number of certified semantic models supports an unlimited number of reports. The model is the investment. Every report built on it is the return.

Reuse before you build. Model sprawl — every workstream building its own version of the same data with subtly different metric definitions — is the most common failure in large Power BI deployments.

Security is designed at the model layer. RLS and OLS live in the model. Reports inherit controls automatically through Live Connection. Security is never compensated for by hiding pages.

This is what the framework actually says.

No hedging. No "consider whether." Each principle states a position, explains the reasoning, and closes with an enforceable rule.

F-01 · Flows

Connection Mode is Determined by Reporting Requirement and Source Cadence.

Import via Dataflow is correct when the reporting requirement can be satisfied by data current as of the last scheduled refresh. DirectQuery to source is correct only when both conditions are true: the requirement is demonstrably near-real-time, and the source updates more than once per day. If only one condition is met, Import is the answer.

Import via Dataflow: default. DirectQuery to source: only when near-real-time is required AND source updates >1× daily. Both conditions must be true.

M-05 · Models

Finite Models. Infinite Reports.

A finite number of certified semantic models supports an unlimited number of reports. This is the stated architectural goal — not a consequence to be discovered later, but a design target held from the start. A team that builds one well-designed certified model and builds twenty reports against it has achieved something. A team that builds twenty models for twenty reports has built twenty maintenance obligations.

The model is the investment. Every report built on it is the return. Certified once. Consumed without limit.

E-01 · Engineering

Git and .pbip are the Source of Truth. The Service is a Deployment Output.

Everything is built in .pbip format and stored in Git. TMDL files define the semantic model — each table, role, and perspective in a separate plain-text file. PBIR defines the report layout. Both formats are human-readable, Git-diffable, and reviewable in a pull request. If Git and the Power BI Service disagree, Git wins. A .pbix file is a binary — it cannot be diffed, reviewed, or meaningfully version-controlled.

Git and .pbip are the source of truth. .pbix is incompatible with this framework.

Written for the people who build and operate it.

FRAMEWORK is written practitioner-to-practitioner. Each principle is built around an implementation path you can act on, with the trade-offs called out clearly.

🏗️

Power BI Architects & Senior Developers

Building or rearchitecting a multi-team Power BI environment and need a principled foundation to work from.

Starting a new enterprise programme

Inheriting a sprawling existing estate

Standardizing across multiple teams

Preparing for a Fabric migration

⚙️

CoE Leads & Data Platform Managers

Responsible for governance quality across an enterprise BI estate and looking for a structured framework to enforce and evolve.

Establishing a Power BI CoE

Defining certification standards

Writing developer onboarding guides

Running governance reviews

📐

Analytics Engineers & BI Developers

Working within an enterprise environment and wanting to build to a consistent, defensible standard from day one.

Learning enterprise-grade patterns

Contributing to a governed environment

Preparing for senior-level responsibilities

Understanding the why behind the rules