Need to manage custom code for your S/4HANA migration…or just in general? This blog describes two of SolMan 7.2’s tools for decommissioning code and monitoring code quality.
1 Decommissioning Cockpit
The majority of custom code created during a project remains in the 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.
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 a 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.
1. Not used during a defined time period
2. Similar or even identical to an existing SAP object
3. Created a long time ago but not active in any productive system
4. 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.
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 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.
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, we recommend 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:
1. Analyze your systems to obtain as is quality information.
2. Consolidate the results of the different checks.
3. Adjust the code according to your check results.
4. 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.
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.