A data strategy framework is the set of layers that turn raw data into decisions: where the data comes from, who governs it, where it lives, how its meaning is defined once, and how people consume it. It works when each layer has a named owner and a clear interface to the layer next to it, not when it stays a slide describing "vision and objectives."

This post covers the structure itself. For turning business goals into measurable KPIs on top of this structure, see our guide to building an analytics strategy. For sequencing the work into phases, see how to develop a data strategy roadmap.

The layers of a data strategy framework

A data strategy framework has five layers. Each depends on the layer below it, and each needs an owner who is accountable when it breaks.

Skipping the semantic layer is the most common failure. Without it, two reports built on the same source data can define "revenue" differently, and nobody notices until a meeting where two numbers disagree.

Sources: bring data in without duplicating logic

Every framework starts with an inventory of source systems: the CRM, the ERP, finance exports, product event logs. The question that matters is not which systems exist, but which team owns each one and who to call when a field changes shape.

In Fabric, ingestion runs through pipelines or Dataflows Gen2, both scheduled and both landing data into OneLake. A shortcut can reference data that already sits in another location, such as an existing Azure Data Lake Storage account, without copying it. That keeps one dataset in one place, instead of a duplicate for every report that needs it.

Platform: one storage layer under everything

OneLake is Fabric's single storage layer. Lakehouses and warehouses store their tables in it as Delta tables, and Spark, SQL and Power BI all read those same tables instead of each tool keeping its own copy.

This is what makes the rest of the framework possible. A sensitivity label applied to an item is inherited by the items built on it, so a report built on a labeled semantic model carries the label too. A semantic model built on Direct Lake mode reads those same Delta tables directly, without an import step and without a separate DirectQuery connection to manage.

Governance: rules that travel with the data

Governance is not a policy document. It is a set of enforced rules: who can see which rows, which fields are sensitive, and which names mean what.

Row-level security is where governance becomes visible to report readers. A role in the semantic model filters a table based on the signed-in user:

[Region] =
LOOKUPVALUE (
    'UserRegionMap'[Region],
    'UserRegionMap'[Email], USERPRINCIPALNAME ()
)

A sales manager in the Berlin region opens the same report as a colleague in Munich and sees only their own rows, without a separate report being built for each. Microsoft Purview extends this past Power BI, applying sensitivity labels and a shared catalog across every Fabric workload. Our guide to data governance strategy covers setting these rules up in more depth.

Semantic layer: one model, reused everywhere

The semantic layer is where a business term gets one definition. "Active customer" should mean the same thing in the executive dashboard and in the sales team's weekly report. A shared Power BI semantic model, built once and reused by several reports, is what makes that true.

Active Customers (12 Months) =
VAR MaxDate = MAX ( 'Date'[Date] )
RETURN
CALCULATE (
    DISTINCTCOUNT ( Sales[CustomerID] ),
    DATESINPERIOD ( 'Date'[Date], MaxDate, -12, MONTH )
)

Every report that plugs into this model inherits the same measure, the same filter logic and the same row-level security. Change the definition once, and every report that uses it updates.

Consumption: reports people actually open

The consumption layer is where the other four layers either pay off or go unused. A Power BI app groups the reports one team needs in one place, and the semantic model's row-level security still applies to everyone who opens it. Email subscriptions put the numbers in front of people on a schedule, so nobody has to remember to go and look.

A framework with a clean semantic layer but no workspace structure still fails here, because nobody can find the right report. Assigning an owner to this layer, usually the business team that owns the decision the report supports, is as important as assigning one to governance.

FAQs

What is the purpose of a data strategy framework?

It gives every part of an organization's data work, from where data is collected to how it is reported, a defined owner and a defined interface to the layer next to it. Without that structure, data work happens ad hoc, one project at a time, with no shared semantic layer underneath it. See our data strategy consulting guide for what a consulting engagement covers beyond the framework itself.

How often should I review my data strategy framework?

Review it when a source system changes, when a new report contradicts an existing one, or at least once a year. A framework that is never revisited drifts as source systems change underneath it, and the semantic layer stops matching reality.

What role does technology play in a data strategy framework?

Technology enforces the framework instead of describing it. OneLake enforces one storage layer, row-level security enforces the governance rules, and a shared semantic model enforces one definition per business term. Without the enforcement, the framework is a document nobody checks against.

Sources

• OneLake shortcuts - Microsoft Learn

• Direct Lake overview - Microsoft Learn

• Microsoft Purview and Fabric governance - Microsoft Learn