Having worked with both approaches extensively, here’s my perspective on the three key areas you mentioned.
Semantic Modeling in Datasphere:
Datasphere’s semantic layer is specifically designed for planning and analytics scenarios. You model business entities (cost centers, GL accounts, organizational units) as semantic objects with relationships, hierarchies, and measures defined declaratively. This maps naturally to multi-dimensional budgeting requirements. The graphical interface makes the model transparent to business users, which helps with governance and documentation. However, you’re operating in a different paradigm than ABAP - it’s more akin to dimensional modeling in traditional BI tools. For complex budget allocation logic or custom calculations, you may still need scripting within Datasphere or SQL-based transformations.
CDS Extensibility and Governance:
CDS views offer superior extensibility when requirements evolve. Your ABAP team can quickly add fields, modify joins, or adjust authorization logic using familiar tools and transport mechanisms. Governance is straightforward - standard ABAP package structure, transport management, and code review processes apply. The challenge comes when you need planning-specific features like write-back, version management, or what-if scenarios. You’ll build these capabilities from scratch, which means more custom code to maintain. CDS excels at read-optimized analytical queries but wasn’t primarily designed for planning workflows.
SAC Integration for Planning:
This is where the approaches differ most significantly. Datasphere provides native planning model exposure to SAC - you define a planning-enabled view in Datasphere, and SAC can directly consume it for write-back scenarios. Version management, data locking, and delta handling are built into the integration. With CDS, you’re building the planning infrastructure yourself. You need custom ABAP logic to handle planning data from SAC, manage versions in S/4HANA tables, and ensure consistency. The Analytics Cloud connector can expose CDS views for read, but write-back requires significant custom development.
Recommendation:
For your budgeting scenario with write-back requirements, I’d lean toward Datasphere if you can invest in the learning curve and establish proper governance processes. The time saved on planning infrastructure and native SAC integration typically outweighs the governance overhead. However, if your budgeting is primarily top-down distribution with limited write-back, or if your team is strongly ABAP-focused and resistant to new tools, CDS with custom planning logic is viable. Consider a phased approach: start with CDS for reporting, then evaluate Datasphere when write-back requirements become critical. This gives your team time to build Datasphere skills while delivering immediate value with familiar technology.