050: Clean Core Measurement (Preview)

Inhaltsverzeichnis

• Überblick
• Dashboard
• Administration
• Prozess
• Reporting
• Ausblick

Die Messbarkeit von Clean Core und der Einstieg in die Clean Core Extensibility ist ein wichtiger Bestandteil, um eine Governance sicherzustellen und ein System sauber weiterentwickeln zu können. Daher schauen wir uns in dieser Folge einmal das Clean Core Measurement Projekt an, welches als Open Source zur Verfügung gestellt wird und zahlreiche Anwendungen zur Auswertung bereitstellt.

 

Überblick

Ist das Projekt sauber im System installiert und sind alle Anwendungen zur Verfügung gestellt, erhältst du einen entsprechenden Space für alle Anwendungen. Dabei ist der Space nach den unterschiedlichen Prioritäten und der Arbeit mit dem Clean Core Dashboard aufgebaut. Im oberen Teil findest du den Reporting-Part: Hier sind vor allem anzeigende Anwendungen, die Einblicke in die Daten der verschiedenen Systeme geben sollen. Im mittleren Teil findest du den Prozess-Part: Hier arbeiten normalerweise Qualitätssicherung, Dokumentation und verschiedene Zuordnungen, um weitere Informationen darstellen zu können. Im unteren Teil findest du die Administration: Hier ist eine Anwendung, um die verschiedenen Läufe zu verwalten. Weitere administrative Konfigurationen befinden sich in der Business Configuration und sind nicht als eigene Kachel eingebunden.

 

Dashboard

Werfen wir daher als Erstes einmal einen Blick auf das Dashboard, das eigentliche Herzstück des gesamten Open-Source-Projekts, um die Visualisierung möglich zu machen. Direkt nach dem Einstieg erhalten wir eine Liste aller möglichen Objekte bzw. Systeme, die an das Dashboard angeschlossen sind. In diesem Fall sehen wir drei Systemlandschaften. Im vorderen Teil finden wir die verschiedenen KPIs, die zu den Systemen gehören, wie zum Beispiel der aktuelle Cloud-Ready-Stand oder der Upgrade-Stable-Stand, dazu der Technical-Debt-Score, nach dem die Systeme sortiert sind. Dann finden wir eine schnelle Übersicht über alle Level und wie sich die verschiedenen Objekte auf die Level aufteilen.

Navigieren wir dann bei einem System in die Details, finden wir eine Übersicht der gleichen Kennzahlen wie zuvor plus zusätzlich noch verschiedene Änderungsindikatoren, die anzeigen, wie sich der Stand zur letzten Messung verändert hat. So bekommst du einen Überblick, in welche Richtung sich dein System entwickelt. Zusätzlich findest du auch noch Kennzahlen wie zum Beispiel die Key-User-Extensibility-Objekte, die im System verfügbar sind, da die Key User Extensibility ein wichtiger Bestandteil der Cloud-Ready-Strategie ist. Im unteren Teil findest du einen Trendchart, dieser ist aktuell aber noch in Umsetzung und stellt noch nicht den finalen Status dar. Hier soll sichtbar sein, wie sich der Trend in den verschiedenen Layern über die Zeit verändert hat.

Klickst du auf ein System in der Übersicht, gelangst du in die Detailansicht, um die verschiedenen Objekte aus diesem System zu prüfen. Da es sich hier um Testdaten handelt, sind diese Daten erst einmal nicht konsistent. Daher sehen wir hier weniger Objekte als in der Statistik angezeigt. Die Ansicht der Objekte würden wir uns aber zu einem späteren Zeitpunkt noch einmal anschauen.

 

Administration

Werfen wir einen ersten Blick in die Administration und schauen uns die gespeicherten Läufe an. Dabei sind diese gruppiert nach den verschiedenen Zeiträumen, in denen sie ausgeführt wurden, und nach den Systemen, die darin verfügbar sind. Navigieren wir in einen Lauf hinein, sehen wir, dass es allgemeine Informationen zum Lauf gibt und die verschiedenen Scores, die berechnet wurden. Aktuell unterstützt das System nur den Standard-Score. Dies ist der echte Score des Systems ohne entsprechende eigene Einstellungen wie eigene APIs, Exemption-Prozesse und Dokumentationen einzurechnen. Dieser zweite Score ist noch in der Umsetzung, daher sehen wir hier nur den Standard-Score. Grundsätzlich ist es möglich, auch verschiedene Score-Typen zu definieren, was vielleicht in einer späteren Version möglich sein kann, aktuell aber nicht geplant ist.

 

Prozess

Gehen wir in den Bereich Prozess, haben wir verschiedene Möglichkeiten, Prozesse aus unserem eigenen Unternehmen abzubilden. In der ersten Kachel findest du deshalb die Dokumentation. Dokumentationen sind Bestandteile, die wir dokumentieren können, entsprechende IDs zuordnen können und am Ende dann auch Objekte zuordnen können. In den Details findest du Informationen wie eine Kurzbeschreibung; diese beschreibt das Projekt oder die Umsetzung in kurzen Details. Wir haben aber auch eine detaillierte Information mit einem Rich Text Editor. Hier haben wir alle Möglichkeiten, längere Texte und Beschreibungen zu formulieren, um das Projekt und den Scope besser festhalten zu können odr auch Links zu externen Dokumenten mit einzufügen. Grundsätzlich können wir auch definieren, ob es einen Custom Score für alle definierten Objekte geben soll. So können wir zum Beispiel definieren, dass wir diese Entwicklung unbedingt benötigen und damit den Score zum Beispiel reduzieren, da wir hier nicht Clean Code sind, aber das Risiko eingehen, da wir diesen Prozess unbedingt benötigen. Im unteren Teil findest du die verlinkten Objekte, die zu dieser Entwicklung gehören. Hier ist es möglich, einzelne Objekte oder Pakete zu definieren.

Daneben gibt es die Anwendung für das Cluster. Im Cluster beschreiben wir eigentlich, ob es zum Beispiel ein Produkt ist, ein Team oder einzelne Menschen, die sich um verschiedene Lösungen kümmern. Daher kannst du im Cluster definieren, was du möchtest, um Objekte miteinander zu verknüpfen. Dabei werden einem Cluster immer Pakete zugewiesen, nicht einzelne Objekte. Hier liegt die Verantwortung auf dem Gesamtpaket. Die Pakete sollten entsprechend klein geschnitten werden, um sie auch Clustern zuordnen zu können und eine gute Übersicht zu haben.

Dazu steht eine weitere Anwendung zur Verfügung, um das Cluster-Assignment durchzuführen. Das heißt, wir wollen relativ einfach offene Pakete der verschiedenen Systeme den unterschiedlichen Clustern zuordnen können. Die Anwendung ist so aufgebaut, dass wir immer nicht zugeordnete Pakete sehen und somit eine offene Liste der Objekte haben, die wir noch zuordnen müssen. Über die Funktion „Assign Cluster“ können wir dann ein oder mehrere Pakete markieren und ein Cluster direkt zuordnen. Über den Filter im oberen Bereich haben wir dann noch die Möglichkeit, zum Beispiel das Assign-Flag auf leer zu setzen. So sehen wir, welche Pakete bereits zugeordnet sind, welchem Cluster sie zugeordnet sind und welche noch offen sind. So können wir auch ganz einfach Änderungen in Masse durchführen.

Die letzte Anwendung aus diesem Bereich sind die Custom APIs. Hier haben wir die Möglichkeit, eigene Standard-APIs zu definieren, die vielleicht einen API-Charakter im System haben, aber nicht offiziell von SAP freigegeben sind. Die Idee ist hier, Objekte zu definieren, die wir zwingend brauchen, damit unsere Prozesse laufen, diese aber zum Beispiel aus dem Clean-Core-Score später herausrechnen wollen. Dazu gibt es neben dem Objekt, Provider-Typ und dem Namen auch eine Kurzbeschreibung, die beschreibt, wofür wir das Objekt eigentlich einsetzen wollen. In der Anwendung steht auch eine Möglichkeit zur Verfügung, die Daten per Excel oder per JSON aus einem Verzeichnis laden zu können, um so eine bestehende Konfiguration einzuspielen.

 

Reporting

Im Bereich des Reportings gibt es verschiedene Anwendungen, um auf verschiedene Sichten innerhalb des Standes schauen zu können. Die Objekte-App hatten wir uns kurz angeschaut: Hier gibt es die Einzelobjekte pro System mit entsprechenden Zuordnungen zu Paketen. Was wir allerdings hier in der Liste nicht sehen, da der Platz auf dem Screen in dieser Auflösung nicht ausreicht, sind weitere Informationen zu dem Einzelobjekt. So sehen wir zum Beispiel die Dokumentation, die hier noch verlinkt ist, aber auch die Zuordnung des Clusters, die Objektklassifizierung und den Technical-Debt-Score, nach dem die Liste auch sortiert ist. Navigieren wir auf das Objekt, sehen wir die entsprechenden Attribute, die für uns wichtig sind und die wir auch in der Liste sehen. Im oberen Teil siehst du die Dokumentation und den entsprechend zugeordneten Cluster. Im Score-Bereich siehst du die Objektklassifizierung und den Technical-Debt-Score, den dieses Objekt erreicht, sowie weitere Informationen zu den Meldungen in der Gesamtheit. Im unteren Teil findest du eine Liste der Meldungen, die für dieses Objekt erzeugt wurden, und kannst so durch die unterschiedlichen Meldungen und Klassifizierungen schauen.

Die zweite Anwendung sind die genutzten APIs, die uns Informationen darüber geben sollen, welche APIs in den verschiedenen Systemen vor allem von den Entwicklern genutzt werden. Hier hast du eine Information über die am häufigsten genutzten APIs sowie eine Möglichkeit, direkt in das entsprechende System abzuspringen. So sehen wir zum Beispiel, dass die BUT000 in drei verschiedenen Objekten genutzt wird, und können mit einem Klick auf die Anzahl auch in die Objekte-App abspringen. Das ist eine Möglichkeit zu analysieren, welche Objekte zum Beispiel angepasst werden müssten, wenn wir die BUT000 austauschen wollen. Hier bietet es sich auch an, einen zentralen Wrapper zur Verfügung zu stellen oder direkt das Nachfolgeobjekt zu verwenden, um die Meldungen aus diesen Objekten loszuwerden.

Bei den Checks findest du eine Übersicht über die verschiedenen Meldungen, gefiltert nach dem eigentlichen Check-Titel und der Check-Message, die wir dann auch auswerten können. So könnten wir zum Beispiel schauen, wie viele Meldungen wir jetzt zum Beispiel relativ einfach beseitigen können, wenn wir alle Messages mit einem Successor zum Beispiel beheben würden. Dies sei ein eindeutiger Indikator dafür, dass es hier Nachfolgeobjekte gibt, die von einem Entwickler nicht genutzt wurden.

Die letzte Übersicht soll Informationen darüber geben, welches Cluster auf welchem System besonders viel Arbeit hat. So sehen wir auf einen Blick, dass den verschiedenen Teams bzw. Produkten eine unterschiedliche Anzahl von Objekten mit unterschiedlicher Klassifizierung zugeordnet ist. Das soll einen groben Überblick geben, welches Team entweder nicht richtig nach Clean Core arbeitet oder vor allem die meiste Arbeit hat, diese Findings in Zukunft wieder zu beseitigen. Diese Übersicht kann auch helfen zu planen, wo besonders viele Kapazitäten in Zukunft benötigt werden, um Anpassungen vorzunehmen, oder weist darauf hin, in welchem Modul die wenigsten Standard-APIs zur Verfügung stehen und deshalb sehr viele nicht freigegebene Objekte verwendet werden müssen.

 

Ausblick

Die groben Klassifizierungen und Anwendungen funktionieren bereits heute sehr gut mit dem Open-Source-Projekt. Kleinere Punkte wie die neuen Kennzahlen oder zum Beispiel verschiedene Validierungen fehlen aktuell noch. Diese werden Stück für Stück nachgeliefert werden, ebenso wie weitere Möglichkeiten, Einstellungen vorzunehmen und Übersichten anzupassen. Bist du neugierig geworden? Dann probier das Projekt einfach mal aus. Einen Link zum Projekt findest du in der Beschreibung, weitere Informationen zur Installation im eigentlichen GitHub-Repository. Aktuell könnte die Installation etwas komplex sein, da hier die einzelnen Anwendungen separat auf das System deployed werden müssen und nicht mit dem GitHub-Projekt ausgeliefert werden. Somit wären wir am Ende dieser Folge. Ich bedanke mich fürs Zuschauen und Zuhören und wir sehen uns dann beim nächsten Mal.

 

YouTube
Video