Part 1 of 3: Understanding the New Reality for SAP Development and Operations
Introduction
If you’re an SAP professional who has spent years mastering transport management, ABAP development, and traditional SAP system administration, SAP S/4HANA Public Cloud might feel like stepping into an alternate universe. Everything you know about SAP change management has been fundamentally reimagined.
This isn’t just another SAP product update—it’s a complete architectural paradigm shift that affects how we develop, deploy, test, and manage SAP systems. For organizations considering Public Cloud, and especially for tool vendors and system integrators working in the SAP ecosystem, understanding these changes isn’t optional—it’s critical for survival.
The Fundamental Architecture Shift
What’s Different About Public Cloud?
Traditional SAP systems gave us unprecedented control. We could access the underlying ABAP stack, modify transport files, install custom programs, and integrate at the database level. S/4HANA Public Cloud strips away virtually all of this access.
No System-Level Access:
- No access to the underlying ABAP application server
- No file system access for transport files (.DAT, .COF files)
- No direct database connectivity
- No ability to install custom programs or agents
SaaS-First Architecture: SAP manages the entire infrastructure, platform, and application layers. Customers receive a pre-configured, standardized system with quarterly updates pushed automatically by SAP.
This isn’t a limitation—it’s by design. SAP’s “Clean Core” principle ensures system stability, predictable updates, and reduced total cost of ownership. But it fundamentally changes how we approach development and operations.
The New Change Management Reality
From Transports to Collections and APIs
The traditional transport request (with customizing and workbench changes bundled together) no longer exists in Public Cloud. Instead, we have multiple, separate change mechanisms:
- Business Configuration via Central Business Configuration (CBC) CBC orchestrates major configuration activities and business scoping. These configurations are deployed to development tenants and then exported via dedicated Fiori applications like “Export Customizing Transports” and “Import Collection.”
- Key User Extensibility via Software Collections Custom fields, CDS views, and other key-user extensions are grouped into Software Collections. These are exported and imported using dedicated Fiori apps, not traditional transport management.
- Developer Extensibility via Git-enabled Change and Transport System (gCTS) ABAP development now follows a Git-first approach. Code is versioned in Git repositories and deployed using gCTS, bringing modern version control practices to ABAP development.
- Side-by-Side Extensions on SAP BTP Complex custom applications are built as side-by-side extensions on SAP Business Technology Platform (BTP) and deployed as Multi-Target Applications (MTARs) using SAP Cloud Transport Management or CI/CD pipelines.
The Orchestration Challenge
This fragmentation creates a new challenge: managing dependencies and coordinating changes across multiple lifecycles. A single business change might require:
- Configuration updates via CBC
- Key-user extensions via Software Collections
- ABAP code changes via gCTS
- Side-by-side application updates via BTP deployment
Traditional change management tools that relied on transport request analysis become largely irrelevant. The value shifts to orchestrating these diverse change mechanisms and ensuring they work together harmoniously.
Clean Core: Principle and Practice
What Clean Core Really Means
“Clean Core” isn’t just a marketing buzzword—it’s a strict architectural principle that governs everything in Public Cloud:
No Modifications to Standard SAP Code: Unlike traditional SAP systems where you could modify standard programs (though it wasn’t recommended), Public Cloud makes this technically impossible.
Extension-Only Development: All customizations must use SAP-approved extension points:
- Business Add-Ins (BAdIs)
- Enhancement spots
- Key-user extensibility tools
- Side-by-side applications on BTP
Quarterly Update Compatibility: Every extension must remain compatible with SAP’s quarterly updates. This requires disciplined development practices and extensive testing.
Impact on Development Practices
Clean Core fundamentally changes how we approach SAP development:
Impact Analysis Shifts: Traditional transport analysis (identifying conflicts, dependencies, retrofits) becomes less relevant. The focus moves to ensuring extensions remain clean-core compliant and compatible with SAP updates.
Testing Strategy Changes: Testing must validate not just that extensions work today, but that they’ll continue working after SAP’s quarterly updates. This requires automated regression testing and continuous compatibility validation.
Skills Evolution Required: ABAP developers must learn modern development practices: Git workflows, API-first design, cloud-native architectures, and CI/CD pipelines.
The Integration Reality
Limited but Strategic Integration Points
While Public Cloud restricts direct system access, it provides strategic integration capabilities:
SAP Cloud ALM Integration: Cloud ALM serves as the official Application Lifecycle Management platform for Public Cloud. It provides APIs for change management, monitoring, and process orchestration—making it a critical integration point for external tools.
Adaptation Transport Organizer (ATO): ATO manages transport execution in Public Cloud environments. When integrated with Cloud ALM, it enables programmatic transport orchestration—a key capability for automation tools.
Standard API Exposure: Public Cloud exposes extensive REST APIs and OData services for business operations, though these are limited to what SAP officially supports.
The Evolution of DevOps in Public Cloud
The Public Cloud paradigm demands a fundamental rethinking of DevOps approaches. Traditional methodologies built around:
- Transport file manipulation
- Direct system access
- STMS integration
- Custom program installation
…are no longer viable in this environment.
Modern SAP DevOps must evolve toward:
- API-first integration strategies
- Cloud ALM as the primary orchestration point
- Cloud-native deployment model management
- Process governance and change orchestration across multiple lifecycles
The Business Case for Public Cloud
Why Organizations Choose Public Cloud Despite Limitations
Predictable Operations: SAP manages all infrastructure, updates, and maintenance. IT teams can focus on business value rather than system administration.
Faster Time-to-Value: Pre-configured industry solutions and best practices accelerate implementation timelines.
Built-in Innovation: Quarterly updates deliver new features automatically. Organizations don’t need to plan and execute major upgrade projects.
Total Cost of Ownership: Despite per-user licensing costs, the total cost often decreases due to reduced infrastructure, administration, and upgrade expenses.
The Trade-offs
Reduced Flexibility: Limited customization options may require business process changes.
SAP-Controlled Timing: Organizations can’t control when updates are applied, potentially disrupting planned activities.
Vendor Lock-in: Migration away from Public Cloud is significantly more complex than traditional SAP systems.
Looking Ahead: Preparing for the New Reality
For Organizations Considering Public Cloud
Assess Your Customization Landscape: Catalog existing customizations and determine how they’ll be addressed in Public Cloud. Heavy customizations may indicate that Private Cloud or on-premise deployment is more appropriate.
Invest in Change Management: The shift to Public Cloud requires new processes, tools, and skills. Change management becomes even more critical in this environment.
Plan for Continuous Adaptation: Quarterly updates are mandatory. Organizations must build capabilities for continuous testing, validation, and adaptation.
For Organizations and Development Teams
Embrace API-First Architecture: Integrate with official SAP APIs and supported integration points like Cloud ALM for comprehensive change management.
Focus on Orchestration: Shift from system manipulation to process orchestration across multiple change mechanisms and deployment lifecycles.
Develop Cloud-Native Expertise: Understanding BTP, Cloud Transport Management, gCTS, and cloud-native development practices becomes essential for modern SAP operations.
Conclusion
SAP S/4HANA Public Cloud represents a fundamental shift in how we think about SAP systems. It’s not just a deployment option—it’s a complete reimagining of the SAP architecture with profound implications for development, operations, and tool ecosystems.
Organizations and professionals who understand and adapt to this new reality will thrive. Those who attempt to apply traditional approaches will struggle with frustration and limited success.
The shift is challenging, but it also creates opportunities. Clean Core architecture, when properly implemented, delivers more stable systems, predictable operations, and faster innovation cycles. The key is embracing the paradigm shift rather than fighting it.
In our next blog, we’ll dive deep into development best practices for Public Cloud environments, exploring how to build extensions that are not only functional but also future-proof against SAP’s continuous update cycle.
This is Part 1 of our 3-part series on SAP S/4HANA Public Cloud. Coming up in Part 2: “Development Best Practices for the Clean Core Era” – where we’ll explore practical approaches to building robust, update-safe extensions in Public Cloud environments.
Leave A Comment