The architectural shift toward a clean core significantly reduces upgrade risks in the ERP while simultaneously increasing the operational complexity of the cloud landscape. For decades, the standard practice for extending SAP functionality—known as classic extensibility—involved modifying the ERP core directly through ABAP code. While this offered deep integration and local execution speeds, it created a significant technical debt trap where every upgrade risked breaking custom logic, leading to months of testing and high costs. In the current enterprise environment of 2026, organizations have recognized that this legacy approach is no longer sustainable for businesses that require agility and frequent updates to their digital core. By relocating custom business logic and specialized data models to the SAP Business Technology Platform, known as SAP BTP, organizations can innovate without compromising the stability of their central systems. This strategy, often termed the side-by-side extension model, ensures that the digital core remains pristine, standardized, and easily upgradeable, while the cloud-native innovation layer evolves at a much faster pace.
Modern enterprises are now pivoting toward the clean-core strategy as a standard operating procedure to escape the cycle of stagnation associated with monolithic architectures. The transition is facilitated by the SAP Cloud Application Programming Model, or CAPM, which serves as a model-driven framework allowing developers to focus on domain-specific logic rather than the underlying technical infrastructure. CAPM provides a set of languages, libraries, and tools for building enterprise-grade services and applications, promoting best practices such as “convention over configuration.” This model-driven approach abstracts the complexities of database persistence, authorization, and network communication, allowing development teams to be more productive. As the 2026 digital landscape becomes more fragmented and specialized, the ability to rapidly deploy extensions that interact seamlessly with S/4HANA while remaining technically independent has become a competitive necessity. This fundamental shift requires engineering teams to manage transactions and security in a distributed cloud environment, moving away from the safety of the local ABAP stack into a polyglot world of Node.js and Java on BTP.
Defining the Clean-Core Paradigm: The Strategic Shift
In a clean-core environment, the SAP S/4HANA system acts as a stable digital core, while SAP BTP serves as the innovation layer where custom processes reside. This separation allows the ERP to be upgraded on its own schedule without impacting custom applications, a feature that is essential for maintaining compliance and security in the modern era. The Cloud Application Programming Model is the preferred framework for this outer layer because it streamlines the development process by using Core Data Services to define data models and services. These models are then compiled into OData or REST services, providing a unified way to handle data across the entire landscape. By utilizing this framework, developers can ensure that their extensions are cloud-native by design, facilitating easier integration with other cloud services such as machine learning and advanced analytics that are native to the BTP environment.
Transitioning to this model requires a new mindset regarding how data is shared and how systems interact across boundaries. It is not just a structural change; it is a commitment to decoupling custom logic from the standard ERP package to prevent the accumulation of future technical debt. Moving logic to the cloud introduces distributed-system challenges such as network latency and eventual consistency that do not exist in local ABAP calls within the same server memory. Developers must account for the possibility of service unavailability and implement patterns like circuit breakers or retry logic to ensure system resilience. The paradigm shift also involves moving from a single-tier development mindset to a multi-tier architectural approach where the frontend, business logic, and database layers are physically and logically separated across different cloud regions or subaccounts.
The maturity of the clean-core strategy in 2026 has led to a standardized way of handling extensibility through various tiers. While classic extensibility is discouraged, on-stack developer extensibility using the ABAP Cloud model is used for logic that must reside close to the data. However, for most user-facing innovations and external integrations, side-by-side extensions on BTP are the gold standard. This multi-layered approach ensures that the digital core stays clean while providing the flexibility to build highly customized user experiences. This ensures that the core remains agile and ready for the next wave of SAP technological updates, such as the periodic releases planned for the 2026 to 2028 roadmap. Organizations that have successfully adopted this paradigm report significantly lower total costs of ownership for their ERP systems and a much higher velocity for rolling out new features to their global business units.
Service Composition: Balancing Synchronous and Asynchronous Flows
One of the most critical design choices in any extension is how it communicates with the S/4HANA core to retrieve or update data. Synchronous OData calls are often used for transactional use cases requiring immediate responses, such as checking real-time stock levels or performing a price calculation during a sales order creation process. While these calls provide the immediate feedback that users expect in high-intensity applications, they also create a direct dependency between the BTP extension and the ERP system. Over-reliance on synchronous calls ties the extension’s availability to the core system’s uptime; if the ERP is undergoing maintenance or experiencing performance issues, the extension may also become unresponsive. This tight coupling contradicts some of the primary goals of a distributed clean-core architecture and must be managed through careful service design and the use of caching mechanisms where appropriate.
Asynchronous events, powered by tools like SAP Event Mesh or SAP Advanced Event Mesh, are the recommended default for the majority of integration scenarios in a clean-core setup. By using a message broker, the core system can publish business events, such as the creation of a new business partner or a change in a material master record, without waiting for the BTP extension to process them. This decoupling improves system resilience and allows the extension to handle bursty traffic without putting unnecessary pressure on the ERP’s resources. In 2026, the use of event-driven architectures has become the standard for building scalable extensions that react to business changes in real-time. This approach allows developers to build “side-effects” to ERP processes, such as sending notifications or triggering third-party workflows, without modifying the original transaction in the digital core.
The selection of the right integration pattern is essential for balancing the need for real-time data with the goal of system independence. Architects often employ a hybrid approach, using synchronous calls for reading small amounts of high-velocity data and asynchronous events for data replication and background processing. CAPM simplifies this by providing built-in support for both types of communication through its service consumption features. Developers can define remote services in their CDS models and switch between synchronous and asynchronous handlers with minimal code changes. This flexibility allows projects to evolve as business requirements change, ensuring that the architecture remains robust as the volume of data grows. Furthermore, the use of event-driven patterns facilitates better error handling, as failed messages can be retried automatically by the messaging infrastructure without human intervention.
Implementing Multitenancy: Managing Shared and Isolated Logic
A recurring challenge in scaling cloud extensions for large global organizations is the requirement for multitenancy. Extensions often begin as single-tenant solutions for specific business units, but as they grow, the need for rigorous data isolation between different departments or geographical regions becomes paramount. Retrofitting tenant isolation into a deployed application is often a disruptive and costly affair that involves restructuring the database and modifying the application’s security logic. In the current 2026 landscape, building multitenant-ready applications on BTP has become the norm for organizations that want to offer internal software-as-a-service models to their various subsidiaries. This approach ensures that while the application logic is shared and maintained in a single location, the data for each tenant remains completely segregated and secure.
The Cloud Application Programming Model addresses this complexity by providing specialized packages, such as the mt-services or the newer CDS-MTXS, which support a shared application with an isolated data model. This architecture allows a single provider subaccount to run the application code, while maintaining separate database containers for each consumer tenant within the SAP HANA Cloud environment. This design satisfies strict regulatory and compliance requirements regarding data residency and privacy, as it ensures that users from one tenant cannot access the data of another under any circumstances. Moreover, the MTXS package automates many of the operational tasks associated with multitenancy, such as the provisioning of new tenants and the deployment of database schema changes across all active containers during an update.
Starting with multitenancy in mind is a best practice for any enterprise-grade BTP project because it allows for easier scaling across the diverse landscapes of a modern corporation. By building on these foundations, developers ensure that their applications are ready for the complexities of a global structure without needing a complete rewrite in the future. This scalability is particularly important for businesses that engage in frequent mergers and acquisitions, as new business units can be onboarded onto existing cloud extensions as new tenants with minimal technical overhead. The ability to manage multiple business entities on a single codebase while maintaining absolute data isolation is a key enabler of the operational efficiency promised by the SAP Business Technology Platform in its 2026-2028 strategic roadmap.
Security Foundations: The Role of Principal Propagation
In traditional extensions, developers often used technical users with broad permissions to call the ERP, a practice that is now considered a major security flaw in the zero-trust environment of 2026. Using a generic account to perform actions on behalf of multiple individuals obscures audit trails and makes it nearly impossible to determine who actually initiated a specific transaction within the system. Furthermore, this approach often bypasses the granular authorization checks that have been carefully configured within the S/4HANA system over many years. Modern architectures demand a more sophisticated approach to identity management that preserves the identity of the end-user throughout the entire request chain, from the browser to the BTP extension and finally to the digital core.
Principal propagation is the consensus solution for this problem in a clean-core architecture. This mechanism uses OAut## and JSON Web Tokens to carry the actual end-user’s identity and permissions from the BTP extension down to the S/4HANA core. When a user logs into a CAPM-based extension, the SAP Authorization and Trust Management service, or XSUAA, issues a token that represents that user. This token is then exchanged for a short-lived certificate or another token that the ERP system recognizes, allowing the ERP to execute the request using the permissions assigned to that specific user. This ensures that the ERP logs reflect the person who actually initiated a change, maintaining the integrity of the audit trail and ensuring compliance with international financial and security regulations.
By using principal propagation, organizations can leverage the ERP’s existing authorization checks instead of trying to replicate them in the cloud layer. This creates a secure environment where every request is authenticated and authorized based on the specific user’s rights, effectively bridging the security gap between the cloud innovation layer and the digital core. CAPM facilitates this by providing declarative security features where developers can define required roles and scopes directly in the data model using annotations. The framework then automatically validates these tokens against the configured security services, reducing the likelihood of human error during the implementation of security logic. This robust security posture is essential for protecting sensitive corporate data as it flows between different parts of the distributed SAP landscape.
Data Modeling Strategy: Referencing over Replicating
When building a data model in CAPM, developers must avoid the temptation to replicate massive amounts of master data from the digital core into the cloud extension’s database. This legacy practice often leads to severe data synchronization issues where the extension’s copy of the data becomes stale, resulting in incorrect business decisions or failed transactions. In a clean-core world, the extension should store only the necessary identifiers, such as a Sales Order ID or a Customer Number, and fetch the current state of the object from S/4HANA on demand using remote service calls. This “reference-over-replication” strategy ensures that the application always works with the single source of truth residing in the ERP, while minimizing the storage and synchronization costs associated with cloud databases.
The Cloud Application Programming Model allows developers to use hooks to add logic to OData requests via custom handlers, which is a powerful way to implement this referencing strategy. For example, a custom handler can be programmed to reach out to S/4HANA to fetch real-time status updates while the user is viewing a record in the extension. The CAPM service acts as an orchestrator, seamlessly combining local data, such as a custom risk assessment, with remote data from the ERP. This orchestration happens at the service level, meaning the frontend application remains simple and does not need to know where the data is coming from. This approach also allows for a more responsive user interface, as the system can load the local data immediately and fetch the remote data asynchronously as it becomes available.
This declarative approach to development extends to authorization as well, where security is defined through annotations within the data model rather than being hard-coded into the application logic. This ensures that even if there is an error in the custom handler code, the framework-level security checks remain in place to protect sensitive information from unauthorized access. By keeping the data model lean and focused on the specific needs of the extension, developers can create more agile and performant applications. This strategy also simplifies the process of evolving the application over time, as there are fewer data dependencies to manage when the underlying ERP system undergoes a version upgrade or a configuration change.
Operational Excellence: Monitoring and Observability in the Cloud
Operating a cloud-native extension requires a completely different toolkit than traditional SAP Basis monitoring that administrators have used for decades. A CAPM service is only as good as its observability, which is vital for maintaining the health of a clean-core architecture where failures can occur at any point in the distributed network. Structured logging is essential because a single user request might traverse multiple services, including the web frontend, the CAPM business logic, the BTP Destination service, the Cloud Connector, and finally the S/4HANA core. Without structured logs and unique correlation IDs, it is nearly impossible for operations teams to trace a request through the landscape to identify where a failure occurred or where a performance bottleneck is hidden.
Distributed tracing tools, such as those compatible with OpenTelemetry, allow architects to identify exactly where latency is occurring in the system in the current 2026 environment. Whether a bottleneck exists in the custom Node.js logic, a slow database query in HANA Cloud, or a delayed response from the S/4HANA OData API, tracing provides the necessary visibility to resolve the issue quickly. This data-driven approach to troubleshooting reduces downtime and improves overall user satisfaction by allowing teams to be proactive rather than reactive. Many organizations now integrate these traces into centralized dashboards that provide a real-time view of the entire extension landscape, allowing for rapid response to emerging issues before they impact a large number of users.
Alerting strategies must also evolve to prevent the common problem of alert fatigue among site reliability engineers. Instead of alerting on every minor anomaly, teams should focus on high-level symptoms that directly affect the business, such as high error rates for critical transactions or significantly increased response times for key APIs. By establishing robust operational procedures and utilizing the built-in monitoring capabilities of SAP BTP, organizations can manage the increased complexity that comes with moving custom logic out of the core. This focus on operational excellence ensures that the cloud-native innovation layer is just as reliable and stable as the digital core it extends, providing a solid foundation for the business’s digital operations.
Strategic Integration: Advancing the Resilience of Modern Systems
Architects and development teams realized that the transition to a clean core was a necessary evolution for maintaining business agility in a rapidly changing market. The implementation of CAPM on SAP BTP provided the structured framework needed to decouple custom logic from the ERP without sacrificing the deep integration required for complex business processes. Organizations that successfully adopted these patterns found that they were able to upgrade their S/4HANA systems in a fraction of the time previously required, as the risk of breaking custom Z-code was largely eliminated. The use of asynchronous event-driven patterns and robust principal propagation created a resilient and secure landscape that could scale to meet the demands of global operations.
The strategy provided a clear roadmap for moving away from legacy technical debt and toward a future-proof architecture. By prioritizing multitenancy and observability from the beginning of the development lifecycle, teams ensured that their applications were not only functional but also operationally sound. The move toward a reference-based data model reduced data silos and ensured that the ERP remained the single source of truth for critical business information. This shift in architectural philosophy empowered developers to use modern tools and languages while remaining within the governed and secure environment of the SAP ecosystem, bridging the gap between traditional enterprise software and modern cloud-native development practices.
Organizations prioritized the education of their workforce to handle the transition from ABAP-only environments to polyglot cloud development. This investment in human capital, combined with the technical capabilities of SAP BTP and CAPM, allowed companies to innovate at the edge while keeping the core stable. The lessons learned from early production deployments helped refine the best practices for configuration management and security mapping, leading to more predictable project outcomes. As the 2026-2028 cycle continues, the focus has shifted toward further optimizing these extensions with advanced analytics and autonomous processes, all built upon the solid foundation of a clean-core architecture that has proven its value in the enterprise.
