When it comes time to migrate to SAP S/4HANA, you’ll probably find yourself with custom code that will need to be considered.
With SAP Solution Manager 7.2, you’ll find yourself with a few different tools for managing this custom code. This blog presents two such tools.
The Decommissioning Cockpit
The majority of custom code created during a project will remain in an SAP S/4HANA system, even if it is not used currently or will not be used in the future. In order to get rid of unused or obsolete custom code, a well-defined decommissioning strategy must be in place.
To define a decommissioning strategy, you need an overview of existing custom code objects, including how each object in your system landscape is used, based on efficient custom code management.
Why Bother Decommissioning Custom Code?
Many SAP customers adhere to the slogan, “Never touch a running system.” On the one hand, that might be sensible; on the other hand, unused or obsolete custom code objects add to the maintenance costs of a system by possibly being affected by system change events—such as moving to SAP S/4HANA. In addition, unused objects can increase the security exposure of an SAP system by becoming unmanaged and unmonitored portals for malicious attacks.
Unused custom code has a big impact on your system, includes high risks, and adds significantly to your bill—for example, by increasing complexity and building roadblocks on the way to a more simplified landscape or a new technology landscape, such as SAP S/4HANA.
The recommendation should be to turn away from “Never touch a running system”; instead, follow the lean management of custom code and the guiding principle, “Don’t invest in waste.”
The goal of decommissioning is to identify custom code objects that you need to eliminate from the system. The process follows the four steps shown below.
The four main characteristics of an object that identify it as a candidate for decommissioning are as follows:
- Not used during a defined time period
- Similar or even identical to an existing SAP object
- Created a long time ago but not active in any productive system
- Obsolete because of existing standard functionality
Custom Code Lifecycle Management (CCLM) supports these four phases of the decommissioning process with its Decommissioning Cockpit (next figure). To use the cockpit, set up CCLM for the complete system landscape in which the decommissioning process will be implemented.
In order to evaluate usage data directly from your managed system, make sure that both workload statistics and UPL or SCMON data is available for your system.
The Decommissioning Cockpit is an integrated part of the CCLM work center. It allows you to analyze your custom code objects based on specific information, such as usage or similarity, in order to identify the right objects for decommissioning. Additional information about the identified objects helps you make the right decision—to delete or keep the object.
During the decommissioning process, the system monitors the usage of all analyzed objects and alerts you if an object has been used during this process. The system defines a lifecycle status for each object to help you through the decommissioning process.
Every decommissioning project needs clear governance and a clear strategy. Decommissioning is not a one-time project supported by different tools; it must be embedded in a complete governance project for Custom Code Management.
This is only possible if the supporting tools are well integrated in this governance model. If this is not the case, it will be very difficult to keep the custom code city “green” and “clean”, by reducing the technical depth by decreasing the amount of obsolete or unused code.
Dashboard and reporting capabilities as well as statistics are part of CCLM, as shown below, and they complete the Decommissioning Cockpit.
The Quality Cockpit
The majority of custom code analysis reports a high number of errors and deviations from quality standards. Experience shows that more than 60% of custom code objects contain code quality issues; perhaps quality guidelines and reviews were not implemented, developers were inexperienced, or there simply was not enough time.
This leads to high maintenance costs, which in turn cause high operating costs. In addition, custom code of poor quality can also increase business risk and system downtime and can act as an impediment to future innovations.
To improve the quality of software code, a well-defined quality strategy has to be in place. To define a quality strategy, it is necessary to achieve transparency for the existing custom code objects, especially for the quality of each object in your system landscape, based on efficient custom code management.
Why Check for Code Quality?
In order to benefit from the advantages of SAP S/4HANA, you must migrate your current custom code to be compliant with SAP S/4HANA. During this migration, you can encounter the following issues:
- Certain existing custom code will not work correctly in an SAP S/4HANA environment; you need to analyze and rewrite it accordingly.
- Certain existing custom code will run slower in an SAP S/4HANA environment compared to its performance in the previous database. You need to analyze and rewrite these portions of custom code as well.
To avoid such issues after migration to an SAP S/4HANA system, it is recommended that you analyze and fix your custom code proactively—before the migration takes place.
In order to achieve smooth migration of your custom code, choose a project-based approach. A successful quality management project is divided into four main steps:
- Analyze your systems to obtain as is quality information.
- Consolidate the results of the different checks.
- Adjust the code according to your check results.
- Monitor the progress of software quality improvements for relevant objects.
You can execute quality management as a one-time project with a defined end for a specific use case, but in general, it should be a recurring initiative.
Code Quality Toolset
The main tools that support the process phase are the ABAP Test Cockpit (ATC) running in the managed system, and the new Quality Cockpit integrated into CCLM in SAP Solution Manager 7.2.
The ATC is an ABAP check toolset that allows you to run static checks and unit tests for your ABAP development objects. The ATC provides specific checks that verify the compatibility of the coding with SAP S/4HANA.
The consolidation of the ATC results takes place in a central SAP Solution Manager system, using CCLM and the fully integrated Quality Cockpit.
SAP Solution Manager can extract the ATC results via the extractor framework into the SAP BW system connected to SAP Solution Manager. From there, CCLM can collect the information to make it visible in one central view (see below).
This comprehensive overview allows you to monitor code adjustments and the success of each quality project in one place. In addition to and based on the defined ATC checks, a quick time estimation is available to help you to plan your project. Analytical capabilities are also available to report on your success.
As you can see, it is imperative to have a solid custom code management strategy, especially when it comes to migrating to SAP S/4HANA. Working to remove unnecessary code and ensuring the quality of remaining code are two major initiatives that should be undertaken.
With SAP Solution Manager 7.2, custom code management is easily achievable. And whether you’re thinking about a cloud, on-premise migration, or hybrid approach to your SAP S/4HANA system, by using the tools outlined above you should be able to have the peace of mind that your migration starts off on a solid foundation.
Editor’s note: This post has been adapted from a section of the book SAP Solution Manager for SAP S/4HANA: Managing Your Digital Business by Marc O. Schäfer and Matthias Melich.