Realizing a Clean SAP Core: A pragmatic approach towards digital transformation

Introduction

The world today witnesses a massive digital transformation especially in the industrial, economic and social facets, impacting organizations globally through fast-evolving business models. Consequently, SAP, world’s leading ERP Software organization is transforming its flagship products with all the more flexibility and robustness. To enable this agility within the foundations of ERP, SAP has repositioned its key product offering, to shift to a new ‘digital-core’, in the form of SAP S/4HANA powered by capabilities of its in-memory database HANA. With recent SAP S/4HANA product releases, also into its Cloud flavors, the new digital core offers a fascinating array of new innovations, ranging across digital-age User Experiences, next-gen end-to-end Business Processes, and Embedded Intelligence through seamless integration and automation options.

Numerous existing SAP customers however are still on the former SAP ERP (ECC or older) systems, with many of them engaging industry specific components to support their businesses. With SAP’s future plans of withdrawing support and maintenance for its legacy ERP product, customers are required to devise an upgrade strategy to move to S/4HANA solutions namely through ‘Brownfield’ implementation projects. In the process, project teams typically deal with several technical challenges in their custom code management, around aspects like complexity, dependency to SAP standard, upgrade stability etc. This is where the catchphrase ‘Clean-Core’ comes in, which essentially emphasizes on fitting to standard offerings, extending them appropriately, and decoupling custom objects with minimal dependency to standard solution lifecycle, outside the central ERP, therefore making the ‘Core’ clean. The coming sections will elaborate the needs, benefits and ways to achieve a realistic ‘Clean Core’ modern SAP solution.

Customer Perspective

It is common knowledge that standard ERP software requires customizations for various business motives. Research data suggests a sweeping majority of customers rely on their custom code to fulfill their business needs. Although SAP provides a solid set of standard capabilities, most organizations require additional functionality to support business processes that are unique and allow for differentiation from competitors. Most of these are established firms using SAP ERP for decades, and have continuously enhanced or modified the standard software over various periods of time using ABAP language. As per recent market research conducted by reputed SAP user groups (ASUG 2021), about 91% customers count on their custom code enable their businesses better. Some further custom code drivers are listed as follows –

• 50% for providing unique user experiences
• 46% for regulatory requirements
• 45% for implementing innovative solution
• 35% for localization needs
• 32% for a competitive edge over others

However, these customizations along with their high volumes, contribute towards quite a few organizational and technical impediments. About one-third of the customer community have expressed concerns over finding the right level of expertise needed to manage their custom code, with lost business knowledge through attritions, compounding the issue. Custom code complexities often come in the way of accomplishing satisfactory security practices. Needless to say, high costs are associated to manage custom codes, with organizations spending almost half of their annual IT budget. More importantly, over 60% of the customers complain, that custom code comes as barriers when it comes to upgrading to new SAP releases. In summary, custom code for SAP customers may have become an integral part of businesses, but there is a definite need for a strategy in place to manage the burden it creates, and lay foundations for modernization and innovation.

Clean Core: Need & Benefits

SAP products are evolving rapidly delivering more business functionality coverage, improved performance, and innovative technology features. Amidst all of this, existing customers need a mechanism to stay flexible and must be equipped to embrace the new-age offerings. Typically, classical extension methodologies, especially core modifications get in the way of smooth software upgrades, and lead to subsequent maintenance issues. In pursuit of modernizing legacy SAP applications, customers or partners often find system conversions quite cumbersome, typically requiring lengthy projects involving teams of consultants. In order to streamline these, SAP emphasizes on keeping a light and clean core ERP stack, with the rationale of allowing customers to extend their core software stack, while making the upgrade cycles ‘non- events’ in due course. This enables faster software deployments, fairly comfortable adoption of new innovations, along with reduced cost of ownership.

Below is a list of key benefits of a Clean Core SAP solution, in a nutshell –

• Smoother and faster upgrade cycles
• Innovation speed at par with market
• Lower cost of ownership
• Future proofing and Cloud readiness
• Fixed pricing models for service providers
• Leaner and proficient architecture

Guidelines from SAP

Starting with Björn Goerke’s (former CTO and head of SAP Cloud Platform) keynote at SAP Teched 2018 and eventually through many subsequent conferences and events, SAP has been heavily endorsing the message, “Keep the core clean”. It has been asserted that over-customization at base level makes it harder to integrate new applications and data sources, without ‘breaking’ the system. With the problem statement and context being established here, it’s let’s understand the guiding principles from SAP in this regard. Fundamentally there are four main aspects to keep in mind, for an ideal clean core approach, as defined by SAP –

Avoidance: Applying a “zero-modification” policy from the beginning. Retiring redundant objects and fitting to standard as much as possible – while remaining flexible in adapting
business processes as per needs swiftly.

Leverage modern Extensibility: Identify standard objects and realize the full potential of approved extensibility options (In-app, side-by-side or hybrid) in the combination that best
suits business needs.

Upgrade-stability: Encouraging decoupling of custom extensions, such that “Custom extensions do not break an upgrade and upgrades do not break extension”.

Be Aware: Understand the technical debts and custom code footprint; review them regularly to make necessary changes, as feasible.

The guidance provided by SAP can be implemented through various means, which however, requires an in-depth analysis and understanding of the legacy attributes and relevance of the modern alternatives available.

Common realization challenges

Although ‘Clean-Core’ has been a buzz-word for a good few years now, many customers and partners across the SAP ecosystem struggle to understand and fully adopt the guidelines, due to some noticeable contributing factors, some of which are listed below:

• With the pace of advancement of technology in the past decade, companies often experience sub-optimal level of skills and awareness of the latest offerings and their capabilities
towards digital transformation.

• Traditional SAP implementations that exists over decades, have custom codes authored by various users for different purposes over different periods of time. These may have resulted in
the object developments go high on complexity, which are hard to decode or reverse-engineer. Consequently, existing teams aren’t completely able to gauge the technical debt arising
from their custom code.

• Some implementations may have still retained primitive ABAP coding in the legacy custom code, and also have overlooked equivalent standard released objects, ensuing increased volumes
of custom objects in their systems.

• Beyond the above drawbacks, a rather technical limitation is the non-availability of adequate ‘functional’ released APIs, in comparison to legacy ERP APIs (mainly Function Modules,
and other functional Class/Methods), making it harder to modernize applications or even make them cloud- compliant.

Cumulatively these aspects pose hindrances in realizing a clean solution and progressing to the modern architectural paradigms.

Implementing a true Clean Core – Comprehensive Recommendations

Considering the commonly observed customer implementation obstacles and nuances, together with the tools and recommendations available from SAP, below section elaborates the key driving principles towards a pragmatic approach to achieve a clean digital-core SAP solution.

Zero Core Modifications

It is crucial in the given context, to abide by a zero-modification strategy. While these are tightly controlled in most projects, modifying SAP standard should be treated as a prohibition, as these causes regression and hiccups during system upgrades, shooting up the testing efforts for each upgrade cycle. Besides legacy ECC systems, one could also attempt modifications in S/4HANA on-premise backend, as these seem to be quick ways to code for various business needs, however these are NOT recommended, and should indeed be a last resort for any implementation team. If at all modifications exists, for historical or unavoidable factors, the teams must engage in stringent quality processes such as maintaining automated unit tests for each core modifications like user exits, and undergo thorough regression tests upfront. It is hence always advisable to implement alternate extensions with lower coupling to SAP solution lifecycle.

Fit-to-standard business processes as much as possible

‘Fit-to-Standard’ is an approach that calls for adoption of standard business process solutions offered through the latest SAP product releases (mainly S/4HANA). It applies industry best practices to create a self-reliant solution for customers to operate effectively using SAP’s standard offerings, also emphasized prevalent initiatives such as SAP Activate methodology. It helps avoid ‘re-inventing the wheel’, rather adapt standard solution leveraging available configuration options to support the customer’s business requirements. This includes utilizing the standard scope items and usage of released APIs to integrate with other systems (SAP/non-SAP). Fitting-to-standard also helps to avail new innovative features from SAP, like Robotic Process Automation (RPA), SAP Co-pilot, and other ML driven capabilities, for example Automated Invoice Matching during Vendor Invoice clearing as a standard feature in S/4HANA. It certainly aids in future-proofing businesses, besides other benefits such as reduced implementation time and cost of ownership.

Handling Indirect Modifications to SAP Standard

Cloned programs (copies of SAP Standard objects) often cause maintenance hindrances, as they aren’t easily detected upfront during conversions/upgrades, unlike enhancements, which is why they pose risk to system stability. Custom object repositories can be scanned deeply for their resemblance to SAP standard objects, using SAP utilities like transaction /SDF/CD_CCA that can perform such analysis per custom package. Upon identification and review, these clone custom objects should be replaced (revert back) with SAP standard code of the upgraded system, unless cloning is absolutely required. Besides clones, other indirect modifications namely – Implicit enhancements at begin and Class-method overwrites (usually listed from SPAU_ENH checks) also need to be evaluated during upgrade cycles. Addressing these would contribute in stable upgrades, and also eliminate redundant custom objects.

Analyze Usage data and Retire unused objects

This is almost an obvious step that is necessary for all customers aspiring to clean up their core SAP system, where the productive usage data of the custom object repository needs to be analyzed. Research articles indicate that as much as 40-60% of custom code is not executed in production environments in actuality, which calls for evident action of retiring the unused custom objects from the core. This is a must-do activity for project teams, considering a moderate need for analysis efforts, owing to existing utilities like ABAP Call Monitor (SCMON), which helps get to the candidates that have no-usage in production, and can be considered for decommissioning. Needless to mention, this contributes to keep the core SAP system lighter and cleaner.

Lean and Upgrade-proof Data-models

SAP offers powerful data-modeling utilities – the fundamental units being, the Core Data Services (CDS) views – which sit at the core of modern ABAP programming models, and are very relevant for any type of application development in S/4HANA product versions (and beyond). SAP offers a plethora of CDS interface views, that define semantically rich data-models typically written on top of standard DDIC Tables at base-level. These entities are bound by release contracts and based on their release statuses, they also feature as released APIs. Usage of released standard CDS Views are mandatory for cloud developments, and also consequently (even in on-premise) helps adhere to clean core principles by imposing usage of standard upgrade-stable artifacts, for example, I_CUSTOMER or I_SUPPLIER in place of KNA1 and LFA1 respectively.

When it comes to modernizing and cleaning up the legacy SAP system, it would be very helpful to analyze DDIC data-models from custom applications (typically SQL operations on combined database Tables), and identify a set of matching released CDS views by performing Table-Field level mapping through the corresponding CDS metadata (including direct and associated components). Furthermore, database fields that are not covered through the standard CDS views, usually the custom fields, can then be candidates for CDS Extensions, essentially applying the in-app extension concept. It is thereby strongly recommended to make use of standard released CDS views, alongside their extensions as much as possible, and create new custom CDS views only when it is really necessary to do so. This way one can ensure an upgrade-proof data-modeling with minimal custom artefacts in the system.

Compare and Consolidate Custom objects based on Functional Commonality

Custom applications are generally written over discrete timelines by different developers for various purposes, which results in new custom objects in the landscape, in spite of similar-functioning (partly or fully) applications. In the pursuit of cleaning the core, it is therefore worthwhile to analyze for functional commonality amongst custom applications. This may be performed by evaluating two key aspects – DDIC based data-models and API usages. Most custom applications typically have either or both of the above aspects contained within them. Custom objects can be scanned through to compare the SQL operations on DDIC Tables (or Views), as well as the various Function Modules and ClassMethod calls amongst custom applications, to arrive at an equivalence score pointing to the extent of commonality.

Through this process, one gets a fair idea about the extent of functional similarity between two custom applications, and also the common set of objects and data-model used to derive the same. This data can henceforth drive effective development decisions viz. – consolidating and refactoring multiple common applications into one, that can now leverage a unified data-model and API set; thereby eliminating the need for the redundant custom objects, ensuring a cleaner core, besides an optimal design. This also creates platform to re-architect applications using latest Restful ABAP programming model, thereby modernizing the custom application repository.

Realize full potential of Key-User (In-App) Extensibility modes

In modern SAP solutions (more so for Cloud), developers are not encouraged to adhere to classic extensibility options such as traditional SE80, or classic BAdis from Enhancement frameworks that were prevalent in SAP Business suite, owing to upgrade impediments and dependencies to non-whitelisted objects. Instead, most implementation teams are thereby recommended to leverage the core pillars of extensibility concept across all SAP S/4HANA product versions – namely In-App also known as, Key-User Extensibility tools in context of S/4HANA Cloud. Speaking of a clean-core solution, Key-user extensibility stands out as a much preferred methodology, with built-in extension capabilities from SAP, implementable on the same software stack, as enhancements to standard applications and artifacts. Key-user tools offer a comprehensive range of extension possibilities, starting from UI Extensions, to adding database fields and custom business logic on S/4HANA. It is non-disruptive (S/4HANA solution point of view) and provides a powerful set of utilities (mostly through Key-user Fiori Applications) that supports quite a few legacy extension scenarios, as described below.

Key-User%20Extension%20Modes

Key-User Extension Modes

• Adding Custom fields at an Application, CDS or Business Object level, catering to most of the standard Table extensions such as custom appends.

• Adding Custom Business Logic, achieved through a set of released BAdis from a given Business Context, where customers or partners can write business logic through a cloud-compliant
(restricted) syntax support.

• Adapting SAP UI based (FIORI) applications – Users (key-user) can add, move, hide, filter, rename labels or regroup fields on the UI for existing applications.

• Custom Business Objects – With this option, users can create own custom Business Objects (CBO) and its related data-model (custom tables), alongside multiple sub-nodes to the given Business Object.

• Exposing Custom Data – One can create own custom CDS views, based on standard and released CDS views which be enabled as external APIs for external data consumption

• Adding Custom Analytics – This option offers ability to build analytical queries based out of custom CDS views. This is typically built based on a SAP released analytical data source
(cube CDS views).

• Managing KPIs and Reports – This is another key-user option that allows adapting SAP delivered KPIs and reports by adjusting them to business needs.

• Add Custom forms or E-mail templates – This option allows customizing printed Forms and E-Mail templates based on existing data sources, where one can extend existing template with
custom fields as well.

Re-platforming decoupled custom developments (side-by-side) outside core to SAP BTP

Filling gaps to the standard solution, may not always be a customer’s viewpoint, and there will certainly arise the need for distinctive and innovative business solutions to gain a competitive edge, while also catering to the clean-core protocols. This demand can be addressed by implementing side-by-side scenarios, by developing or re-writing custom applications outside of core (S/4HANA system), preferably on the new Business Technology Platform (SAP BTP), that can interact with core data, but only using SAP approved APIs. While the previous mode was more applicable for enhancements to SAP objects within the core system, this one is suited for bespoke custom developments, that can be completely decoupled from standard solution, and are usually unaffected by upgrade cycles as long as they are integrated through permitted APIs.

It is also important here to evaluate the legacy custom developments wisely, to determine suitable conditions for an object to be decoupled from the core. One of the key factors to be considered in this regard – is the nature of coupling, that varies contextually. Some important aspects that determine the coupling type, includes – Lifecycle compatibility and upgrade stability, processing behavior (transactional) with respect to SAP standard data, authorizations and access levels etc. Ideally, a custom application can be decoupled as a side-by-side candidate, only when it satisfies the coupling conditions. These candidates generally should be loosely-coupled and are lifecycle-stable, which means the core application can be updated without any obligatory adaptations. In addition, they also must have approved (white-listed) APIs to be able to cover the underlying operations.

Side-by-side%20Extensibility

Side-by-side Extensibility scenario on SAP BTP

For a legacy customer, goal here is mainly to identify suitable custom objects that can be moved out of the core, and mapped to appropriate target applications supported by the new age BTP, as recommended by SAP. Typical example could be – a legacy custom sales application on core ERP, decoupled and re-platformed as a Sales Ordering UI based application built on BTP, that interacts via approved Remote APIs with Material master in the core S/4HANA system, integrated through SAP Cloud Connector. Another prevalent set of custom objects, that can be re-platformed could be the legacy custom configuration tables (customizing aka SPRO) – that may find its new successor in the Business Configuration Apps in SAP BTP ABAP Environment. Such side-by-side scenarios, consequently get customers closer to achieving a true clean core system. Moreover, with the new Restful ABAP programming model making its way, developing custom applications on BTP employing (restricted) ABAP skills, helps in utilizing existing SAP technical resources; which has been an advantage recently compared to the former CAP model.

Usage of released or whitelisted APIs

Customer scenarios typically have numerous integration needs which use legacy interface instruments to communicate within or outside core SAP system. As mentioned in the above sections, custom applications that are decoupled outside the core stack to BTP, also would need permitted interfaces for data exchange. It is hence advised to use only SAP released APIs (whitelists) as stable contracts of communication between systems. One also needs to be cognizant of the choice of APIs based on the concerned target platform, since the list of approved APIs differ for a typical key-user development, from that of an on-stack or cloud BTP implementation. SAP Help Documentation and the SAP Business API Hub, can serve as information sources for SAP’s released API list for cloud developments and functional White-listed APIs (per product version) respectively. Developers should consider building custom abstraction layer (Rest API) in case of missing whitelists for a given functional scope of development, and also ensure going through a proper release procedure for cloud usage and consumption.

Using Developer (on-stack) Extensibility

Recently, SAP delivered another innovation to its customers and partners, in the form of an advanced extension mode named Developer (on- stack) extensibility – especially with the availability of Embedded Steampunk (2021). While it is advised to carve custom developments out of the core SAP stack, there are scenarios where that’s not very convenient or feasible, for instance custom code that needs to run in proximity to the app being extended, also within the same logical unit of work.

Developer%20%28on-stack%29%20Extensibility%20Modes

Developer (on-stack) Extensibility Modes

Now with the new Steampunk development model embedded into the S/4HANA stack (Embedded Steampunk); yet another capability to develop custom extensions is attained, additionally it also brings desirable attributes of upgrade-stability and cloud-readiness, also supporting the new Restful ABAP programming model. Developers however need to use stable public APIs, and are permitted to code in Restricted ABAP language only. It also offers another benefit – it can, not only call the more technical released APIs, but also local public S/4 interfaces containing business functionality. It is certainly worthwhile to consider Embedded Steampunk while modernizing legacy custom code, with its capabilities already integrated with recent S/4HANA Cloud releases.

Re-think, Simplify, Being Aware and Ready

Typical SAP implementations have a wide variety of custom applications, based on business needs, development landscapes and integrated systems, to name a few factors. It is hence always logical to proceed with a combined modernization approach, depending on the nature of existing applications.

There would often be applications that perform multiple functionalities, and are understandably difficult to be mapped to a single target application type. With SAP’s latest offerings like Developer (on-stack) extensibility, customers would be better equipped to make implementation decisions matching their legacy application characteristics. It is hence crucial to have a thorough understanding and analysis of the existing architecture, functional classifications (e.g. RICEFW), object-level dependencies and other technical metrics, to make the right choice of target applications or solutions. A matrix with some of the modern solution options against the traditional RICEFW application types is shown below –

Legacy%20Vs%20Modern%20SAP%20Application%20Types

Legacy (RICEFW) Vs Modern SAP Application Types

There may also be some applications that are too complicated to be refactored, or even written in an obsolete or incompatible manner. It is recommended to diligently document such applications that are unable to be modernized or re-platformed, such that implementation teams totally aware of the technical debts. Lastly, there could be custom objects that are essential, and need to be retained in the core system. Implementation teams are recommended to undergo a cloud-readiness drive for such objects, through a series of ATC checks and related utilities, that also assists having an upgrade-stable codebase.

Conclusion

With customers having a multitude of customizations of various kinds, extents and complexities, it is hard to say ‘one-size-fits-all’, when it comes to adopting a clean core approach. It is essentially a game of balance maintaining a hybrid approach in accordance with the customers’ business and legacy code attributes. With regards to applying the modern extensibility concepts, Key-user (in-app) and Side-by-side extensibility are mostly advised to be used in combination and is less likely to be an either/or choice. Long story short, applying the clean-core strategy in essence, is almost like a mindset shift, in terms of reviewing the custom object repository – zooming in to some key aspects – like upgrade stability, similarity to SAP standard, and the nature of coupling – which helps determine the appropriate extensibility option. Additionally, a conscious effort needs to be made, to ensure minimal customization in the core ERP stack, rather make the most out of the SAP’s modern cloud based development and integration platforms. Last but not the least, it might be rather pleasing to realize, that in the pursuit of cleaning the core, customer’s code eventually becomes modernized and efficient, more importantly, cloud-ready!

I would also encourage readers interested in this topic to actively participate in related blogs and communities (links below).

https://community.sap.com/topics/abap-extensibility

https://community.sap.com/media/hands-on-sap-dev/embedded-steampunk

https://answers.sap.com/tags/338571334339306322581424656448659

https://blogs.sap.com/tags/338571334339306322581424656448659/

Winding up, I’d like to take the opportunity to thank the readers for taking the time to read through the blog, and would be glad to hear thoughts, suggestions or feedback, through the comments section below.