S/4HANA Clean Core, a pragmatic approach

Clean core is a term that is now frequently thrown around and occasionally used synonymously and slightly incorrectly, with side-by-side extension. The clean core approach refers to the simplification and optimisation of the SAP S/4HANA system to remove unnecessary complexity, improve performance and support upgradability. There are numerous methods to achieve a clean core and it is, in my experience a vitally important ingredient to a successful S/4HANA enabled business transformation. However, this definition is often confused or taken too literally, party influenced by what is possible within an S/4HANA public cloud environment and partly influenced by sales focussed statements that are often too idealistic or utopian and do not reflect the realities of an S/4HANA implementation programme. This can lead to customers having unrealistic and often impractical expectations of how extensions to their S/4HANA on premise or private cloud solutions should be delivered. The principles behind clean core are vitally important, not just from a technical and solution future proofing standpoint but also a program delivery standpoint. It is good practice not just because it can be used as a lever to reduce development scope and therefore program complexity but more importantly, the top-down mantra to pursue a clean core can be used to encourage business stakeholders to adopt fit-to-standard, re-prioritise their prior customisation needs and ultimately consider that what they built previously may not be right for the future.

What are the options when it comes to extending S/4HANA?

There are many great blogs covering this extensively, so I won’t cover this in detail but just for convenience, here is a quick overview.

• Building side-by-side provides a means to extend the ERP solution without the associated upgrade risk and on-stack technical debt. SAP’s portfolio of platform services continues to advance considerably with Cloud Application Programming (CAP), providing a strong framework for building cloud native applications on BTP, and this has proven to be a great step forward for full stack application development. However, it is important to note that CAP relies on a different skillset to those associated with traditional SAP implementation as it is based on Node.js and relies heavily on JavaScript skillsets. In recognition of the extensive ABAP skillsets available in the market after years of working in their native programming language, SAP also provided the Cloud ABAP Environment on BTP (formerly known as SteamPunk). This allows for side-by-side extension in ABAP although it adopts a RAP approach (ABAP RESTful Application Programming) which is more “cloud-ready” but does not allow the same level of freedom previously known by ABAP developers, driving them to adhere to a more controlled syntax but offering a revised paradigm with the Business Object being central to this.
• Side-by-side, whether CAP, ABAP or using other environments, undoubtedly has its place firmly cemented in S/4HANA enabled business transformation especially in the domain of decoupled, custom applications, however it is not the answer to meeting all business requirements that necessitate us to extend beyond what the standard SAP products provide. Recognising the need for On-Stack extension (even on S/4HANA Public Cloud) the following methods are available:
  
  
  • Developer Extensibility via the S/4HANA Cloud ABAP Environment (previously embedded SteamPunk) was introduced, carrying with it the same revised syntax as the BTP ABAP Environment, driving adoption of RAP and the use of whitelisted or public extension points. Note, with RAP whether side-by side or on-stack, developers use Eclipse with ADT, driving a move away from the traditional ABAP workbench GUI based transactions (SE80, SE84, CMOD, SMOD, SE24 for OOP etc.).  
  • Key User Extensibility via key User Apps such as Custom Fields or Custom Business Objects. This provides an additional ‘Key User’ ABAP syntax and was designed with citizen developers in mind.   
• For S/4HANA Cloud Public Edition the only way to extend is via the above methods however for S/4HANA on premise and S/4HANA Cloud Private Edition, traditional “On-Stack” extension methods, often referred to as “Classic” are also available to be implemented via the traditional ABAP GUI transactions, such as BADI and Customer exit enhancement spots, (SMOD, SE84, SE80 etc.).

The below diagram will be familiar to many of those in the SAP Architecture & Development communities with the exception of “Smart Core” which will be explained further below.

Can I always achieve a ‘clean core’?

If your organisation is large and complex, you likely customised heavily your legacy ERP to meet your business needs and the likely answer, as controversial as this may seem is “No” (at least not entirely). Even with devout commitment to a fit-to-standard design approach and with clean core at the heart of your development strategy, in certain areas you will simply have to deviate.

For those used to delivering S/4HANA enabled transformation programs the following will resonate:

• For the vast majority of medium to large organisations their complexity across at least some of their more critical business processes drives a necessity to extend the ERP solution.  
• The extension capabilities provided in S/4HANA cloud public edition don’t yet provide the full degree of flexibility, autonomy, and freedom that these more complex organisations need when it comes to enabling their business processes, especially in areas of higher strategic differentiation. This is a major reason why they elect for a private cloud or on-premise construct.
• These organisations typically require a significant degree of extension beyond connectivity (interfaces), outputs (forms), and workflows for example, and into the realms of enhancing or extending standard functionality, building entirely custom applications for supplementary functionality, and supporting the business with bespoke reporting capabilities.

Although I am fully supportive of, and completely aligned to the ideologies, concepts, tools and frameworks enabling a clean core approach, I am also cognisant of where these extension methods lack suitability, fit and maturity. For example:

Example Scenario 1:

A standard legacy GUI app meets 90% of required functionality noting that its Fiori equivalent has not yet been provided. It is possible to extend the legacy GUI app via a non-whitelisted BADI (therefore deemed Classic) or alternatively, an option would be to bottom up build a custom app on BTP to perform the equivalent functionality. Given the tightly integrated nature of the transaction functionality, any full stack app would need to replicate the 90% standard behaviour and then include the delta 10% custom functionality.

• Programme Outcome: Extend the standard transaction via BADI.  
• Rationale: The functionality augmentation is required by the business and cannot be separated from the main functionality. The effort, future support costs and TCO associated with building an entirely custom app for a 10% functionality deficit does not justify a side-by-side approach. The approach was therefore to use the ‘classic BADI’ in conjunction with modern ABAP authoring practices. 

Example Scenario 2:

Requirements drive a need to enhance a standard Fiori App and the intention is to user Key User Extensibility. The business context exists and there is a whitelisted BADI available to implement the business logic. However, with the Key User Syntax direct table reads are not permitted and although there is a CDS view available to access the data required to execute the business logic, it has not yet been whitelisted.

• Programme Outcome: Use Key User Extension to add the custom field to the standard Fiori UI. Leverage the whitelisted BADI but create the implementation in the back end (rather than via the Key User Apps). This will allow usage of a standard ABAP syntax and therefore enable use the non-whitelisted CDS view to execute the business logic.     
• Rationale: Short of replicating the data to BTP, executing the logic there then leveraging a service to write back to the custom field, ‘clean core’ options are currently limited. This development therefore leverages ‘Clean Core’ methods where available supplemented by more traditional techniques only where necessary.

Example Scenario 3:

When a Maintenance Order is saved, custom logic must be executed within the same LUW to derive a series of attributes that are subsequently leveraged downstream to drive automated procurement activities including approver determination in a Purchase Requisition workflow. All the data required to execute the logic resides in S/4HANA standard tables and custom business rules using condition-based logic are required to help derive the values. There is currently no whitelisted enhancement spot (BADI or other) in which to implement the logic. 

• Programme Outcome: Use a non-whitelisted or Classic BADI whilst leveraging principles of RAP (i.e., clear separation of concerns between data access, business logic, and presentation layers) to manage the logic and update operations. Leverage BRF+ decision records within the business logic to manage condition-based business rules and derive the required attributes.
• Rationale: The enhancement is required On-Stack, to be executed in the same LUW. The business logic even relies upon attributes imported into the BADI structures to determine the course of action. Object locking also prohibits calling an externally hosted service to make the updates. In this instance the classic BADI extension is the best approach available.

The above is not intended to be a decision tree on development guidelines but simply highlight that clean core is not always the right approach and a myriad of factors must be assessed not just from a technical standpoint but also a programme delivery perspective. With infinite time and budget, we can find ways to work around the most efficient technical approach but it is critical to challenge whether the pursuance of clean core is worth elongated timelines and, in some cases, significantly increased TCO.  

Further to the above, it is also important to note that many functionality gaps or feature improvements available today contain resolutions in SAP notes that prescribe BADI or custom enhancement spot implementations, which may not yet be available on the Extensibility Registry and by proxy demonstrate an acknowledgement that On-Stack, classic enhancement techniques are sometimes the most appropriate or even only path available.

These extension methods can be managed safely and providing they are implemented correctly by an experienced developer they are often the most appropriate means to extend the S/4HANA solution. See below examples:

• Robust BADI enhancement spots are still a highly effective way to manage development in S/4 especially where tight coupling to the business process is needed and where the whitelisted, public alternative is not available.
• This also extends to AMDP BADIs recognising certain functions require augmentation of database procedures and action at the database level. PPH_SUPPLY_DEMAND_LIST for MRP Live is a common use case and SAP provided extension point.
• Building custom triggers for interfaces or output generation. For example, many SOAP based Enterprise Services exist in S/4 but the required trigger may not exist or may not meet business requirements. For certain, more niche components like Joint Venture Accounting, the required output generation triggers are not available across all processes that drive a partner destined output. Custom triggers can still be built in ABAP whether leveraging an event or scheduled program. Again, leveraging RAP principles in conjunction with the classic extension points can be assessed as an option.   
• BOR (Business Object Repository) and Class Events, accessible via SWO1, still provide strong event-based triggers and allow for custom modules and entirely custom programs to be called and executed where extensive custom logic is needed. They can also be called to trigger integrations that leverage event mesh as an example.
• Newer products such as Field Logistics for Upstream Oil & Gas rely heavily on the implementation of custom BADIs where business specific logic is often needed. With On Premise / Private cloud following a different code base to that of public cloud it is safe to assume not all extension objects will be whitelisted.
• Similarly, such newer products introduce new Fiori Apps for which a fallback GUI alternative would not exist. Adherent to Fiori design principles in being more role based and simple in their design, they can occasionally lack the breadth of required functionality for larger, more complex organisations. Where Key User Extensibility is not sufficient or the business context is not available, adaptation projects may be the most suitable approach.
• Many IMG nodes provide BADI enhancement spots to meet specific customer requirements that are not yet part of the publicly listed repository.

There is no denying that Side-by-side (including CAP on Cloud Foundry or other frameworks & runtimes on other platforms), On Stack (in the form of RAP Developer Extensibility & Key User), and Classic, all have an integral part to play in the overall delivery and development of solutions for S/4HANA, however each business requirement resulting in extension, needs to be assessed on a case-by-case basis to determine which of the above is best fit. Cost, complexity, available skillsets, and timelines also need to be assessed as part of the overall decision in terms of which option to take forward. It is also important to remember that RAP in the ABAP Cloud environment is not as flexible as the traditional ABAP Syntax (hence its origin and ideal to a SaaS / Public Cloud Model). CAP, although highly flexible may be overkill or even not a best fit for certain extensions that required tighter coupling to the process or LUW. This is by no means saying that CAP and RAP do not have a place, they are in fact critical for future state technical architectures, however Classic is also a critical component for now. For large, complex organisations it is therefore often not a question of if we use Classic but simply where and how we use Classic safely or smartly driving a “Smart Core”. 

How do we make the classic methods safer?

Firstly, when defining an extension decision tree as part of your development strategy, clean core methods should absolutely be assessed first. If those do not fit, move into the realms of “Smart Core” where there are techniques that can be deployed to ensure the integrity of your S/4HANA system, support upgradeability and ensure performance. “Smart Core” refers to the use of certain classic techniques like non-whitelisted BADIs, enhancement spots and decoupled ABAP programs but with emphasis on the below points.

• Don’t try to reverse engineer standard SAP logic. This sounds obvious but you would be surprised to see how often businesses have done this. Use standard objects to perform your calculations whether it’s adding working days, reading factory calendars, or performing CRUD operations like generating or updating transaction or master data objects. Robust BAPIs and new RAP services exist to perform all these activities and many more so use them.
• Leverage CDS where you can, to help keep developments performant through leveraging benefits such as code pushdown.
• Use configurable parameters to control your objects. BRF+ is still a great means to manage this and the SAP transition from NACE to OPD also supports this mechanism.
• Adopt an Enhancement Switch Framework allowing you to easily activate and deactivate your custom developments especially those leveraging classic enhancement spots. A switch helps to transition away from the development when a newer, cleaner alternative emerges. It also provides a configurable means for the business to deactivate a development as functional solution changes are released.
• Run ATC cloud readiness checks on ABAP transports to consider suggestions raised by the checks. (It is not mandatory to follow but may provide good guidance or areas to explore).
• Where available, adopt whitelisted objects from Extensibility Registry. Note: You will need to check the availability for your system and relevance for your enhancement type e.g. logic or structural.   
• Always look at the component parts of your development for example with an Extension Activity Diagram so that you have a clear understanding of your Extension Styles and Extension Tasks. (See SAP Extension Methodology for more detail). It is likely that although Classic could be the predominant approach to meeting a requirement, elements of Key User or RAP can also be incorporated into the overall approach (per the example above in Scenario 2).

Note: Under no circumstance does “Smart Core” support direct modification to any standard SAP program.

Summary

Extension to your S/4HANA ERP can be a bit of minefield but an understanding of your options along with their strengths and pitfalls, a clear view of your overarching program objectives and a pragmatic approach to extension as defined in your Development Strategy, will aid in delivering the best possible outcome. The pursuit of an agile, composable, cloud ready ERP is an important one and the way we extend standard functionality plays an important part in this. It is, however, important to recognise that ‘clean core’ in its purest form does not yet have the maturity required by all organisations embarking on the transformation journeys and leveraging certain ‘Classic’ techniques with a “Smart” overlay is an important flavour. In summary:

• Adoption of certain Classic techniques does not have to be in conflict with cloud readiness or cloud adoption. Using a ‘Smart’ approach to implementing these classic extensions is integral to supporting ERP longevity and upgradability. Done right you are less likely to see SPAU / SPDD issues when it comes to upgrading your S/4HANA system.
• Cost complexity and longer term TCO is an important consideration when determining how best to extend. For example, a custom application deployed to Cloud Foundry adheres to clean core but the long-term support and maintenance cost when assessed against other extension approaches (even Classic) may make it less palatable.
• Build with an eye on the future. Technology continues to advance at rapid pace and the techniques we adopt today can become quickly outdated. You don’t have to predict the future, but you must look to how you build in a way that provides agility and does not lock the organisation into the additional functionality you have provided.