Clean Core Measurement - Übersicht

Inhaltsverzeichnis

• Einleitung
• Ziel
• Herausforderungen
• Messbarkeit
• RISE Dashboard
• Projekt Kernseife
• CCM
• Grund
• Anforderungen
• Ausblick
• Fazit

In diesem Artikel machen wir einen Einstieg in das Thema Messbarkeit, schauen uns die Wichtigkeit an und gehen dann auf aktuelle Möglichkeiten ein.

 

Einleitung

Befindest du dich aktuell in einem Clean-Core-Projekt, gibt es eigentlich drei Varianten, um genau zu sein: ein Greenfield-Projekt, ein Bluefield-Projekt und ein Brownfield-Projekt. Bei Greenfield baust du alles direkt neu auf und hast damit die Chance, alles nach den Clean-Core-Standards aufzubauen. Funktionen werden zuvor geprüft, ob sie im Standard vorhanden sind und es sollten mit Erweiterungen nur Mehrwerte geschaffen werden. Bei Bluefield übernimmst du Bestandteile aus einem Altsystem und modernisierst diese Stück für Stück später einmal. Und bei Brownfield nimmst du im Grunde ein bestehendes System, machst ein Upgrade und schaust dir dann an, was eigentlich zu korrigieren wäre, um ein System sauber zu bekommen. Weitere Informationen zu den Arten bekommst du im ABAP Leitfaden der DSAG (bald auch in Englisch).

Entsprechend wichtig ist es, eine Transparenz zu haben über die Fehlermeldungen und die kritischen Objekte im System, um diese zu korrigieren. Die Messbarkeit spielt dabei bei allen drei Arten eine wichtige Rolle, denn wir wollen unser System stetig sauber halten, das heißt, wir haben einen Governance-Prozess über das System, oder wir wollen unser System sauber bekommen. Das heißt, wir schauen, welche Findings wir als Erstes bearbeiten sollten und was im System aktuell am kritischsten ist. Dabei hilft die Messbarkeit, die uns Level D Objekte transparent darstellt und für Eigenentwicklungen einen Technical Debt Score definiert. Damit haben wir verschiedene Möglichkeiten, wie wir an die Abarbeitung der Findings gehen. Egal ob erst alle Level D Objekte oder die Modernisierung von Anwendungen mit hohem Score, so haben wir Möglichkeit transparent die Herausforderung anzugehen.

 

Ziel

Dabei gibt es für Unternehmen unterschiedliche Arten von Zielen. Clean Core ist ein Ziel davon. Dies zu erreichen, ist mittlerweile dank des Clean Core Level Konzepts relativ einfach. Grundsätzlich müssen wir dazu nur alle Level D Findings aus dem System entfernen und stetig an Level C arbeiten.

© SAP SE

 

Damit wären wir im Grunde schon einmal Clean Core und Upgrade-Stable. Wollen wir allerdings Cloud-Ready werden, ist das nochmals ein viel größerer Aufwand, da wir dafür Level A zu 100 % erreichen müssen. Für diese beiden Kennzahlen können wir dann entsprechende Werte errechnen, indem wir zum Beispiel die Objekte aus den verschiedenen Levels nehmen und eine Quote errechnen. Damit könnten wir theoretisch unserer Geschäftsführung immer eine Kennzahl liefern, die den aktuellen Stand des Systems widerspiegelt.

 

Herausforderungen

Allerdings gibt es dafür auch einige Herausforderungen, die wir beachten sollten. So wurde das System zum Beispiel nicht nur aus Spaß modifiziert, sondern weil wir damit bestimmte Business-Prozesse abbilden wollen. Das heißt, Modifikationen oder Enhancement-Technologien, die vielleicht veraltet sind, werden aber von uns benötigt, um unsere Prozesse im Unternehmen am Laufen zu halten und einen Mehrwert zu generieren. Der zweite Punkt ist das Thema fehlende APIs. Manchmal verwenden wir Level C APIs, weil es keine Alternativen oder freigegebenen APIs im System gibt, die zum Beispiel ABAP Cloud oder Classic APIs sind. Damit kann unsere Schuld im Level C Bereich relativ schnell anwachsen, vor allem wenn wir in Modulen unterwegs sind, die bisher noch kein Enablement für ABAP Cloud erfahren haben.

 

Messbarkeit

Schauen wir uns deshalb für das Thema Messbarkeit zwei aktuelle Projekte an und was wir bereits heute daraus gewinnen können.

 

RISE Dashboard

Das umgangssprachliche RISE Methodology Dashboard ist ein Standardprodukt der SAP, welches, wie der Name schon sagt, vor allem für RISE-Kunden gedacht ist. Dabei erhalten wir ein Standard-Dashboard, wo bereits der Großteil der Zahlen eingespielt ist und welches standardisiert eingerichtet wird, um unsere Systeme zu vermessen und Kennzahlen zu erhalten. Allerdings, hier kommt der größte Nachteil, benötigen wir dafür einen RISE-Vertrag mit SAP, wir müssen also auf der Private Cloud sein. Da viele Kunden noch nicht in der Private Cloud sind oder das nicht möchten, steht das Dashboard nur einer gewissen Anzahl von Unternehmen zur Verfügung und es wird eine andere Lösung benötigt, um die Messbarkeit von Clean Core sichtbar zu machen. Das Dashboard teilt sich aktuell in die Dimensionen Extensibility, Data und Integration und soll dafür Zahlen und Übersichten liefern. Schauen wir auf die Extensiblity, erhalten wir den Technical Debt Score eines Systems, sowie Kennzahlen zu den Modifikationen.

 

Im unteren Teil erhalten wir Kennzahlen für die verschiedenen Level von Objekten. Dabei werden Objekte für Level A automatisch aus dem System ermittelt und hinterlegt. Alle Objekte aus dem Standard ABAP für Level B bis D müssen über einen ATC Check eingespielt werden. Dabei führen wir über die Custom Code Migration App oder ein Central ATC einen Lauf durch und laden das Ergebnis im Dashboard hoch.

 

Von hier ist auch eine Navigation in die verschiedenen Findings und Objekte (Level B bis D) möglich, um zu einzelnen Objekten Findings und Nachrichten anzuschauen. Damit können Level D Objekte oder Objekte mit einem hohen Score als erstes bearbeitet werden.

 

Projekt Kernseife

Hier wurde auch das Projekt Kernseife ins Leben gerufen, welches die Messbarkeit von Clean Core noch einmal anpasst. Vor allem, wenn es darum geht, nicht freigegebene APIs zu dokumentieren, die aber sinnvoll zu nutzen sind, wie zum Beispiel Core Data Services, die bereits im System sind, aber keinen Release Contract haben. Weiterhin soll die Menge an ATC-Findings, die am Ende der ABAP Test Cockpit Prüfung ausgegeben wird, reduziert werden, um sich auf das Wesentliche zu konzentrieren. Dafür wurden innerhalb des Projekts verschiedene CAP Applikationen gebaut, die der Kunde auf der Cloud Foundry in der BTP installieren kann, um die Ausnahmeliste fürs ATC zu pflegen und kundeneigene Nachfolger zu definieren. Ebenso stellt das Projekt einen angepassten ATC Check zur Verfügung, um die Ausnahmen, die definiert wurden, auch im eigenen System nutzen zu können.

Allerdings ist diese Lösung noch nicht zu 100% Cloud-kompatibel. Das heißt, sie funktioniert nicht in ABAP Cloud und kann somit zum Beispiel auch auf keinem zentralen ATC im ABAP Environment betrieben werden. Weiterhin müssen CAP Anwendungen deployed und betrieben werden, was vielleicht nicht zur aktuellen Architektur im Unternehmen passt. Weitere Informationen zur Messbarkeit mit "Kernseife" findest du in der Linksammlung unten in der SAP Community und im GitHub Projekt.

 

CCM

Aus diesem Grund ist das Projekt CCM entstanden, um verschiedene Punkte in der Kette anzugehen und auch nicht RISE Kunden eine Möglichkeit zu geben, Messbarkeit einfach zu implementieren.

 

Grund

Grundsätzlich funktionieren die beiden Lösungen von oben, also das RISE-Dashboard und das Projekt Kernseife, schon sehr gut, wenn du Messbarkeit innerhalb eines Clean Cores hinbekommen möchtest und individuell aufs eigene Unternehmen anpassen möchtest. Allerdings fehlen in der ersten Lösung Bestandteile wie zum Beispiel die Dokumentation und Zuordnung zu Produkten innerhalb einer Organisation oder die Bildung von Clustern, um eine Übersicht zu bekommen. Weiterhin möchten Kunden auch dokumentieren, wenn sie bestimmte APIs im System verwenden, diese aber auch wirklich benötigt werden, um den Prozess voranzubringen. Solche Findings möchten wir nicht jedes Mal im Clean-Core-Dashboard sehen, sondern einmal dokumentieren und danach entsprechend aus den Findings nehmen können. Neben diesem fiktiven Clean-Core-Stand möchten wir natürlich trotzdem immer wieder schauen, wie es zum echten Standard eigentlich aussieht. Das heißt, wenn das Ziel ist, in die Public Cloud zu gehen, wollen wir natürlich sehen, welche Prozesse haben wir überhaupt noch nicht implementiert, welche sind noch offen. Wir haben immer einen Arbeitsstand und einen wirklichen Stand im System, den wir entsprechend auch Reporten können. Zum Schluss soll der Prozess auch automatisiert werden, sodass auf Basis von Wochen oder Monaten automatisch Zahlen verfügbar gemacht werden.

 

Anforderungen

Dafür haben wir uns aktuell folgende Punkte als Anforderungen gestellt, um ein Clean Core Measurement zu entwickeln, welchen Mehrwert für uns bieten kann:

• Open Source - Das Ganze soll später einmal als Open-Source-Projekt frei verfügbar zur Verwendung stehen, sodass es jeder installieren kann und auf seiner Reise Richtung Clean Core unterstützt wird.
• Central ATC - Die Lösung soll direkt auf dem zentralen ATC-System laufen. Somit haben wir die Möglichkeit, die Läufe und die Importe für die Objekte zu automatisieren, um so nicht mehr an die Umsetzung denken zu müssen und immer aktuelle Kennzahlen aus dem System zu erhalten. Weiterhin sollen mögliche Custom-Code-Checks später dann auch direkt im aktuellen System mit den Daten implementiert werden können.
• Dokumentation - Die Dokumentation von Findings, Paketen und Aufgaben soll einfach möglich sein und integriert mit dem Dashboard laufen. Dabei soll eine Zuordnung zu Clustern und Dokumentation möglich sein, ebenso eine Anpassung des Custom Scores, um so die TODOs im System noch zu sehen.
• Kennzahlen - Wir möchten auf einen Blick alle Systeme im Dashboard sehen und die beiden Kennzahlen für Clean Core und Upgrade-stable sowie Cloud-ready jederzeit einsehen können.
• Reporting - Über das Reporting wollen wir weitere Einblicke in verschiedene Hebel haben, die wir im System haben und umsetzen können. Dabei wollen wir Findings auswerten nach Gruppen und Meldungen, aber auch nach den verschiedenen Clustern, die im System vorzufinden sind.

 

Ausblick

Die Arbeit am CCM hat bereits begonnen und wir werden dir in den nächsten Artikeln Einblicke in die Architektur und die Entscheidungen geben, sodass du einen Einblick ins Projekt bekommst. Es gibt bereits auch ein GitHub Repository für das Projekt, wo sich immer ein aktueller Stand der Lösung befindet. Das Repository wird sich nach und nach mit Anwendungen und Anleitungen füllen.

 

Fazit

Messbarkeit von Clean Code ist damit weiterhin ein wichtiger Bestandteil, um Transparenz in den Clean Core Prozess und die Entwicklung zu bekommen. Wir möchten den Stand im System verbessern und dabei immer wieder auskunftsfähig sein. Hier macht es auf jeden Fall Sinn, eine Messbarkeit anzugehen, egal in welchem Bereich oder über welches Projekt sie sichergestellt wird. Grundsätzlich ein schlechter Punkt ist, keine Messung durchzuführen und sich nur auf ein Gefühl zu verlassen. Vor allem dann, wenn du sehr viele Entwickler hast, die im System unterwegs sind.

 

Weitere Informationen:
SAP Help - SAP Cloud ALM and RISE with SAP Methodology
SAP Community - Project Kernseife - improving the measurement of Clean Core in ABAP
SAP Community - Taking Control of Clean Core: When to Use Project Kernseife in addition to Standard SAP Tools
GitHub - Project Kernseife