Business Data Architecture: Data Products - Structured Reusable Analytical Assets

[AllanHald]

Why Data Products

In the previous posts, we established which platform owns each business domain and how platforms share data without fragmenting meaning, and where transformations occur through modeling layers - the foundation that organizes data flow from ingestion through harmonization, definition, semantic interpretation, and controlled sharing.

Now we define what is built - Data Products.

Without clear contracts, analytical assets fragment across platforms - the same metric calculated differently in SAP Datasphere, Snowflake, and Power BI, with unclear ownership and duplicated logic. Data Products solve this by grouping related transformations by purpose - all logic for Revenue stays together, all structure for General Ledger stays together - with explicit contracts defining purpose, ownership, and reuse.

This approach establishes three key characteristics:

• Structured organization of analytics assets: Data Products organize data in a consistent, predictable, and self-describing way across types and domains, making it clear where data is sourced from and how different analytical assets are intentionally grouped
• Clear separation by data product type: Different data product types serve distinct roles in the data flow, with clear intent and scope for each type
• Reusable and composable analytics assets: Built on the structural discipline provided by the modeling layers, Data Products are the primary reusable building blocks for analytics, enabling solutions to build on existing data products without rebuilding logic

These characteristics are enforced through a clear contract. But what does that contract actually contain?

What makes a data product different from a dataset or view

While datasets, views, and data marts can organize and transform data, data products add an explicit contract - grouping multiple transformations by purpose with clear ownership and reuse rules. Every data product answers four fundamental questions:

• What does it contain? (Data product type defines the content and purpose)
• Who owns it? (Platform and domain ownership is explicit)
• What transformations does it contain? (Grouped by purpose, documented and versioned)
• How can it be reused? (Dependencies and allowed compositions are documented)

When someone opens a data product, they immediately understand what belongs there and how it is structured - reducing handovers, rewrites, and reverse-engineering.

Data product types: clear separation by role

The first contract question - what does it contain? - is answered by data product type. While data products are often described by business use case (Customer 360, Revenue Analytics), this architecture defines eight foundational types that provide architectural structure for how those use cases are built. Each type serves a distinct role in the data flow.

These eight types organize into four categories that reflect the data flow: source-aligned types preserve system detail, business-meaning types establish shared semantics, consumer-facing types enable consumption, and cross-cutting types support all layers.

Let's explore each type in detail, understanding its purpose, modeling layer placement, characteristics, and implementation across platforms.

Source-Aligned Data Products

These data products capture and harmonize data from source systems, preserving business transaction detail and entity definitions.

Business-Meaning Data Products

These data products establish shared business context, metrics, and analytical perspectives - independent of source system structure.

Consumer-Facing Data Products

These data products shape and expose data for specific analytical needs and consumption platforms.

Cross-Cutting Data Products

This data product type spans all modeling layers, providing enterprise-wide lookup and control data used across all other data product types.

These eight types work together in the data flow. For example, manufacturing data progresses through multiple types: Production Event Transactional DP (captures raw events) feeds Production Order Context DP (establishes process structure) which supports Manufacturing Cost Metric DP (calculates business outcomes). Not every source needs all types - reference data may only need a Reference DP, while complex business areas build through multiple layers.

Context vs. Dimension: Context products define process structure and operational flow (General Ledger establishes the structural foundation for financial accounting, Production Order establishes the structural foundation for manufacturing). Dimensions define how you slice that data for analysis (Organization hierarchy lets you group by region/department, Production Line hierarchy lets you compare across plants). Context is the stable structural foundation; Dimension is the analytical lens you apply to it.

When to use which type:

• Transactional: To ingest and preserve detailed business events from source systems
• Master: To ingest and preserve source system identifiers, attributes, and hierarchies
• Context: When you need stable process structure without calculations (defining how processes operate)
• Metric: When you need summable business outcomes at a defined grain (revenue, cost, quantity)
• Dimension: When you need hierarchical slicing for analysis (organization structure, product hierarchy, time periods)
• Analytical: To apply KPIs and comparisons (ratios, variances, rankings, time-based logic)
• Sharing: To expose data across platforms (with security, access control, consumer-specific views)
• Reference: For enterprise-wide lookup and control data (code lists, mappings, calendars)

Data product type allocation to modeling layers

Data products group transformations by purpose. The allocation below shows which modeling layers each type uses - determining which transformations can occur where.

This explicit allocation prevents common anti-patterns: business metrics defined in harmonization layer, or analytical calculations in definition layer. When data product types are allocated correctly, the modeling layers and data product types together control where transformations occur and how data is structured.

Data flow and composition

Data products are designed to compose, not duplicate. Instead of reimplementing business logic in each analytical use case, data products build on other data products - business rules are defined once and reused everywhere. This composition follows clear flow patterns that prevent circular dependencies and maintain unidirectional progression from source detail to analytical insight.

The architecture defines two distinct flow patterns:

Primary data flow builds business meaning progressively. Source data flows through transactional data products into context data products. Master data products flow into dimension data products. Context products always flow through metric data products before reaching analytical data products. This ensures every business outcome, whether a complex calculation or a simple count, is defined once as a reusable metric. Analytical products then apply interpretation (KPIs, ratios, comparisons) on top of these metrics.

Data sharing exposes data products across platforms and tools. Metric, Analytical, and Dimension data products can be shared through sharing data products with appropriate security, access control, and consumer-specific shaping applied. This enables cross-platform composition - Revenue metrics defined in SAP Datasphere can be consumed by Snowflake for manufacturing profitability analysis, while Manufacturing Cost metrics from Snowflake feed back into SAP Datasphere for consolidated management reporting.

Reference data products support both patterns as cross-cutting lookup and control data.

Reference data products support both patterns as cross-cutting lookup and control data.

When data products compose correctly, changes are absorbed at the right level - structural changes in context products, metric changes in metric products, analytical interpretation in analytical products. Each layer protects downstream consumers from changes that don't affect them.

Why the same data product structure matters across platforms

Organizations with both SAP platforms and cloud data platforms often contain decades of accumulated logic spread across SAP Datasphere views, InfoProviders, Snowflake schemas, dbt models, and Power BI datasets - with the same business meaning implemented differently in each platform.

When data product structure is consistent across platforms, teams gain a shared language. A Metric Data Product in SAP Datasphere has the same purpose, structure, and lifecycle as a Metric Data Product in Snowflake. The clear contract eliminates ambiguity about purpose, ownership, and reuse - reducing handovers, rewrites, and reverse-engineering.

This shared structure enables:

• Cross-platform composition: The Revenue Data Product can be created in SAP Datasphere and consumed by Snowflake analytical data products - business meaning is preserved because both platforms use the same data product contract
• Consistent change management: When a revenue recognition rule changes, the team knows exactly where to make the change (Revenue Data Product) regardless of which platform it lives on - changes flow predictably to all consuming platforms
• Decentralized ownership with shared concepts: SAP data platform teams and cloud data platform teams can work independently using the same data product vocabulary - no central committee needed to coordinate every artifact

The same data product types across platforms create a common way of working. Teams can communicate clearly about what exists, what's missing, and what's still temporary - regardless of whether the conversation involves SAP Datasphere, Snowflake, or downstream analytics tools.

Without this shared structure, each platform develops its own vocabulary: "Analytical Models" in SAP Datasphere, "dbt models" in Snowflake, "semantic models" in Power BI. Teams spend time translating between platforms, and business logic fragments into platform-specific variants that silently diverge over time.

Up next

Data products group transformations by purpose. The next post explores what those transformations are and how they're controlled:

Transformations: Controlled Change Within Data Products

• What transformations are and how they define allowed change within data products
• How transformations are allocated to data product types and modeling layers
• Why transformation discipline prevents business logic from fragmenting across platforms

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

⬅️ Previous Post | Next Post ➡️