The problem: When ownership isn't explicit
In the previous post, we established how to define business meaning by separating what you measure (Metrics) from how you analyze it (Measures and Dimensions). When Finance defines "Revenue" as a metric with its measures (Actual, Budget, YTD, Variance), that business ownership is clear.
But one critical question remains: Where should these definitions be implemented?
Without explicit platform responsibility, organizations end up with Revenue calculated differently on each platform, duplicate ingestion pipelines, and no clear answer to "which platform should implement this?" when changes are needed.
This post shows how to make platform responsibility explicit - so business-owned metrics are implemented once on the right platform and shared safely across platform boundaries.
Four principles of platform responsibility
To assign implementation responsibility, you first need to understand what each platform is for - its analytical purpose, aligned to specific users and business decisions.
Platform purpose is about business responsibility, not technical architecture:
- Which business domains does this platform serve?
- Which users and decision scenarios depend on it?
- What business processes does it primarily support?
Example: Platform Purpose
- SAP Datasphere - ERP Analytics Platform: Owns all core business metrics from SAP S/4HANA (revenue, cost, margin, customer, product) and serves Finance, Sales, and Controlling users. Primary decision support: financial reporting, business performance analysis, and management KPIs.
- Snowflake - Manufacturing & Supply Chain Platform: Owns operational metrics from external manufacturing execution systems (MES) (production efficiency, capacity utilization, cycle time, schedule adherence) and serves Operations, Plant Management, and Supply Chain users. Primary decision support: production planning, manufacturing optimization, and supply chain analytics.
Once platform purpose is clear, four operational principles define how platforms work together without creating fragmentation:
Cross-platform access
In practice: Revenue metrics owned in SAP Datasphere (ERP Analytics platform) are shared to Snowflake (Manufacturing platform) for profitability analysis by production line. The metric definition remains unchanged - only the analytical context differs.
Business meaning ownership
Ownership follows business responsibility, not data origin. The platform responsible for a business domain owns the metrics for that domain - even if data comes from other platforms.
In practice: Manufacturing Cost per Unit is owned on Snowflake (Manufacturing platform), even though cost data originates from SAP S/4HANA. The metric lives where the business knowledge lives.
Controlled reuse
This is where many multi-platform landscapes fail: teams start by consuming shared data, but end up redefining it "just slightly" to fit local needs, creating platform-specific metric variants.
Shared data must preserve shared meaning. Consumption is allowed, redefinition is not.
In practice: Customer master data is ingested into SAP Datasphere from SAP S/4HANA and exposed as a Customer Dimension data product. Snowflake and Power BI consume this shared dimension without creating their own customer hierarchies or customer segmentation logic.
Single-source ingestion
In practice: SAP S/4HANA Financial Actuals are ingested once into SAP Datasphere. Snowflake consumes this through Datasphere's sharing layer, ensuring both platforms work from the same data version with a single extraction pipeline - reducing complexity, ensuring consistency, and making lineage traceable. Before this, separate ingestion into both platforms created version conflicts and maintenance overhead.
What this prevents
These four principles aren't theoretical. They prevent real failure patterns that emerge when platform responsibility isn't explicit:
Common concerns
Organizations increasingly run analytics across heterogeneous platforms - SAP Datasphere, Snowflake, Databricks, Microsoft Fabric, and Power BI often coexist. This gives flexibility but increases fragmentation risk. Platform responsibility enables flexibility without fragmentation by allowing different platforms to serve different purposes while maintaining consistent business meaning.
The circular flow concern
The most common reaction to this approach is: "Won't this create circular data flows?"
Consider this scenario: SAP S/4HANA data is ingested into SAP Datasphere. That data is shared to Snowflake where Manufacturing Cost per Unit is defined (because Snowflake owns the Manufacturing domain). Now Finance wants to use that metric in management reporting - which runs on SAP Datasphere. The data flows back from Snowflake to Datasphere.
This looks like spaghetti. SAP data goes to Datasphere, then to Snowflake, then back to Datasphere.
But this is the wrong way to think about it.
The data doesn't move in circles. What moves is value at different stages of transformation:
- SAP Datasphere ingests raw transactional data from SAP S/4HANA
- Snowflake receives that raw data and transforms it into a business metric (Manufacturing Cost per Unit) - adding manufacturing domain knowledge
- SAP Datasphere receives that finished metric for consumption in management reports
The lineage is clear: raw data → domain-specific transformation → analytical consumption. The fact that the analytical consumption happens on the same platform that ingested the raw data doesn't make it circular - it reflects that SAP Datasphere serves Finance users for management reporting.
This is similar to how microservices architecture works. Service A calls Service B, which calls Service C, which returns data to Service A. That's not circular dependency - it's composition. Each service adds value at its layer.
The alternative - duplicating ingestion or moving all domain logic to one platform - creates the fragmentation these principles prevent.
The key question isn't "does data flow between platforms" - it's "does the flow follow clear responsibility boundaries?" If yes, the architecture is sound. If ownership is confused or metrics are redefined mid-flow, that's when you have a problem.
The organizational challenge
While the technical implementation of platform responsibility is well understood in 2026, the organizational shift is often harder than the technical challenge. For most platform teams, explicitly owning business meaning and exposing it as data products represents a significant cultural change.
Success requires:
- Clear accountability: Platform teams must accept ownership of data quality and business meaning for their domain
- Cross-team coordination: Shared dimensions and metrics require agreement across platform boundaries
- Sustained commitment: Building and maintaining data products is ongoing work, not a one-time project
Organizations that succeed treat this as an organizational transformation, not just a technical architecture exercise.
Up next
In this post, we focused on where business meaning should be implemented - making platform responsibility explicit. The next post explores how to implement it consistently:
Modeling Layers as a Shared Discipline Across Platforms
- How to control where data is transformed - from source to analytics
- Why the same modeling discipline must apply across SAP Datasphere, Snowflake, and other platforms
This blog post is part of the Business Data Architecture for Modern Analytics Landscapes series.
⬅️ Previous Post | Next Post ➡️
Bluesky
