CCM - Calculate Key Figures

Table of contents

• Introduction
• Basis
• Calculation
• Settings
• Method
• Deviation
• Result
• Object List
• Object
• Processing
• GitHub
• Conclusion

In this article, we'll look at how the KPI for the Clean Core Dashboard are calculated, provide some examples, and examine possible deviations in detail.

 

Introduction

The standard dashboard (RISE Methodology) and the Project Kernseife already provide various calculation methods for the different KPIs. The goal is to derive a Technical Debt Score from the messages for an object, which describes how much technical debt is associated with that object. This will make it easier to identify changes in the system that are not based on the object itself, but rather minor changes within the code. Tracking only a single object is therefore relatively imprecise because even small changes in the APIs used within the object, while not changing the object's classification, can still reduce the Technical Debt Score, indicating that something is happening within the system. We use the same calculation method ourselves.

 

Basis

The basis for the calculation is therefore the ABAP Test Cockpit (ATC) check: ABAP_CLEAN_CORE_READINESS. This check validates all customer-specific objects and searches for corresponding APIs that are being used or statements that should no longer be used, classifying them into different grades such as Classic APIs, Internal APIs, or APIs that should no longer be used. The result is a large collection of messages that can then be bundled and classified to calculate a result and classify objects.

 

Calculation

So how is a key figure created from the various messages, and how is an object classified? Let's look at the details in this chapter.

 

Settings

We rely on a so-called weighting and follow the example of the Project Kernseife, which already provides reference suggestions for classifying the different levels. We start with levels B to D, which we still need to calculate accordingly to determine a key figure. Level B is already Clean Core, but not yet Cloud-Ready. Therefore, it receives an additional point, for example, so that it remains visible but doesn't have too great an impact. Level C receives 3 points, and the most severe level, a Level D finding, receives 10 points. You can configure the various classification settings via the Business Configuration and adjust the numbers as needed. However, you can also generally stick to the default weighting.

 

Method

Now we count the different messages we received for an object, calculate a count, and multiply this by the corresponding points for the error classification. This ultimately results in the Technical Debt Score, the technical debt of the object within the system. The object's classification is primarily determined by the highest message class associated with that object.

Let's look at the following example: we have, for instance, 10 warning messages and one error message, resulting in a total Technical Debt Score of 60. The object is classified as Level D overall. This is evident from the error message, even if there is only one.

 

Let's look at a second object. This object has a higher overall Technical Debt Score than our first object, namely 75, but is only classified as Level B overall. This is because we only have 75 informational messages, but no warnings and no errors.

 

Deviation

However, where might such a calculation diverge in the future? There are various reasons for calculating metrics or evaluating findings differently. Currently, there are processes in place, such as the exemption process in the ABAP Test Cockpit, to request exemptions for findings, potentially approve them permanently, and factor them into the calculation. Furthermore, documentation may be required when we implement applications using APIs that are not officially released for standard use but are nonetheless relevant to our processes. A third scenario involves working in a module that lacks released APIs but contains specific APIs we wish to document and use without having them trigger findings in our metric. To accommodate such deviations, the project will introduce additional metrics that can be calculated alongside the standard metric to reflect the system's current status.

 

Result

What about the visualization within the framework? Here we looked at two different examples: first, the object list, which gives us an entry point into the system, and second, the details within the object, which define the classification.

 

Object List

Upon entry, the object list is primarily sorted by the Technical Debt Score. This means that objects with the highest technical debt are at the top, and the least indebted objects are at the bottom. Basically, all object providers, i.e., the different systems, are mixed here. You can use the filter settings to, for example, look at a specific system. At the same time, you will find all object classifications, for example, in this case, Level C for the first object, which has the highest technical debt. Here you can use further filters to determine whether you only want to address Level D objects initially.

 

Object

Let's delve a little deeper into the details, moving from the object list to the individual object. Here you'll find information about the number of different messages generated for an object, as well as the object's classification. Below that, you'll find a list of all messages associated with this object. From this, you can deduce whether there are certain to-dos or which APIs, for example, are used most frequently. These are displayed as reference objects after the message. However, this depends on the message, as not every message refers to a reference object.

 

Processing

There are now various reference scenarios for processing, which you can use depending on the situation. For example, you could start by processing the objects with the highest Technical Debt Score in the system. Here, however, you would iteratively revise individual objects. The second option is to first address all Level D objects and, above all, remove the Level D findings from the system. This is the best practice for handling the findings and for quickly achieving a clean core. Another relatively simple option is to edit all findings where successor objects already exist. For example, you can use the app for the various checks to see how many objects in a system already have a successor object, and then replace them relatively easily and usually with little testing effort. Finding the appropriate API is simple here, but a large number of objects are modified simultaneously.

 

GitHub

Here you can find the open-source project and further information on GitHub. Further information on installing and using the project can be found in the project and the linked resources.

 

Conclusion

Calculating the various metrics within the Clean-Core Dashboard is relatively easy to implement, and it's easy to understand how the metrics are composed and how the classification is generated. These various metrics are intended to provide the opportunity to take action, adjust objects, and also to have an overview of the technical debt in the system. This way, you can deduce how the technical debt within the system has changed each month by performing regular measurements.

 

Further information:
YouTube - CCM Preview