Business Data Architecture: Modeling Layers for Structured Transformations

[AllanHald]

Transformations end up everywhere

In the previous post, we established platform responsibility: who owns data and business meaning. We saw four principles - Cross-Platform Access, Business Meaning Ownership, Controlled Reuse, and Single-Source Ingestion - that prevent platform silos, duplication waste, metric drift, and ownership confusion.

But platform ownership alone doesn't prevent transformation chaos. Even when teams know WHO owns a metric, they still need a shared understanding of which transformations have been applied to data - and which haven't.

Without modeling layers, teams cannot answer critical questions about the data they receive:

• Has this data been harmonized, or is it still in source format?
• Have business rules been applied, or do I need to implement them?
• Are metrics already defined, or am I receiving raw transactions?
• What quality and structure can I expect from this dataset?

This lack of shared understanding leads to two failure patterns:

• Teams duplicate transformations because they don't trust what's already been done. A Snowflake team receives harmonized customer data from SAP Datasphere but reimplements the harmonization logic anyway - "just to be safe" - because there's no common language for understanding transformation state.
• Teams skip transformations because they assume work that hasn't been done. A Power BI team receives data and assumes business logic has been applied, building reports on incorrect assumptions about metric definitions - leading to silent errors that only surface when reports are reconciled.

Without a shared structure for how transformations are organized, you cannot trust what you receive or know what still needs to happen.

This problem exists even within a single platform. A Snowflake-only environment with three teams - Finance, Sales, and Operations - each building their own reporting layers. Finance defines "Customer" during harmonization, Sales defines it in the semantic layer, Operations never defines it at all. When a dashboard pulls from all three, "Total Customers" shows three different numbers - same platform, same source data, three different transformation paths.

The problem scales dramatically across multi-platform landscapes. When SAP Datasphere structures transformations one way and Snowflake structures them differently, cross-platform integration becomes guesswork - but the root cause is the same: no shared understanding of transformation state.

Modeling layers provide structure

Modeling layers solve this by creating a shared structure for transformation organization. They define which kinds of transformations are allowed at each stage of the data flow. Each layer has a distinct responsibility - technical handling, domain alignment, business definition, or analytical interpretation - ensuring these concerns stay separated.

The concept of layered architecture isn't new. SAP BW has LSA++. Snowflake and Databricks have Medallion architecture (Bronze, Silver, Gold). What's different here is one modeling discipline that works consistently across all of them - whether you run analytics on a single platform or across SAP BW, SAP Datasphere, Snowflake, Databricks, Microsoft Fabric, and any other platform in the landscape.

The architecture defines five modeling layers, representing a one-way flow from source data to analytics:

This structure prevents transformations from being applied arbitrarily. Ingestion preserves source data, harmonization standardizes it, the definition layer establishes business meaning, the semantic layer applies analytical interpretation, and the sharing layer controls exposure - each transformation happening exactly once, in the right place.

Metrics and measures are defined before analysis. Analytical preparation supports evaluation without changing meaning. Final analytical logic and KPI evaluation are applied only where analysis is performed. This separation enables predictable impact, clear lineage, and safe reuse.

One discipline across all platforms

Each platform implements the five modeling layers using its own technical constructs - SAP Datasphere uses spaces, Snowflake uses schemas, Databricks uses Delta layers - yet all follow the same separation of concerns.

The same five logical layers map to different technical implementations:

	SAP Datasphere	Snowflake	MS Fabric	Databricks
Ingestion	Inbound	Raw	Bronze	Bronze
Harmonization	Harmonization	Staging	Silver	Silver
Definition	Propagation	Intermediary	Gold	Gold
Semantic	Reporting	Mart	Gold	Gold
Sharing	Outbound	Secure Views / Data Sharing	OneLake Shortcuts / Power BI	Unity Catalog Shares

Note that Medallion architecture (Fabric, Databricks) combines business definition and analytical interpretation in the Gold layer. Where our five-layer model separates Definition (establishing business meaning) from Semantic (applying analytical logic), Medallion's Gold encompasses both - containing business-ready aggregates, star schemas, and semantic models together.

Cross-platform agreement

Beyond technical mapping, platform owners must explicitly agree on which transformations belong in which layer. Technical constructs vary by platform, but the responsibility assignments must be consistent - what counts as harmonization in SAP Datasphere must align with what counts as harmonization in Snowflake.

This isn't just about following a standard. It's about creating shared understanding across platform teams.

When a Snowflake team consumes data from SAP Datasphere's harmonization layer, they need to know exactly what transformations have been applied and which haven't. When they receive data from the definition layer, they must trust that business meaning has been established. Without this agreement, teams make assumptions about data quality and structure that lead to silent errors.

Cross-platform agreement is what allows teams to trust shared data.

When you receive data from the Definition layer, you know business meaning has been established - you can build analytical interpretations without redefining metrics. When you receive data from Harmonization, you know structures are standardized but business logic hasn't been applied yet - you understand exactly what still needs to happen.

This shared structure must be maintained as platforms evolve. When harmonization transformations in SAP Datasphere change, Snowflake teams consuming that data immediately understand what changed - because both platforms follow the same modeling layer discipline. The shared structure tells them: harmonization transformations were updated, business meaning in the definition layer remains unchanged. When new platforms are added to the landscape, they adopt the same layer discipline to maintain this shared understanding across the entire analytics landscape.

Controlled exposure through the sharing layer

 The Sharing layer deserves special attention because of one important characteristic: data can be exposed from any upstream layer - not just from the Semantic layer.

This flexibility is critical where different consumers need data at different stages of refinement - data scientists need harmonized transactions, cross-platform teams need defined metrics without analytical interpretation, and BI users need fully calculated models.

 

 The Sharing layer serves different types of consumers, each needing data at different stages of refinement. Consumer-specific shaping - such as column filtering, regional access controls, or format conversion - is applied without introducing new business logic:

• Share from Ingestion layer: SAP Datasphere shares raw S/4HANA extracts to Snowflake's landing zone - original source structure preserved, with column filtering for sensitive fields
• Share from Harmonization layer: Databricks shares harmonized IoT sensor data to SAP Datasphere for operational reporting - data is standardized and cleansed, with device-level access controls applied
• Share from Definition layer: SAP Datasphere exposes the Revenue metric (defined once) to Snowflake for manufacturing profitability analysis - metric definition preserved with consumer-specific currency formatting
• Share from Semantic layer: Snowflake shares analysis-ready revenue reports to Power BI - fully calculated models with row-level security for regional teams (EMEA users see only EMEA data)

Critical constraint: The Sharing layer applies security, access control, and formatting only. It must not introduce new business logic or analytical transformations.

This ensures that shared data preserves the meaning defined in upstream layers.

This implements Post 3's "Controlled Reuse" principle - data is shared across platforms without silent redefinition of business meaning.

Common concerns

When organizations first encounter modeling layers, several practical questions arise:

Does this take away team autonomy? No. Modeling layers do not control what teams build. They define where different types of logic belong, so teams can work independently with trusted data - knowing which transformations have already been applied and can be reused by others. Without this clarity, teams duplicate work because they don't know what exists or can't trust its quality.

Why can't we just transform data wherever it's convenient? Because convenience-driven transformations lead to duplicated calculations, inconsistent metrics and measures, and unpredictable change impact. When the same transformation appears in multiple places - some in ingestion, some in semantic models, some in reports - you cannot trace lineage, predict what will break, or trust that metrics mean the same thing everywhere.

Does this slow delivery? It may add a small amount of upfront discipline, but it reduces repeated downstream fixes by ensuring metrics and measures are defined before analytical interpretation - not recreated in every report or tool. Teams that skip the definition layer spend more time reconciling "why these two reports show different revenue" than they would have spent defining revenue once, correctly, upstream.

Do modeling layers force us into one technology? No. Modeling layers are a logical structure that can be mapped to different platforms while preserving the same business meaning and transformation discipline. SAP Datasphere, Snowflake, Databricks, and Microsoft Fabric all implement these layers differently - but the separation of concerns remains consistent.

Up next

Modeling layers define where transformations belong. The next post introduces how these transformations are organized into reusable, controlled assets:

Data Products as the Foundation for Controlled Reuse

• How metrics, measures, and dimensions are packaged into data products
• Why data products are the primary building blocks for analytics across platforms

This blog post is part of the Business Data Architecture for Modern Analytics Landscapes series.

⬅️  Previous Post | Next Post ➡️