050: Clean Core Measurement (Preview)

Table of contents

• Overview
• Dashboard
• Administration
• Process
• Reporting
• Outlook

Measurability of Clean Core and getting started with Clean Core Extensibility are crucial for ensuring governance and enabling clean system development. Therefore, in this episode, we'll take a look at the Clean Core Measurement project, which is available as open source and provides numerous applications for analysis.

 

Overview

Once the project is properly installed in the system and all applications are available, you'll have a dedicated space for each application. This space is structured according to different priorities and the use of the Clean Core Dashboard. The reporting section is located at the top: This primarily contains visual applications designed to provide insights into the data from the various systems. In the middle section, you'll find the process part: This is where quality assurance, documentation, and various assignments typically work to display further information. The lower section contains the administration: This is an application for managing the various processes. Further administrative configurations are located in the Business Configuration and are not included as separate tiles.

 

Dashboard

Let's first take a look at the dashboard, the heart of the entire open-source project, which enables visualization. Immediately after logging in, we see a list of all possible objects or systems connected to the dashboard. In this case, we see three system landscapes. In the front section, we find the various KPIs belonging to the systems, such as the current Cloud Ready status or Upgrade Stable status, along with the Technical Debt Score, by which the systems are sorted. Then we find a quick overview of all levels and how the various objects are distributed across them.

Navigating to the details of a system reveals an overview of the same metrics as before, plus various change indicators that show how the status has changed since the last measurement. This gives you an overview of the direction in which your system is developing. Additionally, you'll find key figures such as the key user extensibility objects available in the system, as key user extensibility is an important component of the cloud-ready strategy. At the bottom, you'll find a trend chart, which is currently under development and does not yet represent the final status. It's intended to show how the trend has changed over time in the various layers.

Clicking on a system in the overview takes you to the detailed view, where you can examine the different objects within that system. Since this is test data, it is not yet consistent. Therefore, you'll see fewer objects here than displayed in the statistics. We will take another look at the object view at a later time.

 

Administration

Let's take a first look at the administration and examine the saved runs. These are grouped according to the different time periods in which they were executed and the systems available within them. Navigating into a run, we see general information about the run and the various scores that were calculated. Currently, the system only supports the standard score. This is the system's actual score without including any custom settings such as custom APIs, exception processes, and documentation. This second score is still under development, so we only see the standard score here. In principle, it is possible to define different score types, which might be possible in a later version, but is not currently planned.

 

Process

Going to the Process section, we have various options for mapping processes from our own company. The first tile therefore contains the documentation. Documentation consists of elements that we can document, assign corresponding IDs to, and ultimately assign objects to. In the details, you will find information such as a short description; this describes the project or its implementation in brief. We also have detailed information available with a rich text editor. Here we have all the options to formulate longer texts and descriptions to better document the project and its scope, or to include links to external documents. Basically, we can also define whether there should be a custom score for all defined objects. For example, we could define that we absolutely need this development and thus reduce the score, since we are not using clean code here, but are taking the risk because we absolutely need this process. In the lower section, you will find the linked objects that belong to this development. Here it is possible to define individual objects or packages.

Next to this is the application for the cluster. In a cluster, we essentially describe whether it's, for example, a product, a team, or individual people working on different solutions. Therefore, you can define in the cluster what you want to do to link objects together. Packages are always assigned to a cluster, not individual objects. Here, the responsibility lies with the entire package. The packages should be broken down into smaller, manageable units to allow for easy assignment to clusters and maintain a clear overview.

A further application is available to perform the cluster assignment. This means we want to be able to assign open packages from different systems to different clusters relatively easily. The application is designed so that we always see unassigned packages, thus maintaining an open list of objects that we still need to assign. Using the "Assign Cluster" function, we can then select one or more packages and assign them directly to a cluster. The filter at the top allows us to, for example, set the assign flag to empty. This lets us see which packages are already assigned, which cluster they are assigned to, and which are still open. This also makes it easy to make bulk changes.

The last application in this area is Custom APIs. Here, we can define our own standard APIs that may have an API-like character within the system but are not officially released by SAP. The idea here is to define objects that are essential for our processes to run, but which we might later want to exclude from the Clean Core Score calculation. In addition to the object, provider type, and name, there is also a short description that explains what we actually want to use the object for. The application also offers the option to load data via Excel or JSON from a directory in order to import an existing configuration.

 

Reporting

In the reporting area, there are various applications to view different aspects of the status. We briefly looked at the objects app: Here, you'll find the individual objects per system with their corresponding package assignments. However, what we don't see in this list, due to insufficient screen space at this resolution, is further information about the individual object. For example, we see the documentation, which is linked here, as well as the cluster assignment, the object classification, and the Technical Debt Score, by which the list is also sorted. Navigating to an object reveals the relevant attributes, which are important to us and also appear in the list. The upper section displays the documentation and the assigned cluster. The score section shows the object classification and the Technical Debt Score achieved by this object, along with further information about all related messages. The lower section contains a list of all messages generated for this object, allowing you to browse through the different messages and classifications.

The second application is the APIs used, which provide information about which APIs are primarily used by developers in the various systems. Here you have information about the most frequently used APIs and a way to jump directly to the corresponding system. For example, we can see that BUT000 is used in three different objects, and we can jump to the object app with a click on the number. This is a way to analyze which objects would need to be adjusted, for example, if we want to replace BUT000. It's also a good idea to provide a central wrapper or to use the successor object directly to get rid of the messages from these objects.

Under Checks, you'll find an overview of the different messages, filtered by the actual check title and check message, which we can then also evaluate. For example, we could look at how many messages we could relatively easily eliminate if we resolved all messages with a successor object. This would be a clear indicator that there are successor objects that a developer hasn't used.

The final overview is intended to provide information about which cluster on which system is particularly busy. At a glance, we can see that different teams or products are assigned a different number of objects with different classifications. This should give a rough overview of which team is either not adhering to Clean Core correctly or, more importantly, has the most work to do in the future to eliminate these findings. This overview can also help plan where significant resources will be needed in the future to make adjustments, or it indicates which module has the fewest standard APIs available and therefore requires the use of many unreleased objects.

 

Outlook

The broad classifications and applications already work very well with the open-source project. Smaller features, such as the new metrics or various validations, are currently missing. These will be added gradually, as will further options for configuring settings and customizing overviews. Intrigued? Then just give the project a try. You'll find a link to the project in the description, and further information about installation in the actual GitHub repository. Currently, the installation might be a bit complex, as the individual applications have to be deployed to the system separately and are not included with the GitHub project. That brings us to the end of this episode. Thank you for watching and listening, and I'll see you next time.

 

YouTube
Video