Where the semantic layer should live

Scale and reuse expectations

Question: How many teams and tools need the same metrics?

Datasphere-optimized: If revenue, customer count, and margin need to work across SAC, Power BI, Tableau, and Excel — centralize in Datasphere. One definition, many consumers.

SAC-acceptable: If only SAC users consume analytics and each team maintains their own metrics — SAC models work. Trade reuse for speed.

BW-fit: Large BW investments with mature metrics — keep semantics in BW during transition. Reduces migration complexity.

Governance and compliance maturity

Question: How much audit trail and stewardship do you need?

High governance: Regulated industries (finance, healthcare, pharma) need Datasphere's versioning, lineage tracking, and stewardship capabilities. Audit logs must survive, and Datasphere keeps them 30 days by default (configurable up to 10,000 days), so export them.

Moderate governance: BW or Datasphere both work. BW offers mature governance; Datasphere offers transparency and modern tooling.

Light governance: SAC models with clear ownership are acceptable. Document who owns what and rely on analytics team discipline.

Team structure and operating model

Question: How are data and analytics teams organized?

Separate data and analytics teams: Explicit semantic ownership in Datasphere. Data team owns definitions; analytics team consumes them via live connection.

Cross-functional squads: Split ownership works well. Core metrics in Datasphere; team-specific derivations in SAC.

Centralized analytics center: Strong governance in Datasphere. All metrics flow through review and approval before exposure.

Distributed power centers: Hybrid approach. Datasphere for enterprise metrics; local SAC for department-specific work with clear escalation paths.

Modernization stage and platform investment

Question: How far along is your cloud journey?

Cloud-first (no legacy BW): Datasphere from day one. Design reuse and governance into the architecture immediately. No migration debt.

BW modernization in-flight: Hybrid approach. Identify which metrics move to Datasphere and when. Create a transition roadmap to avoid "everything everywhere" fragmentation.

Heavy BW investment: Keep semantics in BW until business case justifies migration. Use hybrid approach during transition. Don't force artificial timelines.

Post-modernization: Full Datasphere ownership. Legacy BW can be sunset once all metrics successfully consume from Datasphere.

Pattern: Hidden semantics in dashboards

What happens: Calculation logic lives in SAC stories. When a metric needs to change, you find it's defined 7 different ways across 7 stories.

Why it happens: Dashboard builders want speed. Defining logic locally feels faster than waiting for governance.

Prevention: Establish a rule: complex metrics belong in Datasphere or BW, not in SAC formulas. Make it easier to reuse than to duplicate. Provide an escalation path for new metrics.

Pattern: Visual alignment without semantic alignment

What happens: All dashboards look identical, but the underlying metric definitions differ. Business sees alignment; auditors see chaos.

Why it happens: Dashboard designers align UI without aligning source logic. Fragmentation is invisible until you audit.

Prevention: Make lineage visible. Show consumers where metrics come from. Periodic audits: do all revenue calculations actually use the same definition?

Pattern: Waiting for platform clarity before defining ownership

What happens: Teams delay semantic decisions hoping that moving to Datasphere will "solve this later." It rarely does.

Why it happens: Modernization feels like the moment when clarity will magically appear. Clarity never appears on its own.

Prevention: Define ownership today using tools you have now. Be explicit: this metric is owned here, by this team, with this approval process. Write it down. Revisit during modernization, don't rediscover.

Pattern: Semantic coverage before consumption readiness

What happens: Teams build comprehensive semantic models before consumption teams are ready to use them. Models become disconnected from business need.

Why it happens: Data teams optimize for theoretical completeness rather than pragmatic reuse.

Prevention: Build semantics iteratively based on actual consumption requests. Expose metrics as they're needed, not as they're possible. Expect iteration — some metric definitions only clarify once consumption begins.

Phase 1: Identify what needs governance

Audit existing metrics across SAC, BW, and legacy tools. Which ones are replicated? Which ones have definition drift? Prioritize enterprise metrics: revenue, customer, product hierarchies, profitability.

Effort: 2–4 weeks

Outcome: Prioritized list of metrics to centralize

Phase 2: Design exposure architecture

If Datasphere is your target, design which metrics expose to which tools. Create a data dictionary: for each metric, document the owner, definition, consumption tools, and SLA.

Effort: 2–3 weeks

Outcome: Published data dictionary and exposure rules

Phase 3: Pilot semantic centralization + data products

Move 3–5 high-value metrics to Datasphere. Connect SAC live, and connect Power BI and Tableau through OData or SQL. Package initial metrics as custom data products (local tables in a file space, published through the Data Sharing Cockpit), document lineage to source systems, and use release states on the underlying views so consumers can depend on metric stability. If external teams use Snowflake, Databricks, or Google BigQuery, test BDC Connect zero-copy sharing to validate cost and latency. Feed dimension hierarchies from governed master data (SAP Reltio or SAP MDG) to prove governance continuity. Validate that consumption teams can use them reliably.

Effort: 6–10 weeks (data product packaging and master data linking add 1–2 weeks)

Outcome: Proven pattern for metric reuse, data product lifecycle, and external sharing; demonstrated master data linkage

Phase 4: Scale incrementally with model stacking

Based on pilot learnings, establish a regular cadence for metric migration. Not all at once — move metrics as consumption requests arrive or as natural refactoring opportunities emerge. As scale increases: Use analytic model stacking to layer derived semantics on top of base models; stacked models inherit the base definitions, and a shared analytic model can be stacked in another space. For example, base models contain raw dimensions and measures; a second layer stacks market-adjusted or currency-normalized metrics; a third layer applies business rules. A financial organization might stack: Layer 1 (actual data), Layer 2 (currency-normalized data), Layer 3 (compliance-adjusted metrics). Keep master data governance (SAP Reltio or SAP MDG) in step as business rules change, so audit evidence stays current.

Effort: Ongoing; model stacking complexity emerges around 8–10 months

Outcome: Sustainable governance of semantic layer with layered sophistication and cross-tool orchestration