SAP BTP Use Case: Strategy for Building Application Extensions for SAP S/4HANA

In today's era, business reports always demand custom feature innovations, specific reports, or complex approval workflows, but modifying the ERP core often ends up becoming "technical debt" that hinders future upgrade processes. We must find a balance between rapid innovation and sustainable system stability, right?

To overcome this dilemma, SAP Business Technology Platform (SAP BTP) comes as a smart solution. Imagine your SAP S/4HANA core is a solid house foundation; you do not want to change that foundation every time you want to add a terrace or a new room. SAP BTP allows you to build additional features separately, which we call Side-by-Side Extensibility. This is a safe and scalable way to develop the unique capabilities your business needs without ever touching or cluttering the main core system.

Why is "Clean Core" Crucial?

Before diving into the technicalities, let's talk strategy. In many SAP S/4HANA migration projects I have handled, the toughest challenge was not the data migration itself, but handling thousands of lines of legacy custom code (Z-Programs).

SAP is now actively campaigning for the "Keep the Core Clean" strategy. The idea is simple: keep your ERP core standard (vanilla) so it is easy to update (upgrade) every time SAP releases a new version, and place all innovations or customizations outside that core. This is where SAP BTP plays its role as a Platform-as-a-Service (PaaS) that serves as the home for those innovations.

Key Point: SAP BTP is not just a cloud database. It is an integration and application development foundation that separates your business innovation lifecycle from the ERP maintenance lifecycle.

In-App vs Side-by-Side Extensibility: When to Use SAP BTP?

Not all customizations should be placed on SAP BTP. SAP distinguishes between two types of extension approaches. Understanding the characteristics of both will save your IT budget and development time.

1. In-App Extensibility (Extensions Inside the Application) This approach is carried out directly within the S/4HANA environment. It is the solution for light changes.

• Code Location: Runs within the S/4HANA ABAP stack.

• Target User: Key Users or Functional Consultants (does not always require heavy programmers).

• Complexity: Low to Medium.

• Dependency: Highly dependent on the Core ERP.

• When to Use? When you only need to hide fields, change labels, add simple validation logic, or create lightweight custom analytics.

2. Side-by-Side Extensibility (Side-by-Side Extensions via SAP BTP) This approach uses SAP BTP as a separate platform. It is the solution for strategic innovations.

• Code Location: Runs on the SAP BTP cloud (outside S/4HANA).

• Target User: Professional Developers / Programmers.

• Complexity: High (Capable of handling complex business logic, AI/ML, or IoT).

• Dependency: Decoupled from the Core ERP.

• When to Use? When you need to build new applications (Mobile/Web), external vendor portals, integrations with third-party systems, or complex workflows.

As explained in official SAP architecture documentation, using Side-by-Side is recommended when you want to build applications that require access to ERP data but also require modern cloud services.

Case Study: Building a Procurement Approval Portal

Let's look at the most sought-after use case: A Mobile Purchase Approval Application.

The Problem (Pain Point) Your company uses SAP S/4HANA. Field managers travel frequently and struggle to approve Purchase Orders (PO) because they must log in to the SAP GUI via VPN, or the standard Fiori interface is considered too complex and heavy for areas with weak signals.

The Solution with SAP BTP We will build a lightweight application (Mobile/Web) on top of SAP BTP that "talks" to S/4HANA.

1. Technical Architecture Here is the data flow of how this solution works:

• Backend (S/4HANA): PO data and release logic remain in S/4HANA.

• Connectivity (Cloud Connector): A secure tunnel installed on your on-premise server to connect S/4HANA with the SAP BTP account without opening random firewall ports.

• API Management: Manages OData Services (APIs) sent from S/4HANA.

• Frontend (SAP Build Apps): Uses low-code/no-code features in BTP to create a mobile-friendly user interface (UI).

• Workflow (SAP Build Process Automation): Manages logic, such as if a PO > 1 Billion it requires Director approval, if < 1 Billion a Manager suffices.

2. Advantages of This Approach By moving this approval application to SAP BTP:

• User Experience (UX): Users get a very simple interface, similar to everyday consumer apps.

• Security: Users do not log in directly to the main ERP database.

• Flexibility: If you want to change the app's look next month, you don't need to touch the S/4HANA configuration at all.

Long-Term Business Benefits

Based on implementation experience, companies that adopt SAP BTP for extensions gain real benefits:

• Faster S/4HANA Upgrades: Because the core system is not modified, the annual version upgrade process (e.g., from 2022 to 2023) runs smoothly without needing massive regression tests on custom code.

• Broader Talent Pool: Developing on BTP (Cloud Foundry environment) allows your IT team to use popular programming languages like Java, Node.js, or Python, not limited only to the specific ABAP language.

• Ecosystem Integration: Simplifies connections with non-SAP systems (e.g., Salesforce or third-party HRIS) using the SAP Integration Suite within BTP.

Conclusion & Recommendations

SAP BTP is a vital bridge for companies that want to maximize their SAP S/4HANA investment. By moving complex customizations to BTP (Side-by-Side Extensibility), you maintain the "health" of your main ERP while remaining agile in innovation.

If you are currently planning a migration to S/4HANA or feel your current system has too many modifications (Z-code) that are weighing it down, start auditing your custom code. Identify which ones can be moved to SAP BTP. Let Soltius help you audit and identify opportunities for migration to SAP BTP, so your migration process runs smoothly without unnecessary technical burdens.