SAP Datasphere and SAP Analytics Cloud: Keeping Data Integration and Analytics in the Right Place

[Akbarali_DnA]

While exploring analytics architectures and discussing reporting solutions with different stakeholders, I repeatedly encounter the same question: When using both SAP Datasphere and SAP Analytics Cloud (SAC), where should data integration, business logic, and KPI definitions actually live?

When organizations use both Datasphere and SAC, the boundaries between these responsibilities can sometimes become blurred. Both platforms offer powerful capabilities, but deciding what belongs in the data layer and what belongs in the analytics layer can have a significant impact on maintainability and consistency over time.

In this blog post, I share how I personally think about that architectural decision and the trade-offs I've observed when working with two common approaches.

To make this discussion more concrete, let's look at an organization that consumes data from multiple business applications and data sources:

• SAP S/4HANA
• SAP SuccessFactors
• CRM system
• Excel-based planning files

Business users require:

• Executive dashboards
• Sales analytics
• Financial reporting
• Planning and forecasting

At this point, the organization has access to data from multiple systems and must support a variety of analytical and planning requirements.

The challenge is not the availability of data itself, but determining where integration, harmonization, and business logic should be implemented.

Should KPI calculations, transformations, and semantic definitions be created directly within reporting tools? Or should they be centralized in a dedicated data layer before reaching the analytics platform?

In my view, both approaches can deliver business value, but they differ significantly in terms of scalability, governance, reuse, and long-term maintainability.

I've come across both of the following approaches in practice, and each has its own advantages and challenges.

Approach 1: SAC as the Integration Layer

One option is to place integration, harmonization, and business logic directly within SAC.

In this approach, source systems such as SAP S/4HANA, SAP SuccessFactors, CRM platforms, and Excel-based files connect directly to SAC. Data acquisition, transformations, calculations, and reporting models are managed within the SAC layer itself.

Business users then consume dashboards, analytics applications, and planning content built on top of these SAC models.

Initially, this approach is simple and easy to adopt. Since SAC handles both data integration and analytics, dashboards can be delivered quickly without introducing additional platform components. In my experience, this is one of the main reasons organizations start here. It works well for smaller implementations and can deliver value quickly. However, as the number of reports, data sources, and business users grows, challenges around consistency, reuse, and maintenance often start to appear.

Challenges I Often See as the Landscape Grows

Challenge 1: Duplicated Business Logic Leads to Inconsistent KPIs

Suppose several reports require the same KPI: Net Revenue = Revenue - Discounts

Initially, the calculation may exist in a single SAC model. As new dashboards and reporting requirements are added, the same logic is often recreated across multiple models.

In my experience, this is where problems usually start to appear. One report may be updated to include a new discount category while another continues using the original definition. As a result, the same KPI can produce different values across different reports.

This is often the first issue business users notice. The conversation quickly shifts from analyzing business performance to figuring out which report should be trusted.

What's interesting is that the underlying data is often correct. The inconsistency usually comes from maintaining the same business logic in multiple places and allowing it to evolve differently over time.

Challenge 2: Integration Complexity Grows Over Time

Another challenge I've seen is that analytics requirements rarely stay the same.

A project might start with just SAP S/4HANA and SAP SuccessFactors. Over time, additional requirements introduce CRM data, spreadsheets, planning files, and other operational systems.

As more sources are added, SAC ends up managing an increasing number of connections, acquisition processes, and transformations. What started as a simple reporting setup can gradually turn into a distributed integration layer spread across multiple models.

At this point, SAC is no longer acting only as an analytics platform. It gradually starts taking on integration responsibilities that can become difficult to manage as the landscape grows.

This made me ask a different question: what if integration and business logic were maintained in one central place and shared across all analytics and planning use cases?

This brings us to the second architectural approach: using Datasphere as the integration and semantic layer.

Approach 2: Datasphere as the Integration Layer

After seeing these challenges, I've often found that organizations move toward a different approach: centralizing integration, business logic, and KPI definitions in Datasphere.

In this setup, Datasphere sits between the source systems and SAC, bringing data together, standardizing it, and exposing a shared set of business definitions for reporting and planning.

Returning to our Net Revenue example, the KPI is defined once in Datasphere and then reused consistently across all reports and planning scenarios.

Personally, this is where I see the biggest value of Datasphere. In many architecture discussions I've been part of, connecting data sources wasn't the hardest challenge. The bigger challenge was making sure everyone used the same business definitions and calculated KPIs the same way.

As a result, SAC can focus on its core strengths:

• Analytics
• Visualization
• Reporting
• Planning

while Datasphere becomes responsible for:

• Data integration
• Data harmonization
• Business logic
• KPI definitions
• Semantic modeling

From an architectural perspective, I like this separation because each platform focuses on the responsibilities it was primarily designed to support.

With this architecture, the same business logic is consumed by all reports and planning applications. Changes to KPI definitions are implemented once in Datasphere and become available consistently across downstream consumers.

Benefits of Centralizing Logic in Datasphere

Consistent KPIs Across Reports

Business definitions are managed centrally rather than being distributed across multiple SAC models. This helps ensure that reports, dashboards, and planning applications use consistent calculations and business rules.

Easier Growth Over Time

KPIs, calculations, and transformations are defined once and reused wherever needed. New reporting initiatives can leverage existing semantic models instead of recreating logic from scratch.

Reduced Maintenance Effort

Changes to business requirements are implemented in a single location. This significantly reduces the effort required to maintain reporting solutions as the analytics landscape grows.

Improved Governance

Centralized ownership of business definitions improves transparency and makes it easier to manage changes, validate calculations, and apply consistent standards across the organization.

Better Scalability

As new reports, planning scenarios, and business teams are added, they can build on existing models instead of creating their own versions of the same logic.

In my opinion, these benefits become increasingly important as reporting moves beyond individual departments and starts supporting enterprise-wide decision making.

My Takeaway

When I think about this topic, I try to avoid treating it as a choice between a "right" architecture and a "wrong" architecture.

For a limited number of reports, implementing logic directly in SAC may be completely reasonable and could be the fastest way to deliver business value.

However, once multiple teams, shared KPIs, governance requirements, and long-term scalability enter the discussion, I personally lean toward a centralized semantic layer.

If I were starting a new analytics initiative today and knew that multiple teams would rely on shared KPIs and reporting, I would place integration, harmonization, and business logic in Datasphere from the beginning. It would save a lot of maintenance effort later on.

Conclusion

One thing I've learned is that there is rarely a one-size-fits-all architecture.

For smaller reporting scenarios, implementing logic directly in SAC can be a practical and efficient choice. However, as the number of reports, data sources, and stakeholders grows, keeping business logic in a central place becomes increasingly important.

That's why I generally prefer using Datasphere for data integration and business logic, while letting SAC focus on analytics, reporting, and planning.

From my perspective, the biggest benefit of this approach is not the technology itself, but the consistency it creates. When business definitions and KPIs are managed centrally, reports become easier to maintain, easier to scale, and easier for users to trust.

Keeping data integration and analytics in the right place helps each platform do what it does best, while creating a more sustainable analytics landscape for the future.