Home > Docs > Best Practices > Data Management > Data Product Framework

📦 Data Product Framework on Microsoft Fabric¶

Last Updated: 2026-04-27 | Version: 1.0.0 | Wave 3 Sibling of: Master Data Management

📑 Table of Contents¶

• 🎯 Overview
• ⭐ The Five Data Product Tenets
• 🧪 What Counts as a Data Product (and What Doesn't)
• 🪪 Data Product Card Template
• ♻️ Lifecycle Stages
• 🔍 Discoverability Patterns
• 🛣️ Consumption Path Documentation
• 📜 SLA Specification
• 👥 Ownership Model (RACI)
• 💰 Cost Attribution
• 🪦 Deprecation Process
• 🌐 Federation & Sharing
• 🎰 Casino Implementation
• 🏛️ Federal Implementation
• 🚫 Anti-Patterns
• 📋 Implementation Checklist
• 📚 References

🎯 Overview¶

For most of the last decade, data was treated as a byproduct — exhaust from operational systems that a central data team scraped together into reports. The pattern broke at scale: central teams became bottlenecks, data quality lived nowhere, consumers had no way to know whether a table was "trustworthy" or "someone's experiment from 2022", and ownership was a finger-pointing exercise. The Data Product discipline reframes the question. A data set with no owner, no SLA, no contract, and no lifecycle is not a data product — it's organizational risk pretending to be an asset.

A data product is a curated, owned, contracted, observable, and lifecycle-managed unit of data delivered to consumers — internal or external — with the same operational rigor an engineering team would apply to a public API. Microsoft Fabric provides the substrate (workspaces, OneLake, Catalog, Purview, GraphQL endpoints, Direct Lake, mirroring); this framework specifies the discipline applied on top.

Why Data Products Matter on Fabric¶

📝 Wave 3 Position: This is the discipline doc that gives every other Wave 3 anchor a target shape. Master Data Management produces golden records — those golden records become data products under this framework. Data Contracts become the formal contract section of the data product card. Reference Data Versioning handles the schema stability clause of the SLA.

The Mental Shift¶

Byproduct mindset                    Product mindset
─────────────────                    ─────────────────
"I dropped a table in lh_gold"  →    "I shipped Player_360_Master v2.1.0
                                       with documented contract,
                                       4-hour freshness SLA,
                                       three registered consumers,
                                       and a deprecation timeline."

⭐ The Five Data Product Tenets¶

These are the non-negotiable properties. If any of the five is missing, you do not have a data product — you have a pile of bytes with marketing.

1. Discoverable¶

A consumer who has never heard of the product must be able to find it through search, browsing, or AI-assisted discovery within five minutes — and judge whether it fits their need without opening Slack.

2. Addressable¶

The product must have a stable, machine-readable address that consumers can hard-code into pipelines, notebooks, BI models, and external apps. The address survives ownership transfers, workspace renames, and re-platforming.

# Stable addresses (examples)
sql:    contoso.fabric.microsoft.com / WS-Gaming-Prod / lh_gold.fact_daily_revenue
graphql: https://api.contoso.com/data/v2/player360
abfss:  abfss://gaming@onelake.dfs.fabric.microsoft.com/lh_gold.Lakehouse/Tables/fact_daily_revenue

If the address changes, the product version changes (per the deprecation process below).

3. Trustworthy (Quality SLAs)¶

A product publishes the service levels it commits to, instruments itself against them, and exposes the live status to consumers. "Trust me bro" is not a tenet — measured trustworthiness is.

See the SLA Specification section for how these wire to SLI/SLO infra (Wave 1 anchor).

4. Self-describing¶

A product carries enough metadata that a competent analyst can use it without asking the producer a single question. Schema, business definitions, lineage, sample queries, and known limitations all live with the product, not in someone's head.

5. Interoperable¶

A product can be consumed by the natural tools of the consumer's choice — SQL, Direct Lake into Power BI, GraphQL, mirroring, REST, notebooks — without the consumer adopting the producer's stack. This is the difference between "data product" and "internal table you happen to allow people to read".

🧪 What Counts as a Data Product (and What Doesn't)¶

Not every table in OneLake is a product. Treating everything as a product is as bad as treating nothing as a product — it dilutes the discipline.

YES — These ARE Data Products¶

NO — These Are NOT Data Products¶

🎯 Heuristic: If retiring this asset would surprise anyone outside your immediate team, it is functionally a data product — promote it formally or kill it. If retiring it would surprise nobody, it isn't a product, and that's fine.

🪪 Data Product Card Template¶

Every data product publishes a card — a single canonical document that lives alongside the product and is rendered in OneLake Catalog and Purview. The card is markdown so it is reviewable in Git. The same card backs the catalog tile, the workspace landing page, and the API documentation.

---
# Data Product Card
# Save as: docs/data-products/<product_name>.md
# Mirror to: OneLake Catalog description + Purview asset

product_name:    "Player_360_Master"
product_id:      "dp.gaming.player_360_master"   # immutable, dotted, lowercase
domain:          "gaming"
status:          "GA"                              # alpha | beta | GA | deprecated | retired
version:         "2.3.0"                           # semver
addresses:
  sql:           "WS-Gaming-Prod / lh_gold.player_360"
  abfss:         "abfss://gaming@onelake.dfs.fabric.microsoft.com/lh_gold.Lakehouse/Tables/player_360"
  graphql:       "https://api.contoso.com/data/v2/player360"
  direct_lake:   "PowerBI: Casino_Player_360.semanticmodel"
---

## Purpose

One paragraph in plain English: what business decision this product supports, what
question it answers. No jargon, no acronym soup. If a new VP asked "what's this for",
this is the answer.

## Business Glossary Terms

- **Player** — see [Purview glossary: Player](purview://glossary/player)
- **Tier** — see [Purview glossary: Loyalty Tier](purview://glossary/loyalty-tier)
- **Lifetime Value** — see [Purview glossary: LTV](purview://glossary/ltv)

## Schema & Contract

- **Contract:** [docs/data-contracts/player_360_master.yaml](../data-contracts/player_360_master.yaml)
- **Schema version:** 2.3.0 (changelog at bottom of contract)
- **Breaking-change policy:** 30-day notice + dual-write window (see Lifecycle)

| Column | Type | Nullable | PII | Description |
|--------|------|----------|-----|-------------|
| `master_id` | BIGINT | NO | NO | Stable internal player ID — never reused |
| `legal_name` | STRING | NO | YES (PII-Direct) | Full legal name (Compliance source-of-truth) |
| `email` | STRING | YES | YES (PII-Direct) | Most-recent email across sources |
| `tier` | STRING | NO | NO | Loyalty tier: Bronze, Silver, Gold, Platinum, Diamond |
| `ltv_usd` | DECIMAL(18,2) | NO | NO | 365-day rolling lifetime value |
| `last_play_ts` | TIMESTAMP | YES | NO | Most-recent gaming activity |
| ... | ... | ... | ... | ... |

## SLA

| Dimension | Target | Measurement |
|-----------|--------|-------------|
| Freshness | ≤ 4 hours | Time since last successful refresh, measured by Workspace Monitoring |
| Availability | 99.5% | SQL endpoint query success rate over rolling 30 days |
| Completeness | ≥ 99.5% non-null on (master_id, tier, ltv_usd) | Great Expectations checkpoint per refresh |
| Schema stability | Breaking changes require 30-day notice | Enforced via contract CI |
| Accuracy | Reconciles to MDM hub ± 0 records | Daily checksum job |

**SLA wired to:** [SLO/SLI doc](../../slo-sli-instrumentation.md) (Wave 1)

## Cost

- **Producing capacity:** F64 (`cap-gaming-prod`)
- **Average CU per refresh:** 1,840 CU-seconds (last 30-day median)
- **Refresh cadence:** Hourly (24 refreshes/day)
- **Estimated daily cost:** ~$22.30 USD (CU-second × $/CU × refresh count)
- **Tag:** `data_product=player_360_master` (drives [cost attribution](#-cost-attribution))

## Consumers (Registered)

| Consumer Team | Use Case | Consumption Path | Registered |
|---------------|----------|------------------|------------|
| Casino Marketing | Campaign targeting | Direct Lake → Power BI | 2025-11-04 |
| Compliance | Watch-list reconciliation | T-SQL via SQL endpoint | 2025-12-12 |
| Sportsbook | Cross-product KYC | GraphQL | 2026-01-17 |
| Loyalty Ops | Tier audits | Notebook (`%run` template) | 2026-02-03 |

> Unregistered consumers do not get SLA coverage. To register, open a request via the
> domain workspace **Translytical Task Flow** "Register as consumer".

## Lineage

- **Purview lineage:** [open in Purview](purview://lineage/dp.gaming.player_360_master)
- **Upstream:** `bronze.crm_customer`, `bronze.loyalty_member`, `bronze.compliance_party`
- **Downstream:** `gold.fact_player_session`, `MirroredDB_PlayerCRM`, `Casino_Floor_Performance.semanticmodel`

## Discoverability

- **OneLake Catalog tags:** `domain:gaming`, `owner:gaming-data@org.com`,
  `sensitivity:Confidential-PII`, `lifecycle:GA`, `endorsement:Certified`
- **Purview glossary terms:** Player, Loyalty Tier, Lifetime Value, Master Record
- **Endorsement:** Certified by Data Governance Board on 2025-11-15
- **Featured on:** Casino domain workspace landing page (top 3 products)

## Support

- **Product Owner:** Jane Doe (`jane.doe@org.com`)
- **On-call rotation:** `gaming-data-oncall@org.com` (PagerDuty: gaming-data)
- **Slack channel:** `#data-product-player360`
- **Runbook:** [runbooks/player-360-incident.md](../../../runbooks/player-360-incident.md)
- **Office hours:** Thursdays 14:00 ET

## Lifecycle & Roadmap

- **Stage:** GA (since 2025-11-15)
- **Next milestone:** v2.4.0 (Q3 2026) — adds `cltv_predicted` ML-derived column
- **Deprecation horizon:** None planned. v1.x deprecated 2025-09-01, retired 2025-12-01.

## Changelog

- **2.3.0** (2026-03-12) — Added `last_play_channel` (slot/table/sportsbook/online); non-breaking
- **2.2.0** (2026-02-01) — Added `preferred_language`; non-breaking
- **2.1.0** (2026-01-08) — Added `kyc_status`; non-breaking
- **2.0.0** (2025-11-15) — GA. Renamed `player_id` → `master_id` for MDM alignment (BREAKING — see migration guide)
- **1.x** — Deprecated 2025-09-01, retired 2025-12-01

📌 Card Storage: The card lives in docs/data-products/<product_id>.md in the repo. CI publishes it to OneLake Catalog as the item description and to Purview as the asset description on every merge. The card is the single source of truth — catalog and Purview are downstream views.

♻️ Lifecycle Stages¶

A data product moves through five well-defined stages. The stage is part of the card and is enforced by Catalog tags and CI.

Stage Transition Rules¶

flowchart LR
    Alpha([Alpha]) -->|consumer registrations enabled| Beta([Beta])
    Beta -->|SLA met for 30 days + sign-off| GA([GA])
    GA -->|deprecation announced| Dep([Deprecated])
    Dep -->|sunset window elapsed| Ret([Retired])
    Alpha -.->|abandoned| Ret
    Beta -.->|abandoned| Ret

Why Five Stages, Not Three¶

The temptation is "Dev / Prod / Retired". This collapses two important distinctions: - Alpha vs. Beta — Alpha has no consumers; Beta has invited consumers. The first time someone outside your team depends on you, your obligations change. The stage must change with them. - GA vs. Deprecated — Deprecated still has SLA obligations; it is not "post-prod, who cares". Most outages happen during sloppy sunsets.

🔍 Discoverability Patterns¶

A product nobody can find is a product nobody uses. Fabric provides several discovery surfaces — wire all of them.

OneLake Catalog Tags (mandatory taxonomy)¶

tags:
  domain:        gaming | usda | sba | noaa | epa | doi | doj | dot | tribal-health
  owner:         <team-email>
  sensitivity:   Public | Internal | Confidential | Confidential-PII | Restricted
  lifecycle:     alpha | beta | GA | deprecated | retired
  endorsement:   None | Promoted | Certified
  data_product:  <product_id>            # for cost roll-up
  pii:           "true" | "false"
  pci:           "true" | "false"
  hipaa:         "true" | "false"

Microsoft Purview Glossary¶

Every product attaches business glossary terms — not column names, but business concepts:

• "Player Lifetime Value" not "ltv_usd"
• "Crop Production Forecast" not "yield_pct"
• "Air Quality Index" not "aqi_value"

Glossary terms are the bridge between the analyst who knows the business word and the engineer who knows the physical column. See business-glossary-automation.md (Wave 3 sibling) for keeping the glossary in sync with the schema.

Searchable Metadata¶

The product card itself is the metadata. CI pushes: 1. Title → Catalog item display name 2. Purpose paragraph → Catalog description 3. Tags → Catalog tags 4. Schema column descriptions → Purview column-level metadata 5. Glossary refs → Purview term assignments 6. Lineage → Purview lineage edges (auto-populated by Fabric, validated by CI)

Featured Products on Workspace Landing¶

Each domain workspace landing page features its top GA products — the ones the team wants new analysts to find first. This is configured in the workspace customization and refreshed quarterly.

"Yelp for Data Products" — Social Signals¶

Consumers trust products that other consumers use. Surface that signal.

🛣️ Consumption Path Documentation¶

Every GA product publishes at least two consumption paths from the list below. The card spells out each one with a working snippet.

1. SQL Endpoint (T-SQL)¶

-- Connect: WS-Gaming-Prod / SQL endpoint of lh_gold
SELECT master_id, tier, ltv_usd, last_play_ts
FROM   lh_gold.player_360
WHERE  tier IN ('Platinum', 'Diamond')
  AND  last_play_ts >= DATEADD(day, -30, SYSUTCDATETIME());

2. Direct Lake into Power BI¶

1. Open Power BI Desktop
2. Get Data → OneLake → Workspace: WS-Gaming-Prod → Lakehouse: lh_gold
3. Select table: player_360
4. Load mode: Direct Lake (NO duplication, query at source)
5. Add measures from semantic model: Casino_Player_360

3. REST / GraphQL API¶

# https://api.contoso.com/data/v2/player360
query HighValuePlayers {
  players(filter: { tier_in: ["Platinum","Diamond"], last_play_after: "2026-03-27T00:00:00Z" }) {
    masterId
    tier
    ltvUsd
    lastPlayTs
  }
}

4. Mirroring Downstream¶

Use mirrored database `MirroredDB_PlayerCRM` to land a near-real-time replica
of the operational source feeding this product. Consumer workspaces consume
the mirror via shortcut — never re-ingest from source.
See: docs/features/mirroring.md

5. Notebooks (%run Template)¶

# Reusable consumption template — paste at top of any notebook
%run /workspaces/WS-Gaming-Prod/notebooks/templates/load_player_360

# After %run, the helper exposes:
df_players = load_player_360(
    tier_in       = ["Platinum", "Diamond"],
    last_play_after = "2026-03-27"
)
df_players.show()

🚫 Anti-pattern: "Just open the lakehouse and query whatever". Without a documented consumption path, every consumer reinvents the wheel and your "stable address" promise breaks the day someone hard-codes a path you intend to change.

📜 SLA Specification¶

The SLA is a published commitment — not an aspiration. Each clause is measured, alerted, and reported.

Required SLO Dimensions¶

SLA Failure Modes & Responses¶

Wiring to SLO/SLI Infra¶

The SLA clauses become SLIs (Service Level Indicators) in the Wave 1 SLO/SLI doc. Every product registers its SLIs into the central SLO dashboard so cross-domain leadership can see all product health on one page. See slo-sli-instrumentation.md (Wave 1).

flowchart LR
    Card[Data Product Card<br/>SLA section] -->|publish| SLO[SLO Registry]
    GE[Great Expectations<br/>checkpoint] -->|SLI: completeness| SLO
    WSM[Workspace Monitoring<br/>query telemetry] -->|SLI: availability + latency| SLO
    Pipeline[Pipeline run history] -->|SLI: freshness| SLO
    Recon[Reconciliation job] -->|SLI: accuracy| SLO
    SLO -->|breach| Alerts[Alerts & PagerDuty]
    SLO -->|status| Dash[Cross-Domain Health Dashboard]
    SLO -->|status banner| Catalog[OneLake Catalog tile]

👥 Ownership Model (RACI)¶

A data product must have one named accountable owner. "The team" is not an owner. "The platform" is not an owner. A person.

RACI Matrix (Common Activities)¶

(R = Responsible, A = Accountable, C = Consulted, I = Informed)

Why a Single Accountable Owner¶

Distributed accountability is no accountability. The Product Owner is the person whose name goes on the postmortem when the product fails. They have authority to say "no, we won't add that column" or "yes, we will accept the cost increase". A product without a named owner is in Alpha at best and cannot be promoted.

💰 Cost Attribution¶

You cannot manage what you cannot measure, and you cannot prioritize what you cannot price.

Tagging Strategy¶

Every Fabric item that produces or supports a data product carries the data_product=<product_id> tag:

# In Bicep / fabric-cicd item descriptors
tags:
  data_product: dp.gaming.player_360_master
  domain:       gaming
  cost_center:  CC-1024
  environment:  prod

This includes: - Lakehouses, warehouses, eventhouses (storage) - Pipelines, dataflows, notebooks, Spark Job Definitions (compute) - Power BI semantic models built directly on the product (compute on refresh)

Cost Roll-up Query¶

-- Roll up CU-seconds and est. USD cost per product, last 30 days
WITH usage AS (
    SELECT  i.tag_data_product,
            SUM(c.cu_seconds)            AS cu_seconds_30d,
            SUM(c.cu_seconds) * @rate    AS est_usd_30d
    FROM    workspace_monitoring.capacity_usage c
    JOIN    fabric_inventory.items           i  ON c.item_id = i.item_id
    WHERE   c.event_ts >= DATEADD(day, -30, SYSUTCDATETIME())
      AND   i.tag_data_product IS NOT NULL
    GROUP BY i.tag_data_product
)
SELECT  tag_data_product,
        cu_seconds_30d,
        est_usd_30d,
        est_usd_30d * 12 AS annualized_usd
FROM    usage
ORDER BY est_usd_30d DESC;

Charge-back vs. Show-back¶

The Product Owner is responsible for explaining the per-product cost trend monthly to the Domain Lead. A product whose cost is growing faster than its consumer base is a candidate for optimization (see Wave 2 capacity-planning-cost-optimization.md).

🪦 Deprecation Process¶

The hardest part of running data products at scale is shutting them down without breaking consumers. The process is formal, calendared, and non-negotiable.

Five Phases¶

T-90 ────── T-60 ────── T-30 ────── T-0 ─────── T+30
 │           │           │           │            │
 Announce    Migration   Read-only   Retire       Audit
            guide        mode        (remove)     postmortem
            published

Phase 1 — Deprecation Announcement (T-90 days)¶

• Card status flips from GA → deprecated
• Catalog endorsement demotes from Certified → Deprecated (red tag)
• Banner on Catalog tile: "Deprecated — sunset 2026-07-15. Migrate to dp.gaming.player_360_master_v3."
• Email to all registered consumers with subject [DEPRECATION T-90]
• Slack announcement in domain channel
• New consumer registrations refused

Phase 2 — Migration Guide Published (T-90, alongside announcement)¶

The migration guide is a markdown doc that includes: - Side-by-side schema mapping (old → new) - Working SQL/PySpark/GraphQL/DAX examples for each common consumption path - Behavioral diffs (e.g., "ltv now includes sportsbook activity, may be higher than before") - A migration checklist consumers can copy

Phase 3 — Active Consumer Notification (T-60 and T-30)¶

• T-60: second email reminder, Catalog banner upgraded to amber
• T-30: third email, banner red, on-call paged if any consumer hasn't acknowledged migration
• Workspace Monitoring shows "stragglers" — registered consumers with non-zero query traffic and no acknowledgement

Phase 4 — Read-only Mode (T-30)¶

• Pipelines stop writing new data; last refresh is final
• Card states explicitly: "Read-only since YYYY-MM-DD. Data frozen at this date."
• Schema is frozen; no new columns even if requested
• Allows consumers to verify their migration against a stable, frozen old product

Phase 5 — Retirement (T-0)¶

• SQL endpoint and GraphQL endpoint return 410 Gone with a pointer to the replacement
• Tables remain in OneLake read-only for an additional 30 days for audit/legal hold
• After T+30, tables are archived to cold storage (or deleted per retention policy)
• Card status → retired; remains discoverable in Catalog with full history (so future audits can find what existed when)

What Forces a Skip¶

The only thing that forces a faster sunset than 90 days is a legal or security mandate (regulator order, breach response, license revocation). In that case the Compliance Officer signs the accelerated-sunset memo, and the abbreviated process is itself documented as a lesson-learned for the next planning cycle.

🌐 Federation & Sharing¶

Data products are meant to be shared across domains and (sometimes) tenants. The product framework formalizes how.

Cross-Domain Product Sharing (Same Tenant)¶

flowchart LR
    subgraph Producer["🎰 Gaming Domain (Producer)"]
        P[(player_360 product)]
    end
    subgraph Catalog["📚 OneLake Catalog"]
        Card[Product Card]
        End[Endorsement: Certified]
    end
    subgraph Consumer["🌾 USDA Domain (Consumer)"]
        S[OneLake Shortcut → player_360]
        N[Notebook query]
    end
    P -->|register| Card
    Card -.->|discoverable| Consumer
    Consumer -->|request access via Translytical| Producer
    Producer -->|grant via OneLake Security RLS| S
    S --> N

• Discovery: OneLake Catalog
• Access provisioning: Translytical Task Flow → OneLake Security
• Consumption: OneLake Shortcut (see data-sharing-federation.md)
• The consumer registers as a consumer (so SLA breach notifications reach them)

Cross-Tenant Sharing (Direct Sharing / Iceberg)¶

For B2B and inter-agency federation, the product is exposed via: - Fabric Direct Sharing — internal partners and sister organizations - Iceberg endpoint — partners on Snowflake / Databricks / non-Fabric platforms - Delta Sharing (outbound) — open-protocol consumers

See data-sharing-federation.md for the mechanics. The product framework layer requires that:

⚠️ Federal note: Cross-tenant sharing of federal data products requires legal authority (data sharing agreement, Privacy Act exception applicability). The Product Owner cannot unilaterally approve external federation.

🎰 Casino Implementation¶

Two flagship Casino data products demonstrate the framework end-to-end.

Product 1: dp.gaming.player_360_master¶

The Player 360 Master product is the clearest illustration of why the framework matters: before it existed, five teams computed "high-value player" five different ways. Now there is one definition, one address, one SLA, and one phone number to call.

Product 2: dp.gaming.daily_floor_performance¶

Daily Floor Performance has the strictest SLA (executive consumption) and the heaviest cost-attribution scrutiny. The product card explicitly tracks CU consumption per refresh because the CFO sees it monthly.

🏛️ Federal Implementation¶

Product: dp.usda.crop_yield_forecast¶

This product showcases public-eligible federal data products — the same card serves internal users and drives the public API. Sensitivity classification at the column level (e.g., individual respondent flag → Restricted, aggregated yield → Public) lets a single product serve both audiences via OneLake Security row/column filters.

Product: dp.epa.aqi_daily¶

Daily AQI demonstrates external federation in production: the same product is served internally (Direct Lake to BI), to other federal agencies (Fabric Direct Sharing), to state agencies on different platforms (Iceberg), and to the public (rate-limited REST). One card, one SLA, four consumption paths — and consumers in any of them can find it through the same Catalog tile.

🚫 Anti-Patterns¶

📋 Implementation Checklist¶

Before promoting a data product to GA:

Identity & Ownership¶

• Immutable product_id assigned (dp.<domain>.<name>)
• Single named Product Owner
• Single named Steward
• Data Engineer rotation defined; on-call escalation path tested
• Compliance Officer engaged (if PII / regulated)

Card & Documentation¶

• Product card committed to repo at docs/data-products/<product_id>.md
• Card published to OneLake Catalog (description) and Purview (asset)
• Schema documented with column-level descriptions
• Business glossary terms attached in Purview
• Consumption-path snippets work end-to-end (tested by someone outside the producer team)
• Runbook published in runbooks/ and linked from card

Contract & Schema¶

• Formal contract YAML at docs/data-contracts/<product_id>.yaml
• Contract CI gates breaking changes
• Semver versioning (major.minor.patch)
• Changelog up-to-date

SLA & Observability¶

• Freshness SLI instrumented (pipeline run history)
• Availability SLI instrumented (Workspace Monitoring on endpoint)
• Completeness SLI instrumented (Great Expectations checkpoint)
• Accuracy reconciliation job scheduled (where applicable)
• Latency SLI instrumented (interactive products only)
• All SLIs published to SLO registry
• PagerDuty escalation policy live

Discoverability¶

• Catalog tags applied (domain, owner, sensitivity, lifecycle, endorsement, data_product, PII/PCI/HIPAA flags)
• Endorsement granted (Promoted minimum for Beta, Certified for GA)
• Featured on workspace landing page (if domain-flagship)
• Lineage validated in Purview

Cost¶

• All producing items tagged with data_product=<product_id>
• Monthly cost report subscribed by Product Owner
• Cost trend baseline established (first 30 days)

Lifecycle¶

• Stage explicitly set (alpha / beta / GA)
• Beta → GA gate sign-off documented (Domain Lead + Governance Board)
• Deprecation plan exists for any product this one replaces

Consumers¶

• At least 2 registered consumers (GA gate)
• Consumer notification channel configured
• Consumer feedback mechanism (Translytical Task Flow) live
• Star-rating / comments enabled

Federation (if applicable)¶

• Cross-domain access via OneLake Shortcut + Security configured
• Cross-tenant federation reviewed by Compliance
• External SLA addendum signed (if external consumers)
• Egress monitoring active

📚 References¶

Microsoft Fabric Documentation¶

• OneLake Catalog
• OneLake Security
• Microsoft Purview Data Catalog
• Fabric API for GraphQL
• Fabric Direct Sharing
• Workspace Monitoring

Industry Standards & Books¶

• Zhamak Dehghani, Data Mesh: Delivering Data-Driven Value at Scale (O'Reilly) — origin of the data-as-product principle
• DAMA DMBOK 2^nd Edition — Data Management Body of Knowledge
• ODCS — Open Data Contract Specification
• Data Product Manifesto (datamesh-architecture.com)

Related Wave 3 Docs¶

• Master Data Management — Wave 3 anchor; produces golden records that become products
• Data Contracts — formalizes the contract section of the product card
• Reference Data Versioning — handles schema-stability clause
• Late-Arriving Data — affects freshness SLA semantics
• SCD Patterns — how dimensional products handle history
• Business Glossary Automation — keeps glossary in sync with product schemas

Related Existing Docs¶

• Data Mesh Enterprise Patterns — domain topology that underpins product ownership
• OneLake Catalog — discovery surface
• OneLake Security — access provisioning for consumers
• Mirroring — consumption path for operational mirrors
• API for GraphQL — REST/GraphQL consumption path
• Direct Lake — Power BI consumption path
• Workspace Monitoring — SLI instrumentation
• Data Sharing & Federation — cross-domain and cross-tenant mechanics
• Capacity Planning & Cost Optimization — cost attribution backbone
• Data Governance Deep Dive — governance framework context

Related Wave 1 + Wave 2 Docs¶

• SLO/SLI Instrumentation (Wave 1) — where product SLAs become measured SLOs
• Data Quality Incident Runbook (Wave 1) — used when an SLA breaches
• Feature Store on OneLake (Wave 2) — features are themselves data products under this framework
• Responsible AI Framework (Wave 2) — ML-derived products inherit fairness obligations

⬆️ Back to Top | 📚 Data Management Index | 🏠 Home