Introduction
The world today witnesses a massive digital transformation, impacting organizations globally through fast-evolving business models. Likewise at SAP, key products and solutions are advancing with all the more flexibility and robustness. To enable this agility within the foundations of ERP, has repositioned its flagship product offering to a new ‘digital-core’ in the form of S/4HANA. With the recent S/4HANA releases also on Cloud, the new digital core offers a fascinating array of new innovations, ranging across digital-age User Experiences, next-gen Business Processes and Embedded Intelligence, through seamless integration and automation options.
Numerous existing customers however, are still on the former SAP ERP (ECC or older) systems with many of them also engaging industry specific components to support their businesses. With SAP’s future plans of withdrawing support and maintenance for its legacy ERP software versions, customers are required to devise an upgrade strategy to move to S/4HANA solutions, mostly through Brownfield implementation projects. In the process, project teams typically deal with several technical hiccups in managing custom code, around aspects like complexity, dependency with 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 and modern ‘Clean Core’ SAP solution.
Custom Code Perspective
It is common knowledge that ERP implementations require customizations for various business motives and majority of customers rely on their custom code considerably. Most of them are established firms using SAP ERP for decades, and have continuously enhanced or modified the standard software through custom ABAP coding. As per recent market research conducted by reputed SAP user groups (ASUG 2021), over 90% 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 create several 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. Notably, over 60% of customers see custom code management as barriers while upgrading to new SAP releases. Needless to say, high costs are associated in managing this, consuming IT budgets substantially. 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 functionalities, improved performance, and innovative technology features. Amidst all of this, existing customers need to be well-aware and equipped to embrace the new-age offerings. Things like classical extension methodologies, especially core modifications often get in the way of smooth software upgrades or conversions, eating up extensive maintenance efforts. 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 and better adoption of new innovations, along with reduced TCO.
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, through various subsequent conferences and events, SAP has been strongly 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, let’s understand the guiding principles from SAP in this regard –
◉ 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 options: Realize the full potential of approved extensibility options in the combination that best suits business needs.
◉ Upgrade-stability: usage of upgrade-stable standard objects and 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 recurrently to make necessary changes, as feasible.
The guidance provided by SAP can be implemented through various means, which however requires an in-depth analysis of the legacy application attributes and their relevance to the modern alternatives available.
Common realization challenges
Although ‘Clean-Core’ has been a buzz-word for a good few years now, customer implementation teams do struggle to understand and fully adopt the guidelines due to some noticeable 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 on the latest offerings and their applications in driving digital transformation.
◉ Customer implementations existing for decades, have custom codes authored by various users for different purposes over different periods of time. This has resulted in unmonitored growth in the number of custom objects across the systems.
◉ Traditional SAP implementations often have applications that are multi-functional and high on complexity, which are hard to decode or reverse-engineer. Some of them still contain primitive ABAP coding patterns and are difficult to be refactored. These lead to considerable technical debts arising from custom code.
◉ 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 hurdles and nuances, together with the recommendations and utilities 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, however these are NOT recommended and should 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 suggests adoption of standard business process solutions offered through the latest SAP product releases (mainly S/4HANA). Industry best practices are applied to create a self-reliant solution for customers to operate effectively using SAP’s standard offerings, which is also emphasized in frameworks 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 necessities. 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 difficulties, 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 re-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. Considering a moderate need for analysis owing to existing utilities like ABAP Call Monitor (SCMON), it’s a must-do activity for project teams. This helps get to the candidates that have no-usage in production, and can be considered for decommissioning accordingly. 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 – 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 into 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.
Compare, Consolidate and Modernize
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 Extension Modes
◉ Adding Custom fields at an Application, CDS or Business Object level, catering to most of the standard DDIC extension scenarios such as custom appends.
◉ Adding Custom Business Logic through a set of SAP released BAdis from defined Business Contexts, where customers or partners can write business logic through a cloud-compliant
(restricted) syntax support.
◉ Adapting UI (FIORI) (as key-users) being able to add, move, hide, filter fields, rename labels or regroup fields on the standard application UI.
◉ Create Custom Business Objects (CBO) and its related data-model (custom tables), alongside multiple sub-nodes to the given Business Object. This can also be modelled into its corresponding OData service and exposed as a maintenance UI.
◉ Exposing Custom Data – by creating own custom CDS views, based on standard and released CDS views which be enabled as external APIs for external data consumption
◉ Adding Custom Analytics with ability to build analytical queries based out of custom CDS views. This is typically built based on SAP released analytical data sources (cube CDS views).
◉ Managing KPIs and Reports, that allows adapting SAP delivered KPIs and reports by adjusting them to business needs including with app navigation capabilities
◉ Custom forms or E-mail templates allows customizing printed Forms (using Adobe LiveCycle Designer) 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 software, may not always be a customer’s viewpoint, and there will certainly arise the need for distinctive and innovative business solutions to gain competitive edge, while also catering to the clean-core protocols. This demand can be addressed by implementing side-by-side scenarios – 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 interfaces. While the previous mode was more applicable for enhancements to standard 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. Generally custom applications can be tagged as side-by-side candidates upon satisfying these coupling conditions. These candidates should be loosely-coupled and lifecycle-stable, which means the core application can be updated without any obligatory adaptations. In addition, they also must have approved (white-listed) APIs available to cover the underlying data operations.
Side-by-side Extensibility scenario on SAP BTP
The 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 (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, Diversify, Be 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 (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 maintain documentation on 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.
No comments:
Post a Comment