SAP customers go through a burdensome task of preparing for an upgrade by analyzing and adapting the custom code to the new version. Then they will have to plan and spend resources in regression testing before they could use the system again. Customization in the past have been changes with no clear interface boundary with the core product. This led to the classic customizations not being upgrade safe. With the new SAP extensibility strategy that is proposed, upgrades will be completed quicker and safer with minimal testing efforts – ideally none. Intelligence enterprises would integrate with SAP cloud products through either in-app or side-by-side options.

The extensions that are SAP-provided would even come with SAP guarantee that they will not be impacted by SAP upgrades. Success Factors, Concur, Ariba, and other SAP products have to integrate with S/4HANA. For this purpose, the new extensibility strategy provides standard APIs in API Business Hub, CDS (Core Data Services) views and standard business events. The new SAP extensibility strategy offers low code/no code tools that quickly help build and connect to the core solution. These extensions are “lifecycle-stable” as their lifecycle is independent of the core solution. They do not hinder the SAP updates and also continue to work as usual after the updates.

Low Code/No Code SAP Extensibility of Business Data Models

With a low code/no code development model, most tasks are done through drag, drop, and clicks. There is more emphasis on declarative and visual development. It helps in democratizing the development process. For instance, when the sales team of a company that runs SAP would like to quickly categorize customers for a promotion to decide which customers are high value and deserving a higher reward in promotion, they’re in  a desperate need of data categorization of customers based on several criteria like outstanding balance, sales volume, sales revenue, and so on.

With enterprise organizations having thousands of customer accounts that are being handled by several sales representatives, additional data fields for customer categorization by extending the business partner model to track would add so much value. The classic extension strategy is to create the custom fields in the core solution. This customization logic must then make it to the check list of items that are run for every upgrade to confirm successful system upgrade.

Almost all SAP clients have such checklists that become unmanageable in a very short period of time making the testing of an upgrade cumbersome. With the new SAP extensibility strategy, it is now possible to create the customer fields on a separate layer on top of the core solution seamlessly. This is an agile development adding value to the business users through rapid delivery. When an upgrade happens only the core solution is in scope for the task, so the add-on layers where the customization resides is not in scope for analyzing compatibility issues to prepare for an upgrade. The customization will not break an upgrade process during the installation of the upgrade bundle, and core system testing after an upgrade is no more cumbersome as the testing checklist is manageable.

Likewise, data could be pulled from core solution and be exposed to authenticated users in a safe interface for consumption. In a classic data exchange, an RFC/BAPI call is often used. But with the new extension strategy the standard APIs would help in making the data available outside of the application layer. Many companies outsource their business processes or part of their business processes to vendors for cost cutting purposes. For example, a company outsources its ACH (Automatic Clearing House) process to a vendor. Then the vendor would require on a periodic basis the cash flow information and the bank balances.

Through the new extensibility strategy there is an innovative way to retrieve information for third party consumption. In this new innovative approach, at the add-on customization layer technical personnel or business analysts could create a custom data model through very minimal coding, mostly through drags, drops and clicks. The ownership of and monitoring the health of this extension is made user friendly through new SAP extensibility strategy.

These new supporting tools and system interfaces help provide a well-organized insight of data flows inbound and outbound. If an update to data in the S/4HANA system is sent back by the vendor – in this case whichever credits and debits in the bank balance are cleared by the banks would be sent back by the vendor for updating the GL – then we use the new extensibility tools to receive and safely update the system.

In-app Extensibility and Side-by-side Extensibility

In-app is an extensibility option for key feature customizations. If you want to add new fields, or add custom logic that is new or replacing existing logic or add more then In-app extensibility is you key to successful customization. Custom forms to meet your specific business needs, reports that has the data sliced and diced to your preferences are all now made easy through In-app extensions offering through an extensibility cockpit. The cockpit will help both technical personnel and business analysts alike in going through available data models, process model. They could now visualize their SAP extensibility options.

On the other hand, side-by-side extensibility enables developers to build their own applications or integrate existing 3rd party applications that are supplementing SAP S/4HANA, on-premise or cloud. All APIs that are currently available for side-by-side extensions are documented in SAP API Business hub. This is the extension that is best suited for partner solutions integrating with core SAP S/4HANA product. Given that the partner solutions are far more complicated than the in-house custom extensions, side-by-side extension strategy comes handy in decoupling from the core solution the partner solution’s technical factors, such as namespace requirements and different lifecycles, as well as business factors, such as the buying process, contracts, responsibility, and maintenance from the core product. Yet the partner solution is well integrated with the core.

SAP ECC ERP Grandfathered into Easy Transition to SAP S/4HANA

Because a new SAP extensibility strategy is being offered by SAP, it does not mean the old enhancement options (classic extension approach) are being discontinued. Unless an application module itself is discontinued, the classic extension approach will still be available for SAP clients, until it is notified to change.

Moving from SAP ECC ERP to S/4HANA? You could bring your classic extensions along. But these custom codes must now follow the migration guidelines that SAP has stipulated. Simplification items and migrated code check are among the procedures to be followed.

If you’re a legacy SAP ECC client who have moved to SAP S/4HANA, on-prem or cloud, then planning to implement your customizations in the decreasing order of preference of the below ranked options would be a good starting place for discussion.

1. Try adopting SAP S/4HANA’s new BADIs
2. Nextly, user exits, system exits, and enhancements
3. Modification of existing SAP codebase
4. Clone and adopt SAP codebase

Companies are looking for more and more capabilities of cloud based multi-platform agile features and less complexity when it comes to integration. Customers are also looking for to employ machine learning concepts in adapting to new data and process flows to help the users in a seamless experience. SAP S/4HANA cloud and SAP’s other cloud products are industry leading and could be fit to meet the business needs of varied range of companies. To learn more please contact us today.

Contributions by Gopal Krishnan