055: Clean Core Measurement

Table of contents

• Introduction
• Measurement
• CCM Project
• Demo
• Summary

In this episode, we'll be looking at Clean Core Measurement. First, why we should measure at all, and second, the open-source project we'll be examining in detail. We'll start with a brief introduction to Clean Core, then look at the measurement process itself, and then move on to the CCM project. Finally, we'll give a short overview of the software itself, including a brief in-depth look. At the end, we'll summarize everything.

 

Introduction

It all starts with an S/4HANA project. We want to migrate our old ECC system to S/4HANA. We have three different options available for this: Brownfield, Bluefield, and Greenfield. With Brownfield, we take our current system, perform a HANA upgrade, and initially make no changes. All code, technical debt, etc., remain in the system. With a Bluefield migration, we set up a new system and then selectively transfer processes and components. This allows us to determine when we no longer need certain things and to remove inactive components directly. Generally, however, we don't make any major software modifications and, in most cases, transfer the existing system. With a Greenfield migration, we build everything from scratch. We rethink our existing processes and reimplement extensions. In this case, we do not transfer any legacy components from the old system. The advantage of a greenfield migration is that we can completely rethink the process and don't have to cling to the old, existing things.

Meanwhile, and afterwards, we should then focus on Clean Core, because we have a new S/4HANA system and actually want to either become Clean Core or implement Clean Core from the very beginning. This is a strategy for an S/4HANA system. We primarily want to rely on and use SAP's released APIs. We want far fewer modifications to the system, ideally using as many standard processes as necessary. For example, we have on-stack extensibility with ABAP Cloud available to still be able to implement custom developments on the system, which would then also be Clean Core. But this ultimately raises a question: What if we want to become Clean Core?

 

Measurement

This is where the issue of measurability comes to the fore, because nothing is worse than not knowing how clean we actually are. What we want to achieve is to move from a feeling to knowledge. To know how far we are from Clean Core and where we still have things we need to clean up. Various tools are available for this. For example, you could start by creating an architecture board with your internal architects and discussing which extensions are really necessary, where we can use the standard, and why we deviate from the standard. So we always ask ourselves, "Is there a better way?" before we start extending the system and thus accumulate unnecessary technical debt. The second point is activating the ABAP Test Cockpit, and specifically the Clean Core Checks. These provide us with important information if we violate Clean Core rules. We can, for example, centrally request these exceptions with a justification for the violation. The ATC can also be configured to completely block violations of the Clean Core. In this case, the exception process helps if data needs to be transported anyway. Finally, we should start measuring our system. Because only by measuring can we accurately determine: How good are we already and where do we still need to make improvements? And perhaps document things where we can't do anything at all, for example, because the necessary SAP APIs weren't provided in a standard module.

SAP provides the RISE with SAP Methodology dashboards as standard. We can import our ATC results there and receive various key performance indicators from the areas of extensibility, data, and integration. Here we also receive technical information on the technical debt score, the rate of business modifications in the system, and which different objects we have already accumulated at the various levels. We also receive an inventory showing which objects have the highest technical debt, the overall level of the objects, and further information on the various error messages, which we can then begin to correct, for example, to remove all Level D objects from the system. As the dashboard's name suggests, it is only available to RISE customers. This means that a large portion of customers are still excluded from these standard features. Furthermore, relevant aspects such as object documentation and the assignment of objects to the responsible products and teams are still missing.

Next, we have Project Kernseife. This is an open-source project run by two SAP employees and other community members. It allows you to define your own APIs, which is particularly important in modules with few or no standard SAP APIs. These APIs can be centrally documented and then checked against a custom Clean Core Check, thus reducing false positives during the ATC. The project is available in CAP for maintenance purposes. The check for the ABAP Test Cockpit, however, is a separate check and not compatible with Clean Core. Therefore, it cannot be used, for example, in a Central ATC scenario.

 

CCM Project

And this is where the CCM project, which we launched, comes into play. The idea is relatively simple: We want to get a quick overview of all our systems with real KPIs that show how Clean Core we actually are. We want to link the results with the documentation, further notes, teams, and products to get an overview of where the technical debt actually lies. The goal is to eliminate manual tasks and automate everything so we only need to monitor the results. Therefore, we had several requirements for the project, including how and where to build it. The components should be located very close to the Central ATC. For example, we want to reuse the central configuration as well as the results from the runs. We want to establish a flexible configuration to operate it as a reusable, open-source project. And we want to provide the ability to generate our own KPIs to accurately assess our company's Clean Core status, even if we're not yet 100% Clean Core when looking at the actual figures.

The output should be as simple as possible. To achieve this, we divide the different levels into the stack: Level A is at the top, Level D is at the bottom. And we define the key performance indicators for ourselves: For example, Level A means that this is the proportion of Cloud Ready objects, and Levels A and B together form the Upgrade Stable part, which keeps our system stable. The lower part, Level D, contains the "Not Allowed" objects, which we actually don't want anymore, but still report. We completely exclude Level C from our KPIs, because Level C is currently only Conditional Clean Core. This means that in the next release change, the objects could become Level B or even Level D. They are also not upgrade-stable, as we would always have to test these objects in an emergency because SAP can make changes here. Directly below the different levels, we then display our system ID and output the two KPIs for Cloud Ready and Upgrade Stable or Clean Core. With this, we have measured the system. And when we compare the different systems side by side, we quickly gain an overview of our system landscape and the various KPIs.

How is the Technical Debt Score actually calculated? For this, we run an ABAP Test Cockpit using the Clean Core variant and then receive the various messages for each object in different classifications. We then assign a weight to these messages. The weight can be dynamically configured in our project. For example, an error message receives a weight of 10, a warning a 5, and an information message a 1, so that it remains visible. If we then have three error messages for an object, that's 30 points, ten warnings 50 points, and three information messages 3 points. Thus, the overall object receives a Technical Debt Score of 83. Looking at the classification of the overall object, we derive this from the highest message class. This means, conversely, that if we have at least one error message, the object is marked as Level D.

As is typical in any project, there were complications and problems during implementation. Since we are on the Central ATC in the ABAP Environment, we can only develop our objects here using ABAP Cloud. This is partly due to missing APIs or missing information, which makes complete automation impossible at this time. For example, we cannot schedule central ATC runs to perform the clean core checks on the respective systems. The user then has to do this manually as an application job in the system and ultimately execute our job so we can compile the results. Similarly, texts for ATC checks and ATC messages that we can freely read are currently missing. Therefore, we have to populate our customizing tables with these texts ourselves to obtain a clean output within the user interface. Regarding deployment, there are currently differences depending on the abapGit version used. In the ABAP environment, we work with the abapGit plugin in Eclipse. This currently makes it impossible to synchronize, for example, the Fiori artifacts, i.e., the BSP applications, with abapGit. This means that in the end we have all the ABAP artifacts, the Business Catalog, the IAM app, the Launchpad App Descriptor Item, basically everything that's relevant for Fiori, but the BSP applications are missing. Whoever installs the project has to manually deploy all 13 applications to the system again, which makes the installation somewhat more complicated. Overall, the project has a relatively complex setup with a very large number of steps for the various configurations and communication arrangements that need to be maintained. Here, however, we have developed a solution: a small setup application that guides the user through the setup step by step and provides information about what has already been configured and where information is still missing.

 

Demo

Let's take a look at the system in a short demo. In the info card, you'll find another video where we examined the various apps in terms of their significance and accuracy. Today, we want to look at some new features that were added with the latest release. First, let's navigate to the System Overview. This corresponds to the previously mentioned "at a glance" overview for all systems. In the filter bar, you can specify which view you want to see: the standard calculation method or the custom method. You can also view the changes since the last run on the maps. You can then jump to the detailed view via the various items. In the detailed view, we see the Technical Debt Score, the various KPIs, and also the change since the last run. For the cloud objects, we see all Level A objects and the key user objects from the system, and in the area of the other levels, we see Levels B, C, and D, also with their changes. At the bottom, you will find a trend chart that shows the progression and the change across the various measurements. The system generally allows measurements weekly or monthly.

Also new is the setup app, designed to simplify the entire setup process. The various technical steps are thus accompanied by instructions, but also by checks, so you can see at a glance whether any configurations are missing or if certain things haven't been created in the system. For example, we can click "Check" in the settings and receive a message that not all current settings have been created yet. Using "Execute," we can then easily trigger the creation and subsequently receive a green result: The settings have been entered into the system. The setup is primarily intended to help with the initial setup, but also to quickly show any inconsistencies within the configuration later on.

Let's take a brief look at the ABAP architecture. We use a software component for the entire project, which we created in the system. Under the software component, you'll find our standard structure with apps, Fiori, interfaces, test objects, reuse objects, and share objects, if any. Looking at the application, you'll find all the necessary apps belonging to the project. These aren't always just applications; they can also include application jobs or business configurations. Each artifact has its own package to better distinguish and cluster the objects. In the Fiori section, you'll find all the Fiori configurations, such as the Business Catalog, Pages, and Spaces, that we've created for the project and deliver by default. You'll also find the IAM apps and our BSP applications, the deployed artifacts. As mentioned before, you'll need to install these before they're available in the system. In the Interface section, you'll find the service that calls a function module in the on-premises system. The function module returns a result for the ABAP cloud objects and key user objects present in the system, both to obtain a count and to calculate the quotas. In the reuse package, we then find all objects for reuse. However, this package also contains many interfaces to standard SAP APIs, such as business roles or the ABAP Test Cockpit. Therefore, we separate the functions again into their own classes and keep them out of our source code.

Let's then look at the various features that are already complete: We have a dashboard with different system overviews. We can assign documentation and also create clusters. We gain insight into objects, used APIs, checks, and the various clusters, and we can manage our own APIs. A simple setup is now possible via the setup app, and there are already jobs to load the data and, for example, perform auto-approval. Open issues still include the various roles that need to be created, as well as custom APIs. We are also incorporating the exemptions, documentation, and the various APIs we have to determine the true metric. The trend chart has already been corrected and is now available in the application. Likewise, additional categories for clusters should be added to allow for better filtering.

 

Summary

Let's summarize the various points again: Basically, you should start this process when moving towards S/4HANA to achieve standardization and a clean core. This is especially important considering that current AI features and future features are primarily based on standard processes. It helps to have an architecture board at the beginning that looks at the extensions you want to implement, evaluates them, and then approves and documents them accordingly. Secondly, you should activate the ABAP Test Cockpit. It not only shows you the results of the measurement process, but also shows your developers what they are actually developing. And if he violates Clean Core, he will be automatically blocked and will then have to justify why he wants this implementation in that way. As a third point, you should address the topic of metrics. Metrics help visualize how far a system has come, how much technical debt remains, and where this technical debt is located. Furthermore, it can help to spark a friendly competition among developers to see who has the least technical debt or who reduces the most technical debt per month. Essentially, metrics show you in reality whether the system is truly improving or whether with each release the findings are simply increasing and Clean Core is becoming a distant prospect.

Finally, you will find the two QR codes on this slide: one to download the current presentation and one to get further information about the project and the GitHub repository. On the other side, you'll find a QR code to connect with us on LinkedIn if you have any further questions about the project or would like to exchange information in another way. I'd like to thank you in advance for watching, and see you next time.

 

YouTube
Video