Data Mesh Patterns in SAP Analytics: From Centralized Warehouses to Domain-Driven Architecture

The Four Pillars of Data Mesh and Their SAP Equivalents

Zhamak Dehghani's data mesh framework, published in 2020, proposed that the traditional centralized data lake architecture creates bottlenecks, quality problems, and accountability gaps. Her solution: distribute data ownership to business domains (finance, supply chain, HR), treat data as a product, provide self-serve platform capabilities, and enforce governance computationally rather than through manual processes. Each pillar maps directly to SAP's modern analytics stack.

1. Domain Ownership: From Centralized IT to Business Stewardship

In traditional warehouses, a central data engineering team owns all data. This creates single points of failure and slow feedback loops: if Finance needs a new calculation, they wait for the data team. Under domain ownership, Finance owns finance data products; Supply Chain owns supply chain; HR owns people data. Each domain has clear accountability and can move at its own pace.

In SAP, organizational structure naturally maps to domains. A company code in SAP Finance represents a distinct legal entity with its own chart of accounts, profit centers, and cost centers. A plant in Supply Chain Module represents a distinct location with its own inventory and procurement decisions. These organizational boundaries translate directly to data domains in a mesh architecture.

In Datasphere, domains become Spaces. A company code (e.g., "EMEA," "APAC") maps to a dedicated Space where the Finance domain team owns all financial data products. Access is controlled at the Space level: only EMEA Finance users can see EMEA financial data. This creates clear boundaries and prevents accidental data leakage across domains.

2. Data as a Product: From Datasets to Governed Business Services

A dataset is passive: rows and columns with unknown meaning, quality, or ownership. A data product is intentional: it includes metadata (clear definitions, lineage, quality scorecards), ownership, versioning, and service-level agreements. A data product is a contract: the owner guarantees data freshness, completeness, and accuracy; consumers trust the contract and build on it.

In SAP Business Data Cloud, domain teams publish custom data products today through Datasphere's Data Sharing Cockpit; Data Product Studio, announced as a visual workspace for the same job, had no confirmed general availability at the time of this review. A Finance domain might publish three products: "revenue by customer and date," "cost structure by cost center," "cash flow forecast." Each product includes dimensions (customer, cost center), measures (revenue, cost), hierarchies (organization), quality metrics (99% completeness, refreshed hourly), and ownership. A Supply Chain domain publishes "inventory by material and location," with unit-of-measure definitions and stock rotation policies embedded.

Critically, a data product is not just data—it is data plus governance. When a consumer subscribes to a data product, they inherit the product owner's quality commitments and semantic definitions. This eliminates the problem where Sales defines "customer" one way and Finance another.

3. Self-Serve Data Platform: Infrastructure for Decentralized Teams

Decentralized ownership only works if domain teams can provision their own infrastructure. Under centralized platforms, domain teams request resources (compute, storage, connections) from a central platform team and wait weeks. Under self-serve platforms, domain teams provision on-demand.

SAP Datasphere can serve as that self-serve platform. Once an administrator has created a Space for the Finance domain and assigned its scoped roles, the domain team manages its own members, connections to source systems (ERP, bank feeds), models, and custom data products—using SQL and graphical tools—without a ticket for every change. Storage and compute come from the tenant's capacity-unit budget, assigned per space, so growth is an allocation decision rather than a procurement cycle.

SAP Analytics Cloud extends this to the consumption layer. Business users can create their own stories (dashboards), add data from published data products, and collaborate on insights without depending on a central BI team. The platform enforces access controls (only authorized data appears in each story) and tracks lineage (which story uses which data product).

BTP (SAP Business Technology Platform) sits below, providing the cloud infrastructure backbone. Spaces run on BTP cloud resources, which scale elastically. This removes traditional capacity planning bottlenecks.

4. Federated Computational Governance: Policies as Code

In centralized governance, a global team (or consultant-written manual) defines policies ("all PII fields must be encrypted," "all revenue data must be audited monthly," "data retention is 7 years"). Teams attempt to follow policies manually, and compliance is spotty.

In federated governance, as many policies as possible are encoded into platform features, and automated checks cover the rest. In SAP Business Data Cloud the levers are concrete: data access controls restrict rows, spaces and scoped roles separate domains, audit logs record read and change actions per space, and—since September 2026—terms of use and steward approval govern who receives a data product. Where a policy is not covered by a platform feature, implement it as modeling standards and automated checks in your pipelines, and verify each control in your own tenant rather than assuming it.

Governance can be layered the same way: global standards at the tenant level (e.g., "all data must be classified for sensitivity"), domain refinements per space (e.g., "GDPR applies to the EMEA space"), and product-level rules (e.g., "customer salary is visible only to HR"). Access control, lineage analysis, and audit logging are built into Datasphere; classification and retention are standards you define and check.

Master data governance and enterprise catalogs complete the picture. SAP Master Data Governance, one of BDC's capacity services, keeps shared entities such as materials and customers consistent at the source, so domain data products inherit clean keys, while catalog tools such as Collibra synchronize metadata from the Datasphere catalog for enterprise-wide discovery and lineage. Cross-domain governance is coordinated, not duplicated.

Domain Ownership in SAP: Organizational Models and Boundaries

Mapping organizational structure to data domains is the critical first step. In SAP ERP, the standard organizational model is:

• Client (Mandant): Top-level legal entity, typically a holding company. Each client has its own master data, configuration, and financial records.
• Company Code: Legal entities within a client (e.g., EMEA GmbH, APAC Ltd). Each company code has its own general ledger, balance sheet, and P&L.
• Business Area: Optional; represents business lines (e.g., Products, Services, Licensing) that may span multiple company codes.
• Profit Center: Internal accountability centers within company codes (e.g., Sales, Engineering, Operations). Used for internal reporting.
• Cost Center: Operational cost-tracking units (e.g., IT Support, Marketing). Lowest granularity for cost allocation.

These boundaries define data domains. A mid-market company with two legal entities (EMEA and APAC) might define:

• EMEA Finance Domain: Own all financial data products (GL, AR, AP, cash position) for EMEA company code.
• APAC Finance Domain: Own financial data products for APAC company code.
• Global Supply Chain Domain: Own all procurement, inventory, and logistics data across both company codes.
• HR Domain: Own employee, payroll, and organizational data (globally).
• Customer Domain: Own customer master, order history, and customer performance data.

Each domain becomes a Datasphere Space with dedicated compute, storage, and governance policies. Cross-domain data products (e.g., "customer lifetime value" = revenue from Customer Domain + profit from Finance Domain) are orchestrated at the platform level, not within a domain.

This avoids the centralization trap. Each Finance domain owns their P&L and balance sheet products; they can refresh hourly if needed. Each Supply Chain domain owns their inventory and procurement products. When customers request new metrics, domains can iterate independently. When global consolidation is needed, products are combined at the platform layer, not duplicated within domains.

Data Products in SAP: Publishing from Domains to Enterprise

Data mesh architecture in SAP: domains own data products, governed globally, consumed through a self-serve platform layer.

A data product in the mesh context is more than a table. It is a published contract. When Finance publishes "Revenue by Customer," they commit to:

• Semantic clarity: "Revenue" = net recognized revenue per IFRS-15, excluding discounts and returns. "Customer" = unique legal entity with tax ID. Dimensions and measures are unambiguous.
• Freshness SLA: Data is refreshed hourly. If a transaction posts to ERP, it appears in the data product within 60 minutes. Consumers build batch jobs accordingly.
• Completeness: 99.5% of customers and orders are represented. The 0.5% gap (test records, archival accounts) is documented. Consumers know what's missing.
• Versioning: Version 2.0 adds "revenue by sales rep." Version 1.x consumers can continue using the old product; migration is optional. Breaking changes (removing a dimension) trigger v3.0 with deprecation notice.
• Ownership and SLA violations: Finance owns the product. If data quality drops below 99%, they notify consumers and provide workarounds. If they retire the product, they provide 90 days notice and a migration path.

This model requires organizational discipline. Domain teams need data engineers, data product managers, and data quality stewards. A small company might combine these roles (one person wears all three hats); a large company separates them. The critical thing is that responsibility is explicit, not diffused across a centralized team.

Self-Serve Data Platform: Infrastructure and User Experience

SAP Datasphere is the self-serve platform for data engineering. A Finance domain engineer can:

• Work in their own Space (isolated workspace) once an administrator has created it and assigned scoped roles.
• Configure connections to ERP, APIs, and external data sources within their space (on-premise sources still rely on the connectivity agents your platform team operates).
• Author SQL and graphical transformations, and build custom data products from local tables in a file space.
• Publish data products to the Business Data Cloud catalog (discoverable by entire enterprise).
• Document versioning, SLAs, and quality indicators with each product, and attach terms of use in the catalog.
• Monitor flows and task chains, run data validation on views, and analyze impact and lineage with built-in tools.

All without waiting for a central platform team for every change. Capacity comes from the tenant's capacity-unit budget, assigned per space, so domains iterate within agreed limits. This enables fast iteration. If the Finance domain needs a new product, they can prototype in days, not months.

SAP Analytics Cloud is the self-serve platform for consumption. Business analysts can:

• Discover published data products via Business Data Cloud catalog.
• Create dashboards (stories) by combining multiple data products (e.g., revenue from Finance + inventory from Supply Chain).
• Collaborate on stories with colleagues (comments, shared versions).
• Highlight exceptions with thresholds and conditional formatting (e.g., inventory below safety stock).
• Publish stories to stakeholders (no manual report generation).

Row-level security is inherited from Datasphere. If an analyst doesn't have access to APAC financial data, APAC records simply don't appear in their stories. No separate access request process; it's automatic.

The self-serve experience removes friction and accelerates analytics time-to-value. Instead of a 3-month project (requirements → data engineering → report development → QA), teams get value in 2-3 weeks (discover product → build story → iterate).

Federated Computational Governance: Policies as Built-In Features

Governance at scale is impossible if it relies on manual compliance. Teams promise to follow policies and fail. Federated governance embeds as many policies as possible into the platform and automates checks for the rest.

In Datasphere, governance is multi-layered:

Tenant-Level Governance (Global Policies)

The security and compliance team defines global rules. Examples:

• All PII fields (name, email, national ID, customer address) are tagged as "Confidential Personal Data" in the catalog.
• All financial data (GL balances, costs, revenue) is tagged as "Financial."
• Data retention: Transaction-level detail is deleted after 7 years; summary data is retained 10 years.
• Audit logging: read and change actions are logged for spaces holding confidential data (Datasphere retains audit logs for 7 to 10,000 days, as configured) and reviewed monthly.

These rules are not guidelines, but the platform enforces only part of them: access controls and audit logging are platform features, while tagging and retention need checks in your publication process—for example, a release step that blocks a data product with an untagged salary field.

Space-Level Governance (Domain Policies)

Domain teams refine global policies for their context:

• EMEA Space: GDPR applies. All customer data must support right-to-be-forgotten. Retention is 3 years post-customer termination.
• US Space: CCPA applies to California residents' data. Customer data must be delinkable by customer ID. Retention is 2 years post-termination.
• Finance Space: All data products require SOX audit trail. Change logs are immutable.

These build on MDG (Master Data Governance): when MDG governs the customer master, all Finance and US products reference the same keys and definitions.

Data Product-Level Governance (Access Policies)

Owners define fine-grained access rules:

• "Revenue by Customer" is public to all analysts. It contains no PII.
• "Customer Salary and Compensation" is visible only to HR and Finance managers (HR Role).
• "Supplier Cost Negotiations" is visible only to Procurement leadership (Chief Procurement Officer role).

SAP Cloud Identity Services connects Datasphere and SAC to your corporate identity provider (for example, Microsoft Entra ID or Okta). When an analyst logs in, their roles and data access controls apply automatically. An analyst in Sales cannot see Supplier Negotiations even if they try to access via API.

Integration with Enterprise Governance Tools

For organizations using a third-party data governance platform such as Collibra, the integration is mostly metadata flowing out of SAP into the enterprise catalog:

• Collibra synchronizes metadata from the SAP Datasphere catalog—tables, views, columns, models, and SAP Business Glossary terms—into its own catalog, with one domain per space.
• Collibra can also ingest SAP data products and represent them as data product, port, and data contract assets.
• Data quality profiling and rules run in the governance tool against the underlying SAP HANA database (for example, Collibra Data Quality & Observability), because Datasphere itself has no general data quality rule engine.

This federation means that domain teams aren't inventing governance in isolation. Global standards are enforced, but domains have flexibility to apply them in context-appropriate ways.

Three Practical Data Mesh Patterns in SAP Landscapes

Pattern A: Centralized Platform, Decentralized Ownership (Most Common)

A central platform team operates shared Datasphere infrastructure (upgrade management, capacity provisioning, security patching). Multiple domain teams provision their own Spaces and author their own data products within that infrastructure. Domain teams own data products; the platform team owns the platform.

When to use: Organizations with 5-10 domain teams, shared budget model, and preference for economies of scale.

Example: A Fortune 500 company runs a single Datasphere tenant with 7 Spaces (Finance, Supply Chain, HR, Customer, Product, IoT, Analytics). Each Space is isolated (separate schemas, access controls). The platform team (5 people) manages upgrades and governance policies. Domain teams (3-5 engineers per domain) publish data products independently. A shared central data engineering team (10 people) handles complex, cross-domain orchestrations (e.g., "customer profitability" combining Finance and Customer data products).

Pattern B: Full Mesh with Autonomous Domain Teams (Mature Organizations)

Each domain has its own Datasphere tenant, managed by the domain. Domains are fully autonomous: they set their own governance policies, manage their own infrastructure, and decide what data to share with other domains. Sharing happens via BDC Connect (zero-copy federation).

When to use: Large organizations (1000+ employees) with strong domain boundaries, decentralized budget model, and regulatory fragmentation (e.g., finance in EMEA, supply chain in APAC).

Example: A global bank operates Datasphere independently in each region: EMEA Datasphere, APAC Datasphere, Americas Datasphere. Each has its own governance, ops team, and data products. Cross-region products are shared via BDC Connect. A customer in UK accessing a product queries EMEA Datasphere; a customer in Singapore queries APAC Datasphere. Each region complies with local regulations (GDPR, PDPA) independently.

Pattern C: Hybrid—Central Data Engineering + Domain Data Product Owners (Pragmatic Middle Ground)

A central data engineering team handles raw data ingestion, transformation, and quality assurance (centralized "data factories"). Domain teams publish governed data products from that raw data, managing semantics, versioning, and SLAs (decentralized product ownership). This hybrid approach balances centralized consistency with decentralized agility.

When to use: Organizations with complex data integration (many source systems), limited domain engineering talent, but strong need for decentralized ownership and domain-specific product strategies.

Example: A healthcare company runs a central data engineering team that ingests data from ERP, HIS (Hospital Information System), and external partners (insurance claims, demographics). They publish raw datasets to a "Data Foundation" Space. Finance Domain teams consume that foundation and publish "hospital profitability by department"; Clinical Domain teams publish "patient outcomes by diagnosis"; Operations publish "resource utilization by facility." Each domain owns their products' SLAs and semantics, but all are built on the same clean, validated raw data.

BDC Connect: The Mesh Enabler for Multi-Cloud Data Products

Business Data Cloud Connect (BDC Connect) is the critical enabler of data mesh in multi-cloud environments. It solves a fundamental mesh challenge: how do you share data products between independent domains or tenants without copying data?

Data Products as Shared Services Across Clouds

In a pure-mesh architecture, the Finance domain publishes a "revenue by customer" product from Datasphere, while Supply Chain works in Databricks and Reporting in Snowflake. When Reporting needs "customer profitability" (combining revenue + inventory), how do they access both products without duplicating or moving data?

BDC Connect solves this with zero-copy sharing over Delta Sharing. Finance's revenue product is published in the Business Data Cloud catalog, and BDC Connect shares it with Databricks (as a Unity Catalog share) or Snowflake (as a catalog-linked database) without moving data. Consumers query it using native SQL. Semantic metadata travels with the product; access inside each platform is governed by that platform's own controls.

Practical Mesh Pattern: Shared Data Products Across Platforms

Imagine a global company where Finance runs Datasphere (EMEA), Supply Chain runs Databricks (APAC), and Analytics runs Snowflake (global). All three domains publish data products (Finance revenue, Supply Chain inventory, Analytics ML features). Before BDC Connect, they duplicated data across platforms, creating synchronization nightmares.

With BDC Connect:

• Finance publishes "revenue by customer" as a custom data product in the BDC catalog, documented with its SLA and quality indicators.
• A BDC user with sharing rights shares it with the Analytics team's Snowflake account, where it is mounted as a catalog-linked database and queried with SQL.
• The same product is shared with Supply Chain's Databricks workspace, where it appears as a Unity Catalog catalog; Supply Chain and Analytics publish their own products back to BDC the same way.
• All three consume the same source-of-truth data product. No copies, no drift.

Governance Across Mesh Domains via BDC Connect

Access control does not flow automatically from the source product to target platforms. BDC decides which data products are shared with which platform—with terms of use and steward approval since September 2026—and each platform decides who can query them there. If Finance marks salary data as "HR-only," either keep it out of the shared product or replicate the rule in Unity Catalog and Snowflake roles. That two-layer design is what makes federation safe: domains keep full autonomy over their products, and governance is enforced on both sides of every share.

In practice, BDC Connect is how organizations implement "Pattern B" mesh across platforms—domains on Datasphere, Databricks, or Snowflake—without data duplication: products are shared through BDC and governed in its catalog, while each platform enforces its own access rules.

Challenges and Anti-Patterns: Why Pure Mesh Rarely Works in SAP

Data mesh is powerful, but SAP landscapes introduce structural challenges. Pure mesh architectures fail in SAP environments; pragmatic, "mesh-informed" approaches succeed.

Challenge 1: Master Data Dependencies

In SAP, master data (customers, materials, cost centers) is shared across domains. Finance uses customer master; Sales uses customer master; Billing uses customer master. If Finance publishes a customer master product and Supply Chain publishes a different customer definition, the business operates on two truths. This is a nightmare.

Solution: Create a shared "Master Data" domain owned jointly by Finance and Operations. Customer Master, Material Master, and Organizational Hierarchy are published as cross-domain products with strict change governance. Domain teams consume (don't replicate) these products. This removes the pure mesh assumption of independent domains and introduces a thin coordination layer.

Challenge 2: Hierarchical Consolidation

SAP balance sheets roll up: plant → company code → division → global. Profit centers accumulate costs: cost center → profit center → strategic business unit. These hierarchical relationships are governed globally; domains can't change them independently.

Solution: Publish organizational hierarchy products from a central "Finance Foundation" domain with read-only access. Domain teams use (not redefine) hierarchies in their own products. Strict versioning prevents domains from misinterpreting rollup rules.

Challenge 3: Semantic Drift

Even with standards, domain interpretations diverge. Finance defines "revenue" as IFRS-15 recognized; Sales defines "revenue" as booked orders (including unrecognized). Both publish data products. Over time, users mix definitions unknowingly, corrupting insights.

Solution: Centralize semantic definitions in SAP Master Data Governance (MDG) or Collibra. Publish a "Finance Definitions" product documenting every metric. Require domain teams to reference official definitions in their product metadata. Add data lineage and lineage validation to catch drift early.

Challenge 4: Tight System Coupling

SAP systems are highly integrated. A change to the GL in Finance immediately impacts Cost Accounting, Profitability Analysis, and Consolidation. A change to the procurement process ripples to Inventory, Accounts Payable, and Cost Accounting. Domains can't move independently.

Solution: Establish a "System Integration" working group (architecture, finance, ops leadership) that reviews cross-domain changes. Publish change impacts explicitly. Use configuration management (SAP CHARM) to coordinate releases across domains. Accept that some coordination is necessary.

Anti-Pattern: Duplicated Master Data

If each domain maintains its own customer master, you end up with 5 customer definitions and duplicate records. This is a common failure. Avoid it by enshrining master data governance as a pre-requisite to mesh.

Anti-Pattern: Governance Gaps

If domains publish products without versioning, access controls, or quality standards, the mesh becomes a swamp. Every product is different; consumers don't know what's safe. Enforce governance policies globally before enabling domain autonomy.

Anti-Pattern: Over-Decentralization

Giving each domain a separate Datasphere tenant and zero coordination is chaos. Large organizations need some shared infrastructure (common governance, shared semantic layer, central compliance team). Full autonomy is a myth.

The pragmatic approach is mesh-informed, not pure mesh. Accept that some centralization (master data, hierarchies, compliance) is necessary. Decentralize aggressively within those boundaries. The result is faster, more responsive, and actually sustainable.

Organizational Structure and Roles

Data mesh success depends on clear roles and accountability. The traditional structure—a central data team reporting to IT—doesn't scale. Instead, adopt this structure:

Domain Data Product Owner (Reports to Domain Leadership)

Owns the business strategy for the domain's data products. Decides what data products to publish, sets quality and freshness SLAs, manages versions and deprecations, and owns the product roadmap. Works closely with data engineers and domain stakeholders. In a mature setup, owns a small budget for their data products' infrastructure.

Platform Engineer (Reports to CTO/Engineering Leadership)

Operates the Datasphere and SAC platforms. Manages infrastructure (capacity, upgrades, security patching), defines global governance policies, and provides self-serve tooling for domain teams. Does not author domain data products; enables domain teams to author their own.

Data Governance Steward (Reports to COO/Chief Compliance Officer)

Defines and enforces global governance standards (compliance, privacy, retention, audit). Works with domain product owners to apply standards to specific products. Integrates with legal, compliance, and audit teams. Maintains the official semantic definitions (working with MDG).

Domain Data Engineer (Reports to Domain Data Product Owner)

Authors data products using Datasphere. Owns data quality, lineage, and documentation. Troubleshoots data issues and works with source system teams to fix upstream problems. In larger domains, there might be 3-5 engineers; in smaller domains, one engineer covers multiple domains.

Analytics Consumer (Reports to Domain Leadership)

Uses published data products to create insights. In the mesh model, consumers are self-served: they discover products in Business Data Cloud, create stories in SAC, and iterate. They don't submit data requests to a central team.

This structure aligns incentives. Domain owners are rewarded for creating valuable, reusable products. Platform engineers are rewarded for enabling scale and reducing friction. Consumers are empowered and fast.

Change Management and Organizational Readiness

Shifting to a mesh architecture is a cultural change, not just a technical one. Organizations must:

• Fund domain teams: Don't expect domains to publish high-quality products without dedicated engineers and product owners.
• Change incentives: Reward platform adoption and product reuse. Penalize shadow data lakes.
• Invest in training: Domain engineers need SQL, data modeling, and SAP Datasphere skills. Not everyone has these. Budget for training programs.
• Establish governance early: Don't go mesh-first; establish master data and compliance governance first, then decentralize.
• Communicate relentlessly: Explain why mesh matters, celebrate early wins, and address concerns from teams losing central gatekeeping power.

The transition typically takes 12-18 months for a mid-market company (500-5000 employees). Start with 2-3 pilot domains, prove the model, then expand.

Migration Path: From Centralized BW to Mesh-Informed Datasphere

Most SAP customers have legacy SAP BW/4HANA data warehouses. Migrating to a mesh-informed architecture is a phased journey, not a big bang.

Phase 1: Assess and Plan (Months 1-2)

• Audit existing BW artifacts. Which InfoCubes/ADSOs are high-value? Which are orphaned? Which have clear domain ownership?
• Map BW to domains. Decide which company codes/business areas map to data domains.
• Identify quick wins. Which 2-3 domains could become early pilots?
• Establish governance baseline. Document master data definitions, compliance requirements, and quality standards.

Phase 2: Platform Setup (Months 2-4)

• Provision Datasphere. Set up Spaces for pilot domains, establish connections to ERP/BW sources.
• Deploy Business Data Cloud. Set up the catalog, configure access controls, publish metadata standards.
• Establish platform team. Hire or train platform engineers and governance stewards.
• Define governance policies. Encode naming standards, PII handling, retention, and audit rules into Datasphere.

Phase 3: Pilot Domains (Months 4-8)

• Select 2-3 pilot domains with clear domain ownership and high product demand.
• Use the BW Data Product Generator to replicate BW InfoProvider data into the Datasphere object store and publish it as custom data products (after lifting BW to its private cloud edition).
• Manually enhance products: add semantics, SLAs, quality scorecards, and ownership metadata.
• Publish to Business Data Cloud and train domain consumers to self-serve.
• Measure success: product adoption, time-to-value, consumer satisfaction.

Phase 4: Expand and Iterate (Months 8-18)

• Migrate next wave of domains, incorporating lessons from pilots.
• Establish centers of excellence for domain data engineering and product management.
• Decompose large monolithic BW InfoCubes into focused data products.
• Retire legacy BW artifacts as products mature in Datasphere.
• Expand consumption tools (SAC adoption, self-serve analytics enablement).

Phase 5: Optimization (Months 18+)

• Consolidate redundant products across domains.
• Introduce advanced governance (Collibra/Informatica integration, lineage automation).
• Expand beyond SAP: share data products with Databricks, Snowflake via BDC Connect.
• Establish data monetization: identify high-value products and consider charging cross-company usage.

The key is starting small, proving the model, and scaling systematically. Organizations that try to migrate all BW at once fail; organizations that start with 2-3 domains and expand succeed.

Measuring Success: Mesh-Informed KPIs

How do you know if data mesh is working? Track these metrics:

• Product Adoption: % of active analytics users consuming data products vs. shadow sources. Target: 80%+ within 18 months.
• Time-to-Insight: Time from business question to data delivery. Baseline in centralized model: 2-4 weeks. Target in mesh: 1-3 days.
• Data Product Inventory: # of published, versioned, governanced products. Target: 20-30 per mid-market company.
• Reuse Ratio: # of consumers per product. Products used by 3+ teams represent good, reusable assets. Products used by 1 team are suspicious (probably replicated, not federated).
• Governance Compliance: % of products with documented ownership, versioning, quality scorecards, and access controls. Target: 100%.
• Data Quality Incidents: # and severity of quality issues discovered post-publication. Should decrease as products mature and ownership clarifies.
• Domain Autonomy: Time for domain teams to publish new products. Baseline: 4-6 weeks (depend on central team). Target: 3-5 days (self-serve, no waiting).

These metrics shift as maturity increases. Early in a mesh journey, focus on adoption and product inventory. Later, focus on autonomy and reuse. Success isn't binary; it's a trajectory.

Conclusion: From Warehouse to Mesh

Data mesh is not a product; it is an architecture pattern and organizational philosophy. Zhamak Dehghani's four principles—domain ownership, data as a product, self-serve platforms, and federated governance—address real problems in centralized data warehouses: bottlenecks, unclear accountability, slow time-to-value, and governance gaps.

SAP's modern stack (Datasphere, Business Data Cloud, SAC, BTP) provides the tooling to implement these principles. But tooling alone is insufficient. Success requires:

• Organizational willingness to decentralize data ownership to business domains.
• Investment in domain data engineering talent and data product management.
• Discipline to enforce governance (master data, compliance, quality) globally while enabling autonomy locally.
• Realistic roadmap: start with 2-3 pilot domains, measure success, and expand.

Organizations that adopt a mesh-informed approach (accepting some necessary centralization while decentralizing where possible) outpace those pursuing pure centralization or chaos. The result is faster insights, higher data quality, clearer accountability, and lower total cost of ownership.

The future of analytics in SAP is not warehouse-centric; it is domain-centric. Data mesh, implemented pragmatically, is the path to that future.