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.
Check out all topics 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!
tip #4: How to Build Custom Extensions
tip #5: Plan Ahead with Compatibility Packs
tip #6: Gain Insight to Build a Solid Business Case
tip #7: Hardware Planning and Data Volume Management
tip #8: Curate Your Master Data before Deployment
tip #9: Understand the Functional Impact
tip #10: Fix Issues Without Bogging Down Conversion
tip #11: Optimizing Downtime in Conversions
tip #12: Find Relevant SAP Notes
tip #13: Accelerate your Rollout with Test Automation
tip #14: Implementing SAP Fiori