Series of Technology Essentials for Moving to SAP S/4HANA – tip #4: How to Build Custom Extensions

This is a series of blogs written by SAP subject matter experts to prepare you for your journey to SAP S/4HANA. Ready? Let’s go!

Topic #4 is building custom extensions.

For modern enterprise systems, a clean digital core is the way to cope with the accelerating speed of business. Our “clean digital core” paradigm is simple: allow customers to extend their SAP S/4HANA software while making updates eventually non-events.

The extensibility concept of SAP S/4HANA adheres to the “clean digital core” paradigm and is illustrated below. It consists of three main tool sets:

  • Key-user (in-app) extensibility
  • Developer (on-stack) extensibility
  • Side-by-side extensibility on SAP Business Technology Platform (SAP BTP)

In most cases, your applications will use these in combination; it is almost never an either/or decision.

Whether you’re assessing a new business requirement or rethinking an existing custom application, you need a set of architectural patterns to lean on when building custom extensions for SAP S/4HANA. Here are the five most common:

  • Cloud application pattern – Create a new application built on SAP BTP and integrated with SAP and third-party, on-premise, and cloud products based on standard and custom APIs.
  • Hybrid application pattern – Improve the user experience by exposing your application’s user interface through SAP BTP while the application logic and data reside in your SAP S/4HANA or other SAP or third-party system.
  • Key user (in-app) extension pattern – Empower stakeholders with key user tools and embedded analytics to enhance SAP Fiori apps and analyze data on their own.
  • Developer (on-stack) extension pattern – Allow your development teams to build extensions on the same application platform that your SAP S/4HANA uses.
  • Classical extension pattern – Keep your existing custom developments and enhancements from your SAP ERP application. Choosing this option should be an exception because it does not support the clean core paradigm.

Make sure to select the most suitable target architecture for an extension based on your business requirements rather than on the technical implementation of existing custom code or the skill set of your development team. For example, exposing an extension to customers, vendors, or field employees requires a cloud architecture – even through it means redesigning your existing custom solution.

For guidance in choosing the right architectural pattern for your extensions, see the decision matrix in “Part Four” of this white paper.

Earlier blogs of the series:

tip #1: Check Your Add-ons. Now.

tip #2: Check Your Finance Data Quality

tip #3: Don’t Just Rework Custom Code. Rethink it!