Erstellt von All in One SEO Pro v5.0.1.1. Dies ist eine llms-full.txt -Datei, die von hoch entwickelten KI-Systemen (LLMs) zur Indizierung der Websites verwendet wird.
# The Cattle Crew Blog
All about Digital Transformation. Powered by OPITZ CONSULTING
## Beiträge
### [Oracle Forms 14: New Features Every Forms Developer Should Know](https://thecattlecrew.net/2026/07/02/oracle-forms-14-new-features-every-forms-developer-should-know/)
**Published:** Juli 2, 2026
**Author:** Gerd Volberg
**Content:**
Oracle Forms 14, the latest version of the proven enterprise application development environment, brings many new features and improvements. This new version focuses on a modern user experience, improved integration with web technologies and optimized performance. In this article, we take an in-depth look at the new features of Oracle Forms 14 and how they help developers create and manage powerful applications efficiently.
## Improvements to the user interface
With Oracle Forms 14, developers can now design more modern and flexible user interfaces. The most important new features are
Placeholder texts in text fields: This improves user-friendliness by displaying relevant notes directly in input fields.
Figure 1: Placeholders in text items**Modern progress bars:** Developers can now implement progress bars for long-running processes.
Figure 2: Modern progress bars**Gauge progress bars:** Gauge and Half Gauge are very similar to progress bars as they support the visual representation of a data value.
Figure 3: Gauge progress bar**Auto-complete function:** Combo boxes can display text suggestions based on data already entered.
Figure 4: Auto-complete function**Hidden input:** Passwords that are hidden during input can be made visible with a new button. However, only as long as the button is pressed. After the click, the value is hidden again.
Figure 5: Hidden input of passwords**Show number of characters:** For larger text fields, a character counter can be displayed so that you always know how many characters can still be entered.
Figure 6: Show number of characters**Transparent UI elements:** A new glass fill pattern enables the creation of modern, transparent interfaces.
**Dynamic layouts:** Automatic resizing of blocks based on the amount of data for an optimized display. There is a new parameter Records\_Displayed in the procedure SET\_BLOCK\_PROPERTY.
BEGIN
SET\_BLOCK\_PROPERTY (‚EMP‘, RECORDS\_DISPLAYED, 3);
END;
*Listing 1: Reducing the number of rows displayed in a block*
Figure 7: Reducing the number of rows**Rollover button:** With the “Rollover Color Swap” property, the foreground and background colors are swapped when the mouse is moved over the button.
Figure 8: Rollover button## REST services
Oracle Forms 14 extends the possibilities of application integration with modern web technologies. Particularly noteworthy is the native support of RESTful web services: Developers can now use REST APIs to retrieve or send data from external sources. CRUD operations can be called directly from forms: This allows editing, creating, deleting and retrieving data from REST services. Support for JSON data retrieved via REST services is also new.
**REST Package Designer:** With the new REST Package Designer, developers can create PL/SQL packages for direct access to REST services. This enables seamless integration with modern web technologies and APIs.
Figure 9: REST Package DesignerThe REST Package Designer generates a separate PL/SQL package for each operation at the touch of a button.
Figure 10: Automatically generated PL/SQL REST packages## Real-time data update with Continuous Query Notification
A new feature in Oracle Forms 14 is the support for Continuous Query Notification
(CQN). With this function, data is updated in real time when the underlying data changes. The advantages are obvious: Forms masks always show the current values without the user having to start a query. This reduces unnecessary database queries as changes are automatically displayed in the interface. This is perfect for dashboard and reporting applications that require continuous updating.
To do this, you register the query of the forms block that you want to update on the database side. This change notification (QRCN) then starts events that can be queried in Forms. To do this, a WHEN-EVENT-RAISED trigger must be created at form level. The GET\_EVENT\_OBJECT\_PROPERTY function can then be used here to check whether the data block needs to be updated. The following new properties can be read in the function:
- TOTAL\_ROWS\_AFFECTED
- TOTAL\_ROWS\_UPDATED
- TOTAL\_ROWS\_INSERTED
- TOTAL\_ROWS\_DELETED
- ROWS\_INSERTED
- ROWS\_DELETED
- ROWS\_UPDATED
- TABLE\_ALTERED
- TABLE\_DROPPED
## Performance improvements in data processing
Many performance improvements have been implemented in the new release. The most important are the following features.
Sorting in blocks: In Oracle Forms 14, data can be sorted locally. This reduces the load on the database and significantly improves the reaction speed of the application. A best practice with this new feature is to set the Query All Records property in the data block to TRUE so that all data records are cached in Forms. Otherwise, the sorted data records could lose their sorting when new data records are fetched, as the new data records do not automatically appear in the sorting, but are displayed at the end of the data block.
Such sorting could, for example, be built into a WHEN-MOUSE-DOUBLECLICK trigger at block level.
```
BEGIN
Sort_Block (:System.Cursor_Item, Nulls_First, Descending)
END;
```
*Listing 2: Start sorting by double-clicking with the mouse*
In addition to the field name, up to four parameters can be passed:
- ASCENDING (default) or DESCENDING
- NULLS\_LAST (default) or NULLS\_FIRST
- CASE\_SENSITIVE (default) or CASE\_INSENSITIVE
- BINARY\_ORDER (default) or LINGUISTIC\_ORDER
## Improvements in the Form Builder
The Form Builder has also received important new features. The most important ones follow here.
**Revised file open dialog:** Developers can now open multiple files at the same time, which significantly increases productivity. In addition, the file filter has been set to
\*.fmb by default, a feature that many developers have requested in previous versions.
**Database name display:** Forms Builder now also displays the current database name in the status bar, which is particularly helpful for developers with multiple environments.
XML backup: Forms modules can now be automatically backed up to XML files, making integration with version control systems such as Git easier.
Figure 11: Automatically generated XML backup copy**Improvements to the Forms Standalone Launcher (FSAL):** The Forms Standalone Launcher receives some important enhancements with Forms 14. Automatic updates within the same main version are now possible.
The **SSL/TLS certificate management has been improved** and **a cache deletion function has been added** for troubleshooting.
## Conclusion
Oracle Forms 14 brings a host of improvements for developers, administrators and end users. With new UI elements, enhanced REST integrations, real-time data updates and improved performance features, Forms continues to position itself as a powerful platform for enterprise applications. The new features make development more efficient and application maintenance easier. For companies working with Oracle Forms 12, the upgrade to version 14 represents significant added value.
## Links
[„Framework for Oracle Forms“ in: Best of Talk2Gerd (German)](https://thecattlecrew.net/2026/08/27/wiederverwenden-statt-wiederholen-ein-framework-fuer-oracle-forms/)
**Would you be interested in an Oracle Forms training course? [Find out more here](https://opitz-consulting.com/oracle-forms-schulung)**
**Kategorien:** Database, Development
**Schlagwörter:** Oracle Forms
---
### [Wiederverwenden statt wiederholen: Ein Framework für Oracle Forms](https://thecattlecrew.net/2026/08/27/wiederverwenden-statt-wiederholen-ein-framework-fuer-oracle-forms/)
**Published:** August 27, 2026
**Author:** Gerd Volberg
**Content:**
Wenn du diesen Post liest, weißt du wie lange sich viele von uns schon mit Oracle Forms beschäftigen. Mit meinen Best Practices bin ich 1992 gestartet in Trainings, meinem Blog Talk2Gerd, DOAG-Konferenzen und der Oracle Open World, und egal ob alte Hasen oder Neulinge: Immer noch treffe ich auf dankbare Gesichter, wenn ich meine Fundgrube öffne. Die beliebtesten Tipps habe ich jetzt in einer Serie zusammengefaßt, vor der du gerade stehst oder vermutlich eher sitzt. Aber wir wollen keine Zeit verlieren! Und los geht’s:
Teil 1 der Serie Best of Talk2Gerd | Ein Framework für Oracle FormsEine einzelne Oracle-Forms-Maske hast du schnell gebaut. Ein Datenblock, ein paar Items, einige Trigger – und die Anwendung tut, was sie soll. Die eigentliche Herausforderung beginnt, wenn aus einer Maske fünfzig, hundert oder mehrere hundert werden. Dann entscheidet nicht mehr die Geschwindigkeit beim Erstellen der nächsten FMB über die Qualität der Anwendung, sondern die Frage, wie konsequent wiederkehrende Aufgaben nur einmal gelöst werden.
Genau darin liegt die wichtigste Best Practice aus meiner langjährigen Projektarbeit: Eine große Forms-Anwendung braucht ein Framework. Gemeint ist kein möglichst kompliziertes technisches Fundament. Gemeint ist ein verbindliches System aus Konventionen, wiederverwendbaren Bausteinen und klaren Erweiterungspunkten. Es sorgt dafür, dass Entwickler nicht in jeder Maske erneut über Fehlermeldungen, Navigation, Berechtigungen oder Benennungen nachdenken müssen.
## Ohne Framework entsteht Architektur trotzdem, halt nur ungeplant
Auch eine Anwendung ohne offiziell definiertes Framework hat gemeinsame Muster. Sie sind dann lediglich verstreut: Ein Kollege unterdrückt Meldungen über :SYSTEM.MESSAGE\_LEVEL, eine Entwicklerin baut ein eigenes Alert-Package, ein dritter kopiert einen Trigger aus einer alten Maske. Mit jeder Kopie entstehen neue Varianten. Fehlerkorrekturen müssen anschließend an vielen Stellen nachgezogen werden – oder bleiben inkonsistent.
Das Problem ist nicht, dass es Leute gibt, die den Code wiederverwenden. Das Problem ist, dass du mit Copy-and-paste die Herkunft eines Bausteins verschleierst. Ein Framework macht beides: Wo befindet sich die zentrale Implementierung, und wie wird sie von einer Maske verwendet?
## Die fünf Bausteine eines praxistauglichen Forms-Frameworks
Mein ursprünglicher Ansatz beginnt mit drei Schritten: Styleguide definieren, Referenzform und Templates bereitstellen, anschließend Prototypen bauen. Für heutige Teams kannst du daraus ein Modell mit fünf Bausteinen ableiten:
### 1. Ein Styleguide beschreibt Entscheidungen, nicht Geschmack
Ein Forms-Styleguide sollte mehr enthalten als Farben, Schriftgrößen und Namenspräfixe. Wertvoll wird er dort, wo er das Laufzeitverhalten vereinheitlicht. Dazu gehören beispielsweise:
- Welche Trigger dürfen Logik enthalten, und welche delegieren nur an Packages?
- Wie werden Fehler klassifiziert, angezeigt und protokolliert?
- Wie werden Form-, Block- und Item-Namen gebildet?
- Welche Regeln gelten für Commit, Rollback, Exit und Navigation?
- Wie werden Berechtigungen und dynamische Menüs behandelt?
- Welche Logik gehört in die Maske, welche in eine PLL und welche in die Datenbank?
Ein guter Styleguide macht Code-Reviews kürzer. Du diskutierst dann nicht bei jeder Änderung in deinem Team dieselben Grundsatzfragen, sondern du prüfst, ob die vereinbarten Regeln korrekt angewendet wurden.
### 2. Die Referenzform zeigt den Sollzustand
Dokumentation allein reicht bei Forms selten aus. Besser ist eine Referenzform. Denn diese macht sichtbar, wie die Standards zusammenspielen: Welche Libraries sind angebunden? Welche Form-Level-Trigger existieren? Wie werden Alerts aufgerufen? Wie sehen Menüanbindung, Toolbar-Verhalten und Exception Handling aus?
Diese Form ist kein möglichst großes Demo-Modul, sondern ein ausführbares Architekturbeispiel. Sie sollte klein genug bleiben, damit neue Teammitglieder die Mechanik an einem Nachmittag nachvollziehen können. Gleichzeitig muss sie produktionsnah genug sein, um dir als Ausgangspunkt für neue Masken zu dienen.
### 3. Templates reduzieren Varianz
Ein Template spart dir nicht nur Klickarbeit. Sondern es setzt sichere Defaults. Neue Forms starten mit den richtigen Libraries, Triggern, Visual Attributes und Standardobjekten. Noch entscheidender ist jedoch die Pflege: Denn ein Template ist eine Momentaufnahme. Bereits erzeugte Masken übernehmen spätere Änderungen nicht automatisch. Deshalb braucht jede zentrale Funktion zusätzlich einen wiederverwendbaren Implementierungsort – meistens eine PLL oder ein Datenbank-Package.
### 4. Libraries bündeln Querschnittsfunktionen
In meinem [Blog](https://talk2gerd-de.blogspot.com) nenne ich hier unter anderem Exception Handling, dynamisches Meldungswesen, Zugriffsrechte, dynamische Menüs und PL/SQL-Libraries als Framework-Themen. Der gemeinsame Nenner: Es handelt sich um Funktionen, die viele Masken benötigen, deren Regeln aber nur an einer Stelle geändert werden müssen.
Wichtig: Eine Library sollte dabei nicht zu einem ungeordneten Sammelbecken werden. Besser sind klar abgegrenzte Packages, etwa für Navigation, Meldungen, Fehlerprotokollierung, Berechtigungsprüfung und technische Hilfsfunktionen. Denn so bleibt erkennbar, welcher Baustein wofür verantwortlich ist.
### 5. Prototypen prüfen nicht nur die Funktion, sondern das Framework
Ein Prototyp ist für dich besonders wertvoll, wenn er bewusst schwierige Fälle enthält: einen Multi-Record-Block, eine Master-Detail-Beziehung, Validierung mit Navigation, Datenbankfehler und einen Abbruch durch den Anwender. Erst an solchen Fällen zeigt sich, ob das Framework den Alltag erleichtert oder lediglich den einfachen Happy Path abdeckt.
## Konstanten: Kleine Technik, große Wirkung
Eine der einfachsten und zugleich wirksamsten Regeln ist für mich die Trennung von Literalen und Logik. Namen von Alerts, Blöcken, Items, Statuswerten oder Navigationsmodi tauchen in Forms häufig als Strings auf. Werden diese Zeichenketten überall hart codiert, reicht ein Tippfehler für einen schwer auffindbaren Laufzeitfehler.
Deshalb schlage ich in meinen [Trainings](https://opitz-consulting.com/oracle-forms-schulung) zwei Ebenen vor: ein globales Konstanten-Package in einer zentralen Library und ein lokales Package in jeder Formsmaske.
```
PACKAGE const IS
alr_error CONSTANT VARCHAR2(30) := 'AL_ERROR';
alr_info CONSTANT VARCHAR2(30) := 'AL_INFO';
alr_warning CONSTANT VARCHAR2(30) := 'AL_WARNING';
sta_changed CONSTANT VARCHAR2(10) := 'CHANGED';
mod_open_form CONSTANT VARCHAR2(10) := 'OPEN_FORM';
END const;
```
Das globale Package enthält Konstanten, die in der gesamten Anwendung dieselbe Bedeutung haben. Maskenspezifische Namen bleiben lokal:
```
PACKAGE const_local IS
blk_control CONSTANT VARCHAR2(30) := 'CONTROL';
itm_search CONSTANT VARCHAR2(61) := 'CONTROL.SEARCH_TEXT';
END const_local;
```
Der Aufruf wird dadurch lesbarer:
```
IF :SYSTEM.RECORD_STATUS = const.sta_changed THEN
-- geänderten Datensatz behandeln
END IF;
```
Der Nutzen geht über Lesbarkeit hinaus. Das heißt: Hast du den Namen einer Konstanten falsch geschrieben, meldet der Compiler den Fehler. Hat jemand hingegen den hinterlegten Stringwert falsch gepflegt, bleibt zwar weiterhin ein Laufzeitproblem möglich, aber die Ursache findest du an einem zentralen Ort und nicht in vielen Triggern. Diese Unterscheidung ist wichtig: Konstanten beseitigen also keine dynamische Namensauflösung von Forms, sie machen sie kontrollierbarer.
## Was gehört global, was lokal?
Eine einfache Entscheidungsregel hilft:
- **Global:** fach- oder anwendungsweit identische Begriffe, gemeinsame Alerts, Statuswerte, Standardmodi und Framework-Ereignisse.
- **Lokal:** Block- und Item-Namen einer konkreten Form, form-spezifische Canvas- oder Window-Namen sowie lokale Ereigniscodes.
- **Nicht als Konstante:** Werte, die Administratoren konfigurieren sollen, Geheimnisse, Umgebungsparameter oder fachliche Regeln mit eigenem Lebenszyklus. Sie gehören in Konfigurationstabellen oder geeignete Services.
## Ein Framework darf Entwicklung nicht verstecken
Ein Framework ist dann gelungen, wenn du die fachliche Absicht eines Triggers schneller erkennst. Ein WHEN-BUTTON-PRESSED, der eine klar benannte Navigationsroutine aufruft, ist verständlicher als zwanzig Zeilen wiederholte Status-, Fehler- und Fokuslogik. Problematisch wird es, wenn ein einziger vermeintlich komfortabler Aufruf unbemerkt Commit, Navigation, Berechtigungsprüfung und Meldungsunterdrückung kombiniert.
Deshalb sind bei Framework-Routinen **drei Eigenschaften** wichtig:
1. Eindeutige Verantwortung: Der Name beschreibt die relevante Wirkung.
2. Dokumentierte Vor- und Nachbedingungen: Darf die Routine validieren, navigieren oder Transaktionen beenden?
3. Vorhersehbares Fehlerverhalten: Fehler werden entweder behandelt oder eindeutig an den Aufrufer zurückgegeben.
## So startest du ohne Big Bang
Ein bestehendes Forms-System muss du nicht in ein Großprojekt umbauen. Stattdessen könnte ein pragmatischer Einstieg so aussehen:
1. Du sammelst wiederholten Code und häufige Fehler aus mehreren repräsentativen Masken.
2. Daraus leitest du wenige verbindliche Regeln für Deinen Styleguide und deren Namenskonventionen ab.
3. Du erstellst eine kleine Referenzform mit den wichtigsten Objekten, die in jeder Maske benötigt werden.
4. Querschnittsfunktionen verschiebst du zentral in Packages und Libraries.
5. Zwei oder drei unterschiedlich komplexe Forms migrierst du als Pilot.
6. Neue Standards führst du anschließend immer dort ein, wo eine Maske ohnehin geändert wird.
So wächst das Framework mit realen Anforderungen. Es bleibt überprüfbar und wird nicht zu einer theoretischen Plattform, die an deinem Alltag als Entwickler vorbeigeht.
## Fazit: Einmal entscheiden, überall profitieren
Die zentrale Erkenntnis aus drei Jahrzehnten Forms-Praxis heißt für mich: Große Anwendungen bekommst du wartungsmäßig nicht durch einzelne geniale Trigger in den Griff, sondern durch wiederholbare Entscheidungen. Styleguide, Referenzform, Templates, Libraries und Konstanten bilden hierbei gemeinsam eine Plattform, die alle im Team nutzen können.
Das bedeutet im Klartext: Ein gutes Oracle-Forms-Framework nimmt dir nicht die Kontrolle. Es nimmt dir Wiederholungen ab. Dadurch hast du mehr Zeit für das, was in jeder Maske tatsächlich neu ist: die Fachlichkeit.
## Links
**Im Cattle Crew Blog:** [Oracle Forms 14: New Features Every Forms Developer Should Know](https://thecattlecrew.net/2026/07/02/oracle-forms-14-new-features-every-forms-developer-should-know/)
**In meinem Blog Talk2Gerd:**
[Erstellen eines Forms Frameworks](https://talk2gerd-de.blogspot.com/2006/07/erstellen-eines-forms-framework.html)
[Globales Konstanten-Package](https://talk2gerd-de.blogspot.com/2005/10/globales-konstanten-package.html)
**Auf Github:** [Auf Github Historischer Quellstand des Forms-Framework-Projekts](https://github.com/GerdVolberg/forms-framework)
**Du brauchst eine Schulung?** [5-tägige Oracle-Forms-Schulung für Unternehmen mit Gerd Volberg](https://opitz-consulting.com/oracle-forms-schulung)
**Kategorien:** Database, Development
**Schlagwörter:** Forms, Frameworks, oracle, Oracle DB
---
### [MinIO-Alternative SeaweedFS: S3-Storage auf Kubernetes migrieren](https://thecattlecrew.net/2026/08/13/minio-alternative-seaweedfs-kubernetes-migration/)
**Published:** August 13, 2026
**Author:** Philipp Kürsten
**Content:**
MinIO war jahrelang die Standardantwort auf die Frage nach S3-kompatiblem Object Storage im eigenen Cluster. Seit Ende 2025 gilt das nur noch eingeschränkt: Die Community-Edition ist im Dezember 2025 in den Maintenance-Modus gewechselt, das öffentliche Repository wurde Anfang 2026 archiviert. Neue Funktionen entstehen ausschließlich in der kommerziellen Variante. Für viele Self-Hosting-Setups ist das der Anlass, sich nach einer dauerhaft quelloffenen Alternative umzusehen. [SeaweedFS](https://github.com/seaweedfs/seaweedfs) ist dafür ein ausgereifter Kandidat: Apache-2.0-lizenziert, aktiv weiterentwickelt und S3-kompatibel.
Dieser Beitrag zeigt anhand eines praxisnahen Ablaufs, wie SeaweedFS per Helm im HA-Setup auf Kubernetes installiert und bestehende Buckets anschließend per rclone-Job migriert werden – bis hin zum Cutover.
## SeaweedFS in Kürze
Wo MinIO ein einziger, symmetrischer Server-Prozess ist, teilt SeaweedFS die Aufgaben auf mehrere Rollen auf: der **Master** koordiniert den Cluster (Leader-Election per Raft), die **Volume Server** halten die eigentlichen Daten, der **Filer** legt den Namespace darüber, und ein zustandsloses **S3-Gateway** stellt die S3-API bereit. Für ein Setup, das man an SeaweedFS anbindet, spricht man am Ende nur mit dem S3-Gateway – der Rest ist Innenleben.
Zwei Dinge entscheiden über echtes HA: Der Master ist erst mit **drei** Replicas hochverfügbar (Raft-Quorum), und der Filer braucht einen gemeinsamen Metadaten-Store (PostgreSQL, MySQL oder Redis) – mehrere Filer mit lokalem `leveldb` sind kein HA.
## Installation von SeaweedFS per Helm
SeaweedFS bringt ein offizielles Helm-Chart mit, das die einzelnen Rollen als getrennte StatefulSets ausrollt. Das ist genau der Modus, den wir für ein HA-Setup brauchen. Zunächst das Chart-Repository einbinden:
```
helm repo add seaweedfs https://seaweedfs.github.io/seaweedfs/helm
helm repo update
```
Die eigentliche Arbeit steckt in den Values. Für ein hochverfügbares Setup bekommt jede Rolle drei Replicas und `replicationPlacement` legt fest, wie SeaweedFS die Daten über die Volume Server verteilt: Der Wert `001` sorgt dafür, dass jeder Chunk zusätzlich auf einem zweiten Server im selben Cluster liegt.
```
# seaweedfs-ha-values.yaml
global:
replicationPlacement: "001" # eine zusätzliche Kopie auf anderem Volume-Server
master:
replicas: 3 # 3 = Raft-Quorum, erst dann HA
data: { type: persistentVolumeClaim, size: 5Gi, storageClass: standard }
volume:
replicas: 3
dataDirs:
- name: data
type: persistentVolumeClaim
size: 100Gi # an Datenmenge anpassen
storageClass: standard
filer:
replicas: 3
# Für echtes HA: gemeinsamen Store (Postgres/MySQL/Redis) statt lokalem leveldb.
data: { type: persistentVolumeClaim, size: 10Gi, storageClass: standard }
s3:
enabled: true
replicas: 3
enableAuth: true
```
Die Größenangaben sind bewusst klein gehalten: Master und Filer speichern nur Metadaten, der Platzbedarf liegt also fast vollständig bei den Volume-Servern. Mit diesen Values lässt sich das Chart ausrollen:
```
helm upgrade --install seaweedfs seaweedfs/seaweedfs \
--namespace storage --create-namespace \
-f seaweedfs-ha-values.yaml
```
Der erste Start dauert einen Moment, weil die Master erst untereinander ein Quorum bilden müssen, bevor sich Volume Server und Filer anmelden können. Ein Blick auf die Pods zeigt, ob alle Rollen oben sind:
```
kubectl -n storage get pods -l app.kubernetes.io/name=seaweedfs
```
Sobald alles läuft, ist das S3-Gateway clusterintern unter `http://seaweedfs-s3.storage.svc:8333` erreichbar – das ist die Adresse, die später sowohl der Migrations-Job als auch die Anwendung selbst verwendet.
## Migration von MinIO
Der Ansatz: Beide Object Stores laufen parallel, die Daten werden in einem Wartungsfenster per `rclone` synchronisiert und verifiziert, dann stellt man die Anwendung um. MinIO bleibt als Fallback stehen. `rclone` passt hier gut, weil es beide Seiten als reines S3 spricht und mit `sync` idempotent arbeitet – ein abgebrochener Lauf lässt sich risikofrei wiederholen.
Vorab das Ziel-Bucket in SeaweedFS anlegen und die Anwendung read-only schalten, damit während der Migration nichts mehr nach MinIO geschrieben wird.
Das Manifest besteht aus zwei Teilen: Eine ConfigMap hält die `rclone.conf` mit beiden Endpunkten sowie das Migrationsskript, ein Job mountet beides und führt es aus. Beide Stores sind darin schlicht zwei S3-Remotes – der eigentliche Wechsel reduziert sich damit auf einen Kopiervorgang zwischen zwei Adressen:
```
# rclone-migration.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: rclone-migration-config
namespace: storage
data:
rclone.conf: |
[minio]
type = s3
provider = Minio
access_key_id = MINIO_ACCESS_KEY
secret_access_key = MINIO_SECRET_KEY
endpoint = http://minio.storage.svc:9000
region = us-east-1
[seaweedfs]
type = s3
provider = Other
access_key_id = SEAWEEDFS_ACCESS_KEY
secret_access_key = SEAWEEDFS_SECRET_KEY
endpoint = http://seaweedfs-s3.storage.svc:8333
region = us-east-1
force_path_style = true
migrate.sh: |
#!/bin/sh
set -e
BUCKET="my-app-data"
FLAGS="--transfers=16 --checkers=8 --checksum --retries=3 --stats=10s --stats-one-line"
rclone sync minio:$BUCKET seaweedfs:$BUCKET $FLAGS
rclone check minio:$BUCKET seaweedfs:$BUCKET --one-way $FLAGS
echo "Migration OK"
---
apiVersion: batch/v1
kind: Job
metadata:
name: rclone-minio-to-seaweedfs
namespace: storage
spec:
backoffLimit: 2
template:
spec:
restartPolicy: OnFailure
containers:
- name: rclone
image: rclone/rclone:latest
command: ["/bin/sh", "/scripts/migrate.sh"]
volumeMounts:
- { name: config, mountPath: /config/rclone, readOnly: true }
- { name: scripts, mountPath: /scripts, readOnly: true }
volumes:
- name: config
configMap:
name: rclone-migration-config
items: [{ key: rclone.conf, path: rclone.conf }]
- name: scripts
configMap:
name: rclone-migration-config
items: [{ key: migrate.sh, path: migrate.sh, mode: 0755 }]
```
Im Produktivbetrieb gehören die Access-Keys in ein Secret, nicht in die ConfigMap. Hier stehen sie zur besseren Lesbarkeit inline 😉
Ausgerollt wird der Job wie jedes andere Manifest; die Logs zeigen den Fortschritt live mit:
```
kubectl apply -f rclone-migration.yaml
kubectl -n storage logs -f job/rclone-minio-to-seaweedfs
```
`rclone check` vergleicht Quelle und Ziel und lässt den Job fehlschlagen, falls etwas nicht übertragen wurde – die Verifikation ist also direkt eingebaut.
**Cutover**: Anwendungskonfiguration auf den SeaweedFS-Endpoint umstellen (`endpoint: http://seaweedfs-s3.storage.svc:8333`, `forcePathStyle: true` – SeaweedFS erwartet Path-Style), Wartungsmodus deaktivieren, Smoke-Test fahren. MinIO noch ein bis zwei Wochen als Fallback stehen lassen, dann abbauen.
## Worauf ist zu achten?
- **Path-Style**: SeaweedFS adressiert per Path-Style. In `rclone` (`force_path_style = true`) und in der App (`forcePathStyle: true`) setzen, sonst laufen Requests ins Leere.
- **Filer-HA**: Mehrere Filer-Replicas brauchen einen gemeinsamen Metadaten-Store – sonst driften die Namespaces auseinander.
- **S3-Randfälle**: Multipart-Uploads und Presigned URLs verhalten sich zwischen Implementierungen leicht unterschiedlich. Vor dem produktiven Cutover im Staging testen.
## Fazit
Die Migration ist kein Big-Bang, sondern ein planbarer Zwei-Schritt: HA-Setup per Helm, dann eine idempotente rclone-Migration mit eingebauter Prüfung. Weil beide Systeme reines S3 sprechen, bleibt der Eingriff auf Infrastrukturebene – die Anwendungslogik bleibt unangetastet. Und mit MinIO im Fallback verliert der Cutover seinen Schrecken.
**Kategorien:** Cloud, DevOps, Infrastructure
**Schlagwörter:** Helm, Kubernetes
---
### [APEX IntelliSense für VS Code](https://thecattlecrew.net/2021/03/19/apex-intellisense-fuer-vs-code/)
**Published:** März 19, 2021
**Author:** janwinkels
**Content:**
Das großartige, wenn man mit Oracle APEX arbeitet, ist dass es immer noch eine Menge an Pionierarbeit zu erledigen gilt. Oft gibt es Ansätze, die man erweitern kann, aber oft gibt es für bestimmte Probleme noch gar keine Lösung. Genau diese Art von Problemstellungen sind es doch, warum wir ursprünglich mal Softwareentwickler geworden sind. Weil wir es lieben zu tüfteln, zu knobeln, oder nach der Arbeit die Welt von einem bösen Zombiepiraten zu befreien.
Aber zurück zum Thema: In allen weit verbreiteten Programmiersprachen ist eine IDE mit Autovervollständigung der Standard. Der Vergleich mit Oracle APEX ist hier aber nicht hundertprozentig fair, weil APEX im eigentlichen Sinne keine Programmiersprache, sondern ein Framework ist. Die Bibliotheken, die wir bei der Entwicklung in APEX verwenden, liegen in der Oracle Datenbank. Diese brauchen wir, um APEX zu betreiben. Ihr merkt also schon, wir haben kein lokales class-File, dass wir parsen können oder keine lokalen Klassen. Unsere Klassen sind Packages die als kompilierter Code in einem Datenbankschema liegen.
**Welche Tools stehen uns also als APEX Entwickler zur Verfügung?**
Oracles SQL Developer oder Quests Toad sind bisher die beiden Tools, die mir zur Datenbankentwicklung am meisten begegnet sind. Beide haben ihre Vor- und Nachteile, auf die ich hier nicht weiter eingehen will. Aber eine vernünftige Autovervollständigung haben beide nicht!
Als nächstes wäre APEX selbst zu nennen. Ab Version 20.2 gibt es eine integrierte Autovervollständigung. Diese kennt aber „nur“ die APEX Packages und die Objekte die wir in unserem Parsing-Schema (die View Schicht einer APEX Anwendung) definieren. Das Problem hat eine weitere Dimension: Es gibt einen quasi Standard, der besagt, dass man Code innerhalb von APEX aus Performance-, und damit letztendlich User Experience-, gründen vermeiden soll. Der Code soll stattdessen in Form von Packages in der Datenbank gehalten werden.
Es scheint also als müssten wir uns zwischen zwei Alternativen entscheiden: entweder suboptimale Anwendungen in APEX bauen oder auf eine komfortable Entwicklungsumgebung verzichten.
Suboptimale Anwendungen zu entwickeln ist natürlich keine Alternative. Deshalb haben wir uns eine Best Practise Architektur geschaffen, die ich im Folgenden kurz beschrieben möchte, um damit die Problemstellung noch klarer zu machen.
[](https://thecattlecrew.net/wp-content/uploads/2021/03/standardarchitektur.png) Abbildung1: Unsere Best Practice Architektur für Oracle APEX Anwendungen
Wie man in der Abbildung 1 sieht, schneiden wir unsere Anwendungsarchitektur, nach Vorbild des MVC Patterns, in drei Schichten:
Die DATA Schicht ist unsere Persistenz und enthält alle Entitäten unserer Anwendung.
Die LOGIC Schicht enthält die gesamte Anwendungslogik und übernimmt den Transport und die Aufbereitung von Daten von der DATA zur APP-Schicht.
Die APP Schicht ist unser APEX Parsing Schema und übernimmt Aufgaben, die sich auf das Frontend beziehen wie Validierungen, Datenpräsentation etc. Insbesondere auf dieser Ebene wird immer wieder auf Objekte der LOGIC Schicht, auf 3rd Party Libraries oder auf APEX native Objekte zugegriffen.
Um uns also die Arbeit in der APP-Schicht zu erleichtern brauchen wir ein Tool, dass:
- APEX Packages, APEX Variablen (Page Items),
- Objekte der LOGIC Schicht auf welche die APP-Schicht Zugriff hat,
- 3rd Party Libraries die auf der APP-Schicht zum Einsatz kommen
kennt und uns beim coden als Vorschläge zur Autovervollständigung anbietet.
**APEX meet Visual Studio Code**, **Visual Studio Code** **meet APEX**
Die Möglichkeit das zu verwirklichen ist eine Visual Studio Code Extension, [ApexIntelliSense](https://marketplace.visualstudio.com/items?itemName=JanWinkels.ais)!
Visual Studio Code hat sich, aufgrund der guten Erweiterbarkeit durch Extensions, in den letzten Jahren bei uns zu einem de facto Standard entwickelt. Die [ApexIntelliSense](https://marketplace.visualstudio.com/items?itemName=JanWinkels.ais)-Extension bietet die Möglichkeit sich mit einem APEX Parsing Schema zu verbinden. Dabei werden dann alle oben genannten Objekte ausgelesen und in einem Cache gespeichert, der auf Wunsch aktualisiert werden kann. Der Cache wird in Form von yaml-Dateien vorgehalten, die sich gut in eine Versionierung einbinden lassen.
Es werden zwei yaml-Cache-Files aufgebaut:
- eine für Parsing-Schema Objekte
- eine für APEX Objekte
Ein Feature der Extension ist, dass ein bereits erstellter APEX Cache als Quelle angegeben werden kann. Die Datei kann also zentral abgelegt werden und in mehrere Workspaces in Visual Studio Code eingebunden werden. Die Extension steht im Marketplace kostenlos zur Verfügung und kann bequem in Visual Studio Code installiert werden.
Es sei hier explizit erwähnt, dass unsere oben vorgestellt „Best Practise Architektur“ keine Voraussetzung für die Nutzung der Extension ist.
**Demo**
[](https://thecattlecrew.net/wp-content/uploads/2021/03/demo-1.gif)
**Kategorien:** Database, Development, Tools & Methoden
**Schlagwörter:** APEX, LowCode, oracle
---
### [Vom Monitoring zur Fachanwendung: Prometheus-Alerts für Business-Prozesse nutzbar machen](https://thecattlecrew.net/2026/06/22/fachliche-benachrichtigungen-aus-prometheus-alerts/)
**Published:** Juni 22, 2026
**Author:** Mark Hansen
**Content:**
Monitoring- und Alerting-Lösungen wie Prometheus informieren in erster Linie technische Teams über Probleme in Anwendungen und Infrastrukturen. In vielen Szenarien müssen jedoch auch Fachbereiche zeitnah auf Störungen reagieren können. Dieser Beitrag zeigt anhand eines Praxisbeispiels, wie Prometheus-Alerts über den Alertmanager aggregiert und direkt in eine Fachanwendung integriert werden können.
## Ausgangslage: FTP-Störungen in einer skalierenden Microservice-Architektur
Im betrachteten Szenario übernimmt ein Microservice die Übertragung von Dateien an ein externes Drittsystem. Ein Microservice dient als Datei-Mover, um Daten von einem S3-Bucket via FTP an ein Drittsystem zu übertragen. Um Lastspitzen abzufangen, skaliert der Service horizontal auf bis zu zehn Instanzen.
In der Praxis erwies sich die FTP-Verbindung jedoch als störungsanfällig. Die Ursachen reichen von kurzzeitigen Netzwerkschwankungen bis hin zu vollständigen Ausfällen des Drittsystems.
Um das Operations-Team bzw. die Entwickler über anhaltende Probleme zu informieren, existierte ein Prometheus-Alert: Besteht die Verbindungsstörung länger als zehn Minuten, wird automatisch eine Benachrichtigung in Microsoft Teams abgesetzt. Diese dient primär der technischen Analyse.
## Warum technische Prometheus-Alerts nicht ausreichen
Die technische Alarmierung allein reichte nicht aus. Auch der Fachbereich musste zeitnah über Störungen informiert werden, um deren Auswirkungen bewerten und gegebenenfalls Gegenmaßnahmen einleiten zu können.
Bei länger anhaltenden Störungen muss der Fachbereich die Verarbeitung selbstständig über ein Feature-Toggle stoppen können. Technische Alerts sollen deshalb direkt in der Fachanwendung sichtbar sein und dort konkrete Handlungen ermöglichen.
Außerdem soll nicht bei jeder Netzwerkschwankung eine Benachrichtigung erzeugt werden, sondern nur wenn der Fehler instanzübergreifend über einen längeren Zeitraum auftritt.
## Umsetzung: Prometheus-Alerting für fachliche Benachrichtigungen
Die Grundlage bildet ein Prometheus-Alert in dem Microservice, der für den Dateitransfer zum FTP-Server zuständig ist.
Ausgelöst wird der Alert unter folgenden Bedingungen: Der Alarm schlägt an, wenn über einen Zeitraum von zehn Minuten hinweg FTP-Befehle fehlschlagen und in diesem Zeitfenster keine einzige erfolgreiche FTP-Aktion registriert wird. So werden kurzzeitige kurzzeitige Netzwerkstörungen ignoriert und nur echte, anhaltende Blockaden gemeldet.
Da unsere Container-Umgebung stark skaliert, setzen wir auf den Amazon Managed Service for Prometheus. Der serverlose Dienst ermöglicht die zuverlässige Überwachung unserer dynamisch skalierenden Infrastruktur – auch bei hoher Last und vielen Instanzen.
Weitere Informationen zur Definition von Alerting Rules finden sich in der offiziellen [Prometheus-Dokumentation](https://prometheus.io/docs/prometheus/latest/configuration/alerting_rules/). Amazon Managed Service for Prometheus stellt einen vollständig [verwalteten Alertmanager](https://docs.aws.amazon.com/prometheus/latest/userguide/AMP-alert-manager.html) bereit, über den Alerts gruppiert und an verschiedene Zielsysteme weitergeleitet werden können.
### Alert-Aggregation mit dem Prometheus Alertmanager
Ein zentraler Bestandteil dieser Architektur ist der Prometheus Alertmanager. Er empfängt die von Prometheus erzeugten Alerts, fasst sie zusammen und leitet sie an die definierten Zielsysteme weiter.
Da unser File Mover bei hoher Last auf bis zu zehn Instanzen hochskaliert, würden ohne den Alertmanager im Fehlerfall zehn separate Alarme ausgelöst werden. Der Alertmanager erkennt diese Redundanz, fasst die Meldungen der einzelnen Instanzen zu einem einzigen logischen Alarm zusammen und leitet diesen gebündelt weiter – bisher primär an Microsoft Teams und nun zusätzlich an unsere Fachanwendung.
### Alert im Microservice[](#Alert-im-Microservice)
```
changes(aws_lambda_successful_ftp_command_exists_sum[5m]) == 0 and max_over_time(aws_lambda_failed_ftp_command_exists_sum[10m]) > 0
```
### Integration der Alerts in AWS SNS und SQS
Prometheus und der Alertmanager wurden in Terraform definiert, um die Ressourcen auf den verschiedenen Umgebungen identisch zu erstellen.
Die Routing-Logik des Alertmanagers wird ebenfalls über Terraform abgebildet. Dafür werden zunächst die möglichen Empfänger sowie die Regeln für die Weiterleitung der Alerts definiert.
Da es verschiedene Empfänger des Alerts vom Alertmanager gibt, wurden Variablen definiert:
```terraform
variable "alert_routes" {
type = list(object({
receiver = string
matchers = list(string)
active_time_intervals = list(string)
}))
description = "Describes an AlertManager route. The receiver must match a key in the alert_receivers map. The mute_time_intervals is ignored when empty."
}
variable "alert_receivers" {
type = map(object({
hook_parameter = optional(string)
send_resolved = bool
}))
description = "Describes an AlertManager receiver. The map key is used as receiver name."
}
```
Anschließend folgt die **Definition der Alert-Routen.** Dafür werden die Variablen werden wie folgt befüllt:
```terraform
alert_receivers = {
teams_technical = {
hook_parameter = "/amp/alertmanager/ms/teams/support/hook/url"
send_resolved = false
}
sqs_receiver = {
send_resolved = false
}
}
alert_routes = [
{
receiver : "sqs_receiver"
matchers : [
"architecture = application",
"error_type = business"
]
},
{
receiver : "teams_technical"
matchers : [
"architecture = application",
"error_type = technical"
]
}
]
```
Über das Label `error_type` wird zwischen rein technischen Benachrichtigungen und fachlich relevanten Störungen unterschieden. Dadurch können Alerts gezielt an unterschiedliche Empfängergruppen weitergeleitet werden.
### Bereitstellung der SNS-Topics
Für jeden definierten Empfänger wird anschließend ein eigenes SNS-Topic erzeugt:
```terraform
module "sns_topic" {
for_each = var.alert_receivers
source = "./modules/sns_topic"
name = "${module.label.id}-${each.key}-notification"
topic_policy_statements = {
amp = {
actions = [
"sns:Publish",
"sns:GetTopicAttributes"
]
}
effect = "Allow"
principals = [{
type = "Service"
identifiers = ["aps.amazonaws.com"]
}]
}
}
```
Das SNS-Topic des SQS-Empfängers wird anschließend über eine Subscription mit der Ziel-Queue verbunden:
```
resource "aws_sns_topic_subscription" "aws_sqs_notification_input_queue_name_sns_subscription" {
for_each = {
for k, v in var.alert_receivers : k => v
if startswith(k, "sqs_receiver")
}
topic_arn = module.sns_topic[each.key].aws_sns_topic_arn
protocol = "sqs"
endpoint = module.sqs.aws_sqs_topic_arn
}
```
## Nachrichtentemplates für Fachanwendungen
Damit die Fachanwendung die Alertinformationen verarbeiten kann, wird die Nachrichtenstruktur über ein Template standardisiert.
```yml
{{ define "sns.sqs.notification.message" }}{ "messageHeader": "{{ .CommonLabels.MessageHeader }}", "type": "ERROR", "title": "{{ .CommonLabels.Title }}", "message": "{{ .CommonLabels.Message }}" }{{ end }}
```
Abschließend wird der **Prometheus Alertmanager definiert**:
```terraform
resource "aws_prometheus_alert_manager_definition" "alerts_definition" {
workspace_id = aws_prometheus_workspace.this.id
definition = templatefile("${path.module}/alertmanager_config.yml",
{
sns_subject_template = file("${path.module}/templates/sns_subject_template.yml"),
sns_teams_template = file("${path.module}/templates/sns_ms_teams_template.yml"),
sns_sqs_template = file("${path.module}/templates/sns_sqs_notification_template.yml"),
topics = module.sns_topic,
alert_routes = var.alert_routes,
alert_receivers = var.alert_receivers
}
)
}
```
Hier die alertmanager\_config.yml:
```yml
---
template_files:
sns_subject_template: |
${sns_subject_template}
sns_teams_template: |
${sns_teams_template}
sns_sqs_template: |
${sns_sqs_template}:
alertmanager_config: |
global:
templates:
- 'sns_subject_template'
- 'sns_teams_template'
- 'sns_sqs_template'
route:
group_by: ['alertname', 'severity', 'cluster', 'one_shelf_cloud_environment', 'namespace', 'exported_namespace', 'app_kubernetes_io_instance']
receiver: default_receiver
routes:
%{ for alert_route in alert_routes }
- receiver: ${alert_route.receiver}
matchers:
%{ for matcher in alert_route.matchers }
- ${matcher}
%{ endfor ~}
%{ if length(alert_route.active_time_intervals) > 0 }
active_time_intervals:
%{ for active_time_interval in alert_route.active_time_intervals }
- ${active_time_interval}
%{ endfor ~}
%{ endif }
%{ endfor ~}
receivers:
%{ for alert_receiver_key, alert_receiver in alert_receivers }
- name: ${alert_receiver_key}
sns_configs:
- topic_arn: ${topics[alert_receiver_key].aws_sns_topic_arn}
send_resolved: ${alert_receiver.send_resolved}
message: |
%{ if startswith(alert_receiver_key, "sqs_receiver") ~}
{{ template "sns.sqs.notification.message" . }}
%{ else ~}
{{ template "sns.ms.teams.subject" . }}
%{ endif ~}
sigv4:
region: eu-central-1
attributes:
key: severity
value: info
%{ endfor ~}
```
Für die Microsoft-Teams-Benachrichtigungen müssen noch die Hook-Parameter aus dem SSM-Parameter-Store gesetzt werden und die SNS-Topic-Subscription definiert werden. Als Endpoint dient eine AWS-Lambda-Funktion, die die eingehenden Nachrichten an den entsprechenden Microsoft-Teams-Kanal weiterleitet. Wie diese Ressourcen genau definiert sind, wird in diesen Fall außer acht gelassen.
## Fazit und Ausblick[](#Fazit-und-Ausblick)
Die direkte Integration von Prometheus-Alerts in die Fachanwendung schließt die Lücke zwischen technischem Monitoring und operativen Geschäftsprozessen. Fachbereiche erhalten relevante Informationen direkt dort, wo sie arbeiten, und können ohne Umwege auf Störungen reagieren. Stattdessen erhält das Business nun in Echtzeit handlungsrelevante Informationen direkt in seiner gewohnten Arbeitsumgebung.
Durch die intelligente Aggregation im Alertmanager verhindern wir ein Überfluten der Anwendung mit redundanten Meldungen, selbst wenn unser Microservice voll skaliert ist. Der Fachbereich wird befähigt, über die integrierten Feature-Toggles autonom und ohne Verzögerung auf anhaltende Drittanbieter-Störungen zu reagieren. Das entlastet nicht nur die Bereitschaftsdienste der Softwareentwickler, sondern minimiert auch Ausfallzeiten und inkonsistente Datenzustände im Gesamtsystem.
**Kategorien:** Development
---
### [Eventbasierte Synchronisation zwischen Monolith und Cloud-Modul](https://thecattlecrew.net/2026/06/18/eventbasierte-2-wege-synchronisation/)
**Published:** Juni 18, 2026
**Author:** Christoph Ortmann
**Content:**
Viele Unternehmen modernisieren ihre IT-Landschaften schrittweise, indem einzelne Funktionen aus bestehenden Monolithen herausgelöst und als Cloud-Anwendungen neu entwickelt werden. Während dieser Transformation müssen Alt- und Neusystem häufig über längere Zeit parallel betrieben werden. Die Synchronisation von Daten und Geschäftsprozessen stellt dabei eine besondere Herausforderung dar. In einem Kundenprojekt stehen wir genau vor dieser Aufgabe: Eine Komponente eines monolithischen ERP-Systems soll in der Cloud neu implementiert werden, während das bestehende System weiterhin produktiv und führend bleibt.
Änderungen am Monolithen sind prinzipiell möglich, benötigen aufgrund der Release-Prozesse allerdings lange und sind mit Risiko behaftet. Für die Kommunikation mit dem Cloud-Modul implementieren wir im Umfeld des Monolithen eine Service-Fassade mit Zugriff auf die Datenbank und Anwendungsschnittstellen des Monolithen. Die Kommunikation zwischen Alt- und Neusystem erfolgt bevorzugt eventbasiert über Kafka.
Um den Parallelbetrieb von Alt- und Neusystem sicherzustellen, soll eine Synchronisation beider Systeme über Events hergestellt werden.
## Vorgehen zur Synchronisation
Zur Synchronisation vom Altsystem in das Neusystem wird das Altsystem erweitert, sodass jede fachliche Änderung als Event veröffentlicht werden kann. Die Events geben Auskunft darüber, welche fachliche Operation ausgeführt wurde und welches Domänen-Objekt wie geändert wurde. Wir bezeichnen diese Events daher als Domain-Events.
Synchronisation Altsystem => Cloud-Modul
Das Altsystem schreibt die Domain-Events zunächst in eine Outbox-Tabelle in der Datenbank. In der Service-Fassade läuft ein Prozess, der periodisch die Outbox auf neue Events prüft und diese an Kafka sendet. Das Cloud-Modul verarbeitet diese Events und führt die entsprechenden Operationen in seinen Backend-Services durch.
Synchronisation Cloud-Modul => Altsystem
Zur Synchronisation vom Neusystem in das Altsystem werden ebenfalls die fachlichen Änderungen als Domain-Events veröffentlicht. Auch diese werden zunächst in eine Outbox-Tabelle geschrieben, ehe sie an Kafka gesendet werden. Aufseiten des Altsystems werden die Events zunächst durch einen Prozess der Service-Fassade konsumiert und in eine Inbox-Tabelle geschrieben. Von dort werden sie durch einen Hintergrund-Prozess des Monolithen gelesen. Dieser Prozess führt die Events mithilfe der bestehenden Business-Funktionen des Monolithen aus.
## Konflikte vermeiden: Pessimistic Locking
Bei dieser Form der Synchronisation können Konflikte entstehen, wenn dieselben Business-Objekte parallel in beiden Systemen geändert werden. Der erste Ansatz zur Konfliktvermeidung, den wir betrachteten, beruht auf Pessimistic Locking. Im Prinzip bedeutet das, dass das Altsystem als führendes System Business-Objekte zur Änderung sperrt. Das Neusystem fordert vor jeder Änderung eine Sperre beim Altsystem an. Die Sperre wird gewährt, sofern das Altsystem das Business-Objekt nicht selbst gesperrt hat. Die Sperr-Anforderung kann mittels API- oder Command- & Response-Kommunikation über Kafka erfolgen.
Einen beispielhaften Ablauf zeigt die Grafik:
Pessimistic Locking ausgehend vom Monolithen
Im Altsystem wird eine Änderung vorgenommen. Das Altsystem sperrt das geänderte Business-Objekt und sendet an das Neusystem die Aufforderung, die Änderung ebenfalls durchzuführen.
Parallel wird im Neusystem versucht, eine Sperre für das bereits geänderte Business-Objekt zu erlangen. Die Sperranfrage wird vom Altsystem abgelehnt, der Anwender wird informiert, dass das Business-Objekt gesperrt ist und nicht bearbeitet werden kann.
Nachdem das Kommando zum Wiederholen der Änderung im Neusystem verarbeitet wurde, wird eine Bestätigung der Änderung an das Altsystem gesendet, worauf das Business-Objekt durch das Altsystem wieder freigegeben wird.
Das Vorgehen bietet den Vorteil, dass Konflikte weitgehend vermieden werden können. Allerdings erfordert die Einführung einer Sperrverwaltung im Altsystem einen aufwändigen Eingriff in das bestehende System. Darüber hinaus bewirkt die Notwendigkeit der Sperranforderung eine noch engere Kopplung des Cloud-Moduls an das Altsystem, die – besonders im Falle einer asynchronen Umsetzung – zu Latenzen führen kann.
Aufgrund der Nachteile einer Umsetzung mithilfe von Pessimistic Locking wurde als Alternative ein Ansatz auf Grundlage von Optimistic Locking betrachtet.
Grundprinzip Optimistic Locking
Während beim Pessimistic Locking versucht wird, Konflikte durch das Sperren von Datensätzen gar nicht erst entstehen zu lassen, beruht das Optimistic Locking darauf, Konflikte zu erkennen, wenn sie auftreten und durch den Anwender auflösen zu lassen. Typischerweise wird dazu jedes Business-Objekt mit einer Version oder dem Zeitstempel der letzten Änderung versehen, die beim Speichern hochgezählt bzw. aktualisiert werden. Zeitstempel oder Version werden vor der Bearbeitung des Datensatzes gelesen.
Beim Speichern wird geprüft, ob der persistente Wert mit dem gelesenen Wert übereinstimmt. Ist dies nicht der Fall, wurde der Datensatz in der Zwischenzeit geändert. Typischerweise müssen die Daten nun neu geladen und die Änderung erneut durchgeführt werden.
Optimistic Locking ohne Rückmeldung an den Nutzer
Bezogen auf unseren Anwendungsfall bedeutet das, dass alle Business-Objekte versioniert werden und das Altsystem als führendes System für das Hochzählen der Version in Folge von Änderungen verantwortlich ist. Jedes vom Altsystem ausgehende Domain-Event beinhaltet auch die aktuelle Version des jeweiligen Business-Objekts. Diese Version wird im Neusystem gespeichert und im Falle eigener Änderungen in den resultierenden Domain-Events mitgeschickt, jedoch ohne hochgezählt zu werden.
In unserem Beispiel ist das Business-Objekt bereits in beiden Systemen in derselben Version vorhanden. Nun wird das Objekt in beiden Systemen geändert. Das Altsystem erhöht die Version und informiert mit einem Domain-Event über die Änderung und die neue Version. Noch bevor das Event im Neusystem verarbeitet wurde, schickt dieses ebenfalls ein Event mit den Daten der Änderung sowie der zu diesem Zeitpunkt vorhandenen Version. Anschließend verarbeitet das Neusystem das Event aus dem Altsystem. Dabei können Änderungen überschrieben werden, die im Neusystem zwischenzeitlich vorgenommen wurden, aber noch nicht mit dem Altsystem synchronisiert waren.
Das Altsystem verarbeitet das Domain-Event aus dem Neusystem und stellt eine parallele Änderung fest, da die Version aus dem Event älter ist als die in der Datenbank. Als Reaktion darauf wird die Verarbeitung des Domain-Events abgelehnt und ein Sync-Event mit dem vollständigen Aggregat an das Neusystem geschickt. Mit den Daten dieses Events wird der komplette Datensatz im Neusystem überschrieben, wodurch die Konsistenz wiederhergestellt ist.
Dieses Vorgehen lässt Inkonsistenzen zu und behebt sie durch Überschreiben der Daten im Cloud-Modul. Von Nachteil ist, dass Änderungen im Cloud-Modul ohne Vorwarnung überschrieben werden und der Anwender ohne es zu bemerken auf veralteten oder sogar inkonsistenten Daten arbeiten kann. Dieses Problem kann abgemildert werden, indem das Nachführen der Änderung am Cloud-Modul im Altsystem als Kommando umgesetzt wird. Damit böte sich die Möglichkeit, den Anwender direkt über die Ablehnung der Anforderung zu informieren. Darüber hinaus könnte das Business-Objekt für weitere Änderungen gesperrt werden, bis die Konsistenz wiederhergestellt ist.
Optimistic Locking mit Rückmeldung an den Nutzer
In Abwandlung zum vorherigen Beispiel wird nach der Änderung im Neusystem nun ein Command statt eines Events an das Altsystem gesendet. Das System kann dem Anwender kenntlich machen, dass die aktuelle Änderung erst nach der Bestätigung durch das Altsystem gültig ist. Das Altsystem lehnt die Änderungsanforderung ab, da eine parallele Änderung erkannt wurde. Das Neusystem verarbeitet die Ablehnung und sperrt das Business-Objekt für weitere Änderungen. Das Neusystem sendet nun ein weiteres Kommando, um einen vollständigen Stand des inkonsistenten Business-Objekts anzufordern. Das Altsystem antwortet mit einem entsprechenden Data-Event, welches im Neusystem verarbeitet wird, wodurch das Business-Objekt überschrieben und wieder für Änderungen freigegeben wird.
Zwar werden bei dieser Variante Änderungen auf veralteten Daten weitestgehend vermieden, jedoch hat dies den Preis, dass Business-Objekte gegebenenfalls für die Bearbeitung gesperrt werden. Darüber hinaus führt das Anfordern von Sperren zu einer engeren Kopplung beider Systeme, die sich auch durch Wartezeiten für den Anwender bemerkbar machen kann. Beides zusammen kann sich negativ auf die Akzeptanz des Neusystems auswirken.
## Zyklische Updates
Ein weiteres Problem, das es zu lösen galt, ist das von zyklischen Updates: Wenn jede Änderung an einem Business-Objekt zu einem Domain-Event führt, welches vom jeweils anderen System verarbeitet wird, wodurch dort ein Business-Objekt geändert wird sodass wieder ein Domain-Event entsteht, können wir leicht in einer Endlosschleife landen.
Ein einfacher Weg, dies zu vermeiden, ist eine global eindeutige Transaktions-Id, die zum Beginn einer jeden Nutzer-Interaktion mit einem System erzeugt wird und mit jedem ausgehenden Event mitgeschickt wird.
Zyklische Updates mit GlobalTransactionIds vermeiden
Im konkreten Beispiel erzeugt das Cloud-Modul zu Beginn einer Nutzer-Anforderung eine neue Transaktions-Id. Wird aufgrund dieser Interaktion ein Business-Objekt geändert, wird ein Domain-Event zunächst in der Outbox-Tabelle gespeichert und anschließend an Kafka gesendet. Das Event trägt die Transaktions-Id im Header.
Das Alt-System verarbeitet nun das Event und kopiert die Transaktions-Id in seinen Ausführungskontext, anstatt selbst eine Transaktions-Id anzulegen. Ist die vom Event getriggerte Aktion durchgeführt, wird wieder ein Domain-Event erzeugt, wieder mit der Transaktions-Id im Header.
Wird nun das Event im Neusystem verarbeitet, wird zunächst die Transaktions-Id aus dem Header gegen die eigene Outbox-Tabelle geprüft. Dabei wird festgestellt, dass die Transaktions-Id bereits in diesem System bekannt ist, es sich also um einen Zyklus handeln muss. Das Event wird verworfen.
Von Nachteil ist, dass sowohl das Alt- als auch das Neusystem in der Lage sein müssen, Transaktions-Ids zu erzeugen und entsprechend zu behandeln. In unserem Falle hätte es einen massiven Eingriff in das Altsystem bedeutet, das zu ermöglichen, weshalb der Ansatz etwas abgewandelt wurde. Statt einer global gültigen Transaktions-Id wurde auf einen Operations-Key zurückgegriffen, der jede Business-Operation eindeutig identifiziert und im Altsystem bereits zu Audit- und Loggingzwecken eingesetzt wurde:
Die Verantwortung für das Vermeiden von Zyklen liegt hier allein beim Altsystem: Es wird sichergestellt, dass bei Aktionen, die als Reaktion auf ein Domain-Event ausgeführt werden, ein anderer Operations-Key gesetzt ist als bei Operationen, die durch eine Nutzerinteraktion angestoßen werden. Bevor ein Event in die Outbox-Tabelle geschrieben wird, wird nun immer anhand des Operations-Keys geprüft, ob es sich um eine neue Interaktion oder eine Reaktion auf ein Event handelt. Für Reaktionen auf ein Event wird kein neues Event in die Outbox geschrieben.
## Fazit
Die Arbeit an dem Projekt hat noch einmal vor Augen geführt, dass die Synchronisation zweier Systeme, die dieselben Daten ändern, herausfordernd sein kann. Zur Vermeidung von Konflikten durch paralleles Arbeiten müssen Kompromisse eingegangen werden.
Ansätze mit Pessimistic Locking bieten einen guten Schutz vor Konflikten, können aber die Akzeptanz der Anwender schmälern. Ansätze mit Optimistic Locking verringern die Auswirkung gesperrter Objekte, stellen die Konsistenz allerdings nur verzögert sicher. Diesen Nachteilen wurde im Projekt begegnet, indem das neue System schrittweise für einzelne Standorte ausgerollt wurde. Aufgrund der getrennten Zuständigkeiten der einzelnen Standorte war die Notwendigkeit für gleichzeitige Änderungen an denselben Datenobjekten in beiden Systemen gering.
Das Projekt zeigt, dass es bei der Synchronisation von Alt- und Neusystemen selten eine universell richtige Lösung gibt. Vielmehr hängt die Wahl des geeigneten Ansatzes von den fachlichen Anforderungen, den technischen Randbedingungen und dem gewünschten Nutzererlebnis ab.
**Kategorien:** Cloud, Development
---
### [Oracle SE2 und moderne Prozessorarchitekturen: Worauf Unternehmen jetzt achten sollten](https://thecattlecrew.net/2026/06/02/oracle-se2-und-moderne-prozessorarchitekturen-worauf-unternehmen-jetzt-achten-sollten/)
**Published:** Juni 2, 2026
**Author:** thecattlecrew
**Content:**
*Interview der Blogredaktion mit Oracle-Lizenzexperte Michael Paege.*
## Michael, es scheint, es gibt Neuigkeiten bei Prozessoren und Hardware-Architekturen im Hause Oracle? Was ist da los?
**Michael Paege:** In den vergangenen Jahren haben sich Prozessorarchitekturen erheblich verändert. Sowohl Intel als auch AMD setzen zunehmend auf Designs, die deutlich mehr Rechenleistung auf gleichem Raum ermöglichen. Für die meisten Unternehmen ist das zunächst eine positive Entwicklung. Im Oracle-Umfeld können diese technischen Veränderungen jedoch unerwartete Auswirkungen auf die Lizenzierung haben.
Gerade bei Oracle Database Standard Edition 2 (SE2) gelten bestimmte Einschränkungen hinsichtlich der Nutzung von CPU-Sockets. Nämlich, dass die DB SE2 nur auf Server mit maximal 2 CPU-Sockets eingesetzt werden darf.
## Und was hat jetzt der CPU-Sockel, also der Steckplatz, mit der darin steckenden CPU zu tun?
**Michael Paege:** Bereits seit 2011 definiert Oracle in seinen Allgemeinen Geschäftsbedingungen (Oracle-Lizenz- und Service-Abkommen (OLSA), (Transaktionales) Oracle Master Agreement ((T)OMA) und Lizenzdefinitionen und Regeln (LDR)) bei Multi-Chip-Modulen, dass jeder Chip auf einem Multi-Chip-Modul einem (belegten) CPU-Socket entspricht.
## Was hat sich bei aktuellen Prozessorgenerationen konkret verändert?
**Michael Paege:** Moderne Prozessoren setzen zunehmend auf sogenannte Chiplet- oder Multi-Die-Architekturen. Dabei besteht ein Prozessor nicht mehr zwingend aus einem einzigen Silizium-Chip, sondern aus mehreren miteinander verbundenen Komponenten.
Solche Multi-Chip-Module gibt es bei der IBM Power Prozessorserie schon sehr lange. Bei AMD sind die Ryzen- und EPYC-Prozessorfamilien ebenfalls schon seit einigen Jahren meist Multi-Chip-Module, und bei Intel trifft man seit der 4. Generation der Xeon-Prozessoren ebenfalls verstärkt auf Multi-Chip-Module.
## **Warum ist das gerade für Oracle Database Standard Edition 2 relevant?**
**Michael Paege:** Oracle SE2 ist bewusst für kleinere und mittlere Datenbankumgebungen positioniert. Deshalb sind die Nutzungsmöglichkeiten der Hardware/CPUs gegenüber der Enterprise Edition eingeschränkt.
Diese Einschränkung besteht – neben der in der DB SE2 Software vorhandenen Einschränkung auf die Nutzung von maximal 16 Threads für Datenbankprozesse – hauptsächlich in der oben bereits erwähnten Begrenzung auf Server, die maximal 2 CPU-Sockel haben dürfen. Hat ein Server beispielsweise 2 SPU-Sockel, von denen ein CPU-Sockel mit einer CPU mit zwei Chips gefüllt ist, dann hat dieser Server nach den aktuellen Oracle-Regeln drei CPU-Sockel: 1 gefüllter Sockel mit 2 Chips, also 2 Sockel plus ein leerer Sockel, in Summe also drei Sockel. Und darauf darf eine DB SE2 nicht eingesetzt werden.
Wenn neue Hardwaregenerationen eingeführt werden, stellt sich regelmäßig die Frage, wie diese Systeme unter den bestehenden Lizenzregeln einzuordnen sind. Unternehmen müssen sicherstellen, dass die eingesetzte Hardware weiterhin mit den Vorgaben von Oracle kompatibel ist und keine unerwarteten Lizenzrisiken entstehen.
## **Welche Risiken siehst du aktuell für Unternehmen?**
**Michael Paege:** Das größte Risiko besteht darin, Hardware ausschließlich aus technischer Perspektive auszuwählen. Viele Unternehmen betrachten Performance, Energieeffizienz oder Anschaffungskosten, ohne die Oracle-Lizenzierung frühzeitig einzubeziehen.
Im ungünstigsten Fall wird eine neue Plattform beschafft und erst später festgestellt, dass die geplante Nutzung lizenzrechtlich problematisch oder wirtschaftlich nachteilig ist. Die Kosten für nachträgliche Anpassungen können erheblich sein.
## **Betrifft das nur neue Oracle-Kunden oder auch bestehende Installationen?**
**Michael Paege:** Das betrifft neue und bestehende Kunden gleichermaßen. Bestehende Kunden haben aber ggf. ein höheres Risiko, weil solche neuen Regelungen beim einfachen Hardwaretausch schnell mal übersehen werden.
Eine Plattform, die vor einigen Jahren problemlos eingesetzt werden konnte, ist nicht automatisch mit heutigen Architekturen vergleichbar. Deshalb empfiehlt es sich, vor einer Beschaffung sowohl die technische als auch die lizenzrechtliche Bewertung vorzunehmen.
## **Welche typischen Fehler beobachtest du in der Praxis?**
**Michael Paege:** Ein häufiger Fehler besteht darin, Oracle-Lizenzexperten erst sehr spät in Infrastrukturentscheidungen einzubeziehen. Oft wird zunächst die Hardware ausgewählt, im schlimmsten Fall sogar schon bestellt, und erst danach geprüft, welche Auswirkungen dies auf die Lizenzierung hat.
Ein weiterer Fehler ist die Annahme, dass sich neue Prozessorgenerationen automatisch identisch zu ihren Vorgängern verhalten. Gerade bei grundlegenden Architekturänderungen sollte man genau hinschauen.
## **Was empfiehlst du Organisationen, die aktuell neue Datenbankserver planen?**
**Michael Paege:** Ich empfehle, die Lizenzperspektive frühzeitig in die Planung einzubeziehen. Idealerweise werden Infrastruktur-, Datenbank- und Lizenzexperten bereits in der Evaluierungsphase eingebunden. So lassen sich spätere Überraschungen vermeiden und Unternehmen können eine Lösung auswählen, die sowohl technisch als auch wirtschaftlich sinnvoll ist.
## **Welche Fragen sollten IT-Verantwortliche vor einer Hardwarebeschaffung stellen?**
**Michael Paege:**
Wichtige Fragen sind beispielsweise:
- Welche Prozessorarchitektur wird eingesetzt?
- Gibt es Besonderheiten bei der Anzahl von Dies, Chiplets oder Sockeln?
- Welche Auswirkungen ergeben sich für Oracle SE2?
- Gibt es bereits Erfahrungen aus vergleichbaren Projekten?
- Welche langfristigen Lizenzkosten entstehen durch die gewählte Plattform?
Je früher diese Fragen beantwortet werden, desto sicherer fällt die Investitionsentscheidung aus.
Und wichtig: Laut Oracle sind alle Intel Xeon-Prozessoren der 6. Generation nicht für die DB SE2 geeignet.
## **Erwartest du weitere Veränderungen in diesem Bereich?**
**Michael Paege:** Die Entwicklung moderner Prozessoren schreitet sehr schnell voran. Deshalb ist davon auszugehen, dass Unternehmen auch künftig regelmäßig neue technische Konzepte bewerten müssen.
Für Oracle-Kunden bedeutet das, Hardwareentscheidungen nicht isoliert zu betrachten, sondern immer im Zusammenspiel mit Lizenzierung, Compliance und langfristiger Betriebsstrategie.
## **Über Michael Paege**
**Michael Paege** verfügt über mehr als 30 Jahre Erfahrung im Umfeld der Oracle-Lizenzierung. Gemeinsam mit unseren Datenbankexperten informiert er jährlich in umfassenden Lizenz-Webinaren über die neuesten Entwicklungen bei Oracle. Er engagiert sich bei der Deutschen Oracle Anwendergruppe, hält Vorträge und betreibt einen eigenen Blog. Bei **OPITZ CONSULTING Systems** arbeitet er als Senior Manager Cloud & Compliance und berät Unternehmen und Behörden jeder Größe zu Lizenzfragen.
**Kategorien:** Database, Infrastructure
**Schlagwörter:** oracle, Oracle DB
---
### [Die Nachtwache: Rufbereitschaft für IT-Profis](https://thecattlecrew.net/2026/06/09/rufbereitschaft-fuer-profis/)
**Published:** Juni 9, 2026
**Author:** Mateusz Mis
**Content:**
Wenn Produktionssysteme rund um die Uhr laufen, müssen auch die Menschen dahinter jederzeit handlungsfähig sein. Genau dafür gibt es die Rufbereitschaft. Sie ist ein wichtiger Bestandteil des Betriebs und sorgt dafür, dass kritische Systeme auch außerhalb der regulären Arbeitszeiten zuverlässig unterstützt werden können.
## **Die Realität hinter dem Diensttelefon**
4:00 Uhr morgens, Samstagnacht. Ich schlafe nicht – nichts Neues. Seit Dienstag habe ich keine einzige Nacht durchgeschlafen, ohne aus dem Bett aufspringen zu müssen. Über das Diensttelefon spreche ich mit einem Anwender „unserer“ Produktionssysteme und versuche zu verstehen, warum ein Problem, das seit Donnerstagmorgen besteht, erst am Samstag um 4:00 Uhr morgens an unser Team eskaliert wurde – als etwas, das unter keinen Umständen warten kann.
**„Darauf kann ich nicht antworten, ich weiß es nicht. Eigentlich ist es keine Priorität, es kann problemlos bis Montag warten“,** behauptet mein Gesprächspartner, übrigens sehr freundlich im Ton und in seiner Ausdrucksweise.
## **Einstellung ist key**
Manche von euch würden sich vielleicht ärgern, und vielleicht hätten sie sogar das Recht dazu. **„Warum holen sie mich mitten in der Nacht aus dem Bett?“** Ich sehe das anders. Ich fühle eher Erleichterung und ein Gefühl der Erfüllung einer wichtigen Pflicht. Schließlich ist es meine Aufgabe, das Funktionieren der Systeme sicherzustellen. Außerdem helfe ich gerne in schwierigen Situationen und löse Probleme – und genau damit haben wir es hier zu tun. Manchmal besteht eine gut ausgeführte „**Aktivierung**“ nicht ausschließlich darin, einen Incident zu lösen, sondern darin, mit dem Betrieb die verfügbaren Optionen zu besprechen, das Problem selbst sowie seine Auswirkungen auf die Systeme zu analysieren. Oft gehört dazu auch eine gewisse verbale Unterstützung, die paradoxerweise einen großen Einfluss auf die gesamte Situation hat – aber dazu gleich mehr.
Jede Meldung, die die Rufbereitschaft erreicht, ist ein Signal dafür, dass irgendwo etwas nicht so funktioniert, wie es sollte. Manchmal kann die Rechtmäßigkeit solcher Meldungen in der Eskalationskette nicht überprüft werden, bevor nicht jemand mit entsprechender Erfahrung und dem nötigen Wissen erscheint, um die Situation objektiv zu beurteilen – das ist unsere Rolle.
## **Gefährdung der Produktionskontinuität**
Wie wichtig die Rufbereitschaft für unser Projekt ist, ist auf den ersten Blick vielleicht nicht offensichtlich. Was kann schon passieren? Bekommt jemand die angeforderten Berechtigungen nicht? Kann sich jemand nicht in ein System einloggen? Ja – und nein. Das Thema ist viel komplexer, deshalb gehen wir kurz ins Detail.
Grundsätzlich hat jede Meldung, die außerhalb der Bürozeiten an unser Team eskaliert wird, einen direkten Einfluss auf die Kontinuität von Produktions- und Logistikprozessen des Kunden. Die gemeldeten Vorfälle können (müssen aber nicht) direkt die Stabilität industrieller Systeme gefährden – von der eigentlichen Stahlproduktion bis hin zu Logistik und Planung. Wir sind also in jeden wichtigen Prozess eingebunden, der den reibungslosen Ablauf beeinflusst.
Hinter jeder erfolgreichen Rufbereitschaft steht letztlich ein klares Ziel: die Sicherstellung stabiler Produktions- und Logistikprozesse. Für Unternehmen wie thyssenkrupp Steel bedeutet das, Produktionsausfälle zu vermeiden, Lieferketten aufrechtzuerhalten und wirtschaftliche Risiken zu minimieren.
In einem so großen Unternehmen wie thyssenkrupp Steel kann jede Verzögerung potenziell katastrophale Folgen haben, was sich natürlich auch negativ auf unser Projekt auswirken würde.
## Erfahrung schlägt Handbuchwissen
Die Probleme, die uns erreichen, sind daher sehr unterschiedlich. Deshalb können wir hier im Incident Management nicht von standardisierten SOP-Lösungen sprechen. Der Schein kann trügen. Trotz des Namens MES/FLS passt die Zahl der Systeme, die wir überwachen, nicht einmal auf die Finger beider Hände – und FLS ist nur der zentrale Teil dieser Landschaft.
Manchmal erreichen uns auch Meldungen aus Systemen, die wir gar nicht betreuen. Für die meldenden Nutzer ist das meist unwichtig – „**Ich kenne nur diese Telefonnummer und brauche Hilfe**“. Für sie vereinfacht das die Arbeit, für uns erschwert es sie deutlich. Aber irgendetwas lässt sich immer tun: Informationen in Datenbanken suchen, Punkte in JIRA durchsehen und dem Nutzer raten, an wen er sich wenden sollte – schließlich sitzen wir alle im selben Boot.
Multiplizieren wir also die Anzahl der Systeme mit einer noch größeren Zahl möglicher Störungen und ihrer Schnittpunkte – von Servern bis hin zu spezialisierten Programmen zur Verarbeitung bestimmter Aktionen innerhalb eines Systems. Dazu kommen menschliche Fehler und Fehlalarme, und langsam offenbart sich uns ein ganzer Ozean von Möglichkeiten, in dem wir jede Nacht waten, um herauszufinden, wo etwas nicht funktioniert, wer Zugriff darauf hat und wer es nachts beheben kann (falls wir es nicht selbst sind).
## **Die Last der Verantwortung**
Wie man sieht, ist das alles gar nicht so einfach, wie es auf den ersten Blick erscheinen mag. Deshalb sprechen wir in unserem Team von einer Einarbeitungsphase im Projekt, die mehrere Monate bis hin zu einem Jahr dauern kann. Erst danach kann eine neue Person beginnen, sogenannte „Rufbereitschaften oder RBs“ zu übernehmen und selbstständig Entscheidungen zu treffen, die direkten Einfluss auf die industriellen Prozesse des Kunden haben.
Ich muss euch wohl nicht erklären, welche psychische Belastung es bedeutet, wenn man als neuer Mitarbeiter eine ganze Woche lang (Montag 17:00 Uhr bis Montag 8:00 Uhr – außerhalb der Bürozeiten) mit dem Gedanken konfrontiert ist, dass nun der gesamte Service auf den eigenen Schultern liegt und man in jeder Situation und zu jeder Uhrzeit zurechtkommen muss. Ich erinnere mich jedoch gut daran, wie stressig meine ersten Bereitschaften waren.
Zur Klarstellung: In den meisten dieser Systeme sind wir Administratoren, sodass jede falsche Entscheidung schwerwiegende Folgen haben und große Verluste verursachen kann. Deshalb müssen wir vor allem vorsichtig und zurückhaltend handeln. Natürlich gibt es Bereiche mit klaren Prozessen und festen Abläufen – dort können wir ohne Zögern handeln. Viele Fälle sind jedoch reine Improvisation, und auch das muss man lernen.
Natürlich sind wir nicht völlig auf uns allein gestellt – es gibt weitere Eskalationswege, und der gesamte Prozess ist sehr gut aufgebaut. Doch angesichts der Vielzahl an Themen, mit denen wir konfrontiert werden, stellt sich immer wieder die Frage: „**Muss ich wirklich noch eine weitere Person aus dem Bett holen und zusätzlichen Aufwand verursachen**?“ oder „**Ist das überhaupt die richtige Person, die mir hier helfen kann?**“
Und damit kommen wir zurück zum wichtigsten Punkt – der Erfahrung. Sie ist der Grund, warum man uns so schwer ersetzen kann. Das Wissen, das wir über Jahre hinweg sammeln, ist hier ein unverzichtbares Element.
## **30 Minuten Reaktionszeit – jederzeit**
Der Bereitschaftsdienst ist heute eine anstrengende, aber zweifellos wichtige Pflicht in unserem Projekt. Zwar ermöglicht die über Jahre gesammelte Erfahrung meist eine schnelle Identifikation des Problems und möglicher Lösungswege, dennoch bleibt eine gewisse „Bindung“ an das Diensttelefon bestehen.
Das hängt sicherlich von der Person ab, aber für mich ist es erwähnenswert, weil es nicht für jeden selbstverständlich ist. Unser SLA beträgt 30 Minuten. Das bedeutet, dass ich nach der Eskalation eines Incidents 30 Minuten Zeit habe, um zum Computer zu gelangen, mich in die Systeme einzuloggen und den Status eines Tickets in JIRA zu ändern.
Wie ihr euch sicher vorstellen könnt, schränkt das die Freiheit, seine Freizeit außerhalb der Bürozeiten zu gestalten, erheblich ein. Nicht jeder möchte schließlich überall mit einem mobilen Hotspot und einem Dienstlaptop unterwegs sein. Zum Glück dauert eine Bereitschaftsperiode nur sieben Tage – danach wechseln wir uns ab.
## Wertschätzung macht einen Unterschied
Diese Arbeitsweise hat sicherlich ihre Vor- und Nachteile. Auf jeden Fall ist es keine Arbeit für jeden. Persönlich sehe ich darin jedoch eher eine Herausforderung und eine Gelegenheit, mein Wissen und meine Erfahrung einzusetzen, um jemandem zu helfen.
Vor Kurzem ist mir etwas sehr Nettes passiert. Für die Nutzer ist es meist selbstverständlich, dass irgendwo jemand sitzt und nachts bereit ist, ihre Zweifel auszuräumen oder ein System zu reparieren – schließlich ist es seine Arbeit. Und natürlich nehme ich das niemandem übel.
Bei einer der letzten „Aktivierungen“ sagte mir jedoch ein Nutzer während unseres Gesprächs, dass er die Arbeit der Menschen, die solche Bereitschaftsdienste leisten, sehr respektiert und sich sehr für die Unterstützung bedankt.
In einer idealen Welt wäre das vielleicht selbstverständlich, doch in Wirklichkeit hören wir so etwas nur selten. Umso mehr hat es mich gefreut. Es ist schön zu wissen, dass das, was wir tun, nicht nur als Selbstverständlichkeit und Pflicht gesehen wird, sondern auch als etwas, das wir von uns ausgeben.
Deshalb habe ich vorher die verbale Unterstützung erwähnt. Es ist gut, dem Nutzer zu vermitteln, dass ich nicht nur hier bin, weil ich muss, sondern weil ich helfen möchte – und das ist ein großer Unterschied. Wenn wir mit dieser Einstellung an die Sache herangehen, wird die Arbeit angenehmer und bringt bessere Ergebnisse.
Rufbereitschaft bedeutet mehr als technische Unterstützung außerhalb der Bürozeiten. Sie bedeutet Verantwortung für geschäftskritische Prozesse, schnelle Entscheidungen unter Druck und die Bereitschaft, Menschen in schwierigen Situationen zu helfen. Genau diese Kombination macht den Unterschied – für unsere Kunden und für den Erfolg ihrer Systeme.
**Kategorien:** Infrastructure, IT-Security
**Schlagwörter:** Administration, AdminServer, Agile Methode, Apps, Architecture, Articles, responsibility, Zusammenarbeit
---
### [Databricks verstehen – Teil 4: Gegenüberstellung der Ansätze und Fazit](https://thecattlecrew.net/2026/03/12/databricks-verstehen-teil-4-fazit/)
**Published:** März 12, 2026
**Author:** Maximilian Wilhelmi
**Content:**
## Gegenüberstellung der Ansätze und Fazit
Moderne Datenplattformen stehen vor der Herausforderung, stetig wachsende Datenmengen aus unterschiedlichsten Quellen zuverlässig, reproduzierbar und skalierbar zu verarbeiten. In diesem Kontext haben sich Cloud Data Warehouses, Lakehouse-Architekturen und ELT-Ansätze als Quasi-Standard etabliert. Zwei Werkzeuge, die dabei häufig genannt werden, sind Delta Live Tables (DLT) von Databricks und dbt (data build tool). Obwohl beide Frameworks im selben technologischen Umfeld eingesetzt werden, verfolgen sie unterschiedliche Ziele und adressieren klar getrennte Problemstellungen.
In der Praxis entsteht dennoch oft Verwirrung: DLT und dbt werden miteinander verglichen oder als Alternativen betrachtet. Tatsächlich handelt es sich um grundlegend unterschiedliche Tools, die jeweils für eigene Aufgabenbereiche konzipiert wurden. Dieser Blogartikel stellt beide Frameworks gegenüber, grenzt sie sauber voneinander ab, beleuchtet Vor- und Nachteile und schließt mit einem praxisnahen Fazit.
## Einordnung im modernen Datenstack
Um DLT und dbt sinnvoll zu vergleichen, ist zunächst eine Einordnung im typischen Datenverarbeitungsprozess notwendig. Dieser beginnt bei operativen Datenquellen wie Applikationsdatenbanken, SaaS-Tools, APIs oder Event-Streams. Anschließend werden die Daten in eine zentrale Datenplattform geladen, dort transformiert, angereichert und schließlich für Analytics, Reporting oder Machine-Learning-Anwendungen bereitgestellt.
Delta Live Tables (DLT) ist vor allem auf Dateningestion und Pipeline-Orchestrierung ausgelegt. Das Framework unterstützt dabei, Daten aus unterschiedlichen Quellsystemen zuverlässig zu erfassen, zu validieren und in ein Zielsystem wie ein Databricks-Data-Lakehouse zu laden. Als vollständig in Databricks integriertes Managed-Framework auf Basis von Spark bietet DLT automatisierte Funktionen für Schema-Evolution, Inkrementalität und Monitoring, die den Aufbau stabiler Pipelines erleichtern.
dbt hingegen konzentriert sich stärker auf Transformation, Modellierung und Qualitätssicherung der bereits vorhandenen Daten. In der Praxis können sich die Aufgabenbereiche von DLT und dbt teilweise überschneiden, insbesondere wenn Transformationen oder Validierungen bereits während der Ingestion notwendig sind. Grundsätzlich bleibt jedoch der Unterschied bestehen: DLT legt den Schwerpunkt auf die technische Bereitstellung und Stabilität der Datenpipelines, während dbt stärker auf fachliche Modellierung, Tests und Dokumentation fokussiert ist.
## DLT – Fokus auf robuste Datenpipelines in Databricks
Delta Live Tables ist ein proprietäres Managed-Framework von Databricks, das speziell für den Aufbau stabiler, skalierbarer und wartbarer Datenpipelines entwickelt wurde. Es ermöglicht, Pipelines deklarativ zu definieren, und automatisiert viele technische Details – wie die Anpassung an Schemaänderungen, inkrementelle Verarbeitung und Monitoring – direkt im Spark-Umfeld.
Ein wesentliches Merkmal von DLT ist das integrierte State- und Schema-Management. Ändert sich beispielsweise die Struktur einer Datenquelle, kann DLT die Änderung erkennen, entsprechende Anpassungen durchführen und die Pipeline ohne manuelle Eingriffe fortsetzen. Dadurch wird der Wartungsaufwand deutlich reduziert, insbesondere bei komplexen oder dynamischen Datenquellen.
DLT-Pipelines werden in Databricks typischerweise über Python oder SQL definiert und lassen sich direkt in die Spark- und Lakehouse-Umgebung integrieren. Typische Einsatzszenarien sind das Laden von API-Daten, die Replikation operativer Datenbanken oder die Befüllung von Raw- bzw. Bronze-Schichten in einem Lakehouse. DLT legt den Fokus bewusst auf robuste Datenbereitstellung und Qualitätssicherung.
## dbt – Transformation und fachliche Modellierung
Im Gegensatz dazu versteht sich dbt als Werkzeug für die Transformation von Daten innerhalb des Data Warehouses. dbt folgt dem Prinzip „Transform data where it lives“ und verzichtet vollständig auf eigene Extraktions- oder Ladefunktionen. Stattdessen werden Transformationen als SQL-Modelle definiert, die direkt im Zielsystem ausgeführt werden.
Die Stärke von dbt liegt in der strukturierten Modellierung von Daten. Rohdaten werden zunächst in Staging-Modellen bereinigt und vereinheitlicht, anschließend in fachliche Kernmodelle überführt und schließlich zu analytischen Marts aggregiert. Dieser schichtweise Ansatz fördert Übersichtlichkeit, Wiederverwendbarkeit und eine klare Trennung zwischen technischer und fachlicher Logik.
Ein weiterer zentraler Aspekt von dbt ist die Datenqualität. Über Tests lassen sich Annahmen wie Eindeutigkeit, Nicht-Null-Werte oder referenzielle Integrität direkt im Entwicklungsprozess absichern. Ergänzt wird dies durch automatisch generierte Dokumentation und eine transparente Abhängigkeitsdarstellung, die den gesamten Transformationspfad nachvollziehbar macht.
## Abgrenzung und Vergleich
DLT und dbt unterscheiden sich grundlegend in Zielsetzung und Einsatzgebiet. DLT ist ein Werkzeug für den technischen Aufbau von Datenpipelines und adressiert in erster Linie die zuverlässige Erfassung und Bereitstellung von Daten aus operativen Quellsystemen. Der Schwerpunkt liegt dabei auf Stabilität, Wiederholbarkeit und dem Umgang mit technischen Herausforderungen wie Inkrementalität, Fehlertoleranz und Schemaänderungen.
dbt verfolgt hingegen einen deutlich anderen Ansatz. Es ist kein Pipeline- oder Ingestion-Framework, sondern ein Modellierungs- und Transformationswerkzeug, das ausschließlich innerhalb des Data Warehouses operiert. dbt setzt voraus, dass Daten bereits in strukturierter Form vorliegen, und konzentriert sich auf deren fachliche Interpretation, Qualitätsabsicherung und Dokumentation.
Auch aus technologischer Sicht sind beide Tools klar voneinander zu trennen. DLT ist Python-basiert und im klassischen Data-Engineering-Umfeld verankert, in dem Themen wie Datenzugriff, Orchestrierung und technische Robustheit im Vordergrund stehen. dbt hingegen ist SQL-zentriert und richtet sich an Rollen, die nahe an Fachlichkeit und Analytics arbeiten. Die Wahl zwischen DLT und dbt ist daher weniger eine Frage der Kombination, sondern vielmehr eine Frage danach, welches Problem im jeweiligen Kontext gelöst werden soll.
## Vorteile und Grenzen von DLT
DLT überzeugt insbesondere durch seine Robustheit und den hohen Grad an Automatisierung bei der Dateningestion. Änderungen an Datenquellen lassen sich häufig ohne manuelle Eingriffe verarbeiten, was den operativen Aufwand reduziert und die Stabilität der Ladeprozesse erhöht. Der Python-basierte Ansatz ermöglicht zudem eine hohe Flexibilität, insbesondere beim Umgang mit komplexen, heterogenen oder schwer standardisierbaren Datenquellen.
Gleichzeitig ist DLT bewusst auf den Bereich der Dateningestion fokussiert und erhebt nicht den Anspruch, ein umfassendes Framework für analytische oder fachliche Transformationen zu sein. Weitergehende Logik, Kennzahlenberechnungen oder semantische Modellierung können daher entweder in nachgelagerten Werkzeugen oder – abhängig von Plattformstrategie und Teamkompetenzen – auch innerhalb eines Spark-basierten oder vergleichbaren Ökosystems umgesetzt werden. In Umgebungen, die bereits stark auf Spark oder Lakehouse-Technologien ausgerichtet sind, kann es sinnvoll sein, Transformationen bewusst dort zu bündeln, statt zusätzliche spezialisierte Tools einzuführen. Die Abgrenzung von DLT ist in diesem Sinne weniger als Einschränkung zu verstehen, sondern als Einladung zu einer bewussten architektonischen Entscheidung.
## Vorteile und Grenzen von dbt
Die größte Stärke von dbt liegt in der klaren Strukturierung von Transformationen und Business-Logik. Durch Versionierung, Tests und Dokumentation wird Datenmodellierung zu einem echten Software-Engineering-Prozess. Dies erhöht Transparenz, Qualität und Vertrauen in die Daten.
Gleichzeitig ist dbt vollständig auf vorgelagerte Ingestion angewiesen. Ohne saubere, stabile Rohdaten kann dbt seine Stärken nicht ausspielen. Zudem kann sehr komplexe Logik in SQL schnell unübersichtlich werden, insbesondere wenn prozedurale Verarbeitung notwendig wäre.
## Zusammenspiel in der Praxis
In modernen Datenplattformen kann der kombinierte Einsatz von DLT und dbt eine mögliche Architekturvariante darstellen. In einer solchen Konstellation wird DLT häufig für den Aufbau und Betrieb der Ladeprozesse genutzt und stellt die extrahierten Daten in einer Raw- oder Bronze-Schicht bereit. dbt kann darauf aufbauend eingesetzt werden, um diese Daten weiterzuverarbeiten und schrittweise in fachlich strukturierte und analytisch nutzbare Datenmodelle zu überführen.
Diese Aufteilung orientiert sich an einer Trennung zwischen technischer Dateningestion und fachlicher Transformation, ohne jedoch als allgemeingültige Referenzarchitektur verstanden werden zu müssen. Ob ein solches Vorgehen sinnvoll ist, hängt stark ab
- von organisatorischen Rahmenbedingungen,
- Teamzuschnitten
- und der Komplexität der Datenquellen.
In Umgebungen, in denen technische Stabilität und fachliche Weiterentwicklung voneinander entkoppelt werden sollen, kann dieser Ansatz Vorteile bieten. Änderungen an Datenquellen lassen sich dabei tendenziell auf die DLT-Pipelines begrenzen. Fachliche Anpassungen dagegen können unabhängig davon in dbt-Modellen umgesetzt werden.
Gleichzeitig sollte berücksichtigt werden, dass der Betrieb einer solchen Kombination von Tools sorgfältige Pflege, Beherrschung und Wartung erfordert. Beide Frameworks müssen von den Teams verstanden und regelmäßig überwacht werden, um eine zuverlässige Datenbereitstellung zu gewährleisten. Dies umfasst nicht nur die technische Umsetzung, sondern auch die kontinuierliche Anpassung an sich ändernde Datenquellen, Versionsupdates, Monitoring, Alerting und Teststrategien. Auch organisatorische Aspekte wie klare Verantwortlichkeiten, Schulung und Dokumentation spielen hier eine wichtige Rolle.
Kurz gesagt: Die Kombination aus DLT und dbt kann eine leistungsfähige Datenarchitektur unterstützen, sie setzt aber voraus, dass die jeweiligen Werkzeuge konsequent betrieben und weiterentwickelt werden. Ohne eine solche Pflege kann auch eine technisch solide Architektur schnell an ihre Grenzen stoßen.
## Fazit
DLT und dbt adressieren unterschiedliche Aspekte der Datenverarbeitung und sollten daher nicht primär als konkurrierende Werkzeuge verstanden werden. Der Schwerpunkt dieses Vergleichs liegt jedoch klar auf der Rolle von DLT als Fundament moderner Datenplattformen. Durch den Fokus auf robuste, wartbare und weitgehend automatisierte Dateningestion eignet sich DLT insbesondere für den Aufbau stabiler Datenpipelines. Vor allem in Umgebungen, in denen Daten aus vielen, sich verändernden Quellen integriert werden müssen.
Gleichzeitig ist DLT nicht die einzige Option für diesen Teil des Datenstacks. Abhängig von Anforderungen an Skalierung, Performance und Komplexität können auch Frameworks wie Apache Spark oder Spark-basierte Lakehouse-Ansätze eine sinnvolle Alternative darstellen. Insbesondere wenn umfangreiche Transformationen, Streaming-Szenarien oder sehr große Datenvolumina bereits früh im Verarbeitungsprozess notwendig sind.
Welche Architektur letztlich geeignet ist, hängt dabei nicht nur von technischen Kriterien ab, sondern maßgeblich vom organisatorischen Umfeld. Die vorhandenen Kompetenzen im Team spielen eine zentrale Rolle: In Organisationen mit starker SQL- und Analytics-Ausrichtung können warehouse-zentrierte Ansätze naheliegen. Hingegen profitieren Python- oder Data-Engineering-lastige Teams häufig von ingestion-zentrierten oder Spark-basierten Lösungen. Ebenso macht es einen Unterschied, ob eine Datenplattform auf der „grünen Wiese“ neu aufgebaut wird oder ob bestehende Strukturen, Prozesse und Tools berücksichtigt werden müssen.
Eine nachhaltige Datenarchitektur entsteht daher weniger durch die Wahl eines bestimmten Tools als durch eine bewusste Abwägung von Anforderungen, Teamfähigkeiten und Ausgangslage. DLT kann in diesem Kontext eine tragende Rolle einnehmen. Zum einen als eigenständiges Ingestion-Framework zum anderen als Bestandteil eines umfassenderen, individuell zugeschnittenen Datenökosystems.
## Mehr aus dieser Blogserie
**Teil 1:** [Medaillon-Architektur, Delta Live Tables und dbt in der Praxis](https://thecattlecrew.net/2026/01/15/databricks-verstehen-teil-1-medaillon-architektur-delta-live-tables-und-dbt-in-der-praxis/)
**Teil 2:** [Was ist Databricks? Was bietet mir das Tool?](https://thecattlecrew.net/2026/02/06/databricks-verstehen-teil-2-was-ist-databricks-was-bietet-mir-das-tool/)
**Teil 3:** [Was ist DBT und warum ist es für moderne Datenpipelines so wichtig?](https://thecattlecrew.net/?p=40947&preview=true)
**Teil 4:** [Gegenüberstellung der Ansätze und Fazit](https://thecattlecrew.net/2026/03/12/databricks-verstehen-teil-4-fazit/)
Viel Spaß beim Lesen!
**Kategorien:** Analytics & Insights, Architecture & Process Models
---
### [Databricks verstehen – Teil 3: Was ist DBT und warum ist es für moderne Datenpipelines so wichtig?](https://thecattlecrew.net/2026/03/05/databricks-verstehen-teil-3-was-ist-dbt-und-warum-ist-es-fuer-moderne-datenpipelines-so-wichtig/)
**Published:** März 5, 2026
**Author:** Maximilian Wilhelmi
**Content:**
## Was ist dbt und was bietet mir das Tool?
Data Build Tool (dbt), ist ein Open-Source-Framework, das entwickelt wurde, um den Prozess der Datenmodellierung, -transformation und -pflege in modernen Data Warehouses zu vereinfachen und zu optimieren. Es basiert auf SQL und ermöglicht es Datenanalysten und Data Engineers, einfache bis komplexere Datenpipelines zu gestalten. Das Hauptziel von dbt ist es, die Kluft zwischen Datenanalyse und Datenentwicklung zu überbrücken, indem es eine strukturierte Umgebung schafft, in der Transformationen nachvollziehbar dokumentiert, getestet und wiederverwendet werden können.
## Hier einige zentrale Vorteile:
**Automatisierte Daten-Transformationen:** Mit dbt kannst du deine Datenmodelle in SQL definieren, die dann automatisiert ausgeführt werden. Das reduziert manuelle Eingaben, minimiert Fehler und sorgt für konsistente Ergebnisse.
**Transparenz und Nachvollziehbarkeit:** Alle Transformationen werden dokumentiert, was eine klare Übersicht über den Datenfluss ermöglicht. Dadurch kannst du jederzeit nachvollziehen, wie Daten entstehen und sich entwickeln.
**Qualitätssicherung durch Tests:** dbt unterstützt die Implementierung von Tests, um die Integrität und Korrektheit deiner Daten sicherzustellen. Fehler werden frühzeitig erkannt, was die Zuverlässigkeit deiner Analysen erhöht.
**Modularität und Wiederverwendbarkeit:** Datenmodelle können in Komponenten aufgebaut werden, die leicht wiederverwendet und angepasst werden können. Das erleichtert die Pflege und Weiterentwicklung deiner Datenpipelines erheblich.
**Integration in moderne Data-Stacks:** dbt lässt sich nahtlos in gängige Data-Warehouse-Lösungen wie Snowflake, Databricks, BigQuery, Redshift und andere integrieren, was eine flexible Nutzung in verschiedenen Umgebungen ermöglicht.
## Aktive Community und kontinuierliche Weiterentwicklung
Als Open-Source-Projekt profitiert dbt von einer lebendigen Community, die regelmäßig neue Funktionen, Best Practices und Support bereitstellt. Aber auch eine kostenpflichtige Cloud Version ist verfügbar und nicht nur ein Tool zur Datenmodellierung, sondern eine umfassende SaaS-Plattform, die den gesamten Datenentwicklungsprozess in der Cloud vereinfacht, beschleunigt und absichert. Für Unternehmen, die auf Skalierbarkeit, Zusammenarbeit und Automatisierung setzen, kann die kostenpflichtige Version eine wertvolle Investition.
**Kurz gesagt:** dbt ist ein Tool für moderne Datenprojekte, das dir helfen kann, saubere, nachvollziehbare und wartbare Datenpipelines zu erstellen. Es fördert eine Kultur der Transparenz und Qualität in der Datenentwicklung und trägt dazu bei, datengetriebene Entscheidungen effizienter zu treffen.
## Einrichtung der Verbindung zwischen dbt und Databricks
Für unser Projekt haben wir eine Verbindung zwischen dbt und Databricks eingerichtet. Die Entwicklung und Strukturierung der Datenmodelle erfolgt dabei in dbt, während Databricks als skalierbare Ausführungsumgebung für die Transformationen dient.
Technisch wird die Integration über den dbt-databricks-Adapter realisiert. Dieser ermöglicht es dbt, SQL-Modelle in Databricks auszuführen und dort Tabellen oder Views im jeweiligen Lakehouse zu materialisieren.
Für die Authentifizierung haben wir in Databricks einen Personal Access Token erstellt. Dieser Token dient ausschließlich zur Authentifizierung und ermöglicht es dbt, sich gegenüber Databricks zu legitimieren und eine Verbindung aufzubauen.
Alternativ stehen weitere Authentifizierungsmethoden zur Verfügung, beispielsweise:
- Azure Active Directory (Azure AD) Authentifizierung
- Service Principal mit OAuth 2.0
- JDBC/ODBC-Verbindungen mit entsprechenden Zugangsdaten
Welche Methode geeignet ist, hängt von der jeweiligen Infrastruktur, den Sicherheitsanforderungen und organisatorischen Vorgaben ab. Auf eine detaillierte Gegenüberstellung verzichten wir an dieser Stelle und konzentrieren uns im Folgenden auf die tokenbasierte Authentifizierung in unserem Beispiel.
## Vorbereitungen für dbt
Als erstes haben wir den dbt-Adapter für Databricks installiert. Dieser installiert auch gleichzeitig das Grundpaket von dbt mit, sollte dies noch nicht vorhanden sein. Als nächsten Schritt haben wir die Verbindungen aus Databricks in unsere profiles.yml eingetragen:
*Abbildung 1: Profiles*
Zur Überprüfung der eingerichteten Verbindung kann im Terminal der Befehl `dbt debug` ausgeführt werden. Dieser prüft, ob die Konfiguration korrekt ist und ob sich dbt erfolgreich mit Databricks verbinden kann.
Nach erfolgreicher Validierung konnten wir mit der Entwicklung und Ausführung unserer Datenmodelle beginnen.
## Unser Projekt und die Umsetzung
#### Allgemeiner Überblick
In unserem Projekt setzen wir auf eine automatisierte Datenpipeline, die vom Rohdatenimport im Bronze Layer bis zur finalen Verarbeitung im Gold Layer reicht. Hierbei versuchen wir auf die einzelnen Funktionen und Grenzen von dbt einzugehen. Auch nicht benutze Funktionen innerhalb der Demonstration haben wir uns angeschaut und werden dies im Blog beschreiben. Für unser Projekt lassen wir 5 verschieden CSV-Dateien laden und verarbeiten diese in den bekannten Layer Bronze, Silver und Gold. Anschließend schauen wir uns das Einbinden in Databricks-Workflows an, da diese Funktion in dbt nicht zur Verfügung steht.
*Abbildung 2: Metallion – Architektur*
Wir starten mit dem Bronze Layer und möchten die Dateien so weit wie möglich automatisiert in den Bronze Layer 1:1 importieren.
In dbt lässt sich die effektive Funktion Auto-Loader nicht nutzen, weshalb wir auf die Funktion „COPY INTO“ zurückgreifen mussten. Diese kopiert die Daten aus einem Verzeichnis oder auch von einem Volumen direkt in eine Delta-Tabelle und übergeht bereits geladene Dateien. Hierfür legen wir die zu verarbeitenden CSV-Dateien in unser Volumen, von dem wir die Daten anschließend laden können. Da dbt den Befehl „COPY INTO“ in SQL nicht direkt unterstützt, müssen wir uns stattdessen mit einem Makro behelfen. Dieses sorgt im ersten Schritt für die Erstellung der Tabelle, bevor der Befehl „COPY INTO“ ausgeführt wird.
*Abbildung 3: Macro*
Für die Schicht laden wir die Daten dann nicht direkt aus dem Code, der für den Bronze-Layer vorgesehen ist, sondern nutzen den Vorgang als Teil der Beladung im Vorfeld des Silver-Layer, der als PreHook gestartet wird. Der Aufruf dazu sieht folgendermaßen aus:
*Abbildung 4: Beladung Bronze*
In der ersten Zeile „materialized“ wird angegeben, dass die Tabelle im Silver-Layer als Tabelle angelegt werden soll. Die zweite Zeile erstellt die Tabelle im Bronze-Layer und importiert mit der dritten Zeile die Daten in die Tabelle. Die Spalten beim Erstellen der Tabelle mussten wir nicht angeben und wurden bei der ersten Beladung automatisch gesetzt.
Im Silver-Layer erfolgt die weitere Verarbeitung: Hier werden die Daten formatiert, die Datentypen angepasst und die Tabellenstrukturen festgelegt (s. Bild-Beispiel Bestellungen).
*Abbildung 5: Beispiel Bestellung*
Für jede Tabelle im Bronze- und Silver-Layer erstellen wir in dbt eine eigene SQL-Datei, die die Transformationslogik in Form eines SELECT-Statements definiert.
Ergänzend dazu pflegen wir eine YAML-Datei, in der Metadaten wie Spaltenbeschreibungen, Tests (z. B. `not_null` oder `unique`) sowie zusätzliche Modellkonfigurationen hinterlegt sind.
Während die SQL-Datei die eigentliche Datenverarbeitung steuert, dient die YAML-Datei der Dokumentation, Qualitätssicherung und strukturierten Verwaltung der Modelle. Eine automatische Generierung von SQL-Statements erfolgt dabei nicht – vielmehr ergänzt die YAML-Konfiguration die fachliche Logik aus der SQL-Datei.
Während der Erstellung ist uns aufgefallen, dass strukturelle Änderungen an einer bereits materialisierten Tabelle nicht immer automatisch übernommen werden. Insbesondere bei grundlegenden Anpassungen – etwa an bestehenden Spalten – ist häufig ein erneuter vollständiger Aufbau erforderlich.
Dies kann über den Befehl `dbt run --full-refresh` erfolgen, der die betroffene Tabelle löscht und vollständig neu erstellt. Für unseren Anwendungsfall ist das unproblematisch, da wir im Rahmen unseres Beispiels ausschließlich eine Vollbeladung durchführen.
Kleinere Schemaänderungen – wie das Hinzufügen neuer Spalten – lassen sich je nach Materialisierung und Konfiguration (z. B. bei inkrementellen Modellen über `on_schema_change`) teilweise auch ohne vollständigen Neuaufbau umsetzen. Dennoch sind strukturelle Anpassungen insbesondere bei inkrementellen oder historisierten Tabellen mit zusätzlichem Aufwand verbunden.
Bei einer inkrementellen Lösung oder einer historisierten Variante müssten bestehende Daten gegebenenfalls gesichert oder Migrationsstrategien eingeplant werden, um Datenverluste zu vermeiden.
Anschließend setzen wir unsere Arbeit im Gold-Layer fort und beginnen als erstes die Tabellen für Kunde und Bestellungen in eine historisierte Dimensionstabelle nach SCD 2 zu erstellen. Hierzu nutzen wir die Funktion Snapshot von dbt, um dies automatisiert erstellen zu lassen. Mit wenig Aufwand ist hier sichergestellt, dass bei einer Änderung der Daten der alte Satz geschlossen wird und ein neuer Satz mit „Gültig von“ und „Gültig bis“ erstellt wird.
*Abbildung 6: Gold Layer*
Nachfolgend haben wir die weiteren Dimensionstabellen mithilfe von klassischen Modellen mit SQL- und YAML-Dateien erstellt. Abschließend wurde dann die Faktentabelle generiert, in die wir die jeweiligen IDs der Dimensionen integriert haben. Damit war unser Star-Schema-Modell erfolgreich fertiggestellt.
*Abbildung 7: Star Modell*
Für einen vollständigen Datenladeprozess reicht es jedoch nicht aus, nur den Befehl „dbt run“ auszuführen, da dieser lediglich die Modelle verarbeitet, aber keine Snapshots erstellt. Stattdessen empfiehlt sich die Verwendung von „dbt build“, da dieser Befehl automatisch erkennt, welche Komponenten als nächstes verarbeitet werden müssen und sowohl Modelle als auch Snapshots in der richtigen Reihenfolge berücksichtigt.
Ein weiterer wichtiger Aspekt betrifft die Verwaltung der Abhängigkeiten bei der Datenbeladung sowie die Möglichkeit, die Data Lineage transparent darzustellen. Hierbei ist es essenziell, dass die Aufrufe der zu ladenden Tabellen nicht direkt über die Tabellen selbst erfolgen, sondern ausschließlich über Referenzierung und Quellen. Das bedeutet, dass die Entwickler vor Beginn der Entwicklung sorgfältig planen sollten, wie die Referenzen und Abhängigkeiten gestaltet werden, um eine klare, nachvollziehbare und wartbare Datenpipeline zu gewährleisten.
Während der Entwicklung haben wir festgestellt, dass die Data Lineage in unserem aktuellen Tool nur die Modelle (Tabellen) in der Datenkette visualisiert. Es wird jedoch nicht angezeigt, welche Quellspalte in welche Zielspalte geladen wird.
*Abbildung 8: Data Lineage in dbt*
Im Gegensatz dazu bietet Databricks eine umfassendere Übersicht der Data Lineage bis auf die Spaltenebene. Zusätzlich werden die Quellen der CSV-Dateien angezeigt, was eine detailliertere und genauere Nachverfolgung der Daten ermöglicht.
*Abbildung 9: Data Lineage in Databricks*
## Ausführung und Workflows
Die Integration von dbt in einen Databricks-Workflow ist ein bewährter Ansatz, um analytische Transformationen reproduzierbar, versioniert und automatisiert auszuführen. Besonders leistungsfähig wird dieses Setup, wenn der gesamte Workflow direkt aus einem Git-Repository gestartet wird und Ausführungsdetails wie Logs und Status transparent sichtbar sind.
Im Kern basiert der Ansatz darauf, dass das dbt-Projekt vollständig in einem Git-Repository (z. B. auf GitHub oder GitLab) liegt. Dieses Repository enthält neben den dbt-Modellen auch Konfigurationsdateien wie profiles.yml (oder entsprechende Umgebungsvariablen), Tests und Dokumentation. Databricks selbst wird mit dem Repository verbunden, sodass der Code direkt im Workspace verfügbar ist oder bei jeder Ausführung frisch ausgecheckt wird. Damit ist sichergestellt, dass jeder Lauf exakt auf einem definierten Commit basiert – ein zentraler Punkt für Nachvollziehbarkeit und Governance.
Die eigentliche Ausführung erfolgt über einen Databricks-Job, der als Workflow definiert ist. In diesem Job wird ein Task angelegt, der auf einem Job-Cluster läuft. Das Cluster wird meist schlank konfiguriert und nur für die Dauer der dbt-Ausführung gestartet, was Kosten spart und eine saubere Trennung von Entwicklung und Produktion ermöglicht. Innerhalb des Tasks wird dbt entweder über ein init script installiert oder – noch robuster – über ein vorbereitetes Docker-Image bzw. eine Wheel-/Library-Installation bereitgestellt. Die Verbindung zu Databricks SQL-Warehouses oder Clustern erfolgt dabei über das dbt-databricks-Adapterprofil.
*Abbildung 10: Workflow*
Der Startpunkt des Workflows ist bewusst das Git-Repository: Der Job referenziert einen bestimmten Branch oder Tag (z. B. main oder ein Release-Tag). Änderungen an dbt-Modellen werden somit automatisch Teil des nächsten Laufs, ohne dass manuell Code in Databricks kopiert werden muss. Für CI/CD-Szenarien lässt sich dieser Job zusätzlich über externe Trigger (z. B. Merge in den Main-Branch) anstoßen.
Ein entscheidender Aspekt für den produktiven Einsatz ist die Sichtbarkeit der Ausführung. Databricks bietet hier mehrere Ebenen von Transparenz. Auf Job-Ebene sind Status, Laufzeit, verwendetes Cluster und Exit-Code sofort ersichtlich. Innerhalb des Tasks werden die Standardausgaben von dbt – also dbt run, dbt test oder dbt build – vollständig in den Driver-Logs angezeigt. Diese Logs enthalten Informationen zu gestarteten Modellen, Ausführungszeiten, Warnungen und Fehlern und sind direkt im Databricks-UI abrufbar.
Zusätzlich lassen sich dbt-Logs gezielt strukturieren. Durch die Nutzung von JSON-Logs oder durch das Persistieren der target/run\_results.json und manifest.json in einem Storage (z. B. DBFS oder Cloud Object Storage) können Ausführungsergebnisse weiterverarbeitet oder visualisiert werden. In Kombination mit Databricks-Notebooks oder Dashboards entsteht so ein Reporting über dbt-Runs, Fehlerraten oder Modelllaufzeiten.
Für erweiterte Transparenz können einzelne dbt-Kommandos als separate Tasks modelliert werden, etwa ein Task für „dbt deps“, einer für „dbt run“ und ein weiterer für „dbt test“. Dadurch wird im Workflow auf einen Blick sichtbar, in welchem Schritt ein Lauf fehlschlägt. Auch Parameter wie Zielumgebung (dev, prod) oder dbt-Selektoren lassen sich als Job-Parameter definieren und beim Start variabel setzen.
Insgesamt entsteht durch die Kombination aus Git-Repository, dbt und Databricks-Workflows eine saubere, nachvollziehbare und skalierbare Architektur. Transformationen sind versioniert, automatisiert ausführbar und durch Logs sowie Job-Metadaten jederzeit transparent. Genau diese Eigenschaften machen den Ansatz besonders attraktiv für moderne Analytics- und Lakehouse-Architekturen auf Basis von Databricks und dbt Labs.
## Weiter dbt-Funktionen
Im Rahmen der Entwicklung des Projekts habe wir uns noch weiteren Optionen von dbt angeschaut. Hierzu zählen:
## Tests in dbt
Tests in dbt sind automatisierte Prüfungen, die sicherstellen, dass die Daten den erwarteten Qualitätsstandards entsprechen. Sie helfen dabei, Fehler frühzeitig zu erkennen und die Integrität der Daten zu gewährleisten. Hierbei bietet dbt zwei Arten von Tests an:
Schema-Tests: Diese prüfen grundlegende Eigenschaften der Daten, z.B. ob eine Spalte nicht null ist (not\_null), ob Werte innerhalb eines bestimmten Bereichs liegen (accepted\_values) oder ob eine Spalte eindeutig ist (unique).
Benutzerdefinierte Tests: Für spezielle Anforderungen können eigene SQL-Tests geschrieben werden, um komplexe Validierungen durchzuführen wie zum Beispiel Regressionstest.
Tests werden in dbt meist in YAML-Dateien definiert, die den jeweiligen Modellen oder Spalten zugeordnet sind. Bei der Ausführung von „dbt test“ werden alle definierten Tests automatisch ausgeführt. Falls ein Test fehlschlägt, erhält das Team eine Fehlermeldung, sodass Probleme schnell behoben werden können.
## Dokumentation in dbt
Die Dokumentation in dbt umfasst die Beschreibung der Modelle, Spalten, Quellen und Transformationen innerhalb des Data-Warehouse. Sie schafft Transparenz und erleichtert das Verständnis der Datenstrukturen für alle Beteiligten. dbt ermöglicht es, Dokumentationen direkt in den Modell- und Spaltendefinitionen zu hinterlegen. Diese werden in YAML-Dateien gepflegt und können mit Beschreibungen, Metadaten und Beispielen versehen werden. Zudem können zusätzliche Markdown-Dokumente eingebunden werden. Mit dem Befehl „dbt docs generate“ wird eine interaktive HTML-Dokumentation erstellt, die alle Modelle, Spalten und deren Beschreibungen übersichtlich darstellt. Diese Dokumentation kann anschließend im Browser eingesehen werden und ist stets aktuell, wenn die Modelle neu gebaut werden.
## Seeds in dbt
Seeds sind statische Datensätze, die in Form von CSV-Dateien im Projekt gespeichert werden. Sie dienen dazu, kleine, unveränderliche Datenmengen in das Data-Warehouse zu laden, z.B. Lookup-Tabellen, Konfigurationsdaten oder Referenzinformationen. Seeds ermöglichen es, wichtige Referenzdaten versioniert im Projekt zu verwalten. Sie können mit „dbt seed“ in das Ziel-Data-Warehouse geladen werden. Da Seeds in CSV-Format vorliegen, sind sie leicht zu erstellen, zu bearbeiten und zu pflegen.
## Fazit
dbt ermöglicht eine strukturierte, transparente und automatisierte Entwicklung von Datenpipelines. In Kombination mit Databricks lassen sich Transformationen effizient ausführen, Datenqualität sichern und Workflows nachvollziehbar orchestrieren. Unser Beispiel zeigt, wie dbt Teams bei modernen Analytics-Projekten unterstützt, zuverlässige Daten aufzubereiten und datengetriebene Entscheidungen zu erleichtern.
## Mehr aus dieser Blogserie
**Teil 1:** [Medaillon-Architektur, Delta Live Tables und dbt in der Praxis](https://thecattlecrew.net/2026/01/15/databricks-verstehen-teil-1-medaillon-architektur-delta-live-tables-und-dbt-in-der-praxis/)
**Teil 2:** [Was ist Databricks? Was bietet mir das Tool?](https://thecattlecrew.net/2026/02/06/databricks-verstehen-teil-2-was-ist-databricks-was-bietet-mir-das-tool/)
**Teil 3:** [Was ist DBT und warum ist es für moderne Datenpipelines so wichtig?](https://thecattlecrew.net/?p=40947&preview=true)
**Teil 4:** [Gegenüberstellung der Ansätze und Fazit](https://thecattlecrew.net/2026/03/12/databricks-verstehen-teil-4-fazit/)
Viel Spaß beim Lesen!
**Kategorien:** Analytics & Insights, Architecture & Process Models
---
### [Databricks verstehen – Teil 2: Was ist Databricks? Was bietet mir das Tool?](https://thecattlecrew.net/2026/02/06/databricks-verstehen-teil-2-was-ist-databricks-was-bietet-mir-das-tool/)
**Published:** Februar 6, 2026
**Author:** Thomas Eichler
**Content:**
Databricks ist eine cloudbasierte Datenanalyse- und KI-Plattform, die auf Apache Spark basiert und die Zusammenarbeit zwischen Data-Scientists, Data-Engineers und Analysten erleichtert. Die Plattform vereint Big-Data-Verarbeitung, Machine Learning, Data Warehousing und Business Intelligence in einer zentralen Umgebung. Sie wird als sogenannte Lakehouse-Plattform bezeichnet, da sie die Vorteile von Data Lakes (Flexibilität, niedrige Speicherkosten) und Data Warehouses (hohe Performance, strukturierte Abfragen) kombiniert.
## Was bietet dir Databricks konkret?
Die Plattform dient als zentraler Ort für unterschiedliche Data-Workloads, darunter Datenimport, -verarbeitung und -analyse. Sie integriert sich mit den gängigen Cloud-Anbietern AWS, Azure und Google Cloud und unterstützt verschiedene Programmiersprachen wie Python, SQL, Scala und R. Collaborative Notebooks ermöglichen eine cloudbasierte Zusammenarbeit ähnlich wie Jupyter Notebooks, inklusive Versionierung und Kommentaren. Im Bereich Machine Learning bietet Databricks einen vollständigen End-to-End-Prozess für Datenaufbereitung, Modellierung und Deployment und integriert dabei das Open-Source-Framework MLflow.
Ein weiteres zentrales Element ist Delta Lake, das ACID-Transaktionen im Data Lake ermöglicht und Funktionen wie inkrementelle Verarbeitung, Time-Travel und konsistente Abfragen unterstützt. Databricks stellt außerdem Funktionen zur Orchestrierung von Data-Engineering-Pipelines bereit, inklusive Jobs und Workflows, die sowohl Batch- als auch Streaming-Szenarien abdecken. Für Analysten gibt es ein benutzerfreundliches SQL-Interface, das sich auch mit BI-Tools wie Pyramid-Analytics, Power BI und Tableau verbinden lässt. Dank Spark bietet Databricks eine hohe Skalierbarkeit bis hin zu Petabyte-Datenmengen sowie automatische Skalierungsfunktionen.
## Für wen ist Databricks besonders geeignet?
Databricks eignet sich für Data-Scientists, die Modelle entwickeln, für Data-Engineers, die komplexe Pipelines aufbauen, sowie für Analysts, die Daten abfragen und visualisieren. Unternehmen profitieren dabei von einer modernen, skalierbaren Datenplattform, die unterschiedlichste analytische Anforderungen in einer Umgebung vereint.
## Was ist Delta Live Tables (DLT)?
Delta Live Tables ist eine deklarative Schicht über Apache Spark und Delta Lake, mit der Datenpipelines deutlich einfacher erstellt und verwaltet werden können. Datenregeln, Fehlerbehandlung, Optimierung und Abhängigkeiten werden dabei automatisch verarbeitet. Ziel ist eine robuste, wartbare und gleichzeitig leicht implementierbare Pipeline-Entwicklung.
DLT bietet deklarative Pipeline-Definitionen in SQL oder Python, automatisches Abhängigkeitsmanagement, integrierte Datenqualitätsregeln sowie inkrementelle Verarbeitung. Durch Monitoring- und Auto-Healing-Mechanismen werden Pipelines zuverlässig überwacht und visualisiert. Batch- und Streaming-Verarbeitung werden innerhalb eines einheitlichen Modells unterstützt. Typische Anwendungsfälle sind der Aufbau von Data-Warehouse-Strukturen, Datenbereinigung, Bronze-/Silver-/Gold-Layer-Transformationen sowie zeitgesteuerte oder kontinuierliche Verarbeitung.
## Einrichtung Databricks
Die Einrichtung hängt davon ab, ob Databricks über die Community Edition, Azure oder andere Cloud-Anbieter genutzt wird.
1. Databricks Community Edition
Die Community Edition eignet sich gut zum Lernen. Nach der Registrierung auf der Databricks-Website kann man direkt ein Notebook erstellen und mit Spark arbeiten.
2. Databricks auf Azure
Hierzu sind ein Azure-Konto sowie entsprechende Berechtigungen notwendig. Im Azure-Portal wird eine Databricks-Ressource erstellt und anschließend ein Workspace gestartet. Danach können Cluster erstellt und Notebooks verbunden werden. Anschließend lassen sich Daten laden, transformieren, Machine-Learning-Modelle trainieren oder Dashboards erstellen.
## Unser Projekt und die Umsetzung
## Allgemeiner Überblick
Im Projekt wurde eine automatisierte Datenpipeline aufgebaut, die Rohdaten im Bronze-Layer importiert, im Silver-Layer weiterverarbeitet und im Gold-Layer final modelliert. Insgesamt wurden fünf CSV-Dateien geladen und in den bekannten Layern Bronze, Silver und Gold verarbeitet. Anschließend wurde zusätzlich die Einbindung in Databricks Workflows untersucht. Der gesamte DLT-Code basiert auf PySpark (Raw-Layer) sowie SQL (Silver- und Gold-Layer). Ziel war ein möglichst generischer 1:1-Import der Dateien im Bronze-Layer.
## Bronze-Layer
Für das Laden der Daten kommt der Auto-Loader zum Einsatz, der kontinuierlich im Storage nach neuen Dateien sucht und Streaming-Tabellen befüllt. Die Dateien werden in einem Volume abgelegt, aus dem der Auto-Loader die Daten liest.
*Abbildung 1: Auto-Loader-Konfig*
Mithilfe von DLT werden anschließend generische RAW-Streaming-Tabellen erzeugt, wobei Tabellen- und Spaltennamen direkt aus den CSV-Dateien übernommen werden.
*Abbildung 2: DLT*
## Silver-Layer
Im Silver-Layer erfolgt die weitere Verarbeitung, Formatierung und Strukturierung der Daten sowie die Anpassung der Datentypen. Für jede Tabelle wird ein eigener Codeblock definiert, der Spalten, Datentypen, Kommentare und Bedingungen enthält. Zusätzlich wird ein Constraint auf die Spalte BestellungID definiert, um Zeilen mit NULL-Werten zu entfernen. Auch in diesem Layer entstehen Streaming-Tabellen.
## 
## Beispiele für möglichen Constraints:
## Gold-Layer
Im Gold-Layer werden Dimensionstabellen nach SCD2-Logik erstellt. DLT stellt hierfür integrierte Funktionen bereit, die automatisch Versionierung, Zeiträume sowie das Schließen alter Datensätze übernehmen.
*Abbildung 3: Dimension*
*Abbildung 4: SCD2*
Anschließend wird die Faktentabelle generiert, in die die jeweiligen IDs der Dimensionen integriert werden. Damit ist das Star-Schema vollständig aufgebaut.
*Abbildung 5: Fakten*
*Abbildung 6: Star-Modell*
## Ausführung und Workflows
Um DLT nutzen zu können, wird eine Pipeline erstellt. In ihr werden MatViews definiert, einschließlich Cluster und zugehöriger Notebooks. DLT erkennt dabei automatisch die korrekte Ausführungsreihenfolge. Im Beispiel sind Raw-Layer vom Silver- und Gold-Layer getrennt. Eine Aufsplittung von Silver- und Gold-Layer wäre selbstverständlich ebenfalls möglich.
*Abbildung 7: Pipeline*
*Abbildung 8: Modell*
Databricks Workflows basieren auf Jobs und ermöglichen komplexe Abhängigkeiten. Ein Workflow besteht aus mehreren Tasks. Unser Prozess wird über einen Job ausgelöst, der die Pipeline ausführt.
*Abbildung 9: Job*
Jede Ausführung beinhaltet Logs, Metriken, Status sowie Artefakte wie erzeugte Tabellen oder Dateien. Ein weiterer wichtiger Aspekt ist die Darstellung der Data Lineage, die in Databricks bis auf Spaltenebene erfolgt.
*Abbildung 10: Lineage overview*
Diese geht bis auf Spaltenebene runter.
Abbildung 11: Lineage detail
## Feeling Databricks DLT
Die Arbeit im Projekt zeigt, dass SQL allein für komplexere File-Verarbeitung nicht ausreicht und Python in Kombination mit SQL die beste Herangehensweise darstellt. Der RAW-Layer lässt sich mithilfe von KI-Tools sehr schnell entwickeln, während ab dem Conformed-Layer solide Python-Kenntnisse erforderlich sind. SQL-Abfragen dauern meist nur wenige Sekunden, allerdings benötigen auch Cluster-Initialisierungen eine gewisse Zeit. Die Notebook-Umgebung ist angenehm, jedoch wird komplexere Logik schnell unübersichtlich, weshalb eine sehr strukturierte Arbeitsweise notwendig ist. Gleiches gilt insbesondere für den Gold-Layer.“
## Mehr aus dieser Blogserie
**Teil 1:** [Medaillon-Architektur, Delta Live Tables und dbt in der Praxis](https://thecattlecrew.net/2026/01/15/databricks-verstehen-teil-1-medaillon-architektur-delta-live-tables-und-dbt-in-der-praxis/)
**Teil 2:** [Was ist Databricks? Was bietet mir das Tool?](https://thecattlecrew.net/2026/02/06/databricks-verstehen-teil-2-was-ist-databricks-was-bietet-mir-das-tool/)
**Teil 3:** [Was ist DBT und warum ist es für moderne Datenpipelines so wichtig?](https://thecattlecrew.net/?p=40947&preview=true)
**Teil 4:** [Gegenüberstellung der Ansätze und Fazit](https://thecattlecrew.net/2026/03/12/databricks-verstehen-teil-4-fazit/)
Viel Spaß beim Lesen!
**Kategorien:** Analytics & Insights, Architecture & Process Models
---
### [Databricks verstehen – Teil 1: Medaillon-Architektur, Delta Live Tables und dbt in der Praxis](https://thecattlecrew.net/2026/01/15/databricks-verstehen-teil-1-medaillon-architektur-delta-live-tables-und-dbt-in-der-praxis/)
**Published:** Januar 15, 2026
**Author:** Thomas Eichler
**Content:**
Datenmengen wachsen in rasantem Tempo – Studien zufolge verdoppeln sie sich alle zwei Jahre. Klassische Architekturen geraten dabei schnell an ihre Grenzen. Immer mehr Informationen aus Transaktionssystemen, IoT-Geräten oder sozialen Medien müssen integriert, verarbeitet und für Analysen verfügbar gemacht werden. Für IT-Architekten stellt sich deshalb die zentrale Frage, wie sie eine Infrastruktur aufbauen können, die nicht nur heute funktioniert, sondern auch in Zukunft flexibel und skalierbar bleibt.
Genau hier setzt Databricks an. Die Plattform vereint eine cloudbasierte Umgebung mit der Fähigkeit, große Datenmengen performant zu speichern, zu transformieren und für Analysen oder Machine-Learning-Szenarien bereitzustellen. Unternehmen erhalten damit die Möglichkeit, ihre Datenlandschaft kontinuierlich zu erweitern, ohne dass die Leistungsfähigkeit leidet.
## Stärken von Databricks
Was Databricks besonders interessant macht, ist die Kombination aus Offenheit und Integration. Die Plattform baut auf offenen Standards auf und lässt sich durch eine Vielzahl von Open-Source-Tools erweitern. Das gibt Architekten die Freiheit, bestehende Technologien weiterzuverwenden und neue Lösungen nahtlos einzubinden. Gleichzeitig sorgt die modulare Architektur dafür, dass sich einzelne Komponenten flexibel austauschen oder ergänzen lassen.
Die Vorteile lassen sich im Kern so zusammenfassen:
- Databricks wächst flexibel mit den Anforderungen und bleibt dabei performant.
- Daten unterschiedlichster Herkunft und Formate können integriert und verarbeitet werden.
- Sowohl einfache Analysen als auch komplexe Machine-Learning-Szenarien finden in der Plattform einen geeigneten Rahmen.
Für die Praxis bedeutet das, dass IT-Architekten nicht nur ein leistungsfähiges Werkzeug, sondern auch eine strategische Grundlage erhalten, um ihre Datenarchitektur langfristig zukunftsfähig zu gestalten.
## Delta Live Tables und dbt: Zwei Wege zur modernen Datenpipeline
Ein zentrales Thema in jeder Datenplattform ist das Management von Pipelines – also die Frage, wie Rohdaten zuverlässig in eine für Analysen nutzbare Form gebracht werden. In Databricks existieren dafür unterschiedliche Ansätze.
- **Delta Live Tables** ist ein nativer Service, der die Erstellung, Überwachung und Wartung von Pipelines weitgehend automatisiert. Fehlerhandling, Monitoring und Skalierung sind direkt integriert, was den Betrieb spürbar vereinfacht. Wie in diesem Blogbeitrag beschrieben, wird DLT durch die Weiterentwicklung zu Spark Declarative Pipelines (SDP) abgelöst. Auf SDP als Nachfolger von DLT gehen wir in einem eigenen Kapitel dieser Blogserie im Detail ein.
- Mit **dbt (Data Build Tool)** steht ein ganz anderer Ansatz zur Verfügung. Hier werden Transformationen deklarativ beschrieben, meist mit starkem Fokus auf SQL.
dbt hat sich vor allem im Umfeld von Analysten etabliert, wo mit vertrauten Werkzeugen gearbeitet werden soll und man gleichzeitig von einer großen Community profitieren möchte. Während Delta Live Tables die Plattformintegration in den Vordergrund stellt, bietet dbt eine Arbeitsweise, die sich gut in bestehende Teams und Prozesse einfügt.
## Die Medaillon-Architektur als Demo-Szenario
Um die Unterschiede und Gemeinsamkeiten der beiden Frameworks greifbar zu machen, haben wir ein Beispiel-Szenario auf Basis der Medaillon-Architektur entwickelt. Diese Architektur unterteilt Daten in drei Schichten.
1. Im Bronze-Layer werden die Rohdaten möglichst unverändert importiert – etwa aus CSV-Dateien, die automatisiert erkannt und eingelesen werden.
2. Der Silver-Layer dient anschließend dazu, die Daten zu bereinigen, anzureichern und historisch konsistent zu speichern. So entsteht eine solide Grundlage für Analysen.
3. Im Gold-Layer schließlich werden Fakt- und Dimensionstabellen erstellt, die sich unmittelbar für Dashboards, Reports oder weiterführende Data-Warehouse-Konzepte nutzen lassen.
Die Abbildung zeigt den Weg der Daten durch diese Schichten. Besonders interessant ist dabei, wie Delta Live Tables und dbt jeweils – oder auch in Kombination – eingesetzt werden können, um diese Prozesse effizient und zuverlässig zu gestalten.
Modellzeichnung unserer Projektarchitektur
## Mehr als nur Technik: Organisatorische Faktoren
Die Wahl zwischen Delta Live Tables und dbt ist jedoch keine rein technische Frage. Sie hängt stark von organisatorischen Rahmenbedingungen ab. Verfügt das Team bereits über Erfahrung mit einem der Tools, oder sind zusätzliche Schulungen notwendig? Wie leicht lassen sich Fachkräfte mit den entsprechenden Kenntnissen am Markt finden? Und welche strategische Ausrichtung verfolgt das Unternehmen – setzt es lieber auf ein stark integriertes Plattform-Feature oder auf ein weit verbreitetes Open-Source-Werkzeug mit aktiver Community?
Auch die Zukunftssicherheit spielt eine Rolle. Datenarchitekturen müssen so ausgelegt sein, dass sie sich mit den Anforderungen des Geschäfts entwickeln können. Die Entscheidung für ein bestimmtes Tool sollte deshalb immer im Kontext des gesamten Unternehmens betrachtet werden. Letztlich geht es darum, die richtige Balance zwischen technologischen Möglichkeiten, organisatorischen Ressourcen und strategischen Zielen zu finden.
## Mehr aus dieser Blogserie
**Teil 1:** [Medaillon-Architektur, Delta Live Tables und dbt in der Praxis](https://thecattlecrew.net/2026/01/15/databricks-verstehen-teil-1-medaillon-architektur-delta-live-tables-und-dbt-in-der-praxis/)
**Teil 2:** [Projektumsetzung mit Delta Live Tables](https://thecattlecrew.net/2026/02/06/databricks-verstehen-teil-2-was-ist-databricks-was-bietet-mir-das-tool/)
**Teil 3:** [Projektumsetzung mit dbt](https://thecattlecrew.net/?p=40947&preview=true)
**Teil 4:** [Gegenüberstellung der Ansätze und Fazit](https://thecattlecrew.net/2026/03/12/databricks-verstehen-teil-4-fazit/)
Viel Spaß beim Lesen!
**Kategorien:** Analytics & Insights, Architecture & Process Models
---
### [n8n: AI Workflow Automation in der Praxis](https://thecattlecrew.net/2026/05/21/n8n-ai-workflow-automation-in-der-praxis/)
**Published:** Mai 21, 2026
**Author:** Simon Weißmüller
**Content:**
## Vom Video-Call zur automatischen Zusammenfassungen für alle Teilnehmer
Im Zuge der rasanten Entwicklungen von Künstlicher Intelligenz im Allgemeinen und Large Language Models im speziellen, vergeht kaum eine Woche in der kein neues KI-Tool erscheint, welches nicht verspricht die Arbeitswelt zu revolutionieren.
Einer der neusten Trends ist dabei AI-Workflow Automation. Zwar ist Workflow- Automatisierung nicht neu, doch durch die Integration von LLMs und visuell bedienbaren No-Code-Oberflächen versprechen diese Tools, Geschäftsprozesse schneller, flexibler und vor allem intelligenter automatisieren zu können.
Ein Tool, das in diesem Bereich hervorsticht, ist das von einem Berliner Start-up entwickelte **n8n**.
Das Versprechen ist groß: Auch Einzelpersonen oder kleine Teams sollen in der Lage sein, komplexe Arbeitsprozesse zu automatisieren und durch das Einbinden von KI-Modellen anzureichen. Eine tiefe technische Expertise dabei nicht zwingend erforderlich, jedoch gibt es die Möglichkeit auch selbstgeschrieben Javascript Code einzubinden um Prozesse noch detailgenauer abzubilden.
Ich musste bei diesem Versprechen, direkt an ein Problem denken, welches mir im beruflichen Kontext immer wieder begegnet: **Meetings die zu lange dauern, ohne klare Struktur verlaufen und deren Ergebnisse nach wenigen Tagen nicht mehr greifbar sind.**
Deshalb habe ich mich direkt daran gemacht, die Möglichkeiten von n8n, an diesem Praxisbeispiel zu untersuchen.
Ich habe also einen Workflow gebaut, der den Inhalt eines Meetings automatisch transkribiert, diesen mittels KI auswertet, die relevanten Themen und ToDos identifiziert und eine Zusammenfassung als E-Mail an alle Teilnehmer aufsetzt.
## Was ist n8n? Ein kurzer Überblick
n8n bietet ein visuelles User-Interface mit dem Nutzer durch das Verbinden von **Nodes** Arbeitsabläufe erstellen können.
Jeder dieser Nodes empfängt Daten, führt eine Aufgabe auf und reicht die verarbeiteten Daten an die nächsten mit ihm verbunden Nodes weiter. Die Daten liegen dabei fast immer als JSON vor, ein für Entwickler vertrautes Format.
Nodes lassen sich in vier Typen unterteilen:
**Trigger-Nodes:** Starten einen Workflow, etwa bei neuen Dateien im Drive oder eingehenden E-Mails.
**Action-Nodes:** Führen Aufgaben aus und können mit verschiedensten externe Services interagiere, zum Beispiel durch Senden von Emails über ein Gmail Konto, Ausführen von Linux Commands auf einem Remote Server, Prompting von LLMs, oder Zugriff auf Postgres-Datenbanken.
**Transformation:** Erlauben das Filtern, Mappen oder Umformen von Daten – inklusive JavaScript Expressions.
**Logik & Verzweigung:** Ermöglichen mit If/Else, Switch, Merge, Split und Loops komplexe Entscheidungslogik zu implementieren.
## Praxis Beispiel – Vom Meeting zur automatischenZusammenfassung
Ich habe mich für mein Projekt für die Cloud-Version entschieden, die nach einem Testzeitraum kostenpflichtig ist. Die Community Edition ist dagegen kostenlos, open-source und kann vollständig selbst gehostet werden.
Mein Ziel war ein Workflow, der Folgendes leistet:
1. Ein Meeting findet statt.
2. Google Meet erzeugt automatisch ein Transkript und speichert dieses als Google Doc.
3. n8n erkennt das neu erzeugte Dokument.
4. Das Transkript wird von einem LLM ausgewertet.
5. Die Zusammenfassung wird als E-Mail Entwurf in meinem Gmail-Account erstellt.
Bild 1: Visueller Workflow in n8n Cloud
Der Workflow startet mit einem **Google Drive Trigger**, der auf neue Dateien in meinem Ordner *“Meet Transcription”* hört. Wenn ein Meeting endet, legt Google Meet ein Google Doc mit allen Sprecherbeiträgen in diesem Ordner ab.
Der Output des **Trigger-Nodes** ein JSON-Objekt mit Metadaten der Datei: Dateipfad, ID, Timestamp usw.
Der nächste Node nutzt die Dokument-ID, um den Textinhalt aus Google Docs abzurufen. Das komplette Transkript liegt damit als reiner Text vor und kann weiterverarbeitet werden Der Inhalt wird nun von 2 Nodes weiterverarbeitet.
Zum einen nutzt der **OpenAI Node**, den Text um einen Prompt mit folgenden Aufgabe zu definieren:
- Meeting verständlich zusammenfassen
- Action Items identifizieren
- Verantwortlichkeiten zuweisen
- Entscheidungen und offene Fragen extrahieren
Abbildung 2: Der Input eines Knotens lässt sich mittels Javascript Expression Syntax leicht einbinden. Hier nutze ich das Transkript des Meetings um daraus einen Prompt zu erstellen.
Ein **Transformation-Node** extrahiert aus dem Transkript den Meeting-Titel um diesen später als Betreff der E-Mail zu nutzen. n8n unterstützt JavaScript-Expressions, sodass Mapping und Parsing sehr flexibel möglich sind.
Abbildung 3: Die Verwendung von Javascript Expression eröffnet die Möglichkeit zu komplexeren Datenmanipulation
Die Outputs der jeweiligen **Nodes** müssen daraufhin zu einem einzelnen JSON zusammengeführt werden, bevor wir die Daten für meinen E-Mail Entwurf nutzen können.
Im finalen Schritt nutzt ein **G-Mail Node**, welchen ich vorher mit meinem E-Mail Account verbunden habe, den Output der vorherigen Nodes als Betreff und Inhalt für den Entwurf.
Das Ergebnis: Eine fertiger E-Mail mit allen relevanten Infos – bereit zum Versenden an die Teilnehmer. Optional ließen sich noch die E-Mail-Adressen der Teilnehmer automatisch aus dem Google Calendar Event extrahieren.
Abbildung 4: Automatisch erstellter E-Mail Entwurf
## Fazit
Für das Aufsetzten den gesamten Workflow habe ich rund **zwei Stunden** benötigt, wobei der größte Teil davon in das Einrichten der API-Credentials für Drive, Docs und Gmail geflossen ist. Sobald die Authentifizierung stand, ließ sich der Workflow sehr intuitiv umsetzen.
Besonders hilfreich: Der integrierte **n8n AI Helper**, der in der Cloud-Version direkt bei Fehlern Vorschläge liefert oder Transformationslogik generieren kann.
Mein Fazit:
- **Für kleine Teams und wiederkehrende Aufgaben ist n8n eine extrem leistungsfähige Lösung.**
- **Die JSON-basierte Architektur und Javascript Expression Syntax macht es für Entwickler angenehm flexibel.**
- Wie bei vielen Low-Code-Tools nimmt der Nutzen ab, wenn Prozesse sehr komplex, stark verzweigt oder hochskalierbar sein müssen.
Aber für den beschriebenen Use Case – und viele ähnliche – ist n8n ein beeindruckend effektives Werkzeug
**Kategorien:** AI & Data Science, Automation
---
### [Ein halbes Jahr STACKIT: Cloud-Erfahrungen aus der Praxis](https://thecattlecrew.net/2026/05/05/ein-halbes-jahr-stackit-cloud-erfahrungen-aus-der-praxis/)
**Published:** Mai 5, 2026
**Author:** Anton Rösemann
**Content:**
In den letzten Monaten haben wir intensiv in einem Showcase Projekt im Rahmen des OC Public Digital Innovation Lab mit [STACKIT](https://stackit.com/de), dem Cloudanbieter der [Schwarz Gruppe](https://schwarz-digits.de), gearbeitet. Zeit für ein erstes Fazit aus Entwicklersicht: Was kann STACKIT heute schon gut, wo unterscheidet es sich von Hyperscalern wie AWS oder Azure – und für wen lohnt sich der Blick auf diese Cloudlösung aus der DACH-Region?
## **Was ist STACKIT – und warum überhaupt eine Alternative?**
STACKIT ist die Cloud-Plattform der Schwarz Gruppe (u.a. Lidl, Kaufland) und positioniert sich ganz klar als europäische Alternative zu den großen US-Hyperscalern. Funktional bewegt sich STACKIT in einer ähnlichen Liga: Compute, Storage, Netzwerke, Kubernetes, APIs, IaC-Anbindung (z.?B. Terraform) – alles da, was man für moderne Cloud-Projekte braucht.
Der entscheidende Unterschied ist weniger technisch als strategisch und rechtlich motiviert: [Datenschutz](https://thecattlecrew.net/tag/it-secutity/). Wer sensible oder besonders schützenswerte Daten verarbeitet – etwa im Behördenumfeld oder in regulierten Branchen – muss sich sehr bewusst mit dem Thema Datenzugriff durch Drittstaaten auseinandersetzen. Bei US-Anbietern bleibt, unabhängig von Verschlüsselung, immer ein Restrisiko durch amerikanisches Recht. STACKIT hingegen hostet in europäischen Rechenzentren (Deutschland und Österreich) und unterliegt europäischer Gesetzgebung. Für viele Projekte ist das ein echtes Argument.
## **Technisch: weniger Spezial-Showcases, aber ausreichend Substanz**
Wenn man AWS oder Azure gewohnt ist, fällt eines sofort auf: STACKIT hat (noch) nicht diese riesige Breite an hochspezialisierten Managed Services – etwa für KI, Machine Learning oder fertige Analysepipelines. Wo Azure mit „One-Click“-Lösungen für Regression, Logs oder Data Science glänzt, ist STACKIT deutlich nüchterner unterwegs.
In der Praxis ist das aber oft weniger relevant, als man denkt. Viele dieser Showcase-Services sind nett für Demos oder Experimente, spielen im langlebigen Projektalltag aber eine untergeordnete Rolle. Für stabile, langlaufende Anwendungen ist der vorhandene Werkzeugkasten von STACKIT absolut ausreichend – und genau darauf scheint der Fokus auch zu liegen.
## **Kosten: kein Schnäppchen, aber realistisch**
Preislich unterscheidet sich STACKIT weniger von den Hyperscalern, als man zunächst vermutet. Der Einstieg wirkt etwas teurer, dafür sind die Kosten sehr transparent. Man sieht klar, was Compute, Cluster, Netzwerk oder Zusatzdienste pro Tag kosten.
Das Prinzip ist überall gleich: Einzelne Bausteine sind günstig, aber sobald ein realistisches Setup läuft, summieren sich die Kosten. AWS und Azure funktionieren nicht anders – nur heißen die Pakete dort anders. Für produktive Umgebungen bewegen sich die Kosten am Ende auf vergleichbarem Niveau.
## **Stabilität, Performance und Support**
In unserem bisherigen Einsatz gab es keine echten Showstopper. Die Plattform lief stabil, die Performance der (bewusst klein dimensionierten) Maschinen war völlig ausreichend, Netzwerke und Zugriffe funktionierten erwartungsgemäß.
Die wenigen Probleme, die auftraten, waren eher klassische „Kinderkrankheiten“: wenig aussagekräftige Fehlermeldungen oder Situationen, in denen man erst lernen muss, wie ein bestimmter Mechanismus gedacht ist. Positiv: Der Support war erreichbar, hilfsbereit und kompetent – und das ist gerade bei jüngeren Plattformen ein großer Pluspunkt.
## **Usability und Entwicklungstempo**
Die größte Herausforderung ist aktuell weniger die Technik als die Übersichtlichkeit. Wie bei AWS oder Azure wächst das Produktportfolio schnell, und alle Services landen in einer langen, unübersichtlichen Menüstruktur. Man muss sich aktiv merken, welche Services man wirklich nutzt.
Gleichzeitig ist beeindruckend, wie schnell sich STACKIT weiterentwickelt. Neue Features sind klar gekennzeichnet, ganze Produktbereiche (z.B. Workflows, Notebooks, Firewall, KI-Themen) kommen hinzu. Das Produkt wirkt klar auf Wachstum ausgelegt und hat im letzten halben Jahr massiv an Features hinzugewonnen.
## **Lernen und Einstieg: noch wenig Community, aber solide Basis**
Der Einstieg ist etwas holpriger als bei AWS – schlicht, weil es weniger Blogposts, StackOverflow-Antworten und YouTube-Videos gibt. Dafür bietet STACKIT eine eigene Academy mit Kursen und Zertifizierungen sowie eine ordentliche Dokumentation.
Interessant: Selbst KI-Tools kommen mit der STACKIT-API schon erstaunlich gut zurecht. Für einen Anbieter dieser Größe ist das ein gutes Zeichen.
## **Fazit: Würden wir STACKIT empfehlen?**
Ja – definitiv. STACKIT ist keine preisgünstigere Kopie von AWS und auch kein Feature-Monster. Aber es ist eine professionelle, stabile Cloud-Plattform, die besonders dort überzeugt, wo Datenschutz, europäische Hosting-Standards und Langfristigkeit wichtig sind.
Für hochkritische Produktivsysteme, Behörden, regulierte Branchen oder Unternehmen mit klarer EU-Strategie ist STACKIT heute schon eine sehr ernstzunehmende Option. Und der aktuelle Entwicklungsspeed lässt vermuten: Das ist erst der Anfang und die nächsten neuen Features sind bereits in der Pipeline.
**Kategorien:** Cloud, Development, Infrastructure
---
### [Dynamische, Multiparameter REST-Queries mit RSQL](https://thecattlecrew.net/2026/01/19/dynamische-multiparameter-rest-queries-mit-rsql/)
**Published:** Januar 19, 2026
**Author:** Andreas Meyer
**Content:**
In meinem Beitrag soll es um RSQL gehen, eine kleine Ausdruckssprache, die sich eignet, um dynamische Multiparameter Queries zu generieren. RSQL ist eine Erweiterung der „Feed Item Query Language“ (kurz: FIQL). FIQL ist ein [IETF-Draft](https://datatracker.ietf.org/doc/html/draft-nottingham-atompub-fiql-00), der bisher nicht in den IETF-Standard übernommen wurde. RSQL/FIQL umfasst eine kontextfreie Grammatik, mit der sich Ausdrücke bilden lassen, die den Rechenregeln boolescher Algebra folgen.
Warum halte ich das Thema für relevant? Ein alltägliches Problem in der Anwendungsentwicklung ist, Suchfunktionen umzusetzen, die einerseits den Endanwendenden ein hohes Maß an Flexibilität lassen, welches nur durch fachliche Bedingungen eingeschränkt werden sollte, während die technische Komplexität für die Entwickelnden gering bleibt. Da wir Suchanfragen üblicherweise als Filter modellieren, die durch boolesche Ausdrücke repräsentiert werden, lohnt es sich, RSQL zu kennen.
Solche Filter zu implementieren ist nicht trivial, besonders, wenn sie zur Laufzeit variabel sein sollen. Und selbst wenn es trivial wäre, wäre die Umsetzung immer noch nicht umsonst: Ein Design muss her, Tests, Dokumentation etc, man kennt es; nur um am Ende ein bereits gelöstes Problem nochmal gelöst zu haben, während die üblichen Kinderkrankheiten frischer Prototypen als Bonus oben drauf kommen. Denjenigen, die in so einer Situation auch lieber pragmatisch auf Selbstverwirklichung auf Kundenkosten verzichten und stattdessen auf bewährte Technologien setzen, möchte ich im weiteren RSQL etwas detaillierter vorstellen. Bibliotheken, die FIQL-Ausdrücke generieren und parsen, gibt es z.b. für [Python](https://fiql-parser.readthedocs.io/en/stable/usage.html), [Typescript](https://npm.io/package/rsql-criteria-typescript) und [Java](https://github.com/jirutka/rsql-parser). Für das Beispiel verwende ich eine Java-Bibliothek.
Meiner Erfahrung nach ist RSQL noch nicht so bekannt, wie es sein sollte, daher habe ich mich entschlossen, diesen Artikel zu schreiben. (Bei dieser Gelegenheit meine freundlichsten Grüße an Thomas Behrendt, der mich auf RSQL aufmerksam gemacht hat)
### Was meine ich mit dynamischen Multiparameter Queries?
Dynamische Multiparameter Queries sind Suchanfragen, die auf verschiedenen Spalten mit unterschiedlichen Operatoren filtern, während die Filter zur Laufzeit frei kombinierbar sind.
Nehmen wir einen Betrieb an, der sich für seinen Onlineshop Pflegemasken für Bestellungen, Rechnungen etc wünscht. Die Übersicht für Bestellungen könnte z.b. folgende Felder umfassen:
- Kundennummer
- Name
- Produktnummer
- Bestellstatus
- Händlerpreis
- Verkaufspreis
- Bestelldatum
- Lieferdatum
- Rechnungsdatum
- Verkäufer
Idealerweise möchten wir den Sachbearbeitenden erlauben, für jedes Feld Filter zu setzen. Z.b. nach Kundenummern, nach Bestellstatus, nach Bestelldatum. Aber auch nach Kombinationen all dieser:
- Kundennummer == 1234567
- Kundennummer startswith 123
- Bestellstatus in (Geliefert, Bestellt)
- Bestellstatus == Geliefert und Rechnungsdatum < now()
- Lieferdatum < 31.12.2018 und Lieferdatum > 01.01.2017 oder Lieferdatum = now()
- …
Viele Anfragen sind sicher Unsinn, aber auch an sinnvollen Anfragen gibt es unzählige Möglichkeiten. Einerseits möchten wir den Nutzenden ermöglichen, beliebige Anfragen zu stellen, ob sie nun Sinn machen oder nicht. Andererseits muss die technische Abbildung aller Filterkombinationen die Regeln der booleschen Algebra befolgen, was in der Umsetzung gar nicht so unkompliziert ist. ((„true && ((true || false) && false)“ ist bekanntlich was anderes als „true && (true || false && false)“), zumindest für mich. Bevor man sich selber was überlegt, bietet es sich an, einfach eine Bibliothek wie RSQL zu benutzen. Es löst das Problem und ist mit geringem Aufwand einbindbar.
### Beispiel Verwendung von RSQL mit Java und Spring Web
Verwendete Bibliothek:
Ein Filter im RSQL- Format kann als String als z.b. REST-Parameter übergeben werden: „Produktnummer==1234,Name=IN=(‚Max‘, ‚Kim‘, ‚Alex‘)“ entspricht z.b. der sql-Clause: „WHERE Produktnummer = 1234 OR Name in (‚Max‘, ‚Kim‘, ‚Alex‘)“. Das Mapping der FIQL-Darstellung nach einer in sql sähe z.b. so aus:
In einem REST-Controller deklarieren wir ein GET, dass als Request-Parameter einen String erwartet, mit dem eine RSQL-konforme Filteranweisung übergeben wird. Aus der Bibliothek erhalten wir einen RSQL-Parser, der den String in einen booleschen Ausdrucksbaum umwandelt:
```
import cz.jirutka.rsql.parser.RSQLParser;
@RestController
@RequestMapping("/api/v1/order")
public class PurchaseOrderController {
private final PurchaseOrderService purchaseOrderService;
public PurchaseOrderController(PurchaseOrderService purchaseOrderService) {
this.purchaseOrderService = purchaseOrderService;
}
@GetMapping
public ResponseEntity rsqlFeatured(@RequestParam String rsqlFilter, Pageable pageable) {
var expressionTree = new RSQLParser().parse(rsqlFilter);
var result = purchaseOrderService.findAll(expressionTree, pageable);
return ResponseEntity.ok(new PagedModel(result));
}
}
```
Der RSQL-Filterbaum ist visitable, d.h. im Service muss ein Visitor instanziiert werden, der den Baum auf einen Ausdruck abbildet, der von der verwendeten Datenbank, z.b. Postgresql, verstanden werden kann:
```
import cz.jirutka.rsql.parser.ast.*;
@Service
public class PurchaseOrderService {
private final PurchaseOrderRepository purchaseOrderRepository;
public PurchaseOrderService(PurchaseOrderRepository purchaseOrderRepository) {
this.purchaseOrderRepository = purchaseOrderRepository;
}
@Transactional(readOnly = true)
public Page findAll(Node expressionTree, Pageable pageable) {
var query = expressionTree.accept(new NodeToMyDatalayerQueryLanguageVisitor());
return purchaseOrderRepository.findAll(query, pageable).map(PoOverview::of);
}
}
```
Den Visitor (siehe Beispiel) kann man selbst implementieren und dort den RSQL-Filterbaum in die von der verwendeten Datenbank gewünschte Form bringen
```
import cz.jirutka.rsql.parser.ast.*;
final class NodeToMyDatalayerQueryLanguageVisitor extends NoArgRSQLVisitorAdapter {
@Override
public Specification visit(AndNode andNode) {
return andNode.getChildren()
.stream()
.map(node -> node.accept(this))
.reduce(Specification.unrestricted(), Specification::and);
}
@Override
public Specification visit(OrNode orNode) {
return orNode.getChildren()
.stream()
.map(node -> node.accept(this))
.reduce(Specification.not(Specification.unrestricted()), Specification::or);
}
@Override
public Specification visit(ComparisonNode comparisonNode) {
ComparisonOperator operator = comparisonNode.getOperator();
String symbol = operator.getSymbol();
String selector = comparisonNode.getSelector();
List arguments = comparisonNode.getArguments();
return switch (symbol) {
case "==" -> (root, _, cb) -> cb.equal(root.get(selector), arguments.getFirst());
case "=IN=" -> (root, _, cb) -> cb.in(root.get(selector)).value(arguments);
default -> throw new UnknownRsqlComparionOp(symbol);
};
}
}
```
Allerdings gibt es auch Bibliotheken, die diese Aufgabe erledigen, z.b. für [Jpa-Specifications](https://mvnrepository.com/artifact/io.github.perplexhub/rsql-jpa/6.0.33). Allerdings muss man an der Stelle ein bisschen auf Vulnerabilites, transitive Dependencies etc achten und überlegen, ob dieses Teilproblem nicht vielleicht doch eines ist, welches man lieber selbst löst.
### Fazit
Mit RSQL lassen sich mit geringem Aufwand schlanke, robuste APIs schreiben, die Endanwendenden und UX-Designern flexiblen und niederschwelligen Zugriff auf den Datenbestand erlauben ohne die Komplexität im Backend in die Höhe zu treiben. Da die Lösung konsistent in gängige Autorisierung- und Datenzugriffsprozesse einbinden lässt (Der RSQL Filter lässt sich als Requestparameter in einem normalen REST-Request übermitteln und der RSQL-AST ist nicht von Datenbanktreibern out-of-the-box intepretierbar), entsteht kein zusätzliches Risiko.
Als Herausforderung bleibt, Konventionen zu erarbeiten, wie Selektoren und Argumente zu formen sind. Aber das betrachte ich mehr als Chance. Solche Diskussionen müssen ohnehin geführt werden und helfen, eine gemeinsame Sprache zu entwickeln, die jedes Produkt braucht.
### Ein letzter Punkt: Beschränkt sich RSQL auf REST?
Nein, natürlich nicht. Solange die Zeichenkette mit der Filteranweisung nach den Regeln der RSQL-Grammatik erzeugt wird, spielen der technische oder der fachliche Kontext der Anwendung keine Rolle.
**Kategorien:** Development, Tools & Methoden
**Schlagwörter:** API, design, Filtering, Java, methoden, Quality, rest, Softwarenentwicklung
---
### [First experience with AWS IoT - Amazon IoT Hackathon](https://thecattlecrew.net/2016/06/15/first-experience-with-aws-iot-amazon-iot-hackathon/)
**Published:** Juni 15, 2016
**Author:** Attila Nemeth
**Content:**
I recently had the opportunity to visit the Amazon IoT Hackathon in Munich. I did expect a lot from the event and I was not disappointed. But more on the event later, lets start with a brief introduction to the AWS IoT cloud.
Amazon released its IoT Cloud at the very end of last year. Its main purpose is to handle device management and communication from and to the devices (aka „Things“). Its architecture is shown in the next Figure.
[](https://thecattlecrew.net/wp-content/uploads/2016/06/aws-iot-overview.png)
The communication between the devices and the cloud is primarly based on the *MQTT* protocol. The devices publish state changes and custom events to MQTT topics and can subscribe to another topic so that they can be notified by the cloud in case of desired state changes (more on this later).
Before the device first communicates with the cloud, a *certificate* needs to be created for the device. Furthermore, a policy needs to be attached to the certificate, defining the rights of the device (enabling it to post messages to topics or to subscribe to topics). A policy for testing IoT applications could be like:
```
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [ "iot:*" ],
"Resource": [ "*" ]
}
]
}
```
Here we see the first integration within the Amazon Cloud: policies are standard IAM policies as known from AWS Identity and Access Management.
Speaking of integration with other Amazon products: *rules* can be defined within the AWS IoT cloud, which can then forward the message to various other Amazon Cloud products, including S3 for storing the message, Kinesis for stream processing, Lambda for executing custom code on receipt of the message, etc. Rules have an SQL syntax like this:
`SELECT JSonAttributes FROM MQTT topics WHERE FilterConditions based on the JSonAttributes`
so if you have a device submitting temperature values every second to the topic *tempSensorData* and you want to be notified via email if the temperature is above 40 degrees, you can create a rule
`SELECT temp FROM tempSensorData WHERE temp > 40`
and configure an action to send a message to SNS (simple notification service) which will send out the mail.
As you might have noted, however, rules only act on single messages, if aggregation of messages is required, the messages need to be forwarded to Kinesis and the resulting stream needs to be processed.
Devices can also have state information – for example an LED can send its current color to the cloud. This information can be stored in *device shadows*. These device shadows are always available, even if the real device is not connected, so other applications can read the last state of the device. Applications can also update the state of the device shadow (asking the LED to turn green, for example). A state is always made up of a *desired* and a *reported* value.
You can change the desired value in the cloud and this change will be propagated to the real device – the message containing the delta to the previous state is sent to an MQTT topic the device has subscribed to. Once the device has completed the state change, it will report back the current state in the reported attribute. From this moment on, the cloud will know that the change is processed by the device and the device shadow is in sync again. So if you want to change the color of the LED to green, you can change the attribute of the device shadow to
```
{
"desired": {"color":"green"},
"reported": {"color":"red"}
}
```
Once the color is set by the device, it will report back:
```
{
"desired": null,
"reported": {"color":"green"}
}
```
There is also a *registry* component for storing metadata about the devices – device location or manufacturer for example. This information can be used to query a set of devices – for example find all the devices in Munich.
You can do all these activities from the AWS Console but Amazon has also built an *API* do administrative stuff programmatically (if the appropriate policies enable you to do these). In order to speed up connecting devices to the cloud, Amazon has also released [*client SDKs*](https://aws.amazon.com/iot/sdk/) which you can use on your device to connect it to the cloud – currently C, JavaScript and Arduino Yܺn libraries are available.
Now lets back to the event itself:
we started with some presentations where the main concepts of AWS IoT were explained. We also had a short introduction from Intel for the hardware part of the Hackathon. Later on, we started the more interesting part: we have formed teams and each team has received an Intel Edison board with some sensors and a small display attached.
[](https://thecattlecrew.net/wp-content/uploads/2016/06/edison.jpg)
Each team had to build something with the Edison and the AWS products. Time limit was ca. 4 hours. A sample code was provided, which read out all sensor values and sent them to the cloud every second. In the end, each team had to present their idea and vote for the best idea/solution presented.
Our team members had little to no experience with AWS products so it was quite a challenge for us to create something useful within this short time period. We wanted to build something which not only sends data to the cloud but also receives data from it (in order to test the communication in both directions). After a short discussion, we had the idea: we want to build a barkeeper training application.
Our idea was: the Edison is attached to a shaker and with the help of the accelerometer the power of shaking is measured and submitted to the cloud. The values are aggregated there and after a minute a text is sent to display of the trainer (in our case, the display on the Edison) if the shaker was shaked correctly. A button on the bottom of the shaker (in our case, on the Edison) should notice that the shaker is put back on the table and reset the text message.
Creating a certificate, installing it and starting the Edison was an easy task. Sensor messages started arriving in the cloud immediately. Creating a rule and forwarding the messages to Kinesis (for aggregating them) was also no problem.
For the aggregation itself we did not find a solution in the small time window. Apparently this is not so easy to do with the current Cloud offering of Amazon, custom code is inevitable here. Amazon has, however, already noticed that there is a missing component here and started developing [Kinesis Analytics](https://aws.amazon.com/kinesis/analytics/) which should simplify the aggregation of events in the future.
Instead of analysing the stream directly, we have created a Kinesis Firehose rule to buffer events for a minute, then write the aggregated data to S3 in a csv format. Setting up a trigger in S3 which would fire if a new file has been written and start a Lambda script for calculating if the shaking was OK was very straightforward as well.
This way, we have evaluated if the shaker was shaked enough for a minute (although we could not use a sliding window for evaluating data of the last minute because of the lack of stream processing). Next up was to send back a text message to the device. For that, we needed to update the device shadow. It took us quite some time to figure out how to use the SDK to do that but in the end we suceeded in creating a Lambda script updating the device shadow, thus sending data back to the device.
The last task was also an easy one, reacting on a button push to invoke the previously created Lambda script and send the „reset“ text. For this, we have created another rule, which invoked Lambda.
It was interesting to see how easy it is to start with the AWS IoT cloud and configure the first rules. We have noticed that if you can use AWS built-in integrations (from which you do have quite some), you have an easy job configuring your integration. Once you need something more complex, you can use custom code (for example in a Lambda script) but for that some practice and knowledge of the AWS APIs is of advantage. What we really missed was an easy way to aggregate IoT messages and react on the aggregated results – but, as said earlier, Amazon is working on this already.
All in all, it was great to see how multiple AWS components work seamlessly together and how easy it is to start working with AWS. At the end of the day, our solution was voted 2nd of ca. 15 teams, we just cannot complain about this result!
Summarizing my impressions:
- Amazon AWS (and the IoT Cloud) is easy to start with, you can set up sample integration within minutes.
- For more complex integrations custom code is needed. Experience is very helpful if you are planning to do that.
- There is a huge list of available Amazon Cloud products, with lots of different cost structures. In order to find the best combination of products for your integration needs, some experience is needed, too.
- In one sentence: Amazon AWS is easy to start with, challenging to master.
**Kategorien:** Cloud, Tech Events & Networking
**Schlagwörter:** AWS, cloud, English, IoT
---
### [AWS News KW 48](https://thecattlecrew.net/2017/12/04/aws-news-kw-48/)
**Published:** Dezember 4, 2017
**Author:** Marco Buss
**Content:**
Letzte Woche war die re:Invent in Las Vegas, Amazons große Hauskonferenz. Wie zu erwarten gab es eine große Anzahl an Ankündigungen. Deutlich zu viele um sie hier noch einmal im Detail zusammen zu fassen.
Daher verweise ich diese Woche lediglich auf den Blogeintrag meines Kollegen Danilo Schmiedel, der vor Ort war und die wichtigsten Ankündigungen er ersten Keynote von Andy Jessy (CEO Amazon) zusammenfasst. – [OC @ Amazon re:Invent (Part 1)](https://thecattlecrew.net/2017/11/30/oc-amazon-reinvent-part-1/)
Am Donnerstag bot sich dann die Gelegenheit die Keynote von Dr. Werner Vogels (CTO Amazon) als Livestream bei Amazon in Berlin zu sehen. Die wichtigsten Aussagen dieser Keynote waren für mich folgende:
**Conversational Interfaces:** In Zukunft werden immer mehr Interfaces sprachbasiert sein, da es einfach in vielen Situationen die intuitivste Interaktion ist. Bisher waren Interaktionen mit Maschinen durch die Limitierungen der Maschinen begrenzt. Mit dem Fortschritten bei sprachbasierten Interfaces verschieben sich diese Grenzen wieder ein wenig. Ein Beispiel das Werner Vogels brachte kann ich sehr gut nachvollziehen und zwar das Thema Hausautomatisierung. Aus eigener Erfahrung mit simplen Schaltern und Apps, kann ich sagen das die Anbindung eines Sprachinterfaces an die Haussteuerung den meisten Komfort gebracht hat und auch am meisten genutzt wird.
**IOT + Daten:** Ein großer Teil der Keynote handelte von IOT und den Daten die dabei erzeugt werden. Amazon bietet ja bereits einen eigene [IOT Plattform](https://aws.amazon.com/de/iot/). Die in Zukunft auch einige wichtige [Erweiterungen](https://aws.amazon.com/new/reinvent/#iot) bekommen wird. Auch die immer mächtiger werdenden Möglichkeiten des Maschine Learning fallen in diese Kategorie. Auch auf diesem Feld gab es diverse [Ankündigungen](https://aws.amazon.com/new/reinvent/#machine-learning). Am Interessantesten für mich war an dieser Stelle [Sagemaker](https://aws.amazon.com/de/sagemaker/).
**Cloud9:** Die für mich interessanteste Ankündigung war allerdings [Cloud9](https://aws.amazon.com/cloud9/). Amazons eigene Browserbasierte IDE. Wie gut sich damit arbeiten lässt muss zwar noch evaluiert werden, die [Installation](https://thecattlecrew.net/2017/12/01/aws-cloud9-first-steps-creating-the-environment/) lief aber schon mal Problemlos. Ich bin noch skeptisch ob sich damit ein komplettes Projekt inklusive Oberflächen entwickeln lässt. Die Möglichkeit Lambda Functions zu Debuggen ist aber schon mal ein Killerfeature, für das alleine sich die Installation lohnt.
Alle Ankündigungen der re:Invent gibt es in hübscher Form [hier](https://aws.amazon.com/de/new/reinvent/).
**Kategorien:** Cloud
**Schlagwörter:** AWS, Cloud9, SageMaker
---
### [AWS News KW 17 und KW 18](https://thecattlecrew.net/2018/06/25/aws-news-kw-17-und-kw-18/)
**Published:** Juni 25, 2018
**Author:** Marco Buss
**Content:**
## AWS IoT Analytics generally available
Seit dem 24.04. ist das neue AWS IoT Analytics für Jeden in den Regionen US East (N. Virginia), US West (Oregon), US East (Ohio), und EU (Ireland) verfügbar.
IoT Analytics vereinfacht die Bereitstellung einer Datenpipeline für IoT Geräte. Die Analyse der Daten war auch schon vorher möglich, aber mit IoT Analytics vereinfacht sich der komplette Konfigurationsaufwand für die Schritte Datenaufbereitung und Transformation, Anwendung von ML Techniken wie Anomalieerkennung und schlussendlich die grafische Darstellung der Daten.
Weitere Informationen zu IoT Analytics [hier](https://aws.amazon.com/iot-analytics/).
## EC2 Price Reduction „“ H1 Instances
Seit dem 4. Mai haben sich die Kosten für H1 on Demand und Reserved EC2 Instanzen um 15% verringert.
H1 Instanzen bieten 2-16 TB Speicher der für sequentielle I/O Operationen optimiert ist. Damit eignet sich dieser Instanztyp vor allem für BigData Anwendungen.
Weitere Informationen zu H1 Instanz Typen [hier](https://aws.amazon.com/ec2/instance-types/h1/).
**Kategorien:** Cloud
**Schlagwörter:** AWS
---
### [AWS News KW 19 und KW 20](https://thecattlecrew.net/2018/07/05/aws-news-kw-19-und-kw-20/)
**Published:** Juli 5, 2018
**Author:** Marco Buss
**Content:**
## AWS IoT 1-Click
Nachdem die [IoT Buttons der 2. Generation](https://www.amazon.de/AWS-IoT-Button-2-Generation) vom Amazon ca. 1 Jahr in Deutschland verfügbar sind gibt es jetzt eine [neue Version der IoT Buttons](https://www.amazon.de/AWS-IoT-Enterprise-Button-1-Click-Dienst). Die neuen Buttons unterstützen IoT 1-Click. Dadurch wird das Setup und die Verwendung der IoT Buttons stark vereinfacht. Musste man vorher erst entsprechende Zertifikate erzeugen, auf den IoT Button aufspielen und dann auch noch Security Profile anlegen bevor der Button verwendet werden konnte ist dieser ganze Prozess mittlerweile auf 2-3 einfach Schritte reduziert worden.
Der IoT Button ist dabei lediglich das erste Device in Europa das IoT 1-Click unterstützt und benötigt weiterhin ein WLAN. In den USA ist darüber hinaus noch ein Button der LTE-M nutz verfügbar und Amazon sucht weitere Partner die Devices für IoT 1-Click anbieten wollen.
Weitere Informationen zu AWS IoT 1-Click [hier](https://aws.amazon.com/iot-1-click/).
## Amazon Aurora Backtrack
Nachdem DynamoDB bereits eine Restore Funktion erhalten hat (siehe [hier](https://thecattlecrew.net/2018/06/11/aws-news-kw-13-und-kw-14/)) ist dieses Feature ab sofort für alle neu angelegten Aurora Cluster verfügbar.
Damit kann die Datenbank im Falle eines Fehlers auf einen beliebigen Punkt innerhalb des Backtrack Fensters zurückgesetzt werden. Das Fenster kann dabei bis zu 72 Stunden in die Vergangenheit reichen.
Ein weiterer Nützlicher Usecase wäre das zurücksetzen der Datenbank nach einem durchgeführten Test.
Weitere Informationen zu Amazon Aurora [hier](https://aws.amazon.com/rds/aurora/).
## Amazon Sumerian – Generally Available
Nachdem [Amazon Sumerian](https://aws.amazon.com/sumerian/) auf der re:Invent 2017 vorgestellt wurde ist der Dienst jetzt für alle Nutzer verfügbar.
Mit Amazon Sumerian können eigene virtuelle Räume für VR, AR und 3D erstellt werden. Mit Hilfe eines Web basierten Editors können die eigenen Räume ohne Expertenwissen und spezielle Tools erstellt werden.
Die erstellen Umgebungen können im Anschluss für verschiedene Platformen wie Beispielsweise Oculus Rift, HTC Vive aber auch für Browser Umgebungen die WebGL unterstützen deployt werden.
Weitere Informationen zu Amazon Sumerian [hier](https://aws.amazon.com/sumerian/).
## Neue EC2 Instanztypen
Ab sofort sind die neuen C5 Instanztypen verfügbar und lösen die C4 Typen ab. Die neuen Typen bieten eine um 25-50% Reduzierung des Preis/Perfomance Verhältnisses.
C5 Instanztypen sind für rechenintensive Aufgaben wie Batch Verarbeitung, Echtzeitanlaysen, Video Encoding u.s.w geeignet. Für Usecases die darüber hinaus von schnellem Temporären Speicher profitieren sind die neuen **C5d** Instanzen gedacht. Diese sind identisch mit den C5 Instanzen, bieten darüber hinaus aber per NVMe SSD Storage und sind in folgenden Konfigurationen in den Regionen US East (N. Virginia), US West (Oregon), EU (Ireland), US East (Ohio) und Canada (Central) verfügbar.
**Instance Name****vCPUs****RAM****Local Storage****EBS Bandwidth****Network Bandwidth****c5d.large**24 GiB1 x 50 GB NVMe SSDUp to 2.25 GbpsUp to 10 Gbps**c5d.xlarge**48 GiB1 x 100 GB NVMe SSDUp to 2.25 GbpsUp to 10 Gbps**c5d.2xlarge**816 GiB1 x 225 GB NVMe SSDUp to 2.25 GbpsUp to 10 Gbps**c5d.4xlarge**1632 GiB1 x 450 GB NVMe SSD2.25 GbpsUp to 10 Gbps**c5d.9xlarge**3672 GiB1 x 900 GB NVMe SSD4.5 Gbps10 Gbps**c5d.18xlarge**72144 GiB2 x 900 GB NVMe SSD9 Gbps25 Gbps
**Kategorien:** Cloud
**Schlagwörter:** Amazon Aurora, AWS
---
### [AWS News KW 31 und KW 32](https://thecattlecrew.net/2018/08/22/aws-news-kw-31-und-kw-32/)
**Published:** August 22, 2018
**Author:** Marco Buss
**Content:**
## Aurora Serverless MySQL verfügbar
Aurora Serverless war für mich „die“ Ankündigung auf der letzten [re:Invent](https://www.youtube.com/watch?v=1IxDLeFQKPk&feature=youtu.be&t=2595). Aurora Servleress kann erheblich zur Kostenersparnis beitragen, vor allem in Use-Cases mit schwer vorhersehbaren Lasten oder für wenig genutzte Services und das mit MySQL Kompatibilität. Das dürfte viele Migrationen vereinfachen, da die Datenhaltung nicht auf eine DB wie Dynamo migriert werden muss.
Bei der Erstellung eines Aurora Clusters entfallen bei der Wahl von Serverless die Angaben welche Instanztypen der Cluster verwenden soll. Vielmehr ist lediglich die Angabe einer minimalen Kapazität und eine maximalen Kapazität notwendig. Innerhalb dieser Grenzen wird der Aurora Cluster skaliert. Entsprechende Autoscaling Events werden vom Dienst selbständig angelegt. Neben den Kapazitätsgrenzen kann noch definiert werden, nach welcher Zeit ohne Last die Compute Kapazität auf Null skaliert werden soll und somit keine weiteren Kosten verursacht.
Weitere Informationen zu Aurora Serverless [hier](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/aurora-serverless.html).
## Provisioned Throughput für Amazon Elastic File System
Amazon Elastic File System (EFS) ist ein verteiltes Dateisystem, auf das bei Bedarf gleichzeitig tausende von EC2 Instanzen oder lokale Ressourcen zugreifen können. Der mögliche Durchsatz skaliert dabei mit der Größe des Dateisystems.
Für Szenarien mit wenigen Dateien also wenig Volumen aber einem hohen Durchsatz über längere Zeit war EFS bisher keine Option. Mit der Einführung von provisioned throughput ist es jetzt möglich bis zu 1 GiB/Sekunde an Durchsatz zu buchen. Zum Vergleich ein EFS mit 1TiB bietet 50 MiB/Sekunde mit einem Burst von 100MiB/Sekunde für bis zu 12 Stunden am Tag.
Mit provisioned throughput ändert sich auch die Kostenstruktur. Es muss dann für die Größe des Dateisystems bezahlt werden plus die Kosten für den provisioned throughput.
Weitere Informationen zur Wahl des Throughputs [hier](https://d1.awsstatic.com/whitepapers/Storage/amazon_efs_choosing_between_different_performance_and_throughput.pdf).
## AWS IoT Device Defender verfügbar
Immer mehr IoT Geräte wandern in die Haushalte und Unternehmen. Oft wird bei den Geräten aber die Sicherheit nicht ernst genommen. Mit dem AWS IoT Device Defender bietet AWS einen Service mit dem sich die Sicherheit von IoT Geräten erhöhen lässt.
Der IoT Defender prüft kontinuierlich die Konfigurationen der einzelnen Geräte. Das umfasst zum einen die Prüfung der Zertifikate, also das jedes Gerät ein eigenes Zertifikat verwendet oder keine ungültigen Zertifikate verwendet werden. Sollten Geräte nicht den Anforderungen entsprechen wird eine Entsprechende Warnmeldung erzeugt.
Neben der Prüfung der Konfiguration können auch andere Metriken überwacht werden, wie beispielsweise der Datenverkehr der Geräte. Bewegt sich dieser nicht im erwarteten Rahmen kann ebenfalls eine entsprechende Meldung erzeugt werden.
Weitere Informationen zu AWS IoT Device Defender [hier](https://aws.amazon.com/iot-device-defender/).
**Kategorien:** Cloud
**Schlagwörter:** Amazon Aurora, Amazon EFS, AWS, Device Defender, Serverless
---
### [Sensordaten live erleben: Big Data im Kontext der Industrie 4.0](https://thecattlecrew.net/2019/03/25/sensordaten-live-erleben-big-data-im-kontext-der-industrie-4-0/)
**Published:** März 25, 2019
**Author:** mrogolowski
**Content:**
#### Kapitel 1: Projektkontext und verwendete Technologien
Bei der HannoverMesse 2019 präsentieren wir gemeinsam mit einem maschinenverarbeitenden Unternehmen einen spannenden Showcase zur Analyse von Maschinen-Sensordaten und deren Darstellung in einem Dashboard, um den Zustand der Maschine zu überwachen und im Bedarfsfall eingreifen zu können. Es war uns wichtig, den Showcase so nah wie möglich an den realen Bedingungen zu entwickeln. Dafür haben wir keinen Aufwand gescheut:
· Die Umsetzung findet in einer cloudbasierten Umgebung statt.
· Für den Showcase wurde eine Visualisierung mit echtem Mehrwert entwickelt.
· Besucher können eine zusätzliche Visualisierung in der HoloLens erleben.
Die Architektur des Showcases haben wir in der AWS Cloud aufgesetzt. AWS stellt sämtliche Komponenten als Self-Managed Services zur Verfügung, was dem Anwenderunternehmen den Aufwand für die Wartung der Maschinenvisualisierung erspart. Die folgende Abbildung zeigt den groben Aufbau der Architektur, ihre grundlegenden Bestandteile und deren Verbindungen.
Die Architektur setzt sich zusammen aus einer Testmaschine, die unser Partnerunternehmen im Rahmen des Showcases für die Entwicklung zur Verfügung stellte. Diese Maschine sendet die erforderlichen Daten per MQTT im JSON Format an den AWS IoT Core. Dort werden die Daten mithilfe einer Lambda Function weiterverarbeitet, mittels Elasticsearch Service visualisiert und in Amazon S3 persistiert. Soweit, so kurz. Doch was genau leisten die einzelnen Komponenten, und welche Rolle spielen sie im Showcase? Dies möchten wir nun im Einzelnen betrachten, also: „Vorhang auf!“
**AWS IoT Core**
Im ersten Schritt wird der AWS IoT Core verwendet, um die ankommenden Maschinendaten abzugreifen und an die Folgekomponenten weiterzuleiten. In unserem Showcase werden die Daten im JSON Format per MQTT an unseren IoT Core übertragen.
**Amazon Elasticsearch Service**
Im nächsten Schritt werden bestimmte Rohdaten, die keiner weiteren Verarbeitung bedürfen, an den Amazon Elasticsearch Service weitergeleitet. Der Elasticsearch Service kann einerseits zum Zwischenspeichern der Daten verwendet werden und andererseits zur Kommunikation mit dem Visualisierungstool Kibana. Des Weiteren werden transformierte Daten zum Elasticsearch Service geschrieben, die nicht im Rohformat übertragen werden können. Hierbei handelte es sich beispielsweise um Daten, die innerhalb eines Arrays zur Verfügung gestellt wurden. Da Kibana keine Möglichkeit bietet, die Daten eines Arrays darzustellen, teilen wir die einzelnen Daten in dem Array auf.
**Kibana**
Im Showcase entschieden wir uns für Kibana als Visualisierungstool, da Kibana zum einen als Plugin an den Elasticsearch Service angebunden und zum anderen unabhängig von AWS auch on-premises verwendet werden kann. Nachdem die Daten an den Elasticsearch Service weitergeleitet wurden, greift Kibana die Daten über einen Index ab.
**Lambda Function**
Wir standen im Showcase vor der Herausforderung, neben den einfachen Laufzeiten der Messer zusätzlich verschiedene Durchschnittswerte zu berechnen. Aus diesem Grund haben wir die Daten vom IoT Core zu einer Lambda Function weitergeleitet, die für jeden Datensatz ausgeführt wird. Diese Lambda Function erfüllt vor allem zwei Zwecke:
- ***Aufteilung der Arrays***: Die Maschinendaten innerhalb des Arrays werden in einzelne Werte aufgeteilt, die von Kibana verarbeitet werden können.
- ***Berechnung von Durchschnittswerten***: Für den Showcase werden bestimmte Durchschnittswerte visualisiert, die dynamisch berechnet werden müssen.
Von der Lambda Function werden die Daten an den Elasticsearch Service für eine weitere Verarbeitung weitergeleitet. Darüber hinaus werden die Daten an einen Amazon S3 Bucket geschickt, um eine Speicherung der Maschinendaten von bis zu zwei Jahren sicherzustellen.
**Amazon S3**
Zur kostengünstigen und persistenten Speicherung der Maschinen-Sensordaten haben wir einen Amazon S3 Bucket angelegt. Zum einen werden die Rohdaten vom IoT Core in den S3 Bucket übertragen. Zum anderen werden die transformierten Daten ebenfalls im S3 Bucket abgelegt.
In Kapitel 2 folgt eine detaillierte Beschreibung der verwendeten Technologien.
**Hannover Messe**
Eine erste vollständige Live-Demonstration des Showcases mit Testmaschine und Cloud-Anbindung zeigen wir gemeinsam mit unseren Kooperationspartnern vom **01. bis 05. April 2019 bei der HannoverMesse**. Sie planen einen Besuch bei der HannoverMesse? Dann treffen Sie uns! Sie finden unseren Stand in der Digital Factory, Halle 6, D53.
Eine kurze Vorschau können Sie im folgenden Video sehen:
[](https://www.youtube.com/watch?v=h9yvg-pbFHk)
**Kategorien:** Analytics & Insights
**Schlagwörter:** AWS, Big Data, industrie4.0, Kibana
---
### [Überblick im Technologie-Dschungel: Technologie-Management bei OPITZ CONSULTING](https://thecattlecrew.net/2023/03/22/ueberblick-im-technologie-dschungel-technologie-management-bei-opitz-consulting/)
**Published:** März 22, 2023
**Author:** Torsten Winterberg
**Excerpt:** War vor 10 Jahren die Welt für ein mittelständisches IT-Beratungshaus oder eine IT-Abteilung noch relativ überschaubar, so ist die Anzahl der Technologien, mit denen man in IT-Projekten heute in Berührung kommt, sehr stark angewachsen. Wir wollen euch in diesem Blog-Post einen Einblick geben, wie wir bei OC unser Technologieportfolio managen.
**Content:**
War vor 10 Jahren die Welt für ein mittelständisches IT-Beratungshaus oder eine IT-Abteilung noch relativ überschaubar, so ist die Anzahl der Technologien, mit denen man in IT-Projekten heute in Berührung kommt, sehr stark angewachsen.
Wir wollen euch in diesem Blog-Post einmal einen Einblick geben, wie wir bei OC unser Technologieportfolio managen.
**Autoren dieses Beitrags:**
Richard Attermeyer (Chief Architect)
Sven Bernhardt (Chief Architect)
Jens Bleiholder (Chief Architect)
Torsten Winterberg (Director Technology)
Wichtig für uns ist, dass die Tätigkeiten von Projektmitarbeitenden, Accountteams, Zentralbereichen und Management optimal ineinandergreifen, damit wir die gewohnt hohe OC-Qualität beim Kunden dauerhaft und über die ganze Mannschaft leisten können.
Dazu haben wir einen schlanken Technologie-Management-Prozess festgelegt, der durch verschiedene Systeme unterstützt wird:
- TLMT: The Lifecycle Management Tool. Unser Tech-Radar.
- Blueboard: Verwaltung von Tickets zur Durchführung einer Technologieevaluierung.
- OCEH: OC Engineering Handbook. Dokumentation der Technologiebewertungen, Standardarchitekturen und Beratungshandreichungen.
- Oscar: Skillbewertung durch die Mitarbeiter.
- Susy: Vorschlagswesen für Oscar und TLMT zur Erfassung neuer Tech-Items (Funktion in TLMT).
Das Blueboard ist als Jira-Projekt realisiert, die anderen Systeme sind kleine Anwendungen.
Über diesen Systeme liegt ein schlanker Prozess, welcher vom Corporate Development Team und dem OC-Architekturboard bespielt wird.
*Abb. 1: Technologie-Management: Zusammenspiel der Werkzeuge*
## TLMT
Das „The Lifecycle Management Tool“ (kurz TLMT) nutzen wir bei OPITZ CONSULTING, um uns die Vielfalt der Werkzeuge, Technologien und Methoden am IT-Markt zu erschließen und auf die für uns strategischen Technologien zu fokussieren.
Gemäß unserer Strategie #zukunftswirksam, hilft uns das TLMT dabei, proaktiv zu bewerten, welche Technologien unseren Leitthemen (Modern, Automatisiert, Integriert, Sicher) entsprechen, worauf wir unsere Kompetenzen perspektivisch ausrichten sollten und welche Technologien wir unseren Kunden empfehlen (wenn wir die freie Wahl haben).
Zusätzlich erhalten wir durch die Verknüpfung zu unserem Skill Management Tool OSCAR eine einfache Übersicht über die Anzahl unserer Mitarbeiter und deren Tiefe der Qualifizierung pro Technologie. So können wir Rückschlüsse für unsere Wissensdomänen zur Personalentwicklung ziehen, sowie einschätzen, wie gut Kundenanfragen zu unserem Knowhow passen.
Kurzum, das TLMT schafft Transparenz darüber:
1. Was wir für Technologien, Methoden und Standards einsetzen
2. Wie gut wir die Technologien, Methoden und Standards beherrschen
3. Worauf wir uns in der Weiterbildung fokussieren
4. Wie gut Technologien, Methoden und Standards in unser Portfolio passen
## Blueboard
Blueboard steht für eine Innovationsmethode, die Transparenz und Nachhaltigkeit im Ideen-Management fördern soll. Wir haben uns daran angelehnt und unser eigenes, elektronisches Blueboard gebaut. Hierfür haben wir die Möglichkeiten von Jira genutzt, um Ideen und deren Status visualisieren zu können. Ziel ist es, Transparenz über Aktivitäten bei OC zu erzeugen, um nicht Dinge doppelt zu machen und auch um zu wissen, wer sich gerade mit welchem Thema beschäftigt.
Des Weiteren ist das Blueboard ein Hilfsmittel bei der Fokussierung und Bündelung unserer Schlagkraft. Klar ist, dass wir nicht alle Themen gleichzeitig bearbeiten können. Doch welche Themen sind gerade wichtig für die Entwicklung von OC und was wollen und wünschen die Kunden? In verschiedenen Gremien werden die einzelnen Ideen diskutiert und die Auswirkungen auf den Markt und OC betrachtet. Darauf basierend wird dann entschieden, was mit der Idee passieren soll, also geht sie in die Umsetzung, wird sie erstmal zurückgestellt oder liegt sie nicht im Fokus von OC.
*Abb. 2: Status-Modell für Items im OC-Blueboard*
Alle Mitarbeiter sind aktiv aufgerufen Ideen, die unsere Kunden, OC oder sich selbst weiterbringen, ins Blueboard einzutragen.
Je mehr Informationen initial gefüllt sind, umso einfacher ist es für das passende Gremium, die Entscheidung zu treffen. Sofern Kollegen gerade nicht voll durch Projekte ausgelastet sind, finden sie hier Ideen, bei denen sie unterstützen können.
Die einzelnen Bereiche des Blueboard sind über Swimlanes abgebildet. Hinter jeder Swimlane steht ein eigenes Gremium, das sich um die Tickets kümmert:
- F&E: Technologie-Themen und Technologie-Evaluierungen
- (Technologie-) Partnerschaften
- Business Development (neue Themen mit Markteintrittsziel)
- (Technologie-) Communities
- Interne Systeme
- Delivery Process & Knowledge (Optimierung und Weiterbildung)
- Allgemeine Verbesserungsvorschläge
## OCEH
Das OC Engineering Handbuch (OCEH) entwickelt sich zu DER Wissensquelle für alle OC’ler. Damit OC die in der Strategie definierten Ziele erreicht, werden im OCEH die verschiedenen Bereiche adressiert, die für die Erstellung und den Betrieb von Lösungen notwendig sind.
Die Art der Leistungserbringung beim Kunden definiert den notwendigen „OC-Way“, also die OC-bewährte Herangehensweise.
Und dies verstehen wir unter dem „OC-Way“:
- Wie wir das Problem des Kunden analysieren (Auftragsklärung, Business Problem Understanding, Early Solution Design)
- Wie wir eine Lösung entwerfen (Lösungsarchitektur + Design)
- Wie wir Teile einer Lösung umsetzen (Service Design und Development)
- Wie wir eine Lösung produzieren (Local Development, Continuous Integration and Deployment, Staging, Test und Verifikation)
- Wie wir eine Lösung übergeben (Service Transition)
- Wie wir eine Lösung betreiben (Operations und Support)
- Wie wir eine Lösung weiterentwickeln (Application Maintenance)
Damit ist das OCEH in folgenden Situationen hilfreich:
- Eine Begründung für einen bestimmten Technologiestatus finden (über die zugehörige Technologieevaluierung)
- Beantwortung der Frage, welche Technologien bei der Erstellung einer Lösungsarchitektur verwendet werden sollten
- Welche Erfahrungen haben wir bei OC mit einer bestimmten Technologie?
- Was soll ich beim Einsatz einer bestimmten Technologie / Methode beachten?
Das OCEH gliedert sich in diese inhaltlichen Bestandteile, die in den folgenden Abschnitten genauer beschrieben werden:
- Beratungshandreichungen
- Engineering Guidelines
- Lösungs-Architekturen (konkret)
- Architekturschablonen und Standardarchitekturen
- Technologie-Evaluierungen
Generell gilt: Das OCEH ist ein lebendes Dokument, das redaktionell vom OC-Architekturboard betreut wird. Es lebt aber davon, dass jeder seine Erfahrungen beisteuern kann. Dazu nutzen wir das aus Open Source Projekten bekannte „Fork and Pull Request“-Prinzip. Dies gilt auch für schon bestehende Teile, die OC‘ler genutzt und vielleicht um eigene Aspekte ergänzt haben.
Wenn ihr im Rahmen von Projekten eine Evaluierung oder eine Architekturentscheidung getroffen habt, dann kann diese auch anderen OC-Kollegen über das OCEH zur Verfügung gestellt werden.
Unsere Kunden erwarten zu Recht, dass wir sie aufgrund der Erfahrung bei anderen Kunden beraten können. Eine solche Austauschplattform zu haben, ist ebenfalls ein Mittel, um Kopfmonopole aufzubrechen.
Das OCEH wird in AsciiDoc geschrieben, arbeitet mit einfachen Git Fork und Merge Workflows und wird mittels Antora als Webseite veröffentlicht.
### Beratungshandreichungen
In diesem Sub-Kapitel im OCEH sammeln wir Dinge, die sich beim Kunden bewährt haben und im Beratungskontext helfen können.
Es stellt dar, wie sich OC auf Basis von Projekterfahrungen zu einem bestimmten Themenbereich positioniert, etwa zum Einsatz von Kubernetes in unterschiedlichen Einsatzszenarien.
### Engineering Guidelines
Sich auf Spielregeln und Best Practices im Einsatz von Technologien festzulegen, ist in jedem Projekt hilfreich. In diesem Sub-Kapitel sammeln wir bewährte Guidelines aus der OC-Praxis, etwa:
- Angular Guidelines
- REST Guidelines
- Apache Camel Guidelines
- Database Development Guidelines
- Git Guidelines
- usf.
Diese Guidelines werden in unseren Projekten verwendet, um eine Einheitlichkeit bei der Projektumsetzung, bezogen auf die entsprechenden Aspekte, gewährleisten zu können. Zudem wird die Delivery hierdurch effizienter, da man sich keine eigenen Gedanken zu immer wiederkehrenden Fragestellungen machen muss.
Neue Erkenntnisse aus den Projekten fließen hier immer wieder zurück, wenn sich Vorgaben als nicht praktikabel erweisen.
### Lösungs-Architekturen (konkret)
In diesem Sub-Kapitel findet ihr beispielhafte, anonymisierte Lösungsarchitekturen, die wir im Rahmen von Angeboten für Kunden ausgearbeitet haben. Sie sind ggf. nachträglich aufbereitet und ihr findet entsprechende Hinweise, falls wir bei einem Review festgestellt haben, dass wir in der Zwischenzeit etwas anders machen würden.
Beispielhafte Inhalte:
- Moderne Integrationsarchitektur für Ablösung eines alten Enterprise Service Bus (ESB)
- API-Management Konzept für Open Data, Partner-Data, Internal-Data
- Integration vorhandener Daten über API Gateway und Integrationsmuster, um neue Use-Cases zu unterstützen.
- Ansteuerung von verschiedenen Backend-Diensten über eine cloud-native Integration mittels Camel und Priorisierung der Anfragen über priorty based messaging.
- Aufbau einer hybriden, Multi-Cloud API Plattform auf der Basis von Kong
### Architekturschablonen und Standardarchitekturen
Wenn wir uns über Architekturschablonen und Standardarchitekturen unterhalten, dann müssen wir erst einmal ein paar Begriffe definieren.
**Architekturstil**: Ein Architekturstil bezeichnet eine abstrakte Sammlung, die von konkreten Elementen und Aspekten einer Architektur abstrahiert. Sie besteht daher aus einer Menge an gemeinsamen Annahmen und Randbedingung, die über alle konkreten Architekturen gleich ist. Es werden damit eine Menge an konkreten Designentscheidungen schon vorweggenommen und bestimmte Aspekte werden isoliert betrachtet. Beispiele für einen Architekturstil sind
- Microservices Architektur
- Monolithische Architektur
- Schichtenarchitektur
- Datenbank-zentrische Architektur
- Event getriebene Architektur
- REST
- SOA
**Architekturschablone**: Eine Architekturschablone kombiniert unter Umständen mehrere Architekturstile zu einer abstrakten Architektur. Wir gehen davon aus, dass diese Art der Architekturschablonen für eine gewisse Klasse an Anwendungstypen passt, ohne dass dort konkrete Technologien genannt sind. Beispiele
- Cloud Native Systems
- Integrationsarchitekturen
- Analytische Architekturen
Wir beschreiben Schablonen durch die zu realisierenden Technischen Capabilities. Dabei kann eine solche Capability auch Aspekte eines Architekturstils enthalten, etwa „event-based communication“.
**Standardarchitekturen**: Standardarchitekturen konkretisieren die Schablonen durch eine Auswahl von konkreten Technologiebausteinen. Diesen Standardarchitekturen liegen weitere Glaubenssätze und Randbedingungen zugrunde. Glaubenssätze und Randbedingungen schränken den möglichen Lösungsraum ein. Wir sprechen auch von „Flavors“. Beispiele können sein:
- Mixed Flavor (bspw. für Hybride Architekturen)
- AWS Flavor
- Azure Flavor
- Oracle Flavor
**Lösungsarchitektur**: Eine konkrete Lösungsarchitektur entwickeln wir für ein konkretes Kundenproblem. Da Probleme so unterschiedlich sind, wie unsere Kunden, können wir in der Regel nicht einfach mit der Präsentation einer Standardarchitektur antworten. Wir müssen die Architekturtreiber erheben und eine passende Antwort entwickeln. Dabei können Standardarchitekturen und Architekturschablonen eine gute Hilfestellung sein. Die definierten Standardarchitekturen sind in diesem Zusammenhang als eine Art Baukasten zu verstehen, aus dem wir uns bedienen können, um eine passgenaue Lösungsarchitektur für ein Kundenproblem zu definieren. So können wir bspw. mit Hilfe der Standardarchitekturen für „Cloud Native Systems“ und für „Integration“ eine Lösungsarchitektur für eine Cloud-native Integrationsplattform entwerfen, die On-premises, in der Cloud oder auch hybrid und Multi-Cloud deployed und betrieben werden kann.
Die Schablonen helfen durch die Auflistung von häufig notwendigen technischen Capabilities, dass wir an alles denken, was im konkreten Kontext wichtig ist; also dienen die Schablonen als eine Art Checkliste. Dabei ist nicht immer die Adressierung aller Capabilities notwendig. Wir treffen die Entscheidung aber bewusst (und dokumentieren diese), damit wir z.B. im Projektverlauf nicht unliebsame Überraschungen erleben, weil wir vergessen haben einen wichtigen Teil zu schätzen.
Gleichzeitig helfen uns Standardarchitekturen in Pre-Sales Situationen in eine Diskussion mit Kunden einzusteigen: Wenn wir die Wahl haben, dann würden wir ihr Problem wie in unserer Standardarchitektur beschrieben lösen. Sehen Sie auch alle Elemente für notwendig? Worauf wollen Sie verzichten? Das hat aber folgende Auswirkungen. Wir können auch eine andere Technologie verwenden, aber das ist mit größerem Risiko oder Aufwand verbunden.
### Technologie-Evaluierungen und ADRs
Wird eine für OC neue Technologie zur Aufnahme ins OC-Technologie-Portfolio vorgeschlagen, geschieht dies über einen Vorschlagseintrag im TLMT. Das OC-Architekturboard (OCAB) bewertet den konkreten Vorschlag. Soll eine Verprobung stattfinden, wird ein Evaluierungsticket im Blueboard erzeugt und die Ergebnisse werden in Form einer Technologieevaluierung im entsprechenden Sub-Kapitel im OCEH dokumentiert.
Beispiele:
- Pyramid Analytics
- Confluent Cloud
- Ionos Cloud
- Service Meshes
- Go
- …
Allgemeinere Architekturentscheidungen werden in Form von bewährten ADRs (Architecture Decision Records) dokumentiert. Des Weiteren werden ADRs geschrieben, wenn es für die Umsetzung von Capabilities mehrere Technologiebausteine gibt. Der ADR definiert dann den zu präferierenden Baustein und begründet, warum das so ist.
Beispiele für ADRs:
- Rancher Desktop als Docker Desktop Umgebung
- Nutzung eines Key-Value-Stores zur Speicherung einer Service Konfiguration im mixed Flavour
- Nutzung von Prometheus für cloud-natives Service Monitoring
- Nutzung von Kong als API Gateway im mixed Flavour
- Nutzung von Caching Reverse Proxies im Mostly-AWS Flavour
## Wissensdomänen
Das Management von Technologien auf Ebene der einzelnen Tech-Items ist wichtig, aufgrund der hohen Anzahl von Tech-Items jedoch sehr schnell unübersichtlich und schwer handhabbar.
Aus diesem Grund verwenden wir zur Komplexitätsreduktion eine Bündelung vieler Tech-Items. Wir sprechen von den sogenannten Wissensdomänen:
*Abb. 3: Die OC-Wissensdomänen*
Auf Basis dieser Wissensdomänen planen wir Aus- und Weiterbildungen im Kontext des Technologie-Managements.
Das Trend-Scouting, also das Auffinden neuer technischer Strömungen, neuer Technologien, Frameworks oder Lösungsansätze wird so ebenfalls handhabbarer.
## Das OC-Architekturboard (OCAB)
Das OCAB erweitert das Corporate Development Tech-Team und ist zentrales Instrument für #zukunftswirksame OC-Lösungen. Es stellt die technologische sowie methodische Kompetenz von OC für unsere #zukunftswirksamen IT-Lösungen sicher.
Dort Wirkung erzeugen, wo Bedarf ist: In Kundenszenarien, in den Communities, vor Ort. Immer enablend für andere.
Hauptaufgaben des OCAB:
- Tech-Portfoliomanagement und Bereitstellung eines klar kommunizierten Tech-Stacks: Wir helfen unseren Projekten durch eine Standardisierung der technologischen Basis
- Wissensdrehscheibe für Projekterfahrungen: Aus laufenden Projekten lernen und laufende Projekte besser machen. Wiederverwendbarkeit von bereits gelösten Themen. Deliveryfähigkeit verbessern (Qualität).
- Support beim Gewinnen von „modernen“ Projekten (Akquise & Ausschreibungen; im Enablement-Modus für Andere; „mehr Lösungsarchitekten haben“; mehr moderne Technologien, mehr Projekte, Attraktivität als Arbeitgeber)
- Kommunikation über Technologien sicherstellen nach innen und außen (u.a. OC Engineering Handbook, OC TechTalks, Tech-Blog, Fachartikel, Konferenzen)
Das OCAB-Leistungsangebot gliedert sich in drei Bereiche:
1. Technologie-Management / Wissensmanagement (Basis für Akquise und Umsetzung)
2. Unterstützung bei Akquise
3. Unterstützung bei Projekt / Produkt / Service
## Das OC-Forum
Unser Forum ist ein Ort zum technischen Austausch und Quell für wichtige Wissensfundstücke im Projektalltag.
Es ist wichtig, wenn man nicht nur Kollegen eines Teams ansprechen will, sondern das gesamte Wissen aller Kollegen anzapfen möchte.
Wir hatten schon vor Jahren ein Forum und haben es bei der Einführung von Microsoft Teams zunächst abgeschafft. Aus heutiger Sicht lässt sich sagen: das war eine grenzwertig gute Idee. Teams hat viele Vorteile, die Funktionalität der Abbildung eines Forums gehört leider nicht dazu.
Wir haben gelernt und daher ein neues Forum aufgesetzt. Bei der Struktur haben wir uns bewusst an unseren Wissensdomänen orientiert, um dieses Denkmodell in der täglichen Praxis zu verankern.
## Die OC Communities
Neben den Werkzeugen gibt es auch die Möglichkeit des Netzwerkens in Communities.
Jede Community richtet sich an den strategischen Zielen von OC aus. In den Communities tauschen wir uns mit anderen am Thema interessierten Mitarbeiter:innen aus und vergrößern so unser OC-Netzwerk. Die Communities treiben aus ihrer Sicht relevante Aufgaben und gestalten so aktiv die Zukunft von OC mit.
In den Communities wird gelernt, neue Technologien werden ausprobiert, evaluiert und angewendet. Hieraus ergeben sich viele Synergien zum Technologie-Management in den Kategorien der Wissensdomänen.
Beispiele für OC-Communities:
- Next Level Analytics (C42)
- Data Engineering
- DevOps Infrastructure- & Container-Experts (DICE)
- Software-Development-Architektur
- Low Code
- PostgreSQL
- Agile Softwareentwicklung
- Projekt Management
- Team Management
## Schlussbemerkung
Wir hoffen, euch hiermit einen guten Überblick über das Technologie Management gegeben zu haben, das aus unserer Sicht auf diesem Niveau für einen professional arbeitenden IT-Lösungsexperten wie OC absolut unabdingbar ist. Hat es euch gefallen? Sind Fragen aufgetaucht? Wir freuen uns über euer Feedback!
Richard, Sven, Jens und Torsten
**Kategorien:** Tools & Methoden
**Schlagwörter:** Corporate Development, Strategie, Technologiemanagement, Technologieradar
---
### [ETL mit LLM: Warum KI meine Zeichenkünste ernster nimmt als meine Kunstlehrerin](https://thecattlecrew.net/2025/12/19/etl-mit-llm-warum-ki-meine-zeichenkuenste-ernster-nimmt-als-meine-kunstlehrerin/)
**Published:** Dezember 19, 2025
**Author:** Sebastian Pospiech
**Content:**
Vor Kurzem schrieb ich davon, wie Human-Computer Interaction (HCI) unsere Art und Weise, wie wir mit Computern interagieren, ändert – und sprang dann in eine Nische meines Herzensthemas Business Intelligence: dem ETL (Extract, Transform, Load).
Auf dieser Reise habe ich euch berichtet, dass das ETL in so einer Art kleiner Krise steckt. Wo bis vor fünf Jahren grafisch basierte Low-Code-Ansätze dominierten, kehrt man aus vielfältigen Gründen nun zurück in echtes Coding. Absoluter Change-Horror für unseren inneren Elefanten.
Probieren wir doch mal aus, ob uns das LLM (Large Language Model) retten kann …
## Die Demo
Ich bekomme CSV-Dateien mit Informationen von einer Photovoltaik-Anlage. Darin enthalten ist eine Dimension: Zeit. Die Daten sind Aggregate im Abstand von ca. 5 Minuten. Erste kleine Gemeinheit: technologiebedingt können es auch mal 5:01 Minuten sein oder 5:03 Minuten.
Dazu gibt es eine Reihe von Fakten wie den Ertrag, die Netzeinspeisung usw., jeweils in Kilowatt angegeben als Aggregat für dieses „ca. 5-Minuten“-Intervall.
CSV-Datei mit den Werten der PV-Anlage
Säulendiagramm zu den Tagesaggregaten der PV-Anlage (KI-generiert)
## Versuch 1: Eine textuelle Beschreibung für ein einfaches Importieren
Das LLM bekommt eine CSV-Datei mit den oben genannten Inhalten und folgende Beschreibung:
Ich möchte, dass du ein Python-Skript schreibst: – Lese eine oder mehrere CSV-Dateien mit diesem Format und Inhalt
– Schreibe die Inhalte 1:1 in eine MariaDB-Tabelle namens `stage_pv`
– Bitte erzeuge auch ein DDL mit den Create-Befehlen
– Nach Abarbeitung einer Datei, schiebe sie in den Unterordner `Archiv`
– Vermeide Leerzeichen in Spaltennamen und füge eine Spalte mit dem Dateinamen hinzu, aus dem die jeweilige Zeile kommt
– Die Datenbank erreichst du über `localhost:3306`, Benutzername: `demouser`, Passwort: `123`; Schema: `demo`
### Was hat funktioniert?
- Ich bekomme ein lauffähiges Python-Skript.
- Ich kann den Pfad als Parameter mit angeben.
- Das LLM importiert eine CSV oder iterativ mehrere.
- Es hat meine Anweisungen bezüglich der Daten, des Logins zur Datenbank und der Archivierung der Datei umgesetzt.
### Was hat nicht so gut funktioniert?
- Ich habe nicht erfahren, welche Python-Bibliotheken ich noch herunterladen muss.
- Das DDL, um die Tabelle zu erstellen, ist eingebettet. Das brauche ich bei einem regelmäßig laufenden Job nicht. Ein einmaliger DDL-Befehl wäre mir lieber gewesen.
Ganz ehrlich: Zwei Minuten Arbeit und ich habe ein Skript, das ich so laufen lassen kann und das seinen Job macht. Keinen komplexen. Aber es läuft, ist leserlich formatiert und in Funktionen untergliedert.
Die vom LLM generierte Staging-Tabelle
Die Abstriche sind Nebensache und lassen sich mit einem „Kannst du mir bitte das Create-Skript als .sql einzeln geben?“ lösen. Ich habe hier auch nicht präzise gepromptet.
Allerdings: Während ich dies schreibe, nutze ich das taufrische OpenAI-5.2-Modell. Mit dem 5.0 hat der gleiche Prompt auch die beiden Negativpunkte besser gelöst.
Sei’s drum. Weiter geht’s.
## Schaffen wir Fakten
Ja, so einen einfachen Staging-Job zum Import von Hand zu schreiben ist nervig, aber das kann man heute auch super generisch erledigen. Als Data-Lakehouse-Betreiber hat man sein Ingestion-Framework, welches das ziemlich schnell erledigen sollte, parat. Da braucht’s die KI im Grunde nicht.
Gehen wir einen Schritt weiter und erzeugen echte Kennzahlen.
Mein Prompt:
Ich möchte außerdem, dass du eine View v\_fkt\_pv anlegst, die auf der stage\_pv basiert und neben den gegebenen Spalten zusätzlich eine Umrechnung in Kilowattstunden anbietest sowie die Autarkie pro Zeile. Ich möchte, dass du eine fkt\_pv anlegst, die den Output der View persistiert und mit jedem Ladelauf aktuell gehalten wird.
Ich möchte, dass du eine fkt\_pv\_agg anlegst, die eine Aggregation der Einzelwerte auf Tagesbasis vornimmt.
Ich beschreibe also relativ präzise, wie er die Faktenschicht bauen soll, nämlich mit einer View als Definition für Transformationen und einer Persistenzschicht. Allerdings verrate ich dem LLM ein paar Dinge NICHT.
So erfährt es
- nichts davon, wie es auf Kilowattstunden kommt,
- nichts davon, dass die Zeilen Aggregate unterschiedlicher Länge beinhalten – was entscheidend ist für eine korrekte Umrechnung in kWh,
- und ich erzähle auch nicht, was ich mit „Autarkie“ meine.
Und siehe da. Es riecht den Braten:
(s.stromerzeugung\_kw \* (IFNULL(TIMESTAMPDIFF(SECOND, LAG(s.uhrzeit) OVER (PARTITION BY s.source\_filename ORDER BY s.uhrzeit), s.uhrzeit), 300) / 3600.0)) AS stromerzeugung\_kwh,Statt auf fixe 5-Minuten-Intervalle zu gehen, baut es eine LAG-Funktion in die Abfrage ein und macht es sauber, fragt mich aber gleichzeitig:
*„Wenn du mir kurz sagst, ob deine Daten immer 5-Minuten sind (oder variabel), kann ich dir die kWh-Berechnung noch so anpassen, dass sie:*
*– entweder fix per Parameter läuft (z. B. –interval-seconds 300)*
*– oder robust per LEAD/LAG + Plausibilitätskappung (z. B. max. 15 min, min. 1 min) gerechnet wird.“*Das heißt, die KI merkt, dass man hier vereinfachen könnte, wenn die Datenqualität etwas besser wäre.
Auch die Autarkie, also den Anteil am Eigenverbrauch, der über die PV-Anlage abgedeckt wird, berechnet sie korrekt als **1 – (Netzbezug / Stromverbrauch)** inkl. 0-Teiler-Absicherung.
## Und jetzt die Sternchenaufgabe
Ich gebe der KI den Endgegner: meine Zeichenkunst. Ich fertige ganz im klassischen ETL-Style einen graphischen Datenfluss an und gebe ein paar Stichwörter mit, wie z. B., dass die Quelle eine CSV ist, welche Tabellen ich erwarte und welche KPI.
Der Prompt sieht so aus:
Ich habe dir eine CSV-Datei mitgegeben. Das ist ein Beispiel für eine tägliche Quellsystemlieferung. Bitte implementiere eine ETL-Strecke, wie im PNG skizziert, für diese CSV.Skizze der ETL-Strecke
### Die KI ist nicht intelligent
An dieser Stelle sei erwähnt: Eine KI besitzt natürlich keine echte Intelligenz, auch wenn das „I“ dies suggeriert. Hinter ihr steht ein Algorithmus – ein kompliziertes Matheprogramm, das ausrechnet, wofür man es geschaffen hat. Es sind clevere und komplexe Aufgaben, aber am Ende sind es Matheaufgaben. Das LLM ist in der Lage, einen Text aus einer Datenbank entgegenzunehmen und für jedes Textstück Vektoren abzurufen – dargestellt als Zahlen, die das Wort beschreiben – und dann ähnliche Wörter als Antwort zu finden. Das sind Wörter mit nahegelegenen Vektoren, vereinfacht ausgedrückt. Und diese nahen Wörter nach und nach immer wieder durchgerechnet ergeben dann die Antwort.
### Was brauche ich für ein gutes Ergebnis?
Damit ich ein gutes Ergebnis erhalte, kommt es also darauf an, dass
1. eine gute OCR-Erkennung vorgeschaltet ist, die meine Handschrift erkennt
2. und meine Skizze genug beschreibende Elemente enthält.
Als erstes fällt auf, dass deutlich länger „nachgedacht“ wird als zuvor. Allerdings habe ich nun auch die komplette Anforderung eingekippt, nicht wie zuvor in zwei Teilen. Das LLM suggeriert mir erst mal, es habe verstanden, was ich will:
*„Hier ist eine komplette ETL-Strecke für deine tägliche PV-CSV – exakt nach der Skizze:*
*CSV ? stge\_pv (1:1) ? fkt\_pv (+ kWh-Spalten + Autarkie) ? fkt\_pv\_agg (Tages-SUM je Typ)“*Das heißt, die OCR-Erkennung scheint funktioniert zu haben. Mehr lässt sich daraus zunächst nicht ableiten. Offensichtlich ist die 1:1-Wiedergabe dessen, was ich möchte, in einem Vektorraum mit nahe beieinanderliegenden Repräsentationen noch kein Ausdruck von tatsächlichem Verständnis. Übrigens ein Grund, warum die KI immer so „selbstsicher“ und korrekt wirkt und doch, wenn sie etwas nicht kann, ganz zwangsweise halluziniert (lügt).
Dieses Mal wird mir eine ZIP-Datei angeboten. Das LLM liefert neben dem eigentlichen Code ein docker-compose-File, das eine lokale Datenbank startet, sowie eine README und eine requirements.txt. Im Vergleich zum vorherigen Prompt wählt es damit an einer Stelle, an der ich in beiden Fällen Freiheitsgrade gelassen habe, einen anderen Lösungsweg. Der Prompt war allerdings etwas präziser: „Die Datenbank erreichst du über …“ suggeriert, dass diese bereits existiert. Daher wurde im ersten Versuch kein docker File bereitgestellt, welches eine Datenbank hochfährt. Hier schon, da es keine Aussage gab, ob ich eine Datenbank erstellt haben oder nur ansprechen möchte.
Ich übernehme lediglich den Python-Code und lasse die restlichen Artefakte weg. Wie zuvor führe ich ihn blind aus – ganz im Sinne eines fail-fast-Ansatzes. Und er failt fast: keine Datenbankverbindung. Bei der Analyse stelle ich fest, dass meine handschriftliche Vorlage nicht korrekt erkannt wurde; ich passe den Datenbanknutzer an. Zusätzlich scheint das diesmal verwendete SQLAlchemy Probleme mit der DNS-Namensauflösung zu haben. Statt localhost nutze ich daher 127.0.0.1 – und siehe da: es läuft.
Ich erhalte die Staging-Tabelle (mit dem Namen „stge“) sowie beide gewünschten Faktentabellen. Auch in dieser Version werden alle KPIs korrekt berechnet. Beim Durchlesen des Codes fällt jedoch schnell die veränderte Herangehensweise auf: Während zuvor stark SQL-lastig gearbeitet wurde – was ich durch die View explizit intendiert hatte –, wird die Business-Logik diesmal deutlich näher am Python-Code umgesetzt.
Nachfolgend ein Ausschnitt aus der Berechnung der kWh-Stunden:
Ein Auszug des Skripts
Die Faktentabelle mit dem Tagesaggregat sieht diesmal völlig anders aus:
Tabelle mit dem Tagesaggregat der PV-Anlage
Fachlich ist sie korrekt, aber sie wurde transponiert. Statt einem Attribut je Kennzahl, gibt es eine Spalte für die Metrik und eine beschreibende Spalte. Die Skizze ließ hier einfach mehr Spielraum zur Interpretation des Ergebnisses zu als ein gut formulierter Prompt.
Dennoch: Für eine so lieblos dahingeschmierte Skizze wie meine war das Ergebnis durchaus brauchbar.
## Fazit
Ich habe in diesem Beitrag praktisch gezeigt, wie die Theorie des HCI im Sinne von *Die Arbeit mit einem Computer ist ähnlicher zur Kommunikation mit einem Gegenüber als dem Nutzen eines Werkzeugs (und mit LLMs erst recht)* für eine Nische der Softwareentwicklung aussehen kann.
Der Test mit dem OpenAI-Modell 5.2 war durchaus gut, und in dieser Qualität kann man verwendbaren Code produzieren. Eine fachliche Beschreibung und eine Zeichnung, die das Wesentliche sichtbar macht, müssen als Anforderungsdokumentation ohnehin angefertigt werden. Es ist also denkbar, eine verständlich geschriebene und strukturierte Story als Aufsatzpunkt zum Coden zu nehmen.
Für die angesprochene Nische ETL, die sich aktuell in einem großen Change befindet, könnten LLMs eventuell diese Lücke füllen und eine Hilfestellung für Menschen sein, die sich nun umstellen müssen.
Der zuletzt erzeugte Code ist übrigens inklusive Kommentaren 337 Zeilen lang. Das grafische ETL-Tool Talend, in dem dieselbe Semantik abgebildet wurde, hat hingegen 9.319 Zeilen Java-Code produziert – was einer der Gründe dafür ist, warum diese Tools kritisch betrachtet werden.
### Müssen wir nun Sorge um unsere Jobs haben?
Nein. Ohne Verständnis für Datenmodellierung, ETL und Co. würden wir
1. nicht verstehen, was da passiert, könnten außerdem nicht debuggen und müssten dem LLM vollends vertrauen.
2. könnten wir die Prompts nicht präzise genug schreiben.
3. ist das LLM nur so gut wie das Wissen, mit dem es gefüttert wurde.
Es braucht also die Entwickler:innen da draußen, die Lösungen finden, Kennzahlen definieren und Berechnungen implementieren, damit das LLM diese finden und wiedergeben kann. Denn mehr tut es nicht: Es gibt Wissen wieder, das ein Mensch gefunden hat. Die Suche nach dem passenden Wissen wird nur leichter.
---
## Mehr aus dieser Serie lesen?
Diese Reihe lohnt sich für alle Analytics-Expert:innen, die verstehen wollen, wie KI und LLMs unsere tägliche Praxis im BI- und ETL-Umfeld verändern.
1. **Was haben ein Hammer und ein LLM (nicht) gemeinsam?**
In diesem Einstiegsteil geht es um die Grundidee hinter LLMs und Human-Computer Interaction: Warum ein LLM kein Werkzeug im klassischen Sinne ist, wie natürliche Sprache zur neuen Schnittstelle wird und welche Rolle das für die Interaktion mit Systemen spielt.
Hier weiterlesen: [Was haben ein Hammer und ein LLM (nicht) gemeinsam?](https://thecattlecrew.net/2025/10/02/was-haben-ein-hammer-und-ein-llm-nicht-gemeinsam/)
2. **Vibe Coding im BI-Bereich – Wie KI uns ETL-Entwickler retten kann**
Der nächste Beitrag der Serie widmet sich dem Trend Vibe Coding, bei dem KI-gestützte Interaktion die Art verändert, wie Code entsteht und Workflows definiert werden. Er beleuchtet, wie dieser Ansatz für BI-Teams aussehen kann und welche Chancen er für ETL-Entwickler bietet.
Hier weiterlesen: [Vibe Coding im BI-Bereich: Wie KI uns ETL-Entwickler retten kann](https://thecattlecrew.net/2025/11/24/vibe-coding-im-bi-bereich-wie-ki-uns-etl-entwickler-retten-kann/)
**Kategorien:** AI & Data Science, Analytics & Insights
---
### [Was machen Business Analysten? – Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
**Published:** April 30, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten lieben das Unbekannte. Sie entdecken, analysieren und bringen Struktur ins Chaos – und dabei spielt Sprache eine zentrale Rolle. Gemeinsam mit Fachleuten entwickeln sie Lösungsansätze, übersetzen Ideen in Konzepte und helfen, Ergebnisse in produktive Bahnen zu lenken.
Vor allem in der Zusammenarbeit mit Informatiker:innen, Mathematiker:innen und Physiker:innen sind Business Analysten unentbehrlich. Sie sind geduldig, analytisch und gewissenhaft – denn Sicherheit und Klarheit stehen an erster Stelle. Und natürlich: Dokumentation ist ihr zweiter Vorname. Besonders im Anforderungsmanagement, dem Lieblingsbegriff vieler Analyst:innen, zeigt sich ihre Stärke.
---
Neugierig? Hier geht’s zu den ersten beiden Teilen der Serie:
[Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
[Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
Aber nun zurück zu diesem 3. Teil der Serie – Let’s go!
---
## Was sind eigentlich Anforderungen?
In Projekten fällt das Wort „Anforderungen“ oft – und nicht immer ist klar, was gemeint ist. Es wird fast inflationär verwendet, doch selten sauber definiert. Tatsächlich sind Anforderungen oft vage Ideen, noch nicht dokumentiert, noch nicht greifbar.
Sie entstehen, wenn Expertinnen über lange Zeiträume hinweg Wissen anhäufen – oft in mehreren parallelen Projekten. Dabei nimmt jede Person nur ein Puzzlestück mit. Das führt zu wertvollem, aber verstreutem Wissen. Irgendwann muss jemand das kreative Chaos ordnen – und das ist selten die Lieblingsaufgabe der Fachexpertinnen.
Hier kommen Business Analysten ins Spiel: Sie sammeln, bündeln, strukturieren und übersetzen Wissen in umsetzbare Aufgaben. Dieser Prozess – auch sprachliches Mapping genannt – ist essenziell, um aus Ideen tatsächlich funktionierende Produkte oder Prozesse zu machen.
### Kurz gesagt:
Anforderungen sind oft lose Wissensfragmente – schön gedacht, aber noch nicht nutzbar.
## Die Anforderungsanalyse: Zuhören, fragen, ordnen
Business Analysten arbeiten mit Texten und Zahlen, oft mit beidem gleichzeitig. Sie analysieren Berichte, führen Gespräche, nehmen an Meetings teil und extrahieren systematisch relevante Informationen.
Doch: Niemand legt ihnen freiwillig alle Daten auf den Tisch. Analyst\*innen müssen aktiv auf Stakeholder zugehen, mutig nachfragen und feinfühlig Informationen einholen – oft über Wochen hinweg.
Sobald Informationen vorhanden sind, beginnt die eigentliche Analyse:
1. Inhalte werden bewertet, geordnet, kategorisiert.
2. Sensible Daten werden mit Bedacht behandelt.
3. Ergebnisse werden in der Sprache der jeweiligen Organisation formuliert – ob Bank, Versicherung oder IT-Unternehmen.
### Tipp:
Konzentriere dich auf fachlich relevante Inhalte. Zu viele irrelevante Details können Entscheidungen behindern. Prägnanz spart Zeit.
## Vom Analyse-Chaos zum Anforderungsmanagement
Sind Anforderungen analysiert, gilt es, sie nachhaltig verfügbar zu machen – und zwar für alle Beteiligten.
Das bedeutet: Inhalte müssen strukturiert dokumentiert werden, am besten in den Systemen, die der Kunde nutzt. Dabei gilt es, sich an interne Vorgaben zu halten – jede Organisation hat ihre eigenen Standards.
Business Analysten bauen in dieser Phase ein Wissensportfolio auf, das:
1. fortlaufend wächst,
2. regelmäßig geprüft wird,
3. und langfristig lebendig bleibt.
Das Ziel: Wissen kontrollieren, Entscheidungen ermöglichen, Projekte antreiben.
### Ein Beispiel:
Stell dir einen verspielten Welpen vor, der durch dein Wohnzimmer rennt – wild, chaotisch, aber voller Energie. Damit er nicht die teure Vase umwirft, braucht es Erziehung, klare Strukturen und Geduld. Genauso ist es mit Wissen im Projekt: Ohne Kontrolle ist es schnell verloren. Anforderungsmanagement ist quasi der Hundekurs fürs Projektwissen.
### Notizen und Dokumentationen
Eine Notiz ist keine Dokumentation. Allerdings kann eine Notiz ein Bestandteil einer umfassenden Dokumentation sein. Beim Anforderungsmanagement entstehen viele Ideen. Die meisten Ideen werden nie gebraucht. Business Analysten schreiben aber auch solche Ideen auf. Dadurch entstehen Grafiken, die einem Mini-Prozessmodell ähneln, weil sie für eine ‚richtige Grafik‘ viel zu schematisch erarbeitet sind. Diese Grafiken sind Randnotizen und werden für die Erarbeitung einer Business-Analyse-Dokumentation gebraucht. Diese Notizschnipsel sind also auch nicht als Workshop-Vorbereitung geeignet, weil dafür zu viel Inhalt fehlt. Sie werden aber beispielsweise während eines Workshops erarbeitet und fließen dann in die Anforderungsanalyse mit ein. Das ganze sieht dann so aus.
Mehr zur Methodik findest du übrigens auch im zweiten Teil dieser Serie: [Die unsichtbare Kraft hinter erfolgreichen Projekten.](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
## Wie Wissen nutzbar wird
Gut gemanagte Anforderungen helfen nicht nur Business Analysten – sie bringen das ganze Projektteam voran.
Möglich wird das durch:
1. Dashboards
2. Workshops
3. Schulungen
4. Folgeprojekte
So wird Expertenwissen geteilt, Entscheidungen werden fundierter und Entwickler erhalten konkrete, umsetzbare Aufgaben.
### Merke:
Anforderungsmanagement heißt, analysierte Informationen kontrolliert zugänglich zu machen – dauerhaft, nachvollziehbar, nutzbar.
## Fazit
Business Analysten bewegen sich zwischen Analyse, Kommunikation und Dokumentation. Sie sammeln Wissen, strukturieren es und schaffen die Basis für umsetzbare Ergebnisse. In Teil 3 unserer Serie ging es um Anforderungen – vom ersten Gespräch bis zur langfristigen Dokumentation.
Bleib dran! Im nächsten Teil geht’s darum, wie **Dashboards zum Fliegen gebracht werden.**
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Business Intelligence, Data Warehouse, Moderation
---
### [Was machen Business Analysten? – Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
**Published:** April 4, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten – sie sind überall! In Banken, Versicherungen, Start-ups und der Industrie. Aber was macht sie so unersetzlich? Sie jonglieren mit Zahlen, Technik und Fakten, bleiben selbst in den unruhigsten Projekten gelassen und wissen: Die richtigen Fragen bringen die besten Antworten.
Ein Tag im Leben von Business Analysten beginnt selten ruhig. Ein Beispiel: Du startest deinen Laptop im Homeoffice oder kommst ins Büro, und schon prasseln die ersten Anfragen auf dich ein. Der Product Owner braucht Klarheit zu einer Anforderung, das Entwicklungsteam hat technische Rückfragen, und eine Stakeholder-Person möchte wissen, warum ein bestimmter Prozess so lange dauert.
Na, neugierig geworden? In diesem Blogpost erfährst du, welche methodischen Werkzeuge Business Analysten nutzen, um Projekte voranzubringen.
---
Für alle, die neu dabei sind: Hier geht es zu Teil 1 dieser Serie:
[Was machen Business Analysten? – Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
---
## Methodik: Struktur statt Chaos
Business Analyse ist ein Zusammenspiel aus Kommunikation und Dokumentation. Ohne klare Strukturen verliert sich ein Projekt schnell im Nebel der Anforderungen.
Business Analysten setzen dabei auf verschiedene Tools und Techniken:
1. **Excel-Tabellen** zur schnellen Analyse von Daten
2. **Hands-on Notizen** für spontane Ideen
3. **Listen und Organizing-Tools**, um den Überblick zu behalten
4. **Textdokumente** zur detaillierten Anforderungsbeschreibung
Doch Tools allein reichen nicht. Die wahre Herausforderung liegt in der schnellen Anpassung an kundenspezifische Systeme. Nicht alle Unternehmen arbeiten mit Jira oder Confluence, manche setzen auf Tableau, andere auf MS Power BI. Wer das nicht versteht, verbringt viel Zeit mit doppelter Dokumentation.
Hier gilt: Keine Angst vor Aufgaben:
1. Aufgaben sollten in agilen Kontexten am Sprintplan ausgerichtet sein.
2. Tages- und Stundenplanung hilft, Zeit für Meetings und kreative Ideen zu schaffen.
3. In Meetings: aufmerksam zuhören, mitschreiben, nachbereiten. So bleibt man auf dem neuesten Stand.
### Umsetzung der Methodik: Flexibilität ist der Schlüssel
Vielleicht denkst du jetzt: Das ist leichter gesagt als getan. Wie lassen sich all diese Aufgaben mit Leichtigkeit bearbeiten? So, dass am Ende alle Beteiligten mit dem Ergebnis zufrieden sein können?
Die Lösung heißt **Dynamisches Aufgabenmanagement:**
1. Offene Tasks nach Priorität neu ordnen.
2. Flexible Zeiträume einplanen.
3. Wichtige Aufgaben nicht zu lange mitziehen.
Zusätzlich helfen regelmäßige Schulungen, um flexibel auf Kundenwünsche eingehen zu können. Die Themen reichen von Requirements Engineering über Prozessmanagement bis zu Soft Skills und technologische Vertiefungen.
Gerade in unvorhersehbaren Situationen müssen Business Analysten bereit sein, spontane Workshops oder Schulungen vor großen Gruppen zu halten – auch zu Themen, die sie selbst erst vor Kurzem kennengelernt haben.
#### **Business Analyse in Action:** Ein Praxisbeispiel
Ein Unternehmen aus der Versicherungsbranche hat ein klares Ziel: eine neue Software soll Schadensfälle schneller bearbeiten. Doch das Projekt steckt fest.
Die Fachabteilung wünscht sich eine intuitive Oberfläche, die IT hat eine hochkomplexe technische Lösung entwickelt. Keiner versteht die andere Seite.
Hier kommt die Business Analyse ins Spiel. Innerhalb weniger Stunden:
1. Werden bestehende Dokumente analysiert,
2. Gespräche mit Stakeholder-Personen geführt,
3. Der Knackpunkt identifiziert: fehlende Kommunikation zwischen IT und Fachabteilung.
Der Vorschlag? Ein gemeinsamer Workshop, in dem beide Seiten ihre Anforderungen und Möglichkeiten offenlegen. Das Ergebnis: Eine klare, umsetzbare Lösung – und ein Projekt, das endlich vorankommt.
### **Warum jedes Team einen Business Analysten braucht**
Die Zusammenarbeit mit Business Analysten zahlt sich aus. Sie bringen Struktur ins Chaos, entdecken Optimierungspotenziale und sorgen dafür, dass alle Beteiligten an einem Strang ziehen.
Ob in der Versicherung, Industrie, einem Start-up oder der öffentlichen Verwaltung – eine gute Business Analyse ist immer eine Bereicherung.
## **Fazit**
Ohne Business Analysten bleiben viele Projekte bloße Ideen. Sie sind die Übersetzer zwischen Fachbereich und IT, die Architekten der Anforderungen und die Strippenzieher für den Projekterfolg. Bald folgt Teil 3 dieser Blogreihe über Business Analysten. In [Teil 3](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/) teile ich als Business Analyst meine Erfahrungen zu Anforderungsanalysen und dem Anforderungsmanagement.
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Agil, BI, Data Visualization, Workshop
---
### [Was machen Business Analysten? – Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
**Published:** März 27, 2025
**Author:** Charlotte Grade
**Content:**
Sie sind up to date und kennen den Markt: Business Analysten unterstützen Product Owner, Developer, Projektmanager, Führungspersonen, Stakeholder und natürlich ihre Vorgesetzten. Mit Business Analysten zusammenzuarbeiten – so höre ich es oft – bringt nicht immer Freude, erleichtert aber das Projektcontrolling! Denn sie können besondere Dinge: Zum Beispiel finden sie die Lösungen, die ein Kunde erwartet. Außerdem ist ihr Namensgedächtnis phänomenal, denn ihr soziales Umfeld skaliert immer wieder während eines Projekts.
Aber was machen Business Analysten eigentlich den lieben langen Tag? Als Analystin sollte ich es wissen und die Antwort ist alles andere als langweilig!
In diesem Blogpost erfährst du, welche **vier Aufgaben** für Business Analysten entscheidend sind, um die Lage zu überblicken.
## 1. Informationen sammeln
Zu Beginn kommt es für die Business-Analyse darauf an, einen Überblick zu bekommen. Danach ist es wichtig, während der gesamten Projektlaufzeit den Überblick zu behalten. Und das ist gar nicht so einfach, wie es klingt. Denn zu Beginn eines Projekts ist oft Chaos angesagt: Das Projektteam des Kunden stellt sich vor. Organisatorische Aufgaben werden abgearbeitet. Es gibt viel fachlichen Input.
Dieses Wissen muss aufgeschrieben werden, erste „Kennenlernpräsentationen“ werden erarbeitet und dann geht es auch schon ans Eingemachte:
1. Präsentationen
2. Moderationen
3. und das Daily Business.
Stell dir vor, du kommst in ein völlig fremdes Haus und sollst herausfinden, wo die Tür, die Fenster und das Badezimmer sind – und zwar möglichst schnell. Genau dafür ist eine Business Analyse da: Die Business-Analyse-Fachleute sammeln Informationen, sortieren sie und erstellen daraus eine Karte, die für alle verständlich ist.
## 2. Zeit managen
Nachdem alles abgestimmt wurde, müssen die Aufgaben des Kunden abgearbeitet werden. Um diese Arbeit zu bewältigen, braucht es ein gutes Aufgabenmanagement. Denn jeden Tag verlängert sich die Aufgabenliste.
**Dann heißt es:** Aufgaben thematisch strukturieren, Aufgabenpakete mit wenigen oder vielen Aufgaben bestücken und sofort einplanen. Parallel können die ersten einfachen Aufgaben bereits abgearbeitet werden.
**Wichtig:** Bereits zu Beginn eines Projekts heißt es, Termine mit den Beteiligten vereinbaren! Also mit denjenigen, die das Projektziel im Auge behalten müssen:
1. Stakeholder
2. Kunden
3. Dienstleister
4. weitere Ansprechpersonen
## 3. Kommunizieren & dokumentieren
Kommunikation mit Ansprechpartnern, und die Dokumentation der Fachinhalte in den Systemlandschaften des Kunden sind wichtige Aufgaben für die Analyseverantwortlichen. Allerdings kann es auch vorkommen, dass Business Analysten und Analystinnen nicht direkt zu Projektbeginn eingesetzt werden, sondern erst im Projektverlauf dazukommen. Dann heißt es für sie, sich schnell zurechtfinden und wie immer: Erst mal einen Überblick bekommen!
## 4. Wissen weitergeben
Erst wenn Business Analysten die Lage überschauen, können sie Wissen stückchenweise aufbauen. Wissen, das im späteren Projektverlauf gebraucht wird.
### Analysten als gefragte Wissensträger
Die Personen, die Business-Analysen anfertigen, entwickeln sich zu Wissensträgern. Oft sind sie die einzigen mit einem detaillierten Blick auf alle Projektinhalte. Und das hat Folgen: Irgendwann sind nicht mehr sie es, die Termine einstellen und Ansprechpersonen und Stakeholder einladen, sondern sie selbst werden zu Terminen und regelmäßigen Meetings eingeladen.
Anders als in den selbstorganisierten Terminen haben Business Analysten in Terminen, zu denen sie eingeladen wurden, die Aufgabe, über Fachinhalte aus dem Projekt zu sprechen. Meist werden gezielte Fragen gestellt und präzise Antworten erwartet; Antworten die nachweislich korrekt ausfallen. Da kann es schnell passieren, dass eine Antwort, die gegeben wurde, nicht direkt das Thema trifft, das gerade besprochen wird. Dann hakt ein Kunde gerne zwei oder drei Mal nach und wartet auch nach Terminende geduldig auf die korrekte Antwort.
Denn das Wissen aus der Analyse wird gebraucht: Mit diesem Projektwissen werden Entscheidungen getroffen, das Projektbudget „controllt“ und Projektpläne erarbeitet.
## Ausblick
Im zweiten Teil dieser Serie geht es um die Frage [Was machen Business Analysten? – Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/). Es lohnt sich dran zu bleiben!
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Data Warehouse, Datenstrategie
---
### [Was machen Business Analysten? – Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
**Published:** Mai 28, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten arbeiten zwischen IT und Fachbereichen. Sie suchen in Daten und Datenbanken spezifische Zahlen, an denen es sich lohnt, dranzubleiben – oder anders ausgedrückt: Sie suchen Potenziale für Report-Statistiken in Organisationen. Deshalb erstellen sie für Fachbereiche diverse **Auswertungen, Analysen, Reportings- und Report-Landschaften**. Das passiert aktuell nicht mehr nur mit Microsoft Excel und MS Access sondern auch mit Dashboard-Tools, wie **Tableau, Power BI oder SAP BO/BI Business Objects**.
Dashboard-Tools sind Teil von Business-Intelligence-Lösungen (**BI-Tools**) oder Analytics-Software und kommen in allen Branchen zum Einsatz: von Automobilbranche, Logistik- oder Finanzsektor, bis hin zur öffentlichen Verwaltung; sogar im Startup-Umfeld sind sie anzutreffen. Inhaltlich sind diese Tools allerdings – auch kostentechnisch – eher für große und langfristige Vorhaben geeignet. Daher werden sie am häufigsten im Finance-Umfeld oder im Strategie- und Marketing-Bereich verwendet.
Was ein Dashboard in der Business Analyse leistet – Funktionen, Beispiele und Tipps zur Umsetzung, zeige ich in diesem Teil der Serie **‚Was machen Business Analysten?‘**.
---
Neu hier? Hier kannst du dir die ersten drei Teile der Serie ansehen:
[Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
[Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
[Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
Aber nun zurück zu diesem 4. Teil der Serie – Let’s go!
---
## Was sind Dashboards?
**Dashboards** bieten Übersichten, mit wenigen oder vielen Auswertungen, die interaktiv genutzt werden können. Fachlich ausgedrückt: **Daten werden in Übersichtsblättern visualisiert**, also grafisch dargestellt. So entstehen nicht nur Analyseergebnisse sondern lebendige Auswertungen, die direkt für Entscheidungen herangezogen werden können. Business Analysten lieben es, auf diese Art und Weise, Entscheidungsvorlagen, für Kund:innen zu erstellen.
Dashboards sind also moderne Werkzeuge für **Reporting** und **Business Intelligence**. Sie ermöglichen datenbasierte Entscheidungen auf einen Blick – sie sind also aus dem standardisierten BWL-Berichtswesen. Das klingt ziemlich langweilig, oder? Das Berichtswesen hat einen Bezug zum **Strategischen Management** – egal, ob in Geschäftsleitungsbereichen, auf Vorstandsniveau, oder beispielsweise in IT-Abteilungen. Dashboards sind ein Management-Instrument, die Kennzahlen – sogenannte **KPIs** (Key Perfomance Indicator) abbilden. Darüber können Umsatzentwicklungen, Geschäftsfeldentwicklungen und Trendanalysen mit Prognosetendenz erstellt werden. **Denn: Dashboards leben von Daten.**
## Beispiel: Dashboard in Rohfassung
Diese Skizze zeigt, wie unglaublich kompliziert ein Dashboard im Ergebnis auf den ersten Blick aussehen kann. Dabei wird hier nur genau ein Dashboard beispielhaft gezeigt. Es gibt auch Fachbereiche und Organisationseinheiten, die mit mehreren Dashboards arbeiten.
## 
Wie komplex ist es, ein Dashboard zu erstellen?
Kommt‘ drauf an! Dashboards enthalten strategische Kennzahlen (KPIs: Key Perfomance Indicator). Die Erstellung eines einzelnen Dashboards kann wenige Minuten oder Stunden dauern; manchmal nimmt es auch Wochen oder Monate in Anspruch. Das hängt davon ab, welche Fragestellungen ein Dashboard beantworten soll.
### **Beispiel aus einem Einstellungsgepräch für Business Analysten**
Ein Unternehmen in der Logistikbranche möchte seine Umsatzentwicklung über die letzte fünf Jahre in einem Dashboard abbilden, um Potenzialanalysen auf Quartalsebene vorzunehmen. Das Ziel ist klar definiert und heißt: Wachstum.
Es haben sich bereits erste Tendenzen gezeigt, dass es in den Wintermonaten zu Auslastungsdefizieten kommt, die durch den Zukauf von Geschäftsfeldern kompensiert werden könnten. Die Daten der Umsätze liegen allen vor. Die Erstellung – inklusive der Visualisierung der Dashboards – dauert daher in diesem Fall nur wenige Tage.
Die Komplexität eines Dashboards hängt davon ab, welche Fragen es beantworten soll – und ob die nötigen Daten bereits vorliegen. Einfache KPIs wie Umsatzzahlen liegen einer Organisation zum Beispiel direkt vor.
Aufwändiger wird es bei:
1. Spezifischeren Informationen
2. Daten, die länger in die Vergangenheit hinein reichen.
Hier kann es also dauern und Business Analysten müssen dann besonders geduldig sein.
### Datenbeschaffung
In der Praxis müssen Business Analysten diese Informationen zunächst in Form von Rohdaten über einzelne Fachbereiche anfragen und sich mit Expert:innen über den Detailgrad der relevanten Daten austauschen. Dafür sind manchmal wenige, manchmal auch viele Meetings nötig.
Meist entwickeln sich Dashboards im Laufe der Zeit jedoch von alleine. Es fängt an mit einer ersten Variante, die im Zeitverlauf mit weiteren Inhalten, also Zahlen und Daten, angereichert und grafisch visualsiert werden. Erfahrene Analysten beginnen mit wenigen Inhalten, d. h. sie verzichten zugunsten der Richtigkeit der Auswertung zunächst auf Details. Denn: Gerade bei Auswertungen mit Zeitverlaufsbezug, wo eine Vergleichsgrafik von **Neudaten** zu **Altdaten** erstellen werden sollen, muss die **Vergleichsbasis** immer stimmen.
## Wann ist ein Dashboard fertig? (Spoiler: nie ganz)
**Zunächst einmal:** Jedes Dashboard ist ein individueller, visuell-aufbereiteter Report. Er ist also ein Blitzlicht und damit nie „fertig“.
Im Berichtswesen müssen Fragen beantwortet werden. Das braucht Zeit. Diese Fragen werden Business Anlaysten vorgegeben. Manchmal erarbeiten Business Analysten diese Fragestellungen auch zusammen mit Fachabteilungen aus dem Kundenkreis – zum Beispiel mit Projektleitung, Abteilungsleitung oder Geschäftsführung. (Wie so eine Anforderungsanalyse abläuft, erfährst du hier: ‚[Was machen Business Analysten? – Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)‚)
Dashboards werden häufig in Echtzeit aktualisiert. So sind die Daten immer präsent. Also wie gesagt: Mit einem Dashboard wird aktiv gearbeitet. Fertig ist es daher nie, sondern es wird stetig um weitere Inhalte ergänzt, mit neuen Daten und Altdaten für Vergleichsansichten angereichert, und in Nutzerkreisen zugunsten von Entscheidungen diskutiert.
### Ein Gerüst steht bereit
Die Grundstruktur eines Dashboards kann jedoch einmal initial aufgebaut werden. Sind alle relevanten Daten im Dashboard da, ist der visualisierte Bericht fertig. Und natürlich kann dieser im Zeitverlauf weiter ‚***verschönert***‚ werden.
## Warum liefert der Bericht nicht das Ergebnis, das ich jetzt brauche?
Dashboards bilden die Zahlen ab, die ausgewertet wurden. Liefert eine Auswertung also ein Ergebnis, ist das für uns gut und wir haben unser Ziel erreicht. Stellt darüber hinaus jemand aus dem **Dashboard-Team** fest, dass das Ergebnis im Dashboard nicht korekt ist, ist das noch besser. Dann kann das Dashboard optimimiert werden!
### Fehler finden und Reports verbessern
Hier ein paar Beispielfragen, die im Falle eines falschen Wertes im Bericht an das Dashboard gestellt werden sollten:
- Hat sich das Ziel hinter dem Dashboard verändert?
- Stimmt die Datengrundlage eigentlich noch?
- Wurde der Report in der Zwischenzeit um weitere Werte angereicht? Wurde die Anreicherung dokumentiert? Ist diese Datenanreicherung für jeden, der am Bericht arbeitet, nachvollziehbar?
- Kann eine Ist-Soll-Analyse helfen, die aktuelle Abweichung zum erwarteten Ergebnis zu veranschaulichen?
## Welche Rolle spielen Business Analysten im Dashboard-Prozess?
Business Analysten bewegen sich zwischen Development-Teams und dem Fachbereich. Sie verstehen also nicht nur die technische Seite, sondern begreifen vor allem, was das Fachpersonal inhaltlich braucht. Diese Anforderungen übersetzen sie so gut, dass exakt die Daten von der IT-Abteilung bereitgestellt werden, die erforderlich sind, um ein **qualitativ-hochwertiges Dashboard** zu erstellen.
### Schlüsselqualifikation: Fokus und Kommunikation
Business Analysten handeln getreu nach dem Motto: ‚Wozu Daten auswerten, die gar nicht wichtig sind?!‘. Sie schaffen einen Fokus, haben immer das **Projektziel** im Blick und helfen konkrete Lösungen zu finden. Dabei stellen sie viele, viele Fragen und führen Gespräche mit allen Beteiligten, die für die Erstellung des Dashboards gebraucht werden. Alle Projektinvolvierte einzubinden und mitzunehmen gehört zu ihrem täglichen Geschäft.
---
## Fazit: Dashboards leben – dank Business Analyse
Business Analysten lieben das Hinterfragen von Zusammenhängen. Daher fällt es ihnen auch so leicht, Dashboards zu bearbeiten. Du möchtest wissen, wie Business Analysten im Projektalltag ihre Aufgaben detailgetreu umsetzen können? Du bist vielleicht selbst Business Analyst und suchst nach einer gelungenen Organisationsstruktur für deinen Kalender? Dann bleib unbedingt dabei – wenn es in Teil 5 dieser Serie heißt: [Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/).
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Business Intelligence, Data Visualization, Data Warehouse, Datenmodellierung, Reports
---
### [Was machen Business Analysten? – Teil 9: Arbeiten in Gruppen und Projektteams](https://thecattlecrew.net/2025/11/19/was-machen-business-analysten-teil-9-arbeiten-in-gruppen-und-projektteams/)
**Published:** November 19, 2025
**Author:** Charlotte Grade
**Content:**
Für Business Analysten ist die Arbeit in Gruppen und Teams alltägliche Normalität. In Fachbereichen gibt es immer mehrere Ansprechpersonen, oft eingebettet in Gruppen, Teams, Abteilungen oder Referaten – und natürlich in die übergeordneten Organisationseinheiten. Business Analysten laufen inhaltlich zwischen Fachbereichen und Entwicklern permanent hin und her, sammeln Informationen zu Projektinhalten und bereiten diese wiederum sowohl für Fachansprechpersonen als auch für Developer passgenau auf.
Dafür müssen Personen und Rollen in Organisationen möglichst ‚*sauber*‚ auseinandergehalten werden. Oft werden Fachinhalte in großen Unternehmen sogar von genau einer Person pro Abteilung bearbeitet – bei einer Unternehmensgröße von mehreren hunderttausend Mitarbeitenden. Genauso wie einige Entwickler sich lieber in Python- und andere sich eher in Java-Umgebungen wohlfühlen, müssen Business Analysten mitdenken.
---
Wie es Business Analysten trotz dieser Herausforderung schaffen regelmäßig zu überzeugen darum geht es in diesem Blogpost aus der Kategorie „Was machen Business Analysten?“.
Du willst diese Serie besser von Anfang an beginnen? Das kann ich verstehen: [Hier geht’s zum Serienstart](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/).
---
## Was ist eine Gruppe?
Ich habe einmal gehört, dass es einen Unterschied macht, ob man über Teams oder Gruppen redet. Während ein Team bereits bei einer Größe von zwei Personen starten kann und dann natürlich auch auf eine Teamgröße von acht oder zehn Personen anwachsen kann, definiert sich eine Gruppe erst ab einer Größe von mindestens drei Personen. Ich fand diese Unterscheidung interessant – vor allem, weil ich ursprünglich dachte, dass Teams so ungefähr das gleiche wie Gruppen sind. Wahrscheinlich hatte ich „Team“ immer als englischen Begriff verstanden und als Synonym für „Gruppe“ genutzt; ähnlich wie das Wort „Mannschaft“, das ja unter Umständen sprachlich auch eine Gruppe sein könnte. Das ist aber offensichtlich nicht so. Ich habe mir diese Unterscheidung zu Teams und Gruppen seitdem gemerkt.
Eine Gruppe beschreibt sich also über die Größe von mindestens drei Personen, ein Team kann bereits aus zwei Personen bestehen. Projektmitglieder können in Gruppen arbeiten – und Business Analysten auch. Die folgende Skizze macht die Arbeit von Business Analysten in Gruppen ein wenig verständlicher:
Im Kern sind Business Analysten Kommunikationsassistent:innen. Sie sind Unterstützer:innen.
### Business Analysten in Gruppen
Business Analysten gehen in Gruppenkontexten in Projekten zumeist:
- aktiv,
- offensiv und
- ruhig vor.
#### 1 Das Reh nicht aufscheuchen
Ein guter Vergleich ist ein 15-Kilometer-Lauf in der Natur. Wenn man unterwegs auf zwei Rehe trifft, ist man grundsätzlich geneigt, einen Bogen um sie zu machen – doch meistens laufen sie bereits weg, bevor man überhaupt reagieren kann. Rehe sind extrem scheue Tiere. Ähnlich ist es manchmal in Organisationen: Wenn Business Analysten in neuen Projektumfeldern auftreten, reagieren Projektmitglieder zunächst zurückhaltend. Wenn Analysten dann zusätzlich hektisch, gestresst oder mit unangebrachtem Verhalten auftreten, kann es passieren, dass man einige Personen nie wieder zu Gesicht bekommt – und dann werden auch keine Auswertungen oder Analysen entstehen. Business Analysten agieren daher, bewusst und bedacht.
#### 2 Gelassen bleiben
Business Analysten brauchen außerdem, wie ihr euch vorstellen könnt, viel Geduld. Es kann vorkommen, dass Analysten mehrfach im Quartal auf dieselben Projektbeteiligten zugehen und Fragen zum grundsätzlich gleichen Inhalt haben. So ist das. Und natürlich kann es auch nerven, wenn immer wieder dieselbe Frage gestellt wird – obwohl sie bereits mehrfach beantwortet wurde.
#### 3 Details haben Vorrang
Wie so oft gilt auch hier: **Auf den Detailgrad kommt es an!** Manche Inhalte müssen halt diskutiert werden – egal, ob zwei, zwölf oder dreißig Mal. So ist Business Analyse. Denn, genau diese detaillierten Informationen sind entscheidend, weil Developer darauf angewiesen sind. Nur so können Softwareprodukte korrekt ausgesteuert werden.
Bleib gerne dran! Im nächsten und damit auch letzten Teil von „Was machen Business Analysten?“ werden endlich [**Workshops** ](https://thecattlecrew.net/2025/12/02/was-machen-business-analysten-teil-10-spontane-workshops-meistern/)vorgestellt. Das wird auch wieder spannend.
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
- [Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
- [Teil 5: Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/)
- [Teil 6: Tools gezielt nutzen](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)
- [Teil 7: Fachlich klar bleiben](https://thecattlecrew.net/2025/08/28/was-machen-business-analysten-teil-7-fachlich-klar-bleiben/)
- [Teil 8: Modernes Projektmanagement](https://thecattlecrew.net/2025/09/23/was-machen-business-analysten-teil-8-modernes-projektmanagement/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Management, Market Research, Marketing
---
### [Was machen Business Analysten? – Teil 5: Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/)
**Published:** Juli 4, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten leben vom Austausch. Ob persönlich, per E-Mail, im Video-Call oder im Workshop – sie sind präsent, motiviert und mittendrin. Im Gespräch mit Kolleginnen und Kollegen, bei Schulungen oder Meetings erleben wir sie als lösungsorientiert, neugierig und engagiert.
Man könnte fast sagen: Je komplexer das Problem, desto größer die Motivation. Vorbehalte? Rückschritte? Für Business Analysten kein Grund zum Aufgeben – sondern ein Impuls zum Dranbleiben.
Der Grund für diese Beharrlichkeit? Ganz klar: **das Ziel**.
## Warum Ziele wichtig sind
Ziele sind mehr als Wunschdenken. Sie geben Orientierung und machen aus Ideen konkrete Vorhaben. Denn ohne Ziel gibt es keinen Weg – und ohne Weg kein Ergebnis. Ein Ziel motiviert, gibt Struktur und ermöglicht Fortschritt. Deshalb ist das Zielbewusstsein für Business Analysten ein entscheidender Erfolgsfaktor.
---
Neugierig auf den Kontext? Lies gerne auch Teil 3 der Serie:
**[Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)**
---
Du interessierst dich für die **Business Analyse**? Dann empfehle ich dir die Serie vorne zu starten:
[Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
[Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
[Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
[Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
Aber nun zurück zu diesem 5. Teil der Serie – los geht es.
---
## Ziele setzen: Vom Großen ins Kleine
Business Analysten entwickeln Ziele meist nicht selbst – sie bekommen sie vorgegeben. Doch sie spielen eine zentrale Rolle dabei, Ziele zu verstehen, zu übersetzen und in machbare Aufgaben zu überführen.
Sie helfen dabei, Ziele zu strukturieren – zum Beispiel in:
1. große Aufgabenpakete
2. kleine Teilaufgaben
3. konkrete Einzelschritte.
So wird ein großes Ziel greifbar und das Projektteam kann gemeinsam daran arbeiten.
### Ziele geben die Richtung vor – Ergebnisse machen sie sichtbar
Ziele sind nicht bloß Wünsche, sondern klare Vorgaben, die ein gewünschtes Ergebnis vorwegnehmen. Damit aus Theorie auch Praxis wird, müssen diese Ziele im Projektverlauf konsequent verfolgt werden. Daran arbeitet das gesamte Team – und Business Analysten spielen dabei eine zentrale Rolle.
Ihre Aufgabe: Das Ziel verstehen, es inhaltlich durchdringen und so aufbereiten, dass es für jedes Teammitglied nachvollziehbar und greifbar bleibt. Dafür übersetzen sie die Zielvorgabe in strukturierte Aufgaben – von großen Arbeitspaketen bis hin zu konkreten Einzelschritten.
Währenddessen sorgt die Projektleitung für den organisatorischen Rahmen; damit Zeit, Ressourcen und Zielerreichung in Einklang bleiben. In gut aufgestellten Teams funktioniert das meist reibungslos – vor allem dann, wenn alle Beteiligten das gemeinsame Ziel wirklich verstanden haben.
#### Beispiel: Der Marathon
Stell dir vor, du nimmst am Marathon-Event deiner Stadt teil, weil es schon immer dein größter Traum war, einen Marathon zu laufen. Das Ziel ist klar: Die 42 km vom Start bis zum Ziellinie laufend zu meistern.
Dafür bereitest du dich natürlich gut vor:
- Du kaufst ein neues, ziemlich teures Paar Laufschuhe deiner Lieblingsmarke,
- du trainierst viele Monate auf das Event hin,
- du schaust etliche Video-Clips über Marathon-Events,
- du informierst dich über die Geschichte des Marathons und
- du achtest über einige Wochen diszipliniert auf deine Ernährung.
Am Tag des Events bist du aufgeregt, freust dich aber auf deinen Lauf. Die Sonne scheint sogar ein wenig. Und zack, ist das Lauf-Event vorbei und du hast den Marathon sogar unter fünf Stunden geschafft. Und wenn du ins Ziel kommst, stellt sich Zufriedenheit ein. Und danach? Du setzt ein neues Ziel.
Genau so funktioniert Zielarbeit auch in der Business Analyse.
## Ziele erreichen – mit Motivation statt Druck
Auch ein Ziel hat ein Ziel. Oder besser gesagt, einen Zweck. Der Zweck ist es, dabei zu helfen, Ergebnisse zu schaffen. Auf dem Weg dorthin müssen Aufgaben abgearbeitet werden.
### Ohne Fleiß kein Preis?
Aufgaben abarbeiten … – Das klingt nicht nur nach viel Anstrengung, das ist auch viel Anstrengung – vor allem, wenn man dem Glauben verfällt, dass nur Anstrengung zum Ziel führen kann. Wie wäre es hingegen, wenn wir leicht und fröhlich unsere Ziele erreichen könnten? Gelassen, entspannt, voller Erwartung, mit Energie und Geduld.
Das Konzept dahinter nennt man **Motivation**.
### Motivation ist der Schlüssel
Es ist erwiesen: Motiviert an Zielen zu arbeiten, führt häufiger dazu, dass Ziele erreicht werden als ein eher unmotiviertes Vorgehen. Und: Ziele zu verfolgen muss nicht kräftezehrend sein. Wer motiviert ist, erlebt Aufgaben nicht als Last, sondern als sinnvolle Etappen auf dem Weg zum Ergebnis.
Man könnte sagen: Motivation …
1. … macht aus „Müssen“ ein „Wollen“.
2. … erzeugt Energie statt Widerstand.
3. … stärkt die Verbindung zwischen Ziel und Sinn.
Unsere Ziele motivieren uns, in dem sie unserem Tun einen Sinn geben. Eine Sinn, für den es sich lohnt, zu *ackern*. Wer weiß, warum er oder sie etwas tut, arbeitet mit innerem Antrieb – nicht gegen die Uhr.
### Ein Hoch auf die Ziele!
Es lohnt sich also an Zielen zu arbeiten – egal, ob alleine, zu zweit oder mit mehreren. Ergebnisse, die nach und nach sichtbar werden, sind etwas Wunderbares. Sie helfen uns, den Griffel wie von selbst zu schwingen und unsere Aufgaben abzuarbeiten. Ohne übermäßige Anspannung und Widerstand. Gedanken wie: „Wann kann ich endlich Pause machen?“, „Noch eine Stunde dann ist endlich Feierabend.“ oder „Mir tut jetzt schon der Nacken weh.“, gehören der Vergangenheit an. Stattdessen fühlen wir in unserem Element.
## Sinn stiften mit Ergebnissen
Business Analysten arbeiten ergebnisorientiert. Das bedeutet: Ihre Arbeit soll einen Beitrag leisten – für mehr Sicherheit, mehr Transparenz, bessere Entscheidungen. Ihre Ziele sind messbar, nachvollziehbar und langfristig wirksam.
### **Typische Zielwirkungen in der Business Analyse:**
1. Struktur statt Chaos
2. Mehrwert durch faktenbasierte Entscheidungen
3. Fundiertes Wissen, das für Folgeprojekte nutzbar ist
Auf Ergebnissen kann aufgebaut werden; neue, zusätzliche Ergebnisse können entstehen und es entsteht natürlich **Wissen**. Und Business Analysten brauchen Wissen, um am Projekterfolg mitwirken zu können.
Das Ziel schafft also nicht nur Ergebnisse – es stiftet Sinn. Und dieser Sinn ist es, der Business Analysten täglich antreibt.
---
## Ausblick: Tools für den Alltag
Im nächsten Teil der Serie dreht sich alles um Tools, Methoden und Techniken, die Business Analysten in ihrem Arbeitsalltag nutzen. Bleib also dran, wenn es bald weitergeht mit: [**Was machen Business Analysten? – Teil 6: Tools gezielt nutzen**](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
- [Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Agile Methode
---
### [Was machen Business Analysten? – Teil 10: Spontane Workshops meistern](https://thecattlecrew.net/2025/12/02/was-machen-business-analysten-teil-10-spontane-workshops-meistern/)
**Published:** Dezember 2, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten reden gerne, sie hören aber auch gerne zu und dokumentieren fachlichen Kontext. Vor allem aber blühen Business Analysten bei Moderationen und Workshops auf. Meistens sind Workshops so organisiert, dass es genug Zeit gibt, sich gezielt darauf vorzubereiten. Eine strukturierte Arbeitsweise ist Business Analyst:innen schließlich sehr wichtig – vor allem, weil Begriffe wie Chaos, Durcheinander, Stress, Hektik und Unordnung im Alltag von Business Analysten permanent präsent sind.
---
Falls du neu hier bist, kannst du direkt weiterlesen – oder du startest die gesamte Serie über den Alltag von Business Analysten ganz von vorne. Hier geht’s los: [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
---
## Bühne frei für Business Analysten
Das Ziel von Rollen aus der Kategorie „Business Analyse“ ist eindeutig definiert: Business Analysten bauen Wissen auf – Schritt für Schritt. Ein systematischer Umgang mit Tools und Software (siehe [Teil 6: Tools gezielt nutzen](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)) gibt ihnen dabei das Vertrauen und die Sicherheit, die sie im Arbeitsalltag brauchen. Und dann kommt die große Kunst, die Business Analysten besonders anzieht: **WORKSHOPS**.
Bei Workshops geht es um:
1. Sprache, Ausdruck und Wort
2. Fachkontexte
3. Interaktion in und mit Teams und Menschen
4. Routinen und Regelmäßigkeiten
### Die Workshop-Realität
Ein guter Moderator kennt sich aus. Der Speaker weiß, worüber er oder sie spricht. Business Analysten müssen Workshop-Teilnehmende überzeugen – rednerisch und inhaltlich. Ansonsten steigen 30 – 70 % der Teilnehmenden erfahrungsgemäß aus, verabschieden sich remote als Kurznachricht oder verschwinden leise aus dem Raum. Das ist eine richtige ‚Klatsche‘ für die präsentierende Person.
Für Business Analysten ist das oft kein Problem. Analysten können sich auf ihre Umgebung verlassen – zumindest theoretisch. Auch Analysten müssen erst lernen, ihrem Umfeld Vertrauen zu schenken: Kolleginnen und Kollegen, Stakeholdern und ihrer Arbeitsumgebung. Meist bleibt es ohnehin nie bei einem Workshop.
Mein Alltag zeigt: Menschen lieben Workshops. Workshops sind nicht nur „Memory spielen“ (siehe [Teil 7: Fachlich klar bleiben](https://thecattlecrew.net/2025/08/28/was-machen-business-analysten-teil-7-fachlich-klar-bleiben/)) – Workshops sind wesentlich mehr. Menschen haben gleichzeitig Freude und Spaß. Haben Business Analysten ihre Teilnehmenden erst einmal überzeugt, folgt fast immer ein Folge-Workshop. Workshops sind lebendig. Einer folgt auf den nächsten, und so weiter …
### Die Geschichte von der Torte
Workshops täglich vorzubereiten ist nicht möglich. Workshops sind das sogenannte i-Tüpfelchen – etwas Besonderes, bildlich gesprochen: die Kirsche auf der Sahnehaube. Wer liebt sie nicht, die Schwarzwälder Kirschtorte. Auf ihr glänzt die Kirsche wunderschön, aber seien wir ehrlich: Zumeist schmeckt die Torte besser als die Kirsche selbst.
Workshops sind wie Torten: aufwendig, teuer, besonders. Ein Stück Kuchen kaufen ist einfach – aber eine ganze Torte transportieren? Vielleicht sogar mit dem Fahrrad? Nicht so leicht, oder?
## Mindmaps, Menschen und viel Gestaltungsraum
Workshops sind chaotisch. Mindmaps helfen. Nicht zuletzt müssen Gedanken sofort aufgeschrieben werden, sonst verfliegen sie. Aus Analyse-Sicht ist es wichtig, sich auf wesentliche Fakten zu konzentrieren – zu viele Details nerven Teilnehmende in der Regel.
Der Aufbau eines Workshops ist kleinteilig definiert und durchstrukturiert. Das sehen die Teilnehmenden jedoch nicht, weil es vor dem Workshop passiert. Dass es nach Workshops oft hitzige Debatten über die Vortragenden gibt, wissen alle Workshop-Durchführenden – Business Analysten eingeschlossen. Oft melden sich einige Teilnehmende nach einem Workshop direkt bei den Business Analysten, um etwas Persönliches mitzuteilen.
### Test: Mindmap-Idee oder Architektur?
Während des Workshops entsteht häufig Kreativität: Mindmaps, Ideen, kleine Architektur-Skizzen. Für mich als Business Analyst sind das „Mindmap-Ideen“, fachlich aber eigentlich Architektur-Ansätze für technische Systemumgebungen.
Pass auf, ich zeige dir, was ich meine. Guck dir diese Abbildung aus einem Beispielprojekt an. Ist das eine Mindmap oder eine Architektur?
Bis Business Analysten sich an Workshops wirklich einmal heranwagen, vergehen manchmal mehrere Jahre bis Jahrzehnte. Zunächst lernen Business Analysten kleine bis mittlere Meetings zu moderieren.
---
## Serienende
Abschließend zu der Blogserie ‚**Was machen Business Analysten?**‚ stelle ich hier aktuelle Empfehlungen und Trends im Buchmarkt bereit. Beim Schreiben dieser Serie habe ich manchmal versucht den Schreibstil von äußerst erfolgreichen Büchern einzubeziehen, wie z. B. von:
- **„Komm, ich erzähl dir eine Geschichte“** von **Jorge Bucay**
- „**Elefant**“ von **Martin Suter**, oder
- „**Rich Dad Poor Dad**“ von Robert Kiyosaki und Sharin L. Lechter.
Und hier ist meine Top 14-Bücherliste:
**Nr.** **Titel****Autor****1**Der AlchimistPaulo Coelho**2**Vom Glück des WandernsAlbert Kitzler**3**Wege zum glücklichen HandelnEpiktet**4**Der tägliche StoikerRyan Holiday**5**No Logo!Naomi Klein**6**FleischmarktLaurie Penny**7**Bitch DoktrinLaurie Penny**8**Harry Potter und der Stein der Weisen (Carlsen Verlag als gebundene Ausgabe)J. K. Rowling**9**Axolotl RoadkillHelene Hegemann**10**Das Spiel ist ausJean Paul Sartre**11**The Big Five for Life
John Strelecky
**12**Minimalismus
Joshua Fields Millburn und Ryan Nicodemus
**13**Selbstporträt
Helene Beltracchi und Wolfgang Beltracchi
**14**Haben oder Sein
Erich Fromm
---
## In dieser Blogserie sind erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
- [Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
- [Teil 5: Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/)
- [Teil 6: Tools gezielt nutzen](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)
- [Teil 7: Fachlich klar bleiben](https://thecattlecrew.net/2025/08/28/was-machen-business-analysten-teil-7-fachlich-klar-bleiben/)
- [Teil 8: Modernes Projektmanagement](https://thecattlecrew.net/2025/09/23/was-machen-business-analysten-teil-8-modernes-projektmanagement/)
- [Teil 9: In Gruppen überzeugen](https://thecattlecrew.net/?p=40491&preview=true)
- Teil 10: [Spontane Workshops meistern](https://thecattlecrew.net/2025/12/02/was-machen-business-analysten-teil-10-spontane-workshops-meistern/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Data Warehouse, Datenarchitekturen, Datenbankmigration, Datenmodellierung
---
### [Was machen Business Analysten? – Teil 8: Modernes Projektmanagement](https://thecattlecrew.net/2025/09/23/was-machen-business-analysten-teil-8-modernes-projektmanagement/)
**Published:** September 23, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten arbeiten in Projekten eng mit dem Projektmanagement zusammen. Beide Rollen haben völlig unterschiedliche Aufgaben – und doch werden sie in der Praxis oft verwechselt. Business Analysten sind aber keine Projektmanager. Während Projektmanager Budgets, Zeitpläne und Ressourcen im Blick behalten, kümmern sich Business Analysten darum, Inhalte zu sammeln, zu strukturieren und für die Entwicklung aufzubereiten. Sie unterstützen – flexibel und pragmatisch – immer im Rahmen der Projektvorgaben.
**Kurz gesagt:** Business Analysten ersetzen keine Projektmanager, sondern ergänzen sie. Und oft sind sie auf die Arbeit des Projektmanagements angewiesen, um ihre eigenen Aufgaben effektiv erledigen zu können.
---
In diesem Teil der Serie ‚Was machen Business Analysten?‘ wird es besonders interessant. Denn hier stelle ich ‚Modernes Projektmanagement‘ in der Business Analyse praktisch vor.
---
## Modernes Projektmanagement
Modernes Projektmanagement bedeutet heute vor allem agiles Arbeiten – auch in großen Projekten. Stell dir ein Team vor: unterschiedliche Entwickler:innen, ein Projektmanager und eine oder mehrere Business Analysten. Dazu kommen interne Kolleg:innen des Kunden und externe Dienstleister. Für Business Analysten ist das ein Alltag– endlich gibt es wieder viele Inhalte, die sortiert, gebündelt und dokumentiert werden wollen.
Der Projektmanager bündelt alle relevanten Informationen, Business Analysten nehmen diese auf, diskutieren sie mit Fachbereichen oder Entwickler:innen und bereiten sie so auf, dass sie im Projektteam weiterbearbeitet werden können.
### **Business Analysten im Projektmanagement**
Im modernen Projektumfeld übernehmen Business Analysten zentrale Aufgaben:
1. Inhalte für Projektmanager strukturieren und kategorisieren
2. Ergebnisse in den Zielsystemen dokumentieren
3. Termine und Abstimmungen mit Stakeholdern organisieren
4. Aufgaben für Entwickler in umsetzbare Pakete übersetzen
Parallel arbeiten die Entwickler:innen an der Umsetzung, während der Projektmanager den Überblick behält. Business Analysten sorgen dafür, dass Entwickler möglichst klare, direkte Aufgabenstellungen bekommen – damit Code und Ergebnisse eindeutig und zielführend sind. Bildlich ausgedrückt könnte das zum Beispiel dann so aussehen:
### Warum ist Zeit dabei so wichtig?
Am Anfang eines Projekts sammelt der Projektmanager die wichtigsten Informationen vom Auftraggeber. Daraus ergeben sich für die Business Analysten erste Aufgabenpakete für die Entwickler. Doch diese Aufgaben sind meist noch grob. Rückfragen seitens der Entwickler sind die Regel – und manchmal führt das zu Diskussionen zwischen Analysten, Entwicklern und Projektmanager:innen.
Im Ergebnis gehen Business Analysten dann zurück in die Fachbereiche, um Klarheit zu schaffen. Diese Termine müssen erst organisiert werden – und das kostet Zeit. In der Zwischenzeit analysieren Business Analysten deshalb andere Inhalte und übersetzen sie in Aufgaben.
## Fazit
Business Analysten und Projektmanager haben unterschiedliche Rollen – doch gerade im modernen Projektmanagement greifen sie direkt ineinander. Während die Projektmanager den Rahmen setzen, sorgen Business Analysten dafür, Inhalte zu strukturieren, verständlich aufzubereiten und zu bearbeiten. Gemeinsam halten sie Projekte am Laufen und bringen sie zum Erfolg.
Bleib gerne dabei, wenn es im nächsten Teil wieder heißt: *Was machen Business Analysten?* – mit neuen Einblicken aus dem Tagesgeschäft von Analysten.
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
- [Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
- [Teil 5: Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/)
- [Teil 6: Tools gezielt nutzen](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)
- [Teil 7: Fachlich klar bleiben](https://thecattlecrew.net/2025/08/28/was-machen-business-analysten-teil-7-fachlich-klar-bleiben/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Data Warehouse
---
### [Was machen Business Analysten? – Teil 6: Tools gezielt nutzen](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)
**Published:** Juli 18, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten arbeiten mit vielen Tools – und oft mit vielen verschiedenen auf einmal. Die Tool-Auswahl bestimmen sie jedoch nicht immer selbst: Häufig steigen sie in bereits bestehende Projekt-Umgebungen ein, in denen bestimmte Software-Lösungen vorgegeben sind. Dabei bleiben sie flexibel und offen – denn im Mittelpunkt steht das Projektziel, nicht das Tool. Ob es um Software-Entwicklung, Daten-Analysen oder Dokumentation geht – Business Analysten wollen zuerst den Bedarf verstehen. Welche Tools dabei genutzt werden, ist oft zweitrangig. Und doch: Der richtige Umgang mit Tools ist ein Erfolgsfaktor. In diesem Beitrag zeige ich, wie Business Analysten Tools sinnvoll einsetzen können.
---
Dies ist übrigens eine ganze Serie zur Business Analyse und startet hier: [**Serienstart: Die Lage überblicken**.](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
---
## Tool-Auswahl
In der Praxis begegnen Business Analysten einer Vielzahl von Tools – von geliebten Klassikern bis zu sperrigen Systemen. Was zählt, ist in der Regel nicht, ob ein Tool „cool“ ist, sondern ob es die Projektarbeit effizient unterstützt.
### Gezielter Einsatz von Tools
Fangen wir von vorne an: Wofür werden Tools gebraucht? Dies kann in Form einer Dokumentation, einer Unterlage für eine Workshop-Vorbereitung oder in Gestalt eines Dashboards sein. Business Analysten nutzen Tools, um Fachinhalte greifbar zu machen.
Das geschieht etwa in Form von:
1. Dokumentationen
2. Workshop-Unterlagen
3. Dashboards & Reports
4. Datenbankabfragen
5. Modellen und Diagrammen
Zum Einsatz kommen u. a.:
1. BI-Tools wie Tableau, Power BI, SAP BO, etc.
2. ausgewählter Statistik- und Analyse-Software
3. Kalkulationstools (Excel, Google Sheets)
4. Datenbank-Umgebungen
5. Projekt- & Doku-Tools wie Jira, Confluence, Miro, usw.
Business Analysten unterstützen gerne. Deshalb stellen sie auch viele Fragen. Expert:innen und Spezialist:innen kennen sich schließlich viel besser aus. Hier lohnt sich das Fragenstellen also besonders. Auf diese Weise entsteht eine erste Zusammenarbeit mit Developern, Product-Ownern, Stakeholdern, und vielen, vielen weiteren Ansprechpersonen – egal, ob intern oder extern. Die Anforderungen werden in Aufgaben und Fachinhalten übersetzt; jeweils direkt in der jeweiligen Toolumgebung im Projektkontext.
### Beispiel: Eine Medien-Analyse
Ein Medien-Unternehmen nutzt eine BI-/Analytics-Software um Echtzeit-Analysen über performance-freundliche Werbeeinheiten in Form von Werbe-Issues zu tracken. Das Ziel ist eindeutig: Kund:innen, die Werbe-Minuten buchen, sollen die optimalen Werbe-Zeiten erhalten. Das sichert langfristig die Zusammenarbeit – beidseitig. Business Analysten sind dabei und arbeiten an den Analytics-Tools, um die wichtigen Berichte und Dashboards zu erstellen und entwickeln diese stückchenweise mit den Analysten des Medien-Unternehmens weiter.
## Einsatz neuer Tool-Lösungen
Sich neuen Tools zu öffnen, ist nicht immer leicht – aber oft notwendig. Wer zu sehr an gewohnten Tools festhält, macht sich den Arbeitsalltag schwer. Statt Energie in den Wunsch nach Toolwechseln zu investieren, konzentrieren sich erfahrene Analysten auf Inhalte, Ziele und Zusammenarbeit.
In den meisten Projekten wird ohnehin mit verschiedenen Tools gleichzeitig gearbeitet. Umso wichtiger ist ein strukturierter Umgang und ein gesunder Pragmatismus.
Neue Tools kennenzulernen, kann Spaß und Freude mit sich bringen. Dafür braucht es allerdings wie gesagt ein gewisses Maß an Offenheit. Wer sich auf die gewohnten Tools fixiert, erschwert sich den Arbeitsalltag. Das ist verschwendete Energie. Besser ist es, man wartet erst einmal ab, und lässt sich situativ auf Tools ein.
Schließlich arbeiten Business Analysten während des Projektzyklus genauso wie Developer und Projektmanger gleichzeitig mit vielen verschiedenen Tools. Hektik und Stress lenken gerne vom Fachinhalt ab. Da ist es langfristig effektiver und effizienter, sich auf Inhalte zu konzentrieren, als beispielsweise über die Abschaffung einer im Unternehmen integrierten Software zu debattieren. Die Entscheidung trifft der Business Analyst meist nicht selbst. Viel entscheidender kann es daher für ihn sein, den Überblick zu behalten und eine gewisse Ordnung im Umgang mit Tools zu lernen.
### 5 Tipps für den erfolgreichen Umgang mit Tools
Sind Tools neu oder noch unbekannt, muss der Umgang damit gelernt werden. Nicht, dass noch ein Tool-Chaos entsteht; das wäre fatal …
Hier 5 Tipps, die helfen können:
1. **Zeit nehmen:** Sich Zeit für die neuen Tools nehmen, um diese kennen zu lernen, um den Umgang damit zu begreifen.
2. **Hilfe holen:** Ansprechpersonen bei Unternehmen sofort um Hilfe bitten, wenn etwas nicht direkt funktioniert. Es wäre schade, wenn wichtige Inhalte verloren gehen – vor allem, wenn dies vermeidbar ist.
3. **Direkt im Tool arbeiten:** Gemeinsam mit Expert:innen und Spezialist:innen an Fachinhalten direkt in der Toolumgebung arbeiten. Es kostet einfach so unglaublich viel Zeit erst einmal alles auf Papier aufzuschreiben und dann in die Tools zu übersetzen. Viel entspannter ist es, alles direkt am neuen Tool zu machen. Auch Aufgaben direkt innerhalb der Tool-Lösung abarbeiten – nicht mit alternativen Tool-Umgebungen als Zwischenlösung ‚*rumexperimentieren*‚. Das kostet richtig viel Zeit.
4. **Geduld bewahren:** Mutig und gelassen bleiben – auch, wenn einmal etwas nicht sofort funktioniert. Es gibt schließlich immer freundliche und hilfsbereite Expert:innen, die immer gerne weiterhelfen. Wirklich wahr!
5. **Dokumentieren:** Schrittfolgen zur Nutzung von neuen Tools für die eigene, persönliche Dokumentation aufschreiben. Man wird sicher nicht jede ‚*Doku*‚ brauchen, aber manchmal kann die eine oder andere Mitschrift von ‚*früher*‚ schon helfen, um in neuen Projektsituationen fachlich dabei zu bleiben und sich eben nicht nur mit den Tools zu ‚*beschäftigen*‚. In der Beratung kann das ein Schlüssel-Moment sein.
## Fazit: Tool-Kompetenz als Schlüssel
Wenn du für dich erst eine eigene Herangehensweise im Umgang mit Tools gefunden hast, kannst du dieses Wissen weitergeben. Das wird auch anderen Business Analysten helfen. Vielleicht hilft deine Erfahrung sogar bei der Softewarentwicklung.
Wer mit vielen Tools arbeitet, braucht Struktur – nicht Perfektion. Business Analysten bringen genau das mit: Sie adaptieren sich an neue Umgebungen, behalten den Überblick und nutzen Tools zielgerichtet. So unterstützen sie Projekte nicht nur technisch, sondern auch methodisch und menschlich.
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
- [Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
- [Teil 5: Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/)
**Kategorien:** Analytics & Insights
**Schlagwörter:** Softwarenentwicklung, Technologiemanagement, Transformation
---
### [Was machen Business Analysten? – Teil 7: Fachlich klar bleiben](https://thecattlecrew.net/2025/08/28/was-machen-business-analysten-teil-7-fachlich-klar-bleiben/)
**Published:** August 28, 2025
**Author:** Charlotte Grade
**Content:**
Business Analysten müssen Entscheidungen treffen – und zwar häufig. Das ist wichtig, um den Überblick über Fachinhalte zu behalten. Genau dieser Überblick ist in der Business Analyse unverzichtbar. Schließlich soll am Ende ein Produkt entstehen – sei es eine Software, eine Auswertung oder ein Prozess. Eine zentrale Aufgabe von Business Analysten ist es daher, Themen fachlich klar voneinander zu trennen und inhaltlich zu unterscheiden. Ansonsten droht das große Durcheinander im Projekt – und das kann niemand gebrauchen. Business Analysten verleihen Projekten gezielt Struktur und schaffen damit auch eine angenehme Arbeitsumgebung für Entwicklerinnen und Entwickler.
In diesem Teil der Serie erfährst du, welche Möglichkeiten es gibt, Fakten auseinanderzuhalten – auch wenn sie inhaltlich manchmal eng beieinander liegen.
---
Dies ist Teil einer kompletten Serie zur Business Analyse, die hier startet: [**Serienstart: Die Lage überblicken**](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
---
## 5 Tipps, um Fakten auseinanderzuhalten
1. **Themen trennen**
Fachinhalte sollen meist unabhängig voneinander bearbeitet werden – oft ist das auch ein ausdrücklicher Kundenwunsch. Business Analysten orientieren sich daran. Jeder Fachinhalt wird wie ein eigenes Thema behandelt. Manchmal hängen Themen zusammen, manchmal aber auch gar nicht. Und selbst wenn Begriffe ähnlich klingen, steckt inhaltlich oft etwas ganz anderes dahinter. Ein Beispiel: Eine „Cashcow“ ist selbstverständlich keine echte Kuh – das ist Standardwissen im Unternehmen.
2. **Themen splitten und verfeinern**
Business Analysten müssen sich schnell in alle relevanten Inhalte einarbeiten, um diese für Entwickler-Teams so präzise wie möglich aufzubereiten. Oft geht es um eine Detailtiefe bis „fünf Stellen nach dem Komma“. Erst mit dieser Klarheit kann sichergestellt werden, dass das Ergebnis wirklich den Projektbedarf deckt. Kommunikation muss dafür direkt, klar und unkompliziert sein.
3. **Komplex oder kompliziert?**
Fachinhalte können verschachtelt, komplex oder schlicht kompliziert sein. Manchmal ist nicht einmal klar, was ein Begriff bedeutet – da hilft ein Wörterbuch, Selbstvertrauen und die Fähigkeit, sich schnell in neue Themen einzuarbeiten. Je nach Projektkontext sind Inhalte unterschiedlich priorisiert – und Business Analysten müssen sich darin zurechtfinden.
4. **Aufgaben definieren**
Projekte dauern manchmal nur wenige Wochen, manchmal Monate oder Jahre. Über die Zeit sammelt sich viel Fachwissen an – deshalb ist eine ordentliche Dokumentation unverzichtbar. Analysieren ist das eine, Inhalte in konkrete Aufgaben und Ergebnisse zu übersetzen das andere. Beides gehört zur Business Analyse.
5. **Ergebnisse abliefern**
Alte Projekterfahrungen können hilfreich wirken – müssen es aber nicht. Häufig sind Inhalte aus vergangenen Projekten nicht auf aktuelle Kontexte übertragbar. Darum ist es so wichtig, alle Ergebnisse in den Systemumgebungen der Kunden zu dokumentieren – am besten mehrfach. Denn in Projekten sammelt sich oft mehr Wissen an als man es vermuten mag.
### Methodik-Idee: Netzwerkanalyse
Eine hilfreiche Methode in der Business Analyse ist die Netzwerkanalyse. Dabei werden aktuelle Themen gesammelt und visuell miteinander vernetzt. So wird sichtbar, welche Inhalte zusammengehören und welche eigenständig sind. Es ist ein bisschen so wie das Kinderspiel „Memory“: Pärchen suchen – konzentriert und schnell.
**So geht’s:**
1. Alle aktuellen Themen schriftlich sammeln.
2. Inhalte in Gruppen und Gebiete aufteilen.
3. Themen an übergeordneten Kategorien anheften.
4. Zusammenhänge markieren und sichtbar machen.
5. Aufgaben aus den Themen ableiten und direkt abarbeiten.
So entsteht eine Struktur, die Orientierung gibt und Klarheit schafft – selbst bei hoher Themenvielfalt.
Das könnte z. B. so aussehen:
---
Bald erscheint Teil 8 dieser Serie zum Thema **„Modernes Projektmanagement“**. Dort geht es um Projektmanagement in der Business Analyse. Auch wenn Business Analysten selbst nicht fürs Projektmanagement verantwortlich sind, müssen sie doch immer den Überblick behalten: über Ressourcen, Zeit, Bedarfe und Planungsdaten.
---
## Bisher erschienen:
- [Teil 1: Die Lage überblicken](https://thecattlecrew.net/2025/03/27/was-machen-business-analysten-teil-1-die-lage-ueberblicken/)
- [Teil 2: Die unsichtbare Kraft hinter erfolgreichen Projekten](https://thecattlecrew.net/2025/04/04/was-machen-business-analysten-teil-2-die-unsichtbare-kraft-hinter-erfolgreichen-projekten/)
- [Teil 3: Aus Anforderungen produktive Ergebnisse machen](https://thecattlecrew.net/2025/04/30/was-machen-business-analysten-teil-3-aus-anforderungen-produktive-ergebnisse-machen/)
- [Teil 4: Dashboards zum Fliegen bringen](https://thecattlecrew.net/2025/05/28/was-machen-business-analysten-teil-4-dashboards-zum-fliegen-bringen/)
- [Teil 5: Motiviert Ziele erreichen](https://thecattlecrew.net/2025/07/04/was-machen-business-analysten-teil-5-motiviert-ziele-erreichen/)
- [Teil 6: Tools gezielt nutzen](https://thecattlecrew.net/2025/07/18/was-machen-business-analysten-teil-6-tools-gezielt-nutzen/)
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** DWH, Entscheidungsfindung, Moderation, Reports
---
### [Vibe Coding im BI-Bereich: Wie KI uns ETL-Entwickler retten kann](https://thecattlecrew.net/2025/11/24/vibe-coding-im-bi-bereich-wie-ki-uns-etl-entwickler-retten-kann/)
**Published:** November 24, 2025
**Author:** Sebastian Pospiech
**Content:**
Vor ein paar Wochen habe ich etwas theoretischer auf die Entwicklungen der letzten zwei Jahre rund um KI und LLMs geschaut ([„Was haben ein Hammer und ein LLM (nicht) gemeinsam?“](https://thecattlecrew.net/2025/10/02/was-haben-ein-hammer-und-ein-llm-nicht-gemeinsam/)). Mir ging es darum zu erklären, dass ein LLM nicht die „böse KI“ ist, die uns unsere Jobs wegnimmt. Vielmehr stellt es aus der Perspektive des Human-Computer-Interaction-(HCI)-Designs die konsequente Weiterentwicklung von User Interfaces dar: von Lochkarten über Command Lines, GUIs und NUIs bis hin zu LLMs. Letztlich ist es ein intuitiver Weg, mit einem Computer zu kommunizieren und dieses „Werkzeug“ effizient zu bedienen.
## ETL – eine Geschichte
Für diesen Beitrag möchte ich in eine spezielle Nische eintauchen: ETL – Extract, Transform, Load. Eine zentrale Disziplin beim Aufbau und Betrieb von Data Warehouses und Lakehouses. Hier wird Software entwickelt, die Daten transportiert, transformiert, integriert und in ihrer Qualität sichert.
Bis vor etwa fünf Jahren folgte diese Disziplin stark der allgemeinen Entwicklung der HCI. Als Softwareentwicklungsdisziplin nutzte man dafür geeignete Sprachen auf passenden Plattformen: COBOL oder PL/SQL, Bash-Skripte, die Dateien kopieren oder orchestrieren, und natürlich SQL, das bis heute hervorragende Aggregationen liefert.
Mit der Zeit erkannte man das Potenzial und entwickelte dedizierte ETL-Software. Es entstanden Entwicklungsumgebungen und Frameworks, die alles unter einem Dach konsolidierten. Statt vieler einzelner Komponenten gab es nun komplette Suites – oft mit grafischen Oberflächen. Man programmierte und skriptete weniger und definierte stattdessen Graphen, die Prozessschritte und Datenflüsse visualisierten.
20 Jahre lang arbeiteten BI-Entwickler:innen genau so: spezialisiert auf Datenmodellierung und Tools der Anbieter. Dank des Low-Code-Ansatzes mussten sie jedoch keine voll ausgebildeten Softwareentwickler:innen sein. Entscheidend waren das Verständnis von Datenflüssen, der Fachlichkeit und das Lösen vielfältiger Optimierungsprobleme.
## Was passierte nun vor fünf Jahren?
LLMs waren noch nicht praxisreif, aber die ETL-Welt wurde durcheinandergerüttelt. Cloudanbieter boten die ideale Basis für Data Lakes: günstiger, skalierbar, flexibel. Aber sie boten keine monolithischen Suites. Stattdessen viele kleine Tools, die miteinander integriert werden wollten. Keine Low-Code-Oberflächen, sondern Python, Spark, Scala.
Gefühlt ein Rückschritt. Während die Softwarewelt immer weiter Richtung „weniger Code, mehr Framework“ wanderte, schien die ETL-Nische einen anderen Weg einzuschlagen. Viele BI-Spezialist:innen fragten sich:
„Muss ich jetzt Softwareentwickler werden?“
„Lohnt sich das alles, wenn wir statt Standardlösungen wieder selbst bauen müssen?“
## Was hat es mit dem Trend auf sich?
… Um das zu verstehen, lohnt ein Blick darauf, warum ETL so wurde, wie es war. Grafische Tools waren ein offensichtlicher Trend – aber nicht der einzige Grund.
Wer sich mit Prozessdesign, Prozessoptimierung und Modellierungssprachen wie BPMN, EPK, UML, DFD oder PAP beschäftigt hat, erkennt schnell: grafische ETL-Tools sind im Kern nichts anderes als Datenflussdiagramme (DFDs).
Betrachtet man zudem die Zeit, in der große Unternehmen begonnen haben, stark in Prozesse und deren Modellierung zu investieren, fällt auf, dass die Erfolgsphase graphbasierter ETL-Tools eng mit diesem Trend zusammenhängt.
Vielleicht war ETL also lange Zeit nicht deshalb grafisch, weil es intuitiv ist, sondern weil es den dominierenden Zeitgeist traf. Das ist meine persönliche These – wissenschaftlich nicht belegt, aber faktisch lässt sich festhalten:
- Man ist in proprietären Toolwelten gefangen.
- Compiler übersetzen die Grafen ohnehin wieder in Code – oft nicht optimal.
- Versionierung, Kollaboration und Annotationen funktionieren nur eingeschränkt.
- Selbst nach 20 Jahren haben die Oberflächen teilweise gravierende Bugs.
- Performanceoptimierungen verlangen kreative Workarounds innerhalb der Suite-Beschränkungen.
Kurzum: Es gibt gute Gründe für den aktuellen „Rückschritt“ hin zu mehr Code. Und so befinden wir uns seit einigen Jahren in einer Phase des „more code“ statt „low code“ – verbunden mit der Herausforderung, Mitarbeitende für diese Reise zu befähigen.
## Gäbe es da nicht …
… eine ganz neue Form der Mensch-Computer-Interaktion: eine, bei der ich fachliche Anforderungen in natürlicher Sprache formuliere und am Ende ein funktionierendes Stück Software erhalte. Eine Form, die ohne grafisches Design und ohne „Wenn-Dann“-Compiler auskommt, die riesige Bausteine erzeugen.
Ihr wisst, worauf es hinausläuft.
Die aktuelle Lücke – sinkender ETL-Entwicklungskomfort – kann durch ein nutzerfreundliches Interface gefüllt werden, das barrierefrei zugänglich ist und Code erzeugt, der:
- toolunabhängig ist,
- moderne Versionierung unterstützt,
- kollaborativ weiterentwickelt werden kann,
- und sich performanceoptimieren lässt (oder es bereits ist).
LLMs könnten unsere grafische Oberfläche ersetzen. Ich modelliere nicht mehr visuell – ich schreibe oder beschreibe den Code. In beiden Fällen entsteht ETL-Code. Aber vielleicht ist der neue Weg einfacher – und das Ergebnis besser.
## Quo Vadis
Soweit die Vision. Funktioniert das heute schon – oder sind wir noch Jahre entfernt?
Nach dem Clickbait meines letzten Blogbeitrags (der Hammer) nutze ich heute das Instrument des Cliffhangers. Im nächsten Beitrag werde ich versuchen, aus einer fachlich-textuellen Beschreibung mittels KI einen vollwertigen ETL-Prozess zu erzeugen – und dasselbe mit einer einfachen Handzeichnung.
Bis dahin: Schaut gern in die anderen Cattle-Crew-Blogbeiträge. Es gibt bereits einiges zu LLMs und Vibe Coding.
### Hier nur ein paar Beispiele:
[Zeitreihenanalysen im Controlling](https://thecattlecrew.net/2025/11/12/zeitreihenanalysen-im-controlling-von-belastbaren-forecasts-zu-besseren-entscheidungen/)
[Vibe Coding – Teil 1: Mit KI zum eigenen Homeserver](https://thecattlecrew.net/2025/10/20/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen/)
[Vibe Coding – Teil 2: Linux-Server mit KI konfigurieren](https://thecattlecrew.net/2025/11/08/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen-teil-2/)
[KI im Kundeneinsatz: Ein Reality Check der Pyramid-Funktionalität](https://thecattlecrew.net/2025/10/14/ki-im-kundeneinsatz-ein-reality-check-der-pyramid-funktionalitaet/)
[Was haben ein Hammer und ein LLM (nicht) gemeinsam?](https://thecattlecrew.net/2025/10/02/was-haben-ein-hammer-und-ein-llm-nicht-gemeinsam/)
[Open Data in Aktion: Mit KI Abwasserdaten analysieren](https://thecattlecrew.net/2025/08/21/open-data-in-aktion-mit-ki-abwasserdaten-analysieren/)
[RAG or not to RAG, Teil 1: Wann braucht es einen RAG-Ansatz](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/)
[RAG or not to RAG, Teil 2: Prozesse und Aufwand in der Praxis](https://thecattlecrew.net/2025/05/15/to-rag-or-not-to-rag-2-2/)
[Was steckt hinter RAG und Semantischer Suche?](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/)
[RAG und Semantische Suche in der Praxis](https://thecattlecrew.net/2024/01/29/spezialwissen-fuer-chatbots/)
**Kategorien:** AI & Data Science, Development
---
### [Auf nach Red Hat/Oracle Linux 9 – der Sonne entgegen](https://thecattlecrew.net/2025/11/07/auf-nach-red-hat-oracle-linux-9-der-sonne-entgegen/)
**Published:** November 7, 2025
**Author:** Mario Nolte
**Content:**
Red Hat Enterprise Linux 7 (RHEL7) oder Oracle Linux 7 (OL7) bietet gegenüber RHEL9/OL9 vor allem Vorteile in Bezug auf Stabilität, Kompatibilität mit älterer
Software und langjährige Produktionsumgebungen. Allerdings ist RHEL7/OL7
seit Juni 2024 im regulären Wartungszyklus ausgelaufen und nur noch mit
Extended Life Cycle Support (ELS) verfügbar.
## **Vorteile von RHEL9/OL9 gegenüber RHEL7/OL7**
### 1. Bewährte Stabilität
RHEL7/OL7 ist seit 2014 im Einsatz und hat sich in vielen produktiven Umgebungen als äußerst stabil erwiesen. Viele Unternehmen setzen auf RHEL7/OL7, weil es über Jahre hinweg getestet und optimiert wurde.
RHEL9/OL9 ist eine stabile Weiterentwicklung und bringt viele Vorteile mit sich.
So in Themen Virtualisierung und Containerisierung. Damit verbunden sind verbesserte und flexible Möglichkeiten der Datensicherheit unter Beachtung der Sicherheitsstandards wie NIS2, Dora oder dem CRA.
### 2. Kompatibilität mit älterer Software
Legacy-Anwendungen, die auf älteren Bibliotheken oder Kernel-Versionen basieren,
laufen oft nur unter RHEL7/OL7 ohne Anpassungen.
RHEL9/OL9 verwendet neuere Compiler und Bibliotheken, was zu Inkompatibilitäten führen kann. Jedoch sind die Hersteller schon seit längeren auf den Umstieg vorbereitet.
### 3. Vertraute Systemverwaltung
RHEL7/OL7 nutzt noch klassische Tools wie iptables, network-scripts und init.d, die in
RHEL9/OL9 durch nftables, NetworkManager und systemd ersetzt wurden.
Für Administratoren, die mit älteren Tools vertraut sind, ist RHEL7/OL7 oft einfacher zu handhaben (da bekannt). symtemd, nftables, NetworkManager sind allgemeingültige Tools und Mechanismen, die in der Linux Welt seit geraumer Zeit einen Standard darstellen. Dies führt speziell in heterogenen Umgebungen zu Vereinfachungen in der Administration.
### 4. Langfristige Infrastrukturabhängigkeiten
Viele Unternehmen haben ihre Infrastruktur (z.B. Monitoring, Backup, Automatisierung) speziell auf RHEL7/OL7 abgestimmt.
Ein Umstieg auf RHEL 9 erfordert oft umfassende Tests und Anpassungen.
Die Einsatz von Virtualisierung und Containerisierung wird sehr vereinfacht. Hersteller von Lösungen haben Ihre Hausaufgaben erledigt und Releases für RHEL9/OL9 für bereitgestellt.
### 5. ELS (Extended Life Cycle Support) bis 2029
Red Hat bietet für RHEL7 optionalen ELS-Support bis Mai 2029 an. Damit einhergehend wird auch OL9 über Oracle im Extended Support betrieben.
Damit können Unternehmen weiterhin Sicherheitsupdates für kritische Komponenten erhalten, ohne sofort migrieren zu müssen. Jedoch ist dies an Bedingungen geknüpft. Auch ist hier der Kostenfaktor zu nennen. Da es mit der Einleitung der EOL Phase, um none-Standard-Produkt handelt.
### 6. NIS2 fordert aktuellen Stand der Technik
Die NIS2-Richtlinie soll die Cybersicherheit in der EU verbessern und Unternehmen wie Behörden widerstandsfähiger gegen digitale Angriffe machen. Die aktuelle Version von Redhat und Oracle Linux in Organisationen einzusetzen wäre also für Compliance und Sicherheit relevant. NIS2 fordert „den aktuellen Stand der Technik“.
**Stand der NIS2 Gesetzgebung**:
- **Aktueller Stand:** Seit 13. November 2025 ist das Gesetzgebungsverfahren abgeschlossen.
- **Erwartetes Inkrafttreten:** Anfang 2026.
##
**Einschränkungen von RHEL7/OL7 (Stand 2025)**
Kein regulärer Wartungssupport mehr seit Juni 2024.
Keine neuen Hardware-Treiber oder Features.
Sicherheitsrisiken steigen, wenn kein ELS gebucht wird.
## **Fazit**
RHEL7/OL7 war lange die richtige Wahl. Aber wer heute noch auf Altbewährtes setzt, läuft Gefahr, morgen den Anschluss zu verlieren. RHEL9/OL9 ist nicht nur ein Upgrade – es ist ein strategischer Schritt in Richtung Zukunft.
Du willst wissen, wie der Umstieg gelingt, ohne dass die Produktion ins Stolpern gerät?
Ob Oracle Database, Fusion Middleware 14c, PostgreSQL, MongoDB, Virtualisierung, OnPrem oder in der Cloud … – wir unterstützen dich!
Praxisnah, effizient, sicher und mit Weitblick – [DOAG 2025](https://anwenderkonferenz.doag.org/de/home/) komm doch vorbei!
**Kategorien:** Database, Infrastructure, IT-Security
---
### [Zeitreihenanalysen im Controlling: Von belastbaren Forecasts zu besseren Entscheidungen](https://thecattlecrew.net/2025/11/12/zeitreihenanalysen-im-controlling-von-belastbaren-forecasts-zu-besseren-entscheidungen/)
**Published:** November 12, 2025
**Author:** Fabian Heidenstecker
**Content:**
Zeitreihen begegnen uns im Controlling täglich: Absatzkurven, Umsatzentwicklung, Kapazitätsauslastung, Retourenquoten oder externe Treiber wie Inflations- und Wechselkurse. Sie alle verändern sich über die Zeit und enthalten damit mehr als Historie. Sie tragen Information über mögliche zukünftige Entwicklungen in sich. Wer diese Signale sauber extrahiert, gewinnt Handlungsspielräume. Konkret lassen sich so z. B. Budgets proaktiver steuern, Bestände gezielter planen, Kampagnenzeitpunkte präziser wählen.
## Von der vagen Vorhersage zum belastbaren Forecast
Der Forecast ist die betriebswirtschaftlich relevante Form der Vorhersage: datenbasiert, modellgestützt, wiederholbar. Entscheidend ist nicht nur die Präzision, sondern die Verwendbarkeit im jeweiligen Entscheidungskontext. Ein guter Forecast macht Annahmen transparent, liefert eine nachvollziehbare Logik und zahlt auf eine konkrete Managementfrage ein – etwa *„Wie staffeln wir Werbedruck und Personal in den nächsten acht Wochen filial- bzw. kanalgenau?“*.
## Woran erkennt man einen brauchbaren Forecast?
- **Präzision:** geringe Abweichung zu Vergleichsdaten und der späteren Realität
- **Validität:** realistische Größenordnung und realistische Annahmen.
- **Nützlichkeit:** klare Übergabe an Planung/Steuerung (z. B. Budget, Personal, Bestände).
- **Transparenz:** Annahmen, Treiber und Grenzen sind erklärbar.
## Bausteine einer Zeitreihe – und warum sie praktisch zählen
Eine Zeitreihe lässt sich idealtypisch in drei Komponenten zerlegen. Der **Trend** zeigt die Richtung (z. B. Wachstum eines Segments). **Saisonalität** repräsentiert wiederkehrende Muster – wöchentlich, monatlich, jährlich. **Zufallskomponenten** stehen für Zufälle und Einmaleffekte. Diese Trennung ist keine Theorie-Spielerei: Sie bestimmt die geeignete Modellfamilie und die sinnvolle Granularität: z. B. Tag vs. Woche.
### Praxisbeispiel
In Retail-Daten führen Ladenschlusszeiten, Feiertage und saisonale Peaks zu regelmäßigen „Zacken“; auf Tagesebene kann die Streuung hoch sein. Eine Aggregation auf Wochenebene glättet Zufälligkeit und erhöht häufig die Prognosequalität – bei gleichzeitig höherer Steuerbarkeit im Controlling.
## Baselines zuerst: Warum einfache Methoden sinnvoll sind
Viele Teams starten mit Excel – und das ist gut so. Ein **Baseline-Forecast** (z. B. *„Vorjahr fortschreiben“*, *„gleitender Mittelwert“*, *„naive Saisonkurve“*) ist schnell erstellt und liefert einen wichtigen Referenzpunkt.
Zwei Effekte sind dabei zentral:
1. **Benchmarking**: Komplexere Modelle müssen zeigen, dass sie die Baseline zuverlässig schlagen.
2. **Kommunikation**: Einfache Regeln sind für Stakeholder unmittelbar nachvollziehbar und schaffen Akzeptanz.
In einfachen und wenig schwankenden Zeitreihen erreichen naive saisonale Verfahren oft bereits einstellige prozentuale Abweichungen. Das genügt nicht immer – aber es ist eine solide Unterkante.
## Mehr Präzision mit Statistik – direkt im BI-Kontext
Wo Muster stabil sind und Saisonalität dominiert, leisten statistische Verfahren (z. B. exponentielle Glättung) hervorragende Dienste. In BI Tools wie Power BI lassen sich automatische Forecasts unmittelbar auf Visualisierungen anwenden: Parameter wie Horizont, Saisonalität (z. B. 52 Wochen, 364 Tage), Konfidenzintervalle und Backtest-Fenster machen Effekte sichtbar. Die Stärke liegt in der Interaktivität – Filialen, Segmente, Kanäle lassen sich „on the fly“ vergleichen.
### Wo liegt die Grenze?
Viele BI-Forecasts existieren primär im Diagramm. Für Summenbildung, KPI-Vergleiche oder MAPE\*-Berechnung braucht es einen Export oder einen modellierten Datenpfad, der die Vorhersagewerte als Datensätze verfügbar macht.
## Wenn’s komplex wird: Machine Learning, Python und Fabric
Sobald mehrere Treiber interagieren (Preis, Rabattierungen, Wetter, Kampagnen, Kanäle), spielt **Machine Learning** seine Stärke aus. Mit **Python-Notebooks** lassen sich Explorationsschritte, Feature-Engineering und Modellierung transparent dokumentieren und versionieren. **AutoML-Ansätze** (z. B. in Microsoft Fabric) testen mehrere Modellfamilien, wählen hyperparametrisiert die beste Variante und erzeugen reproduzierbare Pipelines – inklusive Backtests und Qualitätsmetrik.
Das verschiebt den Fokus: weniger manuelle Modellpflege, mehr Augenmerk auf Datenqualität, Feature-Design und die Übersetzung der Ergebnisse in Steuerungslogik (z. B. „Wie viele FTE-Stunden verschieben wir pro Woche je Filiale?“).
## Qualität messen – ohne Matheballast
Zur Einordnung der Vorhersagequalität hat sich im Controlling der **MAPE** (Mean Absolute Percentage Error)\* bewährt. Er drückt die mittlere prozentuale Abweichung aus. Der macht es für Stakeholder leicht verständlich und über Perioden vergleichbar.
Daumenregel für die Einordnung:
- **< 10 %:** sehr gute Qualität
- **10 – 20 %:** gut/zweckmäßig
- **20 – 50 %:** begrenzt nutzbar, modellieren oder granularitätsseitig neu denken
Wichtig: Den MAPE immer konsequent **out-of-sample** (auf Testfenstern) bestimmen und im Betrieb laufend überwachen.
## Praxisnahe Erkenntnis: Granularität schlägt Feintuning
In Retail-Zeitreihen mit Sonn- und Feiertagseffekten führt die Tagesebene häufig zu schwankenden Abweichungen. Eine Aggregation auf Wochenebene glättet Ausreißer und erhöht die Prognosequalität sichtbar (z. B. von ~8 % auf ~6 % MAPE). Gleichzeitig ist die Wochenebene näher an vielen Steuerungsrhythmen (Personalplanung, Kampagnentaktung, Warenverfügbarkeit).
Statt ein Tagesmodell immer weiter zu „feintunen“, ist die sauber begründete Granularitätswahl oft der größere Hebel.
## Grenzen anerkennen – und bewusst umgehen
Nicht jede Zeitreihe ist vorhersagbar. Märkte, die einem Random-Walk ähneln (z. B. kurzfristige Kursbewegungen), lassen sich mit Standardverfahren kaum treffsicher prognostizieren. Tests auf Stationarität (z. B. Augmented Dickey-Fuller) helfen bei der Einordnung. Der Punkt ist operativ: Ressourcen dorthin lenken, wo Vorhersagefähigkeit und Entscheidungnutzen hoch sind. Bei chaotischen Reihen stattdessen mit Szenarien, Schwankungsbreiten und Risikobudgets arbeiten.
## Vom Modell zum Management-Instrument
Ein Forecast entfaltet seinen Wert erst im Prozess. Das erfordert drei Dinge:
1. einen klaren Zweck,
2. robuste Datenpfade
3. und sichtbare Verantwortung.
### Minimal-Checkliste für Business-Analysten
- **Purpose klar?** Welche Entscheidung wird mit dem Forecast getroffen – und auf welcher Ebene (Tag/Woche/Monat)?
- **Datenbereitstellung robust?** Fehlende/ausreißende Werte, Kalenderlogik, Feiertage, Promotions, Preisänderungen – alles im Griff?
- **Qualität im Betrieb sichtbar?** MAPE/MAE je Segment, Drift-Erkennung, Alarmierung bei Qualitätsabfall.
- **Persistenz & Reproduzierbarkeit?** Versionierte Modelle, Trainingsdaten-Stände, Parameter-Historie, wiederholbare Pipelines.
- **Hand-off definiert?** Schnittstellen zu Budget, Einsatzplanung, Einkauf, Kampagnenmanagement.
## Werkzeugwahl pragmatisch treffen
Es gibt nicht das eine „richtige“ Tool – es gibt den passenden Stack für euren Reifegrad und Anwendungsfall.
- **Excel:** ideal für Baselines, schnelle Vergleichsrechnungen, Kommunikation mit Fachbereichen.
- **Power BI:** interaktive Visual Analytics, schnelle statistische Forecasts, Storytelling mit Daten – mit Exportpfad für Weiterverarbeitung.
- **Python/Fabric:** wiederholbare ML-Pipelines, AutoML, Skalierung über Workspaces, Integration mit Lakehouse/Data Warehouse.
Die sinnvolle Kombination sieht in vielen Organisationen so aus: Baselines und Visualisierung im BI, operative Forecasts und Qualitätsmonitoring in reproduzierbaren Pipelines – mit klaren Übergaben in die Planungs- und Steuerungsprozesse.
## Fazit
Zeitreihenanalysen sind dann wertvoll, wenn sie Entscheidungen verändern. Eine solide Baseline schafft Transparenz. Statistik bringt Stabilität. Machine Learning erweitert das Vorhersagefenster – vorausgesetzt, Datenqualität, Granularität und Prozessintegration stimmen.
Wer den Forecast als iterativen Management-Prozess versteht, gewinnt nicht nur Genauigkeit, sondern vor allem Geschwindigkeit in der Steuerung. Oder kürzer: Jede Vorhersage ist eine Einladung, die Zukunft besser zu gestalten.
***\* MAPE** steht für Mean Absolute Percentage Error, also den durchschnittlichen prozentualen Fehler einer Prognose. Er zeigt, wie weit Prognosen im Mittel von den tatsächlichen Werten abweichen, bezogen auf die Größe der Werte selbst. (Vgl. [Wikipedia](https://en.wikipedia.org/wiki/Mean_absolute_percentage_error))*
**Kategorien:** AI & Data Science, Analytics & Insights
---
### [10 (scheinbare) Selbstverständlichkeiten im operativen Projektmanagement](https://thecattlecrew.net/2025/11/11/10-scheinbare-selbstverstaendlichkeiten-im-operativen-projektmanagement/)
**Published:** November 11, 2025
**Author:** Stefan Sonner
**Content:**
In meinem letzten Blogpost *„Deine Stakeholder sollen sich gefälligst entscheiden!“* ging es um einen Aspekt des Stakeholder-Managements – und ich hatte bereits angekündigt, demnächst mehr über meine Arbeit in Projekten und meine Übernahme zu berichten.
Heute ist es soweit: Ich nehme euch wieder mit in eine fiktive Situation, die ich im Projektalltag immer wieder erlebe – mit überraschenden Erkenntnissen, viel Kommunikationsbedarf und der Frage: Was darf man als Projektleitung eigentlich voraussetzen?
Es geht um unausgesprochene Standards, Routinen, die dann aber nicht wirklich existieren, und vermeintliche Selbstverständlichkeiten, die sich als alles andere als selbstverständlich entpuppen.
## Ausgangssituation: Unzufriedenheit beim Kunden
Es war Herbst, als sich unser fiktiver Kunde bei meinem Arbeitgeber meldete, weil er unzufrieden über den Verlauf eines Projektes war. Das Team bestand zu dieser Zeit aus einer Projektleitung und drei Entwicklern.
Der Kunde sah eine Lösung im Wechsel der Projektleitung und ich wurde gebeten, diese Rolle zu übernehmen. Eine Situation, die ich nicht zum ersten Mal erlebe. Aber in diesem Fall zeigte sich – auch das erlebe ich immer wieder – schon bei der Übergabe: Es gab einiges, das ich als selbstverständlich angesehen hatte, was in der Realität schlicht nicht gegeben war.
## Erste Erkenntnis: Der Scope – oder eher: der große Nebel
Meine erste Frage an den bisherigen Projektleiter war simpel: *„Was genau muss bis zum Projektende noch umgesetzt werden?“*
### Meine Erwartung:
Als PL habe ich einen Überblick über das, was noch zu tun ist – insbesondere, wenn das Projekt nur noch rund drei Monate läuft.
### Die Realität:
Kein klarer Scope. Ein völlig überladener, unstrukturierter Backlog. Unpriorisierte Tickets, veraltete Einträge, Duplikate – eine wahre JIRA-Geisterbahn.
Meine (zugegeben direkte) Frage: „Warum hast du das denn nicht längst bereinigt?“
Die Antwort: „Ja, wollte ich ja, aber mit mir redet ja keiner.“
Das ließ mich erstmal sprachlos zurück.
## Kein Kollegen-Bashing – sondern ein Appell
Ich möchte hier nicht den moralischen Zeigefinger heben oder jemanden bloßstellen. Vielmehr ist dies ein Aufruf an alle, die Projekte leiten:
### Ihr seid das Kommunikationsdrehkreuz.
Ihr haltet die Fäden zusammen, vernetzt Stakeholder und treibt Entscheidungen voran.
*Communication is King.* Oder wie ich manchmal sage: *„Projektleitung ohne Kommunikation? Das ist wie Schach spielen, ohne dem Gegner zu sagen, dass er dran ist.“*
## Was ich daraus gelernt habe
Im Zuge der Projektübernahme und beim Blick in Dailys, Backlog und Teamrunden habe ich mir einige grundlegende Leitlinien zusammengestellt. Dinge, die für mich in der Projektleitung selbstverständlich sind – und die ich heute gern mit euch teile:
### 10 (scheinbare) Selbstverständlichkeiten in der Projektleitung
1. **Entscheidungen und relevante Infos werden schriftlich dokumentiert**
Egal ob in Confluence, per Mail oder im JIRA-Ticket.
2. **Tickets, die begonnen wurden, werden zügig abgeschlossen**
a) Idealerweise fertiggestellt und ausgeliefert
b) Alternativ sinnvoll gesplittet – Teil 1 fertig, Teil 2 ins Backlog
c) Hauptsache: eindeutiger Status
3. **Tickets werden kommentiert**
Mindestens dann, wenn sie im Board von Spalte zu Spalte wandern.
4. **Jedes Ticket wird geschätzt**
Story Points ? Stunden ? Personentage.
5. **Das JIRA-Board ist zentrales Arbeitsmittel**
Im Daily, im Jour fixe, in Reviews.
So wissen alle, was läuft – oder eben nicht.
6. **Wir kommunizieren aktiv – mit allen Beteiligten**
a) Entwicklerteam
b) Fachbereich
c) Kunden-IT
d) Projektleitungskolleg:innen
Ein *„Mit mir redet ja keiner“* zählt nicht.
7. **Restlicher Scope wird regelmäßig gegen Zeit und Kapazität geprüft**
a) Wenn’s klemmt: kommunizieren, priorisieren, nachjustieren
b) Wenn’s am Anfang schon nicht passt: frühzeitig ansprechen!
8. **Ausgelieferte Releases werden dokumentiert**
z.B. mit Confluence-Seite, JIRA-Release oder einfachen Release-Notes.
9. **Dokumentation wird nicht vergessen**
Ab und zu prüfen, aktualisieren, aufräumen.
10. **JIRA wird strukturiert genutzt**
Mit Sprints, Epics, Komponenten, Releases. Struktur ist kein Selbstzweck, sondern Grundlage für Klarheit.
## Diskussionsanstoß an die Community
Ich bin mir sicher: Viele von euch nicken jetzt – andere vielleicht auch nicht. Und genau das interessiert mich.
- Welche dieser Punkte sind für euch selbstverständlich?
- Wo habt ihr ähnliche Erfahrungen gemacht?
- Oder ganz andere?
Ich freue mich auf eure Gedanken, Kommentare und Beispiele. **Let’s talk PL!**
**Kategorien:** Development, Tools & Methoden
---
### [Vibe Coding – Teil 2: Linux-Server mit KI konfigurieren](https://thecattlecrew.net/2025/11/08/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen-teil-2/)
**Published:** November 8, 2025
**Author:** Andreas Lorenz
**Content:**
Ein eigener Linux-Server, der Dienste wie Nextcloud, Collabora, Immich, einen DLNA Server und weitere Services bereitstellt – bei mir zu Hause, ohne Cloud-Abhängigkeiten, ohne monatliche Abos, ohne die Frage, wer meine Fotos scannt und Dokumente indiziert. Souveräne IT eben. So mein Ziel.
Im [ersten Teil](https://thecattlecrew.net/2025/10/20/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen/) haben wir Hardware ausgewählt und den Mini-PC aufgebaut – leistungsfähig, leise und sparsam genug für den 24/7-Betrieb.
Jetzt geht es an die Konfiguration: Welches Betriebssystem? Wie binde ich Storage an und wie richte ich Virtuelle Maschinen (VMs) ein? ChatGPT begleitet mich dabei als „Co-Pilot“ – und wie sich zeigen wird, ist das ein zweischneidiges Schwert.
---
## Die Wahl des Betriebssystems
Zuerst die Auswahl des passenden Betriebssystems: Mit meinen Vorgaben schlägt mir die KI tatsächlich meine Favoriten vor – Proxmox, TrueNAS, Unraid und einen vollständigen Selbstbau. Letzteren sortiere ich sofort aus. Ich will in meiner Freizeit nicht zum Vollzeit-System-Administrator mutieren, zumal die Profis vieles deutlich besser beherrschen als der Freizeit-Admin.
Wichtig ist für mich vor allem die **Effizienz**: Was 24/7 läuft, darf im Idle-Modus nicht viel Strom verbrauchen. Dazu kommt die **einfache Konfiguration** und sehr wichtig die Möglichkeit fertige Apps als Docker Images nutzen zu können. Final auch **Security**: Wer sich schon einmal aktiv Gedanken gemacht hat, wie viele wichtige Daten heute nur noch digital vorhanden sind, kennt die Gedanken vermutlich. Von den digitalen Fotoalben über wichtige Dokumente bis hin zu Unterlagen für Versicherungen und Steuererklärung – bei so vielen privaten und auch sensiblen Daten sind Sicherheit und Backup zentrale Parameter.
Final entscheide ich mich für **Proxmox VE**, vor allem weil mich die Option, LXC-Container zu nutzen, sehr reizt. Auch so benötigt Proxmox als Hypervisor selbst nur wenig Ressourcen, die Software ist ausgesprochen professionell, mit dem Web-Frontend lassen sich die meisten Admin-Aufgaben auch ohne Konsole erledigen und wenn nicht, dann erlaubt mir der Debian Unterbau, auch mal tief ins System einzugreifen. Für mich die perfekte Wahl.
Zum Thema Proxmox könnt Ihr gerne auch den Artikel von meinem Kollegen [Jeremy Smeets ](https://thecattlecrew.net/author/jeremy-smeets/) lesen: [Proxmox VE: Mit #OpenSource in die Digitale Souveränität](https://thecattlecrew.net/2025/09/18/proxmox-ve-open-source-virtualisierung-fuer-digitale-souveraenitaet/)
---
## Storage einrichten: Viele Optionen, eine Falle
Zwei SATA-SSDs sollen für alle Apps als Storage genutzt werden – und hier gibt es nicht nur viele unterschiedliche Optionen, sondern auch sehr viele Wünsche, die erfüllt werden müssen. ChatGPT liefert wieder gute Vorarbeit und stellt CIFS, NFS, VirtioFS, Mount bind und sogar einen eigenen Storage Service zur Diskussion.
**Ich mag diesen Dialog.** Es ist fast wie ein Gespräch mit einem erfahrenen Kollegen, bei dem man verschiedene Ansätze abwägen kann. Die KI erklärt Vor- und Nachteile strukturiert, ich kann Rückfragen stellen, Szenarien durchspielen.
Doch dann kommt der Moment, wo das gute Gefühl, sagen wir rückblickend einmal, dem Entsetzen weicht …
### Die BTRFS-Falle
Bei der Auswahl des Dateisystems entscheide ich mich nach „intensiver Beratung“ für **BTRFS**, ChatGPT liefert viele Vorteile und eigentlich keine wirklichen Nachteile. Doch weit gefehlt, das war keine gute Entscheidung, wie die Praxis glücklicherweise sehr früh zeigen wird. Früh genug, dass nur wenige Daten vom Backup wiederhergestellt werden müssen.
**Was war passiert?** Mehrere Container müssen gleichzeitig auf die Daten zugreifen – und genau das verträgt BTRFS nicht. Das Dateisystem war schon kurz nach dem Start korrumpiert und die Daten waren verloren.
Da ich BTRFS bis dahin nicht kannte, hätte ich diese Information schon gerne für die Entscheidung gehabt. Natürlich hatte ich ChatGPT nicht explizit nach den Risiken paralleler Schreibzugriffe gefragt – und mit einem vollständigeren Prompt hätte mich die KI vermutlich besser beraten. Für mich ist das ein klassisches „Hinterher ist man immer klüger“-Phänomen.
**Aber:** Der Mehrwert von Erfahrung ist ja gerade, dass man vorher abwägt und es gar nicht erst zum „Hinterher“ kommt. Aus meinem Use-Case-Szenario war eigentlich klar ersichtlich, dass es zu parallelen Schreibzugriffen kommen würde. Ein erfahrener Kollege hätte mich hier gewarnt und ein anderes Dateisystem empfohlen.
---
## Zwei Seiten der KI-Medaille
**Hier zeigen sich für mich zwei wichtige Facetten beim Einsatz der KI als Projektpartner:**
### Die positive Seite
Ich stelle Fragen zu Optionen, bekomme verständliche Erklärungen strukturiert aufbereitet und kann dann bewusst entscheiden. Das ist Vibe Coding / Engineering im besten Sinne – die KI als Erklärbär und Sparringspartner.
### Die Schattenseite
Schwierig wird es, wenn man sich in einer Technologie gar nicht auskennt und meint, sich zusammen mit der KI das Thema erschließen zu können. **Ein LLM „denkt“ NICHT wie ein erfahrener Administrator / Entwickler.** Zugegeben, ein Sprachmodell denkt natürlich nicht im klassischen Sinne, sondern sagt nur die wahrscheinlichste Antwort voraus; Aber OK, lassen wir das mal außen vor. Die KI präsentiert Optionen, erklärt Features – aber sie antizipiert nicht die kritischen Fragen, die ein Experte stellen würde. Ein menschlicher Senior-Administrator hätte vermutlich gefragt: „*Mehrere Container? Parallele Zugriffe?*“ und wäre dann zum Schluß gekommen „*Dann nimm besser kein BTRFS*„.
---
## Die erste VM: Parameter verstehen lernen
Auch beim Aufsetzen der VMs gibt es Positives zu berichten, allerdings auch wieder ungewünschte Nebeneffekte. Ich verwende Debian Linux als minimales System – kein Desktop, nur das Nötigste. Beim Erstellen der VM in Proxmox begegnen mir eine ganze Reihe von Einstellungen: Cores vs. Sockets? Welche Disk-Technologie? Welches Disk-Format? Cache-Settings?
Hier komme ich zusammen mit der KI schnell voran und die erste VM läuft, Debian ist installiert. ChatGPT war hier zunächst ein guter Lernbegleiter. Ich verstehe die Parameter, kann informierte Entscheidungen treffen. Das ist genau die Stärke der KI: Optionen erklären, Kontext liefern, Verständnis ermöglichen. Aber auch hier hat die Medaille ihre Kehrseite:
---
## Der Boot-Crash: Eine kritische Lektion
Das Fiasko beginnt harmlos: Immich braucht mehr Speicherplatz, also füge ich der VM eine zweite Disk nur für die Daten hinzu. Partitionieren, formatieren, in die System-Konfiguration eintragen. Alles schnell erledigt. Ich will einen kleinen Test machen und starte die VM neu. Autsch, das war nicht gut. Der Server bzw. die Virtuelle Maschine kommt gar nicht mehr hoch.
**Was war passiert?** Es gab ein Problem, die neue Festplatte einzubinden und in der Konfiguration fehlte leider das Flag `nofail`. Ohne dieses Flag blockiert der Boot-Prozess komplett, wenn eine Disk nicht verfügbar ist. Und weil ich bei der Installation keinen Root-Zugang vorbereitet hatte, kam ich auch nicht an eine Recovery-Shell. Als Ergebnis durfte ich die Maschine neu installieren. Dramatisch war das nicht, aber ärgerlich allemal.
**Die wichtigste Erkenntnis:** `nofail` ist kein Nice-to-have, sondern bisweilen sehr wichtig und bei einer Virtuellen Maschine sollte man nicht auf einen expliziten root Account verzichten.
**Und genau hier liegt für mich wieder ein Schwachpunkt der KI-Beratung:** ChatGPT hatte sauber erklärt, welche Parameter ich verwenden kann, um eine Disk einzubinden. Genau die feinen Details zur Syntax sind es , die ich nicht im Kopf behalten will: *Wo kommt ein Leerzeichen, ein Komma, ein Doppelpunkt hin; wie binde ich ein NFS Laufwerk ein?*
Bei solchen Details hilft die KI enorm! Allerdings wurden Hinweise, die für ein robustes System wichtig sind, wieder erst auf Nachfrage gegeben. Welcher VIBE Coder weiß denn die kritischen Fragen, bevor etwas zu Bruch gegangen ist?
## Die pragmatische Lösung: Physical Disk Passthrough
Nach diesen Erfahrungen überdenke ich die Storage-Strategie und reiche eine der beiden SSD einfach komplett in den Container für Immich durch. ChatGPT hatte verschiedene Ansätze vorgeschlagen – *VirtioFS, CIFS/NFS, eigener Storage Service*.
Für mich fehlten hier oftmals Hinweise, die für das Einsatzszenario wichtig waren und damit scheiterten einige Versuche in der Praxis. Manchmal waren es sofort offensichtliche Probleme, dass man z.B. die Zugriffsrechte kaum in den Griff bekam. In anderen Fällen hatte ich schlicht Sicherheitsbedenken, zu riskieren „Löcher vom Container zur Virtualisierung-Schicht zu bohren“. Hier bin ich im Chat mit der KI auch an meine Grenzen gestoßen, den richtigen Prompt zu formulieren, damit alle Kriterien berücksichtigt sind.
Immerhin hat die KI hier viel geholfen und geduldig Fragen beantwortet und Szenarien durchgespielt und immer wieder die Sicherheit unterschiedlicher Optionen bewertet – ich hoffe mal, dass ich nie erfahren werde, ob sie dabei richtig lag 😉
## Fazit: Erkenntnisse zum Vibe Engineering
Nach dieser Phase des Projekts zeichnet sich für mich folgendes Bild ab:
### Wo mich der Einsatz von KI überzeugt
**Parameter, Syntax und Optionen verstehen**
Die Erklärungen zu Details & Einstellungen sowie technische Trade-offs waren ausgesprochen hilfreich und sehr oft auch präzise. Generative KI ist ein ausgezeichneter Erklärbär für etablierte Technologien.
Dazu hat es mir auch sehr geholfen, die richtige Optionen inklusive korrekter Syntax von der KI zu erhalten. Dies hat mir einiges an Zeit erspart.
**Strukturierte Dialoge**
Das Durchspielen verschiedener Ansätze im Dialog – z.B. CIFS vs. NFS vs. VirtioFS – war wertvoll. Man kann Rückfragen stellen, Szenarien durchdenken und kann informierte Entscheidungen treffen.
**Schnelle Iteration**
Bei Problemen kann man Fehlermeldungen direkt an die KI geben und bekommt meist sinnvolle Lösungsansätze.
### Wo ich die Arbeit des Co-Piloten kritisch bewerte
#### **Fehlende Risikobewertung**
BTRFS wurde als „modernes Dateisystem mit tollen Features“ präsentiert, ohne auf die Einschränkungen bei parallelen Zugriffen hinzuweisen. Kritische Hinweise wurden nicht proaktiv gegeben.
#### Die Grenzen des Promptings: Wenn zu viele Anforderungen zusammenkommen
Eine Schwäche in der Arbeit mit einem LLM zeigte sich, wenn mehrere Anforderungen gleichzeitig erfüllt werden mussten: Beim Einbinden der Festplatten hatte ich zum Beispiel mehrere Ziele: Performance, Sicherheit/Isolation, Robustheit, Effizienz und noch mehr. ChatGPT berücksichtigte bei seinen Vorschlägen oft nur einen Teil der Wünsche.
**Das größere Problem:** Nachfragen half nicht. Bei jedem „Ja, aber was ist mit…?“ beginnt ChatGPT von vorne, berücksichtigte den neuen Aspekt, vergaß aber dafür andere.
**Die bessere Strategie:** Die KI für Teilaspekte nutzen (z.B. „Erkläre mir BTRFS-Einschränkungen“), aber die Gesamtlösung selbst zusammendenken. Nur werden dann die Chats sehr schlecht leserlich und man findet später kaum noch den roten Faden, warum man sich so entschieden hat.
#### **Bevorzugung „moderner“ bzw \*populärer\* Lösungen**
VirtioFS oder gar ein dedizierte Storage-Service – alles wurde als elegant präsentiert, ohne die praktische Komplexität ausreichend zu betonen. Die KI tendierte für mein Dafürhalten zu neueren Technologien. Ich vermute es sind eben die Themen, die auf reddit und Stackoverflow viel diskutiert werden. Und das macht die KI leider auch dann, wenn einfachere Ansätze besser passen.
#### **Fehlende Antizipation von Problemen**
Die KI erklärt gut den Standardablauf bzw. die Wege, die besonders oft im Netz zu finden sind. Sie liefert aber im Regelfall keine Antworten, wie sie ein erfahrener Administrator geben würde, der potenzielle Fallstricke proaktiv anspricht.
**Unabhängig von den sachlichen Themen**
Den Dialog zu den unterschiedlichen Themen führt ChatGPT angenehm und geschickt. Eine bisweilen geradezu euphorische Wortwahl und immer wieder plakatives Lob der KI: „*Sehr gute Überlegung – und du sprichst einen der wichtigsten Punkte an …*“ empfinde ich zunächst als sehr angenehm und sogar motivierend.
Irgendwann fällt es dann doch auf 🙂 und mittlerweile schätze ich mehr die Sprachassistenten, die diese unterschwellige Beeinflussung zumindest weniger deutlich zeigen.
## Wie geht es weiter?
Im nächsten Teil geht es vermutlich um echtes Vibe Coding. In der Tat habe ich auch eine Flask Web-App mit ChatGPT programmiert, mit der ich vom Handy aus die Container einfach mit einem Klick starten und stoppen kann…
---
**Weitere Ressourcen:**
- [Teil 1: Hardware-Auswahl und Aufbau](https://thecattlecrew.net/2025/10/20/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen/)
- Teil 3: Docker, Immich und Backup-Strategien (coming soon)
**Kategorien:** AI & Data Science, Infrastructure
---
### [Vibe Coding – Teil 1: Mit KI zum eigenen Homeserver](https://thecattlecrew.net/2025/10/20/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen/)
**Published:** Oktober 20, 2025
**Author:** Andreas Lorenz
**Content:**
Wir leben in einer Zeit, in der die Nutzung von KI-Tools alltäglich geworden ist – beruflich wie privat. Doch während viele der KI blind vertrauen und andere ihr grundsätzlich misstrauen, stelle ich mir die Frage nach der Mitte: **Wie nutze ich KI als Sparringspartner, ohne die Kontrolle über mein Handeln zu verlieren?**
## Was ist Vibe Coding?
Vibe Coding beschreibt eine neue Form der Zusammenarbeit zwischen Mensch und Künstlicher Intelligenz – ursprünglich beim Programmieren, zunehmend aber auch in anderen Entwicklungs-Bereichen, hier Hardware- und Infrastruktur. KI agiert dabei als Projektpartner, der Entwürfe analysiert, Lösungen vorschlägt und Entwicklungsprozesse beschleunigt.
## Die Motivation für diesen Artikel?
In diesem Artikel möchte ich meine Erfahrungen teilen, wie ich **privat** technische Projekte zusammen mit der KI umsetze. Am Beispiel meines Homeserver-Projekts zeige ich, wo die KI mich in der Praxis sinnvoll unterstützt hat und welche Herausforderungen es gab. Die Erfahrungen waren auch ganz unterschiedlich, je nachdem welche Aufgabe anstand:
- Der Hardwareaufbau
- Die Installation und Konfiguration des Betriebssystems
- Das Aufsetzen der Apps auf dem Homeserver
- Entwicklung eines Admin UIs als pures Vibe Coding
- Konfiguration des OpenWRT Routers
## Das Projekt – Homeservers aufsetzen mit KI
Seit Jahren beschäftige ich mich mit dem Thema souveräne IT (siehe auch die [Blogserie Datensouveränität](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)) – Wenn ich meine Daten kontrollieren will, muss ich verstehen, wo sie liegen und wie sie verarbeitet werden. Diverse Synology-, QNAP- und Terramaster-NAS-Systeme haben mir über die Jahre gute Dienste geleistet. Da ich einen langjährigen Background im Bereich Linux-Server habe und mich auch im Bereich Docker wohl fühle, will ich jetzt einen Schritt weitergehen und starte das Projekt zusammen mit meinem Sohn (E-Technik Student) und mit ChatGPT als „Co-Pilot“.
leiser, sparsamer Server @Home
**Das Ziel:** Ein eigener Linux-Server, der u.a. Dienste wie Nextcloud, Collabora, Immich und OpenProject als Container für mich und die Familie bereitstellt. Der Betrieb ist dann bei mir zu Hause und somit entfallen Cloud-Abhängigkeiten, monatlichen Abos und die Frage, wer meine Fotos scannt und Dokumente indiziert. Zu Hause bedeutet aber auch, dass er sehr leise, sparsam und optisch unauffällig sein muss! Und Leistung darf trotzdem nicht zu kurz kommen, damit Webseiten auch bei Lastspitzen schnell geladen werden. Seine Vorgänger waren entweder zu schwach oder zu laut, sozusagen „teuer erkaufte Erfahrung“. Diesmal soll es direkt passen, ohne Fehleinkäufe 🙂
## Hardware-Auswahl – KI als Recherche-Turbo
Bei der Auswahl der richtigen Hardware hilft ChatGPT sehr und vergleicht u.a. CPU-Leistungen, Stromverbräuche und wichtige technische Parameter – zunächst von fertigen Lösungen, darunter sowohl PCs als auch NAS Systeme und später auch für Bausätze. Das Ganze ist weit ab von einfach, alleine aus Asien kommen mittlerweile so viele hübsche, kleine Kraftprotze in die Webstores von Amazon und Co, da muss man schon auf die Details achten, damit der Frust nicht direkt nach dem Kauf beginnt.
Dazu recherchiert die KI für mich auch Erfahrungsberichte zu technischen Problemen und zur Kompatibilität mit Linux. Nach demselben Muster werden ein Switch mit VLAN-Support & 2,5-GBit/s-Ports sowie die SSD ausgesucht.
ChatGPT SSD Vergleich
Ich hatte das Gefühl, dass mir die Zuarbeit der KI hier sehr viel Zeit erspart hat. Allerdings hilft es hier auch enorm, der KI **genau** zu sagen, was einem wichtig ist. Und selbst dann, wenn ich mal nicht alles im Blick hatte, kamen wertvolle Tipps: Es hilft gelegentlich offene Fragen zu stellen: „*Vergleiche mir einmal SSD A mit SSD B, was sind die Vorteile und Nachteile*„. Erst so kam ich z.B. auf das Detail DRAM Cache, dass für die Langlebigkeit von SSDs nicht unwichtig ist.
> Die Rolle der KI ?
> Es war ausgesprochen hilfreich, eine enorme Anzahl an Infos innerhalb kürzester Zeit sortiert und aufbereitet auf dem Monitor zu haben und die Suche nach Hardware basierend auf unseren Wünschen einzugrenzen.
>
> Besonders gut gefiel uns, dass es auch sehr viele praxisnahe Tipps gibt. Zum Beispiel das Thema DRAM-Cache bei SSDs hatte ich so gar nicht auf dem Schirm.
Die Entscheidung: Bauvorschlag als Basis
Wir entschieden uns final für eine vollständige Selbstbau-Lösung, gehen aber auf Nummer sicher: Die Wahl fiel auf einen Bauvorschlag aus der c’t (*Sonderheft Dez 2024*) – solide durchdacht und von der Redaktion erprobt.
Beim Hardwareaufbau ist der c’t-Fachartikel und ein Video aus dem Verlag eine große Hilfe. Wenn noch Infos fehlen, dann fragen wir die KI und bekommen ebenfalls Tipps, die sich aber auch genauso gut googlen lassen.
## Realitätscheck: Grenzen der KI beim Einkauf
Beim Einkauf bzw. Bestellen der Einzelteile sind es dann doch Google und Preissuchmaschinen, die helfen, alle Bauteile auch zu bekommen. Die Ergebnisse und Preise, die uns ChatGPT zu dieser Zeit anzeigt, können wir oft nicht nachvollziehen zumal wir auch nicht alle Teile einzeln sondern bei möglichst wenig unterschiedlichen Anbietern bestellen wollten. Ich denke, heute, etwa ein halbes Jahr später, kann das schon wieder ganz anders aussehen.
> Die Rolle der KI ?
> Bei zeitkritischen Daten wie Preisen und Verfügbarkeit muss(te) wir noch gegenchecken. Die KI war für uns noch kein Ersatz für eine aktuelle Marktrecherche.
## Mission accomplished
Final hat alles sehr gut geklappt: Mein Sohn und ich haben gemeinsam geschraubt, verkabelt und das System zum ersten Mal gebootet, dazu dann aber mehr im nächsten Artikel 😉 Der Server erfüllt bis heute zu 100% seinen Zweck: ist absolut leise, klein mit cleanem Design und wenn mal ein Service richtig Leistung braucht, dann ist auch das kein Thema. Bis dahin war es dann aber doch noch ein netter Weg an Herausforderungen, bei der die KI dann noch deutlich mehr unterstützen durfte.
---
**Lest gerne im nächsten Artikel**, wie es bei der [Auswahl und Installation des Betriebssystems und dem Aufsetzen des Servers](https://thecattlecrew.net/2025/11/08/vibe-coding-in-aktion-einen-homeserver-mit-ki-aufsetzen-teil-2/) weitergeht…
**Kategorien:** AI & Data Science, Infrastructure
---
### [Deine Stakeholder sollen sich gefälligst entscheiden!](https://thecattlecrew.net/2025/11/04/deine-stakeholder-sollen-sich-gefaelligst-entscheiden/)
**Published:** November 4, 2025
**Author:** Stefan Sonner
**Content:**
Alle, die IT-Projekte leiten, kommen im Laufe ihrer Ausbildung und Berufspraxis irgendwann an die Stelle, wo sie lernen, dass klare Verantwortlichkeiten und definierte Entscheidungskompetenzen dem Projekterfolg zuträglich, ja fast unabdingbar, sind.
Was aber, wenn genau das fehlt? Wenn du dich in einem Projekt befindest, in dem eine Handvoll Stakeholder mitreden und jede der Parteien so ein bisschen was entscheiden darf?
Wenn dich das interessiert, dann lies gerne weiter. Ich möchte euch gerne von meinen Erfahrungen zu genau diesem Aspekt berichten. Dafür betrachten wir ein rein fiktives Beispiel. Es mag übertrieben wirken. Ist es tatsächlich aber nicht. Ich spreche dabei definitiv nicht über die Mehrzahl der Projekte, das möchte ich an dieser Stelle betonen. Doch das, was ich gleich schildere, habe ich persönlich erlebt.
## Die wichtigsten Stakeholder
Zunächst muss ich euch die wichtigsten Stakeholder vorstellen:
- Der Fachbereich: Inhaltlicher Owner, darf Featurewünsche äußern und hat Mitspracherecht bei der Priorisierung.
- Die IT, Abteilung Softwareentwicklung: Hat die finanzielle Verantwortung und Mitspracherecht, was inhaltlich gemacht wird. Hat außerdem technische Anforderungen, die mit den fachlichen Features hinsichtlich Entwicklerkapazität konkurrieren.
- Das IT-Controlling: Kontrollorgan für die IT und den Fachbereich hinsichtlich Verwendung finanzieller Mittel sowie umzusetzender Inhalte. Hat außerdem ausgeprägtes Mitspracherecht in allen Bereichen, also auch fachlich und technisch. Hat organisatorische Anforderungen, z. B. bezüglich der Revisionssicherheit, und bestimmt, wann das Projekt zu enden hat.
- Die Fachbereichsleitung: Eskalationsinstanz des Fachbereichs, ihre Priorisierung ist teilweise abweichend von den Priorisierungsvorstellungen der Sachbearbeiter.
- Die Leitungsposition der IT/Softwareentwicklung: Zu Beginn der Geschichte unbesetzt. Wird später noch spannend.
## Erste Maßnahmen: Diskussion über Entscheidungswege
Vier Monate nachdem ich das Projekt übernahm, lud ich die genannten Stakeholder zur Besprechung von zwei Kernthemen ein: Eines davon war „Entscheidungen im Projekt“.
In zwei, drei Folien habe ich den Teilnehmern erklärt, warum klare Entscheidungswege so wichtig sind und dass ich wahrnehme, dass hier im Projekt genau das Gegenteil der Fall ist: Keine Klarheit, niemand, der „den Hut aufhat“, jeder zwar ein bisschen, aber keine finale Instanz, die bei konkurrierenden Haltungen ein Machtwort sprechen kann.
Meine nächste Folie beschrieb ein paar Lösungsvorschläge, um die Diskussion anzukurbeln und die Teilnehmer ins Reden und ins „Miteinander“ zu bringen: z. B. den Fachbereich mit einem Storypoint-Budget und mehr Entscheidungsbefugnis auszustatten, den Entscheidungsweg prozessual abzubilden oder den Kreis der Entscheider in einen Refinement-/Replenishment-Zyklus einzubinden.
Das Feedback war allerdings ernüchternd. Genau genommen gab es gar kein Feedback dazu. Es wurde geschwiegen.
## Ein überladener Backlog und neue Herausforderungen
Ganz ehrlich, das hatte ich mir anders vorgestellt. Aber machen wir erstmal weiter. Unser größtes Problem im Projekt war, dass der Backlog eine gigantische Größe hatte, aber das Projektende bereits optimistisch festgesetzt war. Wir mussten also einen Weg finden, zu entscheiden, was noch umgesetzt werden soll und was nicht.
Irgendwie haben wir dann in einer ersten Runde den Backlog etwas verkleinern und das Projekt restrukturieren können. Es blieb aber die Frage offen, was das Entwicklerteam als Nächstes umsetzen soll. Und, ob das Feature „X“ überhaupt noch seine Berechtigung hat und umgesetzt werden soll. Zudem wurden seit meiner Projektübernahme weitere notwendige Features identifiziert, die bis dato noch nicht als Feature/Story erfasst waren.
## Mein Vorschlag: Sprints als Ausweg
Die Meinungen gingen nun stark auseinander. Was hat Prio? Fachliches Feature A vs. Features zugunsten der Revisionssicherheit vs. Fachliches Feature B vs. notwendige technische Features vs. X …
5 Stakeholder mit je 2–3 Meinungen. Ihr bekommt sicher gerade ein Gefühl für die Situation.
Was tun? Mein Vorschlag war der folgende:
- Wir führen Sprints ein.
- Der Fachbereich erarbeitet zusammen mit mir jeweils einen Sprintvorschlag.
- Alle Stakeholder segnen den nächsten Sprint im Rahmen des wöchentlichen Jour-Fixe ab.
- Damit alle Themen adressiert sind, erfolgt ein Mapping der scheinbar möglichen Stories auf die Sprints von jetzt bis Projektende (durch Fachbereich und mich).
Ich war positiv überrascht, aber der Vorschlag wurde einstimmig angenommen.
## Rückschlag: Priorisierung im Dauerwechsel
Die Enttäuschung erfolgte eine Woche später!
Im nächsten Jour-Fixe entfachte wieder die Diskussion über die Prioritäten. Die IT-Steuerung spielte den Präsidenten-Joker und der Priorisierungsslalom begann … in den nächsten 6 Wochen wechselte unsere Prio von links nach rechts und wieder zurück – je nachdem, welcher Teilnehmerkreis gerade im Jour-Fixe anwesend war. Weitere Prio-Veränderungen erreichten das Projektteam per E-Mail. Mal aus der einen, mal aus der anderen Stakeholder-Ecke.
## Notlösungen aus dem PM-Werkzeugköfferchen
Ich kramte in meinem Projektmanagement-Werkzeugköfferchen: Was war da noch so drin?
- Entscheidungen im **Jour-Fixe-Protokoll** schriftlich fixieren? Ja, das geschah sowieso und regelmäßig. Half aber nicht! Entscheidungen wurden revidiert und überschrieben.
- Ich führte **Einzelgespräche** mit den Stakeholdern, um jeden Einzelnen zur Situation abzuholen und deutlich zu machen, dass weitere Prio-Wechsel das Projekt stark verzögern.
- **Arbeitshypothesen**? In anderen Projekten bei diesem Kunden hatte es sich bewährt, bei offenen Fragen mit Arbeitshypothesen zu arbeiten. Also mit der am wahrscheinlichsten eintretenden Option weiterzumachen. Doch in diesem Projekt waren von mir formulierte Hypothesen nach nur wenigen Tagen nichts mehr wert.
## Der Wendepunkt: Neue Leitung übernimmt
So langsam war ich mit meinem Latein am Ende. Aber inzwischen war die Leitungsposition von IT/Softwareentwicklung wieder besetzt, und nach kurzer Einarbeitungszeit war mein Projekt stark im Fokus der neuen Leitung – glücklicherweise. Ich konnte meine Sicht der Dinge nun mit der frischen Führungskraft besprechen, fehlende Entscheidungskompetenzen aufzeigen und notwendige Dringlichkeit herstellen.
Die neue Leitung holte alle Beteiligten an den (virtuellen) runden Tisch und traf zwei Entscheidungen:
- Klare inhaltliche Fokussierung bis Projektende.
- Klare Absichtserklärung, das derzeitige Projektteam über das Projektende hinaus an den weiteren Themen arbeiten zu lassen.
Insbesondere die zweite Entscheidung führte nach meiner Wahrnehmung dazu, dass die Stakeholder entspannter waren und in das Projekt eine gewisse Ruhe einkehrte. Die Zuversicht, dass man „seine“ Themen irgendwann in die Umsetzung bekommt, stieg. Die „Torschlusspanik“ nahm ab und dadurch entstandene Handlungsmuster reduzierten sich.
## Fazit und offene Fragen an euch
Rückblickend würde ich mir an die eigene Nase fassen und sagen: Nachdem ich gemerkt habe, dass ich im bestehenden Projektteam niemanden finde, der ein finaler Entscheider sein kann, hätte ich außerhalb weitersuchen müssen. Ich habe möglicherweise zu viel Energie in das Ziel gesteckt, die Stakeholder zu entschlüsseln.
Welches Fazit würdet ihr ziehen? Was hättet ihr anders gemacht? Oder wie wärt ihr mit der Situation umgegangen? Schreibt das gerne in die Kommentare.
## Ausblick
In meinem nächsten Artikel geht es um *10 (scheinbare) Selbstverständlichkeiten im Projektmanagement*. Es bleibt also interessant und die Diskussion darf weitergehen. Seid gerne wieder dabei.
**Kategorien:** Development, Tools & Methoden
---
### [Schuld und SYNE – Alte Sünden in der IT-Sicherheit und wie wir sie überwinden](https://thecattlecrew.net/2025/10/28/schuld-und-syne-alte-suenden-in-der-it-sicherheit-und-wie-wir-sie-ueberwinden/)
**Published:** Oktober 28, 2025
**Author:** Torsten Jaeschke
**Content:**
Am 17. September 2025 habe ich auf der Digital Xchange 2025 in Gummersbach meinen Vortrag „Schuld und SYNE“ gehalten. Darin habe ich gezeigt, wie sich alte Sünden in der IT-Sicherheit – technische Schulden in der System- und Netzwerksicherheit – über Jahre aufbauen und welche psychologischen Mechanismen dafür sorgen, dass sie bestehen bleiben.
Der Titel „Schuld und SYNE“ hat übrigens einen doppelten Hintergrund: In unserer Firma wird die Richtlinie zur System- und Netzwerksicherheit mit SYNE abgekürzt – diese Abkürzung inspirierte mich zu dem Titel, der bewusst an Dostojewskis Schuld und Sühne erinnert.
Das Echo des Publikums hat mir gezeigt: Wir alle kennen diese Probleme aus der Praxis. Schauen wir gemeinsam noch einmal genauer hin.
## Alte Sünden in der IT-Sicherheit
*Alles Vergangene war nicht vergangen, es lastete.*
Wir stoßen in Audits und Architekturreviews regelmäßig auf dieselben Muster: zu weitgehende Benutzerrechte, fehlende Trennung zwischen Domänen und administrativen Konten, gewachsene Strukturen ohne klare Sicherheitsarchitektur. Meist waren diese Entscheidungen nicht böswillig, sondern das Ergebnis von Zeitdruck und pragmatischen Lösungen. Doch was einst schnelle Ergebnisse versprach, wird heute zum Risiko.
Genau diese Ambivalenz beschreibt Dostojewski in Schuld und Sühne: Raskolnikow begeht eine Tat, die er sich als „erlaubt“ rationalisiert. Organisationen tun Ähnliches, wenn sie Ausnahmen und Quickfixes rechtfertigen.
## Technische Schulden sind auch psychologische Schulden
*Wenn ich es für Recht halte, dann war es Recht.*
Technische Schulden sind mehr als alte Software. Sie sind ein Geflecht aus gewachsenen Strukturen, veralteten Verfahren und fehlender Dokumentation. Niemand fühlt sich mehr verantwortlich.
In der Trauerarbeit spricht Chris Paul von „vagabundierender Schuld“ – Schuld, die keinen klaren Ort oder Adressaten hat. Genau das passiert auch in IT-Organisationen: Konten, Policies, Systeme hängen in der Luft, ohne klaren Owner. Das Ergebnis: Innovation wird blockiert, Kosten steigen und die Angriffsfläche wächst.
Die Psychologie liefert dafür Erklärungen. Leon Festinger beschrieb schon 1957 die „kognitive Dissonanz“: Wir wissen, dass etwas nicht stimmt, verdrängen es aber, weil Handeln unangenehm wäre. Neurowissenschaftliche Studien von McClure et al. zeigen, dass unser Gehirn kurzfristige Belohnungen – etwa ein erfolgreiches Release – stärker honoriert als langfristige Sicherheit. Kahneman erinnert uns daran, wie oft wir im „schnellen Denken“ bleiben und uns mit Ausreden beruhigen.
Chris Paul ergänzt: Schuld kann normativ sein (Verstoß gegen Regeln), instrumentell (Schuldzuweisung als Druckmittel) oder vagabundierend (niemand fühlt sich verantwortlich). Diese Mechanismen wirken auch in Unternehmen – und sie erklären, warum technische Schulden bleiben.
## Das Katz-und-Maus-Spiel vor Audits
*Verbergen, immer verbergen das war sein Schicksal.*
Wir kennen alle die Symptome: kurzfristig Ports schließen, Policies temporär ändern, Dokumentation kosmetisch aufbereiten. Statt Probleme zu lösen, werden sie geschminkt.
Wie Raskolnikow, der lügt und verschweigt, geraten Organisationen in ein Katz-und-Maus-Spiel: Verbergen statt Eingestehen. Doch Audit-Kosmetik beseitigt nicht das Problem, sie stabilisiert es.
## Die tickende Zeitbombe
*Nicht die Schuld ist tödlich, sondern das Schweigen darüber.*
Das Verdrängen funktioniert nicht ewig. Mit jeder weiteren Lücke wächst die Gefahr. Kumulative Risiken – von DSGVO-Verstößen über erhöhte Angriffsflächen bis zu Reputationsschäden – und dauerhafte Alarmbereitschaft führen zu Stress und Burnout im Team.
Chris Paul formuliert es treffend: „Unbearbeitete Schuld kann zerstörerisch wirken – nicht, weil sie existiert, sondern weil sie nicht ausgesprochen wird.“
## Wege aus der Schuldenfalle
*Im Bekenntnis liegt die Erlösung.*
Der erste Schritt ist das Eingeständnis: Ja, wir haben Schulden. Genau wie Raskolnikows Geständnis ist es ein Wendepunkt. Dann gilt es, systematisch zu handeln:
- **Technisch:** Rechte- und Rollenkonzepte (RBAC/ABAC) implementieren, administrative Ebenen trennen, Legacy-Komponenten priorisiert migrieren.
- **Organisational:** Schuldenregister führen wie einen Bugtracker, Verantwortlichkeiten klar zuordnen, eine Kultur schaffen, in der man Schwächen offen ansprechen darf.
Ergänzend gilt: Schuld verliert ihre zerstörerische Macht, wenn sie Sprache bekommt. Wir brauchen Räume ohne Strafe, in denen technische Schulden offen benannt werden können. Transparenz und Struktur sind der Weg zur Sühne.
## Von Schuld zur SYNE
*Das Eingeständnis von Schuld ist nicht Schwäche,
sondern der Anfang von Stärke.*
Schuld ist nicht Stillstand, sondern Ausgangspunkt. Wer sie anerkennt, kann Veränderung gestalten. Unternehmen, die hinschauen, gestalten eine sichere Zukunft – für sich und ihre Kunden.
## Fazit
Technische Schulden sind kein rein technisches Problem, sondern Spiegel menschlicher Muster: Wir verdrängen, rechtfertigen und verschieben. Doch wer Schuld anerkennt, schafft die Grundlage für Veränderung. Mit Transparenz, klaren Verantwortlichkeiten und dem Mut, Schwächen offen anzusprechen, werden alte Sünden zum Ausgangspunkt für mehr Sicherheit und Stärke.
Von Schuld zur SYNE bedeutet: hinsehen, Verantwortung übernehmen und IT-Sicherheit als lebendigen Prozess begreifen – zum Schutz von Unternehmen, Mitarbeitenden und Kunden.
## Quellen
- Dostojewski, F. (1866). Schuld und Sühne
- Festinger, L. (1957). A Theory of Cognitive Dissonance
- McClure, S. M. et al. (2004). Science, 306(5695)
- Kahneman, D. (2011). Thinking, Fast and Slow
- Sapolsky, R. M. (2004). Why Zebras Don’t Get Ulcers
- Paul, C. (2014). Schuld – Macht – Sinn
**Kategorien:** IT-Security, Sustainability & Awareness
---
### [KI im Kundeneinsatz: Ein Reality Check der Pyramid-Funktionalität](https://thecattlecrew.net/2025/10/14/ki-im-kundeneinsatz-ein-reality-check-der-pyramid-funktionalitaet/)
**Published:** Oktober 14, 2025
**Author:** Janine Ellner
**Content:**
Generative KI gilt aktuell als das neue Must-have – kaum eine moderne Analytics-Plattform verzichtet noch auf die Integration von Large Language Models (LLMs). Auch Pyramid bewirbt sich als Gamechanger: Wer Daten in natürlicher Sprache abfragt, soll ohne Umwege zu Tabellen, Visualisierungen oder Prognosen gelangen.
Doch wie so oft im echten Leben ist der Weg von der Vision zur Praxis steinig. Für einen Kunden haben wir die GenAI-Integration in Pyramid getestet. Das Ergebnis ist gemischt: KI kann tatsächlich unterstützen. Allerdings nur dann, wenn man einige Voraussetzungen schafft – sowohl auf technischer als auch auf organisatorischer Ebene – und typische Stolperfallen kennt.
## Erwartungen an GenAI in Pyramid
Die Vorstellung ist verlockend: Statt SQL-Abfragen zu schreiben, reicht eine einfache Frage wie *„Zeig mir die Umsätze der letzten sechs Monate“*. Pyramid übersetzt das Anliegen automatisch in eine Abfrage und liefert die passenden Ergebnisse.
Gerade für Fachbereiche eröffnet das einen niedrigschwelligen Zugang zu Daten. Sie können selbst explorieren, ohne auf die Unterstützung der IT angewiesen zu sein. Für BI- und Analytics-Experten wiederum bedeutet das mehr Freiraum für komplexere Aufgaben.
Die Realität zeigt jedoch: Dieses Versprechen erfüllt sich nur, wenn Modell, Organisation und Anwender vorbereitet sind.
## Modellstruktur – das Fundament der Ergebnisse
Im Test wurde schnell klar, dass die Qualität des Datenmodells über die Qualität der Antworten entscheidet. Ein zu großes, unübersichtliches Modell produziert nicht nur schwer nachvollziehbare Ergebnisse, sondern treibt auch die Kosten in die Höhe. Denn jede natürlichsprachliche Anfrage wird vom LLM in eine technische Abfrage übersetzt. Informationen zum *„Verhalten“* des LLMs, Modelldefinition und Anfrage des Anwenders werden an das LLM gesendet. Dieses liefert eine technische Definition des Outputs zurück. Dabei werden sogenannte Tokens verbraucht, die je nach Modellgröße stark variieren. Ein Token umfasst hierbei bis zu 4-5 Buchstaben, also kurze Wörter oder Wortteile. In einem Fall erzeugte ein Modell mit über 1.000 Objekten bis zu 150.000 Tokens pro Anfrage – in längeren Dialogen summiert sich das schnell.
Wer Pyramid mit GenAI einsetzt, sollte deshalb Modelle möglichst schlank halten, klare und sprechende Feldnamen verwenden und kurze, präzise Beschreibungen ergänzen.
So versteht nicht nur das LLM besser, worum es geht – auch die Anwender finden sich leichter zurecht.
## Prompting – ohne Übung kein Gewinn
Die zweite große Stellschraube ist das Prompting. Pyramid erlaubt sowohl einfache als auch komplexe Fragestellungen. Aber: Je genauer die Formulierung, desto hilfreicher das Ergebnis.
Während eine Standardfrage wie *„Zeig mir die Umsätze“* meist problemlos funktioniert, erfordert eine komplexe Anweisung (*„Erstelle eine Prognose der nächsten drei Monate und visualisiere sie als Liniendiagramm“*) ein gewisses Verständnis dafür, wie man mit dem System kommuniziert.
Das bedeutet: Unternehmen sollten ihre Anwender schulen. Nur wer weiß, wie man gute Prompts formuliert, schöpft das volle Potenzial aus.
## Sicherheit und Datenschutz
Ein weiteres wichtiges Thema ist die sichere Anbindung der LLMs. Pyramid erlaubt die Integration externer Anbieter wie OpenAI. Wer hier unvorsichtig agiert, läuft jedoch Gefahr, dass API-Keys in falsche Hände geraten. Ein geleakter Key ermöglicht Zugriff auf das gesamte Konto – inklusive Abrechnungsdaten.
Sicherer ist der Betrieb über Azure AI. Damit lassen sich Modelle in europäischen Datenzonen hosten, Endpunkte absichern und Zugriffe kontrollieren. Einschränkungen gibt es aber auch hier: Einige Funktionen wie Bildgenerierung oder Entra-ID-Authentifizierung sind noch nicht verfügbar.
## Technische Grenzen der aktuellen Implementierung
So tief die Integration in die Oberfläche wirkt – sie bleibt aktuell auf die Modellebene beschränkt. Dashboards oder gespeicherte Objekte lassen sich nicht per KI öffnen oder steuern. Auch ein plattformweiter Chatbot, der Anwender durch alle Module führt, ist noch Zukunftsmusik.
In der Praxis bedeutet das: LLMs agieren derzeit vor allem als intelligente Assistenten, nicht als umfassende Copiloten. Sie erleichtern die Arbeit innerhalb eines klar definierten Rahmens, ersetzen aber keine End-to-End-Steuerung.
## Fazit: Viel Potenzial, aber kein Selbstläufer
Die Integration von GenAI in Pyramid kann echte Mehrwerte schaffen – aber ohne schlanke Modelle, ohne durchdachtes Sicherheitskonzept und ohne geschulte Anwender bleiben die Ergebnisse oft hinter den Erwartungen zurück.
Wer die Einführung strategisch plant, Pilotprojekte aufsetzt und die organisatorischen Rahmenbedingungen berücksichtigt, kann jedoch profitieren: Datenanalysen werden zugänglicher, schneller und für mehr Nutzergruppen verständlich.
### **Sie möchten herausfinden, wie GenAI Ihre BI- und Analytics-Prozesse unterstützen kann?**
Sprechen Sie mich an – Wir begleiten Sie von der ersten Pilotierung bis zum sicheren, produktiven Einsatz. Vereinbaren Sie jetzt einen Beratungstermin oder fordern Sie eine individuelle Demo an.
**Kategorien:** AI & Data Science, Analytics & Insights
---
### [Anforderungsmanagement in IT-Projekten – Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Published:** Oktober 7, 2025
**Author:** Tim Teulings
**Content:**
Nach sechs Gesprächen zwischen **Architekt Adam (AM)** und **Anforderungsmanager Manfred (AM)** ist es Zeit, Bilanz zu ziehen. Auch wenn diese Dialoge fiktiv sind, spiegeln sie doch reale Herausforderungen aus Projekten im öffentlichen Sektor wider – und liefern konkrete Denkanstöße für ein effizienteres Anforderungsmanagement.
## Die Quadratur des Kreises
… soviel zu Adam und Manfred. Diese Gespräche haben nie so stattgefunden. Aber die Probleme, die Architekt Adam hat, sind aus unserer Sicht typisch. Nicht nur typisch für die Rolle von Architekt:innen sondern wir sind überzeugt, dass es ein entsprechendes Gespräch unter den Verantwortlichen auch auf der Kundenseite geben könnte. By the way: Auch dieser Blickwinkel wäre eine eigene Blogserie wert … aber das wäre ein anderes Thema.
Die Situation des Architekten Adam in einem Projekt bei einer öffentlichen Institution ist charakteristisch, auch für andere Branchen. Dafür gibt es eine ganze Reihe von Gründen. Doch es gibt Wege aus dem Labyrinth, aus der Quadratur des Kreises: Oder sagen wir lieber: Es gibt Alternativen. Und nein, wir werden im Folgenden nicht die nächste Revolution ausrufen oder intensiv über KI reden. Stattdessen wollen wir auf relativ einfache Anpassungen hinweisen, die zu einem erheblich besseren Ergebnis für alle Beteiligten führen könnten.
Wie das gehen kann, darum geht es in dieser Zusammenfassung im letzten Teil der Serie. Dafür sehen wir uns die Erkenntnisse der simulierten Diskussion unserer Protagonisten der letzten Wochen genauer an. Wer hier auf operative Fragen hofft, wie: „Was ist in einem Kick-off-Termin zu beachten?“, den müssen wir leider enttäuschen. Uns interessiert heute das Große und Ganze.
## Das Glaubenssystem hinter dem klassischen Ansatz
Das initiale Ziel der Anforderungsanalyse im diskutierten Projekt-Setup war eine möglichst detaillierte Spezifikation zu schreiben. Diese wiederum bildete den Kern einer Ausschreibung bzgl. der Umsetzung der Anforderungen als Gewerk zum Festpreis. Dahinter steht oft die Annahme: „Je detaillierter die Spezifikation, desto geringer das Umsetzungsrisiko.“ Und das bedeutet häufig, wenn man mit Fachexperten spricht, eine zu starke Betonung der Fachanforderungen. Fachanforderungen sind aber aus Sicht der Architektur nur einer von vielen Bereichen, die betrachtet werden müssen.
Im Rahmen der Risikoübertragung ins Gewerk wird angenommen, dass im Ergebnis damit das magische Dreieck aus Umfang, Kosten, Zeit fixiert ist. Doch die Praxis zeigt: Risiken treten fast immer ein – und dann bleibt oft nur die Qualität als Stellschraube. Damit riskieren Auftraggeber und Auftragnehmer gleichermaßen wirtschaftliche oder qualitative Einbußen.
## Typische Probleme in der Praxis
- Spezifikation unvollständig oder unpräzise
- Änderungen der Anforderungen zwischen Analyse und Umsetzung
- Implizite Annahmen nicht explizit gemacht
- Neue Erkenntnisse beim Kunden während der Umsetzung
- Kalkulation zu ungenau, realer Aufwand deutlich höher
Diese Mängel sind seit Langem bekannt. Agile Methoden versuchen, sie durch kleinere, interaktive Iterationen abzufedern. Doch im öffentlichen Sektor sind agile Projekte oft nur eingeschränkt möglich – sei es aus rechtlichen, organisatorischen oder budgetären Gründen.
## Ein alternativer Weg: Zielorientierte Analyse
Ein Ausweg kann sein, die Anforderungsanalyse zu verkürzen und sich auf das zu konzentrieren, was für eine belastbare Kalkulation wirklich entscheidend ist. Statt maximaler Detailtiefe geht es um das klare Umreißen von Anforderungen und eine wertorientierte Budgetierung.
Das bedeutet:
- Fokus auf architekturrelevante Aufwandstreiber. Architekturtreiber sind auch unter dem Namen -ilities bekannt (Functionality, Maintainability, Usability, Interoperability, …).
- Grundsätzliche Aussagen zu Schnittstellen, Prozessen, UI
- Berücksichtigung typischer Querschnittsfunktionalitäten
- Klärung wesentlicher Aspekte zum Betrieb
Detailliert wird nur dort, wo es Kosten und Risiken maßgeblich beeinflusst.
## Was braucht es?
Wir glauben: Die „Quadratur des Kreises“ ist möglich. Mit mehr Zielorientierung und angepassten Analyse- und Moderationstechniken kann die Zeit für die Anforderungsanalyse deutlich verkürzt werden – ohne zusätzliche Risiken in der Umsetzung.
Das erfordert:
- Den Willen des Kunden, Perfektion gegen klare, risikoarme Anforderungen zu tauschen
- Die Bereitschaft, früh konzeptionelle Entscheidungen zu treffen
- Ein Beraterteam, das konsequent auf dieses Ziel hinarbeitet und die passenden Methoden einsetzt
## Fazit: Mehr Fokus, weniger Ballast
Mit einem schlankeren, aber zielgerichteten Analyseansatz gewinnen Auftraggeber und Auftragnehmer.
**Die drei wichtigsten Vorteile:**
- Weniger Overhead in der Analyse
- Bessere Planbarkeit
- Mehr Freiraum für agile, kreative Umsetzung
So wird Anforderungsmanagement im Festpreisprojekt nicht zur Fleißarbeit, sondern zu einem echten Erfolgsfaktor – und die Quadratur des Kreises ein Stück greifbarer.
---
## Dein Feedback ist gefragt!
Wie hat dir unsere Serie zum Anforderungsmanagement im Public-Sektor gefallen?
Hast du eigene Erfahrungen, Ideen oder Beispiele, die du teilen möchtest?
Dann freuen wir uns sehr über deine **Gedanken und Kommentare** – lass uns wissen, welche Aspekte dich besonders beschäftigt haben und wo du vielleicht noch tiefer einsteigen möchtest.
---
## Alle Teile der Serie ansehen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Anforderungsmanagement in IT-Projekten – Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
**Published:** September 25, 2025
**Author:** Tim Teulings
**Content:**
Wie stellt man sicher, dass Analyse, Ausschreibung und Umsetzung eines Projekts wirklich aufeinander abgestimmt sind? In Teil 6 unserer Gesprächsreihe mit **Architekt Adam (ARCH)** und **Anforderungsmanager Manfred (AM)** geht es um die wohl wichtigste strategische Frage im Anforderungsmanagement: Welche Inhalte gehören in die initiale Analyse – und was sollte besser erst im Umsetzungsprojekt geklärt werden?
## Sechstes Treffen: Zwischen Fußball und Fazit
**Ort des Geschehens:** Das Pokalfinale der Kinder – und ein letztes Gespräch vor der Abgabe.
**ARCH:** Hi Manfred, dein Kleiner scheint ja richtig fit fürs Pokalfinale zu sein. Hast du ihm Kaffee gegeben oder warum ist der so energiegeladen?
**AM:** Schön dich zu sehen Adam! Du weißt doch, es ist wie bei jedem Projekt. Gute Vorbereitung ist das A und O! Und beim Sport gehört dazu halt eine ordentliche Portion Spaghetti Bolo 90 min bevor es ernst wird. Apropos Projekt: Wie läuft dein Lastenheft. Habt ihr nicht morgen Abgabe? Da hast du Zeit für deine Kids?
**ARCH:** Ja, es fällt echt schwer, mich auf Fußball zu konzentrieren. Ich sage mir: Ein bisschen Ablenkung muss sein, ich schaffe auch nicht mehr, wenn ich noch 2 Stunden länger darüber nachdenke. Außerdem ist doch Finale!
**AM:** Also bist du nicht mit dem Ergebnis zufrieden?
**ARCH:** Ach, was soll’s. Nein, zufrieden bin ich nicht. Am Anfang war ich euphorisch, weil ich dachte, dass ich es besser kann. Ich schätze, da habe ich zu viel von mir erwartet. Du hast mir gezeigt, was alles zu berücksichtigen ist. Danach habe ich erst gezweifelt, ob das wirklich alles nötig ist. Als ich es dann verstanden hatte, war ich pessimistisch. Insofern freue ich mich, dass wir doch noch so ein gutes Ergebnis erreichen konnten.
**AM:** Na also. Das klingt schon eher nach dem Adam, den ich kenne. Erzähl mal!
**ARCH:** Meine Erkenntnis des Projekts ist, dass wir früh mit den Kunden nicht nur Fachlichkeit und Technik klären müssen, sondern auch das grundsätzliche Projektvorgehen. Zur Klärung gehört auch, zu klären, was Teil der initialen Anforderungsanalyse ist, um eine Ausschreibung zu erstellen, und was Teil des Umsetzungsprojekts ist.
Viele versuchen, im initialen Anforderungsprojekt alles zu klären. Das braucht dann ewig, erzeugt Papierwüsten und wenn es dann nach langer Zeit zur Ausschreibung und zur Umsetzung kommt, ist eigentlich allen Beteiligten klar, dass es so, wie es beschrieben wurde, doch keiner will. Das war schließlich die Erkenntnis, die zu verschiedenen agilen Vorgehensmodellen geführt hat. Oft sind erste Anpassungen für den ein oder anderen Fachexperten schon offensichtlich, bevor die erste Zeile Code geschrieben wurde. Andererseits gibt es trotz der erheblichen Aufwände keine wirklich gute Grundlage für die Aufwandskalkulation, weil die Aspekte, die für eine Kalkulation notwendig sind, nicht ausreichend beschrieben wurden. Oder ggf. verstecken sich Aufwandstreiber irgendwo in Nebensätzen und werden schnell übersehen.
Mein Gefühl ist, dass so auch nicht immer der Beste die Ausschreibung gewinnt. Und das Risiko für alle Beteiligten so immer noch sehr hoch ist. Es scheitern ja immer noch eine erhebliche Menge an Projekten. Besonders wenn der Kunde zu einem gewissen Maße an Agilität in der Umsetzung bereit ist, würde ich Dinge zwischen dem Anforderungs- und dem Umsetzungsprojekt anders aufteilen.
Ich denke, da sind wir im Ergebnis besser als andere, hätten aber noch effizienter und noch fokussierter sein können. Ich freue mich daher auf das nächste Projekt, um hier nochmal an der Effizienz zu feilen. Ich habe auch schon ein paar konkretere Ideen. Kann ich dir später mal mehr erläutern.
**AM:** Ja, das war der Teil unserer sommerlichen Gespräche, der für mich auch erkenntnisreich war und mich zum Nachdenken gebracht hat. Das ein oder andere in meinem Standardvorgehen werde ich auch noch mal überdenken. Da sollten wir auf jeden Fall im Kontakt bleiben. Unsere Töchter sind ja jetzt auch im gleichen Verein, habe ich gehört, da werden wir uns nun noch häufiger sehen.
## Erkenntnis des Tages: Das Timing entscheidet
Adams Fazit macht deutlich: Eine gute Anforderungsanalyse muss nicht alles vorab klären – aber sie muss die richtigen Dinge klären. Nur wenn Analyse, Ausschreibung und Umsetzung logisch aufeinander abgestimmt sind, lassen sich Risiken minimieren und unnötige Schleifen vermeiden.
---
## Wie geht es weiter?
Eine Ausschreibung ist kein Selbstzweck. Sie muss die Basis für eine erfolgreiche Umsetzung sein – ohne Papierwüsten, die später niemand mehr will.
Im abschließenden Teil 7 der Serie ziehen Adam und Manfred Bilanz und zeigen, wie die „Quadratur des Kreises“ im Anforderungsmanagement gelingen kann.
---
## Bereits erschienen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Anforderungsmanagement in IT-Projekten – Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
**Published:** September 11, 2025
**Author:** Tim Teulings
**Content:**
Tests im Projekt? Oft erst Thema, wenn es fast zu spät ist. In Teil 5 unserer Gesprächsreihe mit **Architekt Adam (ARCH)** und **Anforderungsmanager Manfred (AM)** geht es um einen der größten Klassiker in IT-Projekten: Das Testen wird übersehen – und plötzlich muss alles unter Zeitdruck passieren.
## Fünftes Treffen: Wenn Tests erst am Ende miteinbezogen werden
Ort des Geschehens: Wieder ein Gespräch am Spielfeldrand – diesmal mit einer Mischung aus Erleichterung und Kopfschütteln.
**ARCH:** Manfred, du glaubst nicht, was diese Woche passiert ist, ich bin fast vom Stuhl gefallen.
**AM:** Deine Frau hat dir dein Lieblingsessen gekocht? Dein Sohn hat eine 1 in Mathe?
**ARCH:** Nein! Also doch, meine Frau hat mein Lieblingsessen gekocht. War auch bitter nötig. Was ich meine: Wir sind eine Woche vor Abgabe und da fällt dem Projektmanager ein, dass sich noch niemand um den Test gekümmert hat. Wäre das nicht seine Aufgabe gewesen? Wenigsten einen Qualitätsmanager einzubinden? Ich habe ihn ja schließlich jede Woche darauf aufmerksam gemacht, dass das noch fehlt …
**AM:** Oh, der Klassiker. Niemand denkt ans Testen und der Tester darf dann in 30 % der Zeit alles machen und wird zur Rechenschaft gezogen, wenn es ein großes Problem gibt. Jetzt sag mir bitte nicht, dass du noch eben ein grobes Testvorgehen aus dem Ärmel schütteln darfst?
**ARCH:** Oh doch!
**AM:** Hast du schon Ideen?
**ARCH:** Ideen ja, aber ob das den Anforderungen genügt, weiß ich nicht. Wir konzipieren eine Anwendung mit Frontend, Backend und Datenbank. Im Backend gibt es Schnittstellen zu anderen Systemen und es gibt eine Datenbank-Synchronisation zur Golden Source von gewissen Informationen. Ich habe an ein klassisches Setup mit viel Automatisierung gedacht. JUnit-Tests, Testautomatisierung für fachliche Use Cases inklusive UI-Test und ein manueller Integrationstest überall dort, wo wir mit automatisierten Tests an Grenzen stoßen. Dazu Performance-Tests und ein Pen-Test.
**AM:** Das klingt schon mal nicht so verkehrt. Wie testet ihr den DB-Sync? Gibt es eine initiale Datenbeladung, die gesondert getestet werden muss?
**ARCH:** Oh, guter Punkt. Den DB-Sync hätten wir durch Integration in der Testumgebung implizit über die fachlichen Tests getestet. Aber das stößt bei der Initialbefüllung auf Probleme. Ich glaube, hier braucht es noch einen gesonderten Test.
**AM:** Ja, das wird häufig übersehen. Ebenfalls wird häufig das Test-Setup unterschätzt. Wie genau ist die Testumgebung bestückt? Welche Einschränkungen gibt es? Welche Qualität haben die Testdaten? Welche Performance ist zu erwarten? Wer kümmert sich?
**ARCH:** Ähhhh … Also …
**AM:** Ich sehe schon, ich treffe da einen wunden Punkt. Dann hast du dir bestimmt schon Gedanken gemacht, wann welche Tests laufen? Also im Wasserfall erst alles entwickeln, dann testen, oder doch eher agil nach jedem Feature? Was sagt denn eigentlich der Kunde dazu, wie getestet werden soll? Will er selber testen? Was will er testen? Oder will er nur einen Testreport? Kunden sind da sehr unterschiedlich. Wann werden Dinge abgenommen? Handelt es sich um ein agil umzusetzendes Projekt?
**ARCH:** Ja klar, das Projekt ist agil, also wird in jeder Iteration das jeweilige Inkrement getestet. Durch die hohe Automatisierung können die Testfälle danach regressiv durchgeführt werden.
**AM:** Sehr gut! Die UI-Tests enthalten auch Barrierefreiheit?
**ARCH:** Ja klar, Barrierefreiheit ist inzwischen absoluter Standard und wird natürlich mitgetestet. Wir haben da ein Tool, das uns auf etwaige Lücken hinweist.
**AM:** Das klingt jetzt halbwegs vollständig. Ich kenne deine spezifischen Projektherausforderungen nicht. Da könnte auch noch Testbedarf schlummern, den ich nicht kenne. Beispielsweise wenn eure Anwendung KI-Anteile enthält. Es wird auch Unterschiede geben, je nachdem ob eure Anwendung öffentlich zugänglich ist oder bspw. für die Mitarbeiter eures Kunden gedacht ist. Die Fachlichkeit selbst oder die Branche als Ganze kann auch noch Unterschiede bringen. Eine Anwendung im Public-Sektor hat differenzierte Anforderungen an die Qualität. Andere spezifische Anforderungen existieren im Finance-Sektor, insbesondere bei (Voll-)Banken und Versicherungen. Die Liste könnte ich immer weiterführen, aber ich denke, dass du meinen Punkt verstehst.
**ARCH:** Ja absolut, hier muss ich mich nochmal hinsetzen und alles durchgehen. Glücklicherweise hatten wir ja über regulatorische Rahmenbedingungen mal recht am Anfang gesprochen, so dass ich hier nicht von vorne anfange.
## Erkenntnis des Tages: Testen ist kein „Nice-to-have“
Diese Unterhaltung zeigt deutlich: Testkonzepte gehören von Anfang an in jedes Projekt – nicht erst in die Endphase.
Gerade in komplexen IT-Projekten im öffentlichen Sektor sind Teststrategie, Testumgebung und Abnahmekriterien entscheidend, um Risiken zu minimieren und die Qualität zu sichern.
---
## Wie geht’s weiter?
Tests sind kein „Nice-to-have“, sondern ein zentrales Qualitätsmerkmal. Doch was passiert, wenn die Analyse, die Ausschreibung und die Umsetzung nicht aufeinander abgestimmt sind? Im nächsten Teil der Serie sprechen Adam und Manfred genau darüber – und ziehen Lehren, wie die richtige Balance zwischen Analyse, Projektplanung und Umsetzung aussehen muss.
---
## Bereits erschienen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Anforderungsmanagement in IT-Projekten – Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
**Published:** August 29, 2025
**Author:** Tim Teulings
**Content:**
Manchmal sind es nicht die fehlenden Prozessbilder, sondern die fehlenden Schätzgrundlagen, die Projekte ins Stocken bringen. In Teil 4 unserer Gesprächsreihe mit **Architekt Adam (ARCH)** und **Anforderungsmanager Manfred** (AM) geht es um eine zentrale Frage: Welche Informationen sind wirklich nötig, um Aufwand und Architektur sicher kalkulieren zu können?
## Viertes Treffen: Prozessbilder sind nicht genug
Ort des Geschehens: Wieder am Spielfeldrand. Diesmal wirkt Adam spürbar frustriert.
**AM:** Und…? Wie geht es dir heute?
**ARCH:** Oh man, es wird nicht besser. Unser Anforderungsmanager geht mir gerade ziemlich auf den Keks. Wir hatten ja intern besprochen, dass die Kollegen erst einmal mit dem Kunden abstimmen, wie die Applikation funktionieren soll, damit der Kunde meine technisch-orientierten Fragen anschließend besser beantworten kann. Das ist auch alles ganz nett, was sie da machen und hilft auch dem Kunden, aber es beantwortet keine meiner Fragen. Ich komme gerade nicht weiter. Schön, dass wir detaillierte Prozessbilder haben. Aber meine Frage ist eher, wie schnell ändern sich die Prozesse, wie soll die UI dazu aussehen? Das interessiert aber die Kollegen nicht. Was machen die da? Am Ende des Tages muss man auf Basis der Analyseergebnisse ja ein Angebot schreiben – und im konkreten Fall wollen wir ja auch teilnehmen und haben daher ein direktes Interesse, dass wir ein gutes Angebot machen. Aber trotz der vielen erfassten Informationen, habe ich nicht die Informationen, um eine angemessene Lösungsarchitektur zu erarbeiten und die Umsetzung dieser dann auch zu schätzen. Und so langsam wird die Zeit knapp…
**AM:** Naja, das ist grundsätzlich nicht falsch. Klar beschriebene Prozesse sind schon grundsätzlich ein wichtiger Aspekt für eine Umsetzung. Ich verstehe aber, dass sie nicht ausreichend sind, eine spezielle Umsetzung dieser zu identifizieren.
Mir scheint, ihr habt kein gemeinsames Bild, was ihr für den Kunden und auch für euch erreichen wollt und in welcher Reihenfolge ihr diese Dinge wann erreichen wollt? Was ist für den Kunden und euch heute das wichtigste? Was sind die zu erreichenden Ziele und was muss dafür getan werden – und was ggf. (noch) nicht? Welches Ziel versucht ihr denn deiner Meinung nach gerade zu erreichen?
**ARCH:** Äh …!? Hmm …
**AM:** Was ist dein Ziel?
**ARCH:** Wie gesagt…Ich stelle mir vor, dass ich irgendwann diese Ausschreibung selbst auf den Tisch habe und sie dann schätzen muss. Das ist mein grundsätzlicher Anspruch gegenüber dem Kunden und deckt sich aus meiner Sicht mit seinem Wunsch, ein wirtschaftliches Angebot für eine für ihn möglichst optimale Lösung von einem „guten“ Dienstleister zu bekommen. Dann hab ich meine Arbeit gemacht, dann ist der Kunde zufrieden und empfiehlt mich ggf. auch weiter oder spricht mich für andere Projekte wieder an. Dies funktioniert aber aktuell so noch nicht.
**AM:** OK. Das klingt spannend, da könnte ich auch noch was lernen. Lass uns das mal aufmalen (nimmt seinem Sohn eines der leeren Blätter, auf denen dieser zwischen den Spielen gerade malt, weg). Und schreibt „Schätzen“ auf das Blatt. Was brauchst du, um zu schätzen?
**Arch:** Ich muss eine konkrete architektonische Lösung im Kopf haben.
**AM:** Irgendeine?
**ARCH:** Nein. Eine angemessene, wirtschaftliche Lösung. Eine, die die Rahmenbedingungen und die Qualitätsanforderungen einhält und die Features des Kunden erfüllt.
**AM:** OK, das reicht doch aber nicht. Du kannst ja nicht einfach hingehen und sagen „5 Features => 5 Tage“. Du brauchst doch eine detaillierte Beschreibung der Features, um den Aufwand benennen zu können. Deswegen machen die Kollegen ja so einen Aufwand, oder?**ARCH:** \[Grübelt\] Nein! Das brauche ich nicht! Wir sind ja eine professionelle Firma und haben schon viele Projekte umgesetzt. Die Projekte sind sehr verschieden, aber viele, fast alle Projekte bestehen aus wiederkehrenden Bausteinen. In der Regel gibt es eine Handvoll Lösungen, die sich in ihren spezifischen Eigenschaften unterscheiden. Meist reicht es mir zu wissen, welche Lösung ich umsetzen muss, wie oft ich sie umsetzen muss und wie komplex sie aus Sicht der fachlichen Anforderungen jeweils ist. Nimm so ein Webformular: Für die Schätzung ist es egal, wie die Felder heißen. Wichtig ist eher die Anzahl der Felder, die Komplexität der Validierung und ob es ggf. besondere Merkmale wie z. B. Tabellen gibt. Da verstehe ich auch nicht, warum die Kollegen stundenlang um Namen ringen.
Oder nimm die Erstellung eines T-Shirts. Für die Bestimmung des Preises ist völlig egal, was für ein Motiv auf dem T-Shirt gedruckt wird. Entscheidend ist die Qualität des Materials, die Größe des T-Shirts, sowie ob es ein einfarbiger oder mehrfarbiger Druck ist. Ggf. ist es auch interessant, wie viele T-Shirts der Kunde will. Wenn der Kunde 50 Shirts haben will, kann ich einen anderen Preis machen, ggf. kann ich sogar in der Herstellung durch die Menge etwas effizienter werden, weil meine Mitarbeiter anders arbeiten können. Aber das konkrete Motiv brauch ich ggf. erst kurz vor dem Druck (also bei der Entwicklung), speziell wenn der Kunde sicherstellt, dass das Motiv bestimmte Eigenschaften z.B. bzgl. Größe und Auflösung einhält.
**AM:** Hmm, das ist interessant. Grundsätzlich ist das für mich ja nicht neu. Aber die Vehemenz deiner Aussage überrascht mich dann doch. Da muss ich mal drüber nachdenken.
## Erkenntnis des Tages: Schätzen heißt Muster erkennen
Was Architekt Adam hier deutlich macht: Nicht jede Schätzung braucht jedes Detail. Oft reicht es, die Bausteine zu kennen, aus denen eine Lösung zusammengesetzt wird – und diese richtig zu klassifizieren.
Für das Anforderungsmanagement bedeutet das: Weg vom reinen Festhalten einzelner Fakten hin zu einer strukturierten Erfassung von Aufwandstreibern und Wiederholungsmustern. Das spart Zeit und schafft eine realistischere Basis für Angebote.
---
## Wie geht es weiter?
Im nächsten Teil unserer Serie wird es noch praktischer: Adam erlebt hautnah, was passiert, wenn das Testen im Projekt zu spät auf die Agenda kommt. Ein Thema, das im öffentlichen Sektor besonders häufig übersehen wird – und dessen Konsequenzen weitreichend sein können.
---
## Bereits erschienen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Anforderungsmanagement in IT-Projekten – Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
**Published:** August 12, 2025
**Author:** Richard Attermeyer
**Content:**
Was passiert, wenn sich die Organisation, die dich beauftragt, nicht einig ist? Im dritten Teil unserer Gesprächsreihe mit **Architekt Adam (ARCH)** und **Anforderungsmanager Manfred (AM)** zeigt sich: Selbst die beste Vorbereitung hilft nur bedingt, wenn bei den Verantwortlichen verschiedene Interessen aufeinandertreffen – und keine klare fachliche Linie vorhanden ist.
## Drittes Treffen: Wenn sich die Organisation selbst widerspricht
**Ort des Geschehens:** Wieder am Spielfeldrand. Zwischen Kaffee, Checklisten und Kopfschütteln.
**ARCH:** Danke nochmal für deinen Hinweis, ich habe eine Checkliste erstellt und bin diese beim Kunden durchgegangen. Aber auch die hat nicht geholfen. Wir kamen zwar in die Diskussion, aber ich merkte, dass in der Organisation noch nicht viel dazu nachgedacht worden ist bzw. sich nicht alle Ansprechpersonen des Kunden einig waren. Dann habe ich mal nach konkreten Rahmenbedingungen und Qualitätsmerkmalen gefragt. Glücklicherweise hatte ich da auch etwas vorbereitet, das hat dann geholfen.
**AM:** Ja, jede Kundensituation ist anders. Die einen sind gut darin, Anforderungen zu formulieren. Andere können Anforderungen zumindest diskutieren. Wenn sie beides nicht können, wird es spannend. Aber mit irgendeiner Frage kriegt man sie alle dazu, ihre Anforderungen zumindest so weit benennen zu können, dass sich dadurch der Anforderungsraum konkretisiert und der potenzielle Lösungsraum Stück für Stück kleiner wird. Es ist ein wenig auch eine Kunst, immer die nächste konkreteste und wichtigste Frage zu identifizieren, die das Gegenüber beantworten kann. Und mit jeder Diskussion konkretisiert sich auch das Bild im Kopf, so dass neue Erkenntnisse gewonnen werden und Fragen besser beantworten können. Interessant, dass bei dir die Frage nach den Rahmenbedingungen geholfen hat, einen Einstieg zu finden. Das habe ich so auch noch nicht gesehen.
**ARCH:** Ja, ja, allerdings habe ich dann gemerkt, dass es auch da noch schwer fiel, weiter zu kommen. Letztlich habe ich im weiteren Gespräch dann festgestellt, dass es einfach noch gar keine Idee gab, wie die zukünftige Software aussehen und funktionieren soll. Und das meine ich nicht technisch, nein fachlich! Alles, was ich hörte, klang schwammig und an einigen Stellen haben sich die Leute, mit denen ich zu tun hatte, komplett widersprochen. In einer Situation hätten sie sich fast in die Haare bekommen.
**AM:** Oh, oh: Ich dachte, ihr macht parallel auch die fachliche Anforderungsanalyse? Davon wäre ich jetzt ausgegangen. Es macht ja keinen Sinn, technische Themen zu beleuchten, wenn die Fachlichkeit nicht klar ist.
**ARCH:** Wiebke, die dafür zuständig ist, war erst krank und dann im Urlaub. Sie legt aber jetzt los. Und du hast ja Recht: Deshalb haben wir auch entschieden, dass ich jetzt erst einmal auf die Ergebnisse von ihr warte, bevor noch irgendwelche Türen ausgehebelt werden.
**AM:** So schlimm? Hast du eine Ahnung, woran das liegt? Also nicht, dass sich die Leute widersprechen, sondern weshalb sie sich widersprechen?
**ARCH:** Gute Frage, da habe ich noch gar nicht darüber nachgedacht. Ich denke, sie mögen sich einfach nicht. Keine Ahnung, was da los ist.
**AM:** Vielleicht haben sie schlicht unterschiedliche Vorstellungen? Ggf. sehen sie eine andere Lösung, weil ihre Rahmenbedingungen anders sind. Es macht z. B. einen großen Unterschied, ob ein Team aus 2–3 oder aus 20 Personen besteht. Man hat ganz andere Herausforderungen und optimiert entsprechend auch ganz anders. Was wurde denn intern bereits kommuniziert und diskutiert? Ggf. dringen die einen mit ihren Wünschen schon in ihrem Team nicht durch. Eine andere Idee wäre, dass alle ihre eigene Agenda im Kopf haben. Du wirst schlecht die Zielvereinbarungen der Mitarbeitenden einsehen können, aber eventuell kannst du ja etwas aus ihrem Verhalten ablesen? Herrscht in der Organisation grundsätzlich Ellenbogenmentalität, dann kann das ein Indiz dafür sein. Es kann aber auch sein, dass aus irgendeiner persönlichen Wertvorstellung heraus, die unabhängig von den Zielvereinbarungen ist, einzelne oder sogar alle Beteiligte ihre Macht im Unternehmen demonstrieren wollen. Es gibt weitere Erklärungen, aber in den allermeisten Fällen sind es entweder unterschiedliche Kontexte, mangelnde Kommunikation oder Kompetenzspielchen – oder die Kombination aus allen dreien. Wenn Wiebke es nicht bereits getan hat, würde ich dir raten, das mit deiner Auftraggeberin in einem offenen Gespräch zu klären.
**ARCH:** Hmm, verstehe. Deswegen war auch am Anfang so wichtig, dass ich die handelnden Personen, also Ansprechpersonen, Verantwortliche und Entscheidungsebene kennenlerne.
**AM:** Korrekt. Und nicht nur das Organigramm würde ich studieren, sondern auch die Dynamik hinter diesem Organigramm.
### Wenn interne Konflikte die Analyse blockieren
Anforderungsmanagement scheitert nicht nur an fehlenden Informationen – sondern oft an internen Zielkonflikten beim Kunden. Gerade im öffentlichen Sektor mit seinen vielfältigen Stakeholdern kann es passieren, dass es nicht „den einen Kunden“ gibt, sondern mehrere widersprüchliche Sichtweisen innerhalb der Organisation.
Für Berater:innen bedeutet das: Beobachten, analysieren, moderieren. Und vor allem: Geduld haben.
## Erkenntnis des Tages: Wer entscheidet, wer spricht – und warum?
Was Architekt Adam in diesem Treffen lernt, ist zentral: Fachlichkeit entsteht nicht im Vakuum, sondern im sozialen Gefüge einer Organisation. Bevor technische Entscheidungen vorbereitet werden können, braucht es ein gemeinsames Verständnis – nicht nur über die Anforderungen, sondern auch über die Rollen, Machtverhältnisse und Kommunikationswege im Kundenunternehmen.
---
## Wie geht es weiter?
Im nächsten Teil wird es noch technischer: Wie lassen sich Anforderungen so strukturieren, dass sie architekturrelevant und kalkulierbar werden? Und welche Informationen braucht man wirklich, um zu schätzen?
---
## Bereits erschienen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Anforderungsmanagement in IT-Projekten – Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
**Published:** August 5, 2025
**Author:** Tim Teulings
**Content:**
Nach dem ersten positiven Auftaktgespräch beim Kunden kommt die Ernüchterung: Die technischen Fragen bleiben unbeantwortet, die Unsicherheit wächst. In Teil 2 unserer Blogserie „Anforderungsmanagement im Public-Sektor“ treffen sich **Architekt Adam (ARCH)** und **Anforderungsmanager Manfred (AM)** erneut – und sprechen über den Kern jeder guten Anforderungsanalyse:
## Zweites Treffen: Zwischen Erwartung und Wirklichkeit
**Ort des Geschehens:** Wieder ein Treffen beim Sport – Gelegenheit für einen ehrlichen Rückblick auf das erste Kundengespräch.
**AM:** Und, wie ist es gelaufen?
ARCH:** Ach ja, der Kick-Off war eigentlich ganz gut. Deine Tipps haben mir echt geholfen, vielen Dank noch mal dafür! … Allerdings hat es danach Probleme gegeben. Nachdem wir die von dir genannten Punkte geklärt hatten, bin ich dann eingestiegen und habe die Anwesenden gefragt, welche Datenbank sie brauchen. Das konnten sie nicht beantworten. Da war ich schon überrascht. Dann habe ich sie gefragt, wie die Software betrieben wird und wie ihre Mengengerüste sein werden. Konnten sie auch nicht beantworten. Sie haben auch gar nicht verstanden, warum ich die Fragen stelle, schließlich entscheiden das doch die Bieter. Wie kann man nur so engstirnig sein, dachte ich bei mir! Wenn sie entsprechende Informationen nicht ins Angebot packen, werden sie ggf. sehr unterschiedliche Angebote bekommen. Ggf. fliegt ein eigentlich guter Anbieter so raus, weil er falsche Annahmen getroffen hat.
**AM:** Ja, das erlebe ich immer wieder. Man muss halt verstehen, dass die Leute, mit denen wir reden, meist keine technische Expertise haben. Ihnen ist nicht klar, dass eine Zehnerpotenz im Mengengerüst oder ein paar Prozentpunkte in der Verfügbarkeit im Zweifel auch zu um Faktoren höheren Kosten führen können. Zwischen Sätzen wie „ich kann auf alle historischen Börsenkursänderungen zugreifen und bekomme den aktuellen Stand verlässlich innerhalb von Millisekunden“ und „ich zeige immer den letzten bekannten Stand des DAX auf dem Desktop an“ liegen ggf. Millionen von Euro.
Wie habt ihr das gelöst? Was habt ihr gemacht, als ihr das erkannt habt?
**ARCH:** Wir haben das Meeting erstmal beendet, weil wir schon über die Zeit waren. Gestern haben wir uns dann noch einmal intern beratschlagt. Meine Projektleiterin meint, wir müssen wohl weiter vorne anfangen. Da waren wir uns alle nach kurzer Diskussion einig. Wie würdest du vorgehen? Du sagst ja, du kennst das Problem?
**AM:** Ja klar. Zuerst ist es eine völlig normale Situation. Ich ertappe mich z. B. auch immer wieder dabei, dass ich denke, beim Kunden erwarten sie die eierlegende Wollmilchsau und alles in „schick“ und „aufwändig“. Andererseits hat man ja auch schon viel gemacht und gesehen und hat auch eine bekannte Standardlösung parat – die ist aber ggf. nicht das ist, was gewollt ist. Und so denken Ansprechpersonen in den Behörden in der Regel meist auch nicht. Die kommen meist erst einmal mit ihrem spezifischen Problem und haben eine optimale Lösung im Kopf, die dann auch noch bezahlbar sein soll.
### Die Frage hinter der Frage: Perspektivwechsel im Anforderungsmanagement
**AM:** Mir hilft dann immer, dass ich mich frage: Wie denkt der Kunde? Was ist die Frage hinter der Frage? Was genau macht den Unterschied? Was sorgt dafür, dass deine Ansprechpersonen mit dem Ergebnis zufrieden sind oder nicht? Beispiel: Der Wunsch wäre ein Webshop , in dem Produkte verkauft werden können. Nun gibt es in der betreffenden Organisation eine unzählige Anzahl Produkte, die in vielen verschiedenen Datenbanken gepflegt sind – falls sie überhaupt in einer Datenbank sind. Das kann zum Beispiel daran liegen, dass die Produkte von verschiedenen Fachabteilungen entwickelt und betreut werden und jede Fachabteilung hat ihre eigene Anwendung.
**ARCH:** OK, was willst du damit sagen, komm mal zum Punkt. Ich brauche eine konkrete Idee für mein Problem.
**AM:** Ich komme gleich zum Punkt. Die Frage hinter der Frage in meinem Beispiel könnte also sein: Warum möchte der Kunde einen Webshop? Möchte er ein neues Marktsegment erobern? Möchte er in seiner bestehenden Zielgruppe die Durchdringung erhöhen? Geht es dabei eventuell um eine eingeschränkte Produktauswahl? All diese Fragen können einen Hinweis auf die benötigte Technik liefern. Du darfst ihn also nicht nach der Technik fragen, sondern du musst dir überlegen, welche Kriterien du für eine Auswahl benötigst. Die musst du dann beim Kunden abfragen.
**ARCH:** Ich glaube, es ergibt so langsam Sinn. Wenn in deinem Beispiel der Kunde nur 2–3 Produkte in neuen Kundensegmenten verkaufen möchte, könnte eine Präsenz bei Amazon die Antwort sein. Wenn er aber für seine bestehende Kundengruppe einen neuen Verkaufskanal haben möchte ohne Provision zahlen zu müssen, dann ist wahrscheinlich ein eigener Webshop besser. Und vielleicht will er sogar das eine heute und das andere später?
**AM:** So ist es. Hast du schon eine Idee, wie du das bei deinem Kunden anwenden kannst?
**ARCH:** Ja und nein. Ein paar Fragen hinter den Fragen finde ich bestimmt. Aber was mache ich damit? Wie gehe ich damit auf den Kunden zu?
### Struktur statt Frust: Die Checkliste als Brücke
**AM:** Du hattest ja nun schon einen ersten Termin mit dem Kunden, der nicht so gut gelaufen ist. Eine Option, die sich jetzt aus meiner Sicht anbieten würde, wäre z. B. eine Checkliste. So zeigst du, dass du zum einen natürlich weiter an einer Lösung interessiert und hoch engagiert bist, aber zum anderen beweist du auch, dass du die Analyse strukturiert und professionell vorantreiben kannst. Denk also über die Fragen hinter den Fragen nach und erstelle daraus eine Checkliste. Meistens fallen dir auch noch ganz andere Fragen ein, die sich deine Ansprechpersonen sich selbst noch gar nicht gestellt haben. Die kannst du direkt mit einfließen lassen. Mit ein bisschen Glück und moderativem Geschick erfährst du so, speziell durch die dadurch entstehende Diskussion, viel mehr darüber, wie das Bild im Kopf deines Gegenübers aussieht.
**ARCH:** Das mache ich, danke dir!
## Erkenntnis des Tages: Vom Verstehen zum Vermitteln
Ein zentrales Learning dieses Treffens: Fragen nicht wörtlich nehmen – sondern hinterfragen. Häufig fehlt gerade im öffentlichen Umfeld die technische Perspektive, um den Lösungsraum korrekt abzubilden. Hier hilft kein Bohren in technischen Details, sondern das Denken in Zielbildern und Entscheidungskriterien.
Eine gut vorbereitete Checkliste kann zum Dialog auf Augenhöhe führen – und zur Erkenntnis: Es gibt nicht den einen richtigen Weg, sondern viele mögliche. Wichtig ist nur, dass alle Beteiligten wissen, welchen Weg sie gehen wollen.
---
## Wie geht es weiter?
Im nächsten Teil zeigt sich, wie diese neue Herangehensweise bei Adams Kunden ankommt – und warum es manchmal nicht nur an der Technik, sondern an der Kommunikation im Projekt scheitert. Bleiben Sie dran!
---
## Bereits erschienen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Anforderungsmanagement in IT-Projekten – Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
**Published:** Juli 29, 2025
**Author:** Tim Teulings
**Content:**
Wie beginnt eigentlich ein gutes Anforderungsmanagementprojekt? Oft mit Unklarheiten. Und mit Gesprächen – auf dem Sportplatz, in der Turnhalle oder zwischen zwei Terminen. Im Rahmen unserer Blogserie begleiten wir zwei erfahrene Köpfe – **Architekt Adam (ARCH)** und **Anforderungsmanager Manfred (AM)** – bei ihren Treffen im Alltag. Gemeinsam beleuchten sie typische Herausforderungen aus dem Anforderungsmanagement in IT-Projekten.
## Wie alles begann: Architektur trifft auf Anforderung
Im ersten Teil geht es um den Startpunkt: Wie gelingt der Einstieg in ein komplexes IT-Projekt, bei dem eine öffentliche Ausschreibung vorbereitet werden soll?
## Erstes Treffen: Anforderungsmanagement für eine Ausschreibung
**Ort des Geschehens:** Die Turnhalle beim Sport der Kinder – ein alltäglicher, entspannter Rahmen für ein Fachgespräch mit Tiefgang.
**Hinweis:** Der folgende Dialog ist Teil einer fiktiven Gesprächsreihe, die typische Rollen und Herausforderungen im Anforderungsmanagement realitätsnah beleuchtet.
**ARCH:** Na, Manfred, wie geht’s? Was macht die Kunst?
**AM:** Muss, und selbst? Was macht die Arbeit? Bist du endlich aus diesem ollem Wartungsprojekt raus?
**ARCH:** Ja, das war wirklich sehr langweilig, puh. Aber jetzt habe ich etwas Neues, allerdings wieder nicht das schöne „Grüne Wiese Projekt“, von dem wir alle träumen – zumindest noch nicht …
**AM:** Noch nicht? Wieso?
**ARCH:** Die Auftraggeberin, eine Behörde, möchte, dass wir die fachlichen und technischen Dokumente für eine darauffolgende Ausschreibung erstellen. Die Bestandslösung ist in die Jahre gekommen, nicht mehr wirklich wartbar und fachlich tragfähig. Die kommt aus einer Zeit, wo Digitalisierung ein Synonym für „irgendwie in Software und wie Akte und Karteikarte – nur am Computer“ war. Wenn wir etwas Glück haben und gute Arbeit machen, gewinnen wir ggf. später auch die Ausschreibung …
**AM:** Cool. Also sollte ihr faktisch ein Lastenheft mit dem Kunden erarbeiten?
**ARCH:** Ja, so nennt man das wohl. Spannende Sache, normalerweise kenne ich ja nur fertige Versionen solcher Dokumente – die in der Regel aber nie gut waren. Aus der Sicht der Behörde war dann die Standardantwort „Diskutieren sie nicht, schauen sie in die Spezifikation“, aber da fand ich nicht, was wir wissen mussten. Das führte zu Diskussionen und Mehraufwand, den wir dann an anderer Stelle sparen mussten oder wo die Auftraggeberin dann nochmals versuchen musste, weiteres Geld zu besorgen.
Jetzt habe ich mal die Chance, das besser zu machen. Aber im Team können wir uns nicht einigen, was wir denn jetzt genau wie machen, und was in das Dokument am Ende reingehört. Zu allem Überfluss haben wir nicht so viel Zeit, wie wir dachten. Wir können also nicht einfach mal anfangen, das muss schon von Anfang an sitzen.
**AM:** Aber nun ja. Eure Auftraggeberin muss doch gesagt haben, was sie für die Ausschreibung braucht und haben will – und was nicht. Ebenso sollte sie ja einschätzen können, was sie bereits weiß und nur noch aufgeschrieben haben will oder wo sie noch Hilfe braucht, z. B. in Form von Workshops oder technischer Beratung und Konzeption braucht.
**ARCH:** Nein, die macht das leider auch zum ersten Mal und hat daher auch noch keine wirklich konkreten Vorstellungen. Ich bin mir noch nicht sicher, ob ich unseren Vertrieb loben oder verteufeln soll, aber irgendwie hat er es geschafft, dass auch wir mit wenig Konkretem die Behörde als Kunden gewinnen konnten.
**AM:** Oh … und nu?
**ARCH:** Hmm, nächste Woche ist ein erstes Kennenlernen und wir brauchen langsam eine Agenda für diesen Termin aber auch einen Masterplan für die folgenden Termine … Was würdest du machen? Du bist da doch ein alter Hase?
**AM:** Na ja, erst einmal Kennenlernen klingt schon mal gut. Dann soll die Auftraggeberin sagen, warum sie das Projekt angeht. Was wird bezweckt? Welche Geschäftsziele verfolgt die Organisation und was sind Erfolgskriterien? Auch die Rahmenbedingungen sind wichtig. Wie groß soll das Projekt werden? Meist gibt es ja einen angestrebten finanziellen Rahmen für die Umsetzung. Aber auch für den späteren Betrieb? Gibt es bereits bekannte grundsätzliche Rahmenbedingungen?
**ARCH:** OK, das ergibt Sinn. Auf Basis der allgemeinen Projektbeschreibung hätte ich sogar schon erste Ideen. Ich würde daher ja gerne sofort mit den Umsetzungsdetails loslegen. Wieso brauche ich da „Geschäftsziele“? Das klingt ein wenig weit von der Technik entfernt. Ist das keine Zeitverschwendung? Ich dachte eher an konkrete Fragen zu Technologien, Qualitätsanforderungen, Sicherheitskriterien und natürlich auch zu den Use Cases.
**AM:** Immer langsam und eins nach dem anderen. Wenn du nicht weißt, warum dein Kunde Dinge macht, dann wirst du ihm irgendein, aber nicht ein auch wirklich passendes Lastenheft schreiben können. Und passend bedeutet erst einmal, dass am Ende deien Auftraggeberin mit den Ergebnissen zufrieden ist, weil ihre Behörde mit der neuen Lösung die erhofften Ziele auch erreicht. Du musst immer wissen, was deinen Kunden glücklich macht und vor allem was er braucht. Nur so kannst du ein Lastenheft schreiben, das ihn zufrieden stellt und gegen das du auch gerne entwickelst. Wenn du die Geschäftsziele verstanden hast, sind organisatorische Fragen zu klären. Wer sind deine Ansprechpartner, Verantwortliche und Entscheidungsträger? Wo soll das Projekt umgesetzt werden? Remote? Vor Ort? Welche Abstimmungsrunden und andere Regelmeetings gibt es? Wer entscheidet, wer muss mit einbezogen werden? Was ist die Verfügbarkeit der einzelnen Personen? Ich habe es schon mal gehabt, dass ein Keyplayer nur noch zwei Wochen da war, um dann den Rest der Projektphase z.?B. in Elternzeit zu sein.
**ARCH:** So habe ich das ja noch nie betrachtet, aber klingt eigentlich logisch. Ich versuche das mal zusammenzuschreiben und die ersten Gespräche mit dem Kunden so anzugehen!
## Erkenntnis des Tages: Ohne Ziel kein Plan
Dieses erste Gespräch zeigt, wie wichtig es ist, nicht sofort mit der Lösung loszulegen, sondern das „Warum“ eines Projekts zu verstehen – gerade wenn die Ausschreibung noch vorbereitet werden muss. Die richtigen Fragen zu Beginn helfen, Risiken und Missverständnisse zu vermeiden und eine tragfähige Basis für das Lastenheft zu schaffen.
---
## Wie geht es weiter?
In der nächsten Episode erfahren wir, wie das erste Treffen mit der Auftraggeberin gelaufen ist – und warum die Frage nach der richtigen Datenbank manchmal das falsche Gespräch eröffnet.
Bleiben Sie dran!
---
## Bereits erschienen
[Teil 1: Ein neues Projekt und viele offene Fragen](https://thecattlecrew.net/2025/07/29/anforderungsmanagement-im-public-sektor-teil-1-ein-neues-projekt-und-viele-offene-fragen/)
[Teil 2: Viele Wege führen nach Rom, aber welchen wollen wir gehen?](https://thecattlecrew.net/2025/08/05/anforderungsmanagement-im-public-sektor-teil-2-viele-wege-fuehren-nach-rom-aber-welchen-wollen-wir-gehen/)
[Teil 3: Ein Auftrag? Nein, viele! Und alle wollen etwas anderes](https://thecattlecrew.net/2025/08/12/anforderungsmanagement-im-public-sektor-teil-3-ein-auftrag-nein-viele-und-alle-wollen-etwas-anderes/)
[Teil 4: Was braucht man wirklich, um zu schätzen?](https://thecattlecrew.net/2025/08/29/anforderungsmanagement-im-public-sektor-teil-4-was-braucht-man-wirklich-um-zu-schaetzen/)
[Teil 5: Testen vergessen?](https://thecattlecrew.net/2025/09/11/anforderungsmanagement-im-public-sektor-teil-5-testen-vergessen/)
[Teil 6: Analyse, Ausschreibung und Umsetzung – es muss zusammenpassen!](https://thecattlecrew.net/2025/09/25/anforderungsmanagement-im-public-sektor-teil-6-analyse-ausschreibung-und-umsetzung-es-muss-zusammenpassen/)
[Teil 7: Fazit und Ausblick](https://thecattlecrew.net/2025/10/07/anforderungsmanagement-im-public-sektor-teil-7-fazit-und-ausblick/)
**Kategorien:** Development, Tools & Methoden
---
### [Was haben ein Hammer und ein LLM (nicht) gemeinsam?](https://thecattlecrew.net/2025/10/02/was-haben-ein-hammer-und-ein-llm-nicht-gemeinsam/)
**Published:** Oktober 2, 2025
**Author:** Sebastian Pospiech
**Content:**
Sicher habt ihr alle schon mal einen Hammer benutzt, oder? Ein einfaches, altes Werkzeug. Seine Zwecke sind begrenzt: Nägel in die Wand bekommen, im Notfall eine Scheibe einschlagen oder meinen Daumen zerstören. In allen drei Fällen nutzt man ihn auf dieselbe Art – und das Feedback ist in der Regel unmittelbar visuell erfassbar (oder spürbar).
Mit der Verbreitung von Computersystemen in den 80ern zog auch das Bewusstsein ein, dass man nun ein neues Werkzeug hatte, das den bisherigen ungleich war. Eine Maschine für dutzende Zwecke anstatt nur für einen – und mit deutlich komplexerem Feedback. Dies brachte eine neue wissenschaftliche Disziplin hervor: **Human-Computer Interaction, kurz HCI.**
## Die Kernbotschaft von HCI
HCI ist ein interdisziplinäres Forschungsfeld. Es verbindet unter anderem Verhaltenswissenschaften mit der Informatik und versucht, die Besonderheiten der Arbeit an und mit Computersystemen herauszuarbeiten. Schon in den ersten Werken, die dieses Feld begründeten, wurde die Arbeit mit einem Computer eher wie die Kommunikation mit einem Menschen verglichen als wie die Nutzung eines Werkzeugs.
Man muss bewusst eine Aktion wählen, Daten eingeben und erhält hoffentlich ein Feedback – eine Reaktion, die bei mir als Nutzer wiederum eine neue Handlung auslöst.
Entsprechend muss ein Nutzer die Möglichkeit haben, klar zu formulieren, was der Computer tun soll – zum Beispiel eine Datei löschen. Und so hat sich das Markieren einer Datei und das Betätigen des Papierkorbsymbols für diese Aktion durchgesetzt. Eine semantisch äquivalente, aber rudimentärere Kommunikationsform ist die textbasierte Variante mittels Konsole:
```
rm langweiliger-blogbeitrag.doc
```
Überraschung: Im Mainstream hat sich Ersteres durchgesetzt. Wir holen ja unser Geld am Geldautomaten auch nicht ab, indem wir
```
./give-me-all-money.sh –iban DE…
```
in eine Konsole tippen, sondern werden durch ein intuitives Menü geführt.
In Entwicklerkreisen sieht das nicht immer so aus, doch auch hier haben sich spezialisierte Werkzeuge etabliert – etwa IDEs. Jede Disziplin hat ihre eigene Software, vom ETL-Datenschubser bis zum Game Designer. So entstanden über die Jahre viele Paradigmen, Best Practices und Tools, um gute User Interfaces zu bauen. Schließlich entstand daraus sogar das Berufsbild des **UX-Designers**.
## Gängige Anforderungen an ein gutes Interface
- **Usability First** – Interfaces sollen leicht erlernbar, effizient und fehlerarm sein (Nielsen’s Usability Heuristics, 1990er).
- **Affordances & Signifiers** – Nutzer erkennen an der Gestaltung, wie man ein Interface bedienen kann (Norman, The Design of Everyday Things).
- **Consistency & Standards** – vertraute Muster (z. B. „Save“-Icon) erleichtern Interaktion.
- **Feedback & Visibility** – Systeme sollen jederzeit zeigen, was gerade passiert (z. B. Ladebalken, Statusmeldungen).
- **Minimierung der kognitiven Last** – Systeme sollen Informationen so präsentieren, dass sie leicht verarbeitet werden können.
- **User-Centered Design** – Entwicklung orientiert sich an den Bedürfnissen, Fähigkeiten und Kontexten der Nutzer:innen.
Und doch … alles, was wir hier tun, sind Krücken. Grafiken visualisieren Datenflüsse oder Prozesse, Buttons visualisieren Aktionen. Mit Baukästen versuchen wir, Low-Code- oder No-Code-Ansätze zu erreichen. Animationen, Warnungen oder auch Geräusche sollen uns Feedback geben.
## Barrierefreiheit
Ein kurzer Abschweif ins Thema Barrierefreiheit, weil er mir wichtig ist. Einfach ist das Thema nicht – im Gegenteil, es ist komplex und schwer. Wo Standards Wiedererkennungswerte schaffen und viele Funktionen auf einem Screen untergebracht werden müssen, müssen auch Anforderungen an Barrierefreiheit berücksichtigt werden. Menschen sollen Zugänge haben, ob sie sehschwach, motorisch eingeschränkt oder anderweitig beeinträchtigt sind.
Ein User Interface funktioniert in der Regel am besten, wenn es nicht versucht, alle Bedarfe abzudecken, sondern auf eine Persona zugeschnitten ist. Bei Barrierefreiheit müssen jedoch viele individuelle Charakteristika gleichzeitig bedient werden. Ein Widerspruch, der sich nicht leicht auflösen lässt. Zum Glück gibt es mittlerweile gute Gesetze, die Lösungen trotz dieser Herausforderung einfordern.
## Und dann kam das LLM
Und nun, nach 45 Jahren Forschung und Fortschritt in HCI (lassen wir die Zeit, in der Computer noch keine Bildschirme hatten, mal außen vor) kommen die **Large Language Models**. Ein simples Chatfenster oder ein Mikrofon reicht.
- „Lösche bitte meinen langweiligen Blogbeitrag!“ – zack, weg.
- „Schreib einen neuen!“ – zack, Influencer.
- „Durchsuche meine Mails!“, „Schicke eine Nachricht!“, „Recherchiere Folgendes!“, „Programmiere mir ein Skript!“ – alles über dasselbe Interface.
Wo man früher zehn verschiedene Interfaces brauchte, gibt es jetzt nur noch eins. Die „Zeichensprache“, die jahrelang unsere Kommunikation mit dem Computer geprägt hat, wird nun zur echten, natürlichen Sprache – zu **Natural User Interfaces (NUI)**.
## LLMs als neue Gesprächspartner
Ja, persönliche Assistenten wie Siri oder Alexa können das schon ein paar Jahre. Aber deren Feedback war immer stark eingeschränkt. Ein LLM dagegen agiert mit mir, als wäre ich – oder besser gesagt: als wäre es – ein Mensch. Damit kommen wir der alten Analogie aus den 80ern („HCI ist näher an Mensch-zu-Mensch-Kommunikation als an einer Werkzeugbenutzung“) nun sehr nahe.
Ein LLM als Frontend für ein IT-System kann vieles einfacher machen:
- **Usability:** Die Einstiegshürde sinkt radikal, weil natürliche Sprache jeder versteht.
- **Effizienz:** Statt zehn Klicks reicht eine Anweisung.
- **Barrierefreiheit:** Auch Menschen mit Einschränkungen oder geringen IT-Kenntnissen können komplexe Systeme bedienen.
- **Flexibilität:** Dasselbe Interface kann für unzählige Aufgaben genutzt werden – vom ETL-Skript bis zum Marketingtext.
## Chancen und Risiken
Das bringt viele Vorteile mit sich, die wir alle seit ein bis zwei Jahren spüren. Aber: Kommunikation „wie mit einem Menschen“ bedeutet auch Missverständnisse „wie mit einem Menschen“.
*„Lösche bitte meinen langweiligen Blogbeitrag“* ist sehr viel undeutlicher als
```
rm langweiliger-blogbeitrag.doc
```
– und definitiv Interpretationssache.
Das Verhalten der Maschine kann plötzlich nicht-deterministisch sein und bei gleichen Anfragen Unterschiedliches tun.
## Hybride Ansätze im Entwickleralltag
Dennoch: Gerade aus Sicht eines Analytics-Entwicklers blicke ich positiv auf diese Entwicklung. Von Lochkarten zu Assembler, zu gängigen Programmiersprachen, zu grafischen Low-Code-Baukästen – und nun zu einem reinen Beschreiben von Anforderungen.
Hybride Ansätze halten Einzug in unseren Alltag:
- Tools wie **GitHub Copilot** oder **DBT** verbinden Spracheingabe mit Code-Generierung.
- Erste Plattformen wandeln Prompts in Flowcharts oder Visualisierungen um.
- Hybride Interfaces erlauben es, zwischen Code, Grafik und Sprache zu wechseln – ohne Medienbruch.
## Fazit – und zurück zum Hammer
Mitte November wird es weitere, konkretere (versprochen!) Beiträge zu diesem Thema geben. Wie können grafische ETL-Workflows durch KI-basierte Ansätze abgelöst werden? Warum wird der Code dadurch effizienter? Und wo sind (noch) die Limits?
Und was hat die KI nun mit dem Hammer gemein?
Beide sind Teil der HCI-Forschung – und mit beiden muss man umgehen können. Ansonsten nicht viel. Verzeiht mir also den Clickbait. Ob KI eine ähnliche technologische Explosion auslöst wie das erste menschliche Werkzeug? Wir werden sehen.
## Literatur
- Card, S.K. (Ed.). (1983). *The Psychology of Human-Computer Interaction* (1st ed.). CRC Press.
- Nielsen, J. (1994a). *Enhancing the explanatory power of usability heuristics*. Proc. ACM CHI’94 Conf. (Boston, MA, April 24-28), 152-158.
- Norman, D. A. (2013). *The Design of Everyday Things*. MIT Press.
**Kategorien:** AI & Data Science, Development
---
### [Professioneller Stolz – Qualität, auch wenn keiner hinschaut](https://thecattlecrew.net/2025/09/30/professioneller-stolz-qualitaet-auch-wenn-keiner-hinschaut/)
**Published:** September 30, 2025
**Author:** Stefan Sonner
**Content:**
In Projekten – egal ob im Projektmanagement, in der Softwareentwicklung, im Testing oder in der Systemarchitektur – gibt es einen unsichtbaren Maßstab, der darüber entscheidet, ob wir am Ende stolz auf unsere Arbeit sein können: Qualität.
Wie oft sprechen wir über Termine, Budgets, Liefergegenstände. Selten dagegen über den inneren Anspruch, den wir an unsere Arbeit stellen sollten – ganz unabhängig davon, ob ein Kunde, ein Vorgesetzter oder ein Kollege gerade zusieht.
Was bringt der schönste Projektplan, wenn die Dokumentation niemandem verständlich ist? Was nützt ein pünktliches Meeting, wenn die Architektur dahinter wackelt?
```
„Qualität ist: Es gut zu machen, auch wenn keiner guckt.“ Henry Ford
```
Dieser Satz ist mehr als ein nettes Zitat. Er ist ein Prüfstein für unsere Berufsethik.
## Die 10-Prozent-Regel: Sichtbare Ergebnisse vs. unsichtbare Arbeit
In fast jedem Projekt sind nur etwa 10 % unserer Arbeit unmittelbar sichtbar:
- Das fertige Feature im Sprint-Review
- Die Projektpräsentation beim Steering Committee
- Die Testabnahme durch den Kunden
Die anderen 90 % sind im Verborgenen:
- Die saubere Dokumentation, die später jemandem das Leben leichter macht
- Der durchdachte Code, der wartbar bleibt
- Die sorgfältig gepflegten Testfälle, die Fehler in Zukunft verhindern
- Die gewissenhafte Abstimmung zwischen Teams, die keine sofortigen „Show-Ergebnisse“ bringt, aber Risiken minimiert
## Die unsichtbaren 90 Prozent: Wo sich echter Projekterfolg entscheidet
Genau in diesen unsichtbaren 90 % entscheidet sich, ob ein Projekt nachhaltig erfolgreich ist – oder ob es in ein paar Monaten unter der Last technischer Schulden, Missverständnisse oder unklarer Prozesse zusammenbricht.
## Professioneller Stolz als Kompass für nachhaltige Qualität
Professioneller Stolz bedeutet nicht, stur perfektionistisch zu sein. Es bedeutet:
- Verantwortung für die eigene Arbeit zu übernehmen
- Ehrlich zu sich selbst zu sein, wenn etwas nicht den eigenen Qualitätsmaßstäben entspricht
- Langfristig zu denken, auch wenn der kurzfristige Druck groß ist
Es heißt, die Latte nicht deshalb niedriger zu hängen, weil „es ja keiner merkt“. Denn irgendjemand wird es merken – oft sind es die Kolleginnen und Kollegen im nächsten Projekt, die mit den Folgen leben müssen …
## Qualität betrifft alle: Vom Projektmanagement bis zur Architektur
Qualität ist kein Luxus, den man sich nur leistet, wenn Zeit übrig ist.
Sie ist die Basis für Effizienz, Verlässlichkeit und Vertrauen.
- Projektmanagement: Qualität in Planung und Kommunikation sorgt dafür, dass Entscheidungen auf einer soliden Grundlage getroffen werden.
- Entwicklungsteam: Sauberer Code spart in Zukunft Zeit, Nerven und Kosten.
- Testing: Gründliche Tests verhindern spätere Katastrophen und sichern die Reputation.
- IT-Architects: Eine durchdachte Architektur ist wie ein stabiles Fundament – man sieht es nicht, aber es trägt alles.
## Fazit: Warum die Qualität der unsichtbaren Arbeit bleibt
Der beste Weg, den eigenen professionellen Stolz zu leben, ist simpel:
Arbeite so, dass du auch in einem Jahr noch mit Überzeugung sagen kannst: „Das war mein Werk – und ich stehe dazu.“
Denn am Ende sind es nicht die schnell gelieferten Features oder die pünktlich gehaltenen Meetings, die bleiben – es ist die Qualität der unsichtbaren 90%, die den Unterschied macht.
Oder, um es mit den Worten des eingangs zitierten Satzes zu sagen:
Qualität ist: Es gut zu machen, auch wenn keiner guckt.
Wie gehst du in deinem Projekt mit den unsichtbaren 90 % um? Diskutiere mit mir in den Kommentaren.
**Kategorien:** Development, IT-Security, Sustainability & Awareness
---
### [Proxmox VE: Open-Source-Virtualisierung für digitale Souveränität](https://thecattlecrew.net/2025/09/18/proxmox-ve-open-source-virtualisierung-fuer-digitale-souveraenitaet/)
**Published:** September 18, 2025
**Author:** Jeremy Smeets
**Content:**
Digitale Souveränität – sie ist der Schlüssel zur Unabhängigkeit von Organisationen gegenüber globalen IT-Giganten. Mit **Proxmox VE** steht eine leistungsfähige **Open-Source-Virtualisierungsplattform** bereit, die Offenheit, Sicherheit und Skalierbarkeit vereint. Unternehmen schaffen damit ein stabiles Fundament für nachhaltige Selbstbestimmung, volle Kontrolle über ihre Daten und flexible Zukunftsfähigkeit.
## Digitale Souveränität beginnt bei der IT-Architektur
Souveränität ist ein großes Wort. Eines, das viele für sich beanspruchen und das doch selten greifbar wird, wenn es um konkrete **IT-Architekturen** geht. Zu oft bleibt es in PowerPoint-Folien hängen, während im Backend längst proprietäre Lizenzmodelle, Blackbox-Systeme und globale Abhängigkeiten regieren.
Dabei ist der Begriff aktueller denn je. Was lange wie eine idealistische Forderung wirkte, ist heute ein strategischer Imperativ. Nicht nur im öffentlichen Sektor.
Denn die Realität zeigt: Juristische Kontrolle über Infrastruktur ist nicht selbstverständlich. Als Microsoft jüngst auf Anweisung der US-Regierung den ICC-Chefankläger von der E-Mail-Kommunikation aussperrte, wurde einer breiten Öffentlichkeit bewusst, was **CLOUD Act** und extraterritoriale Gesetzgebung tatsächlich bedeuten. Solche Eingriffe sind keine Ausnahme, sondern systemisch legitimiert und technisch jederzeit möglich, wenn wir die Kontrolle über unsere IT-Landschaft aus der Hand geben.
## Warum Virtualisierung die Grundlage für Unabhängigkeit ist
Ob öffentliche Verwaltung, Forschung, Industrie oder IT-Dienstleister, wer heute **Virtualisierung** einführt, migriert oder weiterentwickelt, steht vor mehr als einer Produktwahl. Es geht um die Frage: Wer kontrolliert, wie meine Systeme laufen, wie sie skaliert werden, wer worauf Zugriff hat und was passiert, wenn ein Anbieter seine Regeln ändert?
### **Virtualisierung bildet den Sockel**
Auf dem Sockel der Virtualisierung laufen Datenbanken, Entwicklerumgebungen, Containerplattformen, Testsysteme, Authentifizierungsdienste und vieles mehr. Wenn dieser Sockel fremdgesteuert ist, etwa durch proprietäre Lizenzzwänge, unklare Jurisdiktionen oder nicht dokumentierte API-Verhalten – dann ist alles darüber automatisch gefährdet.
## Proxmox VE: Offene Alternative zu VMware und Co.
**Proxmox VE** bringt dafür eine seltene Kombination mit: vollständige Offenheit, starke technologische Basis, aktive Community, optionalen Support und die Fähigkeit, mit klassischen Enterprise-Strukturen zu sprechen, ohne sich von ihnen abhängig zu machen.
### Vorteile von Proxmox VE auf einen Blick:
- **Open Source und transparent**: Keine versteckten Lizenzbedingungen oder Blackbox-Komponenten.
- **Alternative zu VMware**: Starke Virtualisierungsfunktionen ohne Abhängigkeit von proprietären Herstellern.
- **Flexible Virtualisierung**: Unterstützung von KVM für VMs und LXC für Container.
- **Integriertes Storage & Backup**: Mit Ceph und ZFS lassen sich hochverfügbare und sichere Umgebungen aufbauen.
- **Keine Telemetrie-Zwänge**: Datenschutz und Unabhängigkeit von externen Cloud-Diensten.
- **Aktive Community & optionaler Enterprise-Support**: Stabile Weiterentwicklung und professioneller Betrieb.
- **Nahtlose Integration**: API-first, Infrastructure-as-Code und volle Dokumentierbarkeit für souveräne IT-Strukturen.
Das System basiert auf bewährten Technologien wie **KVM, LXC, Ceph und ZFS**. Es verzichtet konsequent auf Telemetrie, Cloud-Zwänge oder Lizenzverklausulierungen. Und es erlaubt Organisationen, ihre gesamte Virtualisierungsarchitektur – vom Clusteraufbau über Backup bis zu Monitoring und IAM – dokumentierbar, überprüfbar und reproduzierbar selbst zu gestalten.
[](https://thecattlecrew.net/wp-content/uploads/2025/09/Proxmox-VE-9-0-Metrics.png)Proxmox VE Web Gui – VM Übersicht & Monitoring
## Mehr als nur Container: Proxmox im Spannungsfeld von Legacy und Cloud
Ein häufiger Irrtum in Architekturgesprächen ist die Gleichsetzung von „moderner IT“ mit Kubernetes. Natürlich haben Containerplattformen ihre Berechtigung. Insbesondere dort, wo dynamische Skalierung, Self-Healing und Microservice-Paradigmen sinnvoll sind.
Doch sie lösen nur einen Teil der Herausforderungen. In den meisten Umgebungen existieren weiterhin klassische Workloads: Windows-basierte Fachverfahren, monolithische Datenbanken, sicherheitskritische Legacy-Systeme. Auch moderne Systeme wie GitLab, Keycloak oder Prometheus laufen nicht zwingend containerisiert.
**Proxmox VE ist hier keine Konkurrenz zu Kubernetes – sondern die Basis, auf der Kubernetes sinnvoll betrieben werden kann.** Wer Proxmox als Infrastruktur verwendet, kann Containerplattformen dort ausrollen, wo sie gebraucht werden, ohne dafür seine gesamte Architektur umzustellen oder in Herstellerabhängigkeiten zu geraten.
## Praxisnähe mit echten Erfolgsgeschichten
**Proxmox VE** wird weltweit in unterschiedlichsten Einsatzszenarien genutzt, von Forschungseinrichtungen über Unternehmen bis hin zu Behörden. So konnte etwa ein global agierender Musiksoftware-Hersteller durch den Einsatz von Proxmox-Clustern die Auslastung seiner Systeme optimieren und zugleich hohe Verfügbarkeit sicherstellen. Ein IT-Dienstleister in Hamburg berichtet wiederum von erfolgreichen Migrationen weg von VMware hin zu Proxmox – verbunden mit größerer Unabhängigkeit und reduzierten Betriebskosten.
Weitere Beispiele aus Bereichen wie Bildung, öffentlicher Verwaltung oder dem NGO-Sektor sind auf der Proxmox-Unternehmensseite unter [Success Stories](https://www.proxmox.com/de/ueber-uns/ueber-uns/stories?utm_source=chatgpt.com) dokumentiert. Sie verdeutlichen, wie die Plattform in der Praxis Mehrwerte schafft und Organisationen befähigt, ihre IT-Strukturen nachhaltig souverän auszurichten.
## Souveränität in der Praxis: Transparenz, Exit-Strategien und offene APIs
Eine souveräne Virtualisierungsarchitektur erlaubt es, neue Systeme aufzusetzen, alte zu migrieren, Monitoring zu integrieren, Disaster-Recovery-Strategien umzusetzen und IAM sauber einzubinden, ohne dafür auf proprietäre Portale zugreifen zu müssen.
- Vollständige Audits sind möglich, weil der Quellcode offenliegt.
- Dokumentierte Exit-Szenarien sichern Unabhängigkeit, da keine Lizenzbindungen den Wechsel blockieren.
- APIs, Infrastructure-as-Code und modulare Betriebskonzepte sorgen für Integrationsfähigkeit.
In der Praxis bedeutet das zum Beispiel **spürbare Einsparungen bei Lizenzkosten, eine gesteigerte Audit- und Compliance-Fähigkeit, eine deutliche Reduzierung der Total Cost of Ownership (TCO) sowie die Befähigung interner Teams, die Plattform eigenständig weiterzuentwickeln,** frei von Herstellerabhängigkeiten und ohne Risiko eines Know-how-Verlustes.
## Architektur als kontinuierlicher Prozess
Bei **OPITZ CONSULTING** haben wir ein Vorgehen etabliert, das genau diesen Anspruch aufgreift. Es basiert auf einem zyklischen Modell, das den Aufbau souveräner IT-Strukturen als Prozess versteht, nicht als einmalige Umstellung.
**Define – Design – Deploy – Distribute – Debug – Maintain – Define**
In der Definitionsphase werden bestehende Abhängigkeiten analysiert: Welche proprietären Systeme existieren? Wo ist juristische Kontrolle unklar? Welche Risiken entstehen durch Lock-in oder fehlende Exit-Strategien? Daraus ergeben sich Design-Prinzipien, z. B. Redundanz, Transparenz, Automatisierbarkeit, die in ein konkretes Architekturmodell übersetzt werden.
Die Deployment-Phase bringt diese Architektur in die Realität: Clusteraufbau, Storage, Backup, IAM, Netzwerk, Monitoring. In der Distributionsphase geht es um Wissen: SOPs, Schulungen, Dokumentation. Debugging sorgt für kontinuierliche Verbesserung. Und Maintenance etabliert den laufenden Betrieb auf Basis nachvollziehbarer Regeln, nicht durch Ticket-Magie.
Am Ende beginnt der Zyklus von vorn: **Architektur ist nie fertig, aber sie kann gesund wachsen.**
## Fazit: Mit Proxmox IT-Souveränität und Zukunftssicherheit erreichen
**Proxmox VE** ist nicht die Antwort auf alle Architekturfragen. Aber es ist ein Baustein, der fundamental zur Unabhängigkeit beitragen kann, technisch, rechtlich, organisatorisch.
Wer Proxmox einführt, entscheidet sich nicht nur für ein Virtualisierungsprodukt. Sondern für einen Ansatz, der **digitale Souveränität systemisch ermöglicht**. Gerade in Zeiten geopolitischer Spannungen, unvorhersehbarer Lizenzveränderungen und zunehmender Regulierungsanforderungen wird deutlich:
Selbstbestimmung ist kein Luxus. Sie ist das Betriebssystem einer zukunftsfähigen Organisation.
---
## Mehr zum Thema digitale Souveränität
- [Was bedeutet Digitale Souveränität konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
- [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
- [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
- [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
- [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Kategorien:** Cloud, Infrastructure, IT-Security
---
### [IT-Support in der Industrie: Ohne uns läuft kein Stahl](https://thecattlecrew.net/2025/09/16/it-support-in-der-industrie-ohne-uns-laeuft-kein-stahl/)
**Published:** September 16, 2025
**Author:** Mateusz Mis
**Content:**
Stahlproduktion klingt nach Hochöfen, Funkenflug und tonnenschweren Maschinen. Doch hinter den Kulissen sorgt ein komplexes Netz aus Systemen, Daten und Prozessen dafür, dass alles reibungslos funktioniert – von der ersten Schmelze bis zum fertigen Transport. Ohne diese IT-Infrastruktur würde kein einziger Rohling das Werk verlassen.
Genau hier kommen wir ins Spiel: unser CDS-Team (Customer Domain Support). Wir sind die Feuerwehr, die Detektive und manchmal auch die Kaffeemaschine in einem – immer dann zur Stelle, wenn ein digitales Rädchen klemmt, ein Incident eskaliert oder ein System mitten in der Nacht beschließt, seine eigene Meinung zu haben.
“*Oha… aus Versehen aus 2 Tonnen Stahl plötzlich 10 gemacht?*”
Klingt unmöglich? Nicht bei uns! Manche nennen’s Magie – wir nennen’s **Freitag …**
## Fertigungsleitsysteme: kein Auto, sondern ein Nervensystem
Bei uns heißt das Projekt oft einfach „FLS“ (Fertigungsleitsystem) oder „MES“ (Manufacturing Execution System). Klingt wie ein neues Automodell, ist aber in Wahrheit ein komplexes Geflecht aus Produktions- und Logistiksystemen. Klingt kompliziert? Ist es auch. Genau deshalb gibt es uns.
Ob Incident-Management, Systemadministration, Support für lokale Teams oder schlicht „irgendwas geht nicht, macht mal bitte“ – wir sind mittendrin. Vom Hochofen bis zur LKW-Rampe oder zum Bahnsteig: Wenn irgendwo ein digitales Rädchen klemmt, legen wir los. Mit einem wachen Auge (manchmal auch mitten in der Nacht), analytischem Verstand und oft einer Kaffeetasse in der einen und einer JIRA- und MES-Instanz in der anderen Hand.
## So erklären wir unseren Job
Wie unser Alltag aussieht? Gar nicht so leicht zu beantworten. Im Privatleben bekommen wir oft Fragen, was wir eigentlich machen – und meistens klingt jede Erklärung ein bisschen nach Science-Fiction. Deshalb habe ich das mal an meine Kollegen Adrian und Dominik weitergegeben.
**Was antwortet ihr, wenn euch Freunde oder Familie fragen, was ihr bei eurer Arbeit macht?**
```
Adrian:
Kinder unter 10? – „Ich arbeite am Computer.“
Teenies bis 16? – „Ich mach irgendwas mit IT … und Deutsch.“
Alle zwischen 17 und 50? – „Büro-Ninja im Großkonzern.“
Und Ü50? – „IT für ein Industrieunternehmen,
klingt solide und vertrauenswürdig.“
```
```
Dominik:
„Das hängt vom Tag ab. Manchmal muss ich die Fabrik retten,
manchmal einen Benutzer im System anlegen.“
```
Lustig? Ja. Aber auch ziemlich treffend. Denn unser Job ist schwer auf einen Satz zu bringen – vor allem, weil er so vielseitig ist. Zwischen Tickets, Logfiles und Systemen gleicht kaum ein Tag dem anderen.
## Standard-Incidents? Fehlanzeige.
Ob es so etwas wie einen typischen Incident gibt? Ich frage Matthias, unser wandelndes Wikipedia.
**Gibt’s bei uns sowas wie ein „Standard-Incident“?**
```
Matthias: „Oft gibt es Probleme bei Transporten aller Art.
Viele Systeme kümmern sich um Lagerung,
Verladung und Abstimmung mit der Infrastruktur.
Unser MES vermittelt zwischen diesen Welten.
Wenn das nicht klappt, sind wir gefragt.“
```
Wir sind also zentrale Ansprechpartner für viele Teams, die verschiedene Systeme betreiben. Kein einfacher Job, denn die Vielfalt an Fachlichkeiten sorgt dafür, dass Probleme oft schwer einzugrenzen sind.
## Superkräfte im IT-Support
Sieht ganz so aus, als wäre das kein Job für alle. Deshalb frage ich weiter:
**Welche Superkraft braucht man für diesen Job?**
```
Matthias: „Im MES-Support musst du Hinweise erkennen und Spuren folgen
– das erfordert den Verstand von Batman.
Die Wahl des richtigen Werkzeugs allerdings das Gespür von MacGyver.“
```
Manchmal fühlt sich unser Job tatsächlich an wie eine Mischung aus Supernatural und CSI. Und ja – es passiert, dass sich ein Problem wie von Geisterhand löst. Meistens sind die Enduser glücklich, wir eher misstrauisch.
Deshalb frage ich noch Adrian:
**Hast du schon mal ein Problem gelöst, ohne zu wissen, wie du’s gemacht hast?**
```
Adrian: „Klar, das gibt’s! Oft denke ich:
‚Keine Ahnung, ob das funktioniert
– aber ich probier’s mal.‘
Oder: ‚Darf ich das überhaupt?‘“
```
## Zwischen Minesweeper und MacGyver
Natürlich nutzen wir dafür eine Menge Tools. Manche lieben wir, manche verfluchen wir – brauchen tun wir sie alle. Nach dem letzten gelösten Incident tausche ich mich kurz mit Michal aus – und denke mir: Gut, dass wir so viele Systeme zur Verfügung haben, um ein Problem aus verschiedenen Blickwinkeln zu analysieren.
Ich frage ihn:
**Gibt es ein Tool oder System, das du jeden Tag brauchst – aber ehrlich gesagt am liebsten niemals wiedersehen würdest?**
```
Michal: „Ganz klar: QCS. Ein System mit hundert Tabs
und einem Interface aus dem letzten Jahrzehnt.
Mächtig, ja – intuitiv, eher nicht.“
```
Da kann ich nur zustimmen. Und mein persönlicher Klassiker? Ein Bahn-System, das manchmal aussieht wie eine Runde Minesweeper auf Windows XP … nur in echt.
## Führung im Dauerbetrieb
Aber Technik allein reicht nicht. Hinter den Kulissen braucht es jemanden, der den Überblick behält – und auch bei der fünften Eskalation am Tag Ruhe bewahrt. Also frage ich unseren Teamleiter Thomas:
**Was sind für dich die größten Herausforderungen bei der Führung eines so vielseitigen und verteilten Teams wie CDS?**
```
Thomas: „Die größte Herausforderung ist, trotz räumlicher Verteilung
und 24/7-Betrieb den Teamzusammenhalt zu sichern.
Informationen müssen schnell fließen, Prioritäten klar sein,
und niemand soll das Gefühl haben, allein zu arbeiten.“
```
**Wie hält man dabei Struktur und Motivation hoch?**
```
Thomas: „Das Wichtigste ist für mich, Ruhe und Struktur vorzuleben.
Wir haben klare Abläufe, damit jeder weiß, was im Ernstfall zu tun ist.
Aber genauso wichtig ist der menschliche Umgang: gegenseitiges Vertrauen,
Humor und die Sicherheit, dass man sich aufeinander verlassen kann.
Auch wenn mal fünf ungeplante Themen gleichzeitig auf den Tisch kommen
– wir packen das gemeinsam an.
Diese positive Stimmung und das gute Miteinander im Team sind der Grund,
warum wir trotz Dauerstress motiviert bleiben.“
```
## Fazit: Digitaler Feuerwehrdienst mit Humor
Was Thomas sagt, bringt es auf den Punkt. Unser Alltag lebt nicht nur von Technik, sondern von Teamgeist, Flexibilität und einer guten Portion Humor. Zwischen nächtlichen Incidents, verschwundenen Datenpaketen und Tickets, die sich selbst erledigen, wird es bei uns nie langweilig.
Wir sind IT-Support, Systemanalysten und digitale Feuerwehr zugleich – und dabei immer auf der Suche nach der richtigen Spur im System. Am Ende machen nicht nur Tools und Prozesse den Unterschied, sondern vor allem die Menschen, die sich aufeinander verlassen können.
Und das ist auch gut so. Denn ohne uns würde der Stahl tatsächlich nicht laufen.
**Kategorien:** Development, Infrastructure
**Schlagwörter:** agilität, Agility, Analytics, Bewusste IT, communication, German, Softwarenentwicklung, Teams, Zusammenarbeit
---
### [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Published:** September 2, 2025
**Author:** Aaron Kreis
**Content:**
### **Warum Datenhoheit über den Erfolg von KI entscheidet**
Künstliche Intelligenz (KI) wird nicht aus dem Nichts erschaffen, sie lebt von Daten. Ohne umfangreiche und qualitativ hochwertige Beispiele kann ein neuronales Netz keine Sprache verstehen, keine Objekte erkennen und keine Handlungsempfehlungen geben. Für Unternehmen bedeutet das: Wer über die eigenen Daten nicht souverän verfügt, schenkt fremden Plattformen das Rohöl der digitalen Wirtschaft.
Der Begriff Datensouveränität beschreibt die rechtliche und faktische Kontrolle über Datenbestände. Er geht über klassischen Datenschutz hinaus. Datenschutz will sicherstellen, dass personenbezogene Informationen nicht missbraucht werden und dass die Grundrechte Betroffener gewahrt bleiben. Datensouveränität hingegen fragt, wem die Daten gehören, wer sie wie nutzen darf. Während Datenschutz die Privatsphäre schützt, ist Datensouveränität eine wirtschaftliche und strategische Frage. Sie bestimmt, ob Daten zu einem Wettbewerbsvorteil werden oder unbemerkt in die Wertschöpfung anderer fließen.
### **Warum Daten für KI systemrelevant sind**
Die Frage der Datensouveränität zeigt sich besonders deutlich beim Einsatz von KI, denn deren Leistungsfähigkeit hängt unmittelbar von den verfügbaren Daten ab. KI-Modelle lernen aus vielen Beispielen, welche Zusammenhänge sich in der Realität verbergen, und übertragen diese Muster auf neue Situationen. Die Menge und vor allem die Qualität der Trainingsdaten sind dabei entscheidend. Große generative Modelle wie zum Beispiel Sprachmodelle benötigen Milliarden von Parametern, um natürliche Sprache fließend zu erzeugen.
Bei solchen Modellen hängt die erforderliche Datenmenge von der Modellgröße, der konkreten Aufgabe und der Vielfalt der Inhalte ab. Fehlende oder minderwertige Daten lassen sich nicht einfach durch größere Mengen ausgleichen. Im Gegenteil sie verstärken Fehler. Für Unternehmen bedeutet das, dass nicht allein der Zugang zu großen Datenmengen ausschlaggebend ist, sondern die Fähigkeit, relevante, saubere und konsistente Datenbestände gezielt für den Aufbau von KI zu nutzen. Wer hier die Kontrolle verliert, riskiert fehlerhafte Ergebnisse, steigende Kosten und Abhängigkeiten von fremden Plattformen.
### **Herausforderungen auf dem Weg zur Datensouveränität in der KI**
Der Aufbau von Datensouveränität für KI erfordert weit mehr als den bloßen Zugriff auf große Datenmengen. Der Weg zu souveränen KI-Systemen ist voller Stolpersteine.
Die folgenden Probleme treten häufig auf und sollten frühzeitig adressiert werden:
- **Verzerrungen**: Verzerrungen können in jeder Phase der Entwicklung einer Künstlichen Intelligenz entstehen. Bereits vorhandene gesellschaftliche Ungleichheiten in den Daten werden oft als normal übernommen und im Modell fortgeführt. Beim Sammeln und Beschriften der Daten können persönliche oder kulturelle Vorurteile einfließen, und wenn bestimmte Gruppen in den Trainingsdaten zu selten vorkommen, lernt das Modell vor allem die Muster der Mehrheit. Auch die mathematische Optimierung kann dazu führen, dass Minderheiten weniger berücksichtigt werden, was zu schlechteren Prognosen oder Empfehlungen für diese Gruppen führt.
- **Undurchsichtige Modelle**: Viele KI-Modelle wirken wie Black Boxes. Zwar lassen sich ihre Berechnungen theoretisch offenlegen, doch die Vielzahl an Parametern und komplexen Wechselwirkungen macht es für Menschen praktisch unmöglich, den genauen Entscheidungsweg vollständig zu verstehen. Ohne zusätzliche Methoden zur Erklärbarkeit ist schwer zu erkennen, welche Faktoren eine Entscheidung beeinflusst haben und ob diese fair ist. Mehr Transparenz schafft Vertrauen und ermöglicht Kontrolle durch Anwender und Aufsichtsstellen.
- **Optimierungsziele ohne gesellschaftliche Rückkopplung**: Wenn eine KI nur darauf ausgerichtet ist, schnell und effizient messbare Erfolge zu erzielen, wie etwa möglichst viele Nutzer zu einem Kauf zu bewegen, kann sie dabei aggressiv personalisierte Werbung an besonders verletzliche Gruppen ausspielen, um die Kaufwahrscheinlichkeit zu erhöhen, auch wenn das ethisch problematisch ist.
- **Explosion der Datenquellen**: Unternehmen erzeugen heute Daten auf vielen verschiedenen Plattformen, etwa in Cloud-Diensten, Software-as-a-Service-Anwendungen und sozialen Netzwerken. Diese Daten liegen oft verstreut an unterschiedlichen Orten und werden nicht in einem gemeinsamen System zusammengeführt. Eine sogenannte Datenkarte ist eine Übersicht, die zeigt, an welchen Stellen im Unternehmen Daten entstehen, wer sie verwendet und ob sie unterwegs verändert werden.
Wenn Daten weder verstanden noch auffindbar oder kontrollierbar sind, werden sie nicht zum Vorteil, sondern zur potenziellen Gefahr.
### **Die Datenökonomie boomt**
Trotz der zuvor beschriebenen Herausforderungen beim Umgang mit Daten wächst der Markt rund um Künstliche Intelligenz rasant. Unternehmen investieren Milliarden in Management, Aufbereitung und Qualitätssicherung, um Daten verfügbar, nutzbar und sicher zu machen.
Laut einem Bericht von Fortune Business Insights betrug der weltweite KI Markt 2024 rund 233,46 Milliarden USD und soll bis 2032 auf 1.771 Milliarden USD wachsen. Gleichzeitig vergrößern sich auch die Märkte für Datenmanagement, Datenlabeling und Trainingsdatensätze: Der Markt für KI-Datamanagement hatte 2023 ein Volumen von 25,50 Milliarden USD und wird bis 2030 auf über 104,00 Milliarden USD steigen. Services zum Labeln von Daten, die essenziell für die Überwachung des Lernens sind, erreichten 2024 eine Größe von 18,60 Milliarden USD und dürften bis 2030 auf 57,60 Milliarden USD anwachsen. Die Nachfrage nach synthetischen Daten nimmt ebenfalls zu. Ein Markt von 0,51 Milliarden USD (2025) wächst bis 2030 voraussichtlich auf 2,67 Milliarden USD, da Unternehmen anonymisierte und realistische Datensätze für datenschutzkonforme Trainingszwecke benötigen.
Diese Zahlen zeigen: Daten sind das neue Rohmaterial. Unternehmen investieren Milliarden in Datenaufbereitung, Annotation und Qualitätssicherung. Gleichzeitig ist die Verfügbarkeit hochwertiger Daten entscheidend für die Leistungsfähigkeit von KI-Systemen.
### **Wachstumsmärkte: Datenmanagement, Annotation & synthetische Daten**
Die KI-Branche erlebt derzeit eine starke Konsolidierung. Große Plattformen kaufen spezialisierte Datenunternehmen auf, um sich den Zugang zu hochwertigen Datensätzen zu sichern. Ein Beispiel ist Microsofts Übernahme des Sprach- und Spracherkennungsunternehmens Nuance für 19,7 Milliarden USD.
Gleichzeitig boomt der Markt für synthetische Daten. Dabei erzeugen generative Modelle künstliche Datensätze, die dieselben statistischen Eigenschaften wie reale Daten besitzen, aber keine persönlichen Informationen enthalten. Solche Daten erlauben es, vertrauliche oder seltene Muster zu lernen, ohne Originaldaten preiszugeben. Diese Daten wahren die Privatsphäre, sind strukturell identisch mit der Vorlage und enthalten keine personenbezogenen Daten. Dies ermöglicht die sichere Entwicklung und das Testen von KI Lösungen.
Der Wettbewerb um Fachkräfte im Bereich KI hat sich zu einer intensiven Talentejagd entwickelt. Große Technologiekonzerne sichern sich nicht nur Unternehmen mit wertvollen Datensätzen, sondern konkurrieren auch um die besten Köpfe. Medien berichten, dass Microsoft Fachleute aus dem Umfeld von Apple abgeworben hat und sie mit Millionengehältern sowie umfassenden Aktienpaketen lockt. Die gebotenen Summen erinnern an Ablösesummen im Profisport, denn gesucht sind vor allem Spezialisten für Sprachverarbeitung, maschinelles Lernen und Computer Vision. Solche Abwerbungen werden mit langfristigen Bonusprogrammen und Forschungsbudgets begleitet.
### **Welche Daten sind schützenswert?**
Mit dem Wachstum der Datenökonomie rückt auch die Frage in den Vordergrund, welche Daten für Unternehmen besonders kritisch sind und daher besonderen Schutz erfordern. Nicht alle Daten sind gleich kritisch. Schützenswert sind:
- **Personenbezogene Daten**: Angaben, die sich einer Person zuordnen lassen, etwa Name, Adresse, biometrische Daten, Gesundheitsdaten oder Finanzinformationen.
- **Geschäftsgeheimnisse und Forschungsdaten**: Produktrezepte, Algorithmen, Marktanalysen oder Forschungsergebnisse, deren Verlust den Wettbewerbsvorteil mindern würde.
- **Sensor und Produktionsdaten**: Daten aus Maschinen können Rückschlüsse auf Produktionsprozesse geben und sind daher schützenswert.
- **Kombinierte Daten**: Durch die Verknüpfung verschiedener Quellen können scheinbar harmlose Daten Hinweise auf Konsumverhalten oder politische Einstellungen liefern. Daher sollten Unternehmen immer prüfen, welche Schlüsse aus ihren Daten gezogen werden können.
Für echte Datensouveränität reicht es nicht, große Datenmengen zu besitzen. Entscheidend ist, ob diese Daten für die jeweilige KI-Anwendung relevant, konsistent und nutzbar sind. Ungefilterte Masse kann im schlimmsten Fall die Modellqualität verschlechtern. Wert entsteht erst, wenn Daten gezielt ausgewählt, strukturiert und in einen sinnvollen Kontext gebracht werden. Genau hier setzt das Konzept von Smart Data an.
### **Smart Data statt Big Data: Qualität schlägt Quantität**
Smart Data steht für den bewussten Umgang mit Daten. Im Mittelpunkt steht nicht die schiere Menge, sondern die Relevanz und Qualität der Informationen. Für KI bedeutet das, dass Datensätze gezielt auf die zu lösende Aufgabe zugeschnitten, bereinigt und angereichert werden. So entstehen Datenbestände, die aussagekräftig und effizient nutzbar sind.
Während Big Data häufig als Sammelbegriff für große und vielfältige Datenmengen dient, konzentriert sich Smart Data auf gezielte Auswahl, saubere Struktur und eindeutige Zuordnung. Beispielsweise kann ein kleiner, aber sorgfältig gelabelter Datensatz ein Sprachmodell besser trainieren als unstrukturierte Terabytes voller irrelevanter Inhalte.
Der Mehrwert von Smart Data liegt in der klaren Zielorientierung. Daten werden so gefiltert, dass sie nur die Informationen enthalten, die für eine konkrete KI-Aufgabe wichtig sind. Sie sind konsistent, aktuell und nachvollziehbar, was nicht nur die Modellleistung verbessert, sondern auch die Einhaltung von Compliance- und Datenschutzvorgaben erleichtert. Für Unternehmen bedeutet das: Wer Smart Data beherrscht, erzielt präzisere Ergebnisse, spart Rechenressourcen und wahrt gleichzeitig die Kontrolle über seine wertvollsten Datenbestände.
Damit aus Smart Data ein strategischer Vorteil wird, braucht es technische Konzepte, die Unternehmen die volle Kontrolle über ihre Daten sichern, auch wenn diese für den Einsatz von KI verarbeitet oder geteilt werden.
### **Technische Schlüsselkonzepte für Datensouveränität**
Technische Konzepte für mehr Datensouveränität sind wichtig, weil sie es ermöglichen, KI-Systeme zu nutzen, ohne die Kontrolle über sensible Daten zu verlieren. KI benötigt große Mengen an Informationen, um zuverlässig zu arbeiten, doch viele davon sind vertraulich oder unterliegen strengen Datenschutzregeln. Mit den folgenden Verfahren können diese Daten sicher genutzt werden, ohne sie ungeschützt weiterzugeben.
- **Föderiertes Lernen:** Beim Föderierten Lernen werden die Daten nicht zu einem zentralen Server geschickt. Statt die Daten zu übertragen, werden die Berechnungen direkt vor Ort auf den vorhandenen Daten durchgeführt. Anschließend werden nur die daraus resultierenden aktualisierten Modellparameter weitergegeben. So können beispielsweise mehrere Krankenhäuser ihre Diagnosesysteme gemeinsam verbessern, ohne Patientendaten weiterzugeben.
- **Self Sovereign Identity:** Self Sovereign Identity bedeutet, dass Nutzer ihre digitale Identität in einer eigenen elektronischen Brieftasche, einer sogenannten Wallet, verwalten. Sie entscheiden selbst, welche Informationen sie preisgeben. In einer Onlineplattform könnte sich ein Nutzer so als volljährig ausweisen, ohne seinen vollständigen Namen oder seine Adresse offenlegen zu müssen.
- **Data Trusts:** Ein Data Trust ist eine treuhänderische Struktur, bei der Datenbesitzer die Verwaltung ihrer Daten an eine unabhängige Stelle übertragen, die im Interesse aller Beteiligten handelt. Mehrere Krankenhäuser könnten so Patientendaten in anonymisierter Form bündeln, um gemeinsam medizinische Forschung zu betreiben. Der Treuhänder entscheidet, wer auf welche Daten zugreifen darf, und sorgt für Transparenz und faire Nutzung.
- **Differenzielle Privatsphäre:** Bei der Differenziellen Privatsphäre wird den Daten gezielt statistisches Rauschen hinzugefügt. Dadurch können Analysen durchgeführt werden, ohne einzelne Personen identifizieren zu können. Ein Beispiel ist die Auswertung von Bewegungsdaten einer Fitness App, um allgemeine Trends zu erkennen, ohne exakte Routen einzelner Nutzer zu speichern.
- **Homomorphe Verschlüsselung:** Homomorphe Verschlüsselung ermöglicht es, Berechnungen auf verschlüsselten Daten durchzuführen, ohne diese zu entschlüsseln. Ein einfaches Beispiel ist eine Bank, die prüfen möchte, ob ein Kunde für einen Kredit infrage kommt. Der Kunde sendet seine Einkommens- und Ausgabedaten in verschlüsselter Form an die Bank. Die Bank führt dann spezielle mathematische Berechnungen direkt auf diesen verschlüsselten Daten aus, um zum Beispiel das Verhältnis von Einnahmen zu Ausgaben zu bestimmen. Das Ergebnis dieser Berechnung bleibt ebenfalls verschlüsselt und wird erst vom Kunden entschlüsselt. So kann die Bank die Entscheidung über den Kredit treffen, ohne jemals die genauen Beträge im Klartext zu sehen.
- **Blockchain:** Die Blockchain dient als fälschungssicheres, verteiltes Register, in dem Datenzugriffe und Transaktionen dauerhaft gespeichert werden. Dadurch lässt sich jederzeit nachvollziehen, wer wann auf welche Daten zugegriffen hat. In der Lebensmittelindustrie kann so die gesamte Lieferkette dokumentiert und die Herkunft eines Produkts überprüft werden.
Diese Techniken zeigen, dass Datenschutz und der Einsatz von KI sich nicht ausschließen. Richtig kombiniert ermöglichen sie eine verantwortungsvolle Nutzung von Daten, ohne deren Souveränität zu gefährden. Doch technische Lösungen allein reichen nicht aus. Damit der verantwortungsvolle Umgang mit Daten und KI verbindlich gewährleistet ist, braucht es klare gesetzliche Rahmenbedingungen.
### **Warum klare Regeln für Künstliche Intelligenz unverzichtbar sind**
Regulierungen im Bereich Künstliche Intelligenz sind entscheidend, um den technologischen Fortschritt in sichere und verantwortungsvolle Bahnen zu lenken. Ohne klare Vorgaben könnten KI-Systeme eingesetzt werden, die Menschen gezielt manipulieren, diskriminieren oder ihre Privatsphäre massiv verletzen. Ein Negativbeispiel ist die Kritik an Elon Musks KI „Grok“, die Berichten zufolge so angepasst wurde, dass sie Musks persönliche Sichtweisen stärker wiedergibt und bei kontroversen Themen seine Position bevorzugt darstellt.
Positivbeispiele für den Schutz der Bürgerrechte gibt es ebenfalls: Dänemark arbeitet an einem Gesetz, das seinen Bürgern das Urheberrecht an ihrem eigenen Gesicht, ihrer Stimme und anderen persönlichen Merkmalen zusichert. Damit soll verhindert werden, dass Bilder oder Audioaufnahmen ohne Zustimmung für KI-Trainings und Deepfakes genutzt werden.
In einer Welt ohne solche Regeln bestünde die Gefahr, dass wirtschaftliche Interessen und kurzfristige Effizienzgewinne über den Schutz von Grundrechten und gesellschaftlichen Werten gestellt werden. Aus genau diesem Grund wurden Regulierungen wie der Europäische AI Act, die Datenschutz Grundverordnung (DSGVO) und die Norm ISO/IEC 42001 ins Leben gerufen. Sie sollen Innovation fördern, Risiken minimieren, Missbrauch verhindern und das Vertrauen der Öffentlichkeit in KI stärken.
### **Fazit: Datensouveränität als strategischer Wettbewerbsvorteil**
Datensouveränität entscheidet über den Erfolg von Künstlicher Intelligenz. Ohne qualitativ hochwertige Daten bleibt jedes Modell fehleranfällig, ohne Kontrolle über diese Daten verlieren Unternehmen Gestaltungsmacht und Wertschöpfungspotenzial und ohne rechtliche wie organisatorische Verankerung gehen Chancen verloren. Wer KI verantwortungsvoll einsetzen will, muss daher technische, rechtliche und strategische Fragen gemeinsam betrachten.
Es zeigt sich, dass für leistungsfähige KI nicht Masse, sondern gezielte Qualität der Daten ausschlaggebend ist. Gleichzeitig wächst rund um Datenaufbereitung, Annotation und synthetische Datensätze ein milliardenschwerer Markt, der Chancen, aber auch neue Risiken schafft. Unternehmen stehen vor der Aufgabe, nicht nur Datenbestände aufzubauen, sondern diese auch zu schützen, zu strukturieren und im Sinne von Smart Data gezielt nutzbar zu machen.
Technische Konzepte wie föderiertes Lernen, homomorphe Verschlüsselung oder differenzielle Privatsphäre ermöglichen es, sensible Informationen in KI-Anwendungen einzubringen, ohne die Kontrolle zu verlieren. Doch Technik allein reicht nicht. Erst klare Regeln wie der AI Act, die DSGVO oder ISO-Normen schaffen den Rahmen, in dem Innovation und Verantwortung zusammengehen.
Damit wird Datensouveränität zu einer Führungsaufgabe. Sie verlangt nach rechtlichen Grundlagen, gelebter Verantwortung, technologischer Kompetenz und einer Unternehmenskultur, die Daten nicht als Nebenprodukt, sondern als zentrales Kapital behandelt. Wer frühzeitig in diese Fähigkeiten investiert, stärkt Vertrauen bei Kunden und Partnern, reduziert Risiken, erhöht die eigene Unabhängigkeit und erschließt sich neue Wertschöpfungspotenziale.
Datensouveränität ist damit kein Nebenaspekt der Digitalisierung, sondern ein strategischer Kernfaktor im globalen Wettbewerb um KI.
---
## Alle Artikel zum Thema digitale Souveränität
- [Was bedeutet Digitale Souveränität konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
- [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
- [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
- [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
- [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Kategorien:** AI & Data Science, IT-Security, Sustainability & Awareness
---
### [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
**Published:** Juli 1, 2025
**Author:** Andreas Lorenz
**Content:**
Dies ist der zweite Beitrag der Blogserie zur Digitalen- bzw. Datensouveränität.
Lies gerne auch: Teil 1: [Was bedeutet Digitale Souveränität](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
## Vorab: Keine Blaupause, kein Standardweg
Bevor es konkret wird, sollten wir uns über eines klar werden: In den meisten Fällen lässt sich Datensouveränität nicht einfach in den Warenkorb legen oder als Komplettpaket einkaufen.
Zwar gibt es seit einiger Zeit erste Produkte und Dienste, die echte Alternativen versprechen – etwa durch offene Standards, europäische Hosting-Standorte oder transparente Geschäftsmodelle. Doch in der Breite bleibt der Markt noch schwierig zu durchschauen.
Gerade aktuell sprießen neue Angebote rund um „souveräne Cloud“ wie Pilze aus dem Boden – insbesondere von großen Tech-Anbietern, die auf politischen Druck reagieren. Doch oft bleibt der Begriff ein Etikett, während das grundlegende Abhängigkeitsverhältnis zum Dienstanbieter bestehen bleibt.
## Die richtige Strategie
Ich halte es für sinnvoll, zunächst noch einmal einen Schritt zurückzutreten und das große Ganze zu betrachten – insbesondere die strategische Dimension der digitalen- bzw. Datensouveränität.
Die Debatte wird derzeit leider oft auf eine rein technische Ebene reduziert: als müsste Europa „nur“ eigene Produkte entwickeln oder – auf Unternehmensebene – technische Systeme austauschen und Daten zurück ins eigene Rechenzentrum holen. Ich will gar nicht in Abrede stellen, dass solche Maßnahmen sinnvoll sein können – möglicherweise sind sie langfristig sogar notwendig. Aber: Diese Entscheidungen bringen in der Regel erhebliche Herausforderungen mit sich (mehr dazu später).
Daher lohnt ein kurzer Blick zurück zur eigentlichen Frage: Was genau bedeutet Datensouveränität?
Sowohl für Unternehmen wie auch für Privatpersonen heißt es vor allem: zu jeder Zeit zu wissen, wo die eigenen Daten liegen, wer darauf zugreifen kann – und im Zweifel wieder selbst die Kontrolle übernehmen zu können. Es geht darum, sich nicht in einseitige Abhängigkeiten zu begeben, die später kaum noch aufzulösen sind.
Dabei geht es nicht primär um Technik – sondern um Strategie.
Die zentrale Frage lautet: Wie stelle ich sicher, dass ich echte Wahlfreiheit habe – heute und auch in Zukunft?
Hier sind zumindest drei Elemente sehr wichtig:
- **Offene Standards**, die es ermöglichen, Daten portabel zu halten und Systeme verschiedener Anbieter miteinander zu verbinden.
- **Faire Wettbewerbsbedingungen**, in denen Qualität und Nutzen entscheiden – wo man Systeme unterschiedlicher Anbieter frei wählen und kombinieren kann.
- **Transparenz**, damit klar ist, wie Systeme funktionieren und wer Zugriff hat – für Entscheidungen auf Basis von Fakten, nicht von Versprechungen.
---
### Ist Open Source das Allheilmittel?
Oft lese ich, dass digitale Souveränität nur mit Open Source möglich sei – und ja, offene Software kann ein starker Hebel sein. Sie schafft Transparenz, ermöglicht Kontrolle über den Quellcode und erlaubt flexible Anpassungen an die eigenen Anforderungen.
Aber Open Source ist kein Selbstläufer. Wer diesen Weg wählt, übernimmt ggfs. auch Verantwortung – für Wartung, Sicherheit und Weiterentwicklung. Und nicht jede Open-Source-Lösung ist automatisch souverän: Es kann an professioneller Unterstützung, strategischer Reife oder langfristiger Verlässlichkeit fehlen.
**Schlussendlich** ist eines klar: Wer den Kurs ändern will, muss zuerst die eigene Position kennen. Digitale Souveränität beginnt nicht mit einem Wechsel des Systems – sondern mit dem Blick auf das eigene Fundament.
Legen wir los – mit der Standortbestimmung.
---
## Kapitel 1: Standortbestimmung – Wo bin ich abhängig?
Ich halte die Standortbestimmung für einen der wichtigsten Schritte! Der Umfang der Aufgabe variiert aber stark, je nachdem, welches Ziel man verfolgt. Will man z.B. die Hoheit über die eigenen digitalen Bilder aus der Cloud von Apple oder Google zurückgewinnen, dann ist dies viel einfacher umgesetzt, als wenn man im Unternehmen „digitale Workflows“ in ein neues System umziehen will.
### Warum dieser Schritt so wichtig ist
Bevor du losläufst, musst du wissen, wo du stehst. Das klingt banal – ist aber in der digitalen Welt komplexer, als es scheint. Denn Abhängigkeiten sind oft unsichtbar, verzweigt oder unterschätzt.
### Die zentrale Aufgabe
Fragen zur Selbstanalyse:
- Welche Tools nutze ich – privat oder beruflich? E-Mail, Office, Cloudspeicher, Messenger, Buchhaltung, CRM, Zeiterfassung usw.
- Wie kritisch wäre ein Ausfall eines Systems , bzw. was passiert, wenn der Dienst morgen nicht mehr verfügbar ist?
Viel dreht sich um meine Daten
- Welche Daten werden verarbeitet?
- und wo werden sie gespeichert?
Lokal? In der Cloud? Auf Servern Dritter? In welchem Land?
- Welche Daten sind für mich oder für mein Unternehmen besonders wertvoll?
- Wie komme ich an meine Daten – exportierbar, dokumentiert, wiederverwendbar?
**Tipp** Viele der Informationen können in Unternehmen z.B. als Teil einer Backup- & Recovery-Strategie schon vorhanden sein.
### Beispiel
Das Umziehen eines Mail-Accounts – Was auf den ersten Blick einfach wirkt, kann bei genauerem Hinsehen ein komplexer Migrationsprozess sein – gerade, wenn der Account seit Jahren genutzt wird oder geschäftlich relevant ist.
**1. Bestandsaufnahme**
Fragestellung: Welche Daten liegen im Account?
– E-Mails, Kontakte, Kalender, Notizen, Aufgaben, ggf. Chatverläufe
– Archivordner, Weiterleitungen, Filterregeln
**2. Optionen für den Datenexport**
Fragestellung: Wie komme ich an meine Daten?
– Kann ich meine Mails als Standardformat (z.B. .eml, .mbox, .pst) exportieren?
– über wieviel Daten sprechen wir: Ist es 1 oder 100 GB oder vielleicht noch viel mehr?
– Lassen sich Kontakte und Kalender im offenen Format (z.B. vCard, .ics) sichern?
**3. Analyse der Abhängigkeiten**
Greifen weitere Systeme oder Tools auf den Account zu?
– Zwei-Faktor-Authentifizierung (z.B. für Banking, Cloudspeicher, Social Media)
– Wo ist der Domainname für meine Mail Adresse registriert?
– kann ich meine Mail Adresse einfach mitnehmen?
– Wenn nicht: wird die Mail Adresse in anderen Systemen genutzt,
z.B. als Recovery Option für einen Systemzugang
– mit welchen Mail Clients soll auf den Account zugegriffen werden (Desktop, Mobil …)
– Login via E-Mail bei anderen Diensten
### Bei besonders großen Umstellungen
Insbesondere in großen Unternehmenskontexten können weitere Informationen sehr wichtig sein:
- Welche Schnittstellen bestehen zu anderen Systemen?
- Welche Daten fließen ab und welche Daten kommen von anderen Systemen
- Welche Protokolle werden verwendet (z.B. REST, SOAP, ftp) und wird Verschlüsselung eingesetzt?
- Welche Datenformate werden genutzt: JSON, XML, CSV-Exporte etc.
- Gibt es Abhängigkeiten zu Dritten, die man nicht auf dem Schirm hat? Dies könnte z.B. ein eingebundener Service sein, um automatisiert im Hintergrund Dokumente oder gar Rechnungen zu erstellen und via e-Post zu versenden.
> Je tiefer man in diese Analyse einsteigt, desto deutlicher wird:
> Die Aufgabe ist komplex – aber machbar, wenn man sie systematisch angeht.
### Unterstützung durch Tools
Bei besonders großen Umstellungen ist es sinnvoll, Tools für die Inventarisierung der IT Systemlandschaft zu nutzen. Dies können einfache Worksheets (eher bekannt als Excel) sein oder kann eine Enterprise-Architecture Management (EAM) Lösung sein. So hatte ich 2022 für diese Aufgabe bei einem größeren Konzern LeanIX verwendet. Ein sehr mächtiges aber auch kostenintensives Werkzeug.
## Kapitel 2: Ziele setzen – Schritt für Schritt
Hast du deine digitale Landschaft durchdrungen, kommt der nächste wichtige Schritt:
**Ziele definieren.**
### Was du jetzt tun solltest:
- **Wähle einen Einstiegspunkt.**
Starte mit einem System, das z.B. überschaubar ist oder bei dem Du den größten Nutzen siehst.
Wichtig: Vermeide es, an vielen Baustellen gleichzeitig zu arbeiten.
- Benenne Dein Ziel für das System. Willst Du eine Software gegen eine neue Lösung austauschen oder reicht es vielleicht schon, vertraglich mit dem Anbieter eines Systems zu verhandeln und die Zusicherung zu erhalten, wie Du im Fall der Fälle an Deine Daten gelangst.
- Erstelle Dir einen Umsetzungsplan und überlege welche Schritte nötig sind?
- Wenn Du einen Systemwechsel anstrebst, dann solltest Du unbedingt (wenn es möglich ist) eine Übergangsphase haben, wo sowohl das alte wie auch das neue System verfügbar sind.
Beispiel Handywechsel: Das alte Gerät noch ein paar Tage behalten und erst dann löschen und abgeben, wenn sicher ist, dass das neue Gerät alle Zugänge hat.
### Mein Tipp:
Arbeite mit einem klaren Fahrplan – am besten schriftlich. Wie ein gutes Rezept in der Küche hilft es, Fehler frühzeitig zu erkennen und nicht planlos vorzugehen.
Und wenn du dir unsicher bist: Hol dir Expertise dazu. Gerade bei sensiblen Systemen ist eine zweite Meinung oft Gold wert.
## Lust auf mehr?
Die gute Nachricht: Ich konnte mittlerweile auch einige Kollegen gewinnen, die ebenfalls zu dieser Blogserie beitragen werden und technisch sehr visiert sind. Dann geht es z.B. um Architekturvorgaben und technische Lösungen:
**Hier geht es weiter zu Teil 3**, den mein Kollege Lienhard Siegmund geschrieben hat:
[Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/ "Wie kompatibel sind Hyperscaler mit EU-Vorgaben?")
---
## Alle Artikel zum Thema Datensouveränität
- [Was bedeutet Digitale Souveränität konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
- [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
- [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
- [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
- [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Kategorien:** Development
---
### [Digitale Souveränität – Was bedeutet das konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
**Published:** Juni 11, 2025
**Author:** Andreas Lorenz
**Content:**
Die Smartwatch weckt uns morgens mit einem sanften Vibrieren. Im Halbschlaf greifen wir zum Smartphone – die ersten Push-Nachrichten rauschen über den Bildschirm. Noch vor dem Frühstück ploppen die ersten Termine auf, der digitale Kalender ist bereits ein paar Schritte voraus, und beim Kaffee wird Musik direkt aus der Cloud gestreamt.
Im Büro geht es nahtlos weiter: Outlook, Chats und Videokonferenzen via Microsoft Teams, Anwendungen laufen über die Cloud – als Software-as-a-Service, flexibel, ortsunabhängig und ständig aktualisiert. Digitale Workflows und vernetzte Tools strukturieren den Arbeitstag.
Wir leben in einer Welt, in der Daten fließen wie Strom – unsichtbar, aber allgegenwärtig. Und doch machen sich nur wenige Gedanken darüber, woher dieser Strom kommt, wer den Schalter in der Hand hält – und was passiert, wenn jemand den Stecker zieht.
> Was haben die meisten digitalen Dienste heute gemeinsam?
Sie laufen auf Servern von nicht-EU-Anbietern – unabhängig davon, ob diese physikalisch in Europa, den USA oder in China stehen.
Damit entziehen sie sich unserer direkten Kontrolle. So unterliegen Server von US-Anbietern dem US-amerikanischen Recht, insbesondere dem CLOUD Act, der US-Behörden weitreichenden Zugriff auf gespeicherte Daten erlaubt – auch außerhalb der USA.
> Ist das ein Problem?
> Schauen wir erst einmal weiter …
## Die Risiken einer digitalen Abhängigkeit sind vielfältig
### Privatsphäre war gestern
Seit unsere Phones „smart“ geworden sind, hat sich auch das Geschäftsmodell vieler digitaler Dienste grundlegend verändert: Bezahlt wird nicht mit Euro oder Dollar – sondern mit persönlichen Daten: was auf den ersten Blick kostenlos erscheint, hat einen versteckten Preis: Suchanfragen, Chats, Kontakte, Aufenthaltsorte, Verhaltensmuster und Interessen – all das wird kontinuierlich erfasst, analysiert und kommerziell verwertet.
### Reichweite erzeugt Sichtbarkeit
Neben dem Verkauf persönlicher Daten an die Werbeindustrie scheint sich in den letzten Jahren ein weiterer Trend zu verstärken: Immer mehr Menschen nutzen Social-Media-Plattformen als primäre Nachrichtenquelle – und verdrängen dabei, dass sie nur das sehen, was ihnen der Algorithmus vorsortiert: entweder, weil es vermeintlich zu ihren Interessen passt – oder, auch das kommt immer häufiger vor, um gezielt Meinung zu beeinflussen.
Wer die Kontrolle über die Informationskanäle hat, kann auch öffentliche Stimmungen lenken, polarisieren – und Zustimmung für bestimmte politische Narrative erzeugen. Influencer, Plattformbetreiber und Content-Kreateure monetarisieren Aufmerksamkeit – und damit auch Meinungsmache:
Was Reichweite erzeugt, bekommt Sichtbarkeit. Was sichtbar ist, beeinflusst öffentliche Wahrnehmung. Ein subtiler, aber mächtiger Einfluss auf demokratische Willensbildung ebenso wie auf unser gemeinsames Werteverständnis.
### Daten sind das Öl der digitalen Gegenwart
Disruptive Geschäftsmodelle – von Airbnb über Spotify bis Amazon – zeigen, wie Datenhoheit über ganze Branchen entscheiden kann. Wer die Daten besitzt, kontrolliert die Schnittstellen zum Kunden, erkennt Muster schneller, automatisiert Entscheidungen – und kann Märkte aufrollen, noch bevor traditionelle Anbieter reagieren.
Und die Entwicklung endet nicht bei Plattformökonomie: Daten sind auch der Treibstoff für KI-getriebene Geschäftsmodelle, die das Potential haben bestehende Wertschöpfungsketten tiefgreifend zu verändern – vom Vertrieb über die Produktion bis hin zu Entscheidungen im Management.
Digitale Infrastrukturen sind längst mehr als nur technische Grundlagen – sie sind wirtschaftliche Hebel, geopolitische Einflussfaktoren und mediale Verstärker. Ob wirtschaftliche Abhängigkeiten, politische Einflussnahme oder der stille Verlust an Privatsphäre: Unsere digitale Realität wirft grundlegende Fragen auf – nach Kontrolle, Verantwortung und Gestaltungsfreiheit.
Genau hier setzt für mich der Begriff der digitalen bzw. Datensouveränität an.
Doch was genau bedeutet er – und warum betrifft er uns alle?
## Digitale bzw. Datensouveränität
Digitale Souveränität ist weit mehr als ein politisches Schlagwort. In einer zunehmend vernetzten, datengetriebenen und globalisierten Welt beschreibt sie die Fähigkeit von Individuen, Organisationen und Staaten, über ihre digitalen Infrastrukturen, Daten und Systeme eigenständig und selbstbestimmt zu entscheiden.
### Für mich heißt Datensouveränität …
Ich will selbst entscheiden, ob meine Daten in die Cloud wandern – und wenn ja, in welche. Ich will bestimmen, wer Zugriff darauf hat und was diese Personen oder Unternehmen damit tun dürfen. Es geht um meine Privatsphäre, meine Kontrolle – und letztlich auch um meine Freiheit in der digitalen Welt.
Als Unternehmen habe ich viele Anforderungen an digitale Lösungen: hohe Verfügbarkeit, Sicherheit, Flexibilität, Performance und Effizienz. Aber ebenso wichtig sind Kompatibilität, verlässliche Planbarkeit – und echte Wahlfreiheit, auch beim Anbieterwechsel.
Und wenn aus meinen Daten digitale Werte entstehen – sei es durch Auswertung, Automatisierung oder KI – will ich mitentscheiden. Wer profitiert? Wer trägt Verantwortung? Der aktuelle Streit zwischen der New York Times und großen Tech-Konzernen zeigt: Wenn Inhalte und Daten die Grundlage für neue Geschäftsmodelle bilden, stellt sich auch die Frage nach fairer Teilhabe.
Digitale Souveränität beschreibt die Fähigkeit von Staaten, Organisationen oder Unternehmen, digitale Technologien eigenständig zu nutzen, weiterzuentwickeln und strategisch zu gestalten.
Datensouveränität ist dabei ein zentraler Baustein – sie betrifft den verantwortungsvollen, kontrollierten Umgang mit Daten, technisch, rechtlich und organisatorisch.
Wer die Kontrolle über seine Daten verliert, macht sich abhängig.
## Digitale Abhängigkeit wird zur strategischen Schwachstelle
Mit der Rückkehr von Donald Trump ins Weiße Haus und zunehmenden Spannungen zwischen den USA und Europa wird sichtbar, wie abhängig Europa von fremden digitalen Infrastrukturen ist. US-Gesetze erlauben amerikanischen Behörden den Zugriff auf Daten – selbst wenn sie physisch in Europa liegen. Und wenn ein Tech-Gigant aus dem Silicon Valley entscheidet, Preise zu ändern, Dienste einzuschränken oder gar abzuschalten, dann stehen europäische Nutzer:innen oft ohne Einfluss da. Was wir uns gestern nicht mal im Traum vorstellen konnten, ist heute real – da wird die E-Mail-Adresse des Chefermittlers des Internationalen Strafgerichtshofs (IStGH) einfach gesperrt. Das ist für mich der Versuch der digitalen Erpressung.
Es geht längst nicht mehr nur um Technik. Es geht um Macht und um die Frage: Wem gehören die Daten, auf denen unsere Wirtschaft läuft, unsere Kommunikation basiert und unsere Innovation aufbaut? Wer darf bestimmen, was mit diesen Daten geschieht – und nach welchen Regeln?
Europa ist in zentralen digitalen Bereichen hochgradig abhängig – von Cloud-Diensten über Kommunikationsplattformen bis hin zur Datenverarbeitung. Die Effizienz dieser Systeme ist unbestritten, doch der Preis dafür ist hoch: ein wachsender Kontrollverlust, wirtschaftliche Risiken und geopolitische Verwundbarkeit.
Deshalb rückt digitale Souveränität zunehmend in den Fokus von Politik, Wirtschaft und Zivilgesellschaft. Spätestens seit dem EuGH-Urteil „Schrems II“ und mit neuen Regulierungen wie DSGVO, NIS2 oder DORA zeigt sich: Digitale Souveränität ist kein Ideal – sie wird zur Grundvoraussetzung für rechtssicheren Betrieb, Wettbewerbsfähigkeit und verantwortungsvolle Gestaltung der digitalen Zukunft.
## Wie sollte nun der Weg nach vorne aussehen?
Wege zur Daten- bzw. digitalen Souveränität
Hier geht es zu Teil 2 der Blog Serie: [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
---
## Alle Artikel zum Thema Datensouveränität
- [Was bedeutet Digitale Souveränität konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
- [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
- [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
- [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
- [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Kategorien:** Sustainability & Awareness
**Schlagwörter:** Daten, Digitalisierung, Moderne IT, zukunftswirksam
---
### [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
**Published:** August 19, 2025
**Author:** Lienhard Siegmund
**Content:**
In meinem letzten Blogpost habe ich beleuchtet, [wie sich Cloud-Anbieter auf die wachsenden Anforderungen an Datensouveränität einstellen](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/) – von EU-Regelwerken bis zu technischen Schutzmaßnahmen. Doch Souveränität ist keine Dienstleistung, die man einfach „dazu bucht“ – sie beginnt im eigenen Haus.
In diesem Artikel zeige ich, wie Unternehmen ihre Cloud-Architektur aktiv gestalten können, um Kontrolle über sensible Daten zurückzugewinnen. Sechs konkrete Stellschrauben helfen dabei, aus regulatorischem Druck unternehmerische Handlungsfähigkeit zu machen – pragmatisch, wirksam und individuell skalierbar.
Denn: Wer souverän handeln will, muss wissen, wo er steht – und welche Entscheidungen ihn wirklich weiterbringen.
## 6 Stellschrauben für mehr Datensouveränität in der Cloud
Was können Unternehmen also konkret tun? Sechs Stellschrauben helfen, mehr Kontrolle über die eigenen Daten zu gewinnen:
1. **Regionale Datenhaltung:** Durch Speicherung und Verarbeitung in europäischen Rechenzentren wird die Schwelle für außer-europäische Behördenzugriffe erhöht und Transparenz über die Datenflüsse geschaffen.
2. **Eigene Verschlüsselung & Schlüsselverwaltung:** Stichwort „Bring Your Own Key“ oder „Customer Managed Keys“. Damit behalten Unternehmen die Hoheit über ihre sensiblen Daten – selbst in der Public Cloud. Wichtig ist: Nicht nur verschlüsseln – sondern auch selbst kontrollieren, wer Zugriff auf die Schlüssel hat
3. **Sovereign- oder Trusted-Cloud-Angebote prüfen:** Entweder ich bleibe beim Hyperscaler und nutze dessen Sovereign-Angebot mit europäischem Betrieb und Schlüsselhoheit – oder ich gehe direkt zu einem europäischen Anbieter, der zu 100?% im EU-Rechtsraum agiert. Beides sind Optionen – mit unterschiedlichem Souveränitätsgrad und je nach Risikoabwägung sinnvoll.
4. **Hybride und segmentierte Cloud-Architektur:** Wer nicht alles auf eine Karte setzen will, sollte die Architektur flexibel gestalten: Zum Beispiel bestimmte Daten On-Prem betreiben, andere in der EU-Cloud hosten – oder Dienste so bauen, dass sie portierbar bleiben.
5. **Offene Standards & Open Source:** Technische Souveränität hängt auch davon ab, wie stark ich von proprietären Lösungen abhängig bin. Offenen Standards wie z.?B. bei APIs, Datenformaten, Deployment-Tools mit Technologien wie z.B. Kubernetes, Terraform usw, helfen dabei enorm – damit kann ich leichter wechseln und behalte länger die Kontrolle.
6. **Governance & Compliance aktiv leben:** Ohne Governance bleibt alles Theorie. Policies, Rollen, Audit-Mechanismen – all das muss definiert und gelebt werden. Viele Cloud-Plattformen stellen diese Governance-Tools bereits bereit – entscheidend ist, sie gezielt zu konfigurieren und regelmäßig zu nutzen.
## Datensouveränität messbar machen: Reifegrad statt Bauchgefühl
Wie können wir aus dem Thema Datensouveränität etwas Handfestes machen? Etwas, das man messen, vergleichen und verbessern kann?
Der erste Schritt dahin: Klarheit über den eigenen Reifegrad. Denn oft ist die Cloud-Nutzung längst Realität – mal strategisch geplant, mal eher historisch gewachsen. Manche Systeme laufen produktiv, andere stehen noch auf der Roadmap. Doch egal wo Sie stehen: Um gezielt zu handeln, müssen Sie zuerst wissen, wo Sie anfangen sollten.
Und genau dabei helfen Kennzahlen. Keine graue Tabelle, sondern ein pragmatischer Blick auf sechs zentrale Bereiche, die zeigen, wie souverän Ihre Cloud-Infrastruktur wirklich ist.
**Ihr Fragenkatalog könnte zum Beispiel so aussehen:**
- Wissen Sie, wo Ihre Daten tatsächlich gespeichert sind – und steuern Sie dies aktiv?
- Sind Ihre Daten verschlüsselt – und liegt der Schlüssel auch wirklich in Ihrer Hand?
- Haben Sie definiert, was schützenswert ist – und wie Sie damit umgehen?
- Und ganz konkret: Wenn morgen ein Prüfer kommt – haben Sie die passenden Verträge, Nachweise und Protokolle parat?
Hilfreich sind konkrete Kennzahlen – von Verschlüsselung bis Vertragstransparenz. Einige Punkte kennen Sie vielleicht schon aus dem vorherigen Kapitel. Aber jetzt geht es ums Ganze:
## Wie gut sind Sie wirklich aufgestellt – und was fehlt noch, um souverän zu handeln?
Die folgende Grafik zeigt die wichtigsten Kennzahlen, die dabei helfen, ein klareres Bild vom eigenen aktuellen Stand zu bekommen – jenseits von Bauchgefühl oder Einzelmaßnahmen. Sie zeigen, wo bereits gute Grundlagen bestehen und wo gezielt nachgebessert werden kann.
## Datensouveränität ist kein One-Size-Fits-All
Natürlich gilt dabei: Souveränität ist keine Einheitsgröße. Was für das eine Unternehmen essenziell ist, kann für ein anderes überdimensioniert sein. Die passenden Maßnahmen hängen stark vom Geschäftsmodell, den Datenarten und den regulatorischen Anforderungen ab. Ob Bank, HealthTech-Start-up oder Maschinenbauer – jedes Unternehmen muss seinen eigenen Souveränitätsgrad definieren.
Deshalb lohnt sich der Blick auf konkrete Beispiele:
Die **Deutsche Bank** etwa nutzt längst Cloud-Dienste – beispielsweise Google Cloud für Datenanalysen. Aber eben nicht für kritische Kernsysteme wie Zahlungsverkehr oder Risikosteuerung. Hier gelten strenge Anforderungen der BaFin: klare Exit-Strategien, Datenlokalisierung in der EU und maximale Transparenz.
Im Gesundheitsbereich ist **Ada Health** ein spannendes Beispiel. Das Berliner Start-up entwickelt eine KI zur medizinischen Symptomanalyse – und speichert alle sensiblen Daten verschlüsselt in der Google Cloud, ausschließlich in einem belgischen Rechenzentrum. Die sensiblen Gesundheitsdaten sind logisch dabei getrennt von personenbezogenen Informationen – ein interessantes Beispiel für Privacy by Design in der Anwendung.
Und im Maschinenbau? Da geht es seltener um personenbezogene Daten, dafür aber oft um hochsensible Konstruktions- und Produktionsdaten. Unternehmen wie **Trumpf** oder **Bosch** setzen auf Cloud-basierte Predictive-Maintenance-Lösungen – lassen aber ihre CAD-Pläne lieber im eigenen Rechenzentrum. Der Fokus liegt hier auf technischer Kontrolle und Exit-Fähigkeit, nicht auf juristischer Isolierung.
Der gemeinsame Nenner? Bewusste Architekturentscheidungen und eine klare Risikoabwägung. Souveränität bedeutet nicht, alles abzusichern – sondern zu wissen, was gesichert werden muss.
## Fazit: Souveränität ist eine bewusste Entscheidung – keine technische Konfiguration
Ob globaler Konzern, Mittelständler oder Behörde – wer die Cloud nutzt, steht heute in der Verantwortung, Datensouveränität aktiv zu gestalten. Das gelingt nicht durch Einzellösungen, sondern durch ein ganzheitliches Verständnis von Risiken, Schutzbedarf und Verantwortlichkeiten.
Die vorgestellten sechs Stellschrauben bieten dafür einen praktischen Rahmen: Sie helfen dabei, technische, organisatorische und juristische Aspekte sinnvoll miteinander zu verzahnen – und die eigene Cloud-Nutzung auf ein tragfähiges Fundament zu stellen.
Denn letztlich ist Datensouveränität kein Zustand, sondern ein kontinuierlicher Prozess – und der beginnt mit einer ehrlichen Bestandsaufnahme. Nutzen Sie die Chance, Ihre Architektur bewusst weiterzuentwickeln – Schritt für Schritt, mit klarer Zielsetzung.
---
## Alle Artikel zum Thema Datensouveränität
- [Was bedeutet Digitale Souveränität konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
- [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
- [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
- [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
- [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Kategorien:** Development, IT-Security
---
### [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
**Published:** Juli 31, 2025
**Author:** Lienhard Siegmund
**Content:**
Cloud ist kein Neuland mehr – sie ist Realität. Für Start-ups wie für Mittelständler, für Konzerne ebenso wie für Behörden. Und doch drängt sich in der Praxis immer öfter eine unbequeme Frage auf: Haben wir die Kontrolle über unsere Daten wirklich behalten?
Im letzten Beitrag dieser losen Blogserie zur Digitalen Souveränität haben wir den Begriff Datensouveränität entschlüsselt und ihn von Datensicherheit und digitaler Souveränität abgegrenzt. Jetzt gehen wir einen Schritt weiter: Wie lässt sich Datensouveränität in der Praxis erreichen – speziell in der Cloud? Und was bedeutet das im Spannungsfeld zwischen Innovation und Regulierung, zwischen Hyperscalern und EU-Recht?
In diesem 3. Teil dieser Serie geht es um Digitale Souveränität in der Cloud und ich richte ich meinen Blick auf die Lieferantenseite. Wie reagieren Hyperscaler und kleinere Cloudanbieter auf die steigenden Ansprüchen und Risiken im Bereich der Digitalen Souveränität? In welchem technischen, politischen und juristischen Spannungsfeld bewegen sie sich? Wie verändern sich ihre Cloud Services und was bedeutet das für uns als Kunden? Fragen, die Unternehmen heute ganz konkret beantworten müssen.
## Warum Unternehmen ihre Cloud-Strategie überdenken müssen
Datensouveränität rückt nicht ohne Grund in den Fokus. Politische Unsicherheiten, neue EU-Verordnungen und datenhungrige Technologien wie KI sorgen dafür, dass Unternehmen ihre Cloud-Strategien neu überdenken müssen.
- Politisch sorgen CLOUD Act & Co. für Rechtsrisiken – auch ohne physische Datenverlagerung.
- Regulatorisch erhöht die EU mit NIS2, dem Data Act und dem Cyber Resilience Act den Druck auf Transparenz und Kontrolle.
- Technologisch treiben Cloud und KI den Datenbedarf – und die Fragen nach Standort, Zugriff und Exit-Fähigkeit.
Kurz: Die Cloud treibt Innovation – aber nur, wenn Unternehmen die Kontrolle behalten.
## Hyperscaler und Souveränität – ein Widerspruch?
Viele Unternehmen setzen auf Hyperscaler wie AWS, Azure oder Google Cloud – und das aus guten Gründen. Die Plattformen bieten bewährte Performance, Innovationskraft, ein breites Service-Ökosystem und schnelle Skalierbarkeit.
Doch die Frage bleibt: Ist Datensouveränität mit diesen Anbietern überhaupt möglich?
Die Antwort hängt stark von der Zielsetzung des Unternehmens ab – und davon, wie Datensouveränität priorisiert wird. Denn sie lässt sich in drei Bereiche aufteilen:
- Technische Unabhängigkeit
- Organisatorische Kontrolle
- Juristische Absicherung
Je nachdem, welche dieser Bereiche für ein Unternehmen im Vordergrund stehen, fällt auch die Bewertung anders aus.
**Technisch:** Ja. Hyperscaler bieten mittlerweile umfangreiche Funktionen zur Steuerung und Absicherung:
- Datenlokalisierung durch Auswahl von EU-Regionen
- Eigene Schlüsselverwaltung (Customer Managed Keys)
- Umfangreiche Monitoring- und Governance-Tools
**Organisatorisch:** Auch Exit-Strategien und eine klare Datenklassifikation lassen sich technisch und prozessual umsetzen – durch definierte Migrationsprozesse, Richtlinien für Datenkategorien und klare Verantwortlichkeiten im Datenmanagement.
**Juristisch** wird’s knifflig. Der US CLOUD Act erlaubt US-Behörden theoretisch den Zugriff auf Daten – auch wenn diese in Rechenzentren innerhalb der EU liegen, solange der Anbieter seinen Hauptsitz in den USA hat. Das zwingt Unternehmen zur ehrlichen Abwägung: Wie viel Kontrolle brauche ich – und welches Risiko bin ich bereit einzugehen?
Die großen Cloud-Anbieter versuchen, dieses Spannungsfeld zu entschärfen. Sie integrieren längst EU-Standardvertragsklauseln in ihre Verträge, veröffentlichen Transparenzberichte und geben Schutzversprechen wie Microsofts „Defending Your Data“ oder das AWS GDPR Addendum, in denen sie sich verpflichten, Behördenanfragen anzufechten und ihre Kunden zu informieren. Zusätzlich entstehen Sovereign-Cloud-Angebote in Kooperation mit europäischen Partnern oder über separate Tochtergesellschaften, die das EU-Geschäft rechtlich und organisatorisch klar vom US-Konzern trennen sollen.
Diese Maßnahmen ersetzen zwar keine juristische Unabhängigkeit, sie wirken aber wie ein Puffer: Sie verschaffen technische Kontrolle über Daten und Schlüssel, rechtliche Absicherung durch klar geregelte Verträge – und sie machen Zugriffe von außen deutlich schwerer. Das Restrisiko bleibt, aber es wird kleiner. Für viele Unternehmen ist genau das der Unterschied zwischen unsicher und tragbar.
Was das für Unternehmen konkret bedeutet – und welche Stellschrauben sie selbst in der Hand haben – beleuchte ich im nächsten Teil dieser Serie.
## Neue Verantwortung für Cloud-Anbieter durch EU-Regulierungen
Lange galten Cloud-Anbieter primär als Technologielieferanten: Sie lieferten Rechenleistung, Speicher und Services – um Datenschutz und Compliance musste sich der Kunde selbst kümmern. Doch diese Zeiten sind vorbei. Mit Regulierungen wie der DSGVO, NIS2, dem Cyber Resilience Act und dem neuen EU Data Act verändert sich das Kräfteverhältnis.
Cloud-Anbieter geraten stärker in die Verantwortung. Sie müssen nicht nur performante, sondern auch rechtskonforme und vertrauenswürdige Plattformen bereitstellen. Und die großen Player reagieren: AWS, Microsoft und Google investieren massiv in Sovereign-Cloud-Angebote, europäische Datenräume und Partnerschaften mit EU-Anbietern wie T-Systems oder Thales. Datenlokalisierung, Schlüsselhoheit, Audit-Funktionen und Governance-Tools gehören zunehmend zum Standard – nicht nur für Behörden, sondern auch für den Mittelstand.
Gleichzeitig positionieren sich europäische Anbieter wie STACKIT oder OVHcloud offensiv mit dem Versprechen: „Unsere Daten unterliegen ausschließlich EU-Recht.“ Gerade bei kritischen Infrastrukturen und sicherheitsbewussten Unternehmen sorgt das für Vertrauen – und damit für ein neues Wettbewerbsumfeld.
**Kurz gesagt:** Die Rolle der Cloud-Anbieter verändert sich grundlegend. Wer heute auf Souveränität – technisch wie juristisch – setzt, positioniert sich nicht nur als Dienstleister, sondern als strategischer Partner. Für Unternehmen eröffnet das neue Spielräume – vorausgesetzt, sie wissen, was sie brauchen und worauf sie setzen.
Im nächsten Teil dieser Serie betrachten wir die Anwenderseite: Was können Unternehmen konkret tun, um ihre Datensouveränität in der Cloud zu stärken? Welche Strategien, Tools und Partnerschaften helfen dabei? Bleiben Sie dran!
---
## Alle Artikel zum Thema Datensouveränität
- [Was bedeutet Digitale Souveränität konkret?](https://thecattlecrew.net/2025/06/11/digitale-souveraenitaet-was-bedeutet-digitale-souveraenitaet-konkret/)
- [Wege zur Datensouveränität](https://thecattlecrew.net/2025/07/01/wege-zur-datensouveraenitaet/)
- [Datensouveränität & Cloud: Wie kompatibel sind Hyperscaler mit EU-Vorgaben?](https://thecattlecrew.net/2025/07/31/datensouveraenitaet-cloud-wie-kompatibel-sind-hyperscaler-mit-eu-vorgaben/)
- [Datensouveränität & Cloud: Sechs Stellschrauben für mehr Kontrolle](https://thecattlecrew.net/2025/08/19/datensouveraenitaet-cloud-sechs-stellschrauben-fuer-mehr-kontrolle/)
- [Datensouveränität in der KI-Ära: Warum Datenhoheit das größte Kapital ist](https://thecattlecrew.net/2025/09/02/datensouveraenitaet-in-der-ki-aera-warum-datenhoheit-das-groesste-kapital-ist/)
**Kategorien:** Development
---
### [Open Data in Aktion: Mit KI Abwasserdaten analysieren](https://thecattlecrew.net/2025/08/21/open-data-in-aktion-mit-ki-abwasserdaten-analysieren/)
**Published:** August 21, 2025
**Author:** Anton Rösemann
**Content:**
Der Impuls für diesen Artikel kam während eines KI-Tech-Talks bei OPITZ CONSULTING: Ein Kollege demonstrierte, wie sich ChatGPT zur Visualisierung strukturierter Daten einsetzen lässt – ganz ohne Programmierkenntnisse. Für mich als Berater im Public Sector war sofort klar: Das Potenzial für öffentliche Institutionen ist enorm – gerade, wenn man bedenkt, wie viele spannende Open-Data-Quellen heute schon existieren.
In mehreren aktuellen Projekten arbeiten wir mit Abwasserdaten, teilweise auf Basis offener Daten. ([-> Kundenstory Berliner Wasserbetriebe](https://www.opitz-consulting.com/kompetenz/kundenstory-berliner-wasserbetriebe)) Ein perfektes Umfeld also, um die Möglichkeiten der dialogbasierten Datenanalyse mit ChatGPT-5 auszuprobieren – konkret anhand der Daten aus dem AMELAG-Projekt, einer vom RKI betriebenen Abwassersurveillance.
## Warum Abwasser ein Frühindikator ist
Abwasserdaten sind viel mehr als technisches Beiwerk. Während der Corona-Pandemie zeigte sich, dass steigende Viruslasten im Abwasser oft Vorboten regionaler Infektionswellen waren – teils mehrere Tage vor den offiziellen Meldezahlen. Auch die neue **EU-Abwasserrichtlinie (KARL, EU 2024/3019)** erkennt dieses Potenzial und fordert den systematischen Aufbau entsprechender Überwachungsnetze.
Das bedeutet: Öffentliche Einrichtungen könnten künftig deutlich schneller auf Gesundheitsentwicklungen reagieren – mit gezielter Personalplanung, Medikamentenlogistik oder Hygieneempfehlungen.
Das Thema Abwasseranalyse ist im Public Sektor äußerst relevant und viel mehr als eine technische Spielerei: Während der Corona-Pandemie zeigte sich, dass steigende Viruslasten im Abwasser ein Frühindikator für regionale Ausbrüche sein können. Mit entsprechenden Modellen ließen sich künftig gezielt Hygienemaßnahmen, Medikamentenlieferungen oder andere Gesundheitsinterventionen steuern. Das Potenzial ist also groß – und wird durch die neue Abwasserrichtlinie bereits in wichtigen Teilen adressiert.
## ChatGPT-5 im Datenanalyse-Modus
Für unseren Test haben wir ChatGPT-5 im Modus Advanced Data Analysis genutzt. Besonders hilfreich waren dabei:
- **Uploadfunktion für Dateien (CSV/TSV)** direkt im Chatfenster
- **Kontextbezogenes Prompting**, um gezielte Analysen und Visualisierungen zu steuern
- **Erklärende Rückfragen und Ergebnisse**, auch für Nicht-IT-Fachleute verständlich
Die Grundlage: eine TSV-Datei aus dem AMELAG-Projekt mit Viruslastdaten einzelner Standorte.
## Erste Analysen: Was steckt im Datensatz?
Nach dem Upload identifizierte ChatGPT-5 automatisch die vorhandenen Spalten: Standortinformationen, Zeitstempel, Messwerte für SARS-CoV-2, Influenza u. a. Auffällig: In manchen Feldern fehlten bis zu 75 % der Einträge. Statt aufwendiger Vorverarbeitung entschieden wir uns für einen realistischen Blick auf die Rohdaten.
Auf eine einfache Frage wie „Welche Bundesländer sind im Datensatz enthalten?“ reagierte das Modell schnell und korrekt mit: „Alle 16 Bundesländer.“
Hier zwei Screenshots:
## 
## 
## Visualisieren mit Prompts: Iteratives Vorgehen
Die eigentliche Stärke von ChatGPT-5 offenbarte sich bei der Visualisierung:
1. Zunächst ließen wir uns eine LOESS-Glättung der Influenza-A-Werte für den Standort Stuttgart anzeigen.
2. Danach ergänzten wir weitere Virusparameter für Influenza, um die Entwicklung im Vergleich darzustellen.
3. Im nächsten Schritt erweiterten wir den Betrachtungsbereich auf ganz Baden-Württemberg.
4. Wir wiederholten diesen Ablauf für andere Bundesländer, um Unterschiede und Gemeinsamkeiten zu erkennen.
5. Parallel dazu prüften wir den Datensatz gelegentlich manuell in Excel, um ein Gefühl für die Rohwerte zu bekommen.
Die Ergebnisse zeigten saisonale Effekte, auffällige Peaks und Unterschiede zwischen Regionen. Besonders spannend: Aggregationen über mehrere Standorte mit nur einem Prompt. Ein Feature, das ältere Modellversionen so noch nicht beherrschten.
**Wichtig:** Bei diesen Versuchen war es wichtig, gezielt festzulegen, welche Werte wir für die Darstellung verwenden – in unserem Fall die LOESS-berechneten Werte, da sie für Vorhersagen besonders aussagekräftig sind.
## Was haben wir daraus gelernt?
Die Analyse lieferte eine Reihe von Diagrammen, die interessante Muster aufzeigen:
- **Saisonale Effekte:** Im Winter sind die Influenza-Werte erwartungsgemäß höher.
- **Auffällige Peaks:** Einzelne Zeitpunkte zeigen ungewöhnlich hohe Messwerte. Solche Peaks könnten bei einer zeitnahen Auswertung als Frühindikatoren dienen, um gezielte Maßnahmen einzuleiten.
- **Aggregation nach bestimmten Kriterien:** Ein weiterer Vorteil von ChatGPT-5 ist die Fähigkeit, Daten nach bestimmten Kriterien zu aggregieren – beispielsweise alle Standorte in Baden-Württemberg zusammenzufassen. Solche Aggregationen waren mit demselben Prompt in Modellversion 4.0 in dieser Form noch nicht möglich.
## Wo Behörden profitieren könnten
Die Einsatzmöglichkeiten im Public Sector sind vielfältig: Die Fähigkeit zur Mustererkennung im Abwasser bietet nicht nur Potenzial für den Gesundheitsbereich, sondern es sind auch Einsatzmöglichkeiten in ganz anderen Bereichen denkbar, wie zum Beispiel:
- **Gesundheitswesen:** Früherkennung und Intervention bei Ausbrüchen
- **Bildungseinrichtungen:** Planung von Vertretungsregelungen oder mobilem Unterricht
- **Verwaltungen & Infrastruktur:** Flexible Maßnahmenplanung basierend auf Infektionsprognosen
Viele dieser Ideen erinnern an die Corona-Zeit– nur, dass wir heute über smartere Tools verfügen, um schneller und präziser zu reagieren.
## Auch für Unternehmen interessant: Monitoring per Abwasseranalyse
Was im Public Sector seinen Anfang nimmt, kann auch für privatwirtschaftliche Akteure von Interesse sein – insbesondere dort, wo Betriebssicherheit, Gesundheitsschutz oder Standortsteuerung im Fokus stehen. Denkbar sind zum Beispiel folgende Szenarien:
- **Großunternehmen & Produktionsstandorte:** Frühwarnsysteme für saisonale Infektionswellen, um Personalengpässe besser zu planen oder gezielt Schutzmaßnahmen einzuleiten.
- **Immobilien- und Facility Management:** Überwachung von Gebäuden oder Liegenschaften mit vielen Nutzer:innen – etwa Wohnanlagen, Pflegeeinrichtungen oder Bürokomplexe.
- **Eventbranche & Veranstaltungsorte:** Einsatz temporärer Sensorik zur Risikoabschätzung bei Großveranstaltungen – z.?B. bei Festivals, Messen oder Sportereignissen.
- **Kliniken & Laborbetreiber:** Ergänzende Datenquelle für Infektionscontrolling oder zur Validierung eigener Messreihen.
- **Logistikzentren & Transportinfrastruktur:** Nutzung zur Entscheidungsvorbereitung bei Personal- oder Routenplanung in Phasen hoher Ausfallgefahr.
In vielen dieser Kontexte liegt der Vorteil klar auf der Hand: Die Kombination aus offenen oder lokal erhobenen Daten mit KI-gestützter Analyse ermöglicht flexible, kostenbewusste Entscheidungen – und das ohne den Aufwand komplexer BI-Infrastrukturen.
## Grenzen und klare Empfehlungen
Natürlich ersetzt ChatGPT keine professionelle BI-Lösung. Was fehlt:
- Interaktive Dashboards
- Filtern und Aggregieren per Klick
- Kombination mit anderen Datenquellen
Und: **Datenschutz bleibt oberstes Gebot.** Der Einsatz sollte auf anonymisierte, offene Datensätze beschränkt bleiben. Für sensible Daten sind On-Premise-Lösungen oder KI-Modelle in geschützten Umgebungen notwendig.
## Fazit: Starkes Tool für erste Einblicke
Die Arbeit mit ChatGPT-5 hat gezeigt: Wer Open Data nutzt, kann mit einfachen Prompts fundierte Erkenntnisse gewinnen. Für schnelle, explorative Analysen – insbesondere im Public Sector – ist das Sprachmodell ein hilfreiches Werkzeug. Und vielleicht der perfekte Einstiegspunkt für datengetriebene Entscheidungen in öffentlichen Einrichtungen.
Auch außerhalb des Public Sector bieten sich spannende Anwendungsfelder – von Unternehmen mit vielen Mitarbeitenden über das Immobilienmanagement bis hin zu Veranstaltern. KI-gestützte Abwasseranalysen könnten künftig überall dort unterstützen, wo Planungssicherheit gefragt ist.
**Kategorien:** AI & Data Science, Analytics & Insights
**Schlagwörter:** Artificial Intelligence, Business Intelligence, Prompt
---
### [Helm-Charts in Gefahr? Bitnami Images werden kostenpflichtig](https://thecattlecrew.net/2025/08/13/helm-charts-in-gefahr-bitnami-images-werden-kostenpflichtig/)
**Published:** August 13, 2025
**Author:** Philipp Kürsten
**Content:**
Bitnami ist für viele Kubernetes- und Cloud-Teams ein vertrauter Name. Die vorgefertigten Container-Images und Helm-Charts für Anwendungen wie PostgreSQL, Redis oder Keycloak haben es einfach gemacht, Open-Source-Software schnell und zuverlässig in Kubernetes bereitzustellen.
Wer eine neue Datenbank oder einen Cache brauchte, konnte bisher darauf vertrauen, dass Bitnami ein getestetes Image und gleich das passende Helm-Chart mitliefert. Doch diese Selbstverständlichkeit steht nun vor einem großen Umbruch: Broadcom, seit der VMware-Übernahme Eigentümer von Bitnami, stellt das bisherige kostenlose Image-Angebot in weiten Teilen ein.
## **Was ändert sich konkret?**
Ab dem **28. August 2025** werden ältere und versionierte Bitnami-Images nicht mehr unter der bekannten Registry `docker.io/bitnami` verfügbar sein. Stattdessen wandern sie in ein **„Legacy Repository“**, das keine Sicherheitsupdates mehr erhält.
Parallel dazu führt Broadcom die **Bitnami Secure Images** ein: kommerzielle, sicherheitsgehärtete Container-Images, die in einem reproduzierbaren Build-Prozess erstellt werden und mit zusätzlichen Informationen wie SBOMs (Software Bill of Materials) sowie VEX-Daten (Vulnerability Exploitability Exchange) ausgeliefert werden. Diese Images werden langfristig in LTS-Branches gepflegt – allerdings nur im Rahmen eines [kostenpflichtigen Abonnements](https://aws.amazon.com/marketplace/pp/prodview-pwqgz3mnvxvok).
Die Helm-Charts selbst bleiben zwar Open Source und unter Apache-2-Lizenz auf GitHub verfügbar, doch sie referenzieren standardmäßig auf Images, die nach dem Stichtag ohne Subscription nicht mehr zugänglich sein könnten. Wer also nach dem 28. August ein `helm upgrade` durchführt, **riskiert fehlschlagende Deployments**.
## **Warum macht Bitnami das?**
Broadcom verfolgt seit der Übernahme von VMware eine klar auf Enterprise-Kunden ausgerichtete Strategie. Das Ziel: Kunden in regulierten oder sicherheitskritischen Umgebungen ein vollständig kontrolliertes und überprüftes Container-Ökosystem zu bieten.
Bitnami Secure Images (BSI) sollen dabei nicht nur Sicherheit und Compliance garantieren, sondern auch eine stabile Lieferkette mit nachvollziehbaren Builds schaffen. Für Unternehmen, die auf Zertifizierungen und Audits angewiesen sind, ist das attraktiv. Für kleinere Teams oder Open-Source-Projekte hingegen kann die neue Kostenstruktur eine echte Hürde darstellen.
## **Auswirkungen in der Praxis**
Die Änderungen treffen nicht nur große Plattform-Teams, sondern auch viele kleinere Projekte:
- **Helm-Charts könnten brechen**, wenn die referenzierten Images nicht mehr verfügbar sind.
- **CI/CD-Pipelines** riskieren Build-Fehler, wenn `docker pull` nicht mehr funktioniert.
- **Sicherheitslücken bleiben offen**, wenn Legacy-Images ohne Updates im Einsatz bleiben.
Gerade in produktiven Umgebungen kann das zu Ausfällen oder Compliance-Problemen führen.
## **Handlungsoptionen für Teams**
Kurzfristig lässt sich der Betrieb sichern, indem man Helm-Charts so anpasst, dass sie auf das Legacy-Repository zeigen oder benötigte Images in eine eigene Registry spiegelt. Letzteres sorgt für Stabilität, löst aber nicht das Problem fehlender Sicherheitsupdates.
Langfristig gibt es drei Ansätze:
1. **Bitnami Secure Images abonnieren**
Wer Wert auf Support, Sicherheit und LTS legt, kann die kommerzielle Lösung in Betracht ziehen. Der manuelle Aufwand zur Härtung von Images sollte hierbei nicht unterschätzt werden!
2. **Eigene Images bauen**
Dafür können die Open-Source-Helm-Charts geforkt und auf alternative Basis-Images (z. B. Docker Official Images, Chainguard oder Distroless) umgestellt werden. Hierbei ist allerdings zu beachten, dass die Bitnami-Images meisst mehr als nur den reinen Service implementiert hatten. So wurde beispielsweise bei dem PostgreSQL Image auch das entsprechende Seeding von Datenbanken und Nutzern im EntryPoint des Image mit durchgeführt.
3. **Auf Alternativen aus der Community oder vom Hersteller setzen**
Viele Anwendungen werden direkt vom Upstream-Projekt als Container-Image gepflegt. Häufig gibt es auch OEM-Helm-Charts oder dedizierte Kubernetes-Operatoren. Wie beispielsweise folgende Projekte beweisen:
- Für **PostgreSQL** bietet sich etwa der [cloudnative-pg Operator](https://cloudnative-pg.io/) an, ein CNCF-Projekt, das Installation, Updates, Hochverfügbarkeit und Backups automatisiert.
- **Keycloak** lässt sich ebenfalls mit einem [Operatoren von der Community](https://www.keycloak.org/operator/installation) betreiben.
- **Redis** lässt sich mit Operatoren wie dem [von Spot.io](https://github.com/spotahome/redis-operator) oder dem Helm-Chart [des Herstellers](https://redis.io/docs/latest/operate/kubernetes/deployment/helm/) betreiben.
Der Einsatz von Operatoren hat den Vorteil, dass viele Betriebsaufgaben direkt automatisiert werden und sich die Integration in Kubernetes-Workflows verbessert. Trotzdem ist es auch hier Notwendig eine Auge auf die Härtung der Images zu legen und diese – bei Bedarf – selbstständig nachzubessern.
## **Praktisches Beispiel: PostgreSQL-Deployment anpassen**
Damit der Wechsel reibungslos gelingt, lohnt sich ein Blick in die `values.yaml` des Bitnami PostgreSQL Helm-Charts. Hier lassen sich die Image-Quelle und der Tag überschreiben.
### **1. Kurzfristig: Nutzung des Legacy-Repository**
```
image:
registry: docker.io
repository: bitnamilegacy/postgresql
tag: 15.4.0
```
Das funktioniert nur so lange, wie die benötigte Version im Legacy-Repo liegt – Updates gibt es dort nicht mehr.
### 2. Etwas robuster: Spiegelung in eine eigene Registry
```
# Image aus dem Legacy-Repo ziehen
docker pull docker.io/bitnamilegacy/postgresql:15.4.0
# In eigene Registry pushen
docker tag docker.io/bitnamilegacy/postgresql:15.4.0 registry.example.com/postgresql:15.4.0
docker push registry.example.com/postgresql:15.4.0
```
Im Helm-Chart verweist du dann auf deine Registry:
```
image:
registry: registry.example.com
repository: postgresql
tag: 15.4.0
```
So bist du nicht mehr von Änderungen bei Bitnami abhängig – Updates musst du allerdings selbst einspielen.
### 3. Alternative: Einsatz des cloudnative-pg Operators
**Installation des Operators:**
`helm repo add cnpg https://cloudnative-pg.github.io/charts`
`helm install cnpg cnpg/cloudnative-pg`
**Deployment einer PostgreSQL-Instanz via CRD:**
```
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: my-postgres
spec:
instances: 3
imageName: ghcr.io/cloudnative-pg/postgresql:15.4
storage:
size: 10Gi
```
Der Operator kümmert sich anschließend um Hochverfügbarkeit, Backups und Updates – ohne dass du manuell ein Helm-Chart anpassen musst.
## **Fazit**
Die verbleibende Zeit **bis zum 28. August** sollte genutzt werden, um Klarheit zu schaffen:
Welche Bitnami-Images sind im Einsatz? Sind die genutzten Versionen nach dem Stichtag noch zugänglich? Und welche Migrationsstrategie passt zur eigenen Organisation – Secure Images, Eigenbau oder ein Umstieg auf OEM-Charts bzw. Operatoren?
**Je eher diese Fragen beantwortet werden, desto reibungsloser kann der Wechsel erfolgen.**
Die Umstellung bei Bitnami ist ein deutliches Beispiel dafür, wie schnell sich die Rahmenbedingungen im Open-Source-Ökosystem ändern können – besonders dann, wenn beliebte Projekte in den Besitz großer Konzerne gelangen. Für Betreiber von Kubernetes-Workloads bedeutet das: Nicht allein auf die Bequemlichkeit bestehender Lösungen verlassen, sondern frühzeitig Alternativen evaluieren.
Wer jetzt handelt, kann Ausfälle vermeiden und seine Plattform langfristig unabhängiger und resilienter aufstellen.
**Kategorien:** Development, DevOps, IT-Security
**Schlagwörter:** CI, Deployment, Helm, IT Security, Kubernetes
---
### [Zwischen KI, Governance und Zukunftsvisionen: Das war der Gartner Data & Analytics Summit](https://thecattlecrew.net/2025/06/10/zwischen-ki-governance-und-zukunftsvisionen-das-war-der-gartner-data-analytics-summit/)
**Published:** Juni 10, 2025
**Author:** Jens Bleiholder
**Excerpt:** Alle paar Jahre lohnt sich der Besuch das Gartner Data & Analytics Summit, um sich in drei 3 Tagen kompakt mit Trends und Themen auseinanderzusetzen. Nicht immer ist alles neu, aber es wird kompakt und sehr gut präsentiert und bietet einen vielfältigen und ganzheitlichen Blick auf die Dinge und wie sie zusammenhängen. Hier nun eine notwendigerweise subjektive Sicht auf spannende und relevante Themen der Konferenz.
**Content:**
Am 12. bis 14. Mai 2025 war es wieder so weit: Gartner lud Business-Analysten und Datenverantwortliche aus der ganzen Welt zum Gartner Data & Analytics Summit nach London ein. Wir waren zu dritt dabei und freuten uns auf drei Tage geballte Informationen zu den unterschiedlichsten Data-&-Analytics-Themen.
Der Gartner Summit findet zu unterschiedlichen Themen jährlich mehrmals an verschiedenen Orten statt. Bei dieser Gelegenheit berichten die Analysten von Gartner über ihre Erkenntnisse und Erfahrungen aus den Gesprächen mit ihren Kundenfirmen weltweit und aus ihrer Forschungsarbeit. Neben den Trends, die sie am Markt wahrnehmen, kann man auf dem Summit aber auch Unternehmen und Produkthersteller näher kennenlernen und sich deren Produkte zeigen lassen.
Es war nicht immer leicht, sich aus den über 200 verschiedenen Sessions die spannendste herauszusuchen, da meist fünf oder mehr Sessions parallel stattfanden. Neben den Vorträgen der Gartner Analysten gab es auch viele Projekt- und Produktvorstellungen der fast 100 Aussteller. Hier nun meine notwendigerweise subjektive Sicht auf spannende und relevante Themen der Konferenz.
## Generative KI & Decision Intelligence
Wie erwartet war das Thema Künstliche Intelligenz, insbesondere generative KI (GenAI), allgegenwärtig. In den Vorträgen ging es zum einen darum einzuordnen, wie stark diese Technologie zukünftig unsere Arbeit verändern wird (erheblich) und wo sie überall eine Rolle spielen wird (in vielen Bereichen). Zum anderen gab es viele technische Hilfestellungen, wie KI-Projekte angegangen und auch erfolgreich umgesetzt werden können.
Zwei von vielen Themenbereichen des Summit möchte ich hier besonders hervorheben:
- Wie verbessert KI die Tools, die wir benutzen
- Wie treffen wir bessere Entscheidungen, auch mit Hilfe von KI
### Toolunterstützung durch KI
Im Bereich Tools geht es um die KI-Unterstützung bei der Erstellung von z. B. Berichten und Datenpipelines. Zwei einfache Beispiele:
- Microsoft, das die Copilot-Funktionalitäten in nahezu allen Bereichen integrieren wird, insbesondere zur Verbesserung der Berichtserstellung (z. B. in Power BI) und der Datentransformationen (z. B. in der Data Factory).
- Auch Plotly plant die Einführung eines Assistenzsystems, das in der Lage sein soll, natürliche Sprachbefehle zu verstehen und darauf basierend Reporting-Anwendungen zu bauen.
GenAI soll uns also dabei helfen, schneller und einfacher zu Ergebnissen zu kommen. Es zeigt sich, dass die Hersteller hier unterschiedlich weit sind, meist aber noch nicht so weit, wie man sich das erhofft. KI-Funktionalität ist bisher häufig nur in Form von Beta-Features umgesetzt, die in den Produkten erst im Laufe des Jahres ausgerollt werden.
Generell befindet sich das Thema GenAI im Hype-Zyklus (siehe: ) nach anfänglicher Euphorie nun auf dem Weg ins „Tal der Enttäuschung“, was man an den mittlerweile immer häufiger werdenden Berichte über die Grenzen der Technologie sieht. So musste der Finanzdienstleister Klarna z. B. feststellen, dass seine Idee, seine gesamte Kundenbetreuung auf Chatbots umzustellen, so (noch) nicht funktioniert. Also ruderte er zurück und stellte wieder „echte“ Mitarbeiter:innen für die schwierigen Fälle ein. (siehe: ).
Trotz allem war der Grundtenor auf dem Summit aber positiv: Man freut sich auf die neue Welt, in der viele Mitarbeitende enorm von den Möglichkeiten der KI profitieren werden.
### Entscheidungsunterstützung mit KI
Der zweite Themenbereich ist die weitergehende Unterstützung und idealerweise auch Automatisierung von Entscheidungen. Schlussendlich wollen wir mit unserer Arbeit im Bereich Data und Analytics ja immer die Fachbereiche bei ihren Entscheidungen unterstützen. Und das in einer Welt, in der einerseits immer mehr und komplexere Entscheidungen getroffen werden müssen und uns auf der anderen Seite immer mehr Daten und Analysetechniken zur Verfügung stehen.
Decision Intelligence (siehe: ) versteht sich als Fachgebiet, bei dem es darum geht, den Entscheidungsprozess genauer zu betrachten, zu verstehen und zu verbessern. Die Idee, mit Hilfe von Daten (liefert Data & Analytics) Entscheidungen (trifft der Fachbereich) zu verbessern, ist ja nicht neu, scheint aber schwieriger umzusetzen zu sein als gedacht.
Das Thema war gleich in mehreren Vorträgen präsent. Neben Hinweisen wie man es angeht, Entscheidungen zu formalisieren und gezielt zu verbessern, wurde immer wieder das Thema „Wert“ betont: Vielleicht ist es an der Zeit den Begriff „data-driven“ endgültig durch den Begriff „value-driven“ zu ersetzen; denn schließlich wollen wir mit den Daten und Analysemöglichkeiten den Fachbereichen ja zu Entscheidungen verhelfen, die dann einen Mehrwert liefern. Sich etwas methodischer mit der Art und Weise zu beschäftigen, wie Entscheidungen getroffen werden und wie man dies verbessern kann, ist auch deshalb keine schlechte Idee.
Hier schließt sich dann auch wieder der Kreis zur (generativen) KI, die als Technologie dabei helfen soll, Entscheidungen besser zu unterstützen und weiter zu automatisieren.
## Data Governance & Data Observability
Auch die Themen Data Governance und Data Observability waren beim Gartner Data & Analytics Summit prominent vertreten. Data Observability, unter allen Konferenzthemen vermutlich das neueste – bezeichnet die Fähigkeit, den Zustand von Daten sowie deren Transformationen innerhalb eines Unternehmens kontinuierlich zu überwachen, zu analysieren und nachzuvollziehen. Ziel ist es, frühzeitig Unregelmäßigkeiten zu erkennen, Fehlerquellen zu identifizieren und die Integrität datenbasierter Prozesse sicherzustellen.
Im Rahmen des Summit stellten viele Anbieter aus diesem Bereich ihre Tools vor, darunter auch einige, die mir noch nicht bekannt waren. Diese Tools erlauben die Definition von Datenqualitätstests, zeigen Data Lineage an, integrieren dafür Informationen aus anderen Tools, wie ELT-Tools, Reportingools und Datenkatalogen, oder integrieren sich in solche.
Die Tools hinterließen einen ersten guten Eindruck und scheinen schon einen guten Reifegrad zu haben. Der Übergang zu Datenkatalogen ist fließend und vermutlich muss man sich die Frage stellen, ob der Einsatz eines eigenen Tools gerechtfertigt ist, oder ob Data Observability nicht einfach Teil der Funktionalität eines Datenkatalogs oder der Datenplattform an sich wird.
### Doppelstrategie
Auffällig: Viele Anbieter fahren mittlerweile eine Doppelstrategie und richten ihre Tools sowohl an die Zielgruppe der technischen Nutzer, als auch an Nutzer aus den Fachbereichen. Einerseits sollen damit beide Gruppen in die Lage versetzt werden Datenqualitätschecks o. ä. zu definieren, andererseits soll die Zusammenarbeit gestärkt werden, indem sie z. B. toolgestützt gemeinsam Datenprodukte oder -kontrakte definieren können.
Hier kann man dann auch wieder den Bogen zum Thema KI schlagen: GenAI kann hier an der Schnittstelle zwischen Technik und Business übersetzen und die Zusammenarbeit verbessern. In natürlicher Sprache vom Fachbereich beschriebene Tests, Produkte, Kontrakte, etc. übersetzt die KI in Programmcode, genauso wie von der Technik geschriebener Code in SQL, Python, etc. in natürliche Sprache übersetzt werden kann.
## Datenarchitekturen & Organisationen
Was Datenarchitekturen angeht, fiel vor allem dies auf: Vor 5-10 Jahren gab es beim Gartner Summit noch viele Vorträge über die Unterschiede zwischen Data Lake und Data Warehouse und unter welchen Umständen was zu verwenden ist. Jetzt ging es dagegen eher um die Frage, wie man die Konzepte Data Fabric und Data Mesh voneinander abgrenzen kann und wie man diese einsetzt. Der Fokus hat sich mit der Zeit also von der Technik in Richtung Organisation verschoben.
Generell scheint auch die Zeit der unerbittlichen Debatten vorbei zu sein (wenn es sie denn je gegeben hat…!?):
- Lake oder Warehouse? – Egal, beides koexistiert und erfüllt seinen Zweck!
- Fabric oder Mesh? – Kann man nicht so richtig vergleichen, beides koexistiert, oder beides wird nicht genutzt.
- Zentral oder dezentral organisiert? In der IT oder im Fachbereich angesiedelt? – Man benötigt jeweils beides, je nachdem.
Aus dem gefühlten Entweder-oder hat sich ein entspanntes Sowohl-als-auch ergeben, was ich sehr begrüßenswert finde.
### Neue Teamorganisation
Mit der Zeit ändern sich nicht nur Architekturen, sondern auch Teamorganisationen und Rollen. Gartner berichtet hier in einigen Vorträgen, wie die durchschnittliche Teamgröße der Data-&-Analytics-Funktionen in Unternehmen in Abhängigkeit von Umsatz oder Gesamtmitarbeiterzahl derzeit aussieht. Aber auch über beobachtete prozentuale Verteilungen von Data-&-Analytics-Rollen:
- Die klassischen Rollen wie Data Engineer, Data Analyst, Data Architect und Data Scientist dominieren weiterhin und machen fast 60 % aus.
- Neuere Rollen wie Model Validator oder AI Product Manager zeigen die wachsende Bedeutung von KI.
- Spannend sind auch neue Rollen an der Grenze zwischen Technik und Fachbereich wie z.B. der Data Translator. Der Data Translator soll als Rolle zwischen Technik und Fachbereich übersetzen, die Transformation vorantreiben, sich um die Themen Data Literacy und Data Culture kümmern und generell das Thema Data & Analytics voranbringen.
Solche Zahlen und Trends sind spannend und können als grobe Anhaltspunkte für die Größe und Aufgabenspektren seiner eigenen Data & Analytics Organisation dienen. Allerdings lassen sie auch die jeweiligen Eigenarten der eigenen Organisation außer Acht und haben vermutlich noch nicht die Einflüsse von KI mit eingepreist.
## Fazit
Alle paar Jahre lohnt sich der Besuch das Gartner Data & Analytics Summit, um sich in drei Tagen kompakt mit den aktuellen Trends und Themen auseinanderzusetzen. Nicht immer ist alles neu, aber es wird kompakt und sehr gut präsentiert und bietet einen vielfältigen und ganzheitlichen Blick auf die Dinge, und wie sie zusammenhängen. Natürlich darf man nicht vergessen, dass alles durch die Gartner-Brille präsentiert wird.
Es darf also immer hinterfragt werden, inwieweit der deutsche Markt und die eigene Organisation nicht doch ein wenig anders tickt als der Rest der Welt. Neben den Vorträgen war auch die Vielzahl der Aussteller beeindruckend und bot einen guten Überblick über die derzeitige Anwendungslandschaft.
**Kategorien:** AI & Data Science, Analytics & Insights, Tech Events & Networking
**Schlagwörter:** Analytics, Artificial Intelligence, Conference, Data, Data Governance, Data Observability, data science, Datenarchitekturen, Gartner, Konferenz, Summit
---
### [ACP-120 Erfahrungsbericht: Vom YouTube-Kurs zum Zertifikat](https://thecattlecrew.net/2025/06/17/acp-120-erfahrungsbericht-vom-youtube-kurs-zum-zertifikat/)
**Published:** Juni 17, 2025
**Author:** Mateusz Mis
**Content:**
Für alle, die sich gerade fragen, worum es hier überhaupt geht: ACP-120 ist die Zertifizierung für erfahrene Jira-Administratoren – offiziell nennt sich das Ganze **Atlassian Certified Cloud JIRA Administration**. Der Test richtet sich eigentlich an Profis, die mehrere Jahre tief in der Administration von Confluence und JIRA unterwegs sind. Leute, die Space Permissions im Schlaf konfigurieren und User Management mit verbundenen Augen erledigen. Kurz: eine Liga für sich.
Und dann – na ja… dann komme ich 😀
Ein Frischling mit großen Plänen. Keine jahrelange Berufserfahrung, keine tägliche Administration komplexer Instanzen. Nur Motivation, eine Portion Wahnsinn – und das unerschütterliche Vorhaben, mit einer metaphorischen Gabel gegen Windmühlen zu kämpfen. Oder eben mit einem veralteten YouTube-Kurs gegen einen Zertifizierungstest auf Expertenniveau.
## **Die Vorbereitung – zwischen Selbstzweifel und Copy-Paste-Taktik**
Es begann, wie viele Lernreisen anfangen: chaotisch. Ein halbstaubiger YouTube-Kurs, irgendwo aus der Vor-Migration-Ära, ein paar Mock-Tests auf Udemy (mal hilfreich, mal fragwürdig), und Artikel aus der Atlassian-Dokumentation, die wahrscheinlich zuletzt aktualisiert wurden, als Confluence noch ein Teenager war 😐
Das Fundament war also wackelig, aber ich hatte zwei Ass im Ärmel: Regelmäßigkeit und Sturheit. Kein Tag ohne Lernen. Kein Thema zu trocken. Permissions? Her damit. Schemes? Los geht’s. Ich klickte, las, testete – und machte Fehler. Viele. Aber ich machte sie konsequent, und das zählt.
## **Der Endspurt – aka Tag vor dem Examen**
Der letzte Tag glich einem Trainingslager. Vier komplette Mock-Exams, eins nach dem anderen. Kaffee, Schweiß und ein Kopf voller Shortcuts. Danach die härteste Disziplin: Fehleranalyse. Nicht nur „was war falsch?“, sondern „warum war’s falsch?“. Und wie kann ich das in 60 Sekunden erkennen, wenn’s drauf ankommt?
Die Synapsen glühten, die Konzentration hielt – und die Hoffnung wuchs.
## **Der Tag X – mit Sicherheitscheck und Nervenflattern**
Am Prüfungstag: Wiederholung bis zur letzten Sekunde. Frühstück? Vielleicht. Erinnerungen daran? Keine. Ich war voll im Tunnel.
Dann der Prüfungsstart – und das bedeutete: Willkommen im digitalen Hochsicherheitstrakt. Bevor ich auch nur *eine* Frage sehen durfte, wurde ich dazu aufgefordert, den Raum in unserem Büro zu scannen: Wände, Boden, Decke, Handgelenke, Ohren – ja, sogar unter den Schreibtisch musste ich filmen. Ich durfte nicht murmeln, nicht mit den Lippen bewegen – und mein Gesicht wurde so intensiv beobachtet wie beim Lügendetektortest. Ganz großes Kino.
Der Test selbst? Anspruchsvoll. Technisch, kontextbezogen, mit Zeitdruck. Die Fragen hatten nicht mal eine Antwort, sondern manchmal zwei bis vier. Nach der ersten Runde hatte ich alle Fragen beantwortet – aber innerlich war ich ein Fragezeichen auf zwei Beinen. Also: alles noch mal durchgehen. Prüfen, vergleichen, neu bewerten.
## **Und dann kam das WLAN (absolute cinema)**
Zehn Minuten vor dem Ende, ich hatte gerade die letzte Antwort überprüft – *plötzlich friert alles ein*. Eine Fehlermeldung: “WLAN Qualität ist zu schwach.“ Ich sehe meinen Bildschirm, aber niemand sieht mehr mich. Vorsichtshalber klicke ich auf “OK” und schreibe auf dem Live-Chat, dass ich eine seltsame Fehlermeldung bekommen habe und ob der Test noch läuft. Auf einmal, ohne ein Wort, schließt sich alles von selbst – der Prüfer beendet die Sitzung. Mein Herz setzt aus. Meine Hände schwitzen. Ich starre auf die Anzeige wie auf einen Krimi-Finale.
Schnell wieder eingeloggt. Hoffnungslos. Sicherheitsprüfung von vorn: Raum, Handgelenke, Ohren – ich hätte fast noch die Socken gezeigt, wenn es geholfen hätte 😀 Dann endlich: Ich darf wieder rein. Meine Antworten sind noch da. Noch 10 Minuten, um die restlichen Antworten zu prüfen – jede Sekunde mit dem Gedanken, dass gleich wieder alles unterbrochen werden kann – das würden meine Nerven nicht mehr aushalten, die des Prüfers wahrscheinlich auch. Ein letzter Klick. Und das Ergebnis – scrollen, scrollen – WO SIND DIE ERGEBNISSE, ah, ja, hier, am Ende.
Bestanden. 😮
## **Fazit und Ausblick**
Ich bin zwar kein Veteran der Jira Cloud-Administration, aber ich habe bewiesen, dass Ausdauer, Selbstdisziplin und Lernbereitschaft selbst die höchsten Hürden überwinden können. ACP-120 war kein Test – es war ein Statement.
Und das ist erst der Anfang. Ich bin bereit für mehr. Mehr Wissen. Mehr Zertifikate. Mehr Herausforderungen. Der Mond ist nicht genug – jetzt geht’s zu den Sternen <3
**Kategorien:** Cloud, Tools & Methoden
**Schlagwörter:** Administration, cloud, German, HowTo, Projektmanagement, zukunftswirksam
---
### [Bessere KI-Prompts erstellen – mit dem Prompt Engineering Maturity Model](https://thecattlecrew.net/2025/05/22/prompt-engineering-maturity-model-bessere-ki-prompts-erstellen/)
**Published:** Mai 22, 2025
**Author:** Falk Schramm
**Content:**
# Was ist Prompt Engineering und warum ist es interessant?
Künstliche Intelligenz ist derzeit in aller Munde. Jeder spricht über LLMs (Large Language Models) und die nahezu unbegrenzten Möglichkeiten, die sich damit eröffnen – von kreativen Texten, Zusammenfassungen langer Dokumente, künstlerischen Bildern bis hin zu vollständigen Reiseplänen. Das Potenzial scheint nur durch unsere Fantasie begrenzt.
Sobald es jedoch an die konkrete Nutzung von KI-Tools geht, fällt schnell ein Begriff: **Prompt**. Einfach gesagt sind Prompts die Anweisungen, die einem KI-System gegeben werden, um ein gewünschtes Ergebnis zu erzielen.
Wer sich intensiver mit der Materie beschäftigt, stellt fest: **Prompt Engineering** ist mehr als nur ein paar geschriebene Zeilen – es wird teils sogar als Tätigkeit von Datenanalysten und Software-Entwicklern betrachtet. Aber was steckt wirklich dahinter?
In Gesprächen mit Freunden und Kolleg:innen haben wir festgestellt, dass neben der Begeisterung über KI auch Frust über unklare oder enttäuschende Ergebnisse mitschwingt. Häufig liegt das am Prompt selbst – der lässt sich in vielen Fällen nämlich verbessern.
In diesem Beitrag möchten wir unsere Beobachtungen und Erfahrungen in einem **Prompt Engineering Maturity Model (PEMM)** zusammenfassen. Ziel ist es insbesondere, Perspektiven aufzuzeigen, wie du deine Prompts systematisch optimieren kannst, um auf deine Fragestellungen bessere Antworten zu erhalten.
# Überblick: Das Prompt Engineering Maturity Model (PEMM)
Unser Reifegradmodell umfasst vier Stufen, die wir im Folgenden vorstellen. In den darauffolgenden Abschnitten beschreiben wir jede Stufe ausführlich und zeigen konkrete Prompt-Beispiele.
1. **Ad-hoc-Prompts**: Einstieg ohne Systematik. Die Prompts sind spontan, kurz und unstrukturiert.
2. **Wiederholbare Prompts**: Erste Systematik. Du beginnst zu verstehen, was effektive Prompts ausmacht. Deine Prompts werden allmählich etwas länger.
3. **Standardisierte Prompts**: Du entwickelst eine persönliche Methodik und nutzt strukturierte Templates zum Schreiben von Prompts. Du erhältst verlässlich gute Ergebnisse bei komplexeren Fragestellungen.
4. **Datengetriebene Prompts**: Du misst und optimierst systematisch die Wirksamkeit deiner Prompts mit Metriken. In dieser Ausprägung ist das Schreiben von Prompts mit Softwareentwicklung vergleichbar.
Es geht nicht darum, jeden Prompt auf der höchsten Reifegradstufe zu formulieren. Entscheidend ist allein, dass der Prompt ein zufriedenstellendes Ergebnis für deine konkrete Fragestellung liefert.
## Stufe 1: Ad-hoc-Prompts – spontane Fragen, schnelle Antworten
Diese erste Stufe kennzeichnet den typischen Einstieg. Die Prompts sind oft nur ein oder zwei Sätze lang und entstehen spontan – etwa im Online-Meeting oder bei einer schnellen Recherche.
**Beispiele:**
- *Was ist ein ATS?*
- *Wie oft wurde Donald Trump zum US-Präsidenten gewählt?*
- *Wer ist reicher: Iron Man oder Batman?*
- *Bitte nenne mir fünf Gründe, warum ich einen Blogartikel schreiben sollte.*
Die Ergebnisse solcher Prompts sind nicht immer korrekt; kleine Tippfehler können große Auswirkungen haben: Vielleicht sollte im ersten Beispiel nach einem ATM gefragt werden? Im zweiten Beispiel kennen viele Modelle nur die erste Amtszeit von Donald Trump. Das liegt daran, dass die Trainingsdaten für ein LLM nur bis zu einem bestimmten Zeitpunkt reichen. Die Antworten auf Wissensfragen sollten daher immer sorgfältig geprüft werden.
Solche kurzen Prompts eignen sich für schnelle und generische Anfragen, Brainstorming oder auch Smalltalk-Fragen – nach der „Fictional 15“-Liste von Forbes ist Tony Stark übrigens etwas reicher als Bruce Wayne.
Eine weitere Beschränkung besteht darin, dass die Kontrolle über Länge und Form der Antwort begrenzt ist. Das LLM schöpft ohne Einschränkung aus seinem gesamten Wissen. Für kreative Zwecke mag dies gut funktionieren, für konkretere Fragestellungen ist dagegen mehr Kontrolle sinnvoll.
Übrigens: Unabhängig davon, ob du mit ChatGPT, Gemini, Claude oder einem anderen LLMs arbeitest, funktionieren die dargestellten Methoden bei allen Modellen.
## Stufe 2: Wiederholbare Prompts – erste Struktur und Kontrolle
Wer öfter mit LLMs arbeitet, wünscht sich bald mehr Kontrolle über Inhalt, Form und Länge der Antwort – ein erster Schritt beim Schreiben strukturierter Prompts.
**Beispiele:**
- *Erstelle eine Liste mit fünf negativen Eigenschaften von Superman und illustriere sie jeweils mit einem Beispiel. Die Liste soll prägnant sein und keine weitere Erklärungen enthalten.*
- *Bitte erzeuge eine Liste der zehn reichsten fiktiven Figuren, ihrem geschätzten Vermögen und dem Erfinder der Figur. Die Liste soll im JSON-Format erstellt werden.*
Die Formulierung von expliziten Anforderungen an die Ausgabe ist der Einstieg in das strukturierte Schreiben von Prompts. Auch einfache Kontextangaben verbessern die Ergebnisse deutlich:
- *Ich moderiere einen Kurs für Hobbymaler. Bitte generiere 10 Bildideen, basierend auf berühmten Kunstwerken.*
- *Ich möchte einen Webserver unter Linux aufsetzen. Leider bin ich sehr unerfahren mit Linux. Erstelle mir bitte eine Schritt-für-Schritt Anleitung, wie ich einen Webserver mit Linux aufsetzen kann.*
Das Beispiel zum Aufsetzen eines Webservers zeigt deutlich die Grenzen solcher Prompts bei komplexen Fragestellungen: Wir haben das Beispiel auf verschiedenen LLMs ausprobiert. Am Ende kam zwar immer irgendwie ein Webserver heraus, aber für echte Anfänger wären die Erklärungen nicht ausreichend gewesen; teilweise wurden zusätzlich Datenbanken oder Programmiersprachen installiert etc.
Als ein echter Booster für bessere Antworten hat sich „Role Play“ herausgestellt. Hier wird dem LLM eine Rolle zugewiesen. Probiere mal diese beiden Prompts aus:
- *Du bist ein erfahrener Lehrer für Programmierung mit Java. Bitte zeige und erkläre mir ein „Hello World“ Programm.*
- *Du bist ein ironischer Freund und Technikfreak. Bitte zeige und erkläre mir ein „Hello World“ Programm.*
Je komplexer und spezifischer eine Fragestellung ist, desto genauer muss der Prompt formuliert sein. Für präzise und konsistente Ergebnisse ist ein systematischer Ansatz notwendig – willkommen auf der nächsten Stufe.
## Stufe 3: Standardisierte Prompts – Methode statt Zufall
Mit wachsender Erfahrung entwickelst du eine eigene Methodik für die Erstellung effektiver Prompts. Ziel ist immer die zuverlässige Generierung qualitativ hochwertiger Ergebnisse.
### A. Struktur mit Prompt-Templates
Ein bewährter Ansatz ist die Verwendung von Templates. Es gibt sehr viele Prompt-Templates, die für unterschiedliche Fragestellungen entwickelt wurden. Um sich inspirieren zu lassen reicht schon eine einfache Suche nach *Prompt Templates*. Das Ausprobieren (und Lernen!) von neuen Templates macht Spaß und vertieft dein Verständnis von Prompts.
Ein vielseitig und allgemein nutzbares Template ist **RTCF** (Role – Task – Context – Format). Das Beispiel zeigt den Aufbau des Prompts.
**Aufbau eines RTCF-Prompts:**
```
Role:
– Du bist ein erfahrener Marketingspezialist.
– Du berätst deine Nutzer zu Unternehmenswebseiten.
Task:
– Hier steht eine Beschreibung der konkreten Aufgabe.
– Jede Teilaufgabe erhält einen eigenen Aufzählungspunkt.
Context:
– Deine Nutzer arbeiten in kleinen Unternehmen.
Format:
– Kurz, prägnant, vorzugsweise Listenform.
– Du präsentierst Ergebnisse ohne Erklärungen.
```
Ideen für eigene Versuche: Probiere RTCF-Prompts mit verschiedenen Themen aus. Variiere, wie knapp oder wie ausführlich die Angaben in den einzelnen Abschnitten formuliert sind.
### B. Tools zur Prompt-Erstellung
Viele Standard-UIs von Chatbots bieten keine gute Unterstützung für längere Prompts. Es lohnt sich daher, einen Editor (oder ein ähnliches Tool) zum Schreiben von Prompts zu nutzen. Den fertigen Prompt kopierst du dann auf einen Schlag in den Chatbot.
Ein Editor macht es leichter, umfangreiche eigene Inhalte in den Prompt zu integrieren. Denke etwa an die stichwortartige Mitschrift eines Meetings, dass du mit Hilfe des LLM in ein strukturiertes Protokoll überführen willst.
Die meisten Chatbots zudem bieten die Möglichkeit, Vorgaben für Chats zu konfigurieren (z.B. Customize ChatGPT, Gemini: Saved info). Dies ist sehr nützlich, um sich nicht ständig zu wiederholen. Ich habe in meiner Konfiguration z. B. hinterlegt, dass ich Python als Programmiersprache bevorzuge, Listen und knappe Erklärungen bevorzuge und keine langen Erklärungen und Beispiele will.
### C. Prompts testen und optimieren
Sobald Prompts regelmäßig verwendet werden, lohnt sich ein systematisches Testing. Du sparst damit Zeit, steigerst die Qualität und gewinnst Vertrauen in die Ergebnisse.
### D. Typische Anwendungsbereiche
Die Anwendungsfälle für standardisierte Prompts sind vielfältig. Die folgende Liste zeigt ausgewählte Fragestellungen, die auf dieser Stufe adressiert werden können.
- Erstellung von Blog- oder Social-Media-Inhalten
- Gliederung komplexer Dokumente
- Zusammenfassungen längerer Texte nach spezifischen Kriterien
- Analyse von Webseiten, Dokumenten oder Bildern
## Stufe 4: Datengetriebene Prompts – messen, analysieren, verbessern
Auf dieser Reifestufe nutzt du **Metriken und Datenanalysen**, um deine Prompts kontinuierlich zu verbessern. Statt Bauchgefühl und Trial-and-Error kommt ein Vorgehen ähnlich wie in der Softwareentwicklung zum Einsatz.
Die Leistung von Prompts wird systematisch mit Hilfe von Metriken und definierten Testfällen gemessen. Mittels Datenanalyse werden unterschiedliche Versionen des Prompts verglichen. In einem iterativen Prozess wird der effektivste Prompt entwickelt und optimiert. Eine Automatisierung dieses Verfahrens kann mit Hilfe fortgeschrittener Techniken wie der automatisierten Erstellung von Prompts erreicht werden.
Diese Stufe eignet sich besonders für **KI-Anwendungen im Unternehmenskontext**, bei denen Prompts für spezifische Aufgabenstellungen fest in eine Anwendung integriert werden. Die Nutzer müssen die Feinheiten des Prompts und seiner Erstellung nicht mehr verstehen und können sich ganz auf ihre fachlichen Tätigkeiten konzentrieren.
# Fazit: Wie du mit dem PEMM-Modell deinen Umgang mit Prompts verbesserst
Die Fähigkeit, LLMs effektiv zu nutzen, wird für Wissensarbeiter:innen heute und in Zukunft eine zentrale Kompetenz sein. Mit dem Prompt Engineering Maturity Model geben wir dir ein praxisnahes Werkzeug an die Hand, um deine Kompetenz beim Schreiben von Prompts weiterzuentwickeln.
Die Beispiele in diesem Artikel konzentrieren sich auf Prompts für „normale“ Chatbots. Viele Chatbots bieten inzwischen komplexe Tools wie z. B. *Canvas* oder *Deep Research* an, die über einen einfachen Chat hinausgehen. Prompts für solche Tools können ebenfalls mit den vorgestellten Ideen und Methoden erstellt werden. Zusätzlich sind natürlich die spezifischen Eigenschaften des jeweiligen Tools zu berücksichtigen.
Wie in vielen Bereichen ist **Learning by Doing** und **Erfahrung** der Schlüssel zum Erfolg. Das Lesen von Artikeln oder Ansehen von Tutorial-Videos alleine reicht nicht aus. Beobachte, reflektiere und verfeinere deine eigene Praxis kontinuierlich.
Wenn wir dich mit diesem Artikel ein wenig unterstützen konnten, effektive Prompts zu schreiben, haben wir unser Ziel erreicht. Wenn du möchtest, gib uns gerne Feedback in den Kommentaren.
---
*Die Bilder in diesem Artikel wurden mithilfe von Gemini generiert; Chat GPT half dabei, den Text hinsichtlich Lesefluss und SEO zu optimieren (und einige der aggressiveren Kürzungen und Zusammenfassungen wurden manuell wieder rückgängig gemacht)*
Diese Artikel könnten dich auch interessieren:
[To RAG or not to RAG (1/2)](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/)[Ein Bot mit echtem Security-Know-how](https://thecattlecrew.net/2024/02/09/ein-bot-mit-echtem-security-know-how/)
[Was steckt hinter RAG und Semantischer Suche?](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/)
**Kategorien:** AI & Data Science, Tools & Methoden
---
### [Kurzes Fazit zum DOAG Expertenseminar Forms 12c in Berlin](https://thecattlecrew.net/2017/07/14/kurzes-fazit-zum-doag-expertenseminar-forms-12c-in-berlin/)
**Published:** Juli 14, 2017
**Author:** Holger Lehmann
**Content:**
Am 11. und 12. Juli 2017 fand in den Räumen der DOAG in Berlin das Expertenseminar Forms 12c statt. Als Referenten waren Gerd Volberg und ich angereist, um 12 Teilnehmern unser geballtes Expertenwissen im Bereich Forms zu vermitteln. Wie wir später hörten, war das für eine solche Veranstaltung eine super Teilnehmerzahl, die in anderen Seminaren oft unterschritten wurde.
Wir haben für unsere Übungen und Seminarinhalte zwei Virtuelle Maschinen vorbereitet, die sich die Teilnehmer kopiert und später darin gearbeitet haben. Zu Beginn musste Gerd erst einmal wieder mit dem Vorurteil kämpfen, dass Oracle Forms nicht weiterentwickelt und daher das Produkt tot sei. Aufgeteilt haben wir uns in zwei verschiedene Themenbereiche. Während Gerd Vieles aus seinem Framework und seinen Best Practices gezeigt hat, habe ich den Part mit Forms 12c New Features und Installation übernommen.
Zitat von Gerd: Der Mix aus Forms 12 + Best Practices passt einfach sehr gut in die heutige Zeit. Die einen hätten gerne noch mehr New Features gehabt, die anderen noch mehr Best Practices „¦
Auch hat sich gezeigt, dass einige Teilnehmer noch vor der Migration auf die 12er-Version stehen und das bald angehen werden.
Unser Fazit ist klar: wir hätten das Ganze auch auf 3 Tage verteilen und ausweiten können! Die ganze Veranstaltung war super durchorganisiert und am Dienstag nach harter Arbeit hatten wir ein schönes Abendevent mit Führung durch den Reichstag und anschließendem Essen auf der Dachterrasse.
Viele Grüße
Holger
**Kategorien:** Development, Tech Events & Networking
**Schlagwörter:** DOAG, Forms, Oracle Forms
---
### [To RAG or not to RAG (2/2)](https://thecattlecrew.net/2025/05/15/to-rag-or-not-to-rag-2-2/)
**Published:** Mai 15, 2025
**Author:** Thomas Kerkmann
**Content:**
In [Teil 1](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/) dieses Zweiteilers haben wir gesehen, welche Aspekte berücksichtigt werden sollten, bevor man sich für eine RAG-Lösung (RAG = Retrieval-Augmented Generation) entscheidet. Der Aufwand ist nicht unerheblich, und die Vorbereitung der Dokumente erfordert ein hohes Maß an Anpassung.
Welche Prozesse wir in der Vorbereitung eines Dokuments genau durchlaufen müssen, darum geht es in diesem 2. Teil der Serie. Dafür sehen wir uns eine RAG-Pipeline genauer an, testen und bewerten unterschiedliche Ansätze.
# Was gehört zur RAG-Pipeline?
– Drei zentrale Schritte
Für die Aufnahme von Dokumenten in die Vektordatenbank müssen diese vorbereitet werden. Sie werden in ein Textformat konvertiert, in möglichst semantisch zusammenhängende Abschnitte aufgeteilt und dann vektorisiert:[](https://thecattlecrew.net/wp-content/uploads/2025/05/to-rag-or-not-to-rag.png)
*Abbildung 1: Vorbereitung eines Dokuments für eine Vektordatenbank*
## Schritt 1: Konvertierung
Die Konvertierung aus dem zumeist vorliegenden Dokumentformat PDF stellt die erste Hürde dar. Hierzu gibt es zwar einfache Tools (PdfBox, Apache Tika, …), die jedoch einige Schwierigkeiten beim „Druckformat“ PDF ausblenden, wie z. B. Kopf-/Fußzeilen. Diese werden einfach in den laufenden Text mit übernommen, was den Zusammenhang zerreißt. Weiterhin können Textstrukturierungen nicht erkannt und übernommen werden.
Bei unseren Tests haben wir festgestellt, dass es sinnvoll ist, Kopf- und Fußzeilen zunächst zu entfernen. Dazu wurde ein Algorithmus erstellt, der die ersten Zeilen jeder Seite miteinander vergleicht (übrigens auf Basis eines Embeddings und dann unter Verwendung des Cosinus-Abstands) und sie bei relativer Gleichheit als Kopf-/Fußzeile klassifiziert und entfernt.
Eine weitere Möglichkeit – die wir getestet haben – ist, den Text zunächst in das Markdown-Format umzuwandeln. Es gibt eine gute Python Bibliothek (pymupdf, pymupdf4llm), die dies kann. Die Umwandlung dauert länger, aber das Ergebnis lässt sich einfacher in Abschnitte mit Zusammenhang aufteilen.
Es gibt weitere Konzepte zur Umwandlung von Dokumenten in strukturierten Text, die auf OCR basieren, und zunächst versuchen, die Textblöcke eines Dokuments durch optische Analyse zu ermitteln, eine Reihenfolge herzustellen (z. B. bei mehrspaltiger Anordnung) und dann erst die Konvertierung vorzunehmen.
Vgl. RagFlow (open source),
oder Docupanda (kommerziell)
## Schritt 2: Splitting & Chunking
Wenn der Text keine Struktur mehr hat, wird es schwierig sinnvolle Gruppen von Text zu bilden. Wir haben unterschiedliche Ansätze getestet, die im Folgenden erläutert werden sollen.
### SentenceBasedTextSplitter
Dieser Splitter zerlegt den Dokument-Text in einzelne Sätze zur Weiterverarbeitung. Dabei wird eine NLP Bibliothek verwendet, z.B. „opennlp-de-ud-gsd-sentence-1.1-2.4.0.bin“. Diese ist für deutsche Texte optimiert.
Beispiel:
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
\#Satz1Lorem ipsum dolor sit amet, consectetur adipiscing elit.2Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.3Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.4Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.5Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.Dieser Splitter bildet die Basis der folgenden Splitter und wird nicht selbst direkt verwendet.
### Group
Der SimpleGroupTextsplitter bildet Gruppen von Sätzen einstellbarer Anzahl (3,5…?).
z. B. groupSize=3
GruppeSätze1Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.2Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.Die Idee ist eine größere, zusammenhängende Informationseinheit zu gewinnen. Der Nachteil ist jedoch, dass dieser Zusammenhang praktisch willkürlich gewählt wurde, allein durch die groupSize.
### Overlapped Group
Der OverlapGroupTextSplitter läßt diese Gruppen noch um eine bestimmte Anzahl an Sätzen (1,2…?) überlappen.
z.B. groupSize=3, overlap=1
GruppeSätze1Lorem ipsum dolor sit amet, consectetur adipiscing elit. Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. *Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.*2*Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.* Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.Die Intention dabei ist, den Kontextzusammenhang zwischen Gruppen von Sätzen nicht zu verlieren.
### Similarity
Der SimilarityTextSplitter versucht Gruppen von Sätzen anhand des Abstands ihrer Vektordarstellung (cosinus-distance) zu ermitteln. Die einstellbare Similarity bestimmt die Größe der Satzgruppen. Die Gruppen haben dann keine einheitliche Anzahl von Sätzen.
\#SätzeCosinus DistanzGruppe1Lorem ipsum dolor sit amet, consectetur adipiscing elit.012Sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.0.555123Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.0.457924Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.0.566935Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.0.63134Wenn man nun einen Schwellwert (similarity) von 0.5 annimmt, würde Satz 2 zu weit weg vom ersten Satz stehen, und damit dort eine neue Satzgruppe beginnen. Der nächste Satz (#3) liegt unterhalb des Schwellwertes, und wird daher der gleichen Gruppe zugeschlagen, usw.
Hier erhofft man sich durch die Ähnlichkeitssuche unter den Sätzen, einen realen Bruch im Zusammenhang zu ermitteln. Es wird also nicht mehr willkürlich eine Informationseinheit erstellt, sondern gezielt anhand von Brüchen im Kontext.
### Grouped Similarity
Der SentenceGroupSimilarityTextSplitter gruppiert Sätze, und bestimmt den Abstand der jeweiligen Satzgruppe zur nächsten. Darauf folgend wird der Splitting-Abstand (breakpointThreshold) aus der 95ten Percentile ermittelt. Der Ablauf ist also ähnlich wie beim SimilarityTextSplitter außer, dass der Splitting Schwellwert dynamisch ermittelt wird.
Von diesem Ansatz erhofft man sich, die Grenzen der Informationseinheiten im Text noch genauer zu erkennen.
Vergleiche auch verschiedene Splittling Algorithmen [hier](https://github.com/FullStackRetrieval-com/RetrievalTutorials/blob/main/tutorials/LevelsOfTextSplitting/5_Levels_Of_Text_Splitting.ipynb) (5 Levels of Text Splitting).
### Markdown
Der MarkdownTextsplitter benötigt als Eingabedateiformat wie der Name schon sagt Markdown Text.
Er verwendet als Trennzeichen die wichtigsten Strukturtags für Markdown. In unseren Test haben wir uns auf „#“, „##“, „###“ und „\*\*“ geeinigt. Man könnte sich in dem Fall auch Gedanken über weitere Merkmale zur Abgrenzung von Texteinheiten machen. Letztendlich geht es immer darum, Kontext zusammenzuhalten.
Das doppelte Sternchen wurde übrigens aufgenommen, weil die Umsetzung von Pdf zu Markdown oft fälschlicherweise die Klassifizierung ‚fett‘ für Absätze der vierten Ebene erkennt.
Des Weiteren wird eine maximale Chunk-Größe vorgegeben. (Derzeit fest auf 1024 Zeichen eingestellt.) Auch hier gibt es Optimierungs- bzw. Anpassungsbedarf.
## Schritt 3: Embedding
Nun erst erfolgt das Embedding, d. h. das Umwandeln der Textabschnitte in Vektoren und die Speicherung in der Vektordatenbank. Es gibt spezielle Modell für das Embedding, die wesentlich kleiner sind als die Modelle für die Generierung.
In diesem Schritt ist es entscheidend, wie gut das gewählte Embedding-Modell mit den Dokumenten zurechtkommt. Ausschlaggebend sind oft eine oder mehrere Sprachen, für die ein Modell optimiert wurde.
Wir verwenden gerne das Modell „jina/jina-embeddings-v2-base-de“, weil dieses Modell für Deutsch und Englisch trainiert wurde.
Beim Speichern in der Vektordatenbank werden noch weitere Metadaten zu den einzelnen Dokument-Abschnitten hinzugefügt, z. B. der originale Dateiname. Diese Metadaten erlauben die Ähnlichkeitssuche einzugrenzen, so dass diese effizienter wird. So können auch große Datenmengen mit gleichem Metadaten Schema sehr schnell durchsucht werden.
# Fazit
Für die Befüllung eines RAG müssen wor also eine Kette von Verarbeitungsschritten mit einer großen Menge an Stellschrauben durchlaufen.
Um in einem bestimmten Anwendungsfall das bestmögliche Ergebnis zu erhalten, ist es nötig,
- alle Parameter im Auge zu behalten, die Ergebnisse zu bewerten und ggf. immer wieder nachzujustieren.
- Im besten Fall lassen sich Zwischenergebnisse messbar miteinander vergleichen, um für die Gesamtmenge an Dokumenten durch Stichproben einen optimierten Parametersatz zu erstellen.
- Hierzu ist es dann notwendig, der Anwendung auch ein Tool zur Ermittlung und Verbesserung der Parameter hinzuzufügen. In unserem Testszenario haben wir diesem den Namen „parameter-tuning-service“ gegeben.
In Teil 1 haben wir bei der Betrachtung der Daten und deren Mengen gesehen, welche Aspekte für die Entscheidung für oder gegen RAG wichtig sind.
Teil 2 zeigte uns wie hoch der Entwicklungaufwand für die Vorverarbeitung der Dokumente sein kann, denn es gibt nicht „die“ Methode, die für alle Dokumentformate das beste Ergebnis liefert.
Weitere Methoden werden sicherlich in Zukunft noch entwickelt werden. Komplexe Dokumente mit Hilfe von OCR Technologien zu analysieren ist sicherlich nur der Anfang. Bereits heute sehen wir, dass KI gestützte Analyse ebenfalls möglich ist, jedoch unter Kostenaspekten noch viel zu teuer für große Mengen.
Unter all diesen Bedingungen ist die Frage „To RAG or not to RAG“ nicht so einfach zu beantworten. Schon gar nicht allgemein. Sie hängt von vielen Faktoren ab, und die Entscheidung dafür oder dagegen hat große Auswirkung auf die Gestaltung der Anwendung und deren Erstellungs- und Betriebskosten.
# Mehr zum Thema
[RAG or not to RAG, Teil 1: Wann braucht es einen RAG-Ansatz](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/)
[RAG or not to RAG, Teil 2: Prozesse und Aufwand in der Praxis](https://thecattlecrew.net/2025/05/15/to-rag-or-not-to-rag-2-2/)
[Was steckt hinter RAG und Semantischer Suche?](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/)
[RAG und Semantische Suche in der Praxis](https://thecattlecrew.net/2024/01/29/spezialwissen-fuer-chatbots/)
**Kategorien:** AI & Data Science
**Schlagwörter:** Artificial Intelligence, RAG, Retrieval Augmented Generation
---
### [To RAG or not to RAG (1/2)](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/)
**Published:** Mai 8, 2025
**Author:** Thomas Kerkmann
**Content:**
In zwei vorangegangenen Artikeln von Falk Schramm wurden bereits einige [Grundlagen zu generativer KI und RAG](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/) angesprochen. Mit meiner Artikelserie **„To RAG or not to RAG“** möchte ich den Fokus noch einmal besonders auf diese Fragen bezüglich Retrieval Augmented Generation (RAG) richten:
- Welche Aufwände und Prozesse bringt RAG mit sich?
- Braucht es immer einen RAG-Ansatz? Wann ist er sinnvoll ist und wann vielleicht eher nicht?
Doch auch in dieser Serie fangen wir zunächst vorne an und ich erkläre, was RAG ist und wofür es eingesetzt wird. Wer sich hier bereits auskennt, darf natürlich gerne weiter unten einsteigen.
# Was ist RAG?
RAG (Retrieval Augmented Generation) erweitert das „Wissen“ eines LLM (Large Language Model) durch Spezialwissen, welches sich nicht im gelernten Wissen eines LLM befindet oder nur unzureichend abgebildet ist, z. B. aufgrund des Veröffentlichungsdatums des LLM. Dieses Spezialwissen kann auch firmeninternes Wissen sein, das in Form von Dokumenten in Formaten wie PDF, DOCX oder MD (Markdown) vorliegt. Wenn es für die Bearbeitung durch ein LLM bereitgestellt werden soll, muss es in eine Form gebracht werden, die das Modell versteht. Dafür eignen sich sogenannte Vektor-Datenbanken. Über eine semantischen Suche können hier große Mengen an Text verfügbar gemacht werden. So können relevante Textteile bereitgestellt werden, die ein LLM braucht, um seine Antworten zu generieren.
*Abbildung 1: Die Schritte vom Wissen zur Antwort (Bild-Quelle: [https://huggingface.co/learn/cookbook/advanced\_rag):](https://huggingface.co/learn/cookbook/advanced_rag)*
1. Dokumente werden zunächst zerteilt (chunking),
2. in einen Vektor überführt (embedding)
3. und dann in der Vektordatenbank abgespeichert.
4. Bei der Abfrage (query) werden zunächst relevante Chunks in der Vektordatenbank gesucht (similarity search)
5. und die besten Matches (top k) dem Kontext hinzugefügt.
6. Aus diesen Inhalten generiert das LLM nun seine Antwort.
# Warum RAG?
Wenn es nur darum ginge, ein Dokument in den Kontext des LLM zu stellen und es analysieren zu lassen, wäre es einfach. Doch leider gibt es technische Einschränkungen: Das Modells kann nämlich nur eine limitierte Menge an Informationen verarbeiten.
Deshalb kann es nützlich sein, wenn man große Mengen an Informationen auswerten möchte, diese in semantische Blöcke aufzuteilen. Mittels RAG lassen sich diese vorselektieren und passend zur gewünschten Aufgabe auswählen.
## Welche Begrenzung gibt es genau?
Ein wichtiger Begriff, wenn wir über die Begrenzung der Informationsmenge sprechen, ist **das Kontextfenster**: Es begrenzt die Anzahl der Token, die von einem Modell verarbeitet werden können. Dabei müssen die Eingabe- und Ausgabe-Token zusammengerechnet werden, um die Grenzwerte einzuhalten. Die Kontextfenster der aktuellen Modelle haben sich erheblich erweitert:
**Modell****Kontextfenster in Tokens****entspricht Text**GPT-32.000ca. 2-3 SeitenGPT-3.5-Turbo Instruct4.000ca. 3.000 Worte (englisch), 6 SeitenMistral Tiny (7B)8.000ca. 6.000 Worte, 12 SeitenGPT-48.000ca. 6.000 Worte, 12 SeitenLlama 38.192ca. 6.000 Worte, 12 SeitenGPT-3.5 Turbo16.000ca. 12.000 Worte, 24 SeitenMistral Small16.000ca. 12.000 Worte, 24 SeitenMistral Medium32.000ca. 24.000 Worte, 48 SeitenGemini Pro32.000ca. 24.000 Worte, 48 SeitenGPT-4-32k32.000ca. 24.000 Worte, 48 SeitenClaude 2100.000ca. 75.000 Worte, 150 SeitenGPT-4-Turbo128.000ca. 96.000 Worte, 192 SeitenLlama 3.1128.000ca. 96.000 Worte, 192 SeitenClaude 2.1200.000ca. 150.000 Worte, 300 SeitenGemini 1.5bis zu 1.000.000ca. 750.000 Worte, 1500 SeitenDemgegenüber stehen aber auch unterschiedliche Kosten, die zu berücksichtigten sind. Diese sind von Anbieter zu Anbieter verschieden, daher können wir diese hier nicht im Einzelnen darstellen. Quellen im Internet finden sich leicht.
Nun stellt sich die Frage: Setze ich auf größere Kontextfenster? Oder arbeite ich mit kleinen Kontextfenstern, und setze auf semantische Suche? Hier die drei wichtigsten Vor- und Nachteile beider Varianten auf einen Blick sowie passende Anwendungsfälle:
### Größere Kontextfenster – Vorteile
1. **Verbesserte Kohärenz bei langen Inhalten:** Größere Kontextfenster ermöglichen es dem Modell, mehr Informationen zu speichern und zu verarbeiten, was für die Erstellung kohärenter und detaillierter Antworten in langen Dokumenten oder Gesprächen unerlässlich ist. Dies ist vorteilhaft für Anwendungen wie das Zusammenfassen langer Artikel, das Erstellen juristischer Verträge oder die Bearbeitung langer Kundensupport-Chats, bei denen Kontinuität entscheidend ist.
2. **Verbesserte Informationsspeicherung:** Mit einem größeren Fenster können LLMs mehr historische Eingaben referenzieren, wodurch sie den Kontext über lange Interaktionen hinweg beibehalten können. Dies ist nützlich für Konversations-Agenten, für die Beantwortung von Fragen, die mehrere Runden umfassen, oder für die Zusammenfassung umfassender Berichte.
3. **Geringerer Bedarf an Kürzung:** Bei umfangreichen Texten müssen bei kleineren Kontextfenstern oft Teile der Eingabe gekürzt oder ausgelassen werden, was zu unvollständigen oder ungenauen Antworten führen kann. Ein größeres Fenster kann einen größeren Teil des Eingabetextes umfassen, wodurch das Risiko verringert wird, wichtige Details zu übersehen.
### Größere Kontextfenster – Nachteile
1. **Höhere Rechenkosten:** Die Verarbeitung größerer Kontextfenster erfordert mehr Rechenressourcen, was zu längeren Antwortzeiten und höheren Kosten führt. Dies kann sich bei Echtzeitanwendungen oder bei begrenztem Budget negativ auswirken.
2. **Erhöhtes Risiko irrelevanter Informationen:** Ein größeres Fenster kann auch mehr irrelevante Inhalte enthalten, die das Modell ablenken und die Qualität der Antwort beeinträchtigen können. Modelle mit großen Kontextfenstern müssen sorgfältig geführt werden, um sich auf die wichtigsten Teile der Eingabe zu konzentrieren.
3. **Komplexität in der Prompt-Entwicklung:** Größere Kontextfenster können die Gestaltung von Prompts komplexer machen. Denn es ist herausfordernd, umfangreiche Eingaben kohärent zu strukturieren. Prompt-Designer müssen die enthaltenen Informationen sorgfältig abwägen, um das Modell nicht mit überflüssigen Details zu überfrachten.
### Kleinere Kontextfenster – Vorteile
1. **Geringere Latenz und Kosteneffizienz:** Kleinere Kontextfenster erfordern weniger Rechenressourcen, was zu schnelleren Verarbeitungszeiten und niedrigeren Betriebskosten führt. Dies ist vorteilhaft für Anwendungen, die zahlreiche Anfragen schnell bearbeiten müssen.
2. **Gezielte Antworten:** Ein kleineres Fenster kann dazu beitragen, den Fokus des Modells auf den unmittelbarsten und relevantesten Kontext einzugrenzen, wodurch die Gefahr der Einführung von nicht verwandten Inhalten verringert wird. Dies ist oft von Vorteil bei Anwendungen wie dem kurzen Austausch mit dem Kundensupport oder schnellen Antworten in Q&A-Systemen.
3. **Einfachheit in der Implementierung:** Bei kleineren Fenstern ist die Erstellung von Eingabeaufforderungen in der Regel einfacher. Die Gefahr, das Modell mit fremden Informationen zu überfrachten, ist geringer, was die Einrichtung erleichtert und oft zu konsistenteren Antworten führt.
### Kleinere Kontextfenster – Nachteile
1. **Begrenzte Informationskapazität:** Der größte Nachteil kleinerer Kontextfenster ist die geringere Informationskapazität. Dies kann zu unzusammenhängenden oder sich wiederholenden Antworten führen, wenn das Modell nicht in der Lage ist, ausreichend Kontext über eine lange Eingabe zu speichern.
2. **Häufiges Abschneiden in großen Dokumenten:** Bei einem begrenzten Token-Limit müssen kleinere Fenster häufig abgeschnitten werden, was dazu führen kann, dass kritische Details ausgelassen werden, was die Qualität der Antworten in Anwendungen, die eine umfassende Analyse oder Synthese großer Texte erfordern, verringert.
### Anwendungsfälle für größere Kontextfenster
Bestimmte Anwendungen eignen sich besser für größere Kontextfenster, insbesondere bei der Verarbeitung umfangreicher Textdaten oder wenn die Beibehaltung von Informationen über lange Eingaben unerlässlich ist:
1. **Dokumentenzusammenfassung:** Bei der Zusammenfassung langer Inhalte, wie z. B. Forschungsarbeiten oder juristische Dokumente, muss das Modell umfangreichen Text ohne Abschneiden berücksichtigen, was von einem größeren Kontextfenster erheblich profitieren kann.
2. **Detaillierte Konversationen:** In Anwendungen für den Kundensupport oder virtuelle Assistenten, bei denen die Benutzer längere Interaktionen mit mehreren Umdrehungen durchführen, hilft ein größeres Kontextfenster dem Modell, die Kontinuität und den Kontext der Konversation über die Zeit zu erhalten.
3. **Datenextraktion und -analyse:** In Fällen, in denen das Modell Informationen aus großen Datensätzen oder Dokumenten extrahiert, z. B. aus medizinischen Berichten oder Jahresabschlüssen, stellt ein größeres Kontextfenster sicher, dass keine wichtigen Informationen ausgelassen werden.
### Anwendungsfälle für kleinere Kontextfenster
Kleinere Kontextfenster können dagegen gut in Anwendungen funktionieren, die schnelle Antworten benötigen, bei denen die Ressourcen begrenzt sind oder bei denen knappe Informationen ausreichen:
1. **Echtzeit-Q&A-Systeme:** Anwendungen, die einfache Fragen beantworten, können oft effektiv in kleineren Kontextfenstern funktionieren. Beispiele hierfür sind schnelle Fragen des Kundendienstes oder einfache FAQ-Bots.
2. **Klassifizierung von Kurztexten:** Aufgaben wie Spam-Erkennung, Stimmungsanalyse oder Kurztextklassifizierung erfordern keine umfangreichen Kontextfenster. Das Modell muss nur kurze Nachrichten oder Phrasen verarbeiten, weshalb ein kleineres Kontextfenster ideal ist.
3. **Transaktionsbezogene Interaktionen:** Anwendungen, die kurze, transaktionale Interaktionen verarbeiten (z. B. Restaurantreservierungen oder Wetteraktualisierungen), benötigen im Allgemeinen keinen umfangreichen Kontext. Kleinere Fenster rationalisieren die Antworten und reduzieren die Verarbeitungszeit.
Quelle: [Medium Artikel „Understanding Context Windows in LLMs“, Tahier Saeed](https://medium.com/@tahir.saeed_46137/understanding-context-windows-in-large-language-models-llms-4ad3dca6b86f)
## Welche Rolle spielt die Performance?
Große Informationsmengen enthalten natürlich nicht immer nur relevante Inhalte zu einer bestimmten Fragestellung. Es ist daher vorteilhaft, zunächst die Inhalte zu ermitteln, die mit der Anfrage in Zusammenhang stehen. Insbesondere für die Performance der Anwendung ist dies enorm wichtig.
Hier hilft der RAG-Ansatz: Basierend auf einer Ähnlichkeitssuche (Similarity Search) werden nur jene Inhalte in das Kontextfenster importiert, die in einem relevanten Zusammenhang mit der Anfrage stehen. Diese Suche findet statt, bvor das LLM eine Antwort generiert. Sie ist ein rein mathematischer Vergleich von Vektoren und damit viel performanter, als die Auswertung der gesamten Datenmenge.
Daraus resultieren
- ein reduzierter Tokenverbrauch,
- eine geringere Netzwerklatenz
- und damit schnellere Reaktionszeiten bei der Generierung der Antwort.
Vektordatenbanken sind auf diese Suche spezialisiert. Es gibt Extensions für bekannte Datenbanksysteme wie Postgres oder Oracle, aber auch speziell für diesen Zweck entwickelte Datenbanken wie [Weaviate](https://weaviate.io/) oder [Chroma](https://trychroma.com/) (beide Open Source) und auch kommerzielle Produkte.
# Fazit: Wann setzte ich RAG ein?
So kommt man schlussendlich zu der Frage: Benötige ich für meinen Anwendungsfall ein RAG oder nicht? Welche Aspekte müssen dabei berücksichtigt werden?
## Wie groß sind meine Daten/Dokumente?
Macht eine Zerlegung Sinn, oder passen sie einfach in ein Kontext-Fenster des LLM meiner (Kosten-)Vorauswahl.
## Wie volatil sind die Daten/Inhalte? Werden sie oft geändert, oder sind sie statisch?
Bei sich oft ändernden Daten muss man sich überlegen, ob das erneute Verarbeiten der Ausgangsdaten durch eine andere Speicherung und Filterung verbessert werden kann. Hier ist vielleicht die Vektordatenbank nicht unbedingt das geeignete Mittel. Durch den Einsatz sogenannter Tools im LLM kann auch auf andere Datenbanken mit eigenen Filter Werkzeugen zugegriffen werden (ElasticSearch, OpenSearch, Solr, …).
## Handelt es sich um strukturierte oder unstrukturierte Inhalte?
Strukturierte Inhalte lassen sich gut zerlegen und in einer Vektordatenbank abspeichern. Unstrukturierte Inhalte verlangen unter Umständen viel Probieren, um die optimalen Zerlegungsparameter zu bestimmen. Wenn die Dokumentgröße und die Kosten es zulassen, könnte es hier einfacher sein, das Dokument direkt an das LLM zu übergeben.
## Wie langlebig oder kurzlebig sind meine Daten und Dokumente (Gültigkeitsdauer, Ablaufdatum)?
Kurzlebig gültige Daten sollten aus Gründen der Performance der Vektordatenbank nach Ablauf der Gültigkeit wieder entfernt werden. Hier ist der jeweilige Aufwand dafür abzuschätzen. Bei kleineren Dokumenten kann auch hier ggf. auf ein RAG verzichtet werden.
## Wie oft greife ich auf diese Daten mit Hilfe der KI zu?
Wenn viele Zugriffe auf die gleichen Daten erfolgen, hat das RAG einen Vorteil, da es Rechenleistung beim LLM einspart, und somit die Antwortzeiten und Kosten geringhält.
Wenn die Daten nur selten oder sogar nur einmalig ausgewertet werden sollen, kann auch hier eine Vektordatenbank unter Umständen gar nicht erforderlich sein.
# Weiterlesen …
Wenn ein RAG zum Tragen kommen soll oder muss, kommt der **Pre-Production-Prozess** aus Abbildung 1 (siehe oben) zum Einsatz.
**Lesen Sie im zweiten Teil dieser kleinen Artikelserie:**
- Wie die Prozessschritte im Einzelnen aussehen
- und worauf dabei zu achten ist
[RAG or not to RAG, Teil 2](https://thecattlecrew.net/2025/05/15/to-rag-or-not-to-rag-2-2/)
**Kategorien:** AI & Data Science
**Schlagwörter:** Artificial Intelligence, RAG, Retrieval Augmented Generation
---
### [RAG und Semantische Suche in der Praxis](https://thecattlecrew.net/2024/01/29/spezialwissen-fuer-chatbots/)
**Published:** Januar 29, 2024
**Author:** Falk Schramm
**Content:**
# Chatbots für Spezialwissen – Teil 2 Umsetzung
Neben KI-Themen, mit denen ich mich auch privat gerne beschäftige, ist Cybersecurity mein zweites großes Interessengebiet. Aus Erfahrung weiß ich daher, dass vielen IT’lern und IT’lerinnen das Lesen von formellen Security-Anforderungen keinen Spaß macht. Zudem ist der Zugang zu Security-Standards oft nicht einfach. Diese Schwachstelle wollen wir mit einem Chatbot abstellen, der bei der Nutzung der IT-Grundschutz-Bausteine unterstützt.
[Teil 1: Was Sie über Retrieval Augmented Generation, Semantische Suche und Prompts wissen sollten: Versuch einer verständlichen Erklärung](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/ "Artikel ansehen")
Teil 2: Im zweiten Teil stellen wir unser internes Projekt Chatbot für IT-Grundschutz vor und geben einen Überblick über die Herausforderungen, die sich im Rahmen des (noch andauernden) Projekts ergeben haben.
In weiteren Artikeln gehen wir auf tiefergehende Erfahrungen und Lösungsansätze mit unterschiedlichen Implementierungen und Technologien ein.
## Ein Chatbot für den IT-Grundschutz
### IT-Grundschutz – umfangreich und komplex
Beim [IT-Grundschutz](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html) handelt es sich um einen Security-Standard, der vom [Bundesamt für Sicherheit in der Informationstechnik](https://www.bsi.bund.de/) herausgegeben wird. Ein wichtiger Bestandteil des IT-Grundschutzes sind die sogenannten Bausteine. In einem Baustein werden alle relevanten Sicherheitsaspekte zu einem Thema beleuchtet, z. B. Server, Datenbanken, Firewalls, Administration etc.
Da es im IT-Grundschutz mehr als 100 Bausteine gibt, ist es selbst für einen erfahrenen Security-Consultant schwer, alle Maßnahmen korrekt und vollständig im Kopf zu haben. Für „normale“ IT-Mitarbeitende, die den IT-Grundschutz in seinem Bereich umsetzen muss, erscheint dies nahezu unmöglich.
### Was soll der Chatbot für den IT-Grundschutz leisten?
Die Aufgabe unseres **Chatbots für den IT-Grundschutz** ist es, Security-Beauftragte bzw. IT-Mitarbeitende beim Umgang mit den IT-Grundschutz-Bausteinen zu unterstützen. Er soll zu allen Fragen, die die Bausteine betreffen, verlässliche, also korrekte und vollständige Antworten liefern. Hier sind ein paar Beispiele für solche Fragen:
- Welche Gefährdungen bestehen in einer konkreten Situation?
- Welche Maßnahmen sind in einer bestimmten Situation relevant?
- Wie ist eine Maßnahme genau formuliert?
Eine Besonderheit der Bausteine besteht darin, dass ein Thema zwar vollständig beleuchtet wird, aber in der Regel in einer konkreten Situation mehrere Bausteine zu berücksichtigen sind. Möchte man zum Beispiel einen Kubernetes-Cluster absichern, sind neben dem „eigentlichen“ Kubernetes-Baustein weitere Bausteine zur Administration, Containerisierung, Virtualisierung etc. anzuwenden. Das muss der Chatbot in seinen Antworten natürlich berücksichtigen.
Neben dem fachlichen Ziel, einen Chatbot zu bauen, nahmen wir uns vor, Technologien, Frameworks und Lösungsansätze für die Architektur zu evaluieren, die die die Funktionen des Large Language Models ergänzt. Eine der wichtigsten dieser Funktionen ist die *Retrieval Augmentation Generation (RAG)*.
### Ansätze für die Implementierung
In diesem Projekt untersuchen wir parallel zwei technologische Ansätze:
- Der erste Ansatz basiert auf einer möglichst weitgehenden Nutzung von Azure Cognitive Services und der Vermeidung von individuell erstelltem Code.
- Der zweite Ansatz basiert auf einer möglichst weitgehenden Nutzung von Open-Source-Technologien (u. a. [Langchain](https://python.langchain.com/docs/get_started/introduction)) und der Verwendung von Python als Programmiersprache.
In beiden Fällen nutzten wir primär Chat GPT als LLM (in verschiedenen [Versionen](https://platform.openai.com/docs/models)). Die Evaluation weiterer LLM (Llama 2, Mistral, Falcon etc.) ist zu einem späteren Zeitpunkt ebenfalls geplant.
## Herausforderungen
Unabhängig von den genutzten Technologien gibt es vielfältige fachliche Herausforderungen. Diese ergeben sich insbesondere daraus, dass die vom Chatbot gelieferten Antworten ***in Bezug auf das Spezialwissen IT-Grundschutz korrekt und vollständig*** sein müssen. Antworten, die nicht auf dem IT-Grundschutz sondern auf dem Allgemeinwissens des LLM beruhen, wären also aus Sicht der Aufgabenstellung fehlerhaft.
Um dem LLM die IT-Grundschutz-Bausteine zugänglich zu machen, nutzen wir einen auf *Retrieval Augmented Generation (RAG)* basierenden Ansatz für die Implementierung. Dabei gibt es mehrere wesentliche Stellschrauben:
- Bereitstellung der Wissensbasis (Chunking)
- Auswahl des Embeddings
- Abfrage der Wissensbasis
- Anweisungen an das LLM
Die ersten beiden Stellschrauben sind weitgehend unabhängig von der zur Implementierung genutzten Technologie und sollen im Folgenden beleuchtet werden. Zu den Punkten *Abfrage der Wissensbasis* und *Anweisungen an das LLM* sind eigenständige Blog-Artikel geplant.
### Bereitstellung der Wissensbasis (Chunking)
Das durch den Chatbot zu erschließende Spezialwissen kann in unterschiedlichen Formaten vorliegen. Neben Websites, PDF- und Word-Dokumenten können dies Datenbanken, DWHs und viele weitere Formate sein. Neben reinen Texten sind zudem vielfach Bilder und Tabellen in den Dokumenten enthalten.
Da eine LLM hauptsächlich Texteingaben versteht, liegt die erste Herausforderung darin, die Ausgangsdokumente konsequent in Textform zu überführen. Damit verknüpft sind Fragen nach der Behandlung von Überschriften, Fußzeilen, Referenzen und Metadaten. Denn diese enthalten in der Regel wichtige inhaltliche Informationen. Für HTML- und andere XML-basierten Dokumente kommt die Frage dazu, wie mit Tags umgegangen wird. Auch Tags können wichtige Aspekte eines Textes darstellen.
### Fragmente bilden
Um das Embedding sinnvoll durchführen zu können, müssen die in Textform überführten Dokumente zunächst in kleinere Fragmente zerlegt werden, sogenannte Chunks. In vielen Beispielen und Demos wird hierfür die Strategie gewählt, Chunks mit einer festen Länge (z. B. 1000 Zeichen) und einer definierten Überlappung angrenzender Chunks (z. B. 300 Zeichen) zu verwenden.
Wie sich in unserem Projekt schnell gezeigt hat, ist solch ein „blindes Chunking“ keine optimale Strategie, wenn es um korrekte Aussagen geht: Ein Chunk, der das Ende des einen und den Anfang des nächsten Kapitels umfasst, ist nicht sinnvoll.
Lesson learned: **Chunks sollten die Struktur der Kapitel, Abschnitte und Absätze in einem Dokument respektieren**.
Ein weiteres Thema beim Bilden der Fragmente ist die Behandlung von Überschriften und anderen Strukturierungselementen im Text. Die Identifikation von Kapitel- und Abschnittsüberschriften ist auf der Ebene von Strings ein erstaunlich komplexes Problem: Überschriften sehen aus wie ein sehr kurzer Absatz. Für unseren Chatbot für IT-Grundschutz haben wir deshalb letztlich auf die Nutzung der vom BSI bereitgestellten PDF-Dokumente verzichtet und verwenden stattdessen die XML-Fassung des IT-Grundschutzkompendiums. Aus der XML-Fassung lassen sich Kapitel, Abschnitte und Absätze mit wenig Aufwand präzise extrahieren.
### Auswahl des Embeddings
Es gibt eine Vielzahl von Embeddings, die teilweise mit sehr unterschiedlichen Zielen trainiert werden. Neben den Trainingszielen spielen auch die Trainingsdaten eine wichtige Rolle: So kommt ein ausschließlich mit englischen Trainingsdaten erstelltes Embedding mit der deutschen Sprache oft nicht gut zurecht.
Lesson learned: **Die Auswahl und Optimierung des Embeddings ist eine der wichtigsten Entscheidungen, die bei der Erstellung einer Wissensbasis getroffen werden muss.**
Um ein optimales Ergebnis zu erzielen, müssen verschiedene *Embeddings* in Kombination mit unterschiedlichen Varianten für das Chunking objektiv bewertet werden. Für eine erste grobe Einschätzung des Embeddings ist eine manuelle Bewertung ausreichend. In der Optimierungsphase stößt sie dagegen schnell an ihre Grenzen.
Lesson learned: **Für die Optimierung von Embeddings sollte eine automatisierte Bewertung verschiedener Varianten erfolgen.**
Die automatisierte Bewertung von Embeddings ist eine eigenständige Aufgabe im Projekt. Sie beinhaltet unter anderem die Erstellung von Trainingsdaten, die (naturgemäß) abhängig vom Spezialwissen sind, das mit dem Chatbot erschlossen werden soll.
Damit der Artikel nicht zu lang wird, wollen wir an dieser Stelle die Darstellung der Herausforderungen unterbrechen. Weitere Herausforderungen und unsere Lösungsansätze werden wir Ihnen in Folgeartikeln vorstellen.
## Fazit
In diesem zweiteiligen Beitrag haben wir zunächst die Konzepte beleuchtet, die es ermöglichen, das Allgemeinwissen eines LLM um Spezialwissen zu einem bestimmten Thema zu erweitern. Anschließend haben wir unser internes Projekt „Chatbot für den IT-Grundschutz“ vorgestellt und sind auf einige der Herausforderungen eingegangen, die sich während der Implementierung gezeigt haben. Die Darstellung ist bei weitem nicht vollständig und wir planen Folgeartikel, die auf weitere Herausforderungen und die untersuchten Implementierungsvarianten eingehen.
Die möglichen Einsatzgebiete eines „Chatbots mit Spezialwissen“ sind ebenso vielfältig wie die Wissensdomänen, die innerhalb eines Unternehmens vorhanden sind. Wir sehen wir zwei grundsätzliche Treiber für den Einsatz solcher Chatbots.
Der erste Treiber ist die Erschließung/Aufrechterhaltung von Wissen, für das in der Organisation kein oder nur wenige Wissensträger vorhanden sind. Ein typisches Beispiel sind ältere Legacy-Technologien, deren ursprünglichen Entwickler in den Ruhestand gegangen sind oder inzwischen in anderen Bereichen arbeiten. Die Dokumentation der Legacy-Technologien ist ein interessantes Ziel für Chatbots. Sie können eine wertvolle Unterstützung bei der Erschließung und Nutzung der Dokumentation darstellen.
Der zweite Treiber ist die Entlastung/Produktivitätssteigerung von Fachteams, die umfangreiches Wissen benötigen. Beispiele hierfür sind alle Arten von Support-Teams und Teams, die Kunden fachlich beraten und unterstützen. Der Einsatz von Chatbots mit Spezialwissen fördert die Qualität und Effizienz bei der Beantwortung komplexer Fragen. Die unterstützt sowohl erfahrene Mitarbeiter wie auch neue Mitarbeiter. Diese können mit Unterstützung eines Chatbots schneller produktiv werden.
Aus technologischer Seite sind Chatbots mit Spezialwissen ebenfalls ein interessantes Thema. Die Technologien, die solche Chatbots ermöglichen, sind größtenteils noch ziemlich neu und werden ständig weiterentwickelt. Es lohnt sich daher am Ball zu bleiben. Wir jedenfalls sind gespannt, was die Zukunft bringen wird!
[Teil 1: Was Sie über Retrieval Augmented Generation, Semantische Suche und Prompts wissen sollten: Versuch einer verständlichen Erklärung](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/ "Artikel ansehen")
# Mehr zum Thema
[RAG or not to RAG, Teil 1: Wann braucht es einen RAG-Ansatz](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/)
[RAG or not to RAG, Teil 2: Prozesse und Aufwand in der Praxis](https://thecattlecrew.net/2025/05/15/to-rag-or-not-to-rag-2-2/)
[Was steckt hinter RAG und Semantischer Suche?](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/)
[RAG und Semantische Suche in der Praxis](https://thecattlecrew.net/2024/01/29/spezialwissen-fuer-chatbots/)
**Kategorien:** AI & Data Science
**Schlagwörter:** Generative AI, IT-Grundschutz, LLM, Prompt, Retrieval Augmented Generation, Semantische Suche
---
### [Was steckt hinter RAG und Semantischer Suche?](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/)
**Published:** Januar 29, 2024
**Author:** Falk Schramm
**Content:**
# Chatbots für Spezialwissen – Teil 1: Konzepte
Wenn es um Chatbots geht, geistern seit einige Zeit Begriffe wie Retrieval Augmented Generation (RAG), Semantische Suche und Large Language Model (LLM) durch die Medien. Mit Hilfe dieser Techniken sollen Chatbots Fragen beantworten können, auf die herkömmliche Suchmaschinen keine oder nur unzureichende Antworten anbieten. Was steckt dahinter?
In diesem Zweiteiler möchte ich zunächst kurz vorstellen, was genau sich hinter RAG, Semantischer Suche und den Prompts des LLM verbirgt. Anschließend werden Implementierungsansätze und Herausforderungen beim produktiven Einsatz beleuchtet. Wir haben die Techniken selbst ausprobiert und teilen unsere Erfahrungen mit Ihnen.
Teil 1: Was Sie über Retrieval Augmented Generation, Semantische Suche und Prompts wissen sollten: Versuch einer verständlichen Erklärung
[Teil 2: Im zweiten Teil stellen wir unser internes Projekt Chatbot für IT-Grundschutz vor und geben einen Überblick über die Herausforderungen, die sich im Rahmen des (noch andauernden) Projekts ergeben haben.](https://thecattlecrew.net/2024/01/16/spezialwissen-fuer-chatbots/ "Artikel ansehen")
In weiteren Artikeln gehen wir auf tiefergehende Erfahrungen und Lösungsansätze mit unterschiedlichen Implementierungen und Technologien ein.
## Retrieval Augmented Generation
Öffentlich verfügbare LLM (wie z.B. das vielzitierte ChatGPT) besitzen auf Grund ihres Trainings eine große Menge an Allgemeinwissen. Obwohl dieses Wissen nicht immer korrekt und vollständig ist, reicht es für eine unverbindliche Unterhaltung locker aus. Für den produktiven Einsatz sind Korrektheit und Vollständigkeit der Antworten eines Chatbots jedoch unverzichtbare Kriterien. Man denke beispielsweise an einen Chatbot, der auf Anfragen von Kunden reagiert.
Am Beispiel des Chatbots für Kundenanfragen lässt sich auch eine weitere Problematik veranschaulichen: Trotz des umfangreichen Allgemeinwissens besitzt ein LLM kein Spezialwissen über das Angebot eines Unternehmens. Dieses Spezialwissen muss für den Chatbot in Form einer Wissensbasis verfügbar gemacht werden.
Das durch einen Chatbot zu erschließende Spezialwissen ist dabei nicht auf Angebote eines Unternehmens beschränkt: Informationen aus dem Intranet, interne Dokumente, externe Standards (DIN, ISO etc.) , Tickets zu Supportanfragen, Foren und vieles mehr kommt als Quelle für Spezialwissen in Frage.
Die Nutzung von Spezialwissen zur Beantwortung von Anfragen ist der Use Case für Retrieval Augmented Generation (RAG). Dahinter steckt die Idee, dass das LLM die Eingabe des Nutzers nicht direkt beantwortet. Stattdessen werden vorher aus der Wissensbasis relevante Informationen (Textstellen) als Kontext für die Beantwortung der Nutzereingabe extrahiert. Das LLM wird angewiesen, diesen Kontext für die Beantwortung zu verwenden und sein Allgemeinwissen nicht oder erst in zweiter Linie zu nutzen.
Die folgende Grafik illustriert die Schritte, die im Einzelnen durchlaufen werden.
## Semantische Suche
Die Auswertung der Wissensbasis und das Ermitteln der relevanten Kontexts ist Aufgabe der Semantischen Suche. Eine einfache Stichwortsuche à la Google reicht nämlich typischerweise nicht aus: Der Nutzer formuliert seine Anfrage umgangssprachlich und in seinen eigenen Worten. Er kennt und verwendet möglicherweise nicht die „richtigen“ Stichwörter.
Eine numerische Bewertung, wie ähnlich sich zwei Texte im Hinblick auf ihren Inhalt sind, ist eine seit langem untersuchte Fragestellung in der Linguistik. Im Kontext der Sprachverarbeitung durch Computer (NLP, Natural Language Processing) erfolgt diese Bewertung anhand von Embeddings. Dafür wird ein Text in einen Zahlenvektor umgewandelt und so, mathematisch gesprochen, der Text in einen Vektorraum „eingebettet“ (engl. Embedding). Diese Vektorräume besitzen im Unterschied zu unser 3-dimensionalen Welt höhere Dimensionen. Typische Werte sind etwa 768, 1024 oder 1536.
Der Abstand zwischen zwei Texten lässt sich nun als Abstand der Textvektoren numerisch berechnen. Die „Magie“ des Embeddings besteht darin, dass inhaltlich ähnliche Texte in Textvektoren umgewandelt werden, die kleine Abstände voneinander haben. Beispielsweise werden die Texte „Ich mag meinen Hund“ und „Ich mag meinen vierbeinigen Freund.“ einen kleineren Abstand besitzen als die Texte „Ich mag meinen Hund.“ und „Ich mag indisches Essen.“
Für die semantischen Suche wird die Eingabe des Nutzers mit Hilfe des Embeddings in einen Textvektor umgewandelt und mit den Vektoren aus der Wissensbasis verglichen. Die der Eingabe am nächsten liegenden Vektoren/Texte werden als Ergebnis der semantischen Suche zurück geliefert.
Wie Embeddings genau funktionieren, kann hier nicht dargestellt werden. Embeddings sind ein sich schnell entwickelndes Thema der aktuellen Forschung. Für den interessierten Leser empfehlen wir die Webseite [SBERT](https://www.sbert.net/) und das [METB-Leaderboard](https://huggingface.co/spaces/mteb/leaderboard) der Plattform HuggingFace als Einstieg in eine Vertiefung.
## Prompts: Anweisungen an das LLM
LLM sind im Kern nur eine komplexe statistische Methode, um aus einer natürlich sprachigen Eingabe, dem Prompt, eine Ausgabe zu erzeugen. Im Falle von Retrieval Augmented Generation besteht der Prompt aus der Nutzereingabe, dem ermittelten Kontext und Anweisungen für die Beantwortung.
Warum sind Anweisungen notwendig? Genau wie Menschen brauchen LLMs eine klare Aufgabenbeschreibung: Wie soll geantwortet werden, wenn der Kontext für die Beantwortung einer Frage nicht ausreicht? Wie soll mit Anfragen umgegangen werden, die sich nicht auf die Wissensbasis beziehen? Wie soll geantwortet werden, wenn der Nutzer nach einem Konkurrenzprodukt fragt? Dies und weitere Fragen sind für den produktiven Einsatz eines Chatbots zu klären.
Welche Anweisungen dem LLM gegeben werden, hängt vom jeweiligen Use Case und den Nutzern des Chatbots ab: Wenn die Nutzer des Chatbots Kunden eines Unternehmens sind, werden an Korrektheit, Vollständigkeit und Verhalten bei „Out-of-Topic“ Anfragen hohe Anforderungen gestellt.
Wenn die Nutzer des Chatbots dagegen ein internes Expertenteam sind (z.B. eine Fachabteilung), könnte beispielsweise die Behandlung von „Out-of-Topic“ Anfragen ausgelassen werden. Auch Anforderungen an Vollständigkeit und Korrektheit stellen sich möglicherweise anders dar.
Das Verständnis dieser weniger Konzepte reicht bereits aus, um die grundlegende Funktion von Chatbots mit Spezialwissen zu verstehen. Wie schlagen sich diese Konzepte in der Praxis? Welche Herausforderungen und Lösungsansätze gibt es?
[Teil 2: Im zweiten Teil stellen wir unser internes Projekt Chatbot für IT-Grundschutz vor und geben einen Überblick über die Herausforderungen, die sich im Rahmen des (noch andauernden) Projekts ergeben haben.](https://thecattlecrew.net/2024/01/16/spezialwissen-fuer-chatbots/ "Artikel ansehen")
In weiteren Artikeln gehen wir auf tiefergehende Erfahrungen und Lösungsansätze mit unterschiedlichen Implementierungen und Technologien ein.
# Mehr zum Thema
[RAG or not to RAG, Teil 1: Wann braucht es einen RAG-Ansatz](https://thecattlecrew.net/2025/05/08/to-rag-or-not-to-rag-1-2/)
[RAG or not to RAG, Teil 2: Prozesse und Aufwand in der Praxis](https://thecattlecrew.net/2025/05/15/to-rag-or-not-to-rag-2-2/)
[Was steckt hinter RAG und Semantischer Suche?](https://thecattlecrew.net/2024/01/29/was-steckt-hinter-rag-und-semantischer-suche/)
[RAG und Semantische Suche in der Praxis](https://thecattlecrew.net/2024/01/29/spezialwissen-fuer-chatbots/)
**Kategorien:** AI & Data Science
**Schlagwörter:** Artificial Intelligence, LLM, Prompts, RAG, Semantische Suche, Spezialwissen
---
### [Visuelle Analysen mit Open Source BI Tools – Teil 2: Plotly Dash](https://thecattlecrew.net/2024/01/18/38426/)
**Published:** Januar 18, 2024
**Author:** Nicolas Schaefer
**Content:**
Im ersten Teil unserer Blogserie haben wir uns mit der Erstellung interaktiver Grafiken unter Verwendung des Open-Source Visualisierungstools Plotly befasst. Diese Grafiken bieten bereits einige Funktionalitäten wie z. B. Mouse-Over oder Zoom, jedoch fehlt die Möglichkeit, die angezeigten Daten durch User-Input anzupassen.
In diesem Beitrag gehen wir den nächsten Schritt und zeigen, wie man diese Grafiken mit Plotly Dash in interaktiven Dashboards nutzen kann. Nach einer Einführung in den Aufbau und die Gestaltung einer Dash App werden wir einen kurzen Vergleich zum Arbeiten mit Tableau ziehen und einen Ausblick zum effektiveren Arbeiten mit Dash durch das Nutzen von KI geben.
Doch warum überhaupt Plotly Dash?
- Dash ist wie die Visualisierungsbibliotheken von Plotly auch ein Open-Source Framework und damit grundsätzlich kostenlos nutzbar.
- Es ermöglicht die Entwicklung von interaktiven Dashboards Apps nativ in Python, ohne dass Kenntnisse in anderen Programmiersprachen für Front-End Gestaltung nötig sind. Für tiefergehende Anpassungen können aber CSS oder JavaScript Bestandteile eingebunden werden.
- Dash nutzt Plotly Grafiken und erweitert diese um Input Möglichkeiten wie z.B. Dropdown Filter, Schieberegler oder andere reaktive Elemente.
- Dash Code kann seit Version 2.11 direkt in Jupyter Notebooks ausgeführt werden und ermöglicht so schnelle und aussagekräftige Visualisierungen mit Dashboards in Data Science Kontexten.
# Implementieren einer Dash App
Wir stellen im Folgenden den Aufbau einer Dash-App vor.
## App Layout
Es folgt ein Beispiel für eine Basis Dash App (siehe Abbildung 1), die eine einzige Plotly Grafik anzeigt, ohne eine Möglichkeit für User-Input. Nach dem Importieren der benötigten Bibliotheken und dem Initialisieren einer leeren App wird ein Sub-Dataframe erstellt. Dieser basiert auf dem Superstore Sample Dataset. Dann wird ein statischer Barplot erstellt und das App Layout definiert. In einem div HTML-Element wird die erstellte Grafik referenziert und für spätere Anpassungen HTML Klassen definiert.
```
```
from dash import Dash, html, dcc, Input, Output
import plotly.express as px
``` #app init app = Dash(__name__) #sub dataframe df_bar_plot = df.groupby(['Category', 'Sub-Category']).agg({'Sales': 'sum', 'Profit': 'sum'}).reset_index() # create a static plot fig = px.bar(df_bar_plot, x='Category', y='Sales', color='Sub-Category', barmode='stack', text='Sub-Category') fig.update_traces(textposition='auto', textfont_size=10, width=0.8) fig.update_xaxes(tickangle=45) #define app layout app.layout = html.Div([ dcc.Graph(id='bar-plot', figure=fig, className='full-width-graph') ], className='main-container') #run app if __name__ == '__main__': app.run_server(debug=True, port=8081)
```
Nach dem Ausführen der Dash App sieht das Resultat wie folgt aus.
Abbildung 1: Basis-App mit einem Barchart
Die resultierende App unterscheidet sich auf den ersten Blick nicht von einer einfachen Plotly Grafik. Im unteren Bereich finden sich jedoch 3 Icons, die den Dash Status wiedergeben. Zum einen den Status des Servers, der in diesem Fall der lokale Rechner ist, dann mögliche Fehler und zuletzt vorhandene Callbacks.
## Multi-Page Apps
In Dash ist es auch möglich Apps mit mehreren Seiten zu erstellen. Das Navigieren kann über Links und Klickpfade erfolgen. Ein Layout mit einzelnen Tabs pro Seite ist genauso möglich. Der Aufbau einer Multi-Page App kann in drei Layout Elemente unterteilt werden:
1. Das Hauptlayout, das den Aufbau der App und Unterseiten beschreibt. In diesem Beispiel werden für die App drei Seiten jeweils als Tab festgesetzt und mit Label versehen.
```
app.layout = html.Div([
dcc.Tabs(id="tabs", value='tab-1', className='dash-tab-label' ,children=[
dcc.Tab(label='Sales by Category', value='tab-1'),
dcc.Tab(label='Sales by State', value='tab-2'),
dcc.Tab(label='Product Analysis', value='tab-product-analysis')
]),
html.Div(id='tabs-content')
])
```
2\. Den Seitenlayouts die aufgerufen werden, wenn ein Tab oder eine Seite aufgerufen wird.
```
elif tab == 'tab-1':
return html.Div([
html.Div([
html.Label('Year', className='dropdown-label'),
dcc.Dropdown(
id='year-dropdown',
options=year_options,
value=years[0],
clearable=False,
className='dropdown-quarter-width'
)
], className='dropdown-container'),-content')
])
```
3\. Den Callbacks der einzelnen Seiten, die auch miteinander verknüpft sein können. Wie diese funktionieren wird im nächsten Abschnitt erklärt.
Abschließend zum Thema Multi-Page Apps noch ein Beispiel, wie eine Tab-basierte App aussehen kann. Im oberen Reiter kann auf die einzelnen Seiten zugegriffen werden
Abbildung 2: Tab-basierte Dash-App mit drei Seiten
## Interaktivität durch Callbacks
Callbacks ermöglichen eine Interaktion des Users mit den angezeigten Daten. Über z.B. das Auswählen von Werten in einem Dropdown Filter oder das Bewegen eines Sliders werden bestimmte Elemente eines Dashboards aktualisiert und die Darstellung angepasst. Der Code im folgenden Block generiert drei Callbacks für das zuvor gezeigte Basis Dashboard.
```
@app.callback(
Output('bar-plot', 'figure'),
[Input('year-dropdown', 'value'),
Input('sub-category-dropdown', 'value'),
Input('profit-range-slider', 'value')]
)
def update_bar_chart(selected_year, selected_sub_categories, selected_profit_range):
# Filter based on the selected year
filtered_df = df[df['Order Date'].dt.year == selected_year]
# Aggregate data
agg_df = filtered_df.groupby(['Category', 'Sub-Category']).agg({'Sales': 'sum', 'Profit': 'sum'}).reset_index()
# Apply sub-category filter if sub-categories are selected
if selected_sub_categories:
agg_df = agg_df[agg_df['Sub-Category'].isin(selected_sub_categories)]
# Filter sub-categories based on total profit
agg_df = agg_df[(agg_df['Profit'] >= selected_profit_range[0]) &
(agg_df['Profit']
**Kategorien:** Analytics & Insights, Tools & Methoden
**Schlagwörter:** Open Source, Python, Reports
---
### [Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
**Published:** März 18, 2025
**Author:** Torsten Jaeschke
**Content:**
Die Sicherheit von Kubernetes-Umgebungen ist keine einmalige Aufgabe, sondern ein **dynamischer und kontinuierlicher Prozess**. Wer Kubernetes produktiv einsetzt, weiß: Es reicht nicht aus, die Cluster-Umgebung einmal sicher zu konfigurieren – Bedrohungen entwickeln sich weiter, und mit ihnen die Abwehrstrategien. In dieser Blogserie haben wir die größten Sicherheitsrisiken, bewährte Schutzmaßnahmen und innovative Strategien beleuchtet. Zum Abschluss ziehen wir in diesem siebten und letzten Teil der Serie ein Fazit und werfen einen Blick auf zukünftige Entwicklungen.
---
*Sie steigen gerade erst ein? Hier finden Sie Teil 1 bis 6 dieser Serie sowie das Video des Webcasts, auf dem die Serie aufbaut:*
[*Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie*](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[*Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen*](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[*Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren*](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[*Video: Kubernetes Security Webcast*](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
## 1. Risiken erkennen und proaktiv gegensteuern
Kubernetes-Cluster sind hochattraktive Ziele für Angreifer. Eine ungesicherte API-Schnittstelle, falsch konfigurierte RBAC-Rollen oder ein kompromittierter Container – oft reicht ein einziges Einfallstor, um Zugriff auf das gesamte Cluster zu erlangen. Neben bekannten Bedrohungen wie Container Escape Attacks oder Kryptomining rücken Supply-Chain-Angriffe und Insider-Bedrohungen zunehmend in den Fokus.
**Praxisbeispiel:** Ein IT-Team stellte fest, dass ein Entwickler versehentlich ein Kubernetes-Manifest mit hartkodierten Zugangsdaten in ein öffentliches GitHub-Repository hochgeladen hatte. Innerhalb weniger Stunden tauchten verdächtige Container im Cluster auf, die Krypto-Mining-Software ausführten. Nur durch schnelle Reaktionsmaßnahmen – Rotieren aller Secrets, Isolieren der betroffenen Pods und ein forensisches Log-Review – konnte ein größerer Schaden verhindert werden.
###  **Lösungsansatz**
Unternehmen sollten regelmäßig Security Audits durchführen, Least-Privilege-Richtlinien implementieren und den Zugriff auf Cluster-Ressourcen strikt beschränken.
## 2. Automatisierung und Kontrolle im Fokus
Um Kubernetes sicher zu betreiben, müssen Best Practices nicht nur definiert, sondern auch automatisiert und regelmäßig überprüft werden.
**Hier einige Kernstrategien:**
- Minimaler Zugriff (Least Privilege): Berechtigungen granular verwalten und regelmäßig auditieren.
- Security-Scans automatisieren: Container-Images und Infrastruktur als Code kontinuierlich scannen.
- Netzwerksegmentierung optimieren: Klare Trennung zwischen internen und externen Services.
- RBAC-Richtlinien gezielt überwachen: Unerwünschte Privilegien mit Automatisierungstools aufdecken.
- Echtzeit-Logging & Alerting ausweiten: Sicherheitsrelevante Ereignisse sichtbar machen und mit Eskalationsstufen kombinieren.
### **Technik-Tipp**
Ein oft übersehener Bereich ist die sichere Container-Registry. Images sollten nur aus vertrauenswürdigen Quellen bezogen und durch Signaturen abgesichert werden, um Manipulationen zu erkennen und kompromittierte Anwendungen zurückzuweisen.
## 3. Sicherheitsvorfälle effizient im Griff mit Incident Response
Angriffe lassen sich nie komplett verhindern – entscheidend ist, wie schnell und strukturiert darauf reagiert wird. Unternehmen, die ihre Incident-Response-Prozesse regelmäßig testen und optimieren, sind klar im Vorteil.
### Best Practices für eine effektive Reaktionsstrategie
- Zentrales Logging: Alle sicherheitsrelevanten Events mit Loki, Elasticsearch oder Splunk erfassen.
- Automatisiertes Alerting: Kritische Ereignisse mit Prometheus, Grafana und SIEM-Systemen eskalieren.
- Forensik-Analysen stärken: Langfristige Audit-Logs für retrospektive Untersuchungen archivieren.
- Tabletop-Exercises und Angriffssimulationen: Sicherheitsvorfälle regelmäßig durchspielen, um Abläufe zu verbessern.
### **Praxisbeispiel:**
In einem Unternehmen wurde eine Sicherheitslücke im Kubernetes-Cluster übersehen, die es Angreifern ermöglichte, sensible Daten zu exfiltrieren. Da das Team gut vorbereitet war, konnten Logs innerhalb weniger Minuten ausgewertet, der betroffene Pod isoliert und die Schwachstelle innerhalb von Stunden geschlossen werden. Ohne diesen klaren Incident-Response-Plan hätte es mehrere Tage kosten können.
## 4. Zero Trust in Kubernetes: Der nächste Schritt
Das klassische Perimeter-Sicherheitsmodell hat ausgedient. Zero Trust geht davon aus, dass kein Benutzer oder System von Natur aus vertrauenswürdig ist. Dieses Konzept gewinnt in Kubernetes-Umgebungen zunehmend an Bedeutung.
### Kernstrategien für Zero Trust in Kubernetes
- Pod-Sicherheitsrichtlinien verschärfen: Nur notwendige Berechtigungen und Ressourcen zuweisen.
- IAM-Optimierung: Adaptive Rollenverwaltung und regelmäßige Überprüfung von Berechtigungen.
- Workloads verschlüsseln: Daten bei der Übertragung und im Ruhezustand absichern.
- Service Meshes nutzen: Istio oder Linkerd zur Absicherung von Service-Kommunikation einsetzen.
### Technik-Tipp
eBPF-basierte Sicherheitsmechanismen ermöglichen eine tiefgehende Überwachung der Systemprozesse, ohne die Performance zu beeinträchtigen.
## 5. Zukunftsausblick: Kubernetes-Sicherheit im Wandel
Die Kubernetes-Sicherheitslandschaft entwickelt sich stetig weiter. Diese Trends werden in den kommenden Jahren prägend sein:
- KI-gestützte Threat Detection: Machine Learning für Anomalie-Erkennung in Echtzeit.
- Policy-as-Code: Sicherheitsrichtlinien als Code standardisieren und versionieren.
- eBPF-basierte Überwachung: Effiziente Laufzeit-Sicherheitsanalysen mit minimalem Overhead.
- Self-Healing-Infrastrukturen: Automatisierte Reaktionen auf Sicherheitsvorfälle.
###  Praxisbeispiel
Einige Unternehmen setzen bereits auf AI-basierte Sicherheitslösungen, die Kubernetes-Logs in Echtzeit analysieren und verdächtiges Verhalten automatisch erkennen. Der Vorteil? Sicherheitsvorfälle können erkannt und automatisiert eingedämmt werden, noch bevor Schaden entsteht.
## Fazit: Kubernetes-Sicherheit ist ein dynamischer Prozess
Kubernetes-Sicherheit bedeutet **kontinuierliches Lernen**, **Optimieren** und **Automatisieren**. Wer sich allein auf einmalige Maßnahmen verlässt, läuft Gefahr, überrollt zu werden. Erfolgreiche Unternehmen setzen auf eine Kombination aus **Best Practices**, **Automatisierung** und **proaktiver Überwachung**:
**Jetzt heißt es:**
- Sicherheitskonzepte aus dieser Blogserie in die Praxis umsetzen.
- Bestehende Sicherheitsmechanismen regelmäßig evaluieren und weiterentwickeln.
- Den technologischen Wandel aktiv mitgestalten.
**Die Devise: Nicht nur auf Angriffe reagieren, sondern immer einen Schritt vorausdenken!**
---
### Noch einmal nachlesen? Hier finden Sie alle Artikel dieser Serie:
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
Einen Blick wert: Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
Mit diesem letzten Teil endet unsere Blogserie zur Kubernetes-Sicherheit – doch der Schutz Ihrer Cluster ist ein fortlaufender Prozess.
Nutzen Sie die Erkenntnisse aus dieser Serie, optimieren Sie Ihre Sicherheitsstrategien und bleiben Sie Angreifern immer einen Schritt voraus. **Bleiben Sie wachsam, bleiben Sie sicher – und diskutieren Sie mit uns weiter über die Zukunft der Kubernetes-Sicherheit!**
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Unerlaubte Zugriffe in Kubernetes: Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
**Published:** Februar 7, 2025
**Author:** Torsten Jaeschke
**Content:**
Unerlaubte Zugriffe zählen zu den häufigsten und gefährlichsten Sicherheitsbedrohungen in Kubernetes-Umgebungen. Ohne eine granulare Zugriffskontrolle können Angreifer schnell Schwachstellen ausnutzen, um Zugang zu sensiblen Ressourcen zu erhalten. Wie im klassischen IT-Betrieb sind klare Zugriffsbeschränkungen unerlässlich, doch Kubernetes bringt zusätzliche Herausforderungen und Chancen mit sich.
In diesem zweiten Teil unserer Serie zu Kubernetes Security erfahren Sie:
- Warum unautorisierte Zugriffe ein Risiko darstellen.
- Welche Tools und Methoden Sie nutzen können, um Zugriffe granular zu kontrollieren.
- Wie Sie Ihre Umgebung effektiv absichern können.
---
*Sie steigen gerade erst ein? Hier finden Sie Teil 1 mit einer Übersicht zur Serie sowie den Link zu unserem Webcast, auf dem die Serie aufbaut:*
[*Kubernetes-Sicherheit im Fokus: Best Practices und Strategie*](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[*Kubernetes Security Webcast*](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
## Warum granularer Zugriffsschutz entscheidend ist
Anders als bei herkömmlichen IT-Systemen müssen Kubernetes-Cluster viele verschiedene Komponenten absichern: Pods, Nodes, Secrets und APIs. Ohne abgegrenzte Autorisierung können selbst interne Nutzer oder Anwendungen versehentlich Sicherheitslücken öffnen.
## Effektive Schutzmaßnahmen im Detail
### 1. Granulare Zugriffskontrolle mit RBAC (Role-Based Access Control)
RBAC Autorisierung ist ein Kubernetes Bordmittel. Es ermöglicht, den Zugriff auf Kubernetes-Ressourcen für Benutzer und Anwendungen zu reglementieren. So stellen Sie sicher, dass jeder nur das tun kann, was unbedingt erforderlich ist.
**Beispiel:**
Der folgende YAML-Ausschnitt erstellt eine Rolle, die nur Lesezugriff auf Pods erlaubt:
```
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: development
name: pod-reader
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
```
Zusätzlich hilft **Kubescape**, um sicherzustellen, dass RBAC-Policies korrekt angewendet werden. Führen Sie dazu einfach den folgenden Befehl aus:
```
kubescape scan framework rbac
```
### 2. Richtlinien für den Netzwerk-Zugriff
Wie die RBAC gehören auch die Network Policies zu den Kubernetes Bordmitteln. Sie regeln den Cluster-internen IP- und Port-Zugriff und verhindern, dass Pods und Services unkontrolliert miteinander kommunizieren. Ein Beispiel: Nur Pods mit der Rolle „backend“ dürfen auf eine Datenbank zugreifen:
```
kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
name: allow-backend-to-database
namespace: production
spec:
podSelector:
matchLabels:
app: database
ingress:
- from:
- podSelector:
matchLabels:
role: backend
```
### 3. Admission Policies zur Absicherung
Admission Controller prüfen API-Anfragen und verhindern nicht autorisierte Aktionen. Mit **Kyverno** können Sie beispielsweise sicherstellen, dass nur Images aus einem vertrauenswürdigen Repository genutzt werden:
```
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: restrict-image-repo
spec:
rules:
- name: validate-image-repo
match:
resources:
kinds:
- Pod
validate:
message: "Images must be from trusted.registry.com."
pattern:
spec:
containers:
- image: "trusted.registry.com/*"
```
## Zusammenfassung
Eine Kombination aus RBAC, Admission Policies und Netzwerkisolation bietet eine starke Verteidigung gegen unautorisierte Zugriffe. Tools wie **Kubescape** und **Kyverno** erleichtern die Umsetzung und sorgen für eine kontinuierliche Überwachung.
## Kubernetes-Sicherheit weiterdenken!
Kubernetes mit seinen Bordmitteln ist mächtig – aber auch anfällig für Bedrohungen. In unserer Artikelserie beleuchten wir kritische Sicherheitsaspekte und zeigen praxiserprobte Lösungen.
Freuen Sie sich auf weitere Analysen, Best Practices und konkrete Codebeispiele zu diesen wichtigen Themen:
- Sichere Architektur für Kubernetes-Cluster
- Bedrohungserkennung in Echtzeit
- Sicherheitsmaßnahmen direkt in den Entwicklungsprozess einbinden
---
## Die Blog-Serie komplett
Hier finden Sie alle Teile unserer siebenteiligen Blog-Serie:
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
Einen Blick wert: Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
Haben Sie eigene Erfahrungen oder Fragen? Teilen Sie sie in den Kommentaren oder kontaktieren Sie uns. Gemeinsam stärken wir Ihre Kubernetes-Sicherheit!
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Unsichere Kubernetes-Systeme absichern: Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
**Published:** Februar 14, 2025
**Author:** Torsten Jaeschke
**Content:**
**Unsichere Systeme** sind eine tickende Zeitbombe in Kubernetes-Umgebungen. Fehlerhafte Konfigurationen, veraltete Images oder unzureichende Ressourcenbegrenzungen bieten eine breite Angriffsfläche. In diesem dritten Teil unserer Serie zu Kubernetes Security zeigen wir Ihnen, wie Sie mit den richtigen Tools und Best Practices Ihre Umgebung absichern und automatisieren können.
---
*Sie steigen gerade erst ein? Hier finden Sie Teil 1 und 2 dieser Serie sowie das Video des Webcasts, auf dem die Serie aufbaut:*
[*Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie*](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[*Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen*](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[*Video: Kubernetes Security Webcast*](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
## **Schwachstellen frühzeitig erkennen und beheben**
Mit automatisierte Schwachstellenscans und Ressourcenlimits und Quotas können Sie viel für die Sicherheit Ihrer Systeme erreichen. Aber bei der Aufsetzung ist einiges zu beachten. Darum geht es:
### **1. Automatisierte Schwachstellenscans**
**Container Scanning und Sicherheitsrichtlinien:** Manuelles Überprüfen ist ineffizient – automatisierte Tools wie **Trivy** oder **Clair** bieten hier entscheidende Vorteile. Sie scannen Container-Images auf bekannte Sicherheitslücken und lassen sich in CI/CD-Pipelines integrieren:
Beispiel für **Trivy** in einer Pipeline:
```
scan:
stage: security
image: aquasec/trivy:latest
script:
- trivy image my-image:latest
```
Ergänzend dazu hilft **Kubescape**, Sicherheitsrichtlinien auf Clusterebene zu überprüfen, indem es ermöglicht den Cluster gegen verschiedene Sicherheitsframeworks zu testen.
Kubescape bietet bisher Unterstützung für folgende Frameworks:
- NSA – basiert auf dem Kubernetes Hardening Guide der NSA und CISA
- MITRE – basiert auf dem MITRE ATT&CK® Framework
- CIS – basiert auf den CIS Benchmarks für Kubernetes und ist in drei Varianten vertreten: für Standard Kubernetes, und für Managed Kubernetes jeweils in Azure oder in AWS
Eine Auflistung der unterstützen Frameworks kann über folgenden Aufruf angezeigt werden:
```
kubescape list frameworks
```
Es ist ebenfalls möglich mit einem Aufruf auf unterschiedlichen Frameworks zu testen. Dazu werden die Frameworks kommasepariert im Scan-Befehl aufgeführt:
```
kubescape scan framework nsa,mitre,cis-v1.23-t1.0.1
```
**HELM Chart Scanning:** Nicht nur Container-Images, sondern auch HELM Charts können Schwachstellen enthalten. Tools wie **Trivy** oder **Checkov** helfen, fehlerhafte oder unsichere Konfigurationen zu erkennen.
Trivy für HELM Chart Scans:
```
trivy config /path/to/helm/chart
```
Checkov für Infrastructure-as-Code (IaC) Scans:
```
checkov -d /pfad/zu/helm/chart
```
In diesem Beispiel hat Checkov eine unsichere Konfiguration erkannt. Es fehlt eine SecurityContext-Konfiguration, was ein Sicherheitsrisiko darstellt:
```
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
template:
spec:
containers:
- name: app
image: my-image:latest
```
### 2. Ressourcenlimits und Quotas setzen
Unbegrenzte Ressourcen können den gesamten Cluster lahmlegen oder einen Denial-of-Service (DoS) durch fehlerhafte Pods verursachen. Kubernetes bietet zwei Mechanismen zur Begrenzung:
- **ResourceQuotas** – Begrenzen die maximal nutzbaren Ressourcen von CPU, Memory und Storage innerhalb eines Namespace
- **LimitRanges** – Definieren Default-Limits für einzelne Pods
**ResourceQuota – Globale Limits für einen Namespace:** Mit ResourceQuotas kann verhindert werden, dass ein einzelner Namespace den Cluster monopolisiert.
Beispiel: ResourceQuota für CPU und Speicher
```
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
namespace: production
spec:
hard:
requests.cpu: "4"
requests.memory: "8Gi"
limits.cpu: "10"
limits.memory: "16Gi"
pods: "20"
```
*Erklärung:*
requests.cpu/memory – Minimale garantierte Ressourcen
limits.cpu/memory – Maximale Nutzung pro Namespace
pods – Begrenzung der Gesamtanzahl an Pods
*Warum ist das wichtig?*
– Es wird verhindert, dass einzelne Teams zu viele Ressourcen beanspruchen.
– Es werden Obergrenzen gesetzt, um eine Überlastung des Clusters zu vermeiden.
**LimitRange – Standardwerte für Pods setzen:**
Während **ResourceQuotas** auf Namespace-Ebene arbeiten, ermöglichen **LimitRanges**, dass jeder Pod oder Container innerhalb eines Namespace Mindest- und Höchstwerte für CPU und RAM bekommt.
Beispiel – LimitRange für Container-Limits:
```
apiVersion: v1
kind: LimitRange
metadata:
name: container-defaults
namespace: production
spec:
limits:
- default:
cpu: "500m"
memory: "512Mi"
defaultRequest:
cpu: "200m"
memory: "256Mi"
type: Container
```
*Erklärung:*
default – Maximale Ressourcen, die ein Container erhalten kann.
defaultRequest – Standardanforderungen für neue Container.
*Warum ist das wichtig?*
– Erzwingt Limits, selbst wenn Entwickler sie nicht explizit setzen.
– Verhindert, dass ein Container den gesamten Namespace überlastet.
**Sicherstellen der Limits mit Kyverno:**
Tools wie Kyverno helfen, dass alle neuen Pods automatisch Limits enthalten, wenn sie nicht explizit gesetzt sind.
Beispiel – Kyverno Policy zur Erzwingung von Ressourcenlimits:
```
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: enforce-resource-limits
spec:
validationFailureAction: Enforce
rules:
- name: check-container-resources
match:
resources:
kinds:
- Pod
validate:
message: "CPU und Memory Limits sind erforderlich!"
pattern:
spec:
containers:
- resources:
limits:
cpu: "?*"
memory: "?*"
```
*Vorteile:*
– Pods ohne CPU- oder Memory-Limits werden blockiert.
– Automatisiert die Durchsetzung von Best Practices.
## Zusammenfassung
Automatisierte Scans und Ressourcenmanagement sind essenziell, um Schwachstellen und Sicherheitsrisiken zu minimieren und Cluster-Überlastung zu vermeiden. Setzen Sie auf Tools wie **Trivy**, **Clair**, **Kubescape** und **Checkov**, um proaktiv Sicherheitslücken zu erkennen, zu beheben und die Durchsetzung dieser Regeln zu automatisieren.
## Mehr Sicherheit für Ihre Kubernetes-Umgebung!
Kubernetes bietet enorme Flexibilität – aber auch neue Angriffsflächen. In dieser Artikelserie zeigen wir, wie Sie Risiken minimieren und Ihre Cluster effektiv absichern.
### Was erwartet Sie?
- Strategien gegen unbefugte Zugriffe
- Best Practices für eine widerstandsfähige Kubernetes-Architektur
- Methoden zur frühzeitigen Bedrohungserkennung
- Sicherheit von Anfang an in Ihre Entwicklung integrieren
---
## Lesen Sie die ganze Serie!
Alle Teile diese 7-Teilers finden Sie hier:
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
Einen Blick wert: Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://youtu.be/s5o6TOnt-EM)
---
Teilen Sie Ihre Erfahrungen oder stellen Sie Fragen in den Kommentaren. Gemeinsam entwickeln wir bessere Kubernetes-Sicherheitsstrategien!
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Shift-Left-Security: Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
**Published:** März 12, 2025
**Author:** Torsten Jaeschke
**Content:**
Wenn Sicherheitslücken erst spät im Entwicklungsprozess entdeckt werden – wie es leider oft der Fall ist – erzeugt das hohe potenzielle Risiken und Kosten. Shift-Left-Security setzt genau hier an: Sicherheitsmaßnahmen werden frühzeitig in den Entwicklungsprozess integriert, um Schwachstellen schnell zu identifizieren und zu beheben.
Gerade in Kubernetes-Umgebungen ist ein strukturierter Sicherheitsansatz essenziell, da containerisierte Workloads spezifische Herausforderungen mit sich bringen.
---
*Sie steigen gerade erst ein? Hier finden Sie Teil 1 bis 5 dieser Serie sowie das Video des Webcasts, auf dem die Serie aufbaut:*
[*Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie*](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[*Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen*](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[*Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren*](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[*Video: Kubernetes Security Webcast*](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
## Warum frühe Sicherheitsmaßnahmen entscheidend sind
Früher wurden Sicherheitsprüfungen oft erst am Ende des Entwicklungszyklus durchgeführt – mit teuren Nachbesserungen und Verzögerungen als Folge. Heute setzt sich zunehmend die **frühzeitige Integration von Security in den Entwicklungsprozess** durch.
Durch die Einbindung von **Sicherheits-Scans in CI/CD-Pipelines** können Schwachstellen bereits in frühen Phasen erkannt und behoben werden. Automatisierte Security-Tools analysieren **Code, Container-Images und Konfigurationsdateien**, um Sicherheitsrisiken zu minimieren.
## Sicherheitsherausforderungen in Kubernetes
Kubernetes bietet **Skalierbarkeit und Automatisierung**, erfordert aber auch eine konsequente Sicherheitsstrategie. Fehlkonfigurationen oder unsichere Container-Images können Angriffsflächen schaffen. Daher ist es entscheidend, **Security-Richtlinien strikt einzuhalten und regelmäßig zu überprüfen**.
In unserer Artikelserie haben wir bereits bewährte **Security-Tools für Kubernetes** vorgestellt:
- **Trivy**: Scannt Container-Images auf bekannte Schwachstellen
- **Kubescape**: Prüft Kubernetes-Konfigurationen und sorgt für Compliance
- **Falco**: Überwacht Kubernetes-Cluster in Echtzeit und erkennt verdächtige Aktivitäten
- **Checkov**: Statische Analyse für IaC, um sichere Deployments zu gewährleisten
- **SonarQube & Snyk**: Scannen Code und Abhängigkeiten auf Sicherheitsrisiken
Diese Werkzeuge helfen dabei, **Sicherheitsprobleme frühzeitig zu identifizieren und Kubernetes-Cluster resilienter zu machen**.
Ein weiteres wichtiges Thema ist die **Software Bill of Materials (SBOMs)**, die Transparenz über genutzte Softwarekomponenten schafft. Mehr dazu gibt es in unserer separaten **SBOM-Artikelserie auf dem Cattlecrew Blog**.
## Wirtschaftliche Betrachtung: Sicherheit als Investition
Die frühzeitige Identifikation von Sicherheitslücken führt zu erheblichen Kosteneinsparungen. Studien zeigen: Die Behebung einer Sicherheitslücke in der Produktionsumgebung kann bis zu 100-mal teurer sein als eine Korrektur in der Entwicklungsphase.
Laut der Analyse des Artikels [„Economics of Shift Left Security“](https://stellarcyber.ai/economics-of-shift-left-security/) von Stellar Cyber liegen die wirtschaftlichen Vorteile vor allem in reduzierten Kosten und geringeren Ausfallzeiten.
### Fokus auf Kubernetes und DevSecOps
Besonders im DevOps- und DevSecOps-Umfeld mit Kubernetes zeigt sich der Effekt von „Shift Left Security“. Modell 2, das sich auf DevSecOps konzentriert, verdeutlicht dies eindrücklich**:**
- Behebung von Sicherheitslücken in der Entwicklungsphase **(Shift-Left)**: Ø 3,61 Stunden
- Behebung nach der Produktion **(Shift-Right)**: Ø 10,71 Stunden
- Reduktion der mittleren Behebungszeit von Sicherheitslücken bei hoher Scan-Frequenz: von 217 auf 62 Tage (–71 %)
Diese proaktive Herangehensweise senkt den finanziellen und personellen Aufwand für Entwickler- und Sicherheitsteams und minimiert das Risiko teurer Datenverletzungen.
### Nachhaltiger Wettbewerbsvorteil
Die Analyse zeigt, dass Unternehmen durch „Shift Left Security“ effizienter werden und Risiken verringern. Dies stärkt die Marktposition, da verlässliche Sicherheitspraktiken zu mehr Vertrauen führen. Kunden bevorzugen zunehmend sichere Lösungen – wer früh in Security investiert, sichert sich klare Vorteile.
## Schulung & Awareness: Ein starkes Team als Sicherheitsfaktor
**Tools allein reichen nicht aus** – das Security-Bewusstsein im Team ist entscheidend. Entwickler sollten regelmäßig zu den **OWASP Top 10, SANS Top 25 und anderen Sicherheitsstandards** geschult werden.
Gerade Kubernetes bringt viele Vorteile, erfordert aber spezialisiertes Wissen. **Ein geschultes Team kann Risiken proaktiv minimieren** und Sicherheitsstrategien gezielt umsetzen.
## Fazit: Security von Anfang an mitdenken!
Sicherheit sollte **nicht erst am Ende**, sondern **von Anfang an** in den Entwicklungsprozess integriert werden. Der Einsatz von **automatisierten Security-Scans, bewährten Analysetools und gezielten Schulungen** hilft dabei, Risiken zu minimieren und langfristige Kosten zu senken.
Gerade in Kubernetes-Umgebungen ist eine frühzeitige Sicherheitsstrategie entscheidend, um **stabile, sichere und skalierbare Anwendungen** bereitzustellen.
### Was bedeutet das für Ihre Organisation, Ihr Unternehmen?
- Wie sicher ist Ihre **aktuelle Kubernetes-Umgebung**?
- Nutzen Sie bereits **automatisierte Security-Scans** in Ihren Pipelines?
- Ist Ihr Team mit den **wichtigsten Security-Standards** vertraut?
Falls nicht, ist jetzt der richtige Zeitpunkt, **Ihre Sicherheitsstrategie zu überdenken**. Setzen Sie auf **bewährte Methoden und moderne Security-Tools**, um Ihre Anwendungen von Anfang an zu schützen.
Ein durchdachter Security-Ansatz hilft dabei, Kubernetes-Umgebungen langfristig sicher und stabil zu halten.
## Kubernetes absichern – Praxiswissen & Best Practices!
Kubernetes-Sicherheit ist entscheidend, um Ihre Anwendungen zu schützen. In dieser Artikelserie zeigen wir, welche Maßnahmen wirklich funktionieren.
Folgende Themen erwarten Sie:
- Schutzmechanismen gegen unbefugte Zugriffe
- Best Practices für sichere Kubernetes-Architekturen
- Bedrohungen frühzeitig erkennen & abwehren
- Sicherheit von Anfang an in den Entwicklungsprozess integrieren
---
### Alle Artikel der Serie auf einen Blick
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
**Einen Blick wert:** Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
Tauschen Sie sich mit uns aus! Welche Herausforderungen begegnen Ihnen in der Kubernetes-Sicherheit? Wir freuen uns auf Ihre Kommentare & Fragen.
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
**Published:** Januar 31, 2025
**Author:** Torsten Jaeschke
**Content:**
Die Sicherheit von Kubernetes-Umgebungen ist ein entscheidender Erfolgsfaktor für moderne Softwarearchitekturen. Kubernetes bietet immense Flexibilität und Skalierbarkeit – doch ohne gezielte Sicherheitsmaßnahmen können Risiken entstehen, die schwerwiegende Folgen haben. In unserem [Webcast „Kubernetes Security – Schmerzpunkte und Lösungen“](https://www.opitz-consulting.com/kompetenz/kubernetes-security) haben wir zentrale Herausforderungen und effektive Lösungsstrategien diskutiert. Unser Ziel war es, Softwarearchitekten und DevOps-Teams praxisnahe Ansätze an die Hand zu geben, um Kubernetes-Cluster wirksam zu schützen.
---
In diesem ersten Artikel unserer 7-teiligen Blog-Serie möchten wir Ihnen einen Überblick geben über die wichtigsten Themen aus dem Kubernetes Security Webcast. In weiteren Artikeln der Serie haben wir diese Themen weiter zu vertieft. Freuen Sie sich auf konkrete Tipps und Best Practices! Zu den weiterführenden Artikeln kommen Sie ganz unten in diesem Beitrag.
---
## **Kubernetes-Sicherheit: Die Schlüsselthemen im Überblick**
Im oben erwähnte Webcast haben wir uns vier zentrale Aspekte der Kubernetes-Sicherheit angesehen:
1. **Unerlaubte Zugriffe verhindern**
2. **Unsichere Systeme absichern**
3. **Verdächtiges Verhalten erkennen**
4. **Shift-Left-Security umsetzen**
Diese vier Aspekte bilden das Fundament für eine sichere Kubernetes-Umgebung. Worum geht es dabei im Einzelnen? Hier eine kurze Erläuterung zu den Webcast-Themen:
### **1. Unerlaubte Zugriffe – ein oft unterschätztes Risiko**
Ein großes Risiko in Kubernetes-Umgebungen sind unautorisierte Zugriffe. Granulare Zugriffskontrollen sind entscheidend, um sensible Daten und Services zu schützen. Wir haben im Webcast gezeigt, wie Sie **RBAC (Role-Based Access Control)** und Netzwerkisolation effektiv einsetzen können.
Zusätzlich haben wir Tools wie **Kubescape** und **Kyverno** vorgestellt, die Ihnen dabei helfen, Sicherheitsrichtlinien zu definieren und durchzusetzen. Der Fokus lag auf praxisnahen Tipps zur Minimierung von Angriffsflächen.
### **2. Unsichere Systeme – eine tickende Zeitbombe**
Von veralteten Images bis hin zu unzureichenden Ressourcenlimits: Schwachstellen in Kubernetes-Systemen sind oft die Ursache für Sicherheitsvorfälle. Automatisierte Schwachstellenscans mit Tools wie **Trivy** oder **Clair** können hier Abhilfe schaffen.
Zusätzlich haben wir erklärt, wie Sie Ressourcen effizient begrenzen können, um Überlastungen zu vermeiden. **Kontinuierliche Überwachung** und Automatisierung waren zentrale Empfehlungen, um Systeme langfristig sicher und stabil zu halten.
### **3. Verdächtiges Verhalten – Angriffe frühzeitig erkennen**
Ein auffälliges Verhalten in Kubernetes-Umgebungen kann ein Hinweis auf Sicherheitsvorfälle sein. Mithilfe von **Laufzeitüberwachungs-Tools** wie **Falco** lässt sich verdächtiges Verhalten in Echtzeit erkennen.
Wir haben konkrete Beispiele aus der Praxis vorgestellt, die zeigen, wie anomales Verhalten identifiziert und darauf reagiert werden kann. Eine Kombination aus Echtzeitüberwachung und Compliance-Checks ist hierbei unverzichtbar, um potenzielle Sicherheitslücken zu minimieren.
### **4. Shift-Left-Security – Sicherheit frühzeitig integrieren**
Sicherheitsmaßnahmen sollten nicht erst in der Produktion beginnen. **Shift-Left-Security** bedeutet, dass Sicherheitsmechanismen bereits in frühen Entwicklungsphasen implementiert werden. Automatisierte Tests und statische Codeanalysen helfen, Schwachstellen frühzeitig zu identifizieren.
Im Webcast haben wir gezeigt, wie **Sicherheitsrichtlinien** direkt in CI/CD-Pipelines integriert werden können. Tools wie **Kubescape** bieten hier praktische Lösungen.
## **Warum Kubernetes-Sicherheit mehr ist als Technologie**
Sicherheit in Kubernetes ist kein rein technisches Thema. Es geht um das Zusammenspiel aus kulturellem Bewusstsein, organisatorischen Richtlinien und den richtigen Technologien. Ziel sollte es daher sein, Teams dabei zu unterstützen, ein ganzheitliches Verständnis für Kubernetes-Sicherheit zu entwickeln.
## **Bleiben Sie in der Kubernetes-Security einen Schritt voraus!**
Kubernetes ist leistungsstark – aber auch anfällig für Sicherheitsrisiken. In unserer kommenden Artikelserie tauchen wir tiefer in die einzelnen Themen ein und zeigen praxisnahe Lösungen auf.
Lesen Sie den nächsten Teil dieser Serie: [Wie Sie Ihre Cluster vor unbefugten Zugriffen schützen.](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
Und freuen Sie sich auf weitere fundierte Einblicke, Codebeispiele und konkrete Handlungsempfehlungen zu den vier oben genannten Aspekten:
- Best Practices für eine robuste Kubernetes-Sicherheitsarchitektur.
- Bedrohungen frühzeitig aufspüren und abwehren.
- Sicherheit von Anfang an in Ihre Entwicklungsprozesse integrieren.
---
### **Bleiben Sie gespannt– weitere Artikel folgen bald!**
Diese Artikel sind schon erschienen:
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
Einen Blick wert: Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://youtu.be/s5o6TOnt-EM)
---
## **Teilen Sie gerne Ihre Erfahrungen**
Wir freuen uns auf den Austausch mit Ihnen! Haben Sie Fragen oder Herausforderungen in Ihren Kubernetes-Umgebungen? Teilen Sie Ihre Erfahrungen und Best Practices gerne in den Kommentaren oder kontaktieren Sie uns direkt. Gemeinsam können wir daran arbeiten, Ihre Sicherheitsstrategien auf das nächste Level zu heben.
Vielen Dank an alle, die an unserem [Webcast „Kubernetes Security – Schmerzpunkte und Lösungen“](https://www.opitz-consulting.com/kompetenz/kubernetes-security) teilgenommen haben. Bleiben Sie sicher – in der Entwicklung, im Betrieb und darüber hinaus!
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
**Published:** Februar 21, 2025
**Author:** Torsten Jaeschke
**Content:**
Kubernetes ist das Rückgrat vieler moderner Cloud-Native-Anwendungen – aber auch ein attraktives Ziel für Angreifer. Unautorisierte Zugriffe, Privilege Escalation oder schadhafte Container-Images können ganze Cluster kompromittieren. Eine kontinuierliche Überwachung ist daher essenziell, um Sicherheitsrisiken frühzeitig zu erkennen und zu beheben. In diesem Artikel stellen wir zwei leistungsstarke Open-Source-Tools vor, die Kubernetes-Umgebungen sicherer machen: **Falco** und **Kubescape**.
*Sie steigen gerade erst ein? Hier finden Sie Teil 1 bis 3 dieser Serie sowie das Video des Webcasts, auf dem die Serie aufbaut:*
[*Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie*](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[*Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen*](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[*Video: Kubernetes Security Webcast*](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
## Laufzeitüberwachung mit Falco
Falco ist ein Sicherheitsmonitoring-Tool, das verdächtige Aktivitäten in Echtzeit erkennt. Durch vordefinierte oder benutzerdefinierte Regeln können Angriffe und Fehlkonfigurationen aufgedeckt werden.
### **Beispiel: Erkennen einer Shell in einem Container**
Eine der häufigsten Angriffsmethoden ist das Starten einer interaktiven Shell innerhalb eines Containers. Dies kann auf eine Kompromittierung hinweisen. Die folgende Falco-Regel warnt Administratoren, wenn eine Shell in einem laufenden Container gestartet wird:
```
- rule: Detect Shell in Container
desc: "Warnung, wenn eine Shell innerhalb eines Containers ausgeführt wird"
condition: container and shell
output: "Shell innerhalb eines Containers ausgeführt (user=%user.name shell=%proc.name)"
priority: WARNING
```
### **Erweiterte Falco-Regel: Unerwartete Dateiänderungen**
Falco kann auch ungewollte Änderungen an wichtigen Systemdateien erkennen. Diese Regel löst eine Warnung aus, wenn Dateien in sensiblen Verzeichnissen wie `/etc/` oder `/var/run/` verändert werden:
```
- rule: Detect File Modification in Sensitive Directory
desc: "Warnung bei Änderungen in sensiblen Verzeichnissen"
condition: open_write and (fd.name startswith /etc/ or fd.name startswith /var/run/)
output: "Verdächtige Dateiänderung erkannt (user=%user.name file=%fd.name)"
priority: WARNING
```
### **Falco in Kubernetes integrieren**
Falco kann als **DaemonSet** in Kubernetes bereitgestellt werden, um kontinuierlich alle Pods zu überwachen. Die Installation erfolgt mit:
```
kubectl apply -f https://raw.githubusercontent.com/falcosecurity/charts/master/stable/falco.yaml
```
Nach der Installation gibt Falco Log-Daten aus oder sendet Warnungen an Monitoring-Tools wie **Prometheus** oder **Grafana**.
## Laufzeitüberwachung mit Kubescape
Während Falco primär auf System-Calls und Container-Prozesse fokussiert ist, bietet **Kubescape** zusätzlich eine umfassende Analyse der Cluster-Sicherheit – einschließlich Laufzeitüberwachung und Konfigurationsprüfung.
### **Wie funktioniert die Laufzeitüberwachung mit Kubescape?**
Kubescape kombiniert Verhaltensanalyse, Netzwerküberwachung und System-Call-Monitoring, um verdächtige Aktivitäten frühzeitig zu erkennen. Das Tool identifiziert unter anderem:
- Ungewohnte Netzwerkverbindungen
- Nicht autorisierte Prozesse in Containern
- Manipulationen an wichtigen Systemdateien
### **Beispiel: Auffällige Container-Aktivitäten erkennen**
Um eine Laufzeitüberprüfung durchzuführen, kann folgender Befehl genutzt werden:
```
kubescape runtime scan
```
### **Kubescape in CI/CD-Pipelines integrieren**
Um Sicherheitsprüfungen bereits während der Entwicklung zu automatisieren, kann Kubescape in **CI/CD-Pipelines** eingebunden werden. Hier ein Beispiel für die Integration mit **GitHub Actions**:
```
jobs:
security-scan:
runs-on: ubuntu-latest
steps:
- name: Install Kubescape
run: curl -s https://raw.githubusercontent.com/kubescape/kubescape/main/install.sh | bash
- name: Run runtime security scan
run: kubescape runtime scan --format json --output results.json
```
Diese Automatisierung stellt sicher, dass verdächtige Aktivitäten erkannt werden, bevor sie in die Produktionsumgebung gelangen.
## Fazit: Kubernetes-Sicherheit braucht Echtzeitüberwachung
Sowohl **Falco** als auch **Kubescape** sind leistungsstarke Open-Source-Tools, die zur Absicherung von Kubernetes-Clustern beitragen. Während **Falco** verdächtige Aktivitäten in Echtzeit überwacht, bietet **Kubescape** eine zusätzliche Laufzeitanalyse und umfassende Sicherheitsprüfungen.
Die Kombination beider Tools bietet eine **robuste Sicherheitsstrategie**, um Risiken frühzeitig zu minimieren – sei es durch **Monitoring in der Produktionsumgebung** oder durch **automatisierte Prüfungen in CI/CD-Pipelines**.
### Sind Ihre Kubernetes-Cluster ausreichend geschützt?
- Nutzen Sie bereits eine Laufzeitüberwachung für Ihre Container?
- Sind Ihre Sicherheitsrichtlinien in Kubernetes konsequent umgesetzt?
- Haben Sie automatisierte Tools zur Bedrohungserkennung integriert?
Falls nicht, könnte es an der Zeit sein, Ihre **Security-Strategie** zu überdenken. Kubernetes-Sicherheit ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Wer frühzeitig auf robuste Monitoring-Lösungen setzt, kann sich langfristig vor Angriffen und ungewollten Sicherheitsvorfällen schützen.
---
## Sicher unterwegs mit Kubernetes!
Kubernetes erleichtert moderne Softwarearchitekturen, bringt aber auch Sicherheitsherausforderungen mit sich. In dieser Blogserie geben wir Ihnen praxisnahe Lösungen an die Hand.
Erfahren Sie mehr über:
- Zugriffsschutz & Berechtigungen
- Eine sichere Cluster-Architektur
- Erkennung & Abwehr von Angriffen
- Sicherheitsmaßnahmen direkt in der Entwicklung
---
### Die Blogserie auf einen Blick:
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
Einen Blick wert: Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
Haben Sie Fragen oder eigene Best Practices? Teilen Sie sie gerne in den Kommentaren oder nehmen Sie direkt Kontakt auf.
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
**Published:** Februar 28, 2025
**Author:** Torsten Jaeschke
**Content:**
Kubernetes begeistert uns mit seiner Flexibilität und Skalierbarkeit und ist inzwischen der Standard für moderne Container-Orchestrierung. Doch mit dieser Leistungsfähigkeit geht auch eine erweiterte Angriffsfläche einher. In diesem Beitrag unserer Artikelserie zeigen wir, welche zentralen Angriffspunkte in einem Kubernetes-Cluster existieren, warum sie so kritisch sind und wie Sie mit konkreten technischen Maßnahmen den Schutz Ihrer Infrastruktur nachhaltig verbessern können. Dabei knüpfen wir auch an Erkenntnisse aus früheren Artikeln zu Themen wie Sicherheitsfokus, unerlaubte Zugriffe und Automatisierung an – Themen, die uns persönlich sehr am Herzen liegen.
---
*Sie steigen gerade erst ein? Hier finden Sie Teil 1 bis 4 dieser Serie sowie das Video des Webcasts, auf dem die Serie aufbaut:*
[*Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie*](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[*Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen*](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[*Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren*](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[*Video: Kubernetes Security Webcast*](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
## Die kritischen Angriffspunkte im Überblick
Sicherheitsrelevante Komponenten im Schema
### Der Kubernetes API-Server
Der sogenannte kubeapiserver ist die zentrale Steuereinheit Ihres Clusters. Er nimmt alle Befehle entgegen, verteilt sie an die entsprechenden Komponenten und hält den gesamten Zustand des Systems aktuell. Genau deshalb ist er ein beliebtes Ziel für Angreifer.
- Werden **schwache Authentifizierungsmechanismen** verwendet
- oder sind **Schnittstellen ungeschützt** aus dem Internet erreichbar,
können Angreifer schnell administrativen Zugriff erlangen.
Ein kompromittierter API-Server bedeutet nicht nur, dass einzelne Daten gestohlen werden, sondern potenziell der komplette Cluster in Gefahr ist.
### Das Gehirn von Kubernetes
Als primärer Datenspeicher für Kubernetes dient eine verteilte, zuverlässige Key-Value-Datenbank. Hierfür hat sich etcd als Standard etabliert. Kubernetes gleicht kontinuierlich den tatsächlichen Cluster-Zustand mit dem gewünschten ab, und leitet bei Bedarf korrigierende Maßnahmen ein.
Etcd fungiert damit als Fundamentalgedächtnis von Kubernetes. Die Datenbank beinhaltet auch sämtliche sensible Daten des Clusters – von Secrets und Zugangsdaten bis hin zu kritischen Konfigurationen. Der ungesicherte Zugriff auf etcd bedeutet potenziell eine vollständige Kompromittierung des gesamten Clusters. Ein Angreifer, der Zugriff auf etcd erlangt, kann vertrauliche Daten einsehen oder sogar Manipulationen am Cluster-Zustand vornehmen, was katastrophale Folgen haben kann.
Daher sollten entsprechende Sicherheitsmaßnahmen wie TLS-Verschlüsselung und strenge Zugriffsbeschränkungen absolute Priorität haben.
### Die Rolle der Netzwerkarchitektur
Ein weiterer kritischer Punkt liegt in der Netzwerkarchitektur. Ohne eine klare Trennung der Netzwerksegmente können Angreifer lateral im Cluster agieren – sprich, sie bewegen sich von einem kompromittierten Container zu anderen Komponenten.
Fehlende Isolation zwischen verschiedenen Umgebungen (wie Produktions-, Entwicklungs- und Management-Netzwerken) erhöht dieses Risiko erheblich. Ein gut segmentiertes Netzwerk ist daher ein zentrales Element, um Angriffe frühzeitig einzudämmen.
### Abgesicherte Container
Auch wenn Container grundsätzlich in einer isolierten Umgebung laufen, können sie durch Schwachstellen in der Container-Runtime oder unsichere Basis-Images kompromittiert werden.
- Ein erfolgreicher **Container-Escape** ermöglicht es einem Angreifer, die Isolation zu durchbrechen und direkten Zugriff auf das Host-System zu erlangen.
- **Sicherheitsprofile** wie seccomp, AppArmor oder SELinux sind hier essenziell, um die erlaubten Systemaufrufe zu begrenzen und den Schaden im Fall eines Exploits zu minimieren.
### Die Bedeutung von Verwaltungsschnittstellen und Supply-Chain
Verwaltungsschnittstellen wie das Kubernetes Dashboard sollten niemals öffentlich zugänglich sein. Sind diese unzureichend gesichert, bieten sie Angreifern direkten Zugang zu administrativen Funktionen.
Ebenso wichtig ist die Sicherheit der Supply-Chain: Kompromittierte Container-Images, die unbemerkt in den Build-Prozess eingeschleust werden, können Ihre gesamte Umgebung gefährden.
- Durch den Einsatz von **Image-Signaturen,**
- **regelmäßigen Sicherheits-Scans** in der CI/CD-Pipeline
- und proaktiver Prüfung der Inventarisierung durch **SBOM**s
können Sie hier einen entscheidenden Schritt in Richtung Absicherung machen.
## Konkrete Maßnahmen für einen robusten Cluster-Schutz
### 1. Absichern des API-Servers
Um Ihren API-Server gegen unbefugten Zugriff zu schützen, ist es unerlässlich, ausschließlich gesicherte Verbindungen zuzulassen. Eine typische Konfiguration könnte folgendermaßen aussehen:
```
kube-apiserver \
--tls-cert-file=/etc/kubernetes/pki/apiserver.crt \
--tls-private-key-file=/etc/kubernetes/pki/apiserver.key \
--client-ca-file=/etc/kubernetes/pki/ca.crt
```
Neben dieser TLS-Absicherung sollten Sie auf zertifikatsbasierte Authentifizierung und Multi-Faktor-Authentifizierung (MFA) setzen. Eine feingranulare RBAC-Konfiguration, dass Benutzer und Service Accounts nur die Rechte erhalten, die sie tatsächlich benötigen – ein Ansatz, der den potenziellen Schaden im Fall eines Angriffs erheblich reduziert.
Ein Beispiel, wie eine solche RBAC Konfiguration aussehen kann, haben wir in unserem Artikel zu [unerlaubten Zugriffen in Kubernetes](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/) aufgeführt.
### 2. Den etcd schützen
Da ***etcd*** den gesamten Zustand Ihres Clusters speichert, ist es entscheidend, alle Kommunikationswege zu verschlüsseln. Eine Beispielkonfiguration für ***etcd*** könnte wie folgt aussehen:
```
etcd --cert-file=/etc/etcd/ssl/etcd.pem \
--key-file=/etc/etcd/ssl/etcd-key.pem \
--trusted-ca-file=/etc/etcd/ssl/ca.pem \
--peer-cert-file=/etc/etcd/ssl/peer.pem \
--peer-key-file=/etc/etcd/ssl/peer-key.pem \
--peer-trusted-ca-file=/etc/etcd/ssl/ca.pem
```
Ergänzend sollten Sie den Zugriff auf ***etcd*** über Firewalls oder cloudbasierte Sicherheitsgruppen strikt auf vertrauenswürdige Quellen beschränken. So stellen Sie sicher, dass nur autorisierte Systeme auf diese kritischen Daten zugreifen können.
### 3. Das Netzwerk segmentieren und isolieren
Um eine unkontrollierte seitliche Bewegung im Cluster zu verhindern, setzen Sie auf Network Policys. Mit einer gezielten Policy können Sie beispielsweise den Zugriff auf einen Datenbank-Pod so einschränken, dass nur bestimmte Applikations-Pods darauf zugreifen dürfen:
```
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: allow-db-access
namespace: default
spec:
podSelector:
matchLabels:
role: database
ingress:
- from:
- podSelector:
matchLabels:
role: app
ports:
- protocol: TCP
port: 5432
```
Ergänzen Sie diese Maßnahme durch Mikrosegmentierung, indem Sie Management-, Produktions- und Entwicklungsnetzwerke klar voneinander trennen. Diese Trennung reduziert die Angriffsfläche und sorgt dafür, dass ein potenzieller Einbruch in einem Segment nicht gleich den gesamten Cluster gefährdet. Weitere Informationen zu Network Policys und Admission Controllern finden Sie in unserem Beitrag zu [unerlaubten Zugriffen in Kubernetes](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/).
### 4. Für Container-Sicherheit und Laufzeitschutz sorgen
Container sollten immer mit Sicherheitsprofilen betrieben werden, um unerlaubte Systemaufrufe zu blockieren. So können Sie beispielsweise ein ***seccomp***-Profil in einem Pod aktivieren:
```
apiVersion: v1
kind: Pod
metadata:
name: secure-pod
spec:
containers:
- name: mycontainer
image: mysecureimage
securityContext:
seccompProfile:
type: RuntimeDefault
```
Darüber hinaus empfehlen wir den Einsatz von Monitoring-Tools wie Falco, die kontinuierlich das Laufzeitverhalten der Container überwachen. So können Sie ungewöhnliche Aktivitäten frühzeitig erkennen und entsprechende Gegenmaßnahmen einleiten, bevor es zu einem Sicherheitsvorfall kommt.
Mehr zu Laufzeitmonitoring erfahren Sie in unserem Beitrag zur [Erkennung und Reaktion auf verdächtiges Verhalten in Kubernetes](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/).
### 5. Mit Verwaltungsschnittstellen und Supply-Chains umgehen
Verwaltungsschnittstellen wie das Kubernetes Dashboard sollten niemals offen im Internet erreichbar sein. Setzen Sie auf Ingress-Lösungen mit starker Authentifizierung – etwa über OAuth2 oder SAML – und nutzen Sie IP-Whitelisting, um den Zugriff gezielt zu steuern. Zusätzlich sollten Service Accounts nur minimale Berechtigungen besitzen, und alle administrativen Aktivitäten sollten durch umfassende Audit-Logs dokumentiert werden.
Auch der Schutz der Software-Lieferkette ist ein wichtiger Aspekt: Kompromittierte Container-Images können Ihre gesamte Umgebung gefährden. Durch den Einsatz von Image-Signaturen mit Tools wie [Cosign](https://github.com/sigstore/cosign) und automatisierten Sicherheits-Scans in Ihrer CI/CD-Pipeline, wie in unserem Artikel zur [Absicherung unsicherer Kubernetes-Systeme](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/) vorgestellt, stellen Sie sicher, dass nur vertrauenswürdige Images in den Cluster gelangen.
## Fazit: Es braucht ein ganzheitliches Sicherheitskonzept!
Ein sicherer Kubernetes-Betrieb ist kein Zufall, sondern das Ergebnis eines ganzheitlichen Sicherheitskonzepts, das alle Ebenen der Infrastruktur abdeckt. Durch den konsequenten Einsatz von TLS, präzisen RBAC- und Network Policies, Sicherheitsprofilen für Container sowie der Absicherung kritischer Verwaltungs- und Kommunikationswege legen Sie eine solide Basis gegen vielfältige Angriffsvektoren.
**So sichern Sie Ihren Kubernetes Cluster ab:**
- API-Server mit TLS und RBAC schützen
- etcd-Verschlüsselung aktivieren
- Network Policys zur Segmentierung nutzen
- Sicherheitsprofile für Container einsetzen
- CI/CD-Pipelines mit Security-Scans absichern
Wir hoffen, dieser Beitrag konnte Ihnen Einblicke und Tipps vermitteln, um Ihre Kubernetes-Umgebung nachhaltig abzusichern. Denken Sie daran: Sicherheitsmaßnahmen müssen kontinuierlich überprüft und an die sich ständig verändernde Bedrohungslage angepasst werden. Bleiben Sie also immer am Ball, und scheuen Sie sich nicht, auch neue Ansätze und Technologien in Ihre Sicherheitsstrategie zu integrieren.
Vielen Dank fürs Lesen – viel Erfolg bei der Optimierung Ihrer Infrastruktur und bleiben Sie sicher!
---
## **Teil 1-7 der Blog-Serie**
[Teil 1: Kubernetes-Sicherheit im Fokus: Best Practices und Strategie](https://thecattlecrew.net/2025/01/31/kubernetes-sicherheit-im-fokus/)
[Teil 2: Unerlaubte Zugriffe in Kubernetes – Ursachen, Risiken und Schutzmaßnahmen](https://thecattlecrew.net/2025/02/07/unerlaubte-zugriffe-in-kubernetes-ursachen-risiken-und-schutzmassnahmen/)
[Teil 3: Unsichere Kubernetes-Systeme absichern – Tools, Best Practices und Automation](https://thecattlecrew.net/2025/02/14/unsichere-kubernetes-systeme-absichern-tools-best-practices-und-automation/)
[Teil 4: Verdächtiges Verhalten in Kubernetes erkennen und darauf reagieren](https://thecattlecrew.net/2025/02/21/verdaechtiges-verhalten-in-kubernetes-erkennen-und-darauf-reagieren/)
[Teil 5: Kubernetes-Sicherheit: Die größten Schwachstellen und wie Sie Ihre Cluster schützen](https://thecattlecrew.net/2025/02/28/kubernetes-sicherheit-die-groessten-schwachstellen-und-wie-du-deine-cluster-schuetzt/)
[Teil 6: Shift-Left-Security – Sicherheit von Anfang an in der Softwareentwicklung](https://thecattlecrew.net/2025/03/12/shift-left-security-sicherheit-von-anfang-an-in-der-softwareentwicklung/)
[Teil 7: Kubernetes-Sicherheit: Fazit und Ausblick](https://thecattlecrew.net/2025/03/18/kubernetes-sicherheit-fazit-und-ausblick/)
Einen Blick wert: Auf diesem Webcast basiert die Blogserie: [Kubernetes Security Webcast](https://www.opitz-consulting.com/kompetenz/kubernetes-security)
---
Welche Maßnahmen nutzen Sie, um Ihren Kubernetes-Cluster abzusichern? Teilen Sie Ihre Erfahrungen in den Kommentaren!
**Kategorien:** DevOps, IT-Security
**Schlagwörter:** Container, IT Security, Kubernetes
---
### [Machine Learning mit MLOps – Teil 4: Den Schatz in den Daten bergen mit Data Engineering](https://thecattlecrew.net/2024/11/25/machine-learning-mit-mlops-teil-4-data-engineering-den-schatz-in-den-daten-bergen/)
**Published:** November 25, 2024
**Author:** Jeffrey Remien
**Content:**
Ahoi, ihr unerschrockenen Datentaucherinnen und -taucher! Wir setzen unsere spannende Reise durch die Gewässer des Machine Learnings fort. Nachdem wir in den letzten Artikeln die Bedeutung der Daten erkannt und unsere Karten sorgfältig gezeichnet haben, schnallen wir uns heute die Tiefseetaucheranzüge an und tauchen noch tiefer ein. Falls ihr die bisherigen Etappen verpasst habt, könnt ihr sie hier nachlesen:
[Machine Learning mit MLOps – Teil 1: Woran viele ML-Projekte scheitern](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/)
[Machine Learning mit MLOps – Teil 2: Scoping. Wie umfahren wir die Untiefen im ML-Gewässer?](https://thecattlecrew.net/2024/05/08/machine-learning-mit-mlops-teil-2-scoping/)
[Machine Learning mit MLOps – Teil 3: Abtauchen ins Datenmeer](https://thecattlecrew.net/2024/10/22/machine-learning-mit-mlops-teil-3-abtauchen-ins-datenmeer/)
Heute nehmen wir Kurs auf die verborgenen Schätze unter der Oberfläche unserer Datenmeere. Wir werden entdecken, wie wir unsere Daten analysieren, aufbereiten und für die Verarbeitung in ML-Modellen vorbereiten können. Es geht darum, unsere Navigationsinstrumente – Feature Engineering, Dimensionalitätsreduktion, Datenaugmentation und Datenpipelines – zu meistern, um sicher durch die Tiefen zu navigieren.
## **Die Tiefe ausloten: Explorative Datenanalyse**
Bevor wir uns in die dunklen Tiefen stürzen, ist es entscheidend, das Gewässer gründlich zu erkunden. Die Explorative Datenanalyse (EDA) ist unser Sonar, mit dem wir den Meeresgrund kartografieren und versteckte Gefahren sowie wertvolle Ressourcen entdecken. Ohne EDA wäre unsere Reise wie eine Fahrt ins Ungewisse, bei der wir jederzeit auf unerwartete Hindernisse stoßen könnten.
### **Warum ist EDA so wichtig?**
Stellt euch vor, ihr seid Kapitän eines Forschungsschiffs, das unbekannte Gewässer erkunden soll. Ohne genaue Karten oder Informationen über Untiefen und Strömungen ist das Risiko groß, auf Riffe aufzulaufen oder in einen Sturm zu geraten. Ähnlich verhält es sich mit unseren Daten. Ohne eine gründliche EDA könnten wir wichtige Muster übersehen oder uns von Ausreißern in die Irre führen lassen.
### **Wie führen wir eine effektive EDA durch?**
- **Visualisierung:** Durch Diagramme und Grafiken können wir die Verteilung unserer Daten besser verstehen. Histogramme zeigen uns, wie unsere Daten verteilt sind, während Scatterplots Beziehungen zwischen Variablen aufdecken können. Zum Beispiel kann ein Scatterplot zwischen der Motorleistung eines Schiffs und seiner Geschwindigkeit zeigen, ob ein Zusammenhang besteht.
- **Statistische Analysen:** Mit Kennzahlen wie Mittelwert, Median und Standardabweichung erhalten wir ein Gefühl für die zentralen Tendenzen und die Variabilität unserer Daten. Korrelationsmatrizen helfen uns, Zusammenhänge zwischen verschiedenen Merkmalen zu erkennen. Wenn wir beispielsweise feststellen, dass die Länge eines Schiffs stark mit seiner Tragfähigkeit korreliert, können wir diese Information für unsere Modellierung nutzen.
#### **Beispiel aus der Praxis:**
Angenommen, wir arbeiten an einem ML-Projekt zur Vorhersage von Wetterbedingungen auf See. Durch EDA könnten wir feststellen, dass bestimmte Muster in der Windgeschwindigkeit und dem Luftdruck Hinweise auf kommende Stürme geben. Ohne diese Analyse könnten wir unsere Schiffe in gefährliche Gewässer schicken, ohne es zu wissen.
### **Vorteile der EDA**
- **Frühes Erkennen von Problemen:** Indem wir unsere Daten genau untersuchen, können wir fehlende Werte, Ausreißer oder ungewöhnliche Muster frühzeitig erkennen und entsprechend handeln. Das ist vergleichbar mit dem Erkennen eines aufziehenden Sturms, bevor wir in See stechen.
- **Bessere Modellierung:** Ein tiefes Verständnis der Daten ermöglicht es uns, geeignetere Modelle zu wählen und diese besser anzupassen. So vermeiden wir, mit dem falschen Schiff in die falschen Gewässer zu fahren.
## **Die Ausrüstung vorbereiten: Datenqualität und -bereinigung**
Ein guter Taucher überprüft immer seine Ausrüstung, bevor er ins Wasser springt. Genauso müssen wir sicherstellen, dass unsere Daten in einwandfreiem Zustand sind, bevor wir sie in unsere Modelle einspeisen. Unsaubere oder fehlerhafte Daten sind wie Löcher in unserem Taucheranzug – sie können uns gefährden und den Erfolg unserer Mission beeinträchtigen.
### **Herausforderungen bei der Datenqualität**
- **Fehlende Werte:** Diese können auftreten, wenn Daten nicht erfasst wurden oder verloren gegangen sind. Sie können zu Verzerrungen führen, wenn sie nicht richtig behandelt werden. Ein fehlender Datenpunkt in unserer Wettervorhersage könnte dazu führen, dass wir einen Sturm übersehen.
- **Ausreißer:** Extremwerte können das Modelltraining negativ beeinflussen, insbesondere bei sensitiven Algorithmen wie der linearen Regression. Ein einzelnes Schiff, das ungewöhnlich schnell ist, könnte unsere Geschwindigkeitsprognosen verfälschen.
- **Inkonstistente Formate:** Unterschiedliche Datumsformate, Maßeinheiten oder Kodierungen können zu Verwirrung führen und müssen vereinheitlicht werden. Wenn einige unserer Daten in Knoten und andere in Kilometern pro Stunde angegeben sind, müssen wir sie angleichen.
### **Strategien zur Datenbereinigung**
- **Imputation fehlender Werte:** Fehlende Daten können durch statistische Methoden wie Mittelwert, Median oder mittels komplexerer Techniken wie k-NN-Imputation ersetzt werden. Wenn uns die Temperaturdaten für einen bestimmten Tag fehlen, können wir den Durchschnitt der umliegenden Tage verwenden.
- **Entfernung oder Anpassung von Ausreißern:** Wir können entscheiden, ob Ausreißer entfernt, transformiert oder behalten werden sollen, basierend auf ihrer Ursache und ihrem Einfluss auf das Modell. Wenn ein Sensor einen unrealistisch hohen Wellengang meldet, sollten wir prüfen, ob es sich um einen Messfehler handelt.
- **Standardisierung von Formaten:** Durch die Umwandlung aller Daten in ein konsistentes Format vermeiden wir Interpretationsfehler. Alle Geschwindigkeiten könnten in Knoten angegeben werden, um Verwechslungen zu vermeiden.
### **Warum sich die Mühe lohnt**
Saubere Daten führen zu zuverlässigeren Modellen. Sie minimieren das Risiko von Fehlinterpretationen und erhöhen die Genauigkeit unserer Vorhersagen. So wie ein Taucher mit gut gewarteter Ausrüstung tiefer und sicherer tauchen kann, können wir mit bereinigten Daten bessere Ergebnisse erzielen.
## **Den Kompass kalibrieren: Feature Engineering**
Mit sauberem Schiff und klaren Karten sind wir bereit, den Kurs festzulegen. Das Feature Engineering ist unser Kompass, der uns die richtige Richtung weist. Es geht darum, die wichtigsten Merkmale in unseren Daten zu identifizieren und sie so zu transformieren, dass sie unserem Modell den bestmöglichen Input liefern.
### **Feature Selection**
Nicht alle Datenpunkte sind gleich wichtig. Wie ein Seefahrer, der die Sterne zur Navigation nutzt, müssen wir die relevanten „Sterne“ in unseren Daten finden. Durch die Auswahl der wichtigsten Features verbessern wir die Effizienz und Genauigkeit unseres Modells.
#### **Methoden der Feature Selection:**
- **Filtermethoden:** Diese verwenden statistische Tests, um die Merkmale zu bewerten. Beispielsweise können wir die Korrelation zwischen jedem Feature und der Zielvariable berechnen und diejenigen mit geringer Korrelation ausschließen.
- **Wrapper-Methoden:** Hierbei wird das Modell selbst genutzt, um die besten Features zu finden. Ein Beispiel ist die rekursive Feature-Eliminierung, bei der das Modell wiederholt trainiert wird, wobei jedes Mal weniger Features verwendet werden.
- **Embedded-Methoden:** Diese integrieren die Feature Selection direkt in den Trainingsprozess des Modells, wie es beispielsweise bei Lasso-Regression der Fall ist.
#### **Beispiel:**
Angenommen, wir möchten die Wahrscheinlichkeit vorhersagen, mit der Kunden einen Online-Kauf abschließen. Mögliche Features könnten die Verweildauer auf der Seite, die Anzahl der angesehenen Produkte, demografische Daten usw. sein. Durch Feature Selection könnten wir feststellen, dass die Verweildauer und die Anzahl der Produkte stärkere Prädiktoren sind als das Alter des Kunden.
### **Feature Transformation**
Neben der Auswahl relevanter Merkmale müssen wir diese oft auch in eine Form bringen, die unser Modell optimal nutzen kann. Das ist vergleichbar mit dem Kalibrieren unserer Instrumente, um präzise Messungen zu erhalten.
#### **Techniken der Feature Transformation**
- **Skalierung:** Anpassung der Wertebereiche der Features, z.B. durch Min-Max-Skalierung oder Standardisierung. Dies ist besonders wichtig für Algorithmen, die auf Distanzen basieren, wie k-Means oder k-NN.
- **Encoding kategorialer Variablen:** Kategoriale Daten müssen in numerische Form gebracht werden. One-Hot-Encoding wandelt Kategorien in binäre Vektoren um, während Label-Encoding ihnen numerische Werte zuweist.
- **Transformation schiefer Verteilungen:** Logarithmische oder Box-Cox-Transformationen können angewendet werden, um die Symmetrie der Daten zu verbessern.
#### **Beispiel:**
In einem Modell zur Kreditrisikobewertung könnten wir das Einkommen der Antragsteller logarithmieren, um eine gleichmäßigere Verteilung zu erzielen. Ebenso könnten wir die Beschäftigungsart (z.B. Angestellter, Selbstständig, Arbeitslos) mittels One-Hot-Encoding in numerische Features umwandeln.
### **Warum ist Feature Engineering so wichtig?**
Ein gut durchgeführtes Feature Engineering kann die Leistung eines Modells erheblich steigern. Es ermöglicht dem Modell, die relevanten Muster in den Daten besser zu erkennen und sorgt für stabilere und genauere Vorhersagen. Es ist, als würden wir unserem Schiff die optimalen Segel setzen, um den Wind bestmöglich zu nutzen.
## **Überflüssigen Ballast abwerfen: Dimensionalitätsreduktion**
Auf hoher See ist es wichtig, nicht zu viel Ballast mitzuschleppen. Zu viele unnötige Daten können unser Schiff verlangsamen und den Verbrauch erhöhen. In der Datenwelt bedeutet eine hohe Anzahl von Features nicht immer bessere Ergebnisse; tatsächlich kann sie zu Problemen wie dem „Fluch der Dimensionalität“ führen.
### **Was ist der Fluch der Dimensionalität?**
Je mehr Dimensionen (Features) unsere Daten haben, desto exponentiell mehr Datenpunkte benötigen wir, um den Raum adäquat zu füllen. Das kann zu Überanpassung führen, bei der unser Modell die Trainingsdaten zu gut lernt und auf neuen Daten schlecht generalisiert.
### **Techniken der Dimensionalitätsreduktion**
- **Hauptkomponentenanalyse (PCA):** PCA projiziert die Daten auf weniger Dimensionen, indem sie die Varianz maximiert. Die neuen Komponenten sind lineare Kombinationen der ursprünglichen Features.
- **t-SNE (t-Distributed Stochastic Neighbor Embedding):** Eine nichtlineare Methode, die besonders gut für die Visualisierung hoher Dimensionen in 2D oder 3D geeignet ist.
- **UMAP (Uniform Manifold Approximation and Projection):** Ähnlich wie t-SNE, aber oft schneller und bewahrt sowohl lokale als auch globale Strukturen.
#### **Beispiel:**
In der Genomik arbeiten wir oft mit Tausenden von Genexpressionsdaten. Durch PCA können wir diese auf wenige Hauptkomponenten reduzieren, die den Großteil der Varianz erklären. Das erleichtert die Analyse und Visualisierung erheblich.
#### **Vorteile der Dimensionalitätsreduktion**
- **Effizienzsteigerung:** Weniger Features bedeuten kürzere Trainingszeiten und geringeren Speicherbedarf.
- **Verbesserte Generalisierung:** Reduziert das Risiko von Overfitting.
- **Bessere Visualisierung:** Erleichtert das Verständnis komplexer Daten durch Darstellung in niedrigeren Dimensionen.
**Aber Vorsicht:**
Es besteht die Gefahr, dass wichtige Informationen verloren gehen. Daher sollten wir immer prüfen, wie viel Varianz durch die Reduktion erklärt wird und ob die reduzierten Daten noch aussagekräftig sind.
## **Den Wind in die Segel holen: Datenaugmentation**
Manchmal reicht der Wind nicht aus, um unser Schiff voranzutreiben. In solchen Fällen setzen wir zusätzliche Segel oder nutzen alternative Antriebsmethoden. Ähnlich verhält es sich, wenn unsere vorhandenen Daten nicht ausreichen, um ein robustes Modell zu trainieren.
### **Was ist Datenaugmentation?**
Datenaugmentation ist die künstliche Erweiterung des vorhandenen Datensatzes durch Generierung zusätzlicher Datenpunkte. Dies ist besonders nützlich, wenn wir mit begrenzten oder unausgewogenen Datensätzen arbeiten.
### **Methoden der Datenaugmentation**
- **Bilddaten:**
- *Geometrische Transformationen:* Rotieren, Spiegeln, Skalieren oder Verschieben von Bildern. Zum Beispiel können wir ein Bild eines Schiffs drehen, um verschiedene Perspektiven zu simulieren.
- *Farbvariationen:* Anpassung von Helligkeit, Kontrast oder Sättigung, um unterschiedliche Lichtverhältnisse zu imitieren.
- *Hinzufügen von Rauschen:* Einfügen von zufälligem Rauschen, um die Robustheit gegenüber Störungen zu erhöhen.
- **Textdaten:**
- *Synonymersetzung:* Ersetzen von Wörtern durch ihre Synonyme, um verschiedene Ausdrucksweisen abzudecken.
- *Back-Translation:* Übersetzen in eine andere Sprache und zurück, um den Satzbau zu variieren.
- *Einfügen von Tippfehlern:* Simuliert menschliche Eingabefehler, was in Rechtschreibkorrektur-Systemen hilfreich sein kann.
#### **Beispiel:**
Angenommen, wir trainieren ein Modell zur Spracherkennung, haben aber nur wenige Aufnahmen von bestimmten Dialekten. Durch Datenaugmentation können wir vorhandene Aufnahmen leicht verändern, um verschiedene Sprechgeschwindigkeiten oder Tonhöhen zu simulieren.
### **Warum ist Datenaugmentation wichtig**
- **Verbesserte Generalisierung:** Das Modell lernt, mit einer größeren Vielfalt an Daten umzugehen und wird robuster gegenüber Variationen.
- **Ausgleich von Klassenungleichgewichten:** Erhöht die Anzahl von Beispielen in unterrepräsentierten Klassen, was zu ausgewogeneren Modellen führt.
**Aber Vorsicht:**
Ungeeignete Augmentation kann zu unrealistischen Daten führen und das Modell verwirren. Es ist wichtig, Methoden zu wählen, die den realen Bedingungen entsprechen.
## **Die Route planen: Aufbau von Datenpipelines**
Ein erfolgreicher Törn erfordert eine sorgfältige Planung und klare Abläufe. Die Datenpipelines sind unsere festgelegten Routen und Seewege, die den Fluss der Daten von der Quelle bis zum Ziel steuern. Sie sorgen dafür, dass alles reibungslos läuft und wir effizient vorankommen.
### **Was ist eine Datenpipeline?**
Eine Datenpipeline automatisiert die Prozesse der Datenbeschaffung, -verarbeitung, -speicherung und -bereitstellung. Sie stellt sicher, dass die Daten kontinuierlich und konsistent fließen, ähnlich wie ein gut geöltes Uhrwerk.
### **Komponenten einer Datenpipeline**
- **Datenextraktion:** Sammeln von Daten aus verschiedenen Quellen wie Datenbanken, APIs oder Dateien.
- **Datentransformation:** Bereinigung, Normalisierung und Feature Engineering der Daten.
- **Datenladung:** Speichern der verarbeiteten Daten in Data Warehouses oder für das Modelltraining.
- **Modelltraining und -bereitstellung:** Automatisiertes Training des Modells mit den neuesten Daten und Deployment in die Produktionsumgebung.
#### **Beispiel:**
Ein E-Commerce-Unternehmen möchte täglich die neuesten Verkaufsdaten analysieren und Prognosen erstellen. Eine Datenpipeline könnte automatisiert die Verkaufsdaten aus dem System extrahieren, sie bereinigen, relevante Features extrahieren und das Modell täglich neu trainieren und aktualisieren.
### **Vorteile von Datenpipelines**
- **Effizienzsteigerung:** Automatisierung reduziert manuelle Eingriffe und Fehler.
- **Skalierbarkeit:** Kann leicht an wachsende Datenmengen angepasst werden.
- **Reproduzierbarkeit:** Standardisierte Prozesse führen zu konsistenten Ergebnissen.
### **Tools zur Orchestrierung von Datenpipelines**
- **Apache Airflow:** Ein Plattform zur Erstellung, Planung und Überwachung von Workflows.
- **Kubeflow Pipelines:** Speziell für ML-Workflows auf Kubernetes entwickelt.
- **Luigi:** Ein Python-Paket zur Erstellung komplexer Datenpipelines.
## **Das Logbuch führen: Versionierung und Automatisierung**
Auf hoher See ist es unerlässlich, ein genaues Logbuch zu führen. So können wir jederzeit nachvollziehen, wo wir waren, welche Entscheidungen wir getroffen haben und wie wir auf Herausforderungen reagiert haben. In der Welt der MLOps entspricht dies der Versionierung von Daten, Modellen und Code.
### **Warum ist Versionierung wichtig**
- **Nachvollziehbarkeit:** Wir können jederzeit zurückverfolgen, welche Version von Daten und Modellen zu bestimmten Ergebnissen geführt hat.
- **Reproduzierbarkeit:** Andere können unsere Ergebnisse reproduzieren, indem sie die gleichen Versionen verwenden.
- **Fehlerbehebung:** Bei Problemen können wir auf frühere stabile Versionen zurückgreifen.
### **Tools für die Versionierung**
- **Git:** Weit verbreitet für die Versionierung von Code.
- **DVC (Data Version Control):** Ermöglicht die Versionierung von Daten und Modellen in Verbindung mit Git.
- **MLflow:** Plattform für das Tracking von Experimenten, die Verwaltung von Modellen und deren Deployment.
### **Automatisierung mit CI/CD**
Continuous Integration und Continuous Deployment (CI/CD) sind Prozesse, die die automatische Integration von Codeänderungen und deren Deployment ermöglichen.
### **Vorteile der Automatisierung**
- *Schnellere Entwicklungszyklen:* Änderungen können schneller implementiert und getestet werden.
- *Qualitätssicherung:* Automatisierte Tests stellen sicher, dass neue Änderungen keine Fehler einführen.
#### **Beispiel:**
Ein Unternehmen möchte sicherstellen, dass jedes Mal, wenn ein Data Scientist Änderungen am Modell vornimmt, diese automatisch getestet und, wenn sie bestehen, in die Produktionsumgebung übertragen werden. Durch CI/CD-Pipelines wird dieser Prozess automatisiert, was Zeit spart und die Zuverlässigkeit erhöht.
## **Die Sterne lesen: Metadaten und Data Lineage**
Ein erfahrener Seefahrer verlässt sich nicht nur auf seine Instrumente, sondern auch auf die Sterne und die Kenntnis der Meeresströmungen. Metadaten und Data Lineage sind unsere Sterne und Meereskarten, die uns zusätzliche Orientierung bieten und uns helfen, den Überblick über unsere Daten zu behalten.
### **Was sind Metadaten?**
Metadaten sind Daten über Daten. Sie liefern Kontextinformationen wie Herkunft, Erstellungsdatum, Format, Autor und vieles mehr.
### **Warum sind Metadaten wichtig?**
- **Verständnis:** Helfen uns, die Bedeutung und den Zweck der Daten zu verstehen.
- **Verwaltung:** Erleichtern das Auffinden und die Organisation von Datenbeständen.
- **Compliance:** Unterstützen bei der Einhaltung gesetzlicher Vorschriften durch Dokumentation von Datenquellen und -verarbeitungen.
### **Was ist Data Lineage?**
Data Lineage beschreibt den Weg der Daten von der Quelle bis zur Nutzung. Es zeigt, wie Daten transformiert und bewegt wurden.
### **Vorteile von Data Lineage**
- **Transparenz:** Ermöglicht das Nachvollziehen von Datenfluss und Transformationen.
- **Fehlerbehebung:** Erleichtert das Finden von Fehlerquellen in der Datenpipeline.
- **Compliance:** Unterstützt bei Audits und der Einhaltung von Datenschutzrichtlinien.
#### **Beispiel:**
In einer Bank müssen alle Schritte, die Kundendaten durchlaufen, dokumentiert sein. Von der Datenerfassung über die Verarbeitung bis hin zur Nutzung in Modellen muss klar sein, wer wann was mit den Daten gemacht hat. Metadaten und Data Lineage sind hier unerlässlich.
### **Tools**
- **Apache Atlas:** Open-Source-Plattform für Metadatenmanagement und Data Governance.
- **ML Metadata (MLMD):** Framework für Metadaten in ML-Pipelines.
---
## **Auf stürmische Gewässer vorbereitet sein: Best Practices**
Kein Seefahrer begibt sich ohne Vorbereitung auf eine Reise. Sicherheitsmaßnahmen und bewährte Praktiken sind entscheidend, um in stürmischen Gewässern zu bestehen und sicher ans Ziel zu gelangen.
### **Sicherheitsaspekte**
Der Schutz sensibler Daten ist wie das Tragen einer Rettungsweste – unerlässlich für die Sicherheit. Datenschutzverletzungen können nicht nur rechtliche Konsequenzen haben, sondern auch das Vertrauen der Kunden beeinträchtigen.
#### **Maßnahmen**
- **Datenverschlüsselung:** Schutz der Daten während der Übertragung und Speicherung.
- **Zugriffskontrollen:** Implementierung von Rollen und Berechtigungen, um sicherzustellen, dass nur autorisierte Personen auf bestimmte Daten zugreifen können.
- **Anonymisierung und Pseudonymisierung:** Entfernung oder Verschleierung personenbezogener Daten, um die Privatsphäre zu schützen.
#### **Beispiel**
Ein Gesundheitsdienstleister muss Patientendaten schützen. Durch Verschlüsselung und strenge Zugriffskontrollen wird sichergestellt, dass nur befugtes medizinisches Personal Zugriff hat.
### **Qualitätssicherung**
Die regelmäßige Überprüfung und Wartung unserer Systeme ist wie die Inspektion des Schiffes vor der Abfahrt. Sie stellt sicher, dass alles reibungslos funktioniert und minimiert das Risiko von Pannen.
#### **Methoden:**
- **Monitoring:** Kontinuierliche Überwachung der Modellleistung in der Produktion, um Leistungseinbußen oder Datenverschiebungen zu erkennen.
- **Automatisierte Tests:** Implementierung von Unit-Tests, Integrationstests und Validierungen, um sicherzustellen, dass Änderungen keine negativen Auswirkungen haben.
- **Feedback-Schleifen:** Nutzung von Benutzerfeedback und Performance-Daten zur kontinuierlichen Verbesserung des Modells.
#### **Beispiel:**
Ein Unternehmen bemerkt, dass die Genauigkeit seines Empfehlungsalgorithmus abnimmt. Durch Monitoring wird festgestellt, dass sich das Nutzerverhalten geändert hat. Das Modell wird entsprechend angepasst und neu trainiert.
### **Zusammenarbeit im Team**
Eine gut koordinierte Crew ist das Herzstück jeder erfolgreichen Reise. In ML-Projekten arbeiten oft interdisziplinäre Teams zusammen, und klare Kommunikation sowie effektive Zusammenarbeit sind entscheidend.
#### **Strategien:**
- **Dokumentation:** Sorgfältige Aufzeichnung von Entscheidungen, Prozessen und Modelländerungen.
- **Kommunikationstools:** Nutzung von Plattformen wie Slack, Microsoft Teams oder Jira zur Koordination und zum Informationsaustausch.
- **Agile Methoden:** Anwendung von Scrum oder Kanban zur flexiblen und iterativen Projektentwicklung.
#### **Beispiel:**
Ein Team aus Data Scientists, Entwicklern und Fachspezialisten arbeitet gemeinsam an einem Projekt zur Betrugserkennung. Durch regelmäßige Meetings und klare Aufgabenverteilung werden Missverständnisse vermieden und das Projekt effizient vorangetrieben.
## **Fazit**
Unsere Reise durch die Tiefen der Daten hat uns gezeigt, dass ein erfolgreiches ML-Projekt weit mehr erfordert als nur fortschrittliche Algorithmen. Es ist ein Zusammenspiel aus sorgfältiger Planung, präziser Navigation und effektiver Teamarbeit. Wie ein erfahrener Kapitän, der sein Schiff sicher durch unbekannte Gewässer führt, müssen wir die Herausforderungen erkennen und meistern.
Die Datenanalyse und -aufbereitung sind unsere Karten und Instrumente, die uns den Weg weisen. Mit Feature Engineering und Dimensionalitätsreduktion optimieren wir unsere Route, während Datenaugmentation uns den nötigen Schub gibt, wenn der Wind nachlässt. Durch den Aufbau von Datenpipelines, die sorgfältige Versionierung und Automatisierung stellen wir sicher, dass unser Schiff in bestem Zustand bleibt.
Am Ende hängt der Erfolg von ML-Projekten davon ab, wie gut wir unsere Daten verstehen und nutzen. Mit der richtigen Vorbereitung und den passenden Werkzeugen können wir die Schätze heben, die in unseren Daten verborgen liegen. Es ist eine Reise, die kontinuierliches Lernen erfordert, aber die Belohnungen sind den Aufwand mehr als wert.
---
## **Ausblick**
Die Gewässer sind erkundet, das Schiff ist bereit, und die Crew ist motiviert. Doch die Reise ist noch nicht zu Ende. Im nächsten Artikel werden wir die Segel setzen und uns auf den Weg machen, um die Geheimnisse des Modelltrainings zu lüften. Wir werden herausfinden, wie wir das passende Modell auswählen, es auf unseren Daten trainieren und wie Automatisierung und Pipelines uns dabei unterstützen können.
Oder, um in unserer Seefahrtsprache zu bleiben: **Wie setzen wir die Segel, um mit voller Kraft voraus in Richtung Erfolg zu steuern?**
### **Bereits erschienene Artikel:**
[Machine Learning mit MLOps – Teil 1: Woran viele ML-Projekte scheitern](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/)
[Machine Learning mit MLOps – Teil 2: Scoping. Wie umfahren wir die Untiefen im ML-Gewässer?](https://thecattlecrew.net/2024/05/08/machine-learning-mit-mlops-teil-2-scoping/)
[Machine Learning mit MLOps – Teil 3: Abtauchen ins Datenmeer](https://thecattlecrew.net/2024/10/22/machine-learning-mit-mlops-teil-3-abtauchen-ins-datenmeer/)
[Machine Learning mit MLOps – Teil 4: Den Schatz in den Daten bergen mit Data Engineering](https://thecattlecrew.net/2024/11/25/machine-learning-mit-mlops-teil-4-data-engineering-den-schatz-in-den-daten-bergen/)
### Weitere Teile sind geplant:
- **Modelltraining:** Was brauche ich, um ein Modell auf den eigenen Daten zu trainieren? Wie wähle ich das geeignete Modell, und wie können Automatisierung und Pipelines die Arbeit erleichtern?
- **Deployment:** Wie integriere ich das Modell in ein zukünftiges oder bestehendes System bzw. eine Infrastruktur? Welche Strategien ermöglichen einen reibungslosen Umstieg?
- **Monitoring und Maintenance:** Wie überwachen wir ab hier unser bestehendes ML-System? Welche Entwicklungen können Anpassungen erfordern? Wie bereiten wir uns auf diese vor?
**Kategorien:** Development
---
### [Machine Learning mit MLOps – Teil 1: Woran viele ML-Projekte scheitern. Ein Überblick über MLOps als Lösung](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/)
**Published:** Mai 22, 2023
**Author:** Jeffrey Remien
**Content:**
Im alltäglichen Leben nutzen wir Sprachassistenzsysteme wie Siri oder Alexa, Onlineshops geben uns personalisierte Empfehlungen, Smartphones erkennen unser Gesicht, können es sogar verändern. Und mittlerweile schreibt ChatGPT für uns professionelle Bewerbungen oder erklärt uns die chinesische Kulturrevolution im Rapstil von Eminem. Alles auf der Basis intelligenter Systeme. Was in den 1950er Jahren als Idee auf dem Papier begann und lange Zeit für unmöglich gehalten wurde, hat längst Einzug in unseren Alltag gehalten. Künstliche Intelligenz und der Weg zu dieser: Machine Learning. Beide sind aus heutigen IT-Systemen nicht mehr wegzudenken.
# Der Praxis Gap
Bei neuen Technologien, die Machine Learning einsetzen, werden zumeist Durchbrüche in Algorithmen und ML-Modellen gepriesen. Der große Erfolg und die schier endlos scheinenden Anwendungsmöglichkeiten machen den Einsatz von KI und Machine Learning für viele Firmen interessant. Beim Versuch für das eigene Problem eine KI-Lösung zum Einsatz zu bringen, kommt es aber oft zu ernüchternden Ergebnissen: Eine Studie von Dimensional Research aus dem Jahr 2021 ergab, dass fast die Hälfte (47 %) der befragten Unternehmen Schwierigkeiten bei der Umsetzung von ML-Projekten hatten.
Woran liegt das? Bei den Erfolgsgeschichten von KI wird meist ein gewaltiger Faktor außer Acht gelassen, nämlich die Praktiken, die dazu führen, dass die Daten verfügbar, frei von Bias und repräsentativ sind. Dazu gehört beispielsweise auch, dass das Modell mit möglichst wenig Aufwand und Redundanzen trainiert wurde und die Integration in die Betriebssoftware alle Besonderheiten des Anwendungsgebietes berücksichtigt oder ein Monitoring, das die Qualität der Lösung dauerhaft gewährleistet. Hier könnten wir immer noch Hilfe gebrauchen, oder eine Anleitung.
Diese kommt in Form des Frameworks Machine Learning Operations, kurz: MLOps.
Dieser Artikel soll eine kleine Blogreihe zum Thema MLOps einleiten. Was führt ML-Projekte zum Erfolg? Wir wollen uns ansehen, wie es andere machen und was erfolgreiche ML-Projekte auszeichnet.
In diesem ersten Teil sehen wir uns zwei Beispiele an, die zeigen, wie man es eher nicht machen sollte. Denn tatsächlich gibt es viele Fallen, in die wir tappen können, wenn wir ein ML-Modell trainieren. Diese Negativ-Beispiele zeigen, wo genau MLOps ansetzt und sollen dir helfen, das Konzept hinter MLOps besser zu verstehen.
# Was ist eigentlich MLOps?
Quelle: [towards data science](https://towardsdatascience.com/ml-ops-machine-learning-as-an-engineering-discipline-b86ca4874a3f)
Stark vereinfacht könnten wir sagen: Machine Learning Operations, kurz: MLOps bedient sich des DevOps-Ansatzes, der aus der Softwareentwicklung bekannt ist, und überträgt ihn auf Machine Learning. Mit MLOps sollen sich also Machine-Learning-Modelle effizienter entwickeln, deployen, verwalten und monitoren lassen. Data-Science-Prozesse werden dabei in enger Zusammenarbeit mit Fachleuten aus dem Data Engineering, dem Development und dem IT-Betrieb auf die Strecke gebracht. Mit dem Ziel, Künstliche Intelligenz schneller und geschäftlich erfolgreicher nutzen zu können.
Denn Machine Learning ist in der Praxis mehr als die Entwicklung eines Modells mit geringer Fehlerquote. Es hat sich herausgestellt, dass der größte Teil der Arbeit im „Umland“ liegt. Also bei den Daten, der Softwareintegration, der IT-Infrastruktur und beim konstanten Monitoring.
Abbildung 1: Machine Learning und sein „Umland“
Machine-Learning-Modelle sind für sich allein genommen höchst akademisch und längst nicht so praxisbezogen wie die Softwareentwicklung. Um ein gut funktionierendes Modell zu trainieren, mag es reichen, ein paar Machine-Learning-Fachkräfte einzustellen. Wollen wir das Modell aber in einer Produktivumgebung langfristig und zukunftssicher einsetzen, gibt es einiges mehr zu beachten und viele Fallen zu vermeiden.
Ähnlich wie sich in der klassischen Softwareentwicklung DevOps als Sammlung produktiver Praktiken entwickelt hat, trägt MLOps dazu bei,
- den Umfang und die Anforderungen eines Problems an ein Machine-Lerning-Modell zu erfassen und die Ressourcen frühzeitig angemessen zu skalieren,
- die Daten, sowie deren Vorverarbeitung so anzupassen, dass das Modell effizient und zielgerichtet auf das Problem lernen kann,
- den Aufwand und Redundanzen bei der Entwicklung, Bereitstellung und Wartung von Machine-Learning-Modellen gering zu halten,
- wiederzuverwenden was wiederverwendet werden kann,
- zielführende, robuste Designentscheidungen zu treffen
- und auf möglichst alle Eventualitäten und Sicherheitsrisiken vorbereitet zu sein.
Aber wie sieht das in der Praxis aus? Wo und wie kann MLOps helfen, die erwähnten Fallen zu vermeiden? An zwei Negativbeispielen möchte ich das zeigen.
# Beispiel A: Die zu optimistische Diagnose: Daten können trügerisch sein
2017 wurde das Modell CheXNet auf ca. 112.000 Röntgenaufnahmen des Brustkorbs von mehr als 30.000 Patienten trainiert, um verschiedene Krankheiten oder Befunde zu diagnostizieren. Das resultierende Modell arbeitete zuverlässig mit einer Trefferquote von 99 % auf den Testdaten.
*Abbildung 2: Diagnose durch CheXNet auf einer Röntgenaufnahme einer Person mit Lungenentzündung (Quelle: )*
Da die Ergebnisse zufriedenstellend waren, wurde das System testweise auf echten Daten angewendet. Hierbei kam heraus, dass es einen bestimmten Befund gab, den das System nur schlecht bis gar nicht erkannte: Im Falle einer Hernie war die Trefferquote deutlich geringer als bei allen anderen Befunden. Wäre es nicht um einen Test gegangen, hätte dies schlimme Folgen haben können. Was war geschehen?
## Der Trugschluss
Bei genauerem Hinsehen stellte sich heraus, dass der betroffen Befund sehr selten war und dass es in den Trainings- und Testdaten nur ca. 100 Beispiele für eine Hernie gab. Im Vergleich dazu gab es für die meisten anderen Befunde rund 10.000 Beispiele. Der Befund spielte in den Testdaten also eine derart geringe Rolle, dass die geforderte Trefferquote selbst dann eingehalten werden konnte, wenn das System sie einfach überging. Das Modell hätte eine Hernie also in 100 % der Fälle ignorieren und trotzdem in den Tests zuverlässig erscheinen können.
Die Trainings- und Testdaten bildeten somit zwar die Tatsachen realistisch ab, da eine Hernie eine seltene Erkrankung ist, waren aber ungenügend aufbereitet, um ein Modell auf alle Krankheiten gleichermaßen zu trainieren. Die Folgen für betroffene Patienten hätten schwerwiegend sein können. Wir dürfen nie vergessen, dass Modelle nicht wie wir denken. Ihr einziges Ziel ist eine hohe Zuverlässigkeit auf den Trainings- und Testdaten zu erreichen. Denn die Güte dieser Daten entscheidet über die Entscheidungsqualität des Modells.
Dies ist nur ein Beispiel für viele andere mögliche Fallstricke, die in unseren Daten lauern können, noch bevor wir überhaupt Optimierungen am Modell vornehmen. So ist zum Beispiel häufig ist einfach unklar, welche Daten für die vorliegende Fragestellung benötigt werden und in welcher Gestalt sie gebraucht werden. Viele Daten enthalten zudem irrelevante Werte , die ein Training sehr verlangsamen können. Oder die Daten sind nicht angemessen vorverarbeitet. Oder sie sagen nicht das aus, was sie aussagen sollen und so weiter.
## Was ist bei CheXNet schiefgelaufen?
### **Falle 1: Wenn das Vorgehen fehlerhaft ist …**
Zunächst brauchen wir ein umfassendes Domänenwissen. Wir müssen wissen, auf welcher Grundlage wir arbeiten, um ein Modell effektiv zu trainieren.
Wäre beim Training von *CheXNet* nach MLOps-Prinzipien vorgegangen worden, dann hätte das Team die Daten auf die Repräsentation aller gesuchten Klassen überprüft. Dabei wäre den Verantwortlichen aufgefallen, dass eine Krankheit besonders unterrepräsentiert ist. Durch „Supersampling“ oder mithilfe von „künstlichen“ Daten hätten sie hier beispielsweise gegensteuern können. Ein solches Vorgehen wird auch „Data Augmentation“ genannt. MLOps beschäftigt sich aber auch mit Techniken wie „Data Validation“ oder „Feature Selection“. Das heißt, es wird geprüft, ob die vorliegenden Daten für unser Anliegen gültig sind und ob die Auswahl der Datensätzen für die unsere Problemstellung relevant ist.
### **Falle 2: Wenn es subjektiv wird …**
Auch psychologische Aspekte können sich in Daten widerspiegeln: Daten, die von Menschen erzeugt werden, können immer Vorbehalte oder persönliche Einstellungen enthalten, die wir später mit bloßem Auge nicht mehr nachvollziehen können. Dies kann dramatische Auswirkungen auf die Entscheidungen haben, die ein KI-Systems für uns trifft. Beispielsweise wenn die Kreditwürdigkeit einer Person an ihrer Herkunft scheitert, weil die Trainingsdaten eine entsprechende Ungleichverteilung enthalten.
### **Falle 3: Wenn Infrastrukturen die Analyse schwer machen …**
Ferner können Dateninfrastrukturen die Qualität unserer Daten beeinflussen. Immer wieder erleben wir, dass sich eine Person, die ein ML-Projekt bei uns in Auftrag gibt, sicher ist, alle nötigen Daten zu besitzen. „Es müsse nur noch ein Modell gebaut werden!“ Dann erleben wir, dass die Daten auf diversen Plattformen verteilt, durch unterschiedliche Formate schwer verknüpfbar, voller Redundanzen oder voll von Datensätzen mit wenig Aussagekraft sind. Aus diesem Chaos dann eine verwertbare Quelle zu machen – etwa mittels einer ETL-Strecke, einer Data Pipeline und eines Data Warehouses – kann ein komplett eigenes Team beschäftigen. Ist dies nicht eingeplant, scheitert das Projekt eventuell bereits an diesem Punkt.
### **Falle 4: Wenn Aufwand geschätzt werden muss …**
Sehr häufig werden bei ML-Projekten Arbeitspakete nicht eingeplant oder deren Aufwand nicht richtig eingeschätzt, meist unterschätzt. Auch hier setzt MLOps an. MLOps bietet Tools und Vorgehensweisen an, die uns einen Überblick verschaffen über alles, was da ist und alles, was getan werden muss. Erst wenn wir diesen Überblick haben, sind wir in der Lage, Modelle und das Rahmenwerk sinnvoll zu skalieren und den Aufwand richtig einzuschätzen.
Außerdem gibt es heute zahlreiche Tools, die dabei helfen Aufwand beim Machine Learning zu sparen: So lassen sich Modelle wiederverwenden oder mit wenig Aufwand auf andere Zwecke „umtrainieren“. Auch Datenvorverarbeitungsstrecken, Trainingskonfigurationen und daraus resultierende Artefakte können versioniert und wiederverwendet werden.
Mit all diesen Mitteln hilft MLOps dabei, Modelle effektiv, schnell und mit dem geringstmöglichen Aufwand zu trainieren und auszuliefern.
## **Fazit**
An diesem Beispiel erkennen wir, dass der Weg zu einem erfolgreichen ML-Projekt nicht nur über spezielle Fachkräfte und ein gut trainiertes Modell führt, sondern deutlich mehr Überlegungen und Designentscheidungen im Vornherein, sowie eine umfassende Sichtung und ggf. Anpassung der Daten und der Betriebsumgebung erfordert.
# Beispiel B: À la mode – Auch KI hat ein Verfallsdatum
In diesem Beispiel verwendete eine Online-Modefirma ein Machine-Learning-Modell, um vorherzusagen, welche Kleidungsstücke eine bestimmte Person am wahrscheinlichsten kaufen wird. Dazu wurde das Modell auf Verkaufsdaten der letzten drei Jahre trainiert. Das Unternehmen integrierte das Modell erfolgreich in seine Website, um personalisierte Produktempfehlungen an seine Kundschaft zu liefern.
Ein Jahr später änderte das Unternehmen seine Modekollektion und brachte eine neue Linie von Kleidungsstücken auf den Markt. Diese neuen Produkte wurden von einer jüngeren Zielgruppe bevorzugt und wichen stark von den Produkten ab, auf denen das ursprüngliche Modell trainiert wurde. Da das Modell ausschließlich auf historische Verkaufsdaten basierte, in denen die neuen Produkte keine Rolle spielten, entstand eine Abweichung. Ein Data Drift, der verhinderte, dass das Modell die neuen Muster und Trends in den Daten erfassen konnte. In der Folge lieferte es schlechte Vorhersagen.
Abbildung 3: Verschiebungen durch einen Data Drift
## Fallen in den Daten
### **Falle 1: Data Drift**
Der Data Drift, den wir in diesem Beispiel erlebt haben, bezieht sich auf Veränderungen in den Daten, die ein Machine-Learning-Modell verarbeiten soll. Veränderungen, die im Laufe der Zeit entstehen können. Diese Veränderungen können dazu führen, dass das Modell auf einmal nicht mehr in der in der Lage ist, genaue Vorhersagen zu treffen. Denn es kann die neuen Muster und Trends nicht in den Daten erfassen, die es kennt. In unserem Beispiel führte die Änderung der Mode zu einer Verschiebung in den Daten. Wenn wir ein Modell also als Funktion mit Eingabe- und Ausgabewert F(X) = Y betrachten, dann hat sich die Distribution unserer X-Werte so grundlegend geändert, dass die Y-Werte, die das Modell ausgibt für unseren Anwendungsbereich unbrauchbar sind.
### **Falle 2: Concept Drift**
Ein anderes aber ebenso fatales Alterungsanzeichen unseres Modells wäre der sogenannte *Concept Drift.*
Ein Beispiel für einen Concept Drift kennen wir alle aus Spam-Filtern. Während früher E-Mails mit dem gleichen Absender, die häufig aufeinanderfolgten oder über viele Mailkonten mit dem gleichen Betreff verschickt wurden, als unerwünschte Massen-E-Mail galten, haben wir es heutzutage mit diversen automatischen Kaufbestätigungen und automatisierten Benachrichtigungen zu tun. Ein Spamfilter, der auf dem alten Konzept von Spam-E-Mails liefe, würde heutzutage also legitime E-Mails aussortieren.
### **Fazit**
Das Beispiel zeigt deutlich, dass das Erstellen und Bereitstellen eines ML-basierten Systems kein abgeschlossener Prozess ist. Es reicht also nicht, wenn wir ein Team einmal dafür bezahlen, ein möglichst akkurates Modell zu liefern und zu deployen. Jedenfalls nicht, wenn wir ein nachhaltig funktionierendes Artefakt in der Hand halten möchten. Vielmehr sollten wir uns bewusst sein, dass sich die Welt um uns herum und damit auch die inneren Faktoren des Machine-Learning-Prozesses ständig verändern.
# Summary
Möchten wir also ein ML-basiertes System betreiben, sollten wir uns bewusst sein, dass die laufenden Kosten nach der Entwicklung nicht bloß mit der IT-Infrastruktur zusammenhängen. Man kauft kein fertiges Haus, man kauft sich Expertise auf Dauer ein. Nur so sind die Zuverlässigkeit und Weiterentwicklung des Systems gewährleistet.
MLOps unterstützt diesen Prozess mit diversen Tools für das Scoping und Deployment sowie die Wartung und das Monitoring von ML-Projekten. In einigen Fällen ist es vonnöten, das Modell erneut zu trainieren. Bedient man sich Techniken wie dem „Transfer-Learning“ muss eventuell nicht von vorne begonnen werden, sondern es reicht die Ausprägungen durch Nachtrainings anzupassen.
Abbildung 4: Der MLOps-Prozess (Quelle: [MLOps Kurs von Chang Yaochen)](https://changyaochen.github.io/MLOps-course-1/)
Zusammenfassend würde ich sagen, dass MLOps sich vor allem mit dem „Davor“, dem „Währenddessen“ und dem „Danach“ im Lebenszyklus eines ML-Modells beschäftigt. Es geht also um
- das richtige Einschätzen der Anforderungen und Ausgangssituation eines Projekts und den dazugehörigen Daten,
- die richtige Skalierung der Datenstrecken, des Modells, dessen Trainings und den Softwarestrukturen, in die es eingebettet werden soll
- ein Vorgehen, mit dem sich die Gültigkeit und Performance eines Modells prüfen und überwachen lassen,
- das Einhalten von Compliance-Anforderungen
- und die Wahrung von Sicherheit und Integrität des Systems.
Das Ziel von MLOps ist dabei, so wenig Ressourcen wie möglich für den größtmöglichen Effekt aufzuwenden.
# Ausblick
Damit endet der erste Beitrag dieser Serie. Wie geht es weiter?
In den nächsten Teilen dieser Blogreihe, stechen wir mit dem sprichwörtlichen ML-Schiff in See und werden die grundlegenden Etappen der ML-Reise durchlaufen:
[**–> Scoping:** Die Vorbereitung, Planung und Vorabprüfung des Projekts und seiner Ressourcen. Hier können früh projektentscheidende Hindernisse oder Fehler erkannt und vermieden werden.](https://thecattlecrew.net/?p=38761&preview=true)
[**-> Daten:** Wir lernen, die Wichtigkeit der Daten, zu schätzen, sie zu verstehen und einzuschätzen sowie die möglichen Quellen von Daten und was geschehen muss, damit wir mit ihnen Arbeiten können.](https://thecattlecrew.net/2024/10/22/machine-learning-mit-mlops-teil-3-daten-verstehen-woher-wissen-wir-ob-wir-bei-unserer-ml-ueberfahrt-auf-kurs-sind/)
**-> Modelltraining:** Was gehört dazu, ein Modell auf den eigenen Daten zu trainieren? Wie wählt man das geeignete Modell und wie können uns Automatisierung und Pipelines bei beiden Schritten die Arbeit erleichtern?
**-> Deployment:** Wie integrieren wir das Modell in ein zukünftiges oder bestehendes System bzw. eine Infrastruktur? Und welche Strategien ermöglichen einen reibungslosen Umstieg?
**-> Monitoring und Maintanance:** Wie überwachen wir ab hier unser bestehendes ML-System? Welche Entwicklungen können Anpassungen erfordern und wie bereiten wir uns auf diese vor?
Ich hoffe, ich konnte mit dieser Einführung dein Interesse für MLOps wecken und wir sehen uns im nächsten Blogbeitrag wieder.
**Kategorien:** AI & Data Science, DevOps
---
### [Machine Learning mit MLOps – Teil 2: Scoping. Wie umfahren wir die Untiefen im ML-Gewässer?](https://thecattlecrew.net/2024/05/08/machine-learning-mit-mlops-teil-2-scoping/)
**Published:** Mai 8, 2024
**Author:** Jeffrey Remien
**Content:**
Willkommen zurück an Bord unseres KI-Schiffs! In dieser Episode begeben wir uns auf die nächste Etappe einer spannenden Reise. Im ersten Teil unserer Artikelreihe „[In die Falle getappt! Woran viele ML-Projekte scheitern und wie MLOps dies verhindern kann“](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/) ging es um die oft unterschätzten Herausforderungen und Fallen bei der Umsetzung von Machine Learning-Projekten. Wir haben uns einen Überblick über die typischen Fallstricke in ML-Projekten verschafft und eine Einführung erhalten wie MLOps sowohl dabei helfen kann diese Fallstricke zu vermeiden als auch ML-Projekte und die dafür benötigten Ressourcen effektiv zu Planen und mit so wenig Aufwand wie möglich zum Erfolg zu führen.
Nun wollen wir tiefer in die Materie einsteigen und die einzelnen Etappen der ML-Reise durchlaufen. Beginnend mit dem **Scoping.**
## Worum geht es in diesem Teil?
Im zweiten Teil unserer Reise tauchen wir tiefer in die Welt der MLOps ein. Wir werden uns damit beschäftigen, wie man die Untiefen und Risiken in Projekten durch **Scoping** voraussieht. Wir werden lernen, wie man mit den Augen von Entdecker:innen auf das Projekt und seine Daten blickt, um den in ihnen verborgenen Schatz zu heben. Und nicht zuletzt werden wir lernen die Ressourcen und Problemstellung unter Zuhilfenahme von Domänenwissen richtig einschätzen.
Bereite dich auf eine Reise vor, auf der du lernst, wie du ein ML-Projekt mit den richtigen Werkzeugen und Strategien zum Erfolg führst.
## Wie hilft Scoping?
### Durch Voraussicht den richtigen Kurs setzen
Rufen wir uns die Grafik bezüglich des Ablaufs von ML-Projekten noch einmal ins Gedächtnis:
*Abbildung 1: Ablauf von ML-Projekten (**Quelle:* [*MLOps Kurs von Chang Yaochen)*](https://changyaochen.github.io/MLOps-course-1/)
die Abbildung zeigt die typischen Schritte eines MLOp-Teams bis zum fertigen Projekt:
1. Scoping
2. Daten
-> Sichten
-> Ordnen
-> Selektieren
-> Vorverarbeiten
3. Modell:
-> Trainieren
-> Anpassen
-> in Arbeitsumgebung integrieren
Wie bereits in Teil 1 erwähnt, sind ML-Projekte höchst iterativer Natur. Das bedeutet, sie verlaufen nicht nach Plan und damit geradlinig voran. Stattdessen kann von jedem Abschnitt im Prozess zu jedem vorhergehenden zurückgesprungen werden, um die darauffolgenden dann erneut zu durchlaufen.
Das Scoping entspricht in unserem Seefahrtsgleichnis dem Setzen des richtigen Kurses. Stimmt dieser nicht, arbeiten wir in die falsche Richtung und können wertvolle Zeit und Ressourcen verlieren. Anfangs ist es noch einfacher, Korrekturen vorzunehmen. Doch je weiter unsere Reise fortgeschritten ist, desto länger und teurer werden die Umwege. Also wollen wir im späteren Verlauf des Projektes diese möglichst vermeiden.
### Lohnt sich die Reise?
Zum Scoping eines ML-Projekts gehört zunächst die Frage, ob wir die Reise überhaupt antreten wollen. Passen Ressourcen und Ziele zusammen? Oft muss man schon „losgefahren“ sein, um diese Frage zu beantworten. Denn häufig ermöglicht erst die [Sichtung der Daten](#_Daten_sichten_(was) die Einschätzung, ob der eingeschlagene Kurs Erfolg haben kann. Deshalb gilt es auch hier früh so viele Erkenntnisse wie möglich zu gewinnen.
### KI oder nicht KI?
Ein weiterer Punkt, den wir prüfen sollten ist, ob Machine Learning oder generell KI überhaupt das richtige Gefährt für unsere Reise ist. Es kann gut sein, dass wir damit durch die Gewässer kommen, die wir befahren wollen. Wie ein riesiger moderner Segler erfordert ein ML-Projekt allerdings eine entsprechend große und geschulte Mannschaft und außerdem konstante Pflege und ist bei weitem nicht so leicht zu handhaben wie ein traditionelles Boot, also eine herkömmliche Lösung.
Nicht selten erweist es sich als effektiver, einen Algorithmus zu schreiben und mit erprobten Methoden und einem eingespielten Team eine einfache Lösung zu entwickeln. Hier hat man deutlich mehr Planungssicherheit und weniger Überraschungen. KI kann ein tolles Fahrzeug mit ungeahnten Möglichkeiten sein, aber sie erfordert eben auch ein deutlich spezialisierteres Team und die Bereitschaft, größere Risiken einzugehen.
Es ist also unbedingt zu prüfen, welche Alternativen du hast. Dabei hilft es eventuell, über den Tellerrand zu blicken: Also erst einmal nachsehen, wie andere das Problem angegangen sind, bevor wir auf eigene Faust anfangen, das große KI-Schiff zu beladen!
### Welcher Weg führt zum Ziel?
Bist du die ersten Schritte gegangen und zu dem Schluss gekommen, dass sich dein Problem nicht ohne Machine Learning lösen lässt, dann kann es losgehen: Wir beginnen, die grobe Route abzustecken, auf der wir entlangsegeln wollen. Dies geschieht zunächst in Form von Meilensteinen. Eins ist aber gewiss: Nichts ist gewiss! Das heißt, wir können davon ausgehen, dass ähnlich wie bei einer Expedition zur See, die tatsächliche Route nicht mehr ganz der ursprünglich geplanten entsprechen wird.
Wie schon erwähnt: Am Anfang der Reise werden uns gröbere Kursanpassungen noch verziehen, im späteren Verlauf kosten sie uns Zeit und Geld und sollten, nach Möglichkeit, nur noch leichte Korrekturen sein. Allerdings gibt es immer mehrere Wege zum Ziel und nicht „den einen richtigen“. Es kann sich also lohnen, die Umgebung zu erforschen und mehrere Möglichkeiten auszuprobieren.
Manche Entscheidungen lohnt es aufzuschieben, bis wir Erkenntnisse aus Experimenten gewonnen haben. Denn erst dann können wir unsere Entscheidungen auf einer fundierten Basis treffen und abwägen. In manchen Fällen kann es sich auch lohnen, Kundschafter vorauszuschicken. Bei MLOps würde dies heißen, dass wir einige oder sogar alle Abschnitte mit reduzierter Komplexität ganz ablaufen, um die Machbarkeit oder Erfolgsaussichten einer geplanten Lösung abschätzen zu können. Hierzu wird es in den folgenden Episoden noch mehr Beispiele geben.
### Kenne deine Gewässer! Oder: Warum Domänenwissen wichtig ist
Wenn es um die Entwicklung von ML-Modellen bzw. KI-Projekten insgesamt geht, brauchen wir Domänenwissen. Zwar können heutige Modelle häufig auch schon ohne näheres Verständnis der Daten oder des Anwendungsgebiets vielversprechende Ergebnisse liefern. Trotzdem: Das Material zu kennen, seinen Kontext und seine Bedeutung in der „echten Welt“ zu verstehen, kann jedoch entscheidende Ideen dafür liefern, wie wir die Daten geschäftlich nutzen können oder wie wir effektiver vorgehen können. Außerdem kann das Domänenwissen dazu beitragen, deutlich schneller zum Ziel zu kommen und Ballast in Form von unnötigen Daten und Ressourcen „über Bord zu werfen“.
So wie ein IT-Team ohne KI-Kenntnisse nicht ohne Weiteres ein Modell trainieren kann, benötigen KI-Expert:innen in ihrer Mannschaft Personen mit Domänenwissen. So wie die beste Schiffscrew auch ortskundige Mitglieder braucht.
## Fazit
Das Titelbild für diesen Artikel habe ich bewusst ausgewählt: Wie der Blick durch ein Fernrohr, ermöglicht das Scoping eine klare Sicht nach vorne. So wie ich durch das Fernrohr Untiefen und Klippen entdecke, die es zu umschiffen gilt, entdecke ich auf meiner Suche nach der idealen ML-Lösung für mein Problem Stolpersteine und Risiken, die ich kennen sollte. Was ich versuche, deutlich zu machen: Es ist wichtig, zukünftige Ereignisse vorherzudenken, statt sich sofort in ein ML-Projekt zu stürzen. Denn viele Probleme erwecken zunächst den Anschein durch KI vereinfacht werden zu können, die nötigen Ressourcen und Expertise werden dabei gerne unterschätzt. Kurz: Ein ML-Projekt will gut geplant und das Problem gut verstanden sein, um auf Erfolgskurs gehen zu können!
Ich hoffe, dieser Artikel konnte dich darauf vorbereiten und dir ein Gefühl vermitteln, wie ML-Projekte angegangen werden müssen.
# Wie geht die Reise weiter?
In der nächsten Etappe unserer großen MLOps-Reise werden wir uns ganz den Daten widmen. Also den Gewässern, die wir befahren, wie wir uns in ihnen zurechtfinden, wie wir den verborgenen Schatz in den Daten identifizieren, und wie wir ihn erfolgreich heben.
Daten sind der Dreh- und Angelpunkt jedes ML-Projektes und meistens deutlich wichtiger als das ML-Modell selbst, hierbei geht es aber nicht bloß um die Auswahl der richtigen Datenquellen, sondern auch wie diese aufbereitet und weiterverarbeitet werden.
Hier gibt es zahllose Möglichkeiten und Techniken. Im nächsten Artikel versuche ich dir das Rüstzeug mitgeben, das erfahrene Seeleute brauchen, um erfolgreich durch die Datengewässer zu navigieren.
---
# Überblick Artikelreihe Machine Learning mit MLOPs:
[**-> Einführung MLOps:** Woran scheitern die meisten ML-Projekte und wie kann MLOPs helfen?](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/)
**-> Scoping:** Aktueller Artikel
[**-> Daten:** Wir lernen, die Wichtigkeit der Daten, zu schätzen, sie zu verstehen und einzuschätzen sowie die möglichen Quellen von Daten und was geschehen muss, damit wir mit ihnen Arbeiten können.](https://thecattlecrew.net/2024/10/22/machine-learning-mit-mlops-teil-3-daten-verstehen-woher-wissen-wir-ob-wir-bei-unserer-ml-ueberfahrt-auf-kurs-sind/)
**-> Modelltraining:** Was gehört dazu, ein Modell auf den eigenen Daten zu trainieren? Wie wählt man das geeignete Modell und wie können uns Automatisierung und Pipelines bei beiden Schritten die Arbeit erleichtern?
**-> Deployment:** Wie integrieren wir das Modell in ein zukünftiges oder bestehendes System bzw. eine Infrastruktur? Und welche Strategien ermöglichen einen reibungslosen Umstieg?
**-> Monitoring und Maintanance:** Wie überwachen wir ab hier unser bestehendes ML-System? Welche Entwicklungen können Anpassungen erfordern und wie bereiten wir uns auf diese vor?
**Kategorien:** AI & Data Science, DevOps
**Schlagwörter:** Artificial Intelligence, Datenstrategie, DevOps, LLM, Projektmanagement, Softwarenentwicklung, Strategie, Strategy
---
### [Machine Learning mit MLOps – Teil 3: Abtauchen ins Datenmeer. Warum Daten oft wichtiger sind als Modelle](https://thecattlecrew.net/2024/10/22/machine-learning-mit-mlops-teil-3-abtauchen-ins-datenmeer/)
**Published:** Oktober 22, 2024
**Author:** Jeffrey Remien
**Content:**
Ahoi! Ihr seid ja immer noch da! Alle, die nach den ersten beiden Etappen unserer Reise noch nicht von Bord gegangen sind, können sich die Sauerstoffflasche umschnallen, denn diesmal tauchen wir tief in die Daten ein. Wer die ersten beiden Teile dieser Serie noch nicht kennt, darf sie hier selbstverständlich gerne nachlesen:
[Einführung MLOps: Woran scheitern die meisten ML-Projekte, und wie kann MLOps helfen?](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/)
[Machine Learning mit MLOps – Teil 2: Scoping. Wie umfahren wir die Untiefen im ML-Gewässer?](https://thecattlecrew.net/2024/05/08/machine-learning-mit-mlops-teil-2-scoping/)
In den letzten beiden Artikeln dieser Serie haben wir gelernt, wie wir ein Projekt richtig einschätzen lernen. Und es ging darum, wie wir Ressourcen richtig planen und möglichen Problemen früh vorgreifen.
In diesem Artikel geht es eher darum, zu verstehen, was wir mit unseren Daten überhaupt vor uns haben. Wie diese uns helfen können, um unseren Kurs, also die Richtung unseres ML-Projekts, zu überprüfen:
- Woran erkennen wir, ob unser „Datenschatz“ ausreicht?
- Wo bekommen wir unsere (und gegebenenfalls noch weitere) Daten her?
- Wie können wir mithilfe unserer Daten früh prüfen, ob wir überhaupt auf Kurs sind?
## Warum sind Daten für MLOps wichtig?
Vielleicht fragst du dich, warum es in dieser Artikelreihe zum Thema Machine Learning in zwei Teilen ausschließlich um Daten geht. Die Antwort ist einfach: Daten entscheiden darüber, ob ein Projekt durchführbar ist. Unter uns ML-Engineers gelten die Daten deshalb als „First Class Citizen“. Sie sind für uns noch wichtiger als das Training eines Modells oder das Anpassen von dessen Parametern. Kleinste Unterschiede in Qualität, Menge oder Aufbereitung von Daten können sich auf die Trefferquote eines ML-Modells auswirken. Oder um bei unserem Seefahrtsgleichnis zu bleiben: Ein ML-Modell ohne Daten ist wie ein Schiff ohne Wasser.
## Daten: Welche und wieviel brauche ich?
Fast jedes Projekt beginnt mit dieser Frage. Und sehr häufig treten Kunden an mich heran und sind überzeugt, die nötigen Daten für das geplante Unterfangen zu haben. Und dann, bereits nach ein paar Fragen meinerseits sehen sie ihr Projekt ins Schwanken gebracht. Ddenn Daten können in unzähligen Formen vorliegen. Und: „Viele Daten“ nicht automatisch „gute Daten“. Wie auch die Seeleute unseres ML-Schiffs ihre Gewässer bestens kennen müssen, um die richtige Route einzuschlagen, müssen wir tief in die Materie unserer Kunden „eintauchen“, um unser Vorgehen zu bestimmen. Das dies nicht immer reibungslos klappt, kannst du dir sicher denken.
3 typische Hindernisse:
1. Daten an verschiedenen Orten: Gut und effektiv können wir in der Regel mit Daten arbeiten, die für uns an **einer Stelle** verfügbar sind. Hier trennt sich leider oft schon die Spreu vom Weizen. Viele Projektverantwortliche schwören mir, alle nötigen Daten zu haben. In der Realität kann das aber bedeuten, dass diese auf zehn verschiedenen Systemen verteilt sind und unterschiedliche Definitionen die gleichen Parameter besitzen. Das Zusammenführen kann zu einem Alptraum werden. Ich habe schon erlebt, dass „Wir haben alle Daten“ bedeutete, dass ich mich durch eine 20 GB große händisch ausgefüllte Excel Tabelle kämpfen musste. Natürlich hatte kein Mensch zuvor festgelegt, wie ihre Felder auszufüllen sind.
2. Unterschiedliche Sprachen: Noch schlimmer wenn die Systeme alle unterschiedliche „Sprachen sprechen“ also die Daten auf unterschiedliche Arten durch diese Systeme verfügbar gemacht werden, das eine vielleicht über eine API, das andere mittels CSV Download.
3. Privacy: Weitere Schwierigkeiten können auftreten, wenn Datenschutzrichtlinien beachtet werden müssen. Enthält der Datensatz Informationen über Privatpersonen? Welche Auflagen des Gesetzgebers und welche Firmenpolicys müssen beachtet werden? Welchen Teil der Daten können wir überhaupt verwenden? Was wenn wir nichts verwenden dürfen?
Keine Sorge! Keins dieser Probleme sorgt dafür, dass unser KI-Schiff auf dem Trockenen liegt. Aber es müssen ausreichende Vorkehrungen getroffen werden. Und als projektverantwortliche Person ist es möglich, bereits [beim Scoping](https://thecattlecrew.net/2024/05/08/machine-learning-mit-mlops-teil-2-scoping/) einige Fragen durchzugehen:
- Welche Daten werden für mein Vorhaben vermütlich nötig sein?
- Habe ich diese?
- Falls nein, weiß ich, woher ich sie beschaffen kann?
- Falls ja, in welcher Form liegen diese vor?
- Habe ich Zugriff auf diese Daten?
- Gibt es bezüglich der Daten Sicherheits- oder Datenschutzbedenken?
Die 3 genannten Hindernisse lassen sich auf vielerlei Art beseitigen:
1. **Data Warehouse:** Idealerweise wollen wir, dass unsere Daten aus einer Quelle kommen. Z. B. aus einem Data Warehouse. Dieses kann für die Integrität und Verfügbarkeit sowie Konformität unserer Daten Sorge tragen. Haben wir wie im ersten Beispiel viele unterschiedliche Quellen und vielleicht auch Protokolle oder Formate, wirkt sich das vor allem auf die Entwicklungszeit aus. Wir müssen Data Scientists beschäftigen, die sich eingehend mit den Daten beschäftigen und diese zu einem Data Warehouse oder auch einfach erstmal einer gemeinsamen Datenbank zusammenführen. Auch Dynamische Modelle exisiteren.
2. **Mit den Fachleuten sprechen:** Schildere deinen Data Scientists die Problemdomäne ausführlich und verlasse dich auf ihre Empfehlung hinsichtlich einer robusten Lösung zur Datenbereitstellung! Data Scientists sind wie Unterwasserbewohner. Daten sind ihr Meer. Darin kennen sie sich bestens aus und können uns schnell Aufschluss geben, wie wir navigieren müssen. Selbst aus der chaotischsten Excel Tabelle kann eine sinnvolle Struktur gewonnen werden. Aber das hat seinen Preis und gegebenenfalls ist es günstiger zu prüfen ob die Daten in anderer Form verfügbar gemacht werden können.
3. **Datenschutz klären:** Im Falle der ungeklärten Datenschutzbedenken müssen wir abschätzen wie relevant der personenbezogene Teil der Daten für unser Projekt ist. Eventuell können wir diese Einträge komplett ausklammern. Falls nicht sind *Anonymisierung* oder *Pseudonymisierung* die Werkzeuge unserer Wahl. Falls dies nicht ausreichend möglich ist, empfehle ich unbedingt, Datenschutzbeauftragte heranziehen. Auch dies wirkt sich natürlich auf die Kosten aus. Selbst wenn die vorher genannten Schritte möglich sind, ist es oft sinnvoll, sich kurz beraten lassen. So verhindern Sie, versehentlich gegen Auflagen zu verstoßen, die Sie später das ganze Projekt kosten können.
## Den Kurs festlegen: Baseline etablieren
Wenn Kund: innen mich fragen, ab wann es sich lohnt, mit dem Training von Modellen zu beginnen, antworte ich gerne „sofort“. Damit ist aber nicht gemeint, dass wir uns direkt eine 200 TeraFLOPS Compute-Instanz in der Cloud reservieren oder uns ein Server Rack voller GPUs ins Office stellen und anfangen, am „großen Modell“ zu arbeiten. Nein. Aber wir können kleine „Testtraings“ mit reduzierter Genauigkeit, Ressourcen und Daten machen. Diese sollen kein Modell optimieren. Vielmehr schauen wir uns an ob unsere Änderungen an den Daten(quellen) oder in der Konfiguration einen positiven Einfluss auf die Genauigkeit haben. Oder ob ein einfaches Modell einigermaßen zufriedenstellend Zusammenhänge aus den Daten beziehen kann. Daran erkennen wir früh, ob es sich lohnt so weiterzumachen wie bisher oder ob wir Faktoren ändern müssen. Wir testen sozusagen „die Gewässer“.
Aber worauf achten wir eigentlich? Und wie definieren wir „gut“ oder zumindest „zufriedenstellend“?
Das hängt von unserer Aufgabe ab: Auf Machine Learning basierte KIs werden für sehr unterschiedliche Aufgaben eingesetzt. In der Regel wollen wir etwas klassifizieren, etwa: Ob Produkte auf einem Fertigungsband Schäden aufweisen. Oder: Welchen Gesichtsausdruck eine Person hat, die in die Kamera schaut. In den anderen Fällen sind es meist Vorhersagen, wie die Fortentwicklung eines Aktienkurses oder der Zeitpunkt an dem ein Bauteil wahrscheinlich wegen seiner Vibrationen versagen wird.
Eine gute Nachricht, für alle, die aufgrund meiner vorangegangenen Aussagen etwas pessimistisch auf ML-Projekte blicken: Wir können in Jedem Fall sagen, dass wir prinzipiell jede Aufgabe in den vorher genannten Bereichen auch von einer KI übernehmen lassen können, wenn ein oder mehrere Personen sie bisher ausüben konnte und wir zu allen Informationen Zugang erhalten, zu denen diese auch diese Personen Zugang haben. (Achtung! Wie erwähnt kann es hier selbst bei alten Hasen zu massiven Fehleinschätzungen kommen.) Oder wenn wir wissen, dass es in dem was wir vorhersagen wollen eine Regelmäßigkeit oder Kausalität gibt.
Aha! Erleichterung! Leinen Los! Grünes Licht für das Projekt! Alles lässt sich mit KI lösen! Nicht so schnell … „möglich“ heißt noch nicht „machbar“!
Selbst wenn wir das Problem, das bisher eine Person gelöst hat, perfekt verstehen und wirklich sämtliche Informationsquellen zur Entscheidungsfindung identifiziert haben, könnte es sein, dass das was der Mensch intuitiv entscheidet, für einen Algorithmus ein derart großes Datenaufkommen darstellt, dass wir so viele Ressourcen aufbringen müssten, dass es günstiger wäre, hier einen Menschen einzusetzen. KI ist nach wie vor eine hochspezialisierte Technologie und je unspezifischer und „breiter“ unsere Aufgabe wird, desto schwieriger oder **teurer** wird es auch, sie mittels KI zu lösen:
- Tierarten auf Fotos erkennen? Mittlerweile eine Standardaufgabe.
- Besucherzahlen anhand von Wetter, Saison, Nachrichten und Ausfallzeiten abschätzen? Etwas kniffliger, aber wohl noch im Rahmen.
- Eine Projektstruktur entwerfen nur basierend auf verbalen Input: Möglich? Mit Sicherheit! Aber auch machbar? Mit einem dreistelligen Millionen schweren Investment und einigen Jahren Forschung könnte es gehen.
Haben wir aber ein Problem identifiziert, dessen Domäne wir gut durchblicken und das spezifisch genug ist, um im Rahmen unserer Möglichkeiten von einer KI automatisiert zu werden, dann können wir uns Gedanken über Erfolgskennzahlen machen.
In der MLOps ist die Baseline oft ein einfaches Modell oder eine Heuristik, die den aktuellen Stand der Technik oder den bisherigen Ansatz für das zu lösende Problem darstellt. Dies kann ein einfaches statistisches Modell sein, eine regelbasierte Logik oder sogar menschliche Leistung. Die Idee ist nicht, das komplexeste oder leistungsfähigste Modell zu wählen, sondern eins, das robust, verständlich und leicht zu implementieren ist.
Diese Baseline dient vor allem drei Zwecken.
1. **Sie bietet einen realistischen Maßstab für Verbesserungen.** Wenn ein neues, komplexes Modell entwickelt wird, gibt die Baseline Aufschluss darüber, wie viel besser das neue Modell im Vergleich zu einfacheren Ansätzen ist. Es ist wie das Wissen um die Geschwindigkeit und Stabilität eines alten Schiffes, bevor ein neues, modernes Schiff gebaut wird.
2. **Sie hilft, die Erwartungen zu kalibrieren.** In der Welt der MLOps ist es leicht, sich von den Versprechungen neuester Technologien mitreißen zu lassen. Doch nicht immer führen komplexere Modelle zu besseren Ergebnissen. Die Baseline erdet uns und stellt sicher, dass wir die Vorteile neuer Ansätze objektiv bewerten.
3. **Sie ermöglicht eine schnelle Iteration.** Anstatt sofort mit komplexen Modellen zu beginnen, können Entwickler: innen mit der Baseline beginnen und schrittweise Verbesserungen vornehmen. Dies ist wie das schrittweise Aufrüsten eines Schiffes, anstatt ein neues von Grund auf zu bauen.
Und wo wir zuvor gerade von Aufgaben gesprochen haben, die zuvor von Menschen gelöst wurden: eine weitere bewährte Methode, die Performance einer KI bei einer gegebenen Aufgabe zu messen, ist der Vergleich zum Menschen …
## Mensch versus Navigationssystem: Human Level Performance
Wenn wir eine Aufgabe mittels KI automatisieren wollen, die zuvor ein Mensch übernommen hat, kann die Leistung von Menschen eine gute Metrik sein, um herauszufinden, wie gut sich unsere KI macht. Idealerweise lassen wir diese auf exakt die gleichen Daten los, die auch der Mensch zu sehen bekommt. Dann müssen wir versuchen, aussagekräftige und messbare Vergleichsmetriken zu finden.
Ein Beispiel: Eine Firma, die gebrauchte Handys recycelt, hat einen Prüfstand auf dem schnell und nach „Augenmaß“ entschieden wird, ob ein Gerät erneuert und wiederverkauft werden kann, ob es sich als Ersatzteillager lohnt oder ob es keinen Wert mehr hat und komplett verschrottet werden muss.
Um uns eine zuverlässige Metrik zu schaffen, begleiten wir die Person, die für diese Entscheidungen zuständig ist, an einem typischen Arbeitstag und untersuchen alle Geräte, die sie den Tag über geprüft hat, im Labor auf tatsächliche Verwertbarkeit. Jede Entscheidung bei der das Labor mit ihrem Urteil übereinstimmt ist ein Treffer. Daraus errechnen wir eine Trefferquote zum Beispiel von 87 %. Was erstmal nach nicht viel klingt, kann im laufenden Betrieb und aus Zeitersparnisgründen trotzdem effektiv sein. Diese selben Geräte können wir auch als Maßstab für ein trainiertes Modell nutzen und so prüfen, wie nah es an die Trefferquote des Menschen herankommt. Akzeptable Ergbnisse sind, wenn wir die Ergebnisse des Menschen mindestens zu 95 % reproduzieren können. Unsere Fehlerrate ist hier also reduziert um die Leistung des Menschen, tatsächlich richtig erkannt hätte man mit dieser Quote immerhin noch 82,65 % der Geräte.
Es ist aber auch gut möglich, dass unser Modell, das ja auf tatsächlich untersuchten Geräten trainiert wird, den Menschen übertrifft und 92 % aller geräte richtig einsortiert. Dies entspräche 105 % der Trefferquote des Menschen. Aber hier müssen wir vorsichtig sein. Denn KIs können gleichzeitig auf dem Papier eine durchschnittlich deutlich bessere Performance als Menschen abliefern und die „dümmsten Fehler machen“. Das liegt daran, dass Menschen viele Entscheidungen durch weiteren Kontext treffen können, während die KI „passen“ muss, weil ihr Informationen fehlen. Human Level Performance kann also ein erster Indikator sein ob wir auf dem richtigen Weg sind und unsere Lösng **konvergiert**, sie sollte aber niemals der einzige Maßstab sein. Und unser Training sollte immer möglichst breit aufgestellt sein und viele Situationen abdecken.
Aber wie stellen wir das sicher und wo holen wir entsprechende Daten her?
## Daten kartografieren: Labeling
In manchen Fällen haben wir bereits alles was wir brauchen und können ein Modell auf unsere Daten loslassen. Sehr oft müssen wir aber Kontext hinzufügen, damit das Modell auf den erwarteten Antworten trainiert werden kann. Beispielsweise wenn wir ein Modell darauf trainieren wollen bestimmte Personen zu erkennen, wir brauchen nur zwei Listen Anlegen und unsere Fotos in diese einsortieren, die Bilder mit den zu erkennenden Personen und solche anderer zufälliger Personen. Das sind unsere Labels.
Das präzise Labeling von Daten ist wie das sorgfältige Kartografieren unerforschter Meere. Jedes Label ist ein Punkt auf der Karte, und jeder Fehler ist eine potenzielle Klippe, die unsere Reise gefährden könnte. In der Welt der MLOps ist ein akkurates und konsistentes Labeling entscheidend, um sicherzustellen, dass unser Modell die Welt so sieht und versteht, wie sie wirklich ist.
Stellen wir uns vor, wir sind Kartografen, mit der Aufgabe, unentdeckte Inseln zu kartieren. Jeder Fehler, jede falsche Markierung könnte dazu führen, dass zukünftige Seeleute in die Irre geführt werden. Ähnlich verhält es sich mit dem Labeling beim MLOps. Unsachgemäß gelabelte Daten können unser Modell in die Irre führen, zu falschen Vorhersagen führen und das Vertrauen in unsere KI-Systeme untergraben.
Das Labeling erfordert also Genauigkeit und ein tiefes Verständnis für die Daten und den Kontext, in dem sie verwendet werden. Es handelt sich um einen Prozess, der Sorgfalt und Aufmerksamkeit für Details erfordert. Wie in der Kartografie, bei der eine Person sicherstellt, dass jede Insel korrekt verzeichnet ist, müssen wir sicherstellen, dass jedes Datenlabel so präzise wie möglich ist.
Aber das Labeling ist nicht nur eine Frage der Genauigkeit. Es ist auch eine Frage der Perspektive. Wie Kartografie-Fachleute, die entscheiden, welche Merkmale einer Landschaft hervorzuheben sind, müssen wir entscheiden, welche Aspekte unserer Daten gelabelt werden müssen. Mit dem Ziel, das Problem, das wir lösen möchten, bestmöglich darzustellen. Dies erfordert ein tiefes Verständnis für das Problem und eine klare Vision davon, wie die gelabelten Daten verwendet werden sollen.
Und da Labels so gut wie immer von Menschen erstellt werden, gibt es auch hier eine Subjektivitätsfalle. Das heißt, Entscheidungen unterliegen immer auch kulturellen und persönlichen Einfärbungen und damit Vorurteilen der jeweiligen Person. Das ist unausweichlich und sollte uns daher bei jedem bereits gelabelten Datenset, das wir einkaufen, bewusst sein. Wollen wir möglichst neutrale und allgemeingültige Labels, kann es notwendig sein, ein vielfältiges Team aus diversen Persönlichkeiten zusammenzustellen.
## Fazit
Ich würde sagen: Wir erreichen gerade die 30-Meter-Marke auf unserer Tauchreise durch die Tiefen des Datenmeers. Wir haben gesehen, dass das Erfolgsgeheimnis eines ML-Projekts nicht allein in der Modellarchitektur oder den ausgeklügelten Algorithmen liegt, sondern in der gründlichen Vorbereitung und dem bewussten Umgang mit Daten. Wie ein erfahrener Kapitän, der seine Route sorgfältig plant und seine Ressourcen klug einsetzt, müssen auch wir unsere Datenlandschaft genau kartieren, potenzielle Gefahrenstellen identifizieren und frühzeitig entscheiden, ob wir auf dem richtigen Kurs sind.
Das Navigieren im Meer der Daten erfordert Präzision, Umsicht und die Bereitschaft, jederzeit auf neue Herausforderungen zu reagieren. Nur wenn wir die notwendigen Vorbereitungen treffen, können wir sicherstellen, dass unser ML-Schiff auch in stürmischen Gewässern stabil bleibt und sein Ziel erreicht.
Am Ende gilt: Die Qualität unserer Ergebnisse hängt nicht nur davon ab, wie gut unser Modell trainiert ist, sondern vor allem davon, wie gut wir unsere Daten verstehen und nutzen. Jedes Projekt ist einzigartig, und es gibt keine allgemeingültige Lösung. Doch mit einem soliden Verständnis für die Daten und einer klaren Strategie können wir den Erfolg unserer ML-Vorhaben erheblich steigern.
## Ausblick
Jetzt, wo der Kompass kalibriert ist und die Karten gezeichnet sind, kann die Reise weitergehen. Schließlich gilt es, den Schatz zu heben, der sich in unseren Daten verbirgt. Im nächsten Artikel werden wir daher die Sauerstoffflasche gegen eine Taucherglocke tauschen und noch tiefer abtauchen: Es geht um die Frage, was wir tun können, wenn die Menge oder Qualität unserer Daten nicht ausreicht und wie wir die Daten in eine Form bringen, mit der unser Modell arbeiten kann.
Oder, um in der Seefahrtssprache zu bleiben: Wie machen wir unsere Gewässer befahrbar?
---
# Überblick Artikelreihe Machine Learning mit MLOPs:
[**-> Einführung MLOps:** Woran scheitern die meisten ML-Projekte, und wie kann MLOps helfen?](https://thecattlecrew.net/2023/05/22/machine-learning-mit-mlops-teil-1-in-die-falle-getappt-woran-viele-ml-projekte-scheitern-und-wie-mlops-dies-verhindern-kann-zwei-beispiele/)
[**-> Scoping mit MLOps:** Wie schätze ich ein Projekt und die dafür benötigten Ressourcen richtig ein?](https://thecattlecrew.net/2024/05/08/machine-learning-mit-mlops-teil-2-scoping/)
**-> Daten verstehen mit MLOps:** Aktueller Artikel
**-> Daten verarbeiten mit MLOps:** Wie hole ich das Meiste aus meinen Daten heraus?
**-> Modelltraining:** Was brauche ich, um ein Modell auf den eigenen Daten zu trainieren? Wie wähle ich das geeignete Modell und wie können Automatisierung und Pipelines die Arbeit erleichtern?
**-> Deployment:** Wie integriere ich das Modell in ein zukünftiges oder bestehendes System bzw. eine Infrastruktur? Welche Strategien ermöglichen einen reibungslosen Umstieg?
**-> Monitoring und Maintenance:** Wie überwachen wir ab hier unser bestehendes ML-System? Welche Entwicklungen können Anpassungen erfordern? Wie bereiten wir uns auf diese vor?
**Kategorien:** AI & Data Science, Analytics & Insights, DevOps
---
### [Remix – eine Alternative für Geschäftsanwendungen](https://thecattlecrew.net/2024/09/06/remix-eine-alternative-fuer-geschaeftsanwendungen/)
**Published:** September 6, 2024
**Author:** Richard Attermeyer
**Content:**
In dieser Blog-Serie möchte ich euch das Full Stack Framework Remix als eine vielversprechende Alternative vorstellen, insbesondere für die Entwicklung von Geschäftsanwendungen.
Darum geht’s in dieser ersten Folge:
- Wie hat sich die Entwicklung von Business Applications in den letzten Jahren verändert?
- Welche technischen Herausforderungen haben dazu geführt, dass wir heute dort stehen, wo wir stehen?
- Welche weiteren Technologien gibt es, und was ist das Besondere an Remix?
Viel Spaß beim Lesen!
## Rückblick auf die Vergangenheit
Vor 10 bis 15 Jahren war es noch üblich, Geschäftsanwendungen mittels serverseitigem Rendering zu entwickeln. Frameworks wie PHP, Ruby on Rails, ASP.NET oder Java Server Faces dominierten diese Ära. Die Anwendungen wurden auf dem Server gerendert und als HTML an den Browser ausgeliefert.
JavaScript war damals nicht sehr populär, da Browser noch nicht so standardisiert und performant waren wie heute.
Allerdings hatten diese serverseitig gerenderten Anwendungen einen entscheidenden Nachteil gegenüber klassischen Desktop-Anwendungen, die sie ablösen sollten: Sie waren nicht so responsiv und interaktiv. Deshalb führte der ständige Austausch mit dem Server zu einer langsamen Benutzererfahrung.
## Die Ära der Single Page Applications (SPA)
Mit der Einführung von AJAX und später Single Page Applications (SPA) änderte sich dies. Anwendungen wurden interaktiver und responsiver. SPAs kommunizieren über HTTP APIs, die Daten im JSON-Format austauschen, wodurch das Frontend im Browser gerendert und die Daten über APIs geladen werden. Dies führte zur Verbreitung des REST-Paradigmas.
Abbildung 1. Klassische SPA-Architektur
## Herausforderungen und Komplexität von SPAs
Die Umstellung auf SPAs brachte jedoch einige Herausforderungen mit sich:
- Komplexität der Netzwerkkommunikation: Daten mussten häufig mehrfach gemappt werden, was fehleranfällig und zeitaufwendig war.
- Overfetching und Underfetching: REST-APIs lieferten oft entweder zu viele oder zu wenige Daten, was zu ineffizientem Datenmanagement führte.
- Fragmentierung der Daten: Durch die Einführung von Microservices wurden Daten auf verschiedene Services verteilt, was die Datenabfrage komplexer machte.
Abbildung 2. Whitebox SPA
Die Komplexität lag auch darin begründet, dass viel „Boilerplate Code“ geschrieben wurde, um Daten zwischen Datenbank und UI auszutauschen. Die Architektur der Whitebox SPA ermöglichte z. B. diese beiden Funktionen:
1. Definition von JPA Entites und **Mapping** zwischen SQL und Java Objekten
2. **Mapping** zwischen Java Objekten und JSON
Wir haben hier ein Objektmodell, ein JSON Modell und Mappings drin, die gepflegt werden müssen. Dies ist nicht nur fehleranfällig, sondern auch zeitaufwändig.
Für bestimmte Use Cases konnten Ansätze wie Spring Data REST weiterhelfen. Diese automatisieren zum Teil das Mapping, zumindest Richtung REST. Daraus ergibt sich dann wieder ein Code-First-Ansatz für REST-Schnittstellen. Was in Ordnung sein kann, wenn es sich um private Schnittstellen handelt. Leider ist die Trennung zwischen „privaten“ und „öffentlichen“ Business-API-Schnittstellen nicht immer so klar:
Private Schnittstellen sind z. B. von einem Backend for Frontend (BFF) für ein bestimmtes UI optimiert mit speziellen Schnittstellen. Dies kann dazu führen, dass wir, obwohl wir eine „Business API“ ansteuern wollen, bei einer spezifischen BFF-Schnittstelle landen, die eigentlich privat sein sollte.
Ferner war hier zu beobachten, dass wir Validierungslogik häufig doppelt implementieren. Hier können generierende Ansätze helfen, die aus Java-Klassen (Annotationen) entsprechende Zod-Schemata generieren. Hierzu empfehle ich den Post: [Validieren mit Zod: zwischen Frontend und Backend](https://thecattlecrew.net/2024/07/08/validieren-mit-zod-zwischen-frontend-und-backend/).
## Lösungsansätze: BFF und GraphQL
So langsam wurden auch bei der Benutzung von REST Probleme sichtbar. Ein zentrales Problem war es, Daten bei einem REST-Architekturstil so zu laden, wie das Frontend sie für einen bestimmten Use Case benötigt. Dahinter verbarg sich das Phänomen des Overfetching und Underfetching, von dem oben schon einmal die Rede war. Es werden also zu viele oder zu wenige Daten vom Backend geladen. Mit diesen Folgen:
- **Overfetching** hat zur Folge, dass die Latenzzeit und die Datenmenge, die übertragen werden muss – gerade auch im mobilen Bereich – steigen.
- **Underfetching** hat zur Folge, dass mehrere Requests gemacht werden müssen, um die Daten zu laden, die für einen Use Case benötigt werden. Dies erhöht die Latenzzeit und die Komplexität der Anwendung. Gleichzeitig muss das Frontend wissen, welche Endpunkte es ansprechen muss, um die Daten zu laden. Mit der Einführung von Microservices, ist dies häufig nicht mehr so einfach, da die Daten auf verschiedene Services verteilt sind.
Um das Problem zu lösen, gibt es verschiedene Lösungen:
Zum einen wurde je Frontend ein spezielles Backend entwickelt, das die Daten so liefert, wie das Frontend sie benötigt. Diese Lösung ist als [„Backend for Frontend“](https://bff-patterns.com) bekannt. Eine andere Lösung ist die Einführung von GraphQL oder Falcor.
Diese Technologien erlauben dem Frontend, die Daten zu laden, die es benötigt. Hier hat sich klar GraphQL durchgesetzt. Der GraphQL Server fungiert dabei häufig als Gateway zu den Microservices. Das Frontend braucht nur noch den GraphQL Server ansprechen und bekommt die Daten, die es benötigt.
Wer ein Frontend auf mehrere Backend Microservices aufsetzen muss, ist immer noch mit dieser Technologie oder anderen Technologien, die das gleiche Problem lösen, gut beraten, wie etwa tRPC.
Allerdings wird diese Komplexität für viele Geschäftsanwendungen mit einer überschaubaren Nutzerbasis gar nicht benötigt. Man würde gerne die Vorteile von Single Page Applications nutzen, aber nicht die Komplexität, die damit einhergeht. Die Entwicklung solcher Anwendungen scheint damit zu teuer und zu komplex zu werden.
## Lösungsansatz: Low Code
Vielleicht verstärkt u. a. diese Situation auch den Trend zu No-Code- und Low-Code- Plattformen. Denn diese versprechen die Entwicklung solcher Anwendungen drastisch zu vereinfachen und zu beschleunigen. Aus meiner Sicht allerdings leider auf Kosten von Flexibilität und Kontrolle über die Anwendungen. Denn hier kommt es zu einem starken Vendor Lock-in. Irgendwie erinnert mich das an die 90er Jahre und das Aufkommen von [4GL Sprachen](https://de.wikipedia.org/wiki/4GL). Der Wechsel zu einer anderen Technologie kann schwierig und kostspielig werden. Low-Code-Plattformen sind sehr „opinionated“ in der Art und Weise, wie Software entwickelt wird. Sie bieten vorgefertigte Bausteine und Prozesse. Die können die Entwicklung beschleunigen, bei spezifischen Anforderungen aber an Grenzen stoßen. Häufig bedeuten sie aus meiner Sicht eher einen Rückschritt in der Softwareentwicklung.
- Wenige unterstützen sauberes Unit Testing und die Integration in CI/CD Pipelines.
- Ebenfalls stellen wir immer wieder fest, dass die Entwicklungskosten gesenkt werden, aber die Gesamtkosten aufgrund von Lizenzkosten und Abo-Gebühren steigen. Gerade, wenn dann die Nutzeranzahl steigt, kann es schnell teuer werden.
- Aufgrund der hohen Abhängigkeit von den Plattformen, kann es auch schwierig werden, die Anwendung zu skalieren oder zu migrieren.
- Gleichzeitig benötigt man für die Entwicklung dieser Anwendungen auch noch Entwickler, die sich mit der Plattform auskennen. Die Plattformen sind also nicht so einfach zu bedienen, wie es auf den ersten Blick scheint.
Was aber tun, wenn wir Entwicklungsgeschwindigkeit und Entwicklungskosten senken wollen, aber gleichzeitig keine Kompromisse bei Standard-Technologien und einem relativ un-opinionated Ansatz eingehen wollen? Was gibt es für Alternativen?
## Lösungsansatz: Fullstack Frameworks
Hier kommt Remix ins Spiel. Remix ist ein sogenanntes Fullstack Framework, das auf React und React Router aufsetzt. [Next.js](https://nextjs.org) ist der Platzhirsch im React-Umfeld, aber auch für andere SPA Frameworks gibt es Fullstack Frameworks, wie [Nuxt.js](https://nuxt.com) für Vue.js oder [SvelteKit](https://kit.svelte.dev) für Svelte. Nur für Angular ist das Angebot dünn. Es gibt mit [Analog](https://analogjs.org) ein Fullstack Framework, das auf Angular aufsetzt, aber es ist noch nicht so ausgereift wie die anderen Frameworks.
Viele Fullstack Frameworks motivieren sich über den Aspekt der Search-Engine-Optimierung (SEO). Da HTML-Seiten auf dem Server gerendert werden, sind diese Anwendungen für Suchmaschinen unter Umständen besser geeignet. Dies ist sicherlich wichtig für Anwendungen, die öffentlich zugänglich sind und von Suchmaschinen indexiert werden sollen. Für interne Anwendungen ist der SEO-Aspekt weniger interessant.
Der generelle Aufbau sieht wie folgt aus
Abbildung 3. Whitebox Remix
Im Gegensatz zum ersten Ansatz mit dem Ökosystem-Bruch (JavaScript/Java), haben wir hier einen durchgängigen Ansatz. Wir brauchen keine unnötigen Mappings zu definieren, da wir direkt JSON aus der Datenbank bekommen. Außerdem definieren wir nur einmal die Validierungslogik für die Daten und können diese dann sowohl im Frontend als auch im Backend nutzen. Remix sorgt als Aufsatz auf „React Router“ dafür, dass folgende vier Dinge bereitgestellt werden:
1. ein Compiler
2. ein HTTP Handler (Runtime Server Adapter)
3. ein Server Framework
4. ein Browser Framework
Eine detaillerte Beschreibung findet sich in der [Remix-Dokumentation](https://remix.run/docs/en/main/discussion/introduction). Einer der wesentlichen Unterschiede zu der Entwicklung mit einer REST API wie Spring MVC ist, dass Remix UI zentrisch ist. Während man bei der Implementierung einer REST API einen Controller implementiert, der mehrere URLs für ein einzelnes Modell bereitstellt, ist bei Remix immer eine Datei für das Laden, die Manipulation und das Layout zuständig. Dabei kann eine Route auf ein Segment einer URL mappen. Remix aggregiert Daten und Komponenten, um dann die komplette UI auszuliefern.
Mit diesem Ansatz erfüllt Remix einige der Anforderungen, die wir an eine Geschäftsanwendung haben:
- Serverseitiger Zugriff auf Datenbanken
- Authentifizierung und Autorisierung
- Testbarkeit
- Integration von Frontend und Backend, ohne dass wir uns um die Details kümmern müssen
Einiges davon wird schon durch das Node.js-Ökosystem abgedeckt. Aber gerade der letzte Punkt, also die Integration von Fronend und Backend, ist die Domäne der Fullstack Frameworks. Dies wird als Hydration und Dehydration bezeichnet.
## React-Ökosystem für Geschäftsanwendungen
Für Geschäftsanwendungen ebenfalls häufig wichtig sind aus meiner Sicht zwei Dinge:
- Mächtige Tabellen
- Formulare und Validierung
Beides wird von Remix nicht bereitgestellt.
Für Tabellen setzen wir auf Mantine React Tables bzw. Material React Tables. Diese Komponenten setzen wiederum auf der (Headless) Tanstack Table auf. Neben der kommerziellen [AG-Grid](https://www.ag-grid.com)-Komponente ist das sicherlich eine der mächtigsten Tabellenkomponenten im React-Umfeld.
Für Formulare und Validierung setzen wir auf remix-hook-form, eine kleine Erweiterung von react-hook-form.
Stellt sich aber immer noch die Frage, warum wir Remix statt Next.js einsetzen. Denn war Next.js nicht der Platzhirsch im React Umfeld? Antworten findet ihr z. B. auf Prisimic.io. Dort gibt es einen [Blogpost](https://prismic.io/blog/compare-remix-vs-nextjs#should-you-use-remix-or-next), der die beiden Frameworks vergleicht. Oer ihr lest einfach hier weiter:
### Remix versus Next.js
Vor allem diese vier Argumente sprechen für die Wahl von Remix als Technologie statt Next.js:
- Remix setzt auf React Router auf (d. h. wir können Wissen wiederverwenden, etwa auch für klassische React-Projekte)
- Remix kann als Web Standard genutzt werden (Flexiblität für unterschiedliche Einsatzszenarien)
- Remix hat keine („unnötigen“) Extra-Features
- Bei Remix findet automatische State Synchronisation zwischen Server und UI statt, wenn wir Actions für die Manipulation von Daten verwenden
Insgesamt bietet Remix also genau das, was wir brauchen, um eine Fullstack-React-Anwendung zu bauen, und das ohne weiteren Overhead. Das hat den Vorteil, dass die Lernkurve relativ flach bleibt und man schnell produktiv werden kann.
Wobei der Punkt „unnötigte“ Extra Features natürlich immer eine Frage des Standpunkts ist, schon klar!
Aber einiges, was Next.JS anbietet, wie Static Site Generate oder Incremental Static Regeneration, ist für Geschäftsanwendungen tatsächlich weniger wichtig. Denn hier ist es eher fragwürdig, Daten zu cachen, die ein Nutzer ändern kann. HTTP Caching ist eher etwas für öffentliche Daten, die durch Back-Office Prozesse aktualisiert werden. Da bin ich ganz beim [Standpunkt](https://github.com/remix-run/remix/discussions/1228) von Ryan Florence, einem der Köpfe hinter Remix. Von Florence kann ich auch diese Quelle empfehlen: [CDN Caching, SSG, and SSR](https://youtu.be/bfLFHp7Sbkg?si=T6ROk_sOkch_J8We). Was er sagt, ist nicht nur relevant für CDN Caching, sondern für jede Art von Reverse Proxy vor dem eigentlichen Server. Das heißt, auch wenn wir etwa einen Caddy Server oder einen Nginx Server vor unserem Node.js Server haben.
Bisher haben wir eine reine React-Fullstack-Anwendung gesehen. Was wir aber häufig antreffen, ist eine Aufteilung: Für alle UI relevanten Aspekte wird Remix verwendet, für die Integration mit Fremdsystemen und komplexe Business-Logik ein Java Backend. Die Integration mit Umsystemen sollte ja möglichst asynchron erfolgen, gegebenenfalls werden diese gecacht. Die Beantwortung einer UI-Integration erfolgt dann möglichst innerhalb des eigenen Systems.
Daher wird Remix bei etwas komplexeren Anforderungen nicht alleine genutzt, sondern in Kombination mit einem Java Backend.
Abbildung 4. Komplexere Remix-/Spring-Architektur
Das wäre es für diesen Post. Doch es geht weiter:
In der nächsten Folge könnt ihr erleben, wie sich das Framework im Alltag anfühlt, wenn wir damit entwickeln und einen einfachen CRUD Use Case umsetzen: [Remix: Data Routes und Data Loading](https://thecattlecrew.net/2024/09/13/remix-routes-und-data-loading/)
*Alle Teile dieser Blogserie:*
*[Teil 1: Remix – eine Alternative für Geschäftsanwendungen](https://thecattlecrew.net/2024/09/06/remix-eine-alternative-fuer-geschaeftsanwendungen/)*
[*Teil 2: Remix – Routes und Data Loading*](https://thecattlecrew.net/2024/09/13/remix-routes-und-data-loading/)
[*Teil 3: Remix – Formulare, Validierung und Datenänderungen*](https://thecattlecrew.net/2024/09/27/remix-formulare-validierung-und-datenaenderungen/)
**Kategorien:** Architecture & Process Models, Development
**Schlagwörter:** Business Application, Full Stack Framework, Geschäftsanwendung, React, Remix, Software-Architektur, Softwarenentwicklung, Webentwicklung
---
### [Remix: Routes und Data Loading](https://thecattlecrew.net/2024/09/13/remix-routes-und-data-loading/)
**Published:** September 13, 2024
**Author:** Richard Attermeyer
**Content:**
Nachdem wir im ersten Teil dieser Serie die [Vorteile von Typescript Fullstack Frameworks wie Remix](https://thecattlecrew.net/2024/09/06/remix-eine-alternative-fuer-geschaeftsanwendungen/) betrachtet haben, wollen wir in diesem zweiten Teil damit anfangen, Remix in Action zu bringen. Dazu bauen wir eine Trackliste für Musikalben. Also: Kopfhörer anlegen und los geht’s.
## Wir deployen Remix
Remix lässt sich auf unterschiedliche Arten deployen. Es hat keine feste Bindung etwa an Node.JS. Alles, was es braucht, ist ein kleiner Adapter. Die gibt es als offizielle Varianten vom Remix Team oder auch von der Community.
Wer Remix selbst betreibt, wird wahrscheinlich Node.JS, Deno oder Express verwenden. Wer Remix auf einem CDN betreibt, kann auch einen Adapter für Cloudflare oder Netlify verwenden. Wir werden Remix mit einem Node.JS Adapter verwenden. Den Source Code findet ihr auf [github](https://github.com/opitzconsulting/remix-blog).
Wir verwenden für unser Beispiel eine einfache Datenbank, die [Chinook-Datenbank](https://github.com/lerocha/chinook-database). Die Chinook-Datenbank repräsentiert eine Musikverkaufsplattform mit Tabellen für Künstler, Alben, Tracks, Kunden, Bestellungen, …?
Damit wir uns um die Remix-bezogenen Aspekte kümmern können, gibt es mit dem branch `blog-start` einen Startpunkt. Dort sind alle Tools und Technologien schon so aufgesetzt, dass wir loslegen können.
## **Wir legen unsere Track-Seite an**
Wir wollen eine Seite aufbauen, die es erlaubt über eine Select-Box ein Album auszuwählen. Im unteren Bereich werden die Tracks angezeigt.
Abbildung 1. Screenshot-Album / Tracks-Seite
## Wir definieren Remix-Routen
Die Frage, die wir uns stellen müssen, ist wie wir die Seiten und angezeigte Daten auf Remix-Routen mappen. Generell gibt es dazu mehrere Möglichkeiten:
1. Wir bauen zwei Seiten und zwei Routen `/albums` und `/albums/:albumId/tracks`. Dabei müssen wir aber überlegen, wie wir vermeiden, dass die Select Box nicht doppelt genutzt wird.
2. Wir bauen verschachtelte Routen `/albums` und `/albums/:albumId/tracks`. Die erste Route stellt das generelle Layout bereit und die zweite Route wird an der entsprechenden Stelle eingebettet.
Wir werden die zweite Möglichkeit nutzen.
### So baut ihr Layouts und Routen
Der Layout-Code für die `/albums`-Route sieht wie folgt aus:
Albums-Komponente
```
export default function Albums() {
// einige Zeilen ausgelassen
// ...
return (
Albums
{
setSelectedAlbum(value)
const album = getAlbum(value)
album ? navigate(`/albums/${album?.album_id}/tracks`) : navigate(`/albums`)
}}
label={"Albums"}
clearable
/>
// rendered die verschachtelte Route
);
}
```
Der Layout-Code für die `/albums/:albumId/tracks`-Route sieht wie in Listing Track-Komponente aus. Er stellt im Wesentlichen eine Tabelle dar.
Listing: Track-Komponente
```
export default function Tracks() {
// einige Zeilen ausgelassen
return
{album?.album_title}
{album?.artist_name}
{tracks.length} tracks
}
```
Die Konvention ist, dass die Dateien im `/routes`-Ordner die Routen repräsentieren.
```
src/
app/
routes/
albums.tsx // Die Album Route
albums.$id.tracks.tsx // Tracks Route, mit einem dynamischen Segment $id
```
Es gibt eine sehr gute [Visualisierung](https://interactive-remix-routing-v2.netlify.app/actors/trending) von Dilum Sanjaya, die zeigt, wie Routen auf dem Dateisystem zu URLs gemappt werden.
Die hier dargestellte Konvention ist die bevorzugte Methode, um Routen in Remix zu definieren. Es gibt aber auch andere Möglichkeiten, etwa über Ordner oder eine komplett manuelle Konfiguration.
### So funktioniert die Verschachtelung
Was man hier sieht ist: ein Punkt `.` im Dateinamen wird zu einem `/` in der URL **und** sorgt für die Verschachtelung (nesting) der Routen.
Da man mit den Dateinamen auch die möglichen URLs definiert, gibt es weitere Möglichkeiten, je nach Anwendungsfall, etwa
- verschachtelte URLs ohne verschachteltes Layout
- verschachtelte Layouts ohne verschachtelte URLs
- Optionale URL Segmente
- Splat Routes, die beliebig viele Segmente aufnehmen können (den Rest der URL)
Die [Dokumentation](https://remix.run/docs/en/main/file-conventions/routes) über Routen sollte man sich auf jeden Fall gründlich durchlesen, gerne auch nochmal, wenn man ein paar Seiten gebaut hat.
## Wir nutzen das Route Modul
Nachdem wir die Routen definiert haben, müssen wir uns um das Data Loading kümmern. Unsere Routen enthalten aktuell nur den default export.
Die Dateien (Routen), die wir oben erzeugt haben, sind Typescript-(ESM)-Module. Das Route Modul kann verschiedene Exporte haben, die von Remix interpretiert werden.
Zu den typischen Exporten gehören:
- loader
- action
- Component (default export)
- ErrorBoundary
- headers
Letztere Funktion wird häufig verwendet, um die Cache-Control Header (für öffentliche Routen) zu setzen. Details zu den verschiedenen Exporten findet sich unter dem Stichwort [Route Module](https://remix.run/docs/en/main/route/action) in der Remix-Dokumentation.
### So funktionert das Data Loading
Wir wollen jetzt alle Musikalben laden, um sie in der Select Box anzuzeigen. Dazu verwenden wir den `loader-`Export.
```
export const loader = async ({request}: LoaderFunctionArgs) => {
const albums = await db.query.album_viewInChinook.findMany();
return json({albums});
};
```
Auf das Laden aus der Datenbank gehen wir hier nicht weiter ein. Die Anwendung verwendet drizzle-orm als ORM.
Interessant ist die Rückgabe über die [json-Hilfsfunktion](https://remix.run/docs/en/main/utils/json). Sie erzeugt ein JSON Response Object, welches in der Komponente verwendet werden kann:
```
export default function Albums() {
const {albums} = useLoaderData();
// ...
}
```
Dabei ist unerheblich, ob die Komponenten auf dem Server oder auf dem Client gerendert wird. Remix sorgt dafür, dass die Daten, die im Loader geladen wurden, in der Komponente genutzt werden können. Danach kann man einfach auf das Typescript-Objekt zugreifen. Dies vereinfacht das Zusammenspiel mit dem Backend enorm.
### So klappt die Navigation
Für die Navigation verwenden wir eine Mantine Select Box. Mittels `onChange` navigieren wir dort zur nächsten Route. Dazu nutzen wir einen weiteren Remix Hook `useNavigate`.
```
onChange={(value) => {
setSelectedAlbum(value)
const album = getAlbum(value)
album ? navigate(`/albums/${album?.album_id}/tracks`) : navigate(`/albums`)
}}
```
Wenn ein Album ausgewählt wurde, navigieren wir die Route an, die auch die Tracks darstellt. Im anderen Fall, wenn etwa die Select-Box geleert wird, navigieren wir zurück zur Album-Route.
### Ähnlichkeiten: Remix und React Router
Übrigens stammt Remix von den Machern von [React Router](https://reactrouter.com/en/main). Deshalb heißt es auf der Webseite mittlerweile „Made by Remix“. Und so kommt es auch, dass sich ``, `loader()`, `useNavigate()`, `json()` und viele andere Hooks und Utilities auch in React Router finden. Bei Remix sind die Module hingegen aus `@remix-run/react` zu importieren. Dies bedeutet aber auch, dass das Wissen für beide Frameworks wiederverwendet werden kann. React Router kennt ebenso das Konzept von verschachtelten Routen. Ein Tipp: Manchmal ist es hilfreich, in die Dokumentation von React Router zu schauen, wenn man etwas in der Remix-Dokumentation nicht findet!
## Wir verwenden Track-Route und ErrorBoundaries
Hier gibt es nichts Neues bzgl. des Ladens und Anzeigens der Tracks. Auch hier nutzen wir [Mantine React Table,](https://www.mantine-react-table.com) um die Tracks anzuzeigen. Spannender ist es, die Funktion der Error Boundaries zu betrachten:
Dazu definieren wir im Track-Modul eine Funktion `ErrorBoundary`:
```
export function ErrorBoundary() {
const error = useRouteError()
console.log(error)
return
Nothing to Display
}
```
Wenn wir jetzt im Loader einen Fehler werfen:
```
export const loader = async ({request, params}: LoaderFunctionArgs) => {
// ausgeblendeter Code...
throw new Error('test')
return json({tracks, album});
}
```
Dann sehen wir statt der Trackliste die Fehlermeldung „Nothing to Display“. Es ist also nur ein Teil der Seite betroffen und nicht die gesamte Anwendung.
Auch in der neuesten React Router Version 6.4 gibt es für die Data Router die Möglichkeit, Error Boundaries zu [definieren](https://reactrouter.com/en/main/hooks/use-route-error).
## Summary
Das Laden von Daten, Navigation und Error Boundaries sind die wichtigsten Konzepte von Remix. Dadurch, dass Remix das Thema REST Kommunikation kapselt, vereinfacht es die Kommunikation mit dem Backend enorm.
Im nächsten Teil dieser Serie geht es darum, in Remix Daten zu erstellen und zu ändern. Insbesondere, wenn ihr mit Geschäftsanwendungen zu tun habt, solltet ihr den Blogpost nicht verpassen!
*Alle Teile dieser Blogserie:*
*[Teil 1: Remix – eine Alternative für Geschäftsanwendungen](https://thecattlecrew.net/2024/09/06/remix-eine-alternative-fuer-geschaeftsanwendungen/)*
[*Teil 2: Remix – Routes und Data Loading*](https://thecattlecrew.net/2024/09/13/remix-routes-und-data-loading/)
[*Teil 3: Remix – Formulare, Validierung und Datenänderungen*](https://thecattlecrew.net/2024/09/27/remix-formulare-validierung-und-datenaenderungen/)
**Kategorien:** Development
**Schlagwörter:** Business Application, Full Stack Framework, Geschäftsanwendung, React, Remix, Software-Architektur, Softwarenentwicklung, Webentwicklung
---
### [Remix: Formulare, Validierung und Datenänderungen](https://thecattlecrew.net/2024/09/27/remix-formulare-validierung-und-datenaenderungen/)
**Published:** September 27, 2024
**Author:** Richard Attermeyer
**Content:**
Gerade in Geschäftsanwendungen brauchen wir Formulare, um Daten zu erstellen und zu ändern. In einem Customer Relationship Management (CRM)-System bearbeiten Benutzer beispielsweise Kundendaten wie Namen, Adressen und Kontaktinformationen.
Remix, als modernes Fullstack-Framework, kann sicherstellen, dass diese Daten in Echtzeit geladen und aktualisiert werden, ohne dass die Seite neu geladen wird. Durch „Actions“ und „Loaders“ werden nur die Daten aktualisiert, die wir brauchen, was die Benutzererfahrung verbessert und Systemressourcen spart.
Remix folgt da seiner Philosophie, baut auf Webstandards und nutzt HTML-Formulare als zentrales Element für die Kommunikation von Datenänderungen mit dem Backend, statt alles auf einer separaten REST-Kommunikation aufzubauen.
In diesem dritten Teil unserer Blogserie zu Remix wollen wir uns das in der Praxis ansehen. Dabei bleiben wir in der Musikbranche:
1. Beispiele für Kundendaten aus dem Musikvertrieb bekommen wir uns in der Chinook-Datenbank.
2. Dann erstellen wir ein Formular, um die Daten zu ändern.
*Du bist neu in dieser Blogserie? Hier kannst du Teil 1 und Teil 2 nachlesen:*
*[Teil 1: Remix – eine Alternative für Geschäftsanwendungen](https://thecattlecrew.net/2024/09/06/remix-eine-alternative-fuer-geschaeftsanwendungen/)*
*[Teil 2: Remix: Routes und Data Loading](https://thecattlecrew.net/2024/09/13/remix-routes-und-data-loading/)*
## So geht’s:
Zunächst erstellen wir diese Routen: ([Mehr über Routen in Remix erfahren)](https://remix.run/docs/en/main/file-conventions/routes)
- `customers` als Layout, das aktuell nur den Header bereitstellt
- `customers._index` für die Übersicht der Kunden
- `customers.edit.$id` für die Bearbeitung eines Kunden
- `customers.create` für das Anlegen eines neuen Kunden
- `customers.delete` für das Löschen eines Kunden
### Action-Funktion
Die Route-Module haben einen weiteren Export: die [`action`-Funktion](https://remix.run/docs/en/main/route/action).
Diese Funktion wird bei Non-GET-Anfragen (`DELETE`, `POST`, `PUT`, `PATCH`) aufgerufen, bevor die `loader`-Funktion aufgerufen wird. Die Loader-Funktion wird aufgerufen, um die geänderten Daten zu laden und zu revalidieren. Damit wird ein Statusabgleich zwischen Server und Client hergestellt.
Remix weiß in der Regel, welche Loader-Funktionen optimaler Weise aufgerufen werden müssen und wann. Zusätzlich, falls benötigt, kann dies über die Funktion [`shouldRevalidate`](https://remix.run/docs/en/main/route/should-revalidate) gesteuert werden.
Wie der `loader` ist `action` Teil der öffentlichen API. Das heißt, Daten, die wir über die Action-Funktion empfangen, müssen – wie alle Daten aus dem Web – validiert werden.
Und damit kommen wir zu einem weiteren wesentlichen Aspekt:
### Benutzereingaben validieren
Daten, die eine Person zum Beispiel über Formulare eingibt, müssen validiert werden. Bei Webanwendungen sorgen wir für eine Validierung in der Regel sowohl auf der Client- als auch auf der Server-Seite. Vor allem die Validierung auf der Server-Seite ist ein Muss, da die Client-Seite manipuliert werden kann.
Wie aber schaffen wir es, dass wir die Validierungslogik nur einmal schreiben müssen und sie danach sowohl auf der Client- wie auch auf der Serverseite verwenden können? Warum?
Dies wäre ein großer Vorteil für die Wartbarkeit und die Sicherheit der Anwendung. Eine doppelte Implementierung erzeugt nicht nur mehr Aufwand bei der initialen Erstellung und auch bei der Wartung, sondern birgt auch die Gefahr, dass die Regeln unterschiedlich implementiert werden. Dies hätte zur FOlge, dass das Frontend Eingaben zulässt, die das Backend dann zurückweist. Der Frust bei denjenigen, die die Anwendung benutzen, wäre vorstellbar.
Viele Ansätze für die Validierung setzen in dem Fall auf die Verwendung von Schemata. Eine Bibliothek, die dies ermöglicht, ist [`zod`](https://zod.dev).
Zod selbst ist für jede Art von TypeScript-Anwendung einsetzbar, weiß aber selbst zunächst noch nichts von HTML-Formularen. Hier kommen weitere Bibliotheken ins Spiel. Eine beliebte Bibliothek für die Formularvalidierung in React ist [`react-hook-form`](https://react-hook-form.com). Diese Bibliothek kann mit `zod` kombiniert werden, um die Validierung auf der Clientseite zu übernehmen.
Mit [`remix-hook-form`](https://github.com/forge42dev/remix-hook-form) gibt es eine für Remix abgestimmte Integration von `react-hook-form`. Dieser Adapter ist im Kern keine 300 Zeilen lang.
Andere Vertreter sind
- [remix-validated-form](https://www.remix-validated-form.io)
- [remix-forms](https://github.com/seasonedcc/remix-forms)
- [conform](https://github.com/edmundhung/conform)
Jede dieser Bibliotheken kann die Kombination mit Zod. Deshalb sind sie für die Validierung auf Client- und Serverseite verwendbar. Wir haben uns übrigens auch deshalb für Remix Hook Form entschieden, weil es auf React Hook Form aufsetzt, das wir bereits für andere Projekte verwenden.
### „Unsere“ Action-Funktion
In `customers._create.tsx` haben wir die folgende Action-Funktion:
```
const resolver = zodResolver(customerCreateForm);
export const action = async ({ request }: ActionFunctionArgs) => {
const {
errors,
data,
receivedValues: defaultValues,
} = await getValidatedFormData(request, resolver);
if (errors) {
return json({ errors, defaultValues });
}
const insertedCustomers = await db
.insert(customerInChinook)
.values(data)
.returning();
if (insertedCustomers.length === 0) {
return json({ errors: { root: { type: "insert_failed" } } });
}
return redirect(`/customers/edit/${insertedCustomers[0].customer_id}`);
};
```
Die Funktion verwendet die `getValidatedFormData`-Funktion von Remix Hook Form, um die Daten gegen das `CustomerCreateForm`-Schema zu validieren. Falls Fehler auftreten, werden diese zurückgegeben. Remix Hook Form kümmert sich um die Interpretion von Fehlern und `defaultValues` für das Formular. Die Magic passiert dabei im Hook `useRemixForm`, das einen angepassten submitHandler bereitstellt.
Die Nutzung in der Komponente ist dabei sehr einfach:
```
export default function CustomersCreate() {
const {
handleSubmit,
formState: { errors },
register,
} = useRemixForm({
mode: "onSubmit",
reValidateMode: "onBlur",
resolver,
});
return (
Submit
);
}
```
Etwas mehr Aufwand ist notwendig, wenn es sich um [Controlled-Komponenten](https://react.dev/learn/sharing-state-between-components#controlled-and-uncontrolled-components) handelt. Dies wird in der Dokumentation von [React Hook Form](https://react-hook-form.com/get-started#IntegratingControlledInputs) beschrieben. Controlled-Komponenten führen schnell dazu, dass es für eine Select-Komponente (hier `customer_.edit.$id.tsx`) umfangreicher werden kann:
```
{
// Map salesReps to Select options
const options: SelectOption[] = [
{
value: "",
label: "None",
},
...salesReps.map(
(salesRep) =>
({
value: salesRep.employee_id?.toString(),
label: salesRep.name,
}) as SelectOption,
),
];
// Set the Select component's value to match the current field value
const selectedValue = options.find(
(option) => option.value === (field.value?.toString() || ""),
);
return (
{
field.onChange(
value ? Number.parseInt(value || "") : null,
);
}}
/>
);
}}
/>
```
## Zwei kleine Hinweise zu unserem Beispiel
### 1. Zugriffe und Routen trennen
Im Beispielcode mixen wir Routen-Definition und Datenbankzugriff, da der Zugriff auf die Datenbank hier sehr einfach ist und die Konzepte von Remix einfacher erklärt werden können. Im Sinne einer produktionsreifen Implementierung wäre es allerdings es sinnvoll, diese Zugriffe aus den Routen herauszunehmen und in eigene Module zu kapseln, um eine Strukturierung entsprechend der Hauptaufgaben ([Seperation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)) zu erreichen.
Das macht die Routen übersichtlicher und erleichtert das Testen und ermöglicht mehr Flexibilität.
### 2. Formularmodell braucht weitere Daten
Häufig kommen in `action` und `loader` noch kleine Logiken hinzu, etwa um weitere Daten zu laden und zu speichern. Dies kommt daher, dass häufig das Formularmodell nicht 1:1 mit dem Datenbankmodell übereinstimmt und noch weitere Daten benötigt werden.
Für unseren Code überlassen wir das Refactoring den Leser:innen.
## Summary
Wir haben gesehen, dass die Erstellung von Formularen in Remix ähnlich komplex ist wie in React. Aber durch die Verwendung von `zod` und `remix-hook-form` können wir die Validierung auf der Client- und Serverseite vereinheitlichen. Wir haben also alle Zutaten, um CRUD-Funktionen in Remix zu implementieren.
*Alle Teile dieser Blogserie:*
*[Teil 1: Remix – eine Alternative für Geschäftsanwendungen](https://thecattlecrew.net/2024/09/06/remix-eine-alternative-fuer-geschaeftsanwendungen/)*
[*Teil 2: Remix – Routes und Data Loading*](https://thecattlecrew.net/2024/09/13/remix-routes-und-data-loading/)
[*Teil 3: Remix – Formulare, Validierung und Datenänderungen*](https://thecattlecrew.net/2024/09/27/remix-formulare-validierung-und-datenaenderungen/)
**Kategorien:** Development
**Schlagwörter:** Business Application, Formulare, Full Stack Framework, React, Remix, Softwarenentwicklung, Webentwicklung
---
### [Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Published:** August 23, 2024
**Author:** Dominik Kloke
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 9: Ein Fazit
Was ist nun unser Fazit? „Vielfältig“, wäre hier die kurze, knappe Antwort. Wir versuchen daher unsere Erkenntnisse so zu clustern, dass sie die wahrscheinlich häufigsten Fragen des Lesers beantworten. Sollten noch etwas offen bleiben, schickt uns eure Fragen, schreibt einen Kommentar … wir freuen uns über jedes Feedback!
*Du bist neu dabei? Hier kannst du einen Blick in die bisherigen Teile der Blogserie werfen:*
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
- [Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
- [Teil 4: Was ist eine gute SBOM – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
- [Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
- [Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
- [Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
- [Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
## Was halten wir von den Konzepten hinter der SBOM?
Die grundsätzliche Idee hat uns überzeugt. Als technikaffine Menschen lieben wir strukturierte, formal definierte und automatisch erzeug- und bearbeitbare Dateiformate. Diese lassen sich leicht in CI-Builds integrieren und weiterverarbeiten. Es lassen sich einfach entsprechende Blaupausen definieren, die dann mit wenig Aufwand in viele Projekte integriert werden können. Die Hoffnung ist, hier ein wichtiges Thema, das uns in der Praxis einen hohen Mehrwert bringt, ohne viel Aufwand umzusetzen.
Der Mehrwert für die Security in der Softwareentwicklung ist offensichtlich. Gleiches gilt für die Anwendung der Software: Nutzer:innen profitieren von der höheren Transparenz und können eigene Prozesse aufsetzen.
Herausfordernd sind das Tooling und die tatsächliche Bewertbarkeit potenzieller CVEs bei der Softwarenutzung. Über einen CVE zeitnah informiert zu sein, bedeutet noch lange nicht, diesen bewerten oder die richtigen Reaktionen initiieren zu können. Leider besitzt die Basis hierfür, also der CVE selbst,oft nicht die nötige Qualität. Die Analyse eines CVEs bleibt daher weiterhin aufwändig und erfordert ein gewisses Expertenwissen. Wir müssen damit rechnen, dass es bei einer flächigen Einführung, wie zum Beispiel über den Cyber Resilience Act, zu „Einschwingeffekten“ und „Übersprungshandlungen“ kommen wird.
Auch die Auswirkungen eines Cyber Resilience Acts auf die Open Source Community sind schwer zu bewerten. Es ist zu befürchten, dass sich eine breitere Transparenz sowie eine mögliche Haftbarkeit eher negativ auf die Bewertung des Einsatzes von Open-Source-Produkten auswirken wird. Dies macht zwar die wahren Kosten von sicherer Software sichtbarer, jedoch ohne dabei eine offensichtliche Alternative aufzuzeigen.
## Nehme ich nun CycloneDX oder SPDX?
In der Praxis und für das Ziel unserer Analyse sind beide Formate gleichwertig und gleichen sich auch bei Unterschieden immer wieder an. In der CycloneDX Welt scheint es mehr Werkzeuge zu geben, was aber nicht sofort bedeutet, dass diese auch besser sind.
Für SPDX spricht wiederum die ISO-Zertifizierung, die Unternehmen mehr Sicherheit geben kann. So setzten Microsoft und IBM scheinbar auf SPDX. Über die Nutzung von entsprechenden Client-Bibliotheken ist es allerdings auch möglich, beide Standards in einem Werkzeug zu nutzen. Am Markt beobachten wir aktuell keine offensichtliche Entscheidung für das eine oder andere Format.
Den Schluss, den wir daraus ziehen können ist, dass die Entscheidung am Ende eher über die Werkzeuge und die geplante Prozesskette geführt werden sollte. Darüber hinaus sind Konvertierungen grundsätzlich möglich. Diese sollten aber minimal gehalten und erst im finalen Prozessschritt realisiert werden.
## Gibt es das eine, beste Werkzeug?
Keines der Werkzeuge war perfekt. Alle Werkzeuge, die wir untersucht haben, wiesen an der ein oder anderen Stelle Mängel auf. An den meisten Werkzeugen wird weiterhin auch noch fleißig geschrieben, verbessert und optimiert. So zeigen Tickets, dass Werkzeuge auch noch Probleme mit der Einhaltung von Spezifikationen haben.
Ein weiterer Punkt, den wir bemängeln, ist die Dokumentation. Hier wird teilweise zu wenig erklärt, wie die Werkzeuge konkret vorgehen. Besonders aufgefallen ist uns dies bei der Auswertung von Java beziehungsweise Maven Projekten. Sind nun die \*.jars im Zielverzeichnis relevant oder die POM? Oder gar beides? Wie genau wird die Maven POM analysiert?
Aus dem gleichem Grund kritisieren wir auch die Ausgaben zur Laufzeit. Wenn während des Scans weitere SBOMs gefunden und ausgewertet werden, weil wir bei der Analyse zwischen den einzelnen Tests nicht sauber aufgeräumt haben, ist dies etwas, das aus unserer Sicht zumindest protokolliert werden sollte. Gleiches gilt für die Auflistung der konkreten Dateien, die zu einer Analyse herangezogen werden. Insbesondere bei der Auswertung von pom.xml oder während des Builds erzeugter \*.jar Dateien.
Gerne hätten wir auch mehr Schalter oder mehr strukturierte Ausgaben, um das Werkzeug besser in den CI Build zu integrieren. Speziell definierte Return Codes o. ä. wären hier hilfreich.
## Gibt es das eine große Projekt?
Viele Projekte erschienen uns klein, selbst die großen Projekte mit vielen Sternen hatten eine überschaubare Anzahl von Contributors und durchaus längere Listen von Issues. Diese müssten für eine noch bessere Bewertung genauer analysiert werden.
Unzufrieden sind wir auch mit dem monolithischen Ansatz einiger Applikationen. Aus unserer Sicht ist das Scannen zur Erzeugung der SBOM klar von der Auswertung der SBOM zu trennen. Trivy kann beispielsweise beides. Speziell im Lizenzbereich könnten wir uns vorstellen, die Gesamtfunktionalität auf mehrere, kleine Werkzeuge aufzuteilen, die für sich SBOM erstellen, anreichern, auslesen oder modifizieren. Möglicher Weise stehen dem marktwirtschaftliche Interessen entgegen aber auch das Bedürfnis, ein zentrales Werkzeug für alles zu haben.
Mögliche kommerzielle Gesamtlösungen, die man alternativ im Kontext SBOM Management evaluieren könnte, wären z. B.:
- [Anchore](https://anchore.com/) (Anchore ist auch der Hersteller von Syft und Grype)
- [Snyk.io](https://snyk.io/de/)
- [Mend.io](https://www.mend.io/)
- [Checkpoint](https://www.checkpoint.com/de/)
- [JFrog](https://jfrog.com/security-and-compliance/)
- [Codenotary](https://codenotary.com/)
- [Rezilion](https://www.rezilion.com/platform/sca-dynamic-sbom/)
- [VigilantOps](https://www.vigilant-ops.com/products/)
Diese Liste ist sicherlich nicht vollständig.
Unter dem Strich wäre der aktuelle Stand und die genannten Mängel für uns aber kein Grund, SBOMs nicht jetzt zu nutzen. Wichtig wäre es aber, bei Fehlern Tickets zu erstellen und darin die eigenen Anforderungen klar zu äußern.
## Wie gut ist das Ergebnis?
Bei der SBOM-Erstellung für Maven oder NPM-Projekte wird die Qualität maßgeblich davon beeinflusst, inwieweit das Buildsystem oder die Ergebnisse des Build korrekt ausgewertet werden. Ist dies nicht der Fall, sinkt die Qualität schnell. Beim Scannen von Docker-Containern sehen wir Unterschiede in den unterstützten Distributionen sowie bei der Erkennung von Artefakten außerhalb des Paketsystems der Distribution.
Bei der Erkennung von CVEs haben wir den Eindruck, dass die Werkzeuge bei gleicher Informationsbasis, in diesem Fall der SBOM, zu sehr ähnlichen oder gar zu gleichen Ergebnissen kommen. Hier ist aktuell scheinbar die Wahl des Werkzeugs für die SBOM-Generierung oder die verwendete Datenbank entscheidender als das Werkzeug, mit dem die CVEs gesucht wird.
Unterschiede und größere Anzahl von „False Positives“ entstehen dann, wenn die SBOM keine Versionen oder redundante Einträge mit unterschiedlicher Qualität beinhaltet.
Die Relevanz der Nutzung von CPE ist uns unklar. Wir konnten keine offensichtlichen Unterschiede in den Ergebnissen bei Verwendung oder Nicht-Verwendung sehen.
## Welches Werkzeug nehme ich dann?
Wenig überraschend können wir nicht den einen Weg skizzieren. Zu viele Faktoren spielen hinein, die wichtig sein könnten und die Wahl maßgeblich beeinflussen. Wir sehen aber folgende Abwägungskriterien:
- **Präferenz: Tools, die nah an der semantischen Quelle arbeiten** und so z. B. Informationen direkt aus dem Build-System ziehen. Dies führt tendenziell zu einer höheren Qualität – aber vermutlich auch zu der Nutzung mehrerer Werkzeuge.
- **Präferenz: Minimierung der Werkzeuganzahl.** Grundsätzlich möglich, kann abhängig von den zu unterstützenden Stacks aber zu Qualitätsverlusten führen. Wir empfehlen, hier nicht zu dogmatisch zu sein.
- **Präferenz: Standard.** Hier dominieren dann ggf. Werkzeuge, die SPDX als Format unterstützen. Auch dies kann zu Qualitätsverlusten führen. Die Relevanz eines ISO- Standards ist für uns schwer einzuschätzen und vermutlich stark abhängig vom konkreten Projekt-Kontext.
- **Präferenz: Qualität:** Man nimmt die Kombination von Werkzeugen, die zu der besten SBOM und den besten Reports führt.
- **Präferenz: Ergebnis CVEs.** Abhängig davon, ob wir den SBOM-basierenden Prozessen folgen und die entsprechenden Möglichkeiten ausreizen oder nur schnell und einfach einen CVE-Report haben wollen, kann sich die Werkzeugauswahl unterscheiden.
## Wie sehen wir den Markt?
Wir sehen, dass es historisch eine Reihe von Werkzeugen gibt, die sich funktional mit der Werkzeugpalette im Kontext SBOM überschneiden. So gibt es Tools zum Asset Management und zur Lizenzanalyse, die auch Scanner nutzen und entsprechende Reports erzeugen.
Des Weiteren sehen wir einen Open-Source-Markt, der auf Basis von CycloneDX und SPDX entsprechende Werkzeuge erstellt. Hinter Teilen dieser Werkzeuge stehen allerdings kommerzielle Firmen. Dadurch können die bekannten Risiken entstehen, wie das Verschieben von relevanter Funktionalität in eine kommerzielle Version oder eine Relizensierung des aktuell freien Produkts. Eine entsprechende Risikoabwägung sollte daher in üblicher Weise durchgeführt werden, der Umgang des Herstellers mit dem Werkzeug beobachtet werden.
Eine Alternative können Portal oder SaaS-Lösungen sein, die z. B. auf Basis von Repository Scans zahlreiche Dienstleistung, intuitive Oberflächen und auch Workflow-Unterstützung anbieten. Da wir diese Werkzeuge hier nicht analysiert haben, können wir zu den Features aber auch zu den Lizenzkosten nichts sagen. Grundsätzlich tun sich hier wie auch in anderen Bereichen zwei verschiedene Wege auf.
1. Der kleinteilige, scheinbar wirtschaftlich günstige Weg mit mehr Eigenleistung im Bereich der zugehörigen Prozesse
2. Das „All in One“-Tool, das alle Aspekte abdeckt und klare Prozesse vorgibt, dafür aber möglicher Weise mehr Kosten erzeugt.
## Wie gehe ich denn nun vor?
Insgesamt würden wir empfehlen, klein anzufangen und erst einmal pragmatisch und mit konkreten Zielen (CVEs, Automatisierung der Erstellung und Analyse) mit einer Integration für ein einzelnes Projekt oder Produkt zu beginnen. Hierfür sind die evaluierten Werkzeuge völlig ausreichend.
Ziel sollte sein, ein Gefühl für die Qualität sowie die gewünschten Prozesse zu bekommen – ohne gleich den Anspruch zu haben, die Prozesse technisch vollständig zu lösen. Ebenso würden wir bei der Tool-Auswahl pragmatisch vorgehen und nicht versuchen, alles mit einem Werkzeug zu lösen.
Wichtig: Sich hierbei detailliert mit den konkreten Inhalten der SBOM, deren Ursprung und deren gewünschten Qualität auseinandersetzen!
Speziell im Bereich Docker Images oder VM o.ä. empfehlen wir, Verantwortlichkeiten klar zu definieren: Wer erstellt die SBOM für die eigentliche Software? Wer erstellt eine SBOM für das Docker-Image? Wer prüft auf CVEs und reagiert mit welchen Maßnahmen?
Für die Lizenzauswertung wäre zu klären, ob auf eine SBOM-basierende Analyse gesetzt wird oder ob weiterhin mit einem separaten Prozess und ggf. auch Liefergegenstand gearbeitet werden soll. Speziell ist hier zu klären, inwieweit eine ggf. vorhandene klassische Low-Level-Lizenzanalyse von einer Lizenzbewertung auf Basis einer SBOM zu trennen ist.
Erst nachdem Erfahrungen – dann auch später in mehreren Projekten – gesammelt wurden, würden wir die nächsten Schritte empfehlen und überlegen, wie weiter skaliert und zentralisiert werden kann. Dies vor allem auch in Bezug auf die Professionalisierung der Werkzeugauswahl.
# Bisherige Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Wenn Titelstorys die IT-Security vor sich hertreiben – SBOMs](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
**Published:** Februar 2, 2024
**Author:** Tim Teulings
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 1: Über den nachlässigen Umgang mit bekannten Sicherheitslücken
**2017** wurde die größte Wirtschaftsauskunftei in den USA, Equifax, gehackt. Dabei wurden 143 Millionen Personendaten inklusive Sozialversicherungsnummer und teilweise Führerscheinnummer gestohlen. Darüber hinaus Kreditkartennummern von 209.000 US-Bürger:innen. Des Weiteren hatten 182.000 US-Bürger:innen Korrekturen an ihren Daten verlangt – auch die dazu nötigen Detailinformationen wurden von den Hackern entwendet. Die Plattform wurde zeitweise abgeschaltet. Vermutet wird, dass eine zum Zeitpunkt bekannte Sicherheitslücke in Apache Struts für den Einbruch genutzt wurde. Einen Fix der Sicherheitslücke gab es bereits, dieser wurde aber bei Equifax über längere Zeit nicht eingespielt.
Auch die beiden folgenden Sicherheitslücken gingen durch die Presse:
**Ende 2021:** Die Sicherheitslücke Log4Shell (CVE-2021-44228) führte zu zahlreichen Angriffen auf unterschiedlichste Systeme, darunter vieleVMWare Produkte. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) ging auf Warnstufe Rot und rief eine kritische Bedrohungslage aus. Weltweit prüften Hersteller und Betreiber, ob sie betroffen sind. Laut verschiedener Schätzungen lagen die summarischen Kosten möglicherweise im Bereich mehrerer Milliarden Dollar.
**2022:** Die kritische Zero-Day-Sicherheitslücke Spring4Shell (CVE-2022-22965) hatte ein ähnliches Gefahrenpotential. Da Spring in sehr vielen Applikation genutzt wird, findet man noch heute im Internet Statements in denen Firmen erklären, ob sie von dieser Lücke betroffen waren oder nicht.
Sicherheitsprobleme großer Anbieter oder Plattformen aber auch kleinerer Software-Komponenten, die aber in Tausenden von Software-Instanzen verwendet werden, gehen mittlerweile durch die Presse und schaffen es in die Tagesschau. Gleiches gilt für Einbrüche in IT-Systeme, die zu Datendiebstählen im sechsstelligen Bereich oder größer führen. In einer dritten, weiteren Variante brechen Hackerbanden in IT-Systeme ein und verschlüsseln Daten, um für die Freischaltcodes Geld zu erpressen.
## Die Lage wird brenzliger
Dies hat in den Vereinigten Staaten aber auch in Deutschland dazu geführt, dass IT-Systeme nach einem Vorfall über längere Zeit heruntergefahren werden mussten. Gefühlt ist aktuell in Deutschland immer mindestens eine kommunale Stadtverwaltung „down“. Zum Zeitpunkt dieses Artikels ist die „Südwestfalen-IT“ nach einem Cyberangriff Ende Oktober 2023 nur mit Basisdiensten online. Rund 170 Personen arbeiten – nach eigenen Angaben – weiterhin an der Bewältigung der Folgen.
In die Presse gelangen solche Vorfälle auch deshalb, weil sie zu merkbarem gesellschaftlichen Schaden und Beeinträchtigungen führen. Bürgerinnen und Bürger aber auch Firmen sind großflächig betroffen und müssen temporäre Einschränkung in ihrem Leben hinnehmen.
## Welche Ursachen stehen dahinter?
Was sind die Ursachen dafür, dass sich solche Vorfälle häufen und die Auswirkungen massiver werden? Eine Reihe von Punkten lassen sich hier nennen:
### 1. Fortschreitende Digitalisierung
Grundsätzlich sorgt die fortschreitende Digitalisierung dafür, dass es einfach immer mehr IT-Systeme gibt. Durch die Digitalisierung stehen viele dieser Systeme direkt oder indirekt auch im Internet und sind stärker untereinander vernetzt, damit Kunden oder konkret auch Bürger über eine Webseite oder per App den Dienst nutzen können. Die Angriffsfläche ist so sicherlich einfach erheblich größer als sie es noch vor 10 oder 20 Jahren war.
### 2. Komplexere Systeme
Gründe dafür, dass IT-Systeme komplexer werden, sind ebenfalls in der Digitalisierung zu finden (einfach „mehr machen mit Software“). Aber auch im wachsenden Anspruch an die Software bzgl. Funktionalität und Qualität. Komplexität kommt aber auch durch die stärkere Vernetzung von System und Datenquellen zustande. Für die Systemsicherheit ist der letzte Punkt, also die übergreifende Vernetzung, sicherlich ein besonders kritischer Faktor.
### 3. Kostendruck
Software in ihrer Komplexität anzugehen wie ein in der Komplexität vergleichbares „klassisches“ Planungsprojekt („Hochhaus? Flugzeugbau? Raumschiff?) ist oft nicht bezahlbar oder methodisch nicht durchführbar. Dennoch wird entsprechende Software erstellt, was Risiken mit sich bringt. Das es zu Qualitätsmängeln kommt und Risiken tendenziell eher unterschätzt werden, ist daher nicht überraschend.
### 4. Einsatz von Standards
Der Komplexitätsreduzierer „Standards“ wird nicht so stark genutzt wie in andere Branchen. Software will man, um sich abzugrenzen (die Software soll es ja explizit anders – nämlich „besser machen“, als bei der Konkurrenz).
### 5. Stetige Veränderung
Die IT ist Innovationstreiber und unterliegt einem stetigen, hohen Verbesserungs- und Änderungsprozess, der darin resultiert, dass 100% Qualität und Stabilität oft eher sekundäre Faktoren sind. Software hat oft nicht mehr die Zeit, „fertig“ zu werden.
## Sicherheit als essenzielles Qualitätsmerkmal
Lange Zeit wurde IT-Sicherheit eher als „sekundärer Faktor“ betrachtet; die IT unterlag dem Irrglauben, dass es ausreicht, entsprechende Risiken aufzunehmen, die sich managen und kontrollieren lassen. Die oben gezeigten Fälle zeigen, dass dies nicht immer gelingt.
Wenn wir wollen, dass Digitalisierung erfolgreich ist, müssen wir unsere Sichtweise auf IT-Sicherheit ändern.
Mangelnde Sicherheit im Software-Umfeld ist in den letzten Jahren unternehmenskritisch und in Teilen sogar gesellschaftskritisch geworden. Sowohl Hersteller als auch Nutzende und Beauftragende einer Software sind dabei unterschiedlich aber am Ende doch gleichermaßen betroffen.
Häufige Folgen:
- Erhebliche Datenverluste und damit Datenschutzverletzung mit entsprechenden Strafen
- Reputationsverlust bei Kunden
- Arbeit und Weiterentwicklung stehen still und müssen aufgeholt werden. Die Konsequenz sind Stress, Unzufriedenheit, Überstunden, hohe Kosten – d. h. die Bilanz eines solchn Quartals kann man schon mal vergessen.
- Ungeplante Kosten, weil im Worst Case ganze IT-Infrastrukturen neu aufgesetzt werden müssen, man sich mindestens sehr gut bezahlte Fachleute ins Haus geholt hat oder einfach ein Großteil der Belegschaft seine Arbeit über einen längeren Zeitraum nicht machen kann.
## Typische Reaktionen nach dem Bekanntwerden einer großen potentiellen Sicherheitslücke
Geht ein Sicherheitsproblem durch die Presse – und ist das eigene Unternehmen, die eigene IT ein mögliches „Opfer“ der Zustände, die wir selbst geschaffen haben – folgen darauf meist typische Handlungsmuster:
- Zunächst brechen Hektik und Panik auf Grund von mangelnder prozessualer Vorbereitung aus.
- Es folgen Fragen wie „Sind wir betroffen?“ „Benutzen wir potenziell verwundbare Komponenten?“
- Darauf folgt die Gründung einer Task Force oder ähnlicher Konstrukte, die untersuchen, ob und wo in genutzten, releasten, verkauften Applikationen oder Systemen das verwundbare Softwareartefakt verwendet wird.
- In der Regel sind die Fragen aus Punkt 2 dann nicht schnell eindeutig zu beantworten („Ja, aber …“, „Müssen wir uns genauer anschauen“), was spätestens jetzt dazu führt, dass Systeme sicherheitshalber heruntergefahren werden. Oft ist der Exploit ja trickreich und die Antwort keine einfache Ja/Nein-Frage. Eine potenzielle Mitigation kommt ggf. erst Tage später.
- Schnell steht damit die Frage im Raum, ob ein Update gemacht werden muss oder eine Mitigation zu erhoffen ist. Bei einer Fremdsoftware ist hier in der Regel spätestens Schluss. Denn hier kann weder sicher gesagt werden, ob die Komponente genutzt wurde, noch ob das System angreifbar ist. Es kann also nichts weiter getan werden, als das System auf Verdacht herunterzufahren oder den entsprechenden Dienstleister zu kontaktieren.
- Wildes Blättern im Branchen-Buch nach einem Sicherheitsexperten.
- Wenn schließlich alle Fakten auf dem Tisch liegen, ist die Frage, wie und vor allem wie schnell man in der Lage ist, die identifizierten Probleme an den unterschiedlichen Stellen zu beseitigen. Dabei hat man manches selbst in der Hand (selbstentwickelte Software), anderes hingegen nicht (COTS-Lösungen).
- Wenn man Glück hat, ist man mit den Updates in wenigen Monaten durch und es ist nichts passiert. Zweiteres wird aber leider seltener.
Das meiste davon muss nicht zwingend so passieren. Dieses fiktive Drehbuch zeigt sich aber leider immer noch viel zu oft in der Realität und offenbart grundlegende Probleme mit dem Thema Security in der IT.
Kurz: Unternehmen sind nicht gut auf solche Situationen vorbereitet, Prozesse und Vorgehen sind oft nicht klar oder zu behäbig. Die Datenbasis ist im Fall der Fälle nicht ausreichend, was zu längeren Recherchen und Analysen führen kann. Und grundsätzlich hätte man ggf. schon früher reagieren können, bevor man durch die Presse aufmerksam gemacht wird.
## Wir alle sind betroffen
Längst nicht jedes Sicherheitsproblem geht durch die Presse. Schaut man für den 12.01.2024 auf cvedetails.com steht dort:
- 201 CVEs seit gestern(!) angelegt und 642 wurden aktualisiert!
- 846 CVEs in den letzten 7 Tagen angelegt und 1755 wurden aktualisiert.
- Aktuell gibt es 7 ausgenutzte „Vulnerabilities“, 11 in den letzten 30 Tagen!
Und wer auf die Statistik der letzten 10 Jahre schaut, sieht, dass die Tendenz bei CVEs im Schnitt eher bei „schwerwiegend“ als bei „unkritisch“ liegt. Wobei ja nur die bekannten Sicherheitslücken betroffen sind. Jede Lücke davon könnte uns selbst angehen!
## Fazit
Sei es in selbstentwickelten Lösungen oder in zugekauften Systemen: Wir müssen sensibel mit dem Thema umgehen. Dazu gehört vor allem, Transparenz darüber zu schaffen, welche Abhängigkeiten der genutzten Softwarelösungen existieren.
Hier wäre es hilfreich, eine Art „Inhaltsangabe“ für Software zu haben und diese „Inhaltangaben“ an zentraler Stelle für möglichst jede erstellte oder genutzte Software zu sammeln und einfach auswertbar zu haben. So könnte man an entscheidenden Stellen im obigen Szenario schneller reagieren. Hierfür gibt es tatsächlich bereits Lösungen: Stichwort SBOMs. Mehr darüber im nächsten Teil …
## Quellen
[https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211\_log4Shell\_WarnstufeRot.html](https://www.bsi.bund.de/DE/Service-Navi/Presse/Pressemitteilungen/Presse2021/211211_log4Shell_WarnstufeRot.html)
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber-Angriff, Cyberattack, gehackt, Hackerangriff, IT Security, SBOM
---
### [Mit Software-Stückliste wirksam auf Sicherheit prüfen: SBOMs](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
**Published:** Februar 7, 2024
**Author:** Tim Teulings
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 2: Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten
Um Angriffe auf IT-Systeme, mit denen kriminelle Banden uns in Gefahr bringen, und auf die wir leider oft nur unzureichend reagieren können, darum ging es im [ersten Teil dieser Serie über die Software-Stückliste SBOMs](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/). Aber was macht uns so handlungsunfähig? Klar, Kriminelle sind schwer in den Griff zu bekommen, wohl aber unseren Umgang mit bekannten Sicherheitsproblemen! Hier kommen SBOMs ins Spiel.
Was SBOMs können, und mit welchen Grundfunktionalitäten, sie helfen, unsere IT im Griff zu behalten, darum geht es in diesem 2. Teil der Serie.
## SBOMs als Pflichtprogramm
In den Vereinigten Staaten führte die Gefährdungslage 2021 zu einer Anordnung des Präsidenten, der Executive Order 14028. Darin ist eine Auflistung zahlreicher konkreter Maßnahmen zu finden mit recht kurzfristigen Zielterminen von 30 bis 120 Tagen.
Unter anderem diese:
- Behörden werden angewiesen, Verträge zu prüfen und zu überarbeiten
- Neue Konzepte und Strategien sind aufzusetzen
- Informationen werden eingefordert
- Kommunikationsketten werden definiert
- Sicherheitsmaßnahmen wie Multi-Faktor-Authentifizierung werden grundsätzlich verpflichtend gemacht
Die Maßnahmen dieser Anordnung dienen dem Ziel, die Sicherheit im Software-Umfeld in kürzester Zeit drastisch zu verbessern. Zumindest im Kontext diverser Regierungsdienste und deren Partner, Lieferanten und Dienstleister. Mit der Executive Order 14028 wird – um zum eigentlichen Thema zu kommen – auch die Lieferung von sogenannten Software Bills of Material, kurz: SBOMs verpflichtend. Bei diesen SBOMs handelt es sich dabei genau um die Stücklisten über den Inhalt von Softwarekomponenten, die wir im ersten Teil erwähnt haben.
## Welche Informationen liefern SBOMs?
SBOMs beinhalten Informationen wie diese:
- Beschreibung der Komponente
- Verwendete (abhängige) Software-Komponenten und deren Lizenzen
- Beschreibung von Services und einzelnen Dateien
- Jeweils eindeutige Koordinaten zur eindeutigen Identifikation, wie Name und Version
- Hashes für alle Elemente
Damit dienen SBOMs als standardisiertes Austauschformat für die sicherheitsrelevanten Elemente einer Software. Mit folgenden großen Vorteilen:
1. Einfachheit: Die zentrale Sammlung von Informationen zu eigenen und Fremdprodukten in einer Datenbank wird vereinfacht
2. Transparenz: Hersteller und Nutzende erhalten entsprechende Informationen, ohne, dass die Software an sich „offen“ gelegt wird.
## Weniger Aufwand und schnellere Prozesse
Ein weiterer Vorteil ist die Vereinfachung einiger Prozesse – sowohl bei Herstellern als auch bei Nutzenden oder ggf. zwischengeschalteten Dienstleistern.
Hier drei Beispiele:
- Eine schnellen Suche nach der Verwendung eines bestimmten, vulnerablen Software-Artefakts im Bestand wird möglich. Also eine schnelle Antwort auf die Fragen „Nutzen wird das?“ und „Wo und in welcher Version nutzen wir das?“.
- Regelmäßig wird ein Scan der eigenen und fremden Software-Komponenten auf bekannte Sicherheitslücken durchgeführt. D. h. wir haben wir immer eine Antwort auf die Frage „Sind wir vulnerable?“, ohne eigene Detailanalysen anstellen zu müssen.
- Software-Komponenten werden auf Aktualität geprüft. So bekommen wir Antworten auf die Fragen “Benutzen wir die aktuelle Version?“, „Wie viele neue Versionen gibt es?“ und „Müssen wir jetzt aktualisieren?“.
Standarddaten und ein darauf aufbauendes Tooling schrauben den Aufwand, insbesondere für Softwarenutzende, erheblich herunter.
## Schutz vor selbstgemachten Sicherheitsproblemen
Damit schützen SBOMs nicht vor Sicherheitslücken – diese verschwinden dadurch ja nicht und die Software wird auch nicht automatisch besser. Wovor SBOMs uns schützen, sind selbstgemachte Sicherheitsprobleme durch Ignorieren bekannter Fixes.
So spricht der „9th Annual State of the Software Supply Chain“ von Sonartype – bekannt durch das statische Codeanalyse Werkzeug SonarQube – von im Schnitt 150 Abhängigkeiten, die ein Software-Projekt besitzt, mit in Summe pro Jahr 1500 Änderungen in den Abhängigkeiten. Ebenso haben 96 % der heruntergeladenen Software-Artefakte im Java-Umfeld bekannte Sicherheitsprobleme, obwohl bereits ein Fix existiert.
Diese unnötigen Lücken lassen sich mithilfe von SBOMs schließen.
## Software als lebendes Produkt verstehen
Die Verwendung von SBOMs ermöglicht also großen Teilen der Software-produzierenden oder -konsumierenden Gesellschaft, autonomer, schneller, dezentraler und auch aktiver auf bekannte Sicherheitslücken zu reagieren. Darüber hinaus führt es zu einem anderen Qualitätsanspruch, zu einer anderen Erwartungshaltung und zu einem anderen Verständnis von Software –nämlich als dauerhaftes, lebendes Produkt.
Damit sind Softwaresysteme nicht mehr etwas, das wie ein Möbelstück in einem Möbelhaus gekauft, aufgestellt und genutzt wird, sondern eher vergleichbar mit einem Auto, das regelmäßig überprüft und gewartet werden muss und bei dem hin und wieder schadhafte Teile ausgetauscht werden.
Auch in Deutschland gibt es mit der „Technical Guideline TR-03183, Part 2: Software Bill of Materials (SBOM)“ eine erste Einschätzung und Einordnung durch das BSI. Diese Richtlinie verweist explizit auf den aktuell noch im Entscheidungsprozess befindlichen Cyber Resilience Act der EU, der ggf. für Organisationen im öffentlichen Bereich die Erstellung und Auslieferung von SBOMs verpflichtend machen würde.
## Fazit
SBOMs sind mehr als nur der Traum einiger Technikfreaks, die gerne alles dokumentieren, in Schubladen packen und kategorisieren wollen. SBOMs geben uns schnell und automatisiert Antworten auf Fragen, die für unsere Sicherheit entscheidend sein können. Spätestens bei der nächsten Gefährdungslage werden wir heilfroh sein, dass wir sie eingesetzt haben. Doch es geht nicht nur um die großen Angriffe: Wie wir gesehen haben, helfen SBOMs bereits jetzt, hier und heute, unsere IT sicherer zu machen.
Aber wie sieht eine SBOM denn jetzt genau aus? Welche Formate gibt es? Welche Tools gibt es? Und welche davon sollten wir verwenden? Was ist möglich, wie gut funktioniert es und was geht ggf. noch nicht so gut? Und wie kann ich entsprechende Werkzeuge integrieren?
Denn oft steht und fällt mit der Wahl der Werkzeuge die Qualität des Ergebnisses. Aber auch auf die richtige Umsetzung von Prozessen und ein gesundes Maß an Pragmatismus kommt es an.
Auf diese Fragen wollen wir in den folgenden Teilen dieser Blog-Serie eingehen. Dafür haben wir uns einige Tools angeschaut und schildern unseren Eindruck … und natürlich sprechend wir die ein oder andere Empfehlung aus.
## Quellen
[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183\_node.html](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr03183/TR-03183_node.html)
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [SBOM-Formate im Vergleich](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
**Published:** März 4, 2024
**Author:** Tim Teulings
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 3: CycloneDX und SPDX
Die zunehmende Komplexität und Interkonnektivität von Softwareanwendungen führt dazu, dass es immer mehr Fremdabhängigkeiten in der Software gibt. IT-Verantwortliche stehen vor der Herausforderung, den Überblick zu behalten und die Zusammensetzung und Herkunft von Softwarekomponenten transparent und nachvollziehbar zu dokumentieren. Wie wichtig diese Dokumentation für die Sicherheit, Compliance und Effizienz des gesamten Softwareentwicklungs- und Bereitstellungsprozesses ist, haben die ersten beiden Teile dieser Reihe gezeigt.
Für alle die neu dabei sind: In dieser Blogserie wird die Bedeutung von Software Bill of Materials (SBOM) als Instrument zur Identifizierung, Verfolgung und Analyse von Softwarekomponenten diskutiert. Wir nehmen euch mit in die Praxis, stellen euch Tools und Funktionalitäten vor.
Während es in den beiden ersten Teilen der Serie um grundsätzliche Fragen rund um die Software-Stücklisten ging, haben wir für diesen dritten Teil die beiden führenden SBOM-Formate, CycloneDX und SPDX, genauer untersucht und miteinander verglichen.
Hier kannst du einen Blick in die ersten beiden Teile der Blogserie werfen:
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
Aber nun zurück zu diesem 3. Teil:
CycloneDX und SPDX bieten IT-Verantwortlichen Möglichkeiten, um Informationen über die Komponenten von Softwareanwendungen strukturiert zu erfassen und zu kommunizieren, wobei jedes Format seine eigenen Stärken und Einsatzbereiche aufweist.
Diese Untersuchung zielt darauf ab, IT-Fachleuten einen fundierten Einblick in die beiden gängigen Standards für SBOMs zu geben.
## Wie sind die SBOM-Formate CycloneDX und SPDX entstanden?
Für SBOMs gibt es zwei relevante Standards: SPDX (Software Package Data Exchange) und CycloneDX, die sich in nur wenigen Aspekten voneinander unterscheiden. Auch dies ist beiden gemeinsam: Beide Standards sind Open Source und wurden von gemeinnützigen Organisationen entwickelt:
- **SPDX** wurde 2011 von der Linux Foundation entwickelt und ist seit 2021 ein ISO-Standard (ISO/IEC 5962:2021). Ursprünglich entwickelt wurde SPDX, um in Open Source Projekten Lizenzinformationen zu verwalten. Im Laufe der Zeit wurde der Standard erweitert, um zusätzlich Information zu Sicherheitslücken und weiteren Aspekte aufzunehmen.
- **CycloneDX** ist ein Standard des OWASP (Open Web Application Security Projects), der 2017 entwickelt wurde. Sein Fokus liegt darauf, Anwendenden zu ermöglichen, Sicherheitslücken in Ihrer Software zu identifizieren, insbesondere in deren Abhängigkeiten.
## Wo liegen die Unterschiede?
SPDX und CycloneDX sind heute nahezu deckungsgleich. Beide enthalten Attribute für Metadaten, Softwareabhängigkeiten und externe Dienste oder Dateien, die eingebunden werden. Damit ist jeder Standard nahezu gleichwertig einsetzbar.
### **Abhängigkeiten**
- CycloneDX unterteilt Abhängigkeiten explizit in direkte und transitive Abhängigkeiten.
- SPDX hingegen hat ein eigenes Feld, um Relationen zwischen den verschiedenen Elementen in einer SPDX SBOM abzubilden. Zudem sieht SPDX explizit ein Feld vor, um einen Review der SBOM zu dokumentieren.
### **Fokus Compliance oder Cybersicherheit?**
Die Wahl eines Standards hängt vom Kontext der Verwendung der SBOM ab: Möchte man in erster Linie die Lizenzen einer Software im Auge behalten, bietet sich historisch SPDX an, da dies explizit dafür entwickelt wurde. CycloneDX hingegen wurde speziell für das Verwalten von Sicherheitslücken entwickelt.
Allerdings sind beide Standards mittlerweile so weit entwickelt worden, dass man sie in der Praxis für beides einsetzen kann.
## Wie steht es um die Kompatibilität?
Eine Konvertierung zwischen den beiden Standards ist möglich, beide Projekte stellen dafür Tools bereit. Allerdings muss hierbei beachtet werden, dass nicht alle Attribute der jeweiligen Standards in dem anderen abgebildet werden können. Dies wird in den Tools beider Projekte dokumentiert ([cyclonedx-cli](https://github.com/CycloneDX/cyclonedx-dotnet-library#high-level-overview-of-information-lost-during-conversion) und [cdx2spdx](https://github.com/spdx/cdx2spdx#design-and-implementation-notes))
Zu prüfen ist allerdings, mit welchem Unternehmen die SBOMs ausgetauscht werden sollen, da diese einen Standard vorgeben könnten. So arbeitet Microsoft bspw. mit SPDX und IBM mit CycloneDX.
## Beispiele für den Aufbau der SBOMs
Beispiel 1: Aufbau einer CyclonDX SBOM (Quelle: )
Beispiel 2: Aufbau einer SPDX SBOM (Quelle: )
## Summary
Gibt es also eine klare Empfehlung für einen der beiden Standards? Aus unserer Sicht: Nein. Für die Wahl des geeigneten Standards ist es – wie wir in den folgenden Artikeln zeigen werden – relevanter mit welchen Tools man arbeiten will und welchen Standard diese unterstützen. Ebenso sollte man den Standard und die Werkzeuge so wählen, dass eine Konvertierung zwischen den Standards vermieden wird.
# Wie geht es weiter?
Im nächsten Teil stellen wir uns die Frage: Was ist eine gute SBOM? Wir stellen Kriterien und das Setting für unsere Versuchsreihe vor und nehmen Tools für die Erzeugung von SBOMs unter die Lupe.
Danach geht es weiter mit Fragen wie :
- Was können die Vulnerability Scanner?
- Wie kann ich auf kompatible Lizenzen prüfen?
- Wie integriere ich SBOMs in den Software-Development-Prozess?
- Was ist beim Start in die SBOM-Welt zu beachten?
- Was ist von den Konzepten hinter SBOM zu halten?
- Summary und Tipps für den Start
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Was ist eine gute SBOM?](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
**Published:** März 20, 2024
**Author:** Dominik Kloke
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 4: Das Versuchssetting
Nach grundsätzlichen Fragen rund um die Software-Stücklisten und dem Vergleich der beiden führenden SBOM-Formate, CycloneDX und SPDX stellen wir in diesem vierten Teil unser Versuchssetting vor. Das Setting war die Basis für diverse Tests, mit denen wir in dieser Blogserie der Frage nach einer guten SBOM auf den Grund gehen wollen.
Du bist neu dabei? Hier kannst du einen Blick in die ersten drei Teile der Blogserie werfen:
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
- [Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/ "SBOM-Formate im Vergleich")
## Welche Ziele haben wir uns gesetzt?
Ziel dieser Blogserie ist es, unterschiedliche Werkzeuge für die Erstellung von SBOMs unter die Lupe zu nehmen. Dazu gehörte es, uns die Auswertung bzgl. potenzieller CVEs, Reportings von Software-Lizenzen oder die Erkennung von Lizenzverstößen näher anzuschauen. Auch wenn grundsätzlich mit einer SBOM mehr möglich ist, scheinen uns diese die essenziellen Kernprozesse zu sein.
## Welche Werkzeuge haben wir getestet?
Getestet wurden vor allem:
- (kostenlose) Open-Source-Werkzeuge
- Werkzeuge, die sich grundsätzlich in eine CI-Pipeline integrieren lassen und damit den Wunsch nach Automatisierung unterstützen
- die korrekte Aufzählung von **Software-Abhängigkeiten** eines Software-Produkts. D. h. wir hatten nicht den Anspruch, dass jedes Dateiartefakt korrekt erkannt, aufgezählt und verarbeitet wird. Ebenso bewerteten wir nicht die Erkennung von CVEs von Distributionspaketen des Betriebssystems der Docker-Images. Der Fokus lag also auf dem Erkennen von Abhängigkeiten einer Software, nicht der Umgebung, in der sie ausgeführt wird.
- Rein SBOM-basierende Prozesse. D. h. wir haben die Strecken außer Acht gelassen, in denen ein Werkzeug scannt und CVEs auswertet, ohne dabei intermediär eine SBOM zu nutzen.
- Praktikabilität der Werkzeuge. D. h. wir haben nicht die Korrektheit der SBOM validiert, sondern untersucht, wie gut Werkzeuge mit der SBOM in der Praxis arbeiten können.
## Welcher Technologie-Stack wurde untersucht?
Bei der Wahl des Technologie-Stacks haben wir uns an einen typischen Stack orientiert, den wir bei unseren Kunden immer wieder vorfinden.
- Java Maven Projekte
- Angular / NPM Projekte
- Docker Images (hier wiederum mit Fokus auf den dort installierten Software-Artefakt)
- Die Dokumentation einer Betriebssysteminstallation
## Welcher Code stand im Fokus?
Welchen Code galt es zu begutachten bzw. anhand von welchem Code wollten wir die Werkzeuge prüfen? Hier haben wir uns für Varianten der PetClinic entschieden, eines der Demo-Projekte im Java-Umfeld.
Konkret:
- Das Projekt zum Stand von Mitte Dezember (also ohne die nachfolgende Spring-Boot-Aktualisierung).
- Das Projekt ebenfalls zum Stand von Mitte Dezember.
- Folgende Docker-Images: tomcat:9, tomcat:9-alpine, tomcat:9-jdk21-corretto-al2
- Der Arbeitsrechner unter Windows 11 sowie eine WSL2-Umgebung auf Basis von Ubuntu 22.04.
## Unsere Testkriterien
Eine Empfehlung braucht klare Kriterien. Deshalb haben wir unsere Anforderungen an die Werkzeuge vorab definiert. Drei Gütekriterien wurden dabei unterschieden:
### 1. Eignung für Continuous Integration (CI)
- Die Integrationsfähigkeit in einen CI-Build ist maßgeblich. Generierung und Prüfung sollte bei Änderungen automatisch neu angestoßen werden können.
- Dies bedingt auch, dass z. B. sinnvolle Warnungen oder Fehler erzeugt werden und die Verarbeitung abgebrochen werden kann, wenn im Test ein Fehler entdeckt wird. D. h. auch die Ausgaben sollten „CI-geeignet“ sein.
- Das Werkzeug sollte möglichst wenig Installations- und Pflege-Aufwand bei der Installation auf einem Arbeitsrechner oder einem CI-Rechner erzeugen
### 2. Qualität
- Von Vulnerability Scannern erwarten wir, dass die gängige Bewertung einer Sicherheitslücke mit angegeben wird.
- Grundsätzlich erwarten wir ein Minimum an „false positive“- und „false negative“-Meldungen und natürlich eine vollständige Liste der korrekt identifizierten Vulnerabilities.
- Die Präsentation des Ergebnisses muss auch für Nicht-Techniker nachvollziehbar sein
### **3. Geschwindigkeit**
Die Ausführung sollte zügig erfolgen. Das hieß für uns: Die Ausführung sollte mit Blick auf die Gesamtausführungszeit der Build-Pipeline angemessen sein. Idealerweise liegt die Ausführung bei einigen wenigen Sekunden.
## Woran erkennen wir eine gute SBOM?
Fangen wir mit den Eigenschaften einer guten SBOM an: Zunächst sollte die SBOM grundsätzlich vollständig und korrekt sein – in Bezug auf die zu dokumentierende Komponente sowie auf die oben genannten Ziele.
Um diese Eigenschaft zu bewerten, haben wir in unseren Tests vier Punkte gecheckt:
### **1. Alle relevanten Abhängigkeiten müssen aufgezählt werden!**
- Dokumentieren wir ein Software-Projekt, sollten alle Komponenten sowie deren transitiven Abhängigkeiten vollständig aufgelistet werden.
- Dokumentieren wir einen Docker-Container sollten z. B. alle Packages der Linux Distribution sowie zusätzlich manuell installierte Software, wie ein JDK, aufgezählt werden.
- Dokumentieren wir ein Betriebssystem, gilt das gleiche für Software-Packages, Systemkonfigurationen und Systemeigenschaften.
### **2. Die Listeneinträge müssen eindeutig sein!**
Es sollten eindeutige IDs verwendet werden, um eine Komponente schnell unterscheiden zu können von
- anderen Komponenten,
- anderen Komponentenversionen
- oder gleichnamigen Komponenten anderer Hersteller.
### **3. Folgende Informationen sollten vorliegen, damit die SBOM entsprechend ihrem Zweck ausgewertet werden kann!**
- Jede Komponente ist eindeutig über Namen und Version zu identifizieren.
- Am besten werden weitere IDs wie die Common Platform Enumeration (CPE) verwendet.
- Die Quelle des Artefakts wird eindeutig genannt, z. B. mit der Download-URL.
- Angaben zu Lizenzen oder Lizensierungsmöglichkeiten der Komponente werden gemacht.
- Informationen bzgl. Nutzung oder Einbindung der Komponente, wie Typ („Library“) oder Einbindungsart im Kontext des Builds („scope: test“) stehen zur Verfügung.
### **4. Die Korrektheit der Angaben muss überprüfbar sein!**
Über Hashes kann geprüft werden, ob die vormals dokumentierte Komponente und die Komponente, die uns aktuell vorliegt, inhaltlich identisch sind – die Komponente also nicht modifiziert wurde.
## Summary
Mit den Kriterien, die wir oben genannt haben, setzten wir bei unserer Analyse den Fokus schwerpunktmäßig auf diese Aspekte:
- praktische Nutzbarkeit bzgl. der Identifikation von CVEs bzgl. Lizenzen,
- Korrektheit der Angaben,
- typische Software-Stacks
- und abhängige Software-Artefakte.
# Wie geht es weiter?
Für den nächsten Teil dieser Blogserie haben wir Tools für die Erzeugung von SBOMs getestet. Die Ergebnisse rangieren von „empfehlenswert“ bis „durchgefallen“.
Danach geht es weiter mit Fragen wie :
- Was können die Vulnerability Scanner?
- Wie steht es um die Kompatibilität von Lizenzen?
- Wie integriere ich SBOMs in den Software-Development-Prozess?
- Was ist beim Start in die SBOM-Welt zu beachten?
- Was ist von den Konzepten hinter SBOM zu halten?
- Summary und Tipps für den Start
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Mit welchen Werkzeugen werden gute SBOMs gemacht?](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
**Published:** März 27, 2024
**Author:** Dominik Kloke
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 5: Tools für die SBOM-Erzeugung im Vergleich
Am Beginn unserer Reise durch die SBOM-Welt steht die Erzeugung der SBOMs. Aber welches Werkzeug hat die Nase vorn, wenn es um die Erzeugung präziser und aussagekräftiger SBOMs geht?
Um das herauszufinden, sind wir in diesem Teil der Blogserie in die Welt der SBOM-Erstellungstools eingetaucht. Wir haben getestet, welches Werkzeug unsere Anforderungen am besten erfüllt. Wir wollten herausfinden, welche Tools wirklich gute SBOMs herstellen – und damit uns allen (hoffentlich!) die Auswahl des optimalen Werkzeugs erleichtern.
Du bist neu dabei? Hier kannst du einen Blick in die ersten vier Teile der Blogserie werfen:
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
- [Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
- [Teil 4: Was ist eine gute SBOM – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
Bei unseren Tests der Erstellungstool für SBOMs ging es um eine Reihe von Fragen: Welche Werkzeuge eignen sich, um gute SBOMs zu erzeugen? Gibt es das eine Werkzeug für alles oder sind es eher mehrere Werkzeuge, die sich je nach Situation am besten eignen?
## Welche Werkzeuge eignen sich?
Hier zunächst die Liste der Werkzeuge für die Erzeugung von SBOMs, die wir nach intensiverer Recherche gefunden und entsprechend geprüft haben:
**Werkzeug****URL****Einsatzbereich**cdxgenMaven, NPM, Docker, OScyclonedx-maven-pluginMavenbuild-info-goMaven, NPMSyftJava, NPM, Dockersbom-toolJava, NPM, Dockerspdx-sbom-generatorMaven, NPMspdx-maven-pluginMavenscancode-toolkitMaven, NPMcyclonedx/cyclonedx-npmNPMTrivyMaven, NPM, DockerDiese Werkzeuge haben wir für unsere Tests entweder auf Linux oder Windows installiert und eine SBOM mittels eines entsprechenden Aufruf auf Basis der Dokumentation erzeugt. Die daraus resultierenden SBOMs wurden dann gemäß unserer Testkriterien miteinander verglichen. Die Bewertungen fielen sehr unterschiedlich aus:
### Prädikat: Durchgefallen!
Drei Tools sind in unseren Tests durchgefallen. Sie erfüllten die Kriterien nicht oder unzureichend und sind daher aus unserer Sicht aktuell nicht zweckdienlich:
#### **spdx-sbom-generator**
- Die erzeugte SBOM beinhaltete keine Lizenzinformationen für die Maven Artefakte.
- Vereinzelt fehlten Versionsnummern, was vermuten lässt, dass die durch Maven dokumentierten Abhängigkeiten nicht sauber ausgewertet werden.
- Das Projekt an sich scheint aktuell nicht im aktiven Zustand zu sein: Es gab keine signifikanten Commits in der letzten Zeit dafür eine Reihe offener Pull Requests.
- Vereinzelt hatten wir Abstürze.
#### **scancode-toolkit:**
- Das Maven Projekt wird nicht im Ansatz vollständig abgebildet (es wurde nur eine Dependency gefunden).
- Die SBOM beinhaltet auch hier keine Lizenzen für die Maven Artefakte.
- Die Ausführung dauerte sehr viel länger als bei anderen Tools (ohne entsprechendem „mehr“ an Qualität).
- Das Projekt hat eine große Anzahl offener Tickets. Bei dem NPM-Projekt haben wir die Ausführung nach langer Zeit abgebrochen. Hier scheint scantool überfordert.
#### **build-info-go:**
- Der SBOM fehlen aktuell die Lizenzinformationen der einzelnen Maven Artefakte.
- Sie beinhaltet gefühlt nur das Notwendigste.
- Für Angular scheint das Werkzeug Dependencies und auch Vulnerabilities zu finden, die SBOM ist aber faktisch leer (siehe z. B. ).
Diese Tools erfüllten in unterschiedlicher Güte unsere Kriterien von „Empfehlenswert!“ über „Ganz in Ordnung“ bis „Naja …“:
### Prädikat: Empfehlenswert!
- **cdxgen** für Maven und NPM-basierende Projekte. (wobei für Maven Projekte intern das cyclonedx-maven-plugin nutzt, in der Nachverarbeitung aber in Details patzt). Hier hat auch der Detailierungsgrad der Informationen beeindruckt, wenn man cdxgen eine SBOM für eine Betriebssystem (Linux, Windows) erstellen lässt. Für Docker-Images liefert syft bei mehr Distribution die gewünschte Qualität.
- Eben das besagte **cyclonedx-maven-plugin** für Maven Projekte.
- **cyclonedx-npm** für NPM-Projekte.
- **syft** für Docker-Images (hier klar bevorzugt vor cdxgen, welches nicht alle getesteten Distributionen unterstützt) aber grundsätzlich auch mit leichten Abstrichen für Maven -Projekte. Hier ist wichtig zu verstehen, dass die Auswertung der Maven POM von syft „naiv“ ist, syft in der Praxis die SBOM aber nahezu gleichwertig durch die Auswertung der gebauten Jars erstellen kann. Hier ist die SBOM genau zu analysieren und ggf. die Cataloger entsprechend zu konfigurieren. Im NPM-Kontext werden die Dev-Dependencies mit gelistet, was uns nicht sinnvoll erscheint.
- **Trivy** für Docker-Images mit leichten Abstrichen gegenüber syft (manuelle installierte JDKs nicht erkannt). Ebenso nutzbar für Maven Projekte und NPM-Projekte, wobei bei NPM-Projekten oft die Lizenzangaben fehlten.
- **spdx-maven-plugin**: Im direkten Vergleich sehen wir das cyclonedx-maven-plugin als besser an und nehmen es auch als aktiveres Projekt war.
### Prädikat: Ganz In Ordnung
Wesentlicher formaler Mangel bei **cylonedx-npm**, **cyclonedx-maven-plugin** sowie **cdxgen** ist die unzureichende Unterstützung für CPEs. Das scheint aber bei der Auswertung bzgl. CVEs aktuell nicht entscheidend zu sein.
### Prädikat: Naja …
Das **sbom-tool** konnte uns in keiner der Projektarten wirklich überzeugen. Es liefert in allen Varianten eher rudimentäre Informationen.
## Summary
Wir waren von der doch stark unterschiedlichen Qualität zugegebenermaßen überrascht, sind doch die Werkzeuge entweder schon länger verfügbar oder haben eine kommerzielle Firma im Rücken.
Unser Gefühl ist, dass viele Werkzeuge ihren Schwerpunkt auf die Analyse von Inhalten von Docker-Images setzen, was aus unserer Sicht nicht falsch ist (den die dort manuell installierte Software oder in den Paketen der genutzten Linux-Distribution können ja auch Sicherlücken haben).
Allerdings sieht man auch klar, dass bzgl. der abhängigen Software-Komponenten die Werkzeuge, die die Build-Informationen sauber auswerten, zu vollständigen und auch qualitativ besseren Informationen kommen,
Daher wird man aktuell entweder in der Praxis mit mehreren Werkzeugen arbeiten müssen, oder eben bei einem Tool ggf. qualitative Abstriche in Kauf nehmen müssen.
# Wie geht es weiter?
Im nächsten Teil werdet ihr sehen, inwiefern die Qualität des Vulnerability Scannings direkt mit der Qualität der SBOM zu tun hat.
Danach geht es weiter mit Fragen wie diesen:
- Wie steht es um die Kompatibilität von Lizenzen?
- Wie integriere ich SBOMs in den Software-Development-Prozess?
- Was ist beim Start in die SBOM-Welt zu beachten?
- Was ist von den Konzepten hinter SBOM zu halten?
- Summary und Tipps für den Start
# Bisherige Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Vulnerability Scanner für SBOMs unter der Lupe](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
**Published:** Mai 10, 2024
**Author:** Dominik Kloke
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 6: Was können die Vulnerability Scanner Trivy und Grype?
SBOMs helfen, Sicherheitslücken zu erkennen, die sich im eigenen Code befinden. Dafür werden Vulnarability Scanner gebraucht. Im Folgenden möchten wir zwei Tools vorstellen, die bei diesem Problem helfen können:
**Name****Mögliche Scan-Ziele** **Verwendete Datenbanken** Trivyfs, image, sbom[Trivy-db](https://github.com/aquasecurity/trivy-db/tree/main) siehe [Sources](https://aquasecurity.github.io/trivy/v0.19.2/vulnerability/detection/data-source/)Grypefs, image, sbom*Du bist neu dabei? Hier kannst du einen Blick in die ersten fünf Teile der Blogserie werfen:*
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
- [Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
- [Teil 4: Was ist eine gute SBOM – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
- [Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
## Was können die Scanner von SBOM-Dateien?
Scanner wie Trivy und Grype unterstützen das Scannen verschiedenster Ziele. Hierbei ist allerdings zu beachten, dass die Scanner – je nach Ziel des Scans – verschiedene Ansätze haben. Im Falle einer SBOM versucht der Scanner nicht selbst, weitere Softwareabhängigkeiten zu ermitteln, sondern gibt nur für die in der SBOM eingetragenen Abhängigkeiten CVEs aus.
## Vergleich der Vulnerability Scanner Trivy und Grype
In diesem Abschnitt werden die Ergebnisse der Tools *Trivy* und *Grype* gegenübergestellt. Dabei wurden beide Scanner jeweils gegen die mit verschiedenen Werkzeugen generierten SBOMs sowie gegen das zugrunde liegende Java Maven-Projekt ausgeführt.
### Trivy
**Ziel des Scans** **Anzahl gefundener CVEs** **Anmerkungen**Dateisystem Low: 0
Medium: 6
High: 7
Critical: 0
Gesamt: 13 Cdxgen SBOM
spring-pestclinic-rest Low: 0
Medium: 7
High: 8
Critical: 2
Gesamt: 17 Zusätzlich werden CVEs gefunden in:
[org.springframework.security:spring-security-config ]()
[org.springframework.boot:spring-boot-actuator-autoconfigure](spring-boot-actuator-autoconfigure) Maven Cyclonedx Plugin
SBOM spring-pestclinic-restLow: 0
Medium: 7
High: 8
Critical: 2
Gesamt: 17 Identisch zu cdxgen-java-bom.jsonSyft SBOM spring-pestclinic-rest
Low: 1
Medium: 9
High: 22
Critical: 13
Gesamt: 45Findet zusätzliche CVEs in:
[com.fasterxml.jackson.core:jackson-databind](http://com.fasterxml.jackson.core:jackson-databind)
[mysql:mysql-connector-java](mysql-connector-java)
[org.postgresql:postgresql](postgresql)
[org.hsqldb:hsqldb ](hsqldb)SBOM Tool SBOM spring-pestclinic-rest
Low: 0
Medium: 6
High: 8
Critical: 0
Gesamt: 14Zusätzliche CVE in:
[net.minidev:json-smart](json-smart)Trivy SBOM spring-pestclinic-rest
*Projekt pom.xml:*
Low: 0
Medium: 7
High: 8
Critical: 2
Gesamt: 1
*/target/generated/pom.xml:*
Low: 0
Medium: 8
High: 10
Critical: 0
Gesamt: 18 Scannt die pom.xml im Projekt und die generierte in
[/target/generated-sources/openapi/pom.xml](/target/generated-sources/openapi/pom.xml) ### Grype
**Ziel des Scans** **Anzahl gefundener CVEs** **Anmerkungen**Dateisystem Low: 1
Medium: 15
High: 32
Critical: 23
Gesamt: 71
Grype erkennt hier nicht immer die tatsächlich installierte Version einer Bibliothek und findet so *False Positives*. Cdxgen SBOM
spring-pestclinic-rest Low: 0
Medium: 7
High: 8
Critical: 2
Gesamt: 17 Identisches Ergebnis wie Trivy Maven Cyclonedx Plugin
SBOM spring-pestclinic-restLow: 0
Medium: 7
High: 8
Critical: 2
Gesamt: 17 Identisches Ergebnis wie Trivy Syft SBOM spring-pestclinic-rest
Low: 1
Medium: 9
High: 22
Critical: 13
Gesamt: 45Identisches Ergebnis wie Trivy SBOM Tool SBOM spring-pestclinic-rest
Low: 0
Medium: 6
High: 8
Critical: 0
Gesamt: 14
Identisches Ergebnis wie Trivy Trivy SBOM spring-pestclinic-rest
Low: 0
Medium: 13
High: 12
Critical: 2
Gesamt: 27 Reportet mehr CVEs als Trivy für die im Projekt verwendeten Bibliotheken## Fazit
Vergleicht man die Resultate des SBOM Scannings, sieht man direkt, dass sich beide Tools nicht viel nehmen. Dies liegt nach unserem Verständnis daran, dass die zugrundeliegenden CVE-Datenbanken nahezu identisch sind. Entscheidender scheint vielmehr zu sein, mit welchem Tool die SBOM erstellt wurde.
- Beim Scannen der SBOMs von syft fällt auf, dass mehr CVEs gefunden werden. Dies liegt aber daran, dass syft für einige Softwareabhängigkeiten keine Version findet und in der Folge CVEs gefunden werden, von denen du nicht betroffen bist.
- Eine Besonderheit von Trivy sei an dieser Stelle hervorgehoben: Trivy kann selbst SBOMs in den gängigen Standards generieren. Deshalb könnte das Tool eine „Rundumlösung“ darstellen.
- Grype findet beim Scannen des Filesystems mehr CVEs als Trivy. Das liegt daran, dass es mit seinem „Katalog“ mehr Softwarekomponenten erkennt. Allerdings findet er nicht immer ihre Version. Das heißt das Ergebnis ist garantiert nicht frei von „falsch positiven“ Treffern.
- Beide Tools haben eine JSON-Ausgabe, um einen Custom Report mit anderen Tools zu erstellen.
### Bewertung und Empfehlung
Möchte man sich möglichst umfassend und korrekt absichern, macht die Kombination von Syft und Grype Sinn. Beide Tools sind Open Source und kommen von der Firma Anchore. Im Gegensatz zu Trivy kannst du mit Syft mehr Einfluss darauf nehmen, wie Abhängigkeiten im Projekt erkannt werden. Hierfür stellt Anchore verschiedene Mechanismen (sogenannte„Kataloge“) zur Verfügung.
Möchtest du nur ein Tool einsetzten, empfehlen wir Trivy. Denn Trivy kann beide Aufgaben erledigen und stellt damit wie oben erwähnt eine Rundum-Lösung dar. Allerdings solltest du immer auch die Nachteile beachten, die bei der Generierung der SBOM mit Trivy entstehen.
# Wie geht es weiter?
Im nächsten Teil werfen wir einen Blick auf die Möglichkeit, mithilfe von SBOMs die Kompatibilität von Lizenzen auszuwerten.
Danach geht es weiter mit Fragen wie diesen:
- Wie integriere ich SBOMs in den Software-Development-Prozess?
- Was ist beim Start in die SBOM-Welt zu beachten?
- Was ist von den Konzepten hinter SBOM zu halten?
- Summary und Tipps für den Start
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Mit SBOMs die Lizenzierung überprüfen](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
**Published:** Juni 25, 2024
**Author:** Dominik Kloke
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 7: Lizenzchecks
Grundsätzlich beinhaltet die SBOM auch Lizenzinformationen. Das gilt sowohl für die durch die SBOM beschriebene Komponente selbst, aber insbesondere auch für deren zahlreiche Abhängigkeiten.
Speziell bei der Verwendung von Open-Source-Abhängigkeiten mit ihren verschiedensten, möglichen Lizenzen liegt es so nahe, die SBOM auch als Basis für ein Reporting oder einen Check auf gewollte, kompatible (Whitelist) oder im Unternehmen verbotene Lizenzen (Blacklist) zu nutzen und damit ein ggf. bereits bestehendes Tooling zur Lizenzprüfung abzulösen.
Welche Werkzeuge für Lizenzchecks oder Reportings aus unserer Sicht geeignet sind und was diese genau können, haben wir uns daher für diesen Beitrag genauer angesehen.
*Du bist neu dabei? Hier kannst du einen Blick in die ersten sechs Teile der Blogserie werfen:*
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
- [Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
- [Teil 4: Was ist eine gute SBOM – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
- [Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
- [Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
## Kriterien für die Lizenzauswertung
Für ein Reporting sind aus unserer Sicht drei Kriterien relevant:
1. **Vollständigkeit:** Hier fokussieren wir uns erst einmal auf die Softwarekomponenten und ignorieren OS, Packages o. ä. Wir verzichten an dieser Stelle auch auf Hashes und Fingerprints oder den Abgleich gegen eine zentrale Datenbank.
2. **Sprache:** Der Report sollte auch in deutscher Sprache bereitgestellt werden können. In der Praxis ist dies am einfachsten zu realisieren, wenn das Template für einen Report selbst erstellt werden kann.
3. **Konfigurierbarkeit:**
– Die angezeigten Attribute, die Sortierung sowie die allgemeine Darstellung sollten konfigurierbar sein.
– Bei kombinierten Java- und Angular-Projekten ist es relevant anzuzeigen, ob es sich um ein Maven- oder NPM-Artefakt handelt.
– Auch die GroupId hilft, das Artefakt besser einzuordnen.
– Ggf. kann zusätzlich eine Beschreibung des Artefakts in der SBOM angezeigt werden.
– Schließlich wäre es gut, wenn man auf die Sortierung Einfluss nehmen könnte.
– Ist der Report nicht konfigurierbar, sollte dieser dennoch sinnvoll auswertbar und auch für Nicht-Techniker verständlich sein.
Für eine Prüfung der Lizenzen gegen eine Whitelist oder Blacklist ergeben sich weitere Anforderungen:
- Grundsätzlich muss es möglich sein, entsprechende White- oder Blacklists überhaupt definieren zu können. Am besten wäre es, wenn diese Definition zentral erfolgt. So läßt sich vermeiden, dass in einzelnen Projekten mit einer älteren oder anderen Version der Liste gearbeitet wird.
- Hierzu gehört auch die Möglichkeit, organisatorische Prozesse auf diese Liste(n) abzubilden, um beispielsweise Änderungen protokollieren zu können. Hierfür reicht im einfachsten Fall die Verwendung von Textdateien in einem Git-Repository aus.
- Wichtig ist auch die Möglichkeit, manuell nicht-SPDX-konforme Lizenzangaben nach der Prüfung korrigieren zu können.
- Ebenso ist es hilfreich, wenn man zu einer Lizenz-Expression (z. B. „MIT OR BSD-2-Clause“) definieren kann, welche der möglichen Lizenzoptionen gewählt wurde. Diese Auswahl kann – muss aber nicht – auch automatisch geschehen.
## Welche SBOM-Werkzeuge haben wir untersucht?
Zu den genannten Kriterien haben wir uns diese Werkzeuge angeschaut:
**Werkzeug****URL****Einsatzbereich**sbomgr (SBOM Grep) [https://github.com/interlynk-io/sbomgr ](https://github.com/interlynk-io/sbomgr)Report jqassistant-cyclonedx-plugin [https://github.com/jqassistant-plugin/jqassistant-cyclonedx-plugin ](https://github.com/jqassistant-plugin/jqassistant-cyclonedx-plugin)Report/Check sbom-utility[https://github.com/CycloneDX/sbom-utility ](https://github.com/CycloneDX/sbom-utility)Report/Checkjq[https://jqlang.github.io/jq/ ](https://jqlang.github.io/jq/)Report mdBOM[https://haro87.github.io/mdbom/0.3.0/ ](https://haro87.github.io/mdbom/0.3.0/)Report sbom2docReport LicenseComplianceTool[https://github.com/medavis-gmbh/LicenseComplianceTool ](https://github.com/medavis-gmbh/LicenseComplianceTool)Report license-checker-cyclonedx-maven-plugin[https://github.com/remisbaima/license-checker-cyclonedx-maven-plugin ](https://github.com/remisbaima/license-checker-cyclonedx-maven-plugin)CheckDependency Track [https://dependencytrack.org/ ](https://dependencytrack.org/)Report/Check**Hinweis:** Grundsätzlich existieren weitere Werkzeuge zum Reporting oder zur Prüfung der verwendeten Lizenz. Beispiele hierfür sind u. a. Sonarqube Licensecheck, der Gradle-License-Report, der NPM License Checker, die Möglichkeiten der Maven Site oder auch das License Maven Plugin. Diese Werkzeuge wurden hier nicht betrachtet, weil sie nicht auf Basis einer SBOM arbeiten.
## Kein Werkzeug überzeugte zu hundert Prozent
Um es vorwegzunehmen: Keines der betrachteten Werkzeuge konnte uns völlig überzeugen. Im Bereich Reporting sind sbomgr, sbom-utility sowie sbom2doc Werkzeuge, die man sich anschauen kann, aber auch aus unserer Sicht aktuell offensichtliche Mängel haben. Alternativ sind manuelle Auswertungen auf Basis jq möglich. Im Bereich der Prüfung ist der Einsatz von Dependency Track vermutlich noch am sinnvollsten – mit entsprechend großem Setup-Aufwand.
Wer bereits jQAssistant nutzt, ist mit der Integration vertraut und kann hiermit bzgl. Reporting als auch Prüfung grundsätzlich viele der Anforderungen schnell und elegant umsetzen. Wer jQAssistant noch nicht nutzt, muss sich hierzu allerdings erst in jQAssistant einarbeiten (was es aus Sicht der Autoren grundsätzlich wert ist) und sollte es auch für seinen eigentlichen Zweck („Software Analytics“ und „Living Documentation“) nutzen wollen.
## Die Ergebnisse
Hier die detaillierteren Erkenntnisse zu den einzelnen Werkzeugen:
- **sbomgr:** Grundsätzlich ist ein Text-Report erzeugbar. Die Form des Reports erlaubt allerdings keine einfache, automatisierte Auswertung. Es gibt kein Templating.
- **jqassistant-cyclonedx-plugin:** Siehe oben. Prozesse müssen auf Basis von jQAssistant realisiert werden. Reporting würde man auf Basis Asciidoc realisieren. Ein Abgleich gegen eine Whitelist oder Blacklist ist grundsätzlich möglich. Eine automatische Auswertung von Lizenz-Expressions würde die Möglichkeiten von jQAssistant vermutlich überschreiten.
- **sbom-utility:** Ein Report kann erzeugt werden. Uns gefällt aber die Darstellung nicht (Auswertbarkeit). Es gibt kein Templating. Bzgl. einer Überprüfung können Lizenzen kategorisiert werden. Die Kategorisierung ist schön, hat aber den entscheidenden Nachteil, dass sbom-utility keine entsprechenden Return-Codes erzeugt oder die Verarbeitung abbricht. Für einen Check müsste daher der Report noch selbst manuell ausgewertet werden.
- **jq:** Wir waren mit etwas Aufwand in der Lage, mittels jq eine neue JSON-Datei auf Basis einer CycloneDX SBOM mit den für einen Report relevanten Rohdaten zu erzeugen. Ein weiterführendes Reporting oder Überprüfung müsste dann auf Basis dieser neuen Datei mit eigenen Mitteln erzeugt werden.
- **mdBOM:** Hier ist grundsätzlich ein Templating möglich, allerdings wird die SBOM „von Hand“ nach nur einer kleinen Untermenge von Attributen geparsed. Wir haben das Tool daher nicht weiter betrachtet.
- **sbom2doc:** Hier sind die Reports grundsätzlich ansehnlich, aber in keiner Weise beeinflussbar. Für unsere Zwecke wären es aber notwendig, sie inhaltlich anzupassen. Das PDF-Ergebnis scheint fehlerhaft.
- **License Compliance Tool:** Grundsätzlich scheint das Tool gut zu sein, es ist allerdings für einen anderen Zweck (Aggregation von Lizenztexten) erstellt worden. Ein Tailoring für unsere Zwecke scheint nicht so einfach möglich zu sein.
- **license-checker-cyclonedx-maven-plugin:** Grundsätzlich interessant. Leider scheint dieses Tool aber nicht mehr weiterentwickelt zu werden. Auch ist es sehr auf Maven zugeschnitten, so dass sich in der Praxis schnell integrative Probleme ergeben.
- **Dependency Track:** Unterstützt grundsätzlich viele unsere Anforderungen (Reporting-Sichten sowie die Möglichkeit Policies für Lizenzen zu definieren) und auch vieles mehr – ist aber in dem Sinne keine Lösung für eine einfache Integration im CI Build und kommt mit dem entsprechenden Setup-Kosten daher.
## Fazit und Empfehlung
Im Summe sehen wir sinnvolle und pragmatische und vermutlich auch völlig ausreichende Ansätze in den einzelnen Werkzeugen. Wie schon erwähnt, fehlt uns das *eine* Werkzeug, das *alles* in entsprechender Qualität kann. Es sein denn, wir bauen auf jQAssistant oder Dependency Track auf, die aber entsprechende Einarbeitungs- und Setup-Kosten mit sich bringen.
### Pragmatisch & einfach
Allen, die hohe Kosten und Aufwand vermeiden wollen, empfehlen wir einfache, pragmatische Ansätze, um z. B. mittels jq Input für ein Reportingwerkzeug oder für einen einfachen automatisierten Abgleich zu erzeugen.
### Herausfordernd & mehr Möglichkeiten
Wer die Herausforderung annimmt, wagt sich für eine automatische Bearbeitung evtl. an License-Expressions. Hiermit muss in der Praxis ein pragmatischer Umgang gefunden werden.
### Blick in die Zukunft
Wir vermuten, dass der aktuelle, ernüchternde Status im Bereich Lizenzreporting und -check etwas damit zu tun hat, dass es für die Lizenzprüfung bereits Werkzeuge gibt, die zwar nicht auf der SBOM arbeiten, dafür aber bereits länger existieren und daher schon – mit ausreichender Zufriedenheit – entsprechend verbreitet sind.
Hier wäre im Einzelfall zu entscheiden, ob wir mit einem potenziellen Delta zwischen dieser Prüfung und den Informationen in einer SBOM leben können oder längerfristig doch auf die SBOM umschwenken, die ja zukünftig ein Auslieferungsgegenstand sein könnte.
Besteht die Möglichkeit, schnell zu einer leichtgewichtigen und akzeptablen Lösung zu kommen, kann der Schwenk frühzeitig durchgeführt werden. Ansonsten empfehlen wir, abzuwarten und das Werkzeugangebot weiter zu beobachten!
# Wie geht es weiter?
Im nächsten Teil geht es um die Frage, wie wir SBOMs in den Software-Development-Prozess eingliedern können.
Danach geht es weiter mit Fragen wie diesen:
- Was ist beim Start in die SBOM-Welt zu beachten?
- Was ist von den Konzepten hinter SBOM zu halten?
- Summary und Tipps für den Start
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Was machen SBOMs mit der Softwareentwicklung?](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
**Published:** Juli 23, 2024
**Author:** Dominik Kloke
**Content:**
# SBOMs, die Software-Stückliste für mehr IT-Sicherheit – Teil 8: SBOMs im Softwareentwicklungsprozess
Wie könnten in der SBOM-Welt mögliche Software-Entwicklungsprozesse aussehen? Wo würde ich welches Werkzeug verwenden? Was würde dies für meine CI-Pipeline bedeuten? Und wie wirkt sich das Ganze jeweils z. B. auf Rollen aus wie
- Software-Produzierende,
- Software-Betreibende,
- Software-Nutzende,
- Software-Verkaufende
- oder Beauftragende des Softwareprodukts
*Du bist neu dabei? Hier kannst du einen Blick in die ersten sieben Teile der Blogserie werfen:*
- [Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
- [Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
- [Teil 3: SBOM-Formate im Vergleich – CycloneDX versus SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
- [Teil 4: Was ist eine gute SBOM – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
- [Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
- [Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
- [Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
## SBOM-Prozesse für **Software-Produzierende**
Hier gehen wir von der Prämisse aus, dass Software-Produzierende bei der Softwareentwicklung grundsätzlich eine CI-Pipeline “Build” durchlaufen, die immer dann ausgeführt wird, wenn sich etwas am Softwarestand ändert. Typische Elemente einer solchen Pipeline sind
- der eigentliche **Build**,
- die Ausführung von **Tests**,
- eine Reihe weiterer **Prüfungen** wie z. B. eine statische Code-Analyse.
- Die Pipeline endet in der Regel mit dem **Erzeugen eines Deployment-Artefakts**
- und der **Installation auf einer Testumgebung**.
## Variante 1
In der SBOM-Welt würden nun weitere Schritte hinzukommen:
Das Ergebnis dieses zusätzlichen Schritte wäre
- entweder ein Abbruch der Pipeline, wenn es zu Fehlern kommt (z. B. bei neuen CVEs oder problematischen Lizenzen)
- oder im positiven Fall hätten wir neben dem eigentlichen Produkt nun zusätzlich die SBOM als Build-Ergebnis. In der Regel werden diese Ergebnisse in einem lokalen Repository des Unternehmens gespeichert.
- Zusätzlich könnte an dieser Stelle die SBOM z. B. auch in ein zentrales System wie *Dependency Track* eingespielt werden, um so eine projekt- und versionsübergreifende Abfrage und Auswertung zu ermöglichen.
Als Werkzeuge kommen diejenigen in Frage, die in der Lage sind, SBOMs auf Basis der vorliegenden Software-Artefakte zu erstellen (siehe [Teil 5](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)).
## Pipeline „Release“
In einer weiteren Pipeline „Release“ folgen weitere mögliche Schritte. Diese Pipeline wird aufgerufen, sobald es eine offizielle neue Version gibt. Das kommt bei Continuous-Delivery-Ansätzen durchaus häufig vor und kann im Anschluss an die Build Pipeline erfolgen:
Wie die Abbildung zeigt, werden hier die SBOMs mehrerer Teilprodukte in eine SBOM zusammengeführt. Diese SBOM wird mit der Software paketiert und für die Nutzer der Software bereitgestellt. Hier wäre es u. U. angebracht, die Prüfungen auf CVEs aus dem „Build“ noch einmal durchzuführen. Damit ließe sich ggf. im letzten Moment noch ein Release verhindern. Für das Zusammenführen von SBOM gibt es Werkzeuge wie *cyclonedx-cli* oder *sbommerge*.
## Prüfen auf CVEs
Ein dritter Prozess ist das regelmäßige Prüfen bestehender, relevanter Stände des Produkts auf neue CVEs. Relevante Stände sind dabei z. B. der aktuelle Entwicklungsstand sowie alle veröffentlichen und noch supporteten Releases.
In diesem Prozess wird erneut auf die SBOMs zugegriffen. Diese werden daraufhin auf der Grundlage einer oder mehrerer Vulnerability-Datenbanken ausgewertet. Im Falle neu entdeckter Vulnerabilities, können diese bzgl. ihrer Kritikalität auf Basis z. B. der CVSS-Scores bewertet werden.
Im Anschluss kommt es zu einem Alerting, dem eine zeitnahe manuelle Detailanalyse folgen muss. Der Zugriff auf den eigentlichen Quelltext ist hierbei nicht mehr notwendig. An dieser Stelle haben wir einen CI-basierenden Ansatz skizziert. Grundsätzlich wäre aber auch ein Vorgehen auf Basis z. B. von Dependency Track denkbar, dass obige Schritte selbstständig intern außerhalb eienr CI-Pipeline ausführt. Dies ist auch die Stunde von [Vulnerability Scannern wie Grype oder Trivy](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/).
## SBOM-Prozesse für weitere Rollen
Wie sehen die Prozesse mit integrierter SBOM-Erzeugung für die anderen Rollen aus? Grundsätzlich kann man sagen: Immer sehr ähnlich. Deshalb beschränken wir uns hier auf eine kurze Zusammenfassung:
### Prozess 1: SBOM entgegennehmen und speichern
Die von den Software-Produzierenden gelieferte SBOM ist entgegenzunehmen und mit den SBOMs der anderen Softwareprodukte zentral zu speichern. Relevant an dieser Stelle ist, dass die SBOMs gepflegt werden. So sollten SBOMs zu alten Softwareständen, die nicht mehr eingesetzt werden, zum Beispiel gelöscht werden.
### Prozess 2: Regelmäßige Prüfung auf CVEs
In einem zweiten Schritt werden diese SBOMs regelmäßig auf neue CVEs geprüft. Das Vorgehen ist hier analog wie beim Software-Produzenten:
### Schritte nach dem Alerting
Nach dem Alerting sehen die Prozessschritte für jede Rolle etwas anders aus:
- **Software-Betreibende** würden im Rahmen der Analyse unabhängig vom Hersteller ggf. nach einer möglichen Mitigation recherchieren, um so das Risiko zu minimieren und die definierten Service-Level zu halten.
- **Software-Nutzende** würden vermutlich auf den Hersteller zugehen.
- **Personen, die Software verkaufen**, würden ihre Kunden entsprechend informieren,
- während diejenigen, die die **Umsetzung beauftragen,** sich eng mit den Software-Produzierenden abstimmen und den Fokus mehr auf das resultierende Projekt- und Risko-Management setzen.
## Fazit
Beim Einsatz von SBOMs beobachten wir im Gesamtprozess vor allem drei Vorteile:
1. Keine Rolle muss auf andere Rollen warten.
2. Die einzelnen Schritte sind transparent, sodass alle Beteiligten die Risiken sehr gut abschätzen können.
3. Die Zeit bis zur maßgeblichen Reaktion kann sich erheblich reduzieren.
# Wie geht es weiter?
Im nächsten Teil verraten wir euch Tipps und Tricks für den Start in die SBOM-Welt.
Danach erwarten euch noch zwei abschließende Teile:
- Was ist von den Konzepten hinter SBOM zu halten?
- Zusammenfassung der Reihe
# Alle Teile ansehen:
[Teil 1: Wenn Titelstorys die IT-Security vor sich hertreiben – Über den nachlässigen Umgang mit bekannten Sicherheitslücken](https://thecattlecrew.net/2024/02/02/wenn-titelstorys-die-it-security-vor-sich-hertreiben/)
[Teil 2: Mit Softwarelieferscheinen effizient auf Sicherheit prüfen – Wie Sie mit SBOMs Ihre Softwarekomponenten im Blick behalten](https://thecattlecrew.net/2024/02/07/mit-software-lieferscheinen-effizient-auf-sicherheit-pruefen/)
[Teil 3: SBOM-Formate im Vergleich – CycloneDX und SPDX](https://thecattlecrew.net/2024/03/04/sbom-formate-im-vergleich/)
[Teil 4: Was ist eine gute SBOM? – Das Versuchssetting](https://thecattlecrew.net/2024/03/20/was-ist-eine-gute-sbom/)
[Teil 5: Mit welchen Werkzeugen werden gute SBOMs gemacht? – Tools für die SBOM-Erzeugung im Vergleich](https://thecattlecrew.net/2024/03/27/mit-welchen-werkzeugen-werden-gute-sboms-gemacht/)
[Teil 6: Vulnerability Scanner für SBOMs unter der Lupe – Was können die Vulnerability Scanner Trivy und Grype?](https://thecattlecrew.net/2024/05/10/vulnerability-scanner-fuer-sboms-unter-der-lupe/)
[Teil 7: Mit SBOMs die Lizenzierung überprüfen – Lizenzchecks](https://thecattlecrew.net/2024/06/25/mit-sboms-die-lizenzierung-ueberpruefen/)
[Teil 8: Was machen SBOMs mit der Softwareentwicklung? – SBOMs im Softwareentwicklungsprozess](https://thecattlecrew.net/2024/07/23/was-machen-sboms-mit-der-softwareentwicklung/)
[Teil 9: Halten SBOMs, was sie versprechen?](https://thecattlecrew.net/2024/08/23/halten-sboms-was-sie-versprechen/)
**Kategorien:** IT-Security, Tools & Methoden
**Schlagwörter:** Cyber Resilience, IT Security, SBOM
---
### [Das Analytics Yin und Yang](https://thecattlecrew.net/2024/07/15/das-analytics-yin-und-yang/)
**Published:** Juli 15, 2024
**Author:** Sebastian Pospiech
**Excerpt:** Über das Zusammenspielen von Fachbereichen und Entwicklungsteams im Analytcs Umfeld erklärt am chinesischen Yin und Yang.
**Content:**
In Organisationen sind wir es gewohnt, mit Strukturen und Prozessen zu arbeiten. Egal ob hierarchisch oder flach, es gibt klare Verantwortlichkeiten mit Abgrenzungen, Schnittstellen und Übergabepunkten. Wir malen Prozessdiagramme mit Rollen, die ihre Aufgaben nacheinander oder nebeneinander zu erledigen haben. Als Übergabemedien fungieren in der Regel Daten. Das können einzelne Events sein, Informationen über ein Ergebnis oder ganze Dokumente, die einen bestimmten Status erreichen.
So fand ich mich bei der Vorbereitung von Janine Ellners und meiner Vortragsreihe „DDC Meets Change“ wieder, als ich solche Diagramme erstellte. Weitere [Informationen](https://thecattlecrew.net/2020/03/25/auf-dem-weg-zum-datengetriebenen-unternehmen-teil-1/) zu Datadriven Company findet ihr hier im [Cattle Crew Blog](https://thecattlecrew.net/2020/03/25/auf-dem-weg-zum-datengetriebenen-unternehmen-teil-1/) oder in einem [Beitrag im BI Spektrum](https://www.opitz-consulting.com/kompetenz/ein-tool-allein-macht-noch-nicht-data-driven) . Für die Ausgangssituation gelang mir das gewohnt leicht. Die Fachseite stellt einen Anforderungs-CR, eine User-Story, erstellt vom Product Owner geht daraus hervor und wird an die Entwickler übergeben. Am Ende des Sprints kommt ein Produktinkrement dabei heraus. Das geht zurück an die Fachabteilung, die dann übernehmen soll. Einfach, sequenziell und das Sinnbild des agilen Stille-Post Analytics-Kreislaufs. Die Fachseiten dürfen dann mal gucken, was für eine Kennzahl entstanden ist und wie man diese nutzt.
# Hürden und wie man sie überwindet
Um genau die Hürden, die damit verbunden sind aufzulösen, hat Janine mit ihren Kollegen im Kundenprojekt ein Vorgehen erarbeitet, das mehr als Miteinander gestaltet ist: Im besten Fall wird nicht nur eine User-Story unter dem Türschlitz hindurch ins Refinement Meeting geschoben. Sondern der Anforderer kommt gleich mit dazu (durch die geöffnete Türe, wenn möglich). Product Owner, Entwickler und Anforderer sitzen an einem Tisch, konzipieren, priorisieren, schätzen gemeinsam. Während der Entwicklung unterstützt man sich bei Rückfragen. Nach der Entwicklung von Datenhaltung, Datenaufbereitung, Kennzahlen und Dimensionen geht es gemeinsam an die Auswertung. Egal ob klassischer Report, Dashboard oder erste Ad-hoc Analysen. Im Pairing zwischen Entwicklern und Fachseite soll gemeinsam das erste Outcome produziert, die ersten Analysen erstellt und die ersten Erkenntnisse interpretiert werden. Der Entwickler wird zum Coach für das, was er gebaut hat. Zum „You build it, you run it“, was man DevOps Teams gerne andichtet, kommt ein „We built it, we celebrate it” zwischen Entwickler und Fachseite dazu. Die Inhalte entstehen gemeinsam.
Der Versuch, das mit unseren gängigen Prozessdiagrammen darzustellen, misslang mir völlig. Ein „normales“ Prozessdiagramm brachte die Message kaum rüber. Ich habe herumgeschoben, weitere Beziehungspfeile eingezeichnet und am Ende war ein urhässliches Prozess-Ei geboren, maximal unleserlich und unverständlich. Aus Jugendschutzgründen habe ich es irreversibel entfernt und kann es an dieser Stelle leider nicht zeigen. Nach weiteren versuchen und vernichtendem Feedback der KollegInnen folgte ich einer Eingebung und malte ein Yin-Yang Symbol in den Farben, die in unserem Vortrag Entwickler und Fachseite repräsentierten, um das Miteinander dieser oft gegensätzlich anmutenden Rollen darzustellen. Der klassische Punkt auf der jeweils anderen Seite gefiel mir sofort, denn er impliziert etwas ganz wichtiges, damit oben beschriebene Arbeitssymbiose gelingen kann: Das Gegenseitige lernen und sich annähern. Die Empathie für die andere Seite.
# Beide Seiten im Detail
Ein Fachbereich, der nicht nur Self-Service können, sondern auch Refinements beiwohnen soll, braucht zumindest ein rudimentäres Verständnis dafür, wie Kennzahlen und Dimensionen funktionieren, wie man Dinge über Zeitbezüge auffächern kann und welche Rolle Granularitäten in semantischen Modellen bedeuten. Er braucht aber auch ein Stück Verständnis für Aufwände, die aus technischen Schulden oder Datenschutzanforderungen entstehen und nicht immer direkten Mehrwert bieten.
Ein Entwickler sollte sich auf der anderen Seite davon lösen, ein „null“-Value nur als technisch zu behandelndem Vorkommnis zu werten, sondern die Bedeutung interpretieren und im besten Fall übersetzen: Haben wir keine Informationen über den Kündigungsgrund, weil der Kunde ihn nicht angeben wollte, oder wurde der Kunde gar nicht erst gefragt? Wie können wir zu einer schlüssigen fachlichen Aussage kommen? Steckt mehr dahinter als nur „Die Daten sind halt nicht da?“. Es ist wichtig zu verstehen, für wen entwickelt wird. Für einen versierten Nutzer, der sich viele Freiheiten wünscht und gerne selbst filtert? Oder für einen Nutzer, der möglichst schnell und einfach eine Kennzahl hinzuziehen möchte, in der alle Storni und uninteressanten Status bereits gefiltert sind? Ein Geldautomat wird für ein breites Publikum designt und kommt schließlich ohne Linux-Konsole als Frontend daher, selbst wenn man damit weniger Entwicklungskosten hätte und evtl. flexibler in der Bedienung wäre. Das leuchtet ein. Software wurde spätestens mit dem Siegeszug von Smartphones immer intuitiver wo es nötig war und es gibt heute für jede Zielgruppe oder Persona ein passendes Human-Computer-Interaction Design auf den Endgeräten. Die Zielgruppe und deren Fertigkeiten wird bei jeder neuen App und Software mitgedacht. Wieso tut man dies nicht auch bei den Daten?
# Was kann man aus Yin und Yang lernen?
Zurück zum Yin-Yang: Jeder bleibt auf seinem Gebiet Experte, versteht aber die andere Seite. Nur gemeinsam kann ein gutes Ergebnis entstehen. Ohne die andere Seite geht es nicht. So weit funktioniert die Analogie gut. In Vorbereitung auf diesen Artikel habe ich das getan, was alle guten Informatiker tun: Sie googlen. “Yin-Yang”. Dabei finde ich heraus, das Yin-Yang Symbol aus der chinesischen Philosophie heißt genau genommen Taijitu oder Taji, „das Äußerste“, und soll so eine Art Weltformel für die Funktionsweise unseres Universums sein. Keine Angst, so größenwahnsinnig bin ich (noch) nicht. Dennoch, je mehr ich mich damit beschäftige, desto mehr gefällt mir das Symbol als Metapher für unsere neue Analytics-Arbeitsweise:
Das Yin bezeichnet den Nordhang eines Berges, das Yang die Südseite. Die beiden Seiten sind notwendigerweise untrennbar miteinander verbunden. Sie machen den Anschein, Gegensätze zu sein (die eine schattig und kühl, die andere sonnig und heiß), aber stehen im Einklang zueinander. Ohne Analytics-Anforderung braucht es keine Entwicklung. Ohne Entwicklung kann man sich die Anforderungen sparen. Es gibt eine gemeinsame Bergspitze. Will man auf den Analytics-Zenit, so gelingt das nur gemeinsam. Als Betrachter von außen muss man viele Meilen machen, um herumzulaufen und beide Seiten zu sehen und zu verstehen. Jede Seite hat individuelle Eigenarten und Bedürfnisse, ist anders, obwohl es der gleiche Berg mit dem gleichen Gipfel ist. Wohnt man auf einer Seite und kommt nie herum, versteht man die andere Seite nicht, kann die Temperatur- und Lichtunterschiede nicht nachfühlen, den anderen Blickwinkel auf die Spitze nicht begreifen.
Im Unternehmen können Change-Begleiter dabei helfen „herumzulaufen“, zu verstehen und zu transportieren. Sie können ermutigen, einen Austausch anregen und moderieren. Es braucht diese mutigen auf beiden Seiten, die starten, sich herum trauen und versuchen das erste Dashboard gemeinsam zu bauen, vielleicht nicht direkt das schwerste. Beide Seiten müssen sich trauen die dummen Fragen zu stellen und die (vermeintlich) einfachen Dinge zu erklären. Für Entwickler ist die Rolle als Coach häufig eine neue Kompetenz, die nur durch Machen gelernt wird. Für Fachseiten ist das Dashboard bauen, selbst in einer datengestützt arbeitenden Organisation oft nur selten durchgeführte Praxis.
Eine weitere Interpretation für das Yin-Yang liefert das chinesische „Buch der Wandlungen“, nach welchem die beiden Seiten immer im wechselseitigen Wandel stehen. Auf Bewegung folgt Ruhe, auf ein Hoch ein Tief usw. Kommt euch das bekannt vor? Die agile, iterative Entwicklungsweise passt wunderbar auf diese Metapher. Erst ein POC (Proof of Concept), dann die Entscheidung. Nachfolgend das MVP (Minimal Viable Product) und damit die ersten dauerhaften Mehrwerte. Dann vielleicht ein MLP (Minimal Loveable Product) und daraus resultierend gesteigerte „Gier“ im Unternehmen nach den neuen Zahlen, die wieder zu Folgeanforderungen führen.
Das Analytics-Yin-Yang bietet eine überraschend einfache Darstellung für den sehr stark verwobenen Austausch, der zwischen Fachseite und Entwicklungsseite nötig ist. Im Gegensatz zu klassischer Software-Entwicklung, wo Abläufe, Bedienung und Funktionalität im Fokus stehen, spielt das Business-Know-How eine deutlich zentralere Rolle in der Data & Analytics-Entwicklung, da das Verständnis und die Interpretation von Kennzahlen eben nicht nur schwarz oder weiß ist, sondern ganz viel dazwischen und im Zweifel auch alles, je nach Blickwinkel und Anforderung. Dennoch, in der klassischen Software-Entwicklung wird das Endanwenderbedürfnis bereits seit vielen Jahren enorm stark beachtet. Damit die Analytics einen Schritt nach vorne macht braucht es hier beidseitig eine Annäherung. Das ist eine Herausforderung und eine Chance.
Das Analytics-Yin-Yang wird auch in Zukunft bei meinen Workshops und Vorträgen zu finden sein und ist vielleicht so eine Art Prozessdiagramm, für alle, die keine Prozessdiagramme mögen. Denn es geht nicht um das du und ihr, sondern um das wir. Vielleicht erreicht dieser Artikel ein paar gleichgesinnte, die ihren DDC-Bestrebungen ein Symbol geben möchten. In dem Fall, bitte bedienen. 🙂
**Kategorien:** Analytics & Insights, Development, Tools & Methoden
**Schlagwörter:** Analytics
---
### [Laufzeitvalidierung mit Zod](https://thecattlecrew.net/2024/07/01/laufzeitvalidierung-mit-zod/)
**Published:** Juli 1, 2024
**Author:** Waldemar Lehner
**Content:**
In diesem Blogartikel schauen wir uns die TypeScript-Bibliothek „zod“ an. Dabei gehe ich genauer auf die Einschränkungen von TypeScripts Typen-System zur Laufzeit ein und zeige euch, wie zod diese Probleme löst.
# Das Problem mit TypeScript
TypeScript baut ein Typen-System um die Web-Programmiersprache JavaScript auf. Mit diesem Typen-System kann ein konkretes Interface für Objekte und Funktionen definiert werden. Wenn ich zum Beispiel versuche, einer Funktion, die eine Zahl erwartet, einen String mitzugeben, dann wirft TypeScripts Compiler `tsc` beim Konvertieren einen Fehler – vorausgesetzt TypeScript ist sich sicher , dass dort ein String übergeben wurde.
Wichtig ist dabei, dass diese Überprüfungen nur zur Compile-Zeit passieren, also während der Entwicklung. Nachdem `tsc` die TypeScript-Datei nach JavaScript konvertiert hat, gehen alle Typen-Informationen verloren. JavaScript hat kein Konzept von Typen. Dementsprechend wird auch das Program zur Laufzeit, anders als bei Sprachen wie Java oder C#, keinen Fehler auswerfen, wenn beispielsweise statt einer Zahl ein String übergeben wird.
Solange wir unsere TypeScript-Anwendung nicht mit `any`s bestücken, sollte das bei *statischen Daten* keine Probleme mit sich bringen; wenn in eine Variable beispielsweise eine Zahl geschrieben wird, dürfen wir davon ausgehen, dass die Variable zur Laufzeit auch eine Zahl beinhaltet.
Bei *dynamischen Daten* sieht das allerdings anders aus. Also bei allem, dessen Struktur nicht zur Compile-Zeit garantiert ist. Erwarten wir beispielsweise von einer API eine JSON mit einer bestimmten Struktur, hilft uns das Typen-System von TypeScript bei der Validierung nicht weiter. Denn, wie schon oben erwähnt, ist das Typen-System nur während der Entwicklung verfügbar.
Hier ein kleines Beispiel eines Aufrufs mit `fetch`.
```
interface Body {
name: string;
id: number;
}
const result: Body = await fetch('...').then((e) => e.json());
// ^^^^- hier wird der Body explizit definiert
// ob hier wirklich ein Body zurückgegeben wird wissen
// wir erst zur Laufzeit und müssen es auch zur Laufzeit
// überprüfen
console.log(result.name);
// ^^^^ Dadurch, dass oben result als Body gesetzt ist
// geht TS davon aus, dass Result ein Body ist. Würde hier etwas anderes
// als id oder name stehen, würde es zu einem Compile-Fehler kommen.
```
Nachdem `tsc` diese Eingabe nach JavaScript konvertiert, gehen die Typen-Informationen verloren:
```
const result = await fetch('...').then((e) => e.json());
console.log(result.name);
```
Ob `fetch` hier ein JSON-Objekt mit der korrekten Struktur zurückgibt erfahren wir nur, indem wir zur Laufzeit den Inhalt überprüfen, beispielsweise über eine Funktion wie:
```
function isBody(body: unknown): body is Body {
if (typeof body !== 'object' || body === null) {
return false;
}
if ('name' in body) {
if (typeof body.name !== 'string') {
return false;
}
} else {
return false;
}
if ('id' in body) {
if (typeof body.id !== 'number') {
return false;
}
} else {
return false;
}
return true;
}
```
# Wie Zod helfen kann
Statt solche Validierungs-Funktionen „von Hand“ zu schreiben, kann Zod verwendet werden. Zod ist eine Bibliothek, mit der wir mittels TypeScript-Objekten ein Schema definieren können. Gegen dieses Schema können dann Objekte validiert werden. Die oben gezeigte Funktion lässt sich beispielsweise mit Zod wie gefolgt ausdrücken:
```
import { z } from 'zod';
export const BodyZod = z.object({
name: z.string(),
id: z.number(),
});
```
Das erstellte Schema kann dann importiert und gegen ein unbekanntes Objekt angewandt werden:
```
const responseUnchecked: unknown = await fetch('...').then((e) => e.json());
try {
const response = BodyZod.parse(responseUnchecked);
console.log('validated', response);
} catch (err) {
console.error('failed validation', err);
}
```
Bei der Validierung mit der `.parse()`-Methode gibt Zod automatisch aus dem Schema abgeleitete Typen ab. Wir erhalten mit Zod somit eine umfassende Typen-Überprüfung: Sowohl zur Laufzeit als auch zur Compile-Zeit!
Beispielsweise wirft `tsc` für folgenden Code-Block einen Fehler aus:
```
const response = BodyZod.parse(responseUnchecked);
response.test = 42; // ! Fehler
// Property 'test' does not exist on type '{ name: string; id: number; }'
```
Wir können die Typen-Definitionen auch direkt aus dem Schema extrahieren:
```
type Body = z.infer;
// identisch zu
type Body2 = {
name: string;
id: number;
};
```
Neben den Typen können auch weitere Beschränkungen definiert werden:
So kann ein Validator, der ein Enum oder eine ganze, positive Zahl, die nicht größer als 42 ist, wie folgt definiert werden:
```
const ExampleZod = z
.enum(['value1', 'value2'])
.or(z.number().int().positive().max(42));
type Example = z.infer; // = number | "value1" | "value2"
```
Ein weiteres Beispiel wäre ein Validator mit zwei Strings, die eine E-Mail und optional einen Regex-konformen String definieren:
```
const Example2Zod = z.object({
email: z.string().email(),
alphaNumeric: z
.string()
.regex(/[a-zA-Z0-9]*/)
.optional(),
});
```
Eine Auflistung aller Typen und Beschränkungen findest du auf dieser [Dokuseite.](https://zod.dev/)
# Fazit
Zod bietet eine intuitive Möglichkeit, einen Zustand, den wir zur Compile-Zeit erwarten und der zur Laufzeit tatsächlich aufgetreten ist, zu synchronisieren.
Dies ist wichtig für Anwendungen, die Nutzereingaben oder externe Quellen, beispielsweise über fetch oder Angulars HttpClient, verwenden. Denn hier hilft uns das Typen-System von TypeScript nur während der Entwicklung weiter, während es zur Laufzeit keine Typenüberprüfung gibt.
Zusätzlich können mit Zod auch Beschränkungen definiert werden, die über TypeScripts Typensystem hinausgehen.
# Dran bleiben!
Im [zweiten Teil dieser kleinen Blog-Serie](https://thecattlecrew.net/2024/07/08/validieren-mit-zod-zwischen-frontend-und-backend/ "Validieren mit Zod: zwischen Frontend und Backend") möchte ich dir Zod an einem konkreten Beispiel zeigen. Dafür sehen wir uns die Validierungsschnittstelle zwischen einem Quarkus-Backend und einem Angular-Frontend genauer an. Schau also gerne wieder rein …
**Kategorien:** Development, Tools & Methoden
**Schlagwörter:** rest, TypeScript, Zod
---
### [Validieren mit Zod: zwischen Frontend und Backend](https://thecattlecrew.net/2024/07/08/validieren-mit-zod-zwischen-frontend-und-backend/)
**Published:** Juli 8, 2024
**Author:** Waldemar Lehner
**Content:**
In meinem [vorigen Blogeintrag „Laufzeitvalidierung mit Zod“](https://thecattlecrew.net/2024/07/01/laufzeitvalidierung-mit-zod/ "Laufzeitvalidierung mit Zod") habe ich dir Zod vorgestellt, eine Bibliothek zur Laufzeitvalidierung im TypeScript-Ökosystem. In diesem zweiten Teil dieser Blogserie zeige ich in an einem konkreten Anwendungsbeispiel, wie du Zod verwenden kannst. Und zwar geht es um die effektive Absicherung der Kommunikation zwischen Front- und Backend.
# Worum geht es?
Für Fullstack-Anwendungen ist es im Business-Kontext üblich, ein REST-Backend mit Spring Boot oder Quarkus zu implementieren und an eine Single-Page-Application zu verknüpfen. Die SPA kann zum Beispiel mit Angular implementiert sein. Dies hat zur Folge, dass das Frontend über die REST-Schnittstelle mit dem Backend kommuniziert und so JSON-Daten sendet und empfängt.
Nun könntest du im Frontend die Zod-Schemas „manuell“ definieren. Für Backends, die nur sehr selten aktualisiert werden, ist dies eine valide Lösung. Doch für Anwendungen, welche aktiv entwickelt werden und viele Releases haben, ist diese Herangehensweise fehleranfällig.
Wie wäre es, wenn wir ein Zod Schema automatisch aus dem Backend ableiten könnten?
# Von Java POJOs zum Zod Schema
Es gibt keine direkte Lösung, um von einer Java Klassendefinitionen ein Zod Schema abzuleiten. Es gibt jedoch einen indirekten Weg zu Lösung: Über ein Plugin, mit dem wir ein JSON Schemas im Java Kontext generieren können. Dies kann mit einer Bibliothek verknüpft werden, mit welcher ein Zod Schemas aus einem JSON Schema im TypeScript-Kontext generieren werden kann. Denn diese beiden Dinge sind vorhanden.
## Exkurs: JSON Schema
Das JSON Schema ist eine Spezifikation mit der wir die erwartete Struktur einer JSON (oder YAML)-Datei definieren. Das Schema wird als JSON definiert.
Das JSON Schema, das `{"name": "Waldemar", "id": 1234}` validiert, könnte beispielsweise wie folgt aussehen:
```
{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"name": {
"type": "string"
"minLength": 1
},
"id": {
"type": "int",
"minimum": 0
}
},
"required": [
"name",
"id"
]
}
```
Das JSON Schema hat somit eine ähnliche Aufgabe wie eine OpenAPI Spec. Wobei sich das JSON Schema auf ein JSON-Objekt beschränkt, während die OpenAPI Spec den Vertrag für eine ganze API abbildet.
# Von Java POJOs zum JSON Schema
Mithilfe eines Maven-Plugins (`jsonschema-maven-plugin` aus der `com.github.victools` Gruppe) werden zum `generate`-Step Definitionen für alle DTOs JSON-Schema generiert.
Für das Beispiel wurden folgende Abhängigkeiten eingebunden:
```
com.github.victools
jsonschema-generator
4.31.1
com.github.victools
jsonschema-module-jackson
4.31.1
com.github.victools
jsonschema-module-jakarta-validation
4.31.1
```
Die zwei letzten Abhängigkeiten sorgen dafür, dass Informationen aus den Annotationen von Jackson und Jakarta auch im JSON Schema abgebildet werden.
Folgende Java-Klasse
```
import com.fasterxml.jackson.annotation.JsonClassDescription;
import jakarta.validation.constraints.DecimalMin;
import jakarta.validation.constraints.NotNull;
@JsonClassDescription("A very helpful description!")
public class SumResponseDTO {
@NotNull
@DecimalMin("00.00")
private final double totalProfit;
// ...
}
```
wird somit beispielsweise in folgendes Schema umgewandelt:
```
{
"type" : "object",
"properties" : {
"totalProfit" : {
"type" : "number",
"minimum" : 0.00
},
// ...
},
"required" : [ "totalProfit" ],
"additionalProperties" : false,
"description" : "A very helpful description!",
}
```
Die genaue Konfiguration findet sich im Git Repo in der [pom.xml.](https://github.com/opitzconsulting/BLUE-745-Laufzeitvalidierung-im-Frontend-mit-zod/blob/0a0744f2cb2a34b270de4890f18a8d60525de507/zod-example-backend/pom.xml#L113-L155)
[Eine Anleitung auf Baeldung.com](https://www.baeldung.com/java-json-schema-create-automatically) geht hier nochmal genauer auf die einzelnen Konfigurationsmöglichkeiten ein. Unser Beispiel basiert ebenfalls auf dieser Anleitung.
*Kleine Anmerkung:* Der Weg von Java POJO zu JSON Schema wäre auch anders herum möglich, alsovon einem JSON Schema zu Java DTO Stubs. Dies ist bei der „API First“-Herangehensweise üblich.
# Von JSON Schema zum Zod Schema
Für diesen Schritt wurden die `json-schema-to-zod`– und `json-refs`-Bibliotheken verwendet. `json-schema-to-zod` konsumiert das JSON Schema und gibt einen String zurück, der das Zod Schema abbildet und in eine Datei geschrieben werden kann. `json-refs` wird hierbei verwendet, um Referenzen innerhalb des JSON Schemas aufzulösen.
```
// Tupel-Array mit dem Namen und Zod Schema
const zodifiedData = await Promise.all(
jsonFiles.map(async (filePath) => [
basename(filePath).replace('.json', ''),
jsonSchemaToZod(
await resolveRefs(JSON.parse(readFileSync(filePath, 'utf8')))
),
])
);
// Dateieinhalt wird zusammengeschrieben. z aus dem zod
// Modul wird importiert.
const moduleText = [
"import {z} from 'zod';",
...zodifiedData.map(
([name, content]) => `
export const ${name}Zod = ${content};
export type ${name} = z.infer;
`
),
].join('\n');
```
Der Inhalt wird mithilfe eines Build-Skriptes in eine TypeScript-Datei geschrieben.
Das Frontend kann dann die Schemas einfach importieren.
```
import { WeatherDataResponseDTOZod } from '../../generated/backendTypes';
// ...
const result = await fetch('...')
.then((e) => e.json())
.then((e) => WeatherDataResponseDTOZod.parse(e))
.catch((err) => console.log(err));
```
# Verhalten bei Updates
Wird das Interface des Backends angepasst, werden die JSON Schema-Dateien beim nächsten Build neu generiert.
So lange das Build-Skript nicht getriggert wurde, wird das Frontend für die geänderten Endpunkte Fehler werfen, weil die Antwort nicht dem erwarteten Schema entspricht. Wurde das Build-Skript durchlaufen, und dadurch die Zod Schemas angepasst, hören die Fehler wegen dem unerwarteten Schema auf.
Ggf. kommt es durch die Anpassung zu Fehlern beim Kompilieren durch `tsc`. Dadurch wird das neue aktualisierte Schema auch automatisch auf die generierten TypeScript-Typen abgebildet. Die Entwicklungsumgebung hilft uns bei neuen Änderungen mit Autovervollständigungen.
# Fazit
Zod, sowie das darum liegende Ökosystem an anbindenden Plugins, kann verwendet werden um automatisch TypeScript-Typen und Laufzeit-Validatoren aus Java Klassendefinitionen abzuleiten. Dadurch ist es möglich, REST-APIs automatisch zu typisieren und somit mit wenig Mehraufwand viel mehr Sicherheit und Sauberkeit in die Codebase zu bringen.
Richtig angewendet kann dadurch der zur Compile-Zeit erwartete Zustand und der zur Laufzeit entstandene Zustand „synchronisiert“ werden. Dadurch können wir nach dem Aufruf des Validators davon ausgehen, das der Typ, den TypeScript uns Vorschlägt, auch tatsächlich zur Laufzeit eingetreten ist.
**Kategorien:** Development, Tools & Methoden
**Schlagwörter:** Java, json, TypeScript, Zod
---
### [Microfrontends für Angular und React](https://thecattlecrew.net/2024/06/14/microfrontends-fuer-angular-und-react/)
**Published:** Juni 14, 2024
**Author:** Waldemar Lehner
**Content:**
Während sich im Backend eine fachliche Trennung von Monolithen in unterschiedliche Module (Modulithen) oder gar Microservices etabliert hat, ist die Frontend-Welt noch immer stark monolithisch geprägt. In diesem Artikel will ich dir zwei Ansätze zeigen, um mehr Flexibilität in deine Frontend-Architektur zu bringen: Module Federation und Web Components.
# Monolithen in der Frontend-Welt
In der Angular- und React-Welt ist es üblich, Frontends als Single-Page-Applications aufzubauen. Dabei wird ein inhaltlich leeres HTML-Dokument mithilfe von JavaScript, das im Browser läuft, mit Inhalt befüllt (Client-seitiges Rendering). Außerdem werden alle Komponenten der Webseite in ein großes Bundle transpiliert. Wir haben es also mit einem Monolithen zu tun.
Das HTML-Dokument referenziert einen Einstiegspunkt, von dem aus das Framework und die benötigten Komponenten importiert werden. Wie bei monolithischen Backends hat dies einerseits den Vorteil einer Single Source-of-Truth, und somit auch den Vorteil eines zentralen Release-Prozesses. Andererseits gibt es den Nachteil, dass die ganze Anwendung an einer zentralen Stelle definiert wird. Bei größeren Frontends wären die verschiedenen Teams also stark aneinander stark gekoppelt.
Zwar ist es möglich, Komponenten in Bibliotheken auszulagern, die von der Anwendung importiert werden. Auch können die einzelnen Komponenten durch ein Refactoring besser voneinander getrennt und entkoppelt werden; der Build wird dadurch dennoch nicht dezentralisiert. Dies ist für kleine Frontends in Ordnung. Bei größeren, von mehreren Teams entwickelten Frontends führt dies – wie im Backend – jedoch schnell zu Konflikten.
Der grobe Aufbau eines monolithischen Frontends: Ein HTML-Dokument importiert einen Entry-Point, der die Anwendung mit Inhalt befüllt. Dafür werden vom Entry-Point aus weitere JavaScript-Module aufgerufen.
## Microfrontends? Was genau darf man sich darunter vorstellen?
In der Backend-Welt gibt es das Konzept der Microservices. Das heißt, Funktionalitäten werden in kleine Backend-Services aufgeteilt, die sich auf eine bestimmte Funktionalität beschränken. Diese Backend-Services können untereinander zum Beispiel mittels REST oder gRPC kommunizieren, können aber unabhängig voneinander entwickelt und deployt werden.
Der Microservices-Ansatz ermöglicht dem Team eine höhere Autonomität. Wird der Ansatz richtig umgesetzt, können Teams selbständig arbeiten und deployen, ohne sich gegenseitig in die Quere zu kommen. Es stellt sich die Frage, wie dies in der Frontend-Welt umgesetzt werden kann.
Eine Idee dafür nennt sich Microfrontends. Allerdings kann die Realisierung dieser Idee sehr unterschiedlich aussehen. Der Browser als feste Ablaufumgebung setzt hier klare Grenzen, die sich an Web-Standards wie JavaScript, HTTP oder Web-APIs orientieren müssen.
Wir schauen uns im Folgenden zwei Optionen näher an:
- Module Federation
- Web Components
Basis für die Umsetzung ist die Modulauflösung in JavaScript.
### Exkurs: Modulauflösung mit JavaScript
Historisch gibt es in JavaScript verschiedene Arten von Modulsystemen. Mit ES6 wurde ein neues Modulsystem eingeführt, das in den meisten modernen Browsern unterstützt wird: ECMAScript Modules (ESM). Daher ist ESM seit einigen Jahren das bevorzugte Modulsystem im JavaScript-Ökosystem.
Mit ESM können Module weitere Module über zwei Arten einbinden; über einen top-level Import, sowie über den Aufruf der `import(...)` Funktion:
```
import { something } from '../some/module.js';
// ^- sofort verfügbar
const { somethingElse } = await import('../another/module.js');
// ^- erst nachdem await fertig ist verfügbar
```
Der Aufruf ist eine Promise. Es wird gewartet bis das Modul sowie alle Top-Level-Abhängigkeiten des Moduls geladen wurden. Top-Level-Imports werden sofort mit dem Einbinden des eigenen Moduls mitgeladen und sind dadurch ohne Promise verwendbar. Imports über `import(...)` werden erst dann ausgeführt, wenn die Funktion tatsächlich ausgeführt wird. Da es sein kann, dass das importierte Modul noch geladen werden muss, wird hier eine Promise zurückgegeben.
## Ansatz 1: Framework-spezifische UI-Komponenten
Wie oben erwähnt, habe ich für diesen Blogartikel zwei Strategien genauer unter die Lupe genommen. Erstens: das Einbinden Framework-spezifischer UI-Komponenten in eine Host-Anwendung. Zweitens: das Einbinden Framework-unabhängiger Web Components in eine Host-Anwendung.
Für den Framework-spezifischen Ansatz habe ich mir zwei Frameworks angeschaut: Angular und React.
Da beim Framework-spezifischen Ansatz Host und die eingebundenen Remote-Frontends mit demselben Framework implementiert werden müssen, wurden zwei separate Anwendungen, eine mit React und eine mit Angular, implementiert. Die Anforderung an die Applikationen war es, eine Komponente, bzw. ein Modul von einem anderen Server zu laden und erfolgreich in die Applikation einzubinden, und Daten in der Anwendung zwischen den lokal und remote zur Verfügung stehenden Komponenten zu übertragen.
Screenshot der React-Implementation. In Host-Anwendung (React) wird eine Komponente (React) zwei mal eingebunden. Diese Komponente wurde von einem anderen Server mithilfe von Module Federation geladen.
### Module Federation
Für den Framework-spezifischen Ansatz wurde Module Federation mithilfe von `@angular-architects/module-federation` (Angular) und `@originjs/vite-plugin-federation` (Vite/React) realisiert.
Da alle modernen Browser ESM direkt unterstützen, ist Module Federation auch ohne diese Plugins möglich. Dafür werden die Remote Frontends im Library-Modus gebaut und als ES-Modul direkt konsumiert. Die Plugins automatisieren diesen Schritt für uns und bauen zudem Polyfills für ältere Browser ein.
Module Federation verwendet standardmäßig die `import()` Funktion, um das Remote-Kompilat zu laden. Denn `import()` kann neben relativen Pfaden (`../module.js`) auch URLs (`http://localhost:3001/module.js`) aufrufen. Diese URLs können auch auf Server mit einer anderen Root URL zeigen, solange der Remote Server CORS-Header setzt.
Wurde das Frontend nicht im Library-Modus gebaut, können die Remote Module über `import()` nicht direkt aufgerufen werden. Das liegt daran, dass Bundler wie Webpack und Rollup (Vite) die JavaScript-Module umverpacken und für Browser optimieren. Statt `import("../util/myModule.js")` findet sich bei Webpack im Bundle ein minifizierter Aufruf von `__webpack_require__(module_id)`. Die ID ist intern und kann daher nicht „öffentlich“ konsumiert werden.
Die `remoteEntry.js` ist hier die Lösung. Sie stellt eine Art Nachschlagewerk bereit. Externe Module importieren die `remoteEntry.js` und rufen das interne Modul über den Namen auf.
Hier ein Ausschnitt der nicht minifizierten `remoteEntry.js` aus dem Angular-Projekt:
```
var moduleMap = {
'./RemoteRoute': () => {
return __webpack_require__
.e(44)
.then(() => () => __webpack_require__(2044));
},
};
/// ... der Rest der remoteEntry.js
```
Die remoteEntry.js zeigt einem Konsumenten, wo er im Remote Bundle die „öffentlichen“ JS-Module finden kann.
### React
Das React-Frontend verwendet als Build-Tool Vite, ein relativ neues Entwicklungswerkzeug, das viel Wert auf Entwicklererfahrung setzt und zum Beispiel mittels ESM und Überspringen eines Bundle-Steps während der Entwicklung erheblich schnellere Bauzeiten ermöglicht als es beispielweise bei Webpack der Fall ist.
Für Vite gibt es das `vite-plugin-federation`-Modul, welches als Plugin in die Vite-Konfiguration eingebunden werden kann. Über das Plugin lassen sich von diesem Kompilat bereitgestellte, sowie von externen Kompilaten konsumierte JavaScript-Module deklarieren:
```
// vite.config.ts
import federation from '@originjs/vite-plugin-federation';
return defineConfig({
...,
plugins: [
...,
federation({
name: 'my-component-name',
// Der Remote Entrypoint. Ein externes Modul kann diese Datei aufrufen
// und über einen Lookup eine der unter exposes definierten Komponenten
// laden.
filename: 'remoteEntry.js',
// Exposes, wenn dieses Modul Komponenten bereitstellt
exposes: {
'./SomeComponent': './src/components/SomeComponent',
'./AnotherComponent': './src/components/AnotherComponent',
},
// Remotes, wenn dieses Modul externe Komponenten konsumiert,
// mit einem Link zum Remote-Entrypoint.
remotes: {
someRemoteEntry: 'http://localhost:5001/assets/remoteEntry.js',
},
// Hier definierte Dependencies werden im Browser effektiv
// nur einmal geladen. Es muss also nicht pro Remote Frontend
// eine eigene React-Version geladen werden.
shared: ['react', 'react-dom'],
}),
],
});
```
Bei einem Build sorgt das Plugin dann dafür, dass die `remoteEntry.js`-Datei erzeugt wird. Die Komponenten können dann über den im `remotes`-Objekt definierten Namen eingebunden werden:
```
const RemoteComponent = React.lazy(() => import('someRemoteEntry/SomeRemoteComponent'));
return (
);
```
Das Plugin schreibt den Import während des Builds so um, dass die `remoteEntry.js` vom Remote Server importiert, und darüber die gewünschte Komponente gefunden wird.
Hier ist es wichtig, anzumerken, dass ein Top-Level-Import, also
```
import RemoteComponent from 'someRemoteEntry/SomeRemoteComponent';
```
**nicht** möglich ist, da es sich hier um eine synchrone Operation handeln würde. Das heißt, das Remote-Modul muss zuerst von einem anderen Server geladen werden.
Die `import(...)`-Funktion gibt das Modul als Promise zurück, welche gelöst wird, wenn das Modul, sowie alle Top-Level-Importe dieses Moduls aufgelöst wurden.
### Angular
Da Angular-Projekte standardmäßig Webpack als Build-Tool verwenden, habe ich dieses Tool mit dem Plugin `@angular-architects/module-federation-plugin` für das Aufrufen und Bereitstellen von Remote-Modulen ausprobiert.
Ähnlich wie beim `vite-plugin-federation` kann ein Modul über die `webpack.config.js` über `remotes` und `exposes` Remote-Module konsumieren, bzw. Module für andere Remote-Module bereitstellen.
```
module.exports = withModuleFederationPlugin({
// Wird von diesem Kompilat konsumiert
remotes: {
'angular-remote': 'http://localhost:3001/remoteEntry.js',
},
name: 'module-name',
// Liste der JS-Module, welche von diesem Kompilat bereitgestellt werden
exposes: {
'./ExposedRoute': './packages/angular-remote/src/app/remote-page.module.ts',
},
shared: {
...shareAll({
singleton: true,
strictVersion: true,
requiredVersion: 'auto',
}),
},
});
```
Auch ein Einbinden eines Remote-Modules ist unter Angular sehr ähnlich zum React+Vite- Beispiel:
```
const routes: Routes = [
{
path: '',
component: IndexRoute,
pathMatch: 'full',
},
{
path: 'remoteRoute',
// Das Remote Modul wird über eine Promise geladen. Dabei handelt
// es sich um ein Angular-Modul, welches ein
// RouterModule.forChildren(...) definiert.
loadChildren: () =>
loadRemoteModule({
type: 'module',
remoteEntry: 'http://localhost:3001/remoteEntry.js',
exposedModule: './RemoteRoute',
}).then((m) => m.RemotePageModule),
},
];
@NgModule({
imports: [RouterModule.forRoot(routes)],
exports: [RouterModule],
})
export class AppRoutingModule {}
```
Auch wenn für Angular unüblich, können hier Remote-Komponenten über das asynchrone Austauschen einer `ViewContainerRef` ohne einen Router eingebunden werden (vgl. [ViewContainerRef Dokumentation](https://angular.io/api/core/ViewContainerRef#usage-notes)).
## Ansatz 2: Framework-unabhängiger Ansatz mit Web Components
Für diesen Ansatz wurde eine Host-Anwendung mit Angular implementiert. In diese Anwendung wurden mehrere Web Components eingebunden, implementiert mit Vue, React und „Vanilla TS“. Diese Web Components werden dabei von einem anderen Server bereitgestellt.
Ein Screenshot der entwickelten Anwendung zeigt: In einen Angular-Host wurden mehrere Microfrontend-Komponenten über Web Components eingebunden.
### Web Components
Web Components sind eine [in allen gängigen Browsern unterstützte](https://developer.mozilla.org/en-US/docs/Web/API/Web_components#browser_compatibility) API, mit der neue HTML-Elemente definiert werden können. Diese Element können, ähnlich wie bei Vue und Angular, über Props Daten annehmen und über Events zurückgeben.
Eine Web Component wird erstellt, indem wir die Klasse `HTMLElement` erweitern.
Hier ein Beispiel einer sehr primitiven Web Component. Diese nimmt einen Namen an und rendert den Namen in einen Gruß:
```
class ExampleGreeter extends HTMLElement {
#name: string;
#root!: ShadowRoot;
#htmlElement: HTMLDivElement;
get name() {
return this.#name;
}
// Setter wird aufgerufen wenn das name-Prop modifiziert wird.
// Der Setter ruft die Render-Funktion auf
set name(name: string) {
this.#name = name;
this.render();
}
render() {
if (!this.#htmlElement) {
return;
}
this.#htmlElement.innerHTML = `Hello, ${this.#name}!`;
}
// Code wird aufgerufen wenn das Element aufgebaut wird
connectedCallback() {
this.#root = this.attachShadow({ mode: 'open' });
this.#htmlElement = document.createElement('div');
this.render();
}
// Cleanup Code. Wird aufgerufen wenn das Element entfernt wird
disconnectedCallback() {}
// Damit eine Web Component im HTML verwendet werden darf muss sie
// zuerst angemeldet werden.
// Danach kann die Web Component wie gefolgt verwendet werden:
//
static register() {
window.customElements.define('example-greeter', ExampleGreeter);
}
}
```
Eine wichtige Anmerkung zu Web Components ist, dass diese isoliert zum Rest der Webseite gestylt werden. Der Inhalt der Web Component läuft unter einer Shadow DOM. Die Shadow DOM stellt ein eigenes Dokument bereit. Styles können auf dieses separate Dokument über einen in der Web Component erstellten ``-Knoten oder durch Inline Styles angewandt werden. Diese Styles werden nur auf das eigene Dokument angewandt, die Styles werden also nicht an darunterliegende Web Components oder den Eltern-Knoten übergeben.
### Definition der Remote Frontends
Die Remote Frontends wurden so definiert, dass im Kompilat eine `/webcomponent.js` generiert wird. Die Datei definiert ein ES-Modul, welches als `default`-Export eine Funktion bereitstellt, über welche die Web Component im Host angemeldet werden kann.
Diese Struktur ist für alle Remote Frontends identisch, sodass ein Remote Frontend aus dem Host über
```
const module = await import(`http://localhost:${PORT}/webcomponent.js`);
module.default('component-name-to-use');
```
geladen und im Host registriert wird.
Danach kann im Host eine Komponente mit dem angegebenen Namen (hier `component-name-to-use`) erstellt werden.
Für die Remote Frontends wurde Vite als Build-Tool verwendet. Die Standard-Konfiguration bei Vite baut eine Single Page Application. Diese Konfiguration ist so aufgebaut, dass das Resultat auf einem Server gehostet werden kann und eine Webseite bereitstellt.
Es gibt aber auch den [Library Mode](https://vitejs.dev/guide/build.html#library-mode). Hier wird eine Code-Datei als Einstiegspunkt referenziert.
Statt einer ganzen Webseite wird im Libary Mode dieser Einstiegspunkt, sowie alle Abhängigkeiten, in ein Bundle gepackt. Dieses Bundle lässt sich dann als ES-Modul im Host einbinden.
```
// Die vite Config, welche für die Remote Frontends verwendet wird.
// Hier als Beispiel die vite-webcomponent.config.ts des Vue-Microfrontend
import { resolve } from 'node:path';
import { defineConfig } from 'vite';
import vue from '@vitejs/plugin-vue';
export default defineConfig({
plugins: [vue()],
define: {
'process.env': {},
},
base: 'http://localhost:5002/',
build: {
lib: {
entry: resolve(__dirname, 'src/webcomponent.ts'),
formats: ['es'],
fileName: 'webcomponent',
},
target: 'modules',
sourcemap: true,
},
});
```
Die resultierende `webcomponent.js` beinhaltet den ganzen Code, der für diese Web Component benötigt wird. Das beinhaltet die Laufzeit (bpsw. Vue), sämtliche Komponenten, die in der Anwendung definiert und eingebunden wurden, sowie die Logik zum Verpacken und Registrieren der Anwendung als Web Component.
Das Anbinden der Frontend-Frameworks an die Web Component hängt vom jeweiligen Framework ab. Vue 3 hat beispielsweise die [`defineCustomElement`](https://vuejs.org/guide/extras/web-components#definecustomelement)-Funktion, die eine Vue Singe File Component in eine Web Component umwandelt.
Die genauen Implementationen können [dem Github Repository](https://github.com/opitzconsulting/webcomponent-microfrontends) aus den `webcomponent.ts(x)`-Dateien entnommen werden.
### Einbindung und Kommunikation zwischen Host und Microfrontend-Komponenten
In der Host-Anwendung wurde eine Angular-Komponente definiert, die das Laden und Einbinden einer remote Web Component ermöglicht. Kurz gesagt lädt die Komponente über `import(...)` das Remote-Modul, ruft dort den Default Export auf und registriert somit die Web Component. Daraufhin wird eine Instanz der Web Component erstellt und der Zustand zwischen der Host-Anwendung und der Web Component verknüpft.
Die Web Components sind so aufgebaut, dass die Host-Anwendung einen Zustand (hier Testweise `count`) übergeben und über Updates auf diesen Zustand informiert werden kann. Für die Information ist die Anmeldung an ein von der Web Component bereitgestelltes `CustomEvent` notwendig.
Ein Kommunikations-Beispiel zwischen den Web Components und der Host-Anwendung zeigt: Die Host-Anwendung übergibt Daten „nach unten“ über Props.
Aktualisiert eine der Web Components den Zustand, erfährt die Host-Anwendung darüber über das `CustomEvent`. Kommt ein Event an, aktualisiert die Host-Anwendung den eigenen Zustand. Die Änderung wird in die Web Components propagiert, wodurch der neue Zustand in allen Web Components landet.
Für das Beispiel wurde ein sehr einfacher Zustand, ein einzelner Counter, verwendet. Es ist jedoch genauso möglich, den Zustand komplexer aufzubauen oder sogar eine Message Queue zu implementieren.
# Beide Ansätze im Vergleich
Im Grunde können beide Herangehensweisen verwendet werden, um Microfrontends zu realisieren. Der Framework-spezifische genauso wie die Framework-unabhängige. Doch es gibt Unterschiede:
Der Framework-spezifische Ansatz hat den Vorteil, dass Frameworks wie *React*, *Vue* oder *Angular* nur einmal eingebunden werden. Somit bleibt das generierte Bundle vergleichsweise klein. Auch bleibt man dadurch im Daten-Konzept des jeweiligen Frameworks (bspw. `:props` und `@events` mit Vue) und kann Komplexität sparen, die durch das Verpacken der Anwendung in eine Web Component entstünde.
Der Framework-unabhängige Ansatz mit Web Components hat den Vorteil, dass man sich nicht auf ein bestimmtes Framework beschränkt. Für die Kommunikation zwischen Host und Microfrontends wird eine API verwendet, die im [Living Standard für HTML](https://html.spec.whatwg.org/multipage/custom-elements.html#custom-elements) definiert ist.
Man darf davon ausgehen, dass Web Components als Standard stabil sind. Falls verwendete Frameworks in der Zukunft nicht mehr unterstützt werden, wäre der Austausch vergleichsweise einfach.
Ein Nachteil dieses Ansatzes ist, dass jedes Microfrontend das verwendete Framework separat einbindet. Dies hat jedoch auch den Vorteil, dass es nicht zu Versionskonflikten kommen kann.
Bei der Implementation des Framework-spezifischen Ansatzes bekam ich kryptische Fehler beim Anbinden eines Microfrontends. Nach längerem Debugging entdeckte ich die Ursache: Der Fehler kam aufgrund unterschiedlicher Versionen zwischen Host und Microfrontend zustande.
Eine alternative Lösung ist es, in den Web Components und im Host die Frameworks als *externe Abhängigkeiten* einzubinden.
Das verhindert einerseits, dass die verwendeten Funktionen des `react`-Moduls in die `webcomponent.js` kopiert werden und sorgt gleichzeitig dafür, dass stattdessen das `react`-Modul auch weiterhin als Top-Level-Import im Kompilat eingebunden wird. Gekoppelt mit einer [Import-Map](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap) können so mehrere `react`-Imports auf denselben Import abgebildet werden, wodurch das zu ladende JS-Bundle kleiner wird.
Beide Ansätze teilen die grundlegenden Probleme mit Microfrontends:
- Builds sind schwerer reproduzierbar, weil es keine Single Source-of-Truth gibt. Es müssten also alle Komponenten in einer bestimmten Version deployt werden, um einen Build reproduzierbar zu testen.
- Weil es zum Übersetzungzeitpunkt keine Informationen über die Microfrontends gibt, gibt es keine Typsicherheit auf der Schnittstelle
# Welche Alternativen gibt es?
Zwei alternative Ansätze sollten meines Erachtens nicht unerwähnt bleiben. Mit ihnen lassen sich einige der genannten Probleme lösen:
## 1. Komponenten-Bibliothek
Statt die einzelnen Microfrontends dezentral zu deployen und von einem zentralen Host zur Laufzeit die einzelnen Microfrontends einzubinden, könnten die Microfrontends weiterhin dezentral gebaut, aber zentral *zur „Kompilierzeit“* eingebunden werden – oder anders gesagt: Die Microfrontends stellen jeweils Komponenten über ein NPM-Modul bereit, das vom Host konsumiert wird.
Dadurch gewinnen wir Typ-Sicherheit und haben Dank der Single Source-of-Truth einen reproduzierbaren und somit deutlich testbareren Build. Die „Microfrontends“ können weiterhin isoliert voneinander entwickelt und getestet werden. Die einzige Konfliktstelle zwischen den verschiedenen Implementationsteams stellt die Host-Anwendung dar. Hier müssen die einzelnen Module in der `package.json` eingebunden und bei Bedarf aktualisiert werden.
Der Nachteil: Die einzelnen Microfrontends verlieren an Unabhängigkeit: Sie sind nicht mehr unabhängig deploybar, die Deploymentzeitpunkte sind zeitlich aneinander gekoppelt.
## 2. Multipage-Application (MPA) mit nginx
Ein Beispiel-Aufbau mit NGINX und Microfrontends im MPA Ansatz
Sind die einzelnen Microfrontends vollständig voneinander isoliert, also nicht verschachtelt, und bilden nur Routen ab, könnte die Verwendung einer Multi Page Application (MPA) mit nginx in Erwägung gezogen werden.
Die ganzen Frontends werden separat als *vollständige* Frontends deployt. Die Router der jeweiligen Microfrontends sind so konfiguriert, dass die Wurzel nicht `/` ist, sondern ein dem Frontend zugeordneter Pfad wie `/account` oder `/checkout`. Somit ist beispielsweise ein Microfrontend zuständig für die `/account/**`-Routen, ein anderes für die `/checkout/**`-Routen.
Die Frontends werden auf verschiedenen Server unabhängig deployed. Es wird als „Host“ ein Nginx-Deployment erstellt, das die einzelnen Pfade auf die dazugehörigen Frontend-Deployments abbildet. Bleibt der Nutzer auf demselben Microfrontend, so wird der Frontend-interne Router verwendet. Wechselt man zwischen den Microfrontend, dann wird die ganze Seite neu geladen. Dies führt zu etwas längeren Ladezeiten, da das HTML-Dokument, sowie die ganzen Styles und Skripte für das neue Microfrontend geladen und ausgeführt werden müssen. Dieses Problem kann jedoch durch das Setzen eines `` in der aufrufenden Seite eingedämmt werden.
Ein weiteres Problem ist geteilter Zustand. Möchte man Daten zwischen den Frontends austauschen, kann nicht der Frontend-interne Store verwendet werden.
Ein Lösungsansatz ist es, den geteilten Zustand in die `sessionStorage` zu schreiben. Hierfür muss der Zustand als String abbildbar sein, bspw. als JSON String. Während der `localStorage` einen permanenten Key-Value-Store für eine Webseite darstellt, ist der `sessionStorage` nur für die aktuelle Session aktiv. Wenn eine Webseite auf mehreren Tabs geöffnet wird, wird für jeden Tab eine neue Session erstellt. Wird ein Tab, bzw. der Browser, geschlossen, dann erlischt die Session (vgl. [MDN Docs](https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage)).
Dank der nginx Proxy haben alle Frontends für den Browser denselben Origin. Dadurch verfällt die `sessionStorage` nicht bei einem Seitenwechsel auf ein anderes Microfrontend.
# Mein persönliches Fazit
Microfrontends bieten die Möglichkeit, riesige und hochkomplexe Frontends sinnvoll aufzuteilen und voneinander unabhängig zu machen und somit auch unabhängig daran zu entwickeln.
Du solltest dir jedoch gut überlegen, ob die Einbußen in der Entwicklererfahrung, Testbarkeit, Typsicherheit und Reproduzierbarkeit von Builds sich für die dadurch gewonnene Unabhängigkeit der einzelnen Microfrontends lohnen.
Für *riesige* Anwendungen kann dies tatsächlich der Fall sein. Doch für die meisten Anwendungen sind Investitionen in bessere Architektur, einen besseren Schnitt der Komponenten und klare Coding-Konventionen eine effizientere Art, um Konflikte zwischen Entwicklungsteams an einem Frontend zu reduzieren.
Wenn ich zwischen einer der beiden gezeigten Strategien für Microfrontends wählen müsste, würde ich die framework-unabhängige Herangehensweise empfehlen.
Aufgrund von drei Gründen:
- Höhere Flexibilität (weil unabhängig von Framework und Version)
- Einfachere Austauschbarkeit durch die Verwendung von Web Components
- Unterstützung und Unabhängigkeit: Wie erwähnt sind Web Components Teil der HTML-Spezifikation, werden von allen gängigen Browsern unterstützt und bieten somit eine Framework-unabhängige Möglichkeit für die Kommunikation zwischen Microfrontends.
# Weiterführende Links
- Git-Repo framework-abhängiger Implementation mit Angular:
- Git-Repo framework-abhängiger Implementation mit React:
- Git-Repo framework-unabhängiger Implementationen:
- MDN Docs zu Web Components: [https://developer.mozilla.org/en-US/docs/Web/API/Web\_components](https://developer.mozilla.org/en-US/docs/Web/API/Web_components)
- HTML Spezifikation zu Custom Elements:
- Bibliothek Microfrontends Angular:
- Bibliothek Microfrontends React / Vite:
**Kategorien:** Architecture & Process Models, Development
**Schlagwörter:** microfrontends, TypeScript, web, web components
---
### [How to ignore errors for unreachable hosts in AWX](https://thecattlecrew.net/2024/06/17/how-to-ignore-errors-for-unreachable-hosts-in-awx/)
**Published:** Juni 17, 2024
**Author:** Bartlomiej Sowa
**Content:**
As many of you already know, Ansible AWX is a great and powerful tool to manage your infrastructure. However even one unreachable host results in entire AWX job being reported as failed regardless of the outcome of all other hosts. If you would like to ignore unreachable hosts and prevent marking jobs as failed just because of host reachability keep reading…
# The problem
When you run jobs against your entire big inventory (for example to rollout some compliance settings, cmdb update or some checks) very often you target some hosts, that are simply down for any reason whatsoever.
Having only one host powered down / not reachable results in `ansible-playbook` returning exit code 4 (BTW [here you find](https://jwkenney.github.io/ansible-return-codes/) excellent description of all exit codes for Ansible and when which code is produced).
AWX decides alone based on exit code, whether the entire job was successful or not. And in case of unreachable hosts – **the entire job is reported as failed**.
Because of this, such AWX job will very often be failed. Therefore it might be hard to distinguish if there is really a problem with your Ansible code (and the playbook fails for all of the hosts), or this is just because of unreachable hosts.
Of course you can each time analyze the task output, but especially when working with slices each time you would need to analyze outputs of each slice manually… just to find out that this is still due to having at least one unreachable host.
# Solution
There is a quite simple solution – just by using Ansible means, as this is where the problem comes from. Just prepend the main PLAY in the playbook with another one, that checks reachability of hosts. Then execute the main PLAY only on the reachable ones. That way if you get an error for the entire Job, you know for sure that there is a problem that needs to be addressed.
Here is how such a playbook might look like:
```
- name: Check host reachability
gather_facts: false
hosts: "{{ target_hosts }}"
tasks:
- name: Check connection via explicite fact gathering
ansible.builtin.setup:
register: reachable_check
- meta: clear_host_errors
- name: Add to un-/reachable group
ansible.builtin.group_by:
key: "{{ reachable_check is unreachable | ternary('unreachable','reachable') }}_hosts"
- name: MAIN PLAY - Actions with reachable hosts
hosts: reachable_hosts
gather_facts: true
tasks:
- ....
roles:
- ...
- name: SUMMARY Play (optional)
hosts: localhost
gather_facts: false
tasks:
- name: SUMMARY
ansible.builtin.debug:
msg: "Playbook executed on {{ groups['reachable_hosts'] | length }}/{{ q('ansible.builtin.inventory_hostnames',target_hosts) | length }} hosts that were reachable."
- name: Unreachable hosts with reason for unreachability
ansible.builtin.debug:
msg: "{{ hostvars[item]['reachable_check']['msg'] }}"
with_items: "{{ groups['unreachable_hosts'] }}"
```
By using this extra play before you assign a host either to `reachable_hosts` or `unreachable_hosts` virtual inventory group. Then by running next play only against `reachable_hosts` the main playbook code is executed only against hosts, that were reachable during the time the job was started. As a bonus you get a list of hosts that are not reachable should this be needed like for the summary at the very last play.
Also if using `clear_host_errors` be aware that as of moment of writing of this article there was a [still open Bug in Ansible](https://github.com/ansible/ansible/issues/35086), that results in unexpected behavior when there are many tasks between the failing one and the meta task. Make sure that the bug is already fixed or you have just one task before the meta that might fail due to unreachable host.
If calling `ansible.builtin.setup` is not wanted (for example when using fact caching and explicite fact collection takes too much time/ressources) you may use any other task like `ansible.builtin.ping` (or `ansible.builtin.win_ping`) as long as it really connects to the host (some do not) and is able to produce `unreachable` status (here again, not all do).
# Solution 2
If you do not need extra information about unreachable hosts in the summary, you may skip the register variable and just declare reachable\_hosts group like this:
```
...
tasks:
- name: Check connection via explicite fact gathering
ansible.builtin.setup:
- name: Add to un-/reachable group
ansible.builtin.group_by:
key: "reachable_hosts"
- meta: clear_host_errors
...
```
This way you save the runtime inventory some bytes by not doubling all collected facts. This might seem nothing, but at a scale of thousands of hosts memory can start getting an issue.
# Another solution
This is of course not the only working solution (as in Ansible, there are always multiple ways to achieve the same result more or less performant). There is also a posibility to use `block:` with `rescue:` and do not use `meta: clear_host_errors` like this:
```
- name: Check host reachability
gather_facts: false
hosts: "{{ target_hosts }}"
tasks:
- block:
- name: Check connection
ansible.builtin.wait_for_connection:
timeout: 10
register: reachable_check
# ignore_unreachable: true
- name: Add to reachable hosts
ansible.builtin.group_by:
key: "reachable_hosts"
rescue:
- name: Add to unreachable hosts
ansible.builtin.group_by:
key: "unreachable_hosts"
- name: MAIN PLAY - Actions with reachable hosts
hosts: reachable_hosts
gather_facts: true
tasks:
...
```
Here the `ansible.builtin.wait_for_connection` has been used instead of `ansible.builtin.setup` to save some space in runtime inventory (especially when using fact\_caching and explicite fact gathering is not wanted). This approach however has some drawbacks:
- `ansible.builtin.wait_for_connection` does not return unreachable status, only a failure. Changing it to something that returns unreachable would require either to use `ignore_unreachable: true` on the task to conert unreachable into failed (as rescue does not heal not reachable hosts) or `meta: clear_host_errors` as a last task outside block (do not use this meta inside block, as weird things happen)
- the `rescue:` block heals failed tasks and there is no information about failure/unreachability (only `rescued` in the standard ansible summary at the very bottom)
# Summary
The first proposed solution works in a way, that AWX shows the number of unreachable hosts next to number of total and/or failed hosts at the very top of the Job Summary and I personally like it better.
All solutions work with windows and linux target hosts which also might need do be eventually taken into account when choosing proper check task. Final choice is of course yours, feel free to experiment (as long as it is not on production environment :))
See also other [Ansible](/tags/ansible) or [AWX](/tags/awx) Related articles on [CattleCrew](/).
**Kategorien:** Automation, Infrastructure
**Schlagwörter:** ansible, Automation, awx, unreachable
---
### [Manage Kubernetes Services with Kong](https://thecattlecrew.net/2024/06/03/manage-kubernetes-services-with-kong/)
**Published:** Juni 3, 2024
**Author:** Sven Bernhardt
**Content:**
Kubernetes (K8s) has become a cornerstone technology for deploying and managing containerized applications. But have you ever wondered how to manage your K8s services efficiently, especially when exposing many services outside the Cluster?
By opting for an API gateway over a simple Ingress Controller, you’re simplifying the management of your K8s services and enhancing your control and efficiency. The API Gateway is a single entry point for client requests, abstracting security-related complexities, service discovery, routing, and load balancing. This centralized management of all your APIs running within the Kubernetes Cluster empowers you to handle your services easily. Moreover, an API Gateway opens up new possibilities like API Analytics, further enhancing your capabilities. Additionally, you can expose your services using protocols like TCP, UDP, or gRPC, giving you the flexibility you need.
# One Gateway, multiple options
With Kong’s flexible API Gateway, you become independent of any platform or runtime. In Kubernetes, you have two variants for deploying and using Kong Gateway. You can deploy it as a regular Kubernetes Service or an Ingress Controller.
## Deployment model: Kong Gateway as Kubernetes Service
When you choose to deploy Kong Gateway as a regular Kubernetes deployment, you’re making a decision that significantly benefits your operations. However, it’s important to note that you’ll need to make the Kong Proxy and Admin API services available outside the Cluster. This step, though necessary, is a small price to pay for the enhanced control and management that Kong Gateway brings to your Kubernetes services.
With the Kong Gateway in place, you can configure other Kubernetes services to be securely exposed. The Kong Admin API plays a crucial role here. It allows Gateway Admins to update the Gateway’s configuration. Because it can change the Gateway configuration, you must ensure that the [Kong Admin API is adequately secured](https://docs.konghq.com/gateway/latest/production/running-kong/secure-admin-api/#main).
The Kong Admin API is a REST API. Therefore, you can integrate it easily with CI/CD pipelines. However, this can be cumbersome due to the imperative nature of a REST interface. Instead of using the Admin API directly, Gateway Admins can use [Kong decK](https://docs.konghq.com/deck/latest/). The tool allows us to manage the Kong Gateway configuration declaratively. In the background, it connects to the Admin API and automatically applies the necessary changes.
Figure 1: Kong deployed as a regular K8s service
The API Gateway can also secure Kubernetes traffic internally using this deployment model. If you have such requirements, you should consider using a Service Mesh like [Kuma](https://kuma.io/) to secure and manage your East-West traffic.
## Deployment model: Kong Ingress Controller
If you want to manage your Kubernetes services in a Kubernetes-native way, you can use the [Kong Ingress Controller (KIC)](https://docs.konghq.com/kubernetes-ingress-controller/latest/). It defines respective c[ustom resource ](https://docs.konghq.com/kubernetes-ingress-controller/latest/reference/custom-resources/)definitions, so Gateway Admins can use Kubernetes Manifests to configure Kong Gateway.
As shown in Figure 2, there’s still a Kong Gateway proxy for exposing Kubernetes services to the outside world. In addition, you can see an Ingress Controller component. As it watches etcd, it is essential for relevant Kong-specific Manifests. KIC translates these into Kong Gateway configurations and applies them to the proxy. In the background, KIC uses Kong Admin API to configure the Gateway proxy.
Figure 2: Kong Ingress Controller deployment
The main differences regarding the scenario above are:
- You don’t need to expose the Kong Admin API publicly
- Gateway configuration in a Kubernetes-native way
- Securing Kubernetes internal traffic is not possible
# Increasing complexity through API distribution
Usually, you have to deal with more than just one Kubernetes cluster. In addition, you’ll also have to deal with non-containerized workloads. Furthermore, you may distribute those workloads over on-prem environments and different public cloud vendors. Now, you may ask how to manage all APIs in that distributed environment consistently.
[Kong Konnect](https://konghq.com/products/kong-konnect) is a single-pane-of-glass solution for tackling the challenges of today’s distributed world. It provides a central, global control plane with rich management capabilities. Read [this blog](https://konghq.com/blog/product-releases/kic-in-kong-konnect) to learn more about Konnect.
# Seeing is believing
Would you like to see this in action? Fortunately, I created a video tutorial that shows how to get started with Kubernetes-native API Management using Kong Konnect and Kong Ingress Controller.
Check it out, and let me know your thoughts, impressions, and questions!
# Further reading
If you want to learn more about the unique features of an API Gateway like Kong, I recommend [this blog](https://konghq.com/blog/engineering/how-to-manage-your-kubernetes-services-with-an-api-gateway). It details when an API Gateway might be more suitable for your needs than a simpler Ingress Controller such as Nginx.
**Kategorien:** Development, Integration
**Schlagwörter:** API, API Management, cloud native, Kong, Kubernetes, Tutorial
---
### [Lessons Learned Applikationswartung - Eine Retrospektive (Teil 1)](https://thecattlecrew.net/2014/06/22/lessons-learned-applikationswartung-eine-retrospektive-teil-1/)
**Published:** Juni 22, 2014
**Author:**
**Content:**
[](https://thecattlecrew.net/wp-content/uploads/2014/06/retrospektive-msa2.png)
Dieser Blogeintrag ist der Anfang einer Serie von Blogeinträgen, in denen ich meine Erfahrungen mit der **Organisation von Wartung und Weiterentwicklung von Individualsoftware** weitergeben möchte. Hierbei betrachte ich in einer Art Retrospektive die Erfahrungen, die ich mit meinem Team bei Opitz Consulting gesammelt habe. Dieses Team erbringt unter dem Namen „Managed Services Applications“ Dienstleistungen für unsere Kunden. Zusätzlich fließen auch viele weitere Projekt- und Wartungssituationen aus den vergangenen Jahren ein, bei denen wir in unterschiedlichsten Konstellationen (gemischte Teams, Beratungsdienstleistungen, Professional Services) uns zum Thema Wartung und Weiterentwicklung bei unseren Kunden eingebracht haben.
Wie in einer Retrospektive üblich teile ich meine Erfahrungen in vier Kategorien ein (siehe auch http://www.retrospectives.com/pages/RetrospectiveKeyQuestions.html):
- Was war gut und ich würde es weiter so machen?
- Was sollte ich beim nächsten Mal anders machen?
- Was habe ich gelernt?
- Was verwundert mich immer noch?
Anfangen möchte ich heute mit einer Erfahrung, die ich aus positiver und negativer Sicht gemacht habe und die somit sowohl unter der Kategorie „Was war gut?“ als auch unter „Was sollte ich beim nächsten mal besser machen“ auftauchen kann:
- **„Softwareentwicklung und Softwarewartung durch getrennte Teams verursacht Schmerzen“**
- **„Softwareentwicklung und Softwarewartung ist dann erfolgreich, wenn diese aus einer Hand durch ein Team erfolgt“**
Meine Erfahrung zeigt, dass in der Praxis häufig die Entwicklung der Lösung (Projekt) und die anschließende Wartung organisatorisch getrennt werden. Auf die Spitze wird dies getrieben, wenn auch kleinere Erweiterungen (CRs) über ein Entwicklungsteam abgewickelt werden, während das Wartungsteam sich nur um die vermeintlich unangenehmen Dinge wie Bug Fixing und Rufbereitschaft kümmern darf. Aus meiner Sicht sprechen viele Gründe gegen diese strikte Trennung.
### Wissenstransfer
Der notwendige Wissenstransfer aus dem Entwicklungs- in das Wartungsteam erzeugt hohe Kosten und Reibungsverluste. Dies verschärft sich noch, wenn der Wissenstransfer nicht nur einmal erfolgt sondern kontinuierlich erfolgen muss. Dies ist für viele Systeme, die sich nicht am Ende ihres Lebenszyklus befinden, aber durchaus der Fall.
Besonders die agile Softwareentwicklung schreit in diesem Zusammenhang nach Entwicklung und Wartung durch ein Team. Optimaler Weise werden in agilen Entwicklungsprojekten bereits frühzeitig erste Ergebnisse produktiv gesetzt. Die erste Produktivsetzung definiert den Beginn der Wartungsphase. Häufig ist zu einem so frühen Zeitpunkt ein dediziertes Wartungsteam nicht denkbar und ein regelmäßiger Wissenstransfer kaum möglich.
Achtung: Eine ausreichende Dokumentation ist trotzdem sinnvoll. Wartung und Entwicklung aus einem Team heraus lässt die Dokumentation im ersten Moment weniger wichtig erscheinen. Hier sollten aber Reviews und ähnliche Maßnahmen dazu führen, dass die Dokumentation nicht vernachlässigt wird. Ich ergänze dies als weitere Karte unter „Was habe ich gelernt?“
### Auslastung
Erfolgt Softwareentwicklung und Wartung aus einem Team heraus ist es deutlich leichter die Teams kontinuierlich zu beschäftigen. Auslastungsschwankungen sollten durch das temporäre Hinzufügen von Entwicklern (ggf. auch Externe) ausgeglichen werden. Am Ruder bleibt immer das langfristig eingesetzte Wartungsteam. Dies ist eine weitere Karte (diesmal in der Kategorie „Was habe ich gelernt?“) wert: „Die Wartung gibt den Ton an“.
### Verantwortung
Die Trennung von Wartung und Entwicklung wirkt sich negativ auf das Verantwortungsbewusstsein der beteiligten Personen aus. Entwickler identifizieren sich mit der durch sie entwickelten Software und sind um hohe Qualität bemüht. Wurde die Software durch ein anderes Team entwickelt, kann sich das Wartungsteam leicht auf ein „den Fehler haben die Anderen eingebaut“ zurückziehen. Verschärft wird dieses Problem, wenn auch noch unterschiedliche Vertragspartner Entwicklung und Wartung übernehmen. Hier wird dann gerne und lange über den Verursacher und die Übernahme von Kosten (Gewährleistung ja oder nein) diskutiert.
### Motivation
Wartungsaufgaben werden eher als uninteressant empfunden. Gleichwohl sind viele Probleme in der Wartung hochkomplex und benötigen sehr fähige Softwareentwickler für die Analyse und Lösung. Das Zusammenlegen von Entwicklungs- und Wartungsaufgaben in ein Team ermöglicht einen Ausgleich zwischen unterschiedlichen Aufgabentypen. Stärken und Schwächen aber auch Vorlieben einzelner Mitarbeiter können und sollten berücksichtigt werden.
### Abschließende Überlegungen
Sinnvoll erscheint die Steuerung des Wartungs- und Entwicklungsteams über **Kanban**. Ich notiere dies auf einer Karte unter der Rubrik „Was verwundert mich immer noch?“ und merke mir dieses Thema für einen späteren Blogeintrag vor.
**DevOps** treibt den Gedanken weiter. Betrieb wird ebenfalls ins Team integriert. Auch dies ergänze ich als Karte unter „Was verwundert mich immer noch?“ und betrachte es vielleicht später in diesem Blog im Detail.
Und zum Schluss der wichtige Hinweis: **„Jede Situation ist anders!“**. Es gibt keine Standardvorgehensweisen. Höchstens Best Practices und Rahmenwerke, an denen man sich orientieren kann, die am Ende aber immer individuell angepasst und kontinuierlich hinterfragt und verbessert werden sollten.
**Kategorien:** DevOps, Tools & Methoden
**Schlagwörter:** ALM, Applikationswartung, Managed Services, Management, MSA, Retrospektive, Softwarenentwicklung, Wartung, Weiterentwicklung
---
### [Mobile Team as a Service](https://thecattlecrew.net/2017/07/07/mobile-team-as-a-service/)
**Published:** Juli 7, 2017
**Author:** philippleinius
**Content:**
Das Thema Mobile bewegt uns längst nicht mehr nur im privaten Umfeld sondern auch im Unternehmen. Warum ist das so und wie können Unternehmen dieser Anforderung begegnen?
## Gestiegene Ansprüche & Generationenwechsel
Verdeutlichen wir uns den Einsatz von mobiler Software anhand der Glockenkurve von Rogers (Diffusion of Innovations, 1962):
Die Innovators des Einsatzes mobiler Software im heutigen Sinne finden sich in den späten 90er- und frühen Nuller-Jahren: Erste Unternehmen nutzten Anwendungen für Pocket PC / Windows Mobile. Ein Beispiel ist allgemein bekannt in Form der „Postboten-Keulen“, Geräten mit resistivem Touchscreen und eingebauter Tastatur. Auch Privatleute besaßen vereinzelt PDAs (Personal Digital Assistant), etwa von der Firma Palm.
Die Early Adopters folgten kurz darauf: Immer mehr Unternehmen setzten auf Geräte von Blackberry. Diese ermöglichten, mit ihrer dauerhaft bestehenden Push-Verbindung, eine Verschiebung der asynchronen Kommunikation per Email in Richtung Echtzeit.
Die Verwendung mobiler Technologie durch die Early Majority der Konsumenten begann 2007 mit der Vorstellung des iPhones. Ob kostenloses Echtzeit-Messaging, Spiele, Nachrichten oder Nischenwünsche: „There was an App for that“.
Im Bereich der Konsumenten sind 10 Jahre später längst die Laggards wie Schwiegermütter und Opas erreicht: Sie haben entweder schon ein Smartphone oder denken darüber nach.
Innerhalb von Unternehmen ist heute allerdings erst die Phase der Early Majority .
Durch diesen Innovations-Vorsprung sehen sich die Unternehmen einem Erwartungsdruck ausgesetzt: Viele Mitarbeiter und Kunden fragen sich, warum die Anwendungen im professionellen Einsatz, denen aus dem Privatleben nicht das Wasser reichen können.
Mit dieser Erkenntnis begeben sich die Unternehmen an die Umsetzung von interner Software in Apps. Richtungsweisend sind hier die Giganten: IBM und SAP haben Partnerschaften mit Apple zur Entwicklung von Enterprise-Apps geschlossen (2014 respektive 2016).
Hier sprechen wir von der „2. Welle der Apps“.
Darüber hinaus steht bei einigen der Innovators und Early Adopters ein Generationenwechsel an: Die bisher verwendeten Plattformen sind am Ende ihres Lebenszyklus angekommen und nicht mehr wirtschaftlich zu betreiben und/oder zu erweitern. Heute wollen sie entweder auf moderne und ausgereifte Plattformen wie iOS und Android setzen oder speziellen Anforderungen mit Multi-Plattform-Technologien wie ReactNative oder Xamarin begegnen.
## Spezialisten unterstützen den kompletten Lifecycle
Wir, als Berater, knüpfen bereits bei ganz grundlegenden Entscheidungen der Unternehmen an:
- Wer sind meine Kunden?
- Wie erreiche ich Wirtschaftlichkeit für meinen Anwendungsfall?
- Welche Technologie ist die richtige für meine besonderen Anforderungen?
Entsprechend bieten wir sowohl Workshops zur Auswahl von Engagement- und Geschäfts-modellen als auch solche für die passende Mobile-Technologie an.
Wir unterstützen die Konzeption und Implementierung mit Teams aus Spezialisten. Die mobilen Plattformen und Sub-Plattformen, wie watchOS oder Android TV, sind längst so komplex, dass es einer Spezialisierung bedarf um nach dem State of the Art zu arbeiten.
Komplette Teams haben darüber hinaus den Vorteil, dass sie sich bereits auf Konventionen und Vorgehensweisen geeinigt und eventuelle persönliche Differenzen überwunden haben, also vom ersten Tag an produktiv sind.
Auf Grund einer schlanken Projektleitung können die Teams aus Mobile-Entwicklern um Rollen, wie Product Owner, UX-Spezialisten und Backend-Entwickler ergänzt werden.
Schließlich sind wir darauf eingestellt, Apps über ihren kompletten Lebenszyklus zu begleiten: Wir freuen uns, wenn ein Kunden uns nach Konzept und Implementierung auch Betrieb & Wartung seiner Software anvertraut. Unserer Meinung nach entstehen die besten Produkte wenn sie auch in dieser Dimension von vornherein auf geringe Reibung ausgelegt sind. Und nichts gewährleistet das eher, als wenn dieselben Personen für Implementierung und Betrieb zum Einsatz kommen.
## Engagement Model
Unternehmen können dabei explizit die mobilen Leistungen als Dienstleistung, als Werk oder aber als Services beauftragen. Dabei ist aber vor allem das Engagementmodel „Mobile Team as a Service“ für Unternehmen interessant. Hierbei kann ein Unternehmen, je nach seinen Bedürfnissen, auf ein Mobile-Team zugreifen und bekommt anhand seiner Kriterien Services für seine Anforderungen geliefert. So ist es denkbar, dass ein Team Unternehmen mit einer gewissen Mannstärke und speziellen Skills in gewissen Servicezeiten zur Verfügung steht. Dabei können Unternehmen je nach Bedarf die Mannstärke skalieren und zusätzliche Services geliefert bekommen, z. B. Usability Engineering und Architekturberatung. Darüber hinaus kann das Unternehmen die benötigte Infrastruktur von der Entwicklung bis zum Betrieb erhalten.
## Fazit
Mit dem Modell „Mobile Team as a Service“ können Unternehmen einfach und entspannt die besonderen Herausforderungen der Mobile-Entwicklung angehen. Dabei rufen sie entspannt die Services entspechend ihren Anforderungen ab.
Für mehr Informationen zu den Angeboten von Opitz Consulting zum Thema Mobile kontaktieren Sie gerne Philipp Leinius (philipp.leinius@opitz-consulting.com) oder Karsten Will (karsten.will@opitz-consulting.com).
**Kategorien:** Development, Tools & Methoden
---
### [Managed Services "“ Engagement-Modelle](https://thecattlecrew.net/2017/07/27/managed-services-engagement-modelle/)
**Published:** Juli 27, 2017
**Author:** philippleinius
**Content:**
Mit diesem Blogeintrag möchten wir einen generellen Überblick über unsere Managed-Services-Angebote geben, die wir als Alternativen zu herkömmlichen Formen der Zusammenarbeit zwischen Kunde und Dienstleister anbieten. Hierbei berichten wir über die Erfahrungen, die wir mit unseren Teams im Laufe unserer Aktivitäten gesammelt haben.
## Warum Managed Services
Grundsätzlich steht die IT eines Unternehmen vor einer Vielzahl von Herausforderungen, wenn es darum geht, die Wartung, Weiterentwicklung und Entwicklung seiner Individualsoftware und deren Infrastruktur sicherzustellen. Dies können beispielweise die folgenden Aspekte sein:
Die IT „¦
- „¦ muss Personal und dessen Know-how effizient einsetzen.
- „¦ muss schnell auf geänderte Geschäftsmodelle reagieren.
- „¦ muss den Betriebsübergang von Neuentwicklungen effizient steuern.
- „¦ muss die Wartung und Weiterentwicklung von Anwendungen und Infrastruktur sicherstellen.
- „¦ muss im Rahmen der Digitalisierung IT-Trends und Innovationen im Blick halten.
- „¦ muss das IT-Budget einhalten.
Diese Liste lässt sich fast beliebig erweitern. All die genannten Aspekte stellen die Unternehmens-IT vor große Herausforderungen. Eine Lösung könnte sein, die Leistungen nicht intern oder nur zum Teil intern sicherzustellen, sondern diese als Service einzukaufen und somit die Leistungen bei Bedarf komfortabel abzurufen. Hierbei ergeben sich je nach Problemstellung zwei Schwerpunkte, Operation oder Development, und dazu unterschiedliche Engagement-Modelle.
## Managed Services „“ Operation
Hat sich ein Unternehmen entschieden, den Betrieb der Individualsoftware und somit die Wartung und Weiterentwicklung über einen externen Dienstleister sicherzustellen, können verschiedene Engagement-Modelle die Basis für die Zusammenarbeit sein. Je nach Wahl des Engagement-Modells trägt der Kunde oder der Dienstleister die Verantwortung für die Aufrechterhaltung des Betriebs der Infrastruktur und/oder der Applikation. Die Engagement-Modelle können dabei folgende Ausprägung haben:
**Dienstleistungen für Software- und Infrastruktur-Betrieb**
Bei diesem klassischen Engagement-Modell hat weiterhin das Unternehmen die alleinige Verantwortung für den Betrieb der Infrastruktur und deren Applikationen. Der Dienstleister unterstützt dabei und stellt dem Kunden je nach Bedarf Experten mit dem entsprechenden Know-how zur Verfügung. Diese Form der Zusammenarbeit ist vor allem zur Abdeckung von kurz- bis mittelfristigen Engpässen im Betrieb sinnvoll oder bei punktueller Expertenunterstützung, beispielsweise bei Migrationsvorhaben.
**Betriebskontingent-Service als Managed Services**
Mit dem Modell Betriebskontingent-Service als Managed Services wird der Betrieb verstärkt durch den IT-Dienstleister unterstützt. Der Dienstleister stellt je nach den Bedürfnissen des Unternehmens ein Team zur Verfügung und konkrete Unterstützungsleistungen werden individuell zu einem Service zusammengefasst und als Kontingent angeboten. So ist es denkbar, dass ein Team dem Unternehmen mit einer gewissen Personalkapazität und speziellen Skills in gewissen Servicezeiten zur Verfügung steht. Dabei kann das Unternehmen je nach Bedarf die Personalkapazität skalieren und zusätzliche Services geliefert bekommen, z. B. Usability Engineering und Architekturberatung. Die Verantwortlichkeit für den Betrieb (z. B. Hoheit über den Betriebsprozess, Vorgehen und Applikationsstrategie,“¦) bleibt aber weiterhin beim Unternehmen.
**Application Management als Managed Services**
Bei dem Engagement Modell Application Management als Managed Services liegt die Verantwortung für den Betrieb der Infrastruktur und/oder Anwendung beim Dienstleister. Eine Möglichkeit können die Managed Services Infrastruktur (OC|MSI®) sein. Hiermit wird die Wartung und Weiterentwicklung der Infrastruktur vom Dienstleister anhand definierter Service Level Agreements (SLA) sichergestellt. Oder aber die Leistung Managed Services Applications (OC|MSA®), welche die Wartung und Weiterentwicklung der Individualsoftware anhand definierter SLA im Fokus hat. Dabei sind alle Kombinationen als Managed Services denkbar:
- Sicherstellung des Betriebs der Infrastruktur mit oder ohne Sicherstellung des Betriebs der Anwendung
- Sicherstellung des Betriebs der Anwendung mit oder ohne Sicherstellung des Betriebs der Infrastruktur
**Custom Software as a Service (Custom SaaS) als Managed Services**
Bei dem Modell Custom Software as a Service liegt die Verantwortung für die Infrastruktur und Anwendung beim Dienstleister. Bei diesem Service wird zunächst die Entwicklung der Applikation auf Basis der Kundenanforderung auf einer Cloud-basierten Plattform umgesetzt. Der Betrieb der Applikation geschieht als Managed Services für Infrastruktur und Anwendung und der Kunde erhält eine maßgeschneiderte Software.
## Managed Services „“ Development
Möchte ein Unternehmen eine neue individuelle Softwarelösung realisieren, gibt es auch verschieden Möglichkeiten der Zusammenarbeit. Auch hier hat je nach Ausprägungsform das Unternehmen oder der Dienstleister die Verantwortung für das Erstellen der Lösung:
**Dienstleistung für Software Development und Beratung**
Mit dem Modell Dienstleistung für Software-Development und Beratung erhält das Unternehmen die Möglichkeit Expertenwissen z. B. für die Umsetzung seiner Applikation einzukaufen und kann auf entsprechende Berater zugreifen. Die Lösungsverantwortung trägt aber weiterhin der Kunde.
**Development-Kontingent-Service als Managed Services**
Bei dem Development-Kontingent-Service als Managed Service erhält ein Unternehmen z. B. in definierten Zeiten ein garantiertes Kontingent an Entwicklungskapazitäten. Dabei stellt der Dienstleister dem Kunden ein garantiertes Development-Kontingent zur Verfügung, welches ein zuvor definiertes technisches und methodisches Skillset und ein kundenspezielles fachliches und technisches Know-how umfasst. Die Verantwortung für die Erstellung der Lösung bleibt weiterhin beim Kunden. Der Dienstleiter garantiert aber die Projektkapazität durch ein Development-Kontingent mit den definierten Services.
**Individuelle Lösung als Gewerk**
Beim Engagement-Modell Individuelle Lösung als Gewerk garantiert der Dienstleister die Umsetzung der Anforderungen des Kunden. Die Lösungsverantwortung für die Applikation trägt der Dienstleister.
## Fazit
Wir stellen bei unseren Kunden fest, dass wir viele grundlegende Probleme mit unseren Managed-Services-Modellen lösen können. So ist im Bereich Managed Services „“ Operation das Engagement Model Betriebskontingent-Service als Managed Services besonders gefragt. Aber auch das klassische Application Management als Managed Services ist für viele Kunden interessant. Im Bereich Managed Services „“ Development ist das Development-Kontingent-Service als Managed Services eine gute Möglichkeit, die Entwicklungskapazität abzusichern und weitere Services bei Bedarf abzurufen (beispielsweise [Mobile Team as a Service](https://thecattlecrew.net/2017/07/07/mobile-team-as-a-service/)). Darüber hinaus entwickeln wir mittlerweile ganz neue Service-Modelle, wie z. B. Innovation Lab as a Service (ILaaS). Hier erhalten Unternehmen die Möglichkeit, ihr digitales Labor als Service zu nutzen. Der Kunde kann so beim Aufbau und bei der Evaluierung neuer digitaler Geschäftsmodelle das OC|Lab® nutzen und innovative Ansätze durch Machbarkeitsstudien, Proof of Concepts oder Prototyping eruieren.
In den nächsten Blog-Einträgen, möchten wir für die unterschiedlichen Engagement-Modelle darstellen, warum unsere Kunden, welches Model auswählen. Wo lagen ihre Probleme und wie können diese mit welchem Modell gelöst werden?
Für mehr Informationen zu unseren Angeboten zum Thema Managed Services kontaktieren Sie gerne unser Competence Center Managed Services ().
## Quellen & Weiterführende Informationen:
[http://www.opitz-consulting.com/fileadmin/user\_upload/Collaterals/Fact\_Sheet/39-factsheet-oc-msa\_sicher.pdf](http://www.opitz-consulting.com/fileadmin/user_upload/Collaterals/Fact_Sheet/39-factsheet-oc-msa_sicher.pdf)
[http://www.opitz-consulting.com/fileadmin/user\_upload/Collaterals/Fact\_Sheet/35-factsheet-managed-service-infrastructure-msi\_sicher.pdf](http://www.opitz-consulting.com/fileadmin/user_upload/Collaterals/Fact_Sheet/35-factsheet-managed-service-infrastructure-msi_sicher.pdf)
[http://www.opitz-consulting.com/fileadmin/user\_upload/Collaterals/Fact\_Sheet/75-factsheet-oc-lab.pdf](http://www.opitz-consulting.com/fileadmin/user_upload/Collaterals/Fact_Sheet/75-factsheet-oc-lab.pdf)
**Kategorien:** Tools & Methoden
---
### [Managed Services "“ eine Alternative zur Arbeitnehmerüberlassung](https://thecattlecrew.net/2018/04/09/managed-services-eine-alternative-zur-arbeitnehmerueberlassung/)
**Published:** April 9, 2018
**Author:** inesmoeckelopitzconsultingcom
**Content:**
### **Was ist ANÜ überhaupt?**
Alle reden von ANÜ. Nur warum? Und was ist das überhaupt?
Grundsätzlich liegt eine ANÜ (Arbeitnehmerüberlassung) dann vor, wenn Arbeitnehmer (Leiharbeitnehmer) von einem Arbeitgeber (Verleiher) einem Dritten (Entleiher) gegen Entgelt für begrenzte Zeit überlassen werden. Rechte und Pflichten eines Arbeitgebers übernimmt der Verleiher und der Leiharbeitnehmer steht weiterhin in einem Arbeitsverhältnis zum Verleiher. Den rechtlichen Rahmen hierfür bildet das „Gesetz zur Regelung der Arbeitnehmerüberlassung“ (AÜG).
Mit der Reformierung zum 01.04.2017 traten einige Ü„nderungen in Kraft, die Auswirkungen mit erheblichen Nachteilen auf verschiedene Auftragsformen in der IT haben.
Darstellung: Was ist Arbeitnehmerüberlassung?
### **Nachteile von ANÜ**
Welche Nachteile sind das?
Ein Mitarbeiter, der per ANÜ bei einem Kunden im Einsatz ist, muss nach spätestens 18 Monaten den Kunden wechseln. Mit jedem Wechsel geht dem Kunden Projekt-Know-how verloren, das Mitarbeiter in der IT-Branche im Projektkontext aufbauen. Daraus resultiert, dass mit jedem neuen Mitarbeiter eine erneute Einarbeitung erforderlich wird. Dies belastet jedes Projekt und wirkt sich auch auf den Projekterfolg aus.
Ein weiterer Nachteil ist, dass über ANÜ nicht so einfach skaliert werden kann, wenn der Bedarf besteht, weil für jeden Mitarbeiter die ANÜ vertraglich transparent geregelt werden muss. Jeder neue Vertrag benötigt Zeit für die Abstimmung mit den Mitarbeitern (Wer ist der Richtige? Passt er ins Team? Wie lange werde ich ihn brauchen? Will er per ANÜ arbeiten? …)
Ein weiteres Problem ist die Themenvielfältigkeit in den Projekten. Ich bin mit den Projektaufgaben an das Know-how der Mitarbeiter gebunden, die ich per ANÜ entliehen habe. Was passiert, wenn temporär neue oder andere Aufgaben entstehen und damit andere Skills benötigt werden? Mit dem aktuellen Mitarbeiter bin ich zufrieden, kann ihn in den nächsten Wochen nur nicht auslasten, da seine Skills nicht passen. Ich benötige diesen Mitarbeiter jedoch später wieder für den Projekterfolg.
### **Managed Services als Antwort**
Unsere Antwort auf die Nachteile, die sich mit der ANÜ ergeben sind „“ Managed Services. Trotz des temporären Einsatzes unserer Experten im Unternehmen eines Kunden, grenzen sich OC|Managed Services deutlich von Arbeitnehmerüberlassungen (ANÜ) „“ auch als Leiharbeit bekannt „“ ab. Managed Services bergen somit kein Risiko, in die Falle einer unerlaubten Arbeitnehmerüberlassung zu tappen, die häufig im IT-Projektgeschäft vorgefunden wird.
Zunächst sind die Mitarbeiter von OPITZ CONSULTING in der Regel nicht immer vor Ort bei den Kunden, arbeiten mit ihren eigenen Arbeitsmitteln, die sie nicht vom Auftraggeber gestellt bekommen, sondern nutzen eigene Hardware. Über Remote Zugänge und Offsite-Arbeitsplätze lassen sich die Aufgaben in Eigenregie bearbeiten.
Unsere Mitarbeiter sind zudem nicht in die Arbeitsabläufe und Prozesse der Kunden eingegliedert.
Die beiden letztgenannten Punkte führen oft dazu, dass eine Leistung als ANÜ gewertet wird
Die Erfüllung der vertraglichen Verpflichtungen, die häufig in SLAs gemessen werden, erfolgen selbstorganisiert durch die Mitarbeiter und nicht auf Weisung des Auftraggebers.
Die Vertragspflicht im Rahmen eines Managed Services endet im Vergleich zur Arbeitnehmerüberlassung nicht mit der Auswahl und Zurverfügungstellung eines Arbeitnehmers und nach 18 Monaten, sondern wir schulden die Erfüllung eines Services.
Die eingesetzten Arbeitnehmer sind als Erfüllungsgehilfen zu betrachten und unterliegen weiterhin den Weisungen von OPITZ CONSULTING. Der sogenannte Dritte in diesem Verhältnis, also unser Kunde, kann jedoch entsprechend § 645 Abs. 1 Satz 1 BGB dem Unternehmer oder seinen Erfüllungsgehilfen sogenannte werk-/objektbezogene Anweisungen für die Werkserstellung erteilen. Gleiches gilt bei Dienstverträgen.
Ein weiterer Vorteil liegt in der flexiblen Skalierung: Bei unseren Services werden keine dedizierten Mitarbeiter verliehen, sondern ganze Teams. Je nach Thema und Dringlichkeit können also weitere Mitarbeiter hinzugezogen werden. Dies sichert eine qualitativ hochwerte Erfüllung. Getreu dem Motto: „Die Richtige für das richtige Problem.“ sorgen wir für das entsprechende Know-how und dessen Verfügbarkeit.
Managed Services stellen also tatsächlich Services dar, die wir dem Kunden anbieten und kein Verleihen von Mitarbeitern.
**Kategorien:** Tools & Methoden
---
### [Leb wohl RAC! Hochverfügbarkeit in der Oracle 19c SE2](https://thecattlecrew.net/2019/07/03/leb-wohl-rac-hochverfuegbarkeit-in-der-oracle-19c-se2/)
**Published:** Juli 3, 2019
**Author:** Rainier Kaczmarczyk
**Content:**
Mit Version 19c hat Oracle die Real Application Cluster (RAC) Option aus der Standard Edition 2 genommen. Ein solches Vorgehen hatte sich im Vorfeld bereits angekündigt, da mit der Standard Edition 2 die Anzahl der erlaubten Threads pro Knoten auf 8 beschränkt wurde. Damit war ein 2-Knoten-RAC-System, bedingt durch den verwaltungstechnischen Overhead, bereits weniger leistungsfähig als ein vergleichbares Single Instance System, das auf 16 Threads limitiert ist.
Viele Anwender setzten in der Vergangenheit, wenn es um Hochverfügbarkeit ging, genau auf den Einsatzes der RAC Option. Für die Zukunft entfällt diese Möglichkeit ersatzlos. Oracle bietet, im Gegensatz zu Dataguard in der Enterprise Edition, in der Standard Edition 2 keinerlei auch nur annähernd ähnliche Option an.
Was nun?
Da der Anwender auf interne Mechanismen, die Dataguard verwendet, nicht zugreifen kann bzw. darf, bleibt nur die altbewährte Methode: die Verwendung eines Standby Systems, basierend auf der Oracle Backup/Recovery-Technologie. Eine solche Implementierung wird als physikalische Replikation bezeichnet.
Ein solches System kann durch selbstgeschriebene Skripte realisiert werden. Der Aufwand steht in keinem Verhältnis zum Nutzen.
Ein Partner von uns bietet ein Produkt an, das genau in diese Bedarfslücke passt und mit dem ich in diesem Umfeld schon sehr gute Erfahrungen machen durfte. Dbvisit Standby ist eine einfach zu bedienende Lösung , um eine effiziente und zuverlässige Hochverfügbarkeit in der Oracle Standard Edition 2 abzubilden. Zudem kann Dbvisit Standby, im Gegensatz zu einem RAC System, sowohl über weite Entfernungen, als auch ganz oder teilweise als hybride Lösung in der Cloud implementiert werden.
Mit Dbvisit Standby kann mittels eines sog. Switchover vom Primärsystem auf das Standbysystem innerhalb weniger Minuten ohne Datenverlust umgeschaltet werden. Es erfolgt ein Rollentausch beider Systeme.
Im Katastrophenfall, d. h. falls das Primärsystem durch äußere Einflüsse oder auf Grund von Hard- bzw. Softwareproblemen nicht mehr verfügbar sein sollte, kann durch das Aktivieren des „überlebenden“ Standby Systems ein Weiterbetrieb der Datenbank mit einem geringen Datenverlust (in der Regel weniger als 5 Minuten) gewährleistet werden.
Wenn in Oracle 19c Standard Edition 2 eine Hochverfügbarkeit weiterhin gewährleistet werden soll, ist Dbvisit Standby eine einfache und kostengünstige Lösung.
Falls Sie Interesse an einer Demo oder eine testweisen Implementation von Dbvisit Standby haben, kommen Sie gerne auf mich zu.
**Kategorien:** Infrastructure
**Schlagwörter:** Hochverfügbar, oracle
---
### [Catastrophic slow backup/restore to Oracle Cloud Infrastructure Object Storage and its fix](https://thecattlecrew.net/2020/08/28/catastrophic-slow-backup-restore-to-oci-object-storage-and-its-fix/)
**Published:** August 28, 2020
**Author:** Bartlomiej Sowa
**Content:**
I used Oracle Zero Downtime Migration Tool to move some databases from OnPrem Exadata to a freshly instantiated OCI Exadata Cloud Service (Quarter Rack to be more precise). I found out then, that the speed and performance of backup and restore to OCI Object Store was more than catastrophical. Instead of advertised ~2,5h for a 5 TB big database over 8 channels, the restore took… more than 20 hours!
The backup was not as fast due to connection speed limit, but I assumed that at least within OCI, the restore should run as advertised in [Oracle Cloud Infrastructure Exadata Backup & Restore Best Practices using Cloud Object Storage](https://www.oracle.com/technetwork/database/availability/oci-exa-br-bp-objectstore-5573845.pdf). I was really astonished when I saw that.
I opened an SR of course, but after more than 20 days of ping-pong with Oracle eventually found the reason myself.
You see – ZDM comes with the libopc.so in version 19.0.0.1. This is exactly the same version that is included in every ORACLE\_HOME in lib subdirectory. You can easily get the version string with following command:
```
[zdm@zdm lib]$ strings libopc.so.original | grep -Po 'DNZ_REL_VER=".*?"' | head -1
DNZ_REL_VER="19.0.0.0.0-Production"
```
On the ExaCS I found, that even for 19.7 database home, the `libopc.so` that is used for automatic backup and bkup\_api is actually an older version, the 12.2.0.1, and it is located under `/var/opt/oracle/dbaas_acfs//opc/libopc.so`
```
[oracle@exa1-node1 ~]$ strings /var/opt/oracle/dbaas_acfs//opc/libopc.so | grep -Po 'DNZ_REL_VER=".*?"' | head -1
DNZ_REL_VER="12.2.0.1.0-Production"
```
I tested both with RMAN running a backup. For that I used a slightly modified SQL (thanks to Mariami Kupatadze) [Script](https://dba010.com/2017/01/17/rman-displaying-current-backup-progress/):
```
select recid
, output_device_type
, dbsize_mbytes
, input_bytes/1024/1024 input_mbytes
, output_bytes/1024/1024 output_mbytes
, (output_bytes/input_bytes*100) compression
, (mbytes_processed/dbsize_mbytes*100) complete
, to_char(start_time ,'DD-MON-YYYY HH24:MI:SS') started
, to_char(start_time + (sysdate-start_time)/(mbytes_processed/dbsize_mbytes),'DD-MON-YYYY HH24:MI:SS') est_complete
from v$rman_status rs
, (select sum(bytes)/1024/1024 dbsize_mbytes from v$datafile)
where status like 'RUNNING%'
and output_device_type is not null;
```
The results for a 5TB big database were astonishing. First the 12.2.0.1 lib version:
```
RECID OUTPUT_DEVICE_TYP DBSIZE_MBYTES INPUT_MBYTES OUTPUT_MBYTES COMPRESSION COMPLETE STARTED EST_COMPLETE
---------- ----------------- ------------- ------------ ------------- ----------- ---------- ----------------------------- -----------------------------
8197 SBT_TAPE 4911385.78 162145.547 60951.75 37.5907641 3.30142152 28-AUG-2020 10:08:18 28-AUG-2020 12:37:14
```
(scroll right and look at STARTED and EST\_COMPLETE). I aborted the backup after few moments as it was already at 3%.
Then I started again the same full database backup, but this time with the 19.x version of libopc.so. I had to wait multiple minutes to get to 0.7% to have at least some kind of representative estimation. And there it is:
```
RECID OUTPUT_DEVICE_TYP DBSIZE_MBYTES INPUT_MBYTES OUTPUT_MBYTES COMPRESSION COMPLETE STARTED EST_COMPLETE---------- ----------------- ------------- ------------ ------------- ----------- ---------- ----------------------------- ----------------------------- 8201 SBT_TAPE 4911385.78 35671.0469 13269.5 37.1996371 .726292913 28-AUG-2020 10:17:34 29-AUG-2020 07:17:23
```
So, there you have it. 2,5 hours versus nearly 21 hours. Both over 8 Channels, both within OCI, same bucket, same Database, same Exadata.
Ps. Both libraries seem to consume really a lot CPU, so consider this choosing the number of channels. 19.x version uses 100% CPU for each channel thread. The 12 Version showed around 70-90% CPU for each channel. So see, that you have enough free CPUs in your Exadata Node to run given number of channels.
**Kategorien:** Cloud, Infrastructure
**Schlagwörter:** backup, cloud, ExaCS, Exadata Cloud Service, libopc.so, low, OCI, oracle, Performance, rman, slow, ZDM, Zero Downtime Migration
---
### [Manually catalog backup pieces in Oracle Object Storage (OSB)](https://thecattlecrew.net/2020/10/06/manually-catalog-backup-pieces-in-oracle-object-storage-osb/)
**Published:** Oktober 6, 2020
**Author:** Bartlomiej Sowa
**Content:**
Typically, when working Oracle Secure Backup / libopc you should in general have an RMAN Catalog. Just to be on the safe side. But what if you do not have it and would like to just catalog all backups in OSS Bucket as you could do with CATALOG START WITH? It is not possible to do CATALOG START WITH for the device SBT\_TAPE.
But there is hope – oracle allows you to do „CATALOG DEVICE\_TYPE ’sbt\_tape‘ BACKUPPIECE ‚xxxx'“ – you „just“ need to know the names of all backup pieces…
Luckilly the repository structure is not as complicated as one could think and it is pretty simple to get all piece names out of Oracle Object Storage (OSS) in a script-friendly matter.
You would need to have the OCI Commandline tool configured (~/.oci/config – see [docs](https://docs.cloud.oracle.com/en-us/iaas/Content/API/SDKDocs/cliinstall.htm)) and [jq](https://stedolan.github.io/jq/) installed.
with configured oci cli, just enter the following command as one line:
```
oci os object list --all -bn | jq -r '.data[].name|select(test("sbt_catalog.*"))|split("/")[1]|("catalog device type '\''sbt_tape'\'' backuppiece '\''"+.+"'\'';")' > catalog-backup.sql
```
Then feed the generated script into RMAN, ideally inside a run block (for performance). Works fastest with PARALLELISM on SBT\_TAPE configured to 1.
```
rman target /
RMAN> RUN {
@catalog-backup.sql
}
...
RMAN> list backup summary;
```
It should be easily possible to adjust the JQ code to work with AWS S3 Object Store and OSB module.
**Kategorien:** Cloud, Infrastructure
**Schlagwörter:** backuppiece, catalog, cloud, libopc, OCI, oracle, Oracle Cloud, oracle secure bacup, OSB, rman, sbt_tape
---
### [Dbvisit Standby Version 10 ist da!](https://thecattlecrew.net/2021/01/22/dbvisit-standby-version-10-ist-da/)
**Published:** Januar 22, 2021
**Author:** Rainier Kaczmarczyk
**Content:**
 Auch wenn schon für Dezember letzten Jahres angekündigt, hat die neue Version von Dbvisit Standby nun im Januar „das Licht der Welt“ erblickt.
Warum so spät? Ich denke, dass sich die Mütter und Väter dieser Version nicht drängen haben lassen wollen. Qualität geht vor. Erste Tests bestätigen das.
Was ist herausgekommen? Eine würdige Nachfolge von Version 9!
Was ist neu? Neben vielen anderen, zwei wichtige neue Funktionen!
- Vollständige Unterstützung der Pluggable Database mit bis zu drei Datenbanken in der Oracle Standard Edition.
- Möglichkeit, die Standby Datenbank als Reporting Datenbank (Dbvisit Snapshots Option) nutzen zu können.
Bisher konnte man die Standby Datenbank zu „nichts“ gebrauchen. Sie war da, kostete nur Geld in Form von Strom, Hardware und Lizenzen. Zumindest bot sie Sicherheit.
Mit der Snapshot Option ist das anders. Und die kostet nichts extra. Sie ist Teil der Lizenz.
Wie funktioniert das ganze? Wie der Name schon sagt, basiert das ganze Konzept auf der Basis von (Linux) Snapshots. Daher, leider, gibt es diese Funktion nur auf Linux basierenden Systemen. Jedenfalls derzeit.
Es wird in einem selbst zu definierenden Intervall ein Snapshot der existierenden Standby Datenbank erzeugt (read-only). Es kann auch ein zweiter oder dritter Snapshot gezogen werden (diese werden in einem „round-robin“ Verfahren ständig neu erzeugt).
Man könnte die Dbvisit Snapshot Option auch als das kleine Pendant von Oracle Active Data Guard bezeichnen.
Damit kann die Standby Datenbank für Test- und Berichtszwecke oder ähnliches verwendet werden.
Neugierig?
Für Rückfragen und Kommentare bin ich immer offen!
Rainier Kaczmarczyk
PS:
OPITZ CONSULTING ist mit Stand heute (22.01.2021) (www.dbvisit.com) der einzige zertifizierte Partner für die Snapshot Option in Deutschland.
**Kategorien:** Infrastructure
**Schlagwörter:** datenbank, Dbvisit, Hochverfügbarkeit
---
### [Dbvisit Standby MP: Von der Evolution zur Revolution](https://thecattlecrew.net/2022/02/03/dbvisit-standby-mp-von-der-evolution-zur-revolution/)
**Published:** Februar 3, 2022
**Author:** Rainier Kaczmarczyk
**Content:**
Die Evolution:
Dbvisit Standby steht seit über 15 Jahren für die Hochverfügbarkeit von Oracle Datenbanken (vor allem Standard Edition).
Das Produkt ist mehr als ausgereift. Das ist die Evolution.
Die Revolution:
Dbvisit Standby MP — Die MultiPlatform!
Nicht mehr nur Oracle als Datenbank wird unterstützt, sondern neu ist der Support für Microsoft SQL Server.
In einer integrierten Weboberfläche können in Zukunft sowohl Oracle, als auch SQL Server in Punkto Hochverfügbarkeit administriert werden.
MultiPlatform bedeutet „mehr als Eins“. Weitere Datenbanken werden folgen! Kenner der Szene ahnen schon welche.
Eine Testversion kann unter www.dbvisit.com heruntergeladen werden.
Kommentare und auch Rückfragen: Gerne.
**Kategorien:** Infrastructure, Tools & Methoden
**Schlagwörter:** Dbvisit, Hochverfügbarkeit, oracle, SQL Server, Standby
---
### [Published CattleCrew Case Management UI](https://thecattlecrew.net/2017/02/23/published-cattlecrew-case-management-ui/)
**Published:** Februar 23, 2017
**Author:** Halil Hancioglu
**Excerpt:** As a result of our case management experience, we recently released a self-developed case management UI on GitHub to get a better introduction to case management and CMMN 1.1.
**Content:**
As a result of our case management experience, we recently released a self-developed case management UI on GitHub to get a better introduction to case management and CMMN 1.1.
In addition to the traditional process and rules management, Case Management has established itself as the third standard in the BPM standard Toolkit. Case management is particularly suitable for dynamic business processes, which have a high variance in execution. What BPMN represents for traditional process models is the CMMN standard for case management.
The CattleCrew Case Management UI has emerged from the idea of providing an easy introduction to the topic with tool support. We decided for a UI because during our first attempts we noticed that an optimized user interface is a central element for case management. In order to promote the topic with the help of the community, we have published it on GitHub.
# **Try it out**
After following the [instructions](https://github.com/opitzconsulting/cattlecrew-case-management-ui#try-it-out) on GitHub and invoking the user interface, the overview page opens. By selecting a case you get to the detailed view.
Dashboard
In the detail view, all the context informations about the current case are displayed in four columns to support the knowledge worker with required information. This includes case“™s history, information from comparable or related cases, and existing documents.
In the first column of the left the navigation search functionality for similar or related cases is placed. Below all the associated documents are displayed. In the second column from the left, relevant context information are listed. In the third column you can see the status of the case and what happened so far. The right column shows the activities that can be executed or are currently being processed.
Case Details
Behind the second tab, the rendered case model is displayed.
Case Model
Behind the third tab, DMN tables with the input and output parameters are displayed . In the current version, these are displayed only if a BPMN process was started from the case that references a DMN table.
Decision History
The fourth tab shows the data you’ve determined and is especially useful for the developer.
Raw Case Data
By selecting the „New Case“ button in the main navigation, a new case can be started.
New Case
All existing cases in the process engine are listed. After the selection of a case a business key and process variables can be added.
New Case with Process Variables
As soon as a case has been started, you will be directed to the overview page, where the newly started case is also visible.
## **Used process engine**
The project requires the Camunda BPM Process Engine. Camunda BPM is one of the first software vendorsthat has integrated CMMN 1.1 into their process engine and also provides a corresponding modeller. Since Camunda 7.6, the „CMMN Monitoring“ feature is also included in the Enterprise version.
CattleCrew Case Management UI is flexible designed so that the engine specific implementation can be replaced by another to test the UI with other process engines. In the following figure, the layers are shown in an abstract manner.
Technical Birdview
The project can be found on GitHub at . There is also an installation manual. The QR code is
QR-Code
Of course, you are invited to participate to this project, too. If you are interested, please contact us.
Have fun on experimenting with case management and CMMN!
Feedback is always welcome 😉
**Kategorien:** Architecture & Process Models, Development
**Schlagwörter:** ACM, BPM, Camunda, Integration, Modern Clients, Web Developement
---
### [Angular: Release of version 4](https://thecattlecrew.net/2017/07/11/angular-release-of-version-4/)
**Published:** Juli 11, 2017
**Author:** pascalmhumbert
**Content:**
When Angular version 4 was released in March 2017, people wondered „What has happened to version 3?“ And another question of particular concern for (us) developers was „What is new in Angular version 4?“ In this article we address these questions.
## Semantic versioning
In order to answer the first question why Angular version 3 has been omitted let us take a look at the versioning convention adopted by the Angular development team. According to Igor Minar in the [opening keynote for version 4](https://www.youtube.com/watch?v=aJIMoLgqU_o), the Angular team uses *semantic versioning* for their releases. By means of the illustration shown in Fig. 1, we explain in the following how this system works.
**Fig. 1:** Example of semantic versioning for Angular releases. Release cycles are indicated.The version specification consists of three numbers: one for major versions, one for minor versions and, lastly, one for patches. A patch is supposed to introduce no new features or breaking changes to Angular. A minor version change can feature new functionalities but no breaking changes. A major version release typically entails new features and potentially breaking changes. As indicated by Fig. 1, new patches are released every week, minor versions every month and major versions every half year.
The reason for skipping version 3 is quite subtle. While all but one Angular module were still at major version number 2, the routing module had already advanced to version 3. Eventually, the Angular team desired to have consistent version numbers for all modules. Hence, when the next major release was due, all modules jumped to version 4. Thus, Angular version 3 was omitted. Also, the development team decided to suppress the version number in the name (as it is going to change every half year, anyway,) and just call the framework „Angular“.
## New features in version 4
In this part we talk about what is new in Angular version 4. Note that we do not discuss passive changes like the enhanced performance of the angular-cli or the better compression rate for the distributed app. Instead we demonstrate the appliance of three new features in version 4. These are the new \*ngIf, the new possibility to introduce local variables via the *as* keyword and the email validator.
### The new \*ngIf
Since version 4 the *\*ngIf* statement can be extended by a *then* and an *else* statement, both optional. To see how the new \*ngIf works, first, let us take a look at Listing 1 below.
\[code language=“html“ firstline=“1″\] This text is only visible if the condition is *true*.
This text is only visible if the condition is *false*.
\[/code\]**Listing 1:** Example of how the \*ngIf statement used to be formulated in version 2.
Consider that in an Angular component we have a boolean *condition*. In our app we want to display different content depending on whether the condition evaluates to *true* or *false*. As shown in Listing 1, in version 2 this was realized by having two separate DOM elements, one checking for *condition* and the other for *!condition* — but wait, this feels a little clumsy. If we test *condition* in line 1 why do we have to repeat this step in line 5 again?
Now, since version 4, we can solve this in a more elegant way as illustrated in Listing 2. The html code snippet shown there does the same as the one in Listing 1, only it extends the \*ngIf statement with an else statement to get the result we want. In this example the *elseBlock* defines which content is to be displayed if the condition evaluates to *false*. Note that this content must be encapsulated in an *ng-template* element. In line 5 we also register this element as „elseBlock“ in the DOM (via #elseBlock). Interestingly, the angular-cli does not care *where* the elseBlock is declared in the html. Instead the element with the \*ngIf expression serves as an outlet for the conditional content.
\[code language=“html“ firstline=“1″\] This text is only visible if the condition is *true*.
This text is only visible if the condition is *false*.
\[/code\]**Listing 2:** Example of an \*ngIf-else statement featured since version 4.
Finally, in Listing 3, we show an example of an if-then-else statement. In addition to the elseBlock we had before, we now also include a thenBlock. This block is displayed if the condition evaluates to *true*. It is apparent that the thenBlock works in a similar way as the elseBlock. However, it is important to notice that, if a then statement is included into the \*ngIf expression, the content of the element attached to the \*ngIf is completely ignored (as statet in line 2 of Listing 3).
\[code language=“html“ firstline=“1″\] This part is completely ignored, now.
This text is only visible if the condition is *true*.
This text is only visible if the condition is *false*.
\[/code\]**Listing 3:** Example of an \*ngIf-then-else statement featured since version 4.
Let us summarize what we have learned in this section. With the new \*ngIf we can handle the evaluation of a boolean expression in only one line (cf. Listing 3, line 1). This element is used as outlet for the conditional content. By means of (optional) then and else blocks, which need be embedded in ng-template elements, we can keep our DOM tidy and well organized.
### Create local variables with the *as* keyword
Another new feature is the possibility to define a local variable using the *as* keyword. In the example in Listing 4 we label the *index* parameter inherent to \*ngFor *as idx* and insert it in the subsequent line with one-way data binding. The *as* keyword is also quite useful to relabel (lengthy) variable names in order to make our html code cleaner. Another nice application of the *as* keyword in combination with asynchronous data loading is described in [this article](https://juristr.com/blog/2017/06/new-enhanced-ngIf-and-ngFor/).
\[code language=“html“ firstline=“1″\] {{idx}}. {{item}}
\[/code\]**Listing 4:** Example of an appliance of the *as* keyword featured since version 4.
### The new email validator
In many forms an email address is required. Formerly, validity of the address needed be checked against a manually written regex. Since version 4 we can now use the email validator as illustrated in Listing 5 (the validator is the last occurrence of the word „email“). Validating an email address never has been that easy!
\[code language=“html“ firstline=“1″\]
\[/code\]**Listing 5:** The new email validator featured since version 4.## Conclusion
Angular version 4 has brought a lot of improvement in terms of performance of the framework. Many new features like the new \*ngIf, the *as* keyword and the email validator discussed in this article have been introduced to make our life as programmers easier and to help us to keep our code cleaner. With major version releases every six months we are looking forward for many new features yet to come.
**Kategorien:** Development
**Schlagwörter:** Angular
---
### [React vs. Angular - When to Choose Which?](https://thecattlecrew.net/2017/11/01/react-vs-angular-when-to-choose-which/)
**Published:** November 1, 2017
**Author:** Stephan Rauh
**Content:**
A couple of days ago, Marius Hofmeister and I held a talk about „Angular vs. React“ at the International JavaScript conference iJS at Munich. Which one is better, Angular or React?
Truth to tell, we can’t answer the question. Actually, it’s the wrong question, anyway. The real question is „Which one is better for my project?“
## It depends!
Because that’s what we found out during our investigation: During the last couple of years, Angular and React have learned a lot from each other. Each team is watching the progress of the other team. Good ideas tend to be adopted by the other team after a while, provided they match the general philosophy of the framework.
So we came to believe you can do anything with either framework. We’ve collected a couple of technical criteria helping you choose the right tool for the job. But you should base your decision on technical considerations alone.
## Take performance, for example
For instance, we’ve been frequently asked about performance. Raw speed seems to be an important topic to JavaScript developers. The answer of React.js is: „We’re the fast ones“, and I’m tempted to believe them. On the other hand, the Angular answer is „We’re fast enough. Plus, we’re rapidly catching up!“
That matches my personal experience, too. Granted, there are use cases requiring as much performance as you can get. But these are corner cases. More often than not, being fast enough is all you need.
## Ask your team!
Cutting a long story short, we identified a couple of technical considerations you should take in mind. But there are more important topics. I’ve never seen a project failing because of technical problems. But I’ve seen a lot of projects failing because of human factors. So you should ask your team. If your team members have a lot of experience with JavaScript, choose React. If they prefer functional programming over object-oriented programming, choose React. If you’ve got a large web page containing lots of interactive elements, each interacting with each other, choose React.
On the other hand, if you’re coming from a Java or C# background, choose Angular. If you’re working for a big enterprise, developing an application consisting of hundreds of forms, you’ll prefer Angular. If you feel familiar with TypeScript after an hour, choose Angular.
## Wrapping it up
You get the idea. Most discussions in the blogosphere are sort of misleading. They concentrate on their pet topics: „I hate TypeScript!“ or „I need performance!“. Take them with a grain of salt. Maybe the [slides of our talk](https://www.beyondjava.net/blog/images/slides/Angular-vs-React-Rauh-Hofmeister-IJS.pdf) help you. Plus, you may be interested in [our interview with Jaxenter.com](https://jaxenter.com/angular-5-vs-react-interview-138469.html). It provides you with some additional information neither this article nor our slides cover.
There’s also [my previous article comparing Angular with React](https://www.beyondjava.net/blog/ui-roundup-2017-angular-vs-react/) on BeyondJava.net. Not that I’ve published the article during our research phase, so I’m sure it has a couple of issues. Even so, it contains some additional info that didn’t make it into the final slides.
**Kategorien:** Development
**Schlagwörter:** JavaScript
---
### [GraphQL Demo (3/8) - Dataloader und Batching](https://thecattlecrew.net/2018/08/30/dataloader-und-batching/)
**Published:** August 30, 2018
**Author:** Manuel Styrsky
**Content:**
Der Dataloader stellt Batching und Caching zur Verfügung. Entwickelt wurde er von Facebook. Wir haben ihn für das Batching eingesetzt, so werden nun verschiedene Anfragen, die mit den Chatnachrichten laden, zu einer Anfrage zusammenführt, die dann an die Datenbank gestellt wird. Die geladenen Daten werden im Dataloader gecacht und können später ohne Datenbankzugriff geladen werden.
### **Lizenzierung**
Der Dataloader darf kostenfrei verwendet werden, sofern man die Copyright-Notiz von Facebook beibehält und für Facebook durch die Verwendung keinerlei Schaden entsteht. Genaueres [hier](https://github.com/facebook/dataloader/blob/master/LICENSE).
### **Wie man den Dataloader einsetzt**
Wir haben unsere Beispielanwendung in TypeScript geschrieben. Demnach sind auch folgende Codefragmente in TypeScript gehalten.
1. Vorausetzungen: Der Dataloader setzt derzeit eine JavaScript-Umgebung voraus, welche die Features von globalen ES6-Promises- und Map-Klassen unterstützt.
2. Den Dataloader im Projekt installieren:
> npm install –save dataloader
3. Dataloader in der Klasse verfügbar machen:
> let DataLoader = require (‚dataloader‘);
4. Jeder Batch benötigt einen eigenen Dataloader. Ein Dataloader bekommt als Argument eine Funktion, die die entsprechenden Schlüssel über die Batch-Funktion auf die Ergebnisse mappt:
> let messageLoaderForUsers = new DataLoader((ids:any) =>
> batchMessagesUser(ids));
5. Der Kern liegt in der Batch-Funktion. Sie bekommt mehrere IDs und lädt diese alle auf einmal aus einer Datenbank oder anderen Datenquelle. Sie gibt ein Dictionary zurück, welches als Schlüssel die ID und als Value die geladenen Daten liefert:
> async function batchMessagesUser(ids: number\[\]) {
> //Messeges from the given authors are filtered
> let messages = await Message.findAll({
> attributes: \[‚id‘, ‚authorId‘\],
> where: {authorId: { $in: ids }}
> });
>
> //messages are grouped by author
> const groupedMessages = \_.groupBy(messages, „authorId“);
>
> //We return an array with the IDs as key and the message as value
> return ids.map(key => groupedMessages\[key\] || \[\]);
> }
6. Wenn die Daten nun abgefragt werden sollen, muss nur noch die Load-Funktion vom Dataloader aufgerufen werden, welche ein Promise zurückgibt:
> messageLoaderUser.load(authorID)
### **Herausforderungen beim Dataloader**
Der Dataloader stellt nativ keine Unterstützung zur Pagnation zur Verfügung. In einem solchen Fall werden bei jeder Anfrage alle Tabelleneinträge zurückgegeben und die ganze Datenbank abgefragt.
Um dieses Problem zu lösen, gibt es zwei Möglichkeiten. Zum einen könnte man ein verschachteltes rekursives Union-All-SQL-Statement bauen, das die angefragten Daten bis zum übergebenen Limit zurück gibt und der Map-Funktion übergibt. Dazu muss aber der batch-Funktion die Pagnation übergeben werden und für jeden Offset und jedes Limit der Pagnation existiert dann ein eigener Batch.
Die andere Möglichkeit wäre zunächst alle IDs und Fremdschlüssel über den Dataloader aus der Datenbank laden, auf diese dann die Pagnation ansetzt und anschließend die Datensätze zu den entsprechenden IDs sich über den Dataloader holt (1-1 Beziehung). Das reduziert die aus der Datenbank zu ladenden Daten, im Vergleich dazu, dass alle Felder zu allen Datensätzen geladen werden. Jedoch werden immer noch von allen Einträgen die IDs und Fremdschlüssel geladen, was bei großen Tabellen problematisch wird.
> //Loading MessagesInfos (id and authorId) from DataLoader
> let messageInfos = await messageLoaderForUsers.load(this.getId());
> if (!offset) {offset = 0;}
>
> //Pagination and extracting the Ids of the messageInfos
> messageInfos = messageInfos.slice(offset, (offset + limit));
> let messageIds = messageInfos.map((message: any) => message.id);
>
> //Loading the full messages
> let results = await messageLoader.loadMany(messageIds);
> results = results.map((result: any) => result\[0\]);
>
> return results;
Für jeden Anfragetyp muss ein eigener Dataloader mit entsprechender Batch-Funktion implementiert werden. Zusätzlich muss auch für jede Anfrage, oder zumindest für jeden User, ein eigener Dataloader erstellt werden, um Zugriffe über die Caches der Dataloader auf die Daten anderer Nutzer zu verhindern. Das Problem kann aber durch den Einsatz von entsprechenden Factory-Methoden sehr einfach gelöst werden.
### **Zusammenfassung:**
Insgesamt lässt sich sagen, dass der Dataloader vor allem beim Batchen von einzelnen Fremdtypen bzw. 1:1-Beziehungen viel bringt (bis zu Faktor 20 schneller). Bei Listen bzw. 1-n-Beziehungen war der Performance-Vorteil mit eineinhalb bis doppelter Durchsatzrate eher mäßig. Dies würde aber höher ausfallen, wenn Datenbank und Server nicht auf der selben Maschine laufen würden und die RTT (Round Trip Time) höher wäre.
Der Dataloader vermindert zusätzlich noch die im Cache der Apollo Engine zu speichernde Datenmenge, da er nur die Attribute zurückgibt, die angefordert werden und nicht der ganze Datensatz im Cache gespeichert wird. Das hat allerdings den Nachteil, dass bei einer neuen Anfrage auf den gleichen Datensatz mit anderen Attributen kein Cache-Eintrag mehr vorhanden ist, da die Attribute nicht im Cache liegen.
Problematisch ist aufgrund von Sicherheit, Zugriffskontrolle auch, dass der Dataloader Daten für immer speichert und das kontextunabhängig. Die Kontextunabhänigkeit führt zusätzlich dazu, dass kontextabhängige Daten zu einem späteren Zeitpunkt abhängig vom Kontext, der zur Zeit der Speicherung geherrscht hat, zurückgegeben wird.
### **Anhang „“ Testergebnisse**
Wir haben mit unserem Server Loadtesting durchgeführt. Dazu haben wir mit dem Tool JMeter unterschiedlich viele Wiederholungen der selben Anfragen an unseren Server geschickt.
Folgende Aspekte haben wir dabei beachtet:
- Query: Die Query, die an den Server gestellt wurde
- Komplexität Die maximale Anzahl der Knoten, die zurückgegeben werden können
- Threads: Die Anzahl der parallelen Anfragen an den Server
- Wdhs: Die Anzahl, der Wiederholungen der parallelen Threads
- Abgeschlossene Proben: Die Anzahl der Anfragen, die insgesamt während dem Test an den Server geschickt wurden
- Durchsatz: Die Anzahl der bearbeiteten Anfragen pro Sekunde
- Caching: Gibt an, ob Caching im Server aktiviert war
- Dataloader: Gibt an, ob der Dataloader aktiv war
- Production Mode: Gibt an, ob der Server im Production Mode gelaufen ist.
In der folgenden Tabelle haben wir unsere Testergebnisse dokumentiert:
[LoadTest – QraphQL](https://thecattlecrew.net/wp-content/uploads/2018/09/loadtest-qraphql.xlsx "LoadTest - QraphQL")
**Kategorien:** Development, Integration
**Schlagwörter:** Endpoints, Facebook, GraphQL, Innovation, Internet, JavaScript, Mobile, OC|Lab, rest, TypeScript
---
### [GraphQL Demo (4/8) - Response Caching](https://thecattlecrew.net/2018/09/06/response-caching/)
**Published:** September 6, 2018
**Author:** Manuel Styrsky
**Content:**
Die Apollo Engine stellt eine einfache Möglichkeit zum Response Caching zur Verfügung. Dabei können ganze GraphQL Query Antworten oder auch nur einzelne Felder gecached werden.
### **Warum Caching und was ist das Besondere dabei mit GraphQL?**
Caching ist bei GraphQL etwas schwieriger als bei REST-Schnittstellen, da nicht wie beim HTTP oder Netzwerk Caching, Daten zum Beispiel über die URL gecached werden können. Dennoch ist Caching bei Datenbankanwendung, wie in unserem Beispiel, das A&O um schnelle Antwortzeiten zu erlangen. Daher muss Caching bei GraphQL die Queries selber bewerten und Antworten im Cache speichern. Genau das liefert Apollo Engine mit.
### **Wie aktiviere ich den Cache?**
Die einzigen Schritte, die dazu gemacht werden müssen, sind das Caching in den Serveroptionen zu aktivieren und die Cache Hints zu setzen.
1. Caching in den Serveroptionen aktivieren:
Sowohl *tracing* als auch *cacheControl* müssen auf *true* gesetzt werden.
*CacheControl* kann optional auch ein Defaultobjekt übergeben werden, in dem das defaultMaxAge gesetzt wird.> resolve({ schema,
> **tracing: true,**
> cacheControl: {**
> defaultMaxAge: 10,**
> },**
> context
> });
2. Cache Hints setzen
Man kann Cache Hints an zwei verschiedenen Stellen setzen. Entweder direkt im *resolver* oder im *Schema*. Im *Schema* können sowohl ganzen Typen, als auch einzelnen Feldern Cache Hints gegeben werden.
Cache Hints bestehen aus zwei Parametern. Dem *maxAge*, welcher angibt, wie lange die Daten maximal gecached werden sollen. Und dem *scope*, dieser kann entweder private oder public sein. Private gecachete Daten sind dann nur in der entsprechenden Session eines bestimmten Clients verfügbar. Der default Wert ist public, die so gecacheten Daten können von allen Clients abgerufen werden.
Kürzere *maxAge* Angaben überladen längere in anderen Ebenen (Typen/Felder). Genau dasselbe gilt für private und public beim *scope*.> type User **@cacheControl (maxAge: 120)** {
> id: Int
> name: String
> phone: String
> conversations(limit: Int!, offset: Int): \[Conversation\]
> messages(limit: Int!, offset: Int): \[Message\]
> isViewer: Boolean **@cacheControl (maxAge: 60, scope: private)**
> }
Würde jetzt hier eine Anfrage an die ID und den Namen der User gestellt werden würden die Daten 120 Sekunden im Public Scope gehalten. Im Gegensatz dazu würde eine Anfrage an das isViever Attribut und den Namen nur 60 Sekunden und auch im nur im Private Scope gehalten werden.
3. Optional können noch die Cache Optionen geändert werden
Um private cachen zu können, muss dies auch bei der Konfiguration des Servers beachtet werden. Hierfür reichen die default-Werte nicht mehr aus.
Hier für muss“¦
1. „¦ *stores* mit einem extra Cache initialisiert werden
2. „¦ *sessionAuth* übergeben werden, wie die Session identifiziert wird (HTTP-Header oder Cookie)
3. … im *queryCache* dem *privateFullQueryStore* der zuvor extra angelegte Cache zugewiesen werden
> const engine = new ApolloEngine({
> **stores: \[{**
> **name: ‚privateResponseInMemoryCache‚**
> **}\],**
> **sessionAuth: {**
> header: ‚authorization‚,**
> **},**
> **queryCache: {**
> **privateFullQueryStore: ‚privateResponseInMemoryCache‚,**
> //By not mentioning publicFullQueryStore, we keep it enabled
> //with the default empty-string-named in-memory store.
> **},**
> „¦
> „¦
> });
### **Wo werden die Daten gespeichert?**
Es werden zwei Speichermöglichkeiten für den Cache unterstützt
1. *inMemory* (default)
Der Cache liegt innerhalb des Engine Proxys, also auf dem eigenen Server und nutzt die LRU (Least recently used) Verdrängungstechnik. Dadurch, dass der Cache innerhalb eines bestimmten Engine Proxys liegt, kann der Cache zwischen verschiedenen Instanzen nicht gemeinsam genutzt werden ist dafür aber sehr schnell.
Die Default Cachegröße liegt bei 50mb, kann aber geändert werden.
2. *Memcache*
Memcache nutzt externe [Memcached](https://memcached.org/)„¯Server. Dadurch wird der Cache für mehrere Engine Proxies verfügbar ist aber langsamer als der *inMemory* Cache und liegt nicht mehr auf den eigenen Servern.
### **Ergebnisse bei unserer Demo-Anwendung und Zusammenfassung:**
Das Response Caching bringt bei unserer Anwendung bei vielen identischen Anfragen einen Enormen Performance boost (je nach Anfrage: Faktor 20 bis zu 10³). Wichtig ist auch, die im Cache zu speichernde Datenmenge zu reduzieren. Hierbei, hat der Einsatz des [Dataloaders](https://thecattlecrew.net/2018/08/30/dataloader-und-batching) auch positive Nebeneffekte gehabt.
Zusammenfassend lässt sagen, dass sich der Cache bei der Apollo Engine sehr leicht mit ein paar Zeilen Code aktivieren lässt und als Response-Cache auch einen deutlichen Performance Boost bei Identischen Anfragen bringt.
### **Anhang „“ Testergebnisse**
Wir haben mit unserem Server Loadtesting durchgeführt. Dazu haben wir mit dem Tool JMeter unterschiedlich viele Wiederholungen der selben Anfragen an unseren Server geschickt.
Folgende Aspekte haben wir dabei beachtet:
- Query: Die Query, die an den Server gestellt wurde
- Komplexität Die maximale Anzahl der Knoten, die zurückgegeben werden können
- Threads: Die Anzahl der parallelen Anfragen an den Server
- Wdhs: Die Anzahl, der Wiederholungen der parallelen Threads
- Abgeschlossene Proben: Die Anzahl der Anfragen, die insgesamt während dem Test an den Server geschickt wurden
- Durchsatz: Die Anzahl der bearbeiteten Anfragen pro Sekunde
- Caching: Gibt an, ob Caching im Server aktiviert war
- Dataloader: Gibt an, ob der Dataloader aktiv war
- Production Mode: Gibt an, ob der Server im Production Mode gelaufen ist.
In der folgenden Tabelle haben wir unsere Testergebnisse dokumentiert:
[LoadTest – QraphQL](https://thecattlecrew.net/wp-content/uploads/2018/09/loadtest-qraphql.xlsx "LoadTest - QraphQL")
**Kategorien:** Development, Integration
**Schlagwörter:** ApolloEngine, Caching, Entpoints, GraphQL, Internet, OC|Lab
---
### [How to solve the 404 HTTP Error for Angular Apps hosted on S3](https://thecattlecrew.net/2018/10/15/how-to-solve-the-404-http-error-for-angular-apps-hosted-on-s3/)
**Published:** Oktober 15, 2018
**Author:** Marco Buss
**Content:**
As described in this [blogpost](https://thecattlecrew.net/2018/10/12/how-to-use-cloudfront-to-serve-private-s3-bucket-as-website/), S3 is very suitable for serving a single Page Web Application.
If your users always come through the index page to your site everything will be fine. You have an corresponding HTML file on S3 and your request will be handled like a charm. But it is really common to provide some functionality that is triggered by an HTML request, for example some confirmation links and that URL has no corresponding file in S3 because all the magic stuff is handled by the Angular Router. The result for such an Request is an 404 HTTP error.
To solve that problem with our infrastructure, we must instrument CloudFront to handle the 404 HTTP error from S3. To do that we simply define some custom error Response. So go to the „Error Pages“ Tab for your CloudFront Distribution and create a new Custom Error Response.
Now we configured the following.
If our Origin (S3) returns a 404 Error CloudFront returns the index.html and the status code 200. With that configuration the content from our index.html is returned but the url itself will be unchanged and that is all to get the Angular Router to do his work.
**Kategorien:** Development
**Schlagwörter:** Angular, AngularJS, AWS, Frontend, Mobile, S3
---
### [Personas und äußerst beliebte Designfallen in der Entwicklung von Softwareprodukten](https://thecattlecrew.net/2019/10/23/personas-und-aeusserst-beliebte-design-fallen-in-der-entwicklung-von-software-produkten/)
**Published:** Oktober 23, 2019
**Author:** Andreas Lehner
**Content:**
Personas sind ein nützliches und grundlegendes Design-Werkzeug, um positive Benutzererfahrungen zu entwickeln. Personas unterstützen Produktteams dabei, bessere Design-Entscheidungen zu treffen. Die Basis von Personas ist tiefes Verständnis der Nutzer. Dieses Verständnis wird durch User Research gewonnen, analysiert und aufbereitet und als Nutzer-Archetyp (Persona) für die tägliche Arbeit am Produkt genutzt. Im Idealfall helfen Personas Design-Fallen von Software-Produktteams zu verhindern. Drei der beliebtesten Fallen beschreibe ich hier:
# Falle 1: Self-Referential Design
Was passiert, wenn wir als Produktteam Design-Entscheidungen treffen ohne die Nutzer zu verstehen? Wir projizieren unsere Ziele, Motivationen, Skills und mentale Modelle \[1\] auf das Produkt. Wir treffen Design-Entscheidungen ausschließlich für uns. Wir selbst verstehen unsere Anwendung sehr gut, weil sie auf unserem „Implementation Model“ \[2\] basiert. Alle anderen jedoch, also auch die Nutzer, verstehen die Anwendung im schlimmsten Fall nicht. Oft tappt man in diese Falle, wenn wir besonders „coole“ Apps bauen wollen (z.B. abgefahrene Animationen, verrückte Interaktionen, crazy AI, usw.) die nur wir als Ersteller verstehen, aber der Rest der Welt nicht.
Personas helfen dabei, diese Falle zu umgehen, da die Persona im Team ein gemeinsames Verständnis über den Nutzer erzeugt. Dennoch kann auch unter Nutzung der Persona etwas geschwindelt werden. Besonders geschwindelt wird dann, wenn wir als Produkt-Team sogenannte „Geister“-Personas erstellen.
# Falle 2: Geister-Personas
Wir als Produkt-Team treffen Annahmen über die Nutzer. Beispielsweise treffen wir uns in einem Design-Thinking Workshop mit ein paar Stakeholdern, erstellen brav Empathy Maps, entwickeln daraus Persona-Profile, um Geschichten über die Nutzer zu erzählen. Exzellent. Wir verfügen über ein gemeinsames Verständnis über unsere Nutzer und haben eine gemeinsame Basis um Design-Entscheidungen zu treffen. Vorsicht! Wir glauben alles über die Nutzer zu wissen, doch wir haben noch keine unserer Annahmen validiert, etwa durch Daten aus qualitativer User Research.
Auf diese Weise entstehen Geister-Personas, die uns durch die komplette Produktentwicklung hin verfolgen. Personas sollten daher immer auf zuverlässigen Daten beruhen. Sei es aus qualitativer Research oder quantitativer Research. UX Researcher sorgen mit entsprechenden Research-Methoden dafür, Sinn aus dem Datenchaos zu entwickeln. Starten wir mit Annahmen über unsere Nutzer, ist es von größter Bedeutung diese Annahmen mit „echten“ Daten zu validieren.
# Falle 3: Elastic User
Wir als Produktteam beabsichtigen natürlich, dass wir mit unserem Produkt die Bedürfnisse der Nutzer befriedigen. Darüber herrscht Einigkeit, keine Frage. Jetzt ist es aber so, dass Timo ein anderes Verständnis über den Nutzer hat, als Freddy. Jedes Teammitglied hat ein unterschiedliches Konzept des Nutzers und seiner Bedürfnisse im Kopf. Kommt der Zeitpunkt Design-Entscheidungen zu treffen, entsteht der „Elastic User“. Am Elastic User wird gezogen und gezerrt, um die individuellen Konzepte bequem zu rechtfertigen und durchzusetzen. So wird aus einem Nutzer mal ein „Power-User“, der durch seine Erfahrung mit komplexen und überladenen Dialogen gut umgehen kann, manchmal wird er zum „First-Time“-User, der unbedingt Wizards benötigt, um seine Tasks in einem Workflow abzuschließen. Auf diese Weise gewinnen wir als Produktteam die Freiheit, zu machen was wir wollen, mit dem Nachteil die Bedürfnisse und Ziele der „echten“ Nutzer ignoriert zu haben.
# Conclusio
Personas helfen Produktteams bessere Design-Entscheidungen zu treffen. Dennoch fällt eine Persona nicht einfach vom Himmel, sondern sollte gewissenhaft und sorgfältig erstellt und am Leben erhalten werden. Ein guter Beginn ist es mit Annahmen zu Proto-Personas zu starten. Besser und unverzichtbar für gutes Persona-Gelingen ist es, die Annahmen zu validieren. Auf diese Weise entfalten Personas ihren größten Mehrwert und gängige Design-Fallen wie Elastic User, Geister-User oder Self-Referential-Design können erfolgreich umgangen werden.
**Möchtest Du mehr erfahren über User Experience und Design Thinking?**
**Kontaktiere uns und lass uns austauschen: https://www.opitz-consulting.com/portfolio/software-development/user-centered-development.html**
# Spannende Links und Referenzen
\[1\]
\[2\] [http://www.jonkolko.com/projectFiles/scad/IACT315\_03\_MentalModelsPersonasScenarios.pdf](http://www.jonkolko.com/projectFiles/scad/IACT315_03_MentalModelsPersonasScenarios.pdf)
**Kategorien:** Development, Tools & Methoden
**Schlagwörter:** Design Thinking, Empathy, Persona, user experience
---
### [Coloring rows in ClassicReports](https://thecattlecrew.net/2022/02/08/coloring-rows-in-classicreports/)
**Published:** Februar 8, 2022
**Author:** Maik Michel
**Content:**
I often encounter the problem that I want to highlight a row of a Classic Report. Most of the time the logic here is based on the presence of a certain value or status. Every time I implement something like this, I start searching the good old web again. Here comes a new contribution to solve the problem „Coloring rows in ClassicReports“ 😉
Since it is common to separate CSS, i.e. the layout, from the logic, this is also the first choice. So you don’t just color a line by color code, but assign the right class at the right place. As far as classes are concerned, it will be easy to do that, as APEX provides us with 45 classes by default, together with the Universal Theme. [https://apex.oracle.com/pls/apex/apex\_pm/r/ut/color-and-status-modifiers](https://apex.oracle.com/pls/apex/apex_pm/r/ut/color-and-status-modifiers)
First we include the CSS class in the query. Either you create the name of the class on the fly or you save it in the respective target table. Like this:
```
select phs_id, phs_name, phs_css_class
from crm_phasen
order by phs_sortierung, phs_name
```
Unfortunately, APEX does not offer any property by itself, where we can store the column containing the class information. Therefore, we will set this information to an already existing one. Like for example in name field.
```
#PHS_NAME#
```
[](https://thecattlecrew.net/wp-content/uploads/2022/02/html_expression.png) Properties of report column Here, the class `row-class` serves me as a marker of the required information. The attribute data-class contains the class I selected.
To attach the class `PHS\_CSS\_CLASS` to the line of a Classic Report some Javascript code must be executed after each query. This does nothing else than attaching the class to the appropriate `tr` tag. To do so, create a Dynamic Action on the report for the event: `AfterRefresh`. As action you choose the execution of Javascript code.
```
$('.row-class').each(function() {
$(this).closest('tr').addClass($(this).attr('data-class'));
});
```
[](https://thecattlecrew.net/wp-content/uploads/2022/02/da_execute_javascript.png) Properties of DynamicAction It is important to activate the switch for Fire on Initialization, so that the Javascript code is executed directly when the page is loaded.
The actual coloring is then done via CSS. This can be done inline on the page itself or better, via static file upload.
```
.oc--u-color-1 {border-left: 8px solid; border-left-color: var(--u-color-1);}
.oc--u-color-2 {border-left: 8px solid; border-left-color: var(--u-color-2);}
.oc--u-color-3 {border-left: 8px solid; border-left-color: var(--u-color-3);}
.oc--u-color-4 {border-left: 8px solid; border-left-color: var(--u-color-4);}
.oc--u-color-5 {border-left: 8px solid; border-left-color: var(--u-color-5);}
.oc--u-color-6 {border-left: 8px solid; border-left-color: var(--u-color-6);}
.oc--u-color-7 {border-left: 8px solid; border-left-color: var(--u-color-7);}
.oc--u-color-8 {border-left: 8px solid; border-left-color: var(--u-color-8);}
.oc--u-color-9 {border-left: 8px solid; border-left-color: var(--u-color-9);}
.oc--u-color-10 {border-left: 8px solid; border-left-color: var(--u-color-10);}
.oc--u-color-11 {border-left: 8px solid; border-left-color: var(--u-color-11);}
.oc--u-color-12 {border-left: 8px solid; border-left-color: var(--u-color-12);}
.oc--u-color-13 {border-left: 8px solid; border-left-color: var(--u-color-13);}
.oc--u-color-14 {border-left: 8px solid; border-left-color: var(--u-color-14);}
.oc--u-color-15 {border-left: 8px solid; border-left-color: var(--u-color-15);}
```
Done .. 😉
[](https://thecattlecrew.net/wp-content/uploads/2022/02/final_report.png) Report showing colored rows Have fun developing with APEX
> This blog post was orignally published in my personal blog
>
>
**Kategorien:** Analytics & Insights, Development
**Schlagwörter:** APEX, Frontend, HowTo, oracle
---
### [APEX: Additional Group Column Heading in ClassicReport](https://thecattlecrew.net/2022/06/25/addionaly-group-column-heading-in-classic-report/)
**Published:** Juni 25, 2022
**Author:** Maik Michel
**Content:**
In my projects it sometimes happens that I have a lot of columns in a classic report. Of course, this has a negative effect on the look and feel. Often it helps here to outsource similarities of the respective columns in an additional heading line. You can find out how to do that right here.
We create a Dynamic Action on the corresponding report that fires on the event AfterRefresh.
[](https://thecattlecrew.net/wp-content/uploads/2022/06/APEX_PageBuilder_Attributes_DynamicAction_setColumnGroupHeadings.png)
As the actual action, we choose to execute JavaScript code, which should also be executed on load.
[](https://thecattlecrew.net/wp-content/uploads/2022/06/APEX_PageBuilder_Attributes_ExecuteJavaScript_for-setColumnGroupHeadings.png)
Following lines of JavaScript, insert a new line before the actual heading line generated by APEX:
```
apex.jQuery(this.triggeringElement).find('thead').prepend(` + +The Book +Publish +
`
);
```
Done. [You can find a demo here.](https://apex.oracle.com/pls/apex/r/die21/demos/column-groups)
> This blog post was orignally published in my personal blog
>
> https://micodify.de/addionaly-group-column-heading-in-classic-report/
**Kategorien:** Development
**Schlagwörter:** APEX, English, Frontend, HowTo, oracle
---
### [Angular Signals: Übersicht und aktueller Stand](https://thecattlecrew.net/2023/11/06/angular-signals-uebersicht-und-aktueller-stand/)
**Published:** November 6, 2023
**Author:** Alexander Möller
**Content:**
State Management und die Reaktion auf State-Veränderungen sind ein wichtiges Thema in Frontend-Applikationen. Aktuell setzt Angular dafür auf die Eigenentwicklung Zone.js. Mit Angular Signals wurde dieses Jahr ein vielversprechendes alternatives Reaktivitätssystem vorgestellt.
Als neue „reactive primitives“ bieten Signals eine neue Möglichkeit, auf Änderungen am State zu reagieren und die UI feingranular zu aktualisieren. Damit lässt sich die Change Detection deutlich effizienter durchführen. Das Konzept ist allerdings nicht neu: Preact.js, Solid.js und Vue.js verwenden bereits seit Jahren ähnliche Konstrukte.
Als Entwickler stellen sich mir jetzt vor allem drei Fragen:
- Wie funktionieren Signals und was sind ihre Vorteile?
- Wie werden Signals eingesetzt?
- Welche Auswirkungen habe sie auf Angular?
Diese Fragen möchte ich im Artikel klären.
## Wie funktionieren Angular Signals?
Signals sind Wrapper um eine Variable. Sowohl Lesen als auch Schreiben von Werten der Variablen wird durch Funktionsaufrufe auf den Wrapper umgesetzt. Durch die lesenden Methodenaufrufe kann der Wrapper eine Liste der Konsumenten pflegen. Wird der Wert des Signals geändert können so alle vom Signal abhängigen Konsumenten informiert werden. Wichtig: Sowohl das Lesen als auch das Schreiben eines Signals ist immer synchron!
Angular stellt einen readOnly- und einen writable-Typen zur Verfügung. Um Konsumenten eines Signals auf das Lesen von Werten zu beschränken, gibt es die Möglichkeit von einem writableSignal ein readOnly-Signal zu generieren.
```
const readOnlySignal: Signal = signal(0);
readOnlySignal() // 0 (= Der Getter)
readOnlySignal.set(2) // error
const writableSignal: WritableSignal = signal(0);
writableSignal.set(2) // 2
writableSignal.update((previousValue) => {return previousValue + 1}) // 3
const readOnlySignal2: Signal = writableSignal. asReadonly();
const writableSignal2: WritableSignal = singal([0]); // [0]
const writableSignal2.mutate((val) => val.push(1); // [0,1] Änderung In-Place
```
### Effects
Effects sind Methoden die ein oder mehrere Signals konsumieren und jedes Mal durchgeführt werden, wenn eines der Signals seinen Wert ändert. Ein typischer Anwendungsfall für Effects ist das Loggen von Werten.
Achtung: Im Gegensatz zu Signals sind Effects immer asynchron!
```
loggingEffect = effect(() => console.log(writableSignal()))
```
### Computed Angular Signals
Diese Signalart konsumiert beliebig viele Signals und generiert daraus einen Rückgabewert. Ändert sich eines der verwendeten Signals wird der Wert erneut berechnet und alle Konsumenten des Computed Signals werden benachrichtigt. Computed Signals bieten keine Methode zum direkten Setzen eines Wertes an.
Computed Signals sind immer asynchron.
```
computedSignal: Signal = computed(() => this.readOnlySignal() + 1);
```
Signals, Effects und Computed Signals sind ab Angular 16 als Developer Preview verfügbar.
## Auswirkungen auf Angular
Um die Vorteile von Angular Signals bezüglich Reaktivität nachvollziehen zu können, ist es hilfreich zu verstehen, wie Change Detection in Angular derzeit funktioniert. Dazu hier ein kleiner Exkurs:
### Wie funktioniert Change Detection in Angular?
Change Detection beschreibt den Prozess, die UI synchron mit den Änderungen am Model der Applikation zu halten. Framework-agnostisch wird dieser Mechanismus als Reaktivität bezeichnet. Angular stellt dafür einen Ablauf zur Verfügung, der nach einer Änderung am Model angeworfen wird: Der Change Detection Cycle (CDC).
Beginnend bei der Root-Komponente werden alle Komponenten sequenziell bis zum letzten Blatt durchlaufen. Dabei werden die von der UI referenzierten Werte auf Änderungen untersucht und gegebenenfalls die UI aktualisiert. Angular geht dabei sehr performant vor. So können mehrere tausend Checks in Millisekunden durchgeführt werden. Dennoch können CDCs in größeren Anwendungen zu einem Performanceproblem werden.
### Was triggert einen CDC?
Angular verwendet Zone.js, um beim Hochfahren bestimmte Browser-APIs so abzuändern, dass sie neben ihrer eigentlichen Funktion zusätzlich einen CDC anwerfen. Das Vorgehen, Funktionalität zur Laufzeit zu ändern, wird als Monkey Patching bezeichnet.
Ermöglicht wird dies durch Zonen von Zone.js, die Tasks in gesonderten Execution Contexts ausführen und Hooks anbieten, wenn bestimmte Events, wie das vollständige Ausführen aller Tasks, eintreffen. Vor allem bei asynchronen Tasks, wie der Kommunikation mit einem Webserver über HTTP, ist die Ausführung innerhalb von Zonen essenziell. Durch die Hooks kann auf die Events reagiert und ein CDC angeworfen werden.
### Schwächen der aktuellen Lösung
Das Triggern eines Zone-Hooks macht lediglich eine Aussage darüber, dass sich etwas geändert haben könnte. Es liefert aber keine Aussage darüber, ob sich überhaupt etwas geändert hat. Und wenn doch, dann wird nicht klar, was sich ändert. Das wird erst im Verlauf des daraufhin ausgelösten CDC festgestellt, der alle Komponenten durchlaufen muss.
Hier gibt es also Optimierungspotential und das ist der Punkt an dem Signals aufsetzen. Mit der On-push-Change-Detection-Strategie lässt sich zwar die Anzahl der zu durchlaufenden Komponenten verringern, das Grundproblem, dass deutlich mehr Abgleiche stattfinden als notwendig, bleibt aber bestehen.
Um es auf den Punkt zu bringen: Es werden CDCs ausgelöst, die nicht notwendig sind, weil sich nichts geändert hat. CDCs überprüfen jedes Mal unnötig große Teile der Applikation.
Diese Probleme werden durch Signals gelöst.
## Angular Signals als alternatives Reaktivitätssystem
Die Kombination aus Signals und Effects ermöglicht es Angular, ein alternatives Reaktivitätssystem zu etablieren:
- Ein Signal beinhaltet einen Wert, der in der UI angezeigt und aktualisiert werden soll.
- Die UI verwendet eine Referenz auf das Signal.
- Ein Effekt beobachtet das Signal und aktualisiert jedes Mal die UI, wenn sich der Wert des Signals ändert.
Die Synchronisierung der UI mit dem State der Signals verrichtet Angular im Hintergrund.
Da Zone.js und Signals sehr unterschiedliche Annahmen bezüglich des Data Flows in Applikationen treffen, wird es zukünftig die Möglichkeit geben auf Komponentenbasis zu entscheiden, ob sie auf Zone.js oder Signals basieren. Beide Komponententypen sollen problemlos in derselben Applikation miteinander interagieren können. So können Entwicklungsteams Komponente für Komponente auf Signals umstellen. Laut Aussage eines Maintainer/Authors des RFC hat Google aktuell keine Pläne, den Support von Zone.js in Angular einzustellen (Kommentar von April 2023).
In reinen Signal-Komponenten wird die Change Detection damit deutlich effizienter. Sie wird nur noch dann durchgeführt, wenn sich ein Signal, dass in der UI referenziert wird, ändert. Während ein Zone.js-Hook triggern kann, ohne dass es eine Änderung am State gab, ist dies bei Signals nicht mehr möglich.
Des Weiteren ist bekannt, welcher Teil der UI aktualisiert werden muss. Angular bleibt bei dem Konzept, dass nicht individuelle Bindings sondern Bereiche aktualisiert werden. Die Bereiche sind aber wesentlich kleiner als beim Durchlauf eines Zone.js-CDC. Dafür unterteilt Angular Komponenten in kleinere Teile, sogenannte Views, und rendert nur die betroffenen Views neu.
Bei einer Mischung von Zone.js- und Signal-Komponenten in einer Applikation werden die Signal-Komponenten beim Durchlaufen des Zone.js-CDC ausgenommen und separat abgehandelt.
### Nutzung von Angular Signals in Komponenten
Um die genannten Vorteile von Signals nutzen zu können, ist für die Zukunft angedacht, dass Komponenten entweder als Zone-basierte oder als Signal-basierte Komponente definiert werden. Der aktuelle Vorschlag besteht darin, ein neues Attribut zur @Component-Annotation hinzuzufügen. Signals sind aber nicht auf Signal-basierte Komponenten beschränkt, sondern können auch in Zone-basierten Komponenten verwendet werden.
```
@Component({
signals: true,
…
})
```
Die Verknüpfung des Templates mit einem Signal funktioniert über den Aufruf des Getters:
component.ts
```
count = signal(0);
```
component.html
```
Count {{ count() }}
```
Aktuell ist es in der Regel keine gute Idee, im Template Methodenaufrufe zu referenzieren, da diese dann bei jedem CDC erneut ausgeführt würden. Bei Signals gibt es dieses Problem nicht. Im Gegenteil: Es ist explizit erlaubt (und notwendig), da sonst das Signal selbst und nicht der aktuelle Wert des Signals referenziert wird.
Ob Nicht-Signal-Bindings erlaubt sein werden und wie damit umgegangen werden wird, ist Bestandteil der aktuellen Debatte. Zum aktuellen Zeitpunkt (Oktober 2023) sind Signal-basierte Komponenten noch in keiner Angular-Version verfügbar. Sie sollen frühestens mit Angular 18 zur Verfügung stehen.
### Angular Signals und RxJS
Signals sollen RxJs nicht ersetzen, sondern ergänzen. Dafür wurde ein neues Paket zur Core Library von Angular hinzugefügt: @angular/core/rxjs-interop
Darüber werden die Funktionen toObservable und toSignal zur Verfügung gestellt, die es erlauben, die beiden Konstrukte in das jeweils andere umzuwandeln.
toObservable
```
countSignal = signal(0);
count$ = toObservable(this.count);
```
Dabei wird im Hintergrund ein Effect gestartet, der bei jeder Änderung des Signals dafür sorgt, dass das Observable den Wert ausgibt:
toSignal
```
interval$ = interval(1000);
intervalSignal: Signal = toSignal(this.interval$);
```
Dabei gilt:
- Wenn ein Observable einen Wert emitted, wird der Setter des Signals aufgerufen
- Wenn ein Observable einen Error emitted, wird der Error von Angular geworfen
- Beim Emitten von „Complete“ bleibt der letzte Wert des Signals erhalten
Da das Observable keinen initialen Wert besitzt, bis der erste Wert emitted wird, muss „undefined“ in den Typen aufgenommen werden. Um die Typisierung auf umzustellen, kann ein initialer Wert bei der Umwandlung mitgegeben werden:
```
intervalSignal2: Signal = toSignal(this.interval$, {initialValue: 0});
```
### Achtung: Angular Signals sind keine Streams
Signals geben, im Gegensatz zu Observables, nicht jeden Zwischenwert aus, der ihnen zugewiesen wird. Gibt es mehrere Zuweisungen nacheinander, so werden diese synchron ausgeführt und die Konsumenten erst im Anschluss benachrichtigt. Dadurch entsteht ein Verhalten, das für den Observable-erfahrenen Entwickler auf den ersten Blick überraschend sein kann:
```
const writableSignal: WritableSignal = signal(0);
loggingEffect = effect(() => console.log(writableSignal()))
writableSignal.set(1);
writableSignal.set(2);
writableSignal.set(3);
```
Da das Setzen der Werte synchron, das Update durch den Effect aber asynchron stattfinden, werden erst der initale Wert 0 und anschließend der finale Wert 3 geloggt. Das gleiche Verhalten ist auch bei Computed Signals der Fall. Dieser Batch-Verarbeitung sollten wir uns bewusst sein, wenn wir mit Signals arbeiten.
### Einsatz im State Management
Signals sind prädestiniert dafür, im Kontext State Management eingesetzt zu werden. Eine eigene Lösung für kleinere Projekte kann auch heute schon über einen State Service implementiert werden. Angular selbst wird dabei keine eigene State Library anbieten. Die verbreiteten State-Management-Bibliotheken NgRx und NGXS haben bereits Diskussionen über den Einsatz von Signals gestartet.
## Fazit
Angular arbeitet mit Signals an einem lange ersehntem System, dass das Thema Reaktivität für Entwickler vereinfacht und gleichzeitig die Performance der Change Detection steigert. Damit wird es zudem möglich, sich von der Abhängigkeit der Bibliothek Zone.js zu lösen. Einen Zwang zum Wechsel wird es aber nicht geben. Google hat aktuell keine Pläne, den Support von Zone.js in Angular einzustellen (Kommentar im RFC von April 2023).
Aktuell ist der Einsatz von Signals aber noch mit Vorsicht zu genießen: Zwar kann ab Angular 16 mit Signals als Developer Preview experimentiert werden, das bedeutet aber auch, dass die API sich noch mit Breaking Changes ändern kann. Dazu kommt, dass das Herzstück des neuen Reaktivitätssystems, die Signal-basierten Komponenten, erst frühestens mit Angular 18 zur Verfügung stehen werden. Ohne diese wird aber die bessere Performanz nicht erreicht, da unter der Haube weiterhin das alte Change Detection System verwendet wird.
Signals und die auf ihnen basierenden Komponenten sehen vielversprechend aus und haben gute Chancen darauf, fester Bestandteil der Zukunft von Angular zu werden. Solange sie nicht veröffentlicht und ihre Auswirkungen noch nicht vollständig bekannt sind, muss ein abschließendes Urteil aber noch auf sich warten lassen. Man wird sich also noch etwas gedulden müssen, bis es richtig losgeht.
## Quellen
Offizielles RFC
Javascript Execution Contexts
Zone.js gepatchte APIs
Angular.io Signals
RFC Signal API
**Kategorien:** Development
**Schlagwörter:** Angular, Change Detection, Change Detection Cycle, Computed, Effects, Reaktivität, Signals, Zone.js
---
### [Showdown für den Java Full Stack](https://thecattlecrew.net/2024/02/14/showdown-fuer-den-java-full-stack/)
**Published:** Februar 14, 2024
**Author:** Patrick Boerk
**Content:**
# Thymeleaf/HTMX versus Vaadin Flow & Hilla – Teil 1: Tools im Vergleich
In der sich ständig verändernden Welt der Softwareentwicklung gibt es immer wieder neue Tools und Technologien, die uns dabei helfen sollen, besser und effizienter zu arbeiten. Bei dieser Geschwindigkeit ist es für uns Entwickelnde nicht so leicht, auf dem Laufenden bleiben.
Gerade der Ansatz von Technologien, die wir für die Entwicklung von Frontends nutzen können, ist sehr wechselhaft und schwingt häufig von einem Extrem zum anderen. Die Extrempunkte sind dabei: Server-seitiges Rendern und Client-seitiges Rendern.
Grob vereinfacht lassen sich folgende Entwicklungsschritte beobachten:
- Terminal-basierte UIs aus Großrechnerzeiten: Server-seitig
- Swing oder native Windows Clients: Client-seitiges Rendern in einer Client-Server-Architektur
- JSF, ASP.net u. a.: Browser basierte UIs mit Server-seitigem Rendern in einer Mehrschichtenarchitektur
- Angular, React, Single Page Apps (SPA): Client-seitiges rendern in einer Microservices-Architektur
Dabei haben beide Ansätze Vor- und Nachteile: Beispielsweise verursacht ein komplett separierter Client, wie wir ihn aktuell bei SPAs sehen, Overhead, da wir uns um die Kommunikation zwischen Client und Server zusätzlich kümmern müssen. Andererseits haben SPAs Vorteile, weil sie einen hohen Grad an Interaktivität ermöglichen.
Doch welche Alternativen gibt es derzeit zu einem reinen SPA-basierten Ansatz? Was zeichnet diese aus? Und für welche Anwendungen sind sie am besten geeignet?
Drei Technologien halte ich, aufgrund ihrer breiten Akzeptanz bei der Webentwicklung, persönlich für besonders beachtenswert:
- Thymeleaf mit HTMX
- Vaadin Flow
- Hilla
Damit die Entscheidung für das eine oder andere Tool leichter fällt, stelle ich in diesem ersten Teil der Serie „Thymeleaf/HTMX versus Vaadin Flow & Hilla“ wesentliche Charakteristika der Technologien vor und vergleiche sie miteinander. Im zweiten Teil zeige ich dann später Codebeispiele.
## Thymeleaf mit HTMX: Server-seitige Template Engine trifft auf Hypertext
Thymeleaf ist eine Server-seitige Engine für Java Templates , die speziell für die Webentwicklung gedacht ist und es ermöglicht, HTML in Server-seitig generierten Templates zu verwenden. Wird Thymeleaf mit HTMX kombiniert, einer leichten JavaScript-Bibliothek, so entsteht ein kraftvolles Werkzeug zur Modernisierung von Webanwendungen.
Abbildung 1: Funktionsweise von Thymeleaf
Wollen wir Anwendungen mit hoher Interaktivität und schnellem Feedback entwickeln, dann sind Thymeleaf und HTMX ein mächtiges Team: Sie manipulieren den HTML-Code direkt im Browser anstatt vollständige Seiten vom Server zu laden. Das macht Webanwendungen schnell und reaktionsfähig und verbessert die Benutzererfahrung.
### Thymeleaf: Natürliche Templates und mehr
Thymeleaf verfolgt einen natürlichen und intuitiven Ansatz zur Erzeugung von HTML-Seiten. Mit diesem Tool können wir dynamische Daten sehr einfach in unsere HTML-Templates einfügen.
Abbildung 2: In diesem Code werden dynamische Werte (title und message) aus dem Modell in das HTML-Template eingesetzt, sodass wir HTML-Seiten erzeugen können, die auf den jeweiligen Kontext der Anwendenden zugeschnitten sind.
### HTMX: Einfache Server-seitige Interaktivität
Thymeleaf ist im Umfeld von Spring seit Jahren etabliert und besitzt ein aktives Ökosystem, das sowohl Framework Integration (Spring) als auch Plug-ins für diverse IDEs bereitstellt. Thymeleaf ist zunächst ohne weitere Integration sehr seitenorientiert, d. h. Interaktionen erfordern ein re-rendering der gesamten Seite. Hier kommt HTMX ins Spiel.
### HTMX: die leistungsstarke JavaScript-Bibliothek
Die HTMX JavaScript-Bibliothek hilft uns, die Interaktivität und Benutzerfreundlichkeit unserer Webanwendungen erheblich zu steigern. HTMX erreicht dies durch den Einsatz moderner Webtechnologien wie AJAX, CSS-Transitions, WebSockets und Server-Sent-Events.
Abbildung 3: In diesem Beispiel sendet der Button bei einem Klick eine AJAX-Anforderung an den Pfad /clicked und ersetzt sich selbst mit der Antwort des Servers. Dies ist eine einfache und doch mächtige Möglichkeit, um Interaktivität in unsere Webanwendungen zu bringen
### Thymeleaf und HTMX: Zwei starke, jedoch unterschiedliche Technologien
Thymeleaf bietet natürliche HTML-Templates und vielseitige Verarbeitungsmöglichkeiten, einschließlich serverseitiger Validierung und Fehlerbehandlung. Die Syntax ist allerdings komplex und Fehlermeldungen sind manchmal schwer zu interpretieren. Das kann für Unerfahrene eine Herausforderung sein.
HTMX hingegen lässt sich einfach einbinden und versetzt uns in die Lage, auch ohne tiefes JavaScript-Wissen dynamisches HTML zu erzeugen. Als JavaScript-Bibliothek hängt es jedoch immer von dessen Verfügbarkeit und Eigenschaften ab. Auch ist seine Dokumentation im Vergleich zu einigen etablierten Technologien weniger umfangreich.
Beide Technologien haben also ihre Vorzüge und Herausforderungen.
Diese Herausforderungen oder Hürden können aber in der Kombination mit Spring abgemildert werden. So existiert z. B. eine Bibliothek für HTMX im Zusammenspiel mit Spring Boot und Thymeleaf, die eine Reihe von Helferklassen bereitstellt. Das vereinfacht die Integration von HTMX in eine Spring Boot Applikation. ()
Die Idee von HTMX ist, dass der Server nicht, wie bei SPAs üblich, JSON zurückliefert, sondern HTML-Fragmente. Diese können wiederum mittels Thymeleaf angefertigt werden.
Damit erübrigt sich die Entwicklung eines eigenen REST/JSON Modells für die Übertragung von Daten zwischen Client und Server. Als Entwickelnde können wir dann im Server-seitigen Objektmodell bleiben.
### Vaadin Flow: Freies Java-Framework für eine Server-seitige Architektur
Vaadin ist ein freies Java Webframework für Rich Internet Application (RIA). Es bietet eine Server-seitige Architektur, sodass der Großteil der Logik auf einem Server ausgeführt wird.
Seit Version 10 baut Vaadin mit dem neuen Teilframework Flow auf der Client-seitig auf Web-Komponenten auf und fügt allen Aktionen eine serverseitige Datenvalidierung hinzu. Die Standardkomponenten von Vaadin können mit eigenen Steuerelementen erweitert werden.
Neben Open-Source-Erweiterungen bietet Vaadin selbst auch kommerzielle Erweiterungen wie z. B. den Vaadin TestBench für automatisierte Oberflächentests basierend auf Selenium2. Oder Vaadin Charts, einer Bibliothek visueller Komponenten, mit der sich animierte und interaktive Diagramme darstellen lassen.
### Vaadin (Flow) versus Hilla
Tabelle 1:Vaadin (Flow) und Hilla im Vergleich
## Vaadin Flow: Full Stack Java in Aktion
Vaadin ist eine Plattform, die es ermöglicht, moderne und kollaborative Web-Applikationen für Java Backends zu realisieren. Sie beinhaltet UI-Components, Frameworks und Tools, wobei die meisten dieser Komponenten geteilt und auch von Vaadin Flow und Hilla benutzt werden.
Mit Vaadin Flow können wir Webanwendungen auf dieselbe Weise erstellen wie Desktop-Anwendungen. Allerdings mit der zusätzlichen Effizienz und dem Komfort eines reinen Java-UI-Komponenten-basierten Programmiermodells. Insbesondere wenn es um die Erstellung von Geschäftsanwendungen geht, die hauptsächliche aus Formularen und Tabellen bestehen.
Abbildung 4: Feature-Vergleich – Vaadin, Angular und React
Wie gesagt ist Vaadin Flow ein Framework, das sich auf die Entwicklung von Webanwendungen konzentriert, indem es ein Java UI-Komponenten basiertes Programmiermodell verwendet. Dies ermöglicht es uns, Webanwendungen wie Desktop-Anwendungen zu bauen – alles in reiner Java-Umgebung, ohne TypeScript oder JavaScript.
Abbildung 5: Vaadin Flow – ein Code-Beispiel
Der größte Vorteil von Vaadin Flow liegt noch woanders: Mit über 20 Jahren Erfahrung im Rücken bietet Vaadin eine ausführliche Dokumentation und eine aktive Community, die bei der Lösung von Problemen hilft.
Abbildung 6: Die Historie von Vaadin
Doch auch Vaadin Flow hat seine :
Während Single Page Applikationen (SPA) wie Angular, Vue oder React skalierbar sind, sofern sie keinen Server-State halten müssen, trifft das auf Vaadin leider nicht zu. Da Vaadin sich allerdings darauf konzentriert, Geschäftsanwendungen mit Tabellen und Formen zu bauen, gibt es hier keine Einschränkung. Ebenso ist Vaadin Flow nicht darauf ausgelegt, komplexe und hübsche User Interfaces mit Animationen und Features zu bauen. Zudem sind nicht alle UI-Komponenten kostenlos verfügbar – für fortgeschrittene Features wie Charts und Maps ist ein kommerzielles Preismodell erforderlich.
## Hilla – Das Beste aus beiden Welten
Hilla, ist eine kraftvolle Kombination aus einem Spring Boot Java Backend und einem reaktiven TypeScript Frontend. Es vereinfacht die Webentwicklung durch die automatische Generierung von REST-API und Client Code. Damit können wir bei der Entwicklung direkt auf Services und Repositorien über den UI-Code zugreifen.
Abbildung 7: Hilla – ein Code-Beispiel
Einer der größten Vorteile von Hilla ist die , einer von Google entwickelten Boilerplate-Killing-UI-Komponentenbibliothek. Die ermöglicht es, schnelle und leichte Web-Komponenten zu erstellen.
Jedoch kann Hilla auch gut zusammen mit React eingesetzt werden. Ein weiteres Merkmal von Hilla ist, dass es nur einen Client-State verwendet. So können TypeScript-Views ohne Server-Session erstellt werden. Das verbessert die Performance und die Effizienz der Webanwendung.
## Fazit
Die Wahl zwischen Vaadin Flow, Hilla und Thymeleaf mit HTMX hängt von den Anforderungen unseres Projekts ab. Suchen wir ein einfaches, effizientes und vor allem Java-basiertes Framework, dann ist Vaadin Flow eine ausgezeichnete Wahl. Wollen wir jedoch eine leistungsfähige, reaktive Webanwendung erstellen, die sowohl auf der Client- als auch auf der Server-Seite ausgeführt wird, und möchten wir dabei außerdem die Vorteile von Spring Boot und TypeScript nutzen, dann wäre Hilla das Werkzeug unserer Wahl.
Zusammenfassend lässt sich sagen:
- Vaadin Flow ist ideal, wenn wir eine Full-Stack Java Entwicklung anstreben und der Schwerpunkt auf der Server-seitigen Logik liegt.
- Hilla hingegen eignet sich für Anwendungen, die eine starke Client-seitige Logik erfordern und eine große Anzahl von Nutzern unterstützen müssen.
- Die Kombination von Thymeleaf und HTMX bietet eine attraktive Alternative für diejenigen, die sich auf eine Server-seitige Java Template Engine mit der Flexibilität einer leichten JavaScript-Bibliothek verlassen möchten.
# Alle Teile ansehen
[Teil 1: Showdown für den Java Full Stack – Thymeleaf/HTMX versus Vaadin Flow & Hilla im Vergleich](https://thecattlecrew.net/2024/02/14/showdown-fuer-den-java-full-stack/)
[Teil 2: Deep Dive in den Java Full Stack – Codebeispiele aus Thymeleaf/HTMX, Vaadin Flow & Hilla](https://thecattlecrew.net/2024/02/20/deep-dive-im-java-full-stack/)
[Teil 3: Mit Angular Server Side Rendering zur besten UX – Wie Angular Server Side Rendering (SSR) hilft, blitzschnelle Webanwendungen zu entwickeln](https://thecattlecrew.net/2024/05/08/mit-angular-server-side-rendering-zur-besten-ux/)
**Kategorien:** Development
**Schlagwörter:** Client-seitiges Rendern, Hilla, HTMX, Java Full Stack, JavaScript-Bibliothek, Reactives Webdesign, Rich Internet Application (RIA), Server-seitige Template Engine, Server-seitiges Rendern, single page apps, Spring Boot, Thymeleaf, TypeScript Frontend, Vaadin Flow, Webentwicklung
---
### [Deep Dive im Java Full Stack](https://thecattlecrew.net/2024/02/20/deep-dive-im-java-full-stack/)
**Published:** Februar 20, 2024
**Author:** Patrick Boerk
**Content:**
# Thymeleaf/HTMX versus Vaadin Flow & Hilla, Teil 2: Codebeispiele
In unserem [vorherigen Blogpost](https://thecattlecrew.net/2024/02/14/showdown-fuer-den-java-full-stack/) haben wir die Unterschiede und Merkmale der drei ausgewählten TechStacks – Thymeleaf mit HTMX, Vaadin Flow und Hilla – beleuchtet. Jetzt werden wir tiefer in die technischen Aspekte eintauchen, indem wir Codebeispiele aus jedem der TechStacks betrachten.
In diesem Beitrag tauchen wir in vier entscheidende Aspekte ein, die in gängigen Webanwendungen allgegenwärtig sind:
- **Benutzerregistrierung und Anmeldung:** Die Implementierung eines Registrierungsprozesses für neue Benutzer und die Möglichkeit für angemeldete Benutzer, sich in der Webanwendung anzumelden.
- **Datenverwaltung und Anzeige:** Die Fähigkeit, Daten in einer Liste anzuzeigen, hinzuzufügen, zu aktualisieren und zu löschen.
- **Formulare und Validierung:** Die Erstellung von interaktiven Formularen zur Eingabe von Benutzerdaten, einschließlich der serverseitigen Validierung.
- **RESTful API-Kommunikation:** Die Interaktion mit externen Diensten über eine RESTful API, um Daten abzurufen oder zu senden.
Wir werden nicht nur jeden dieser Aspekte genauer betrachten, sondern auch die Umsetzungen mit unseren ausgewählten TechStacks vergleichen. Dies verspricht nicht nur spannende Einblicke, sondern auch die Möglichkeit, die Vor- und Nachteile verschiedener Ansätze zu erkunden.
*Du bist neu dabei? Hier kannst du einen Blick in den ersten Teil der Blogserie werfen:*
- [Teil 1: Showdown für den Java Full Stack – Thymeleaf/HTMX versus Vaadin Flow & Hilla im Vergleich](https://thecattlecrew.net/2024/02/14/showdown-fuer-den-java-full-stack/)
## Thymeleaf mit HTMX
Thymeleaf in Kombination mit HTMX ermöglicht es uns, interaktive Webanwendungen mit serverseitigem Rendering zu entwickeln. Hier ist ein einfaches Beispiel, wie wir dynamische Inhalte in eine HTML-Seite einfügen können:
In diesem Beispiel verwenden wir Thymeleaf, um dynamische Werte in die HTML-Seite einzufügen, und HTMX, um serverseitige Interaktivität zu ermöglichen. Der Button sendet eine AJAX-Anfrage an den Server und aktualisiert den Inhalt der
mit der Antwort.
## Vaadin Flow
Vaadin Flow ermöglicht die Entwicklung von serverseitigen Java-basierten Webanwendungen. Hier ist ein einfaches Beispiel für eine UI-Komponente in Vaadin Flow:
In diesem Beispiel erstellen wir eine einfache UI-Komponente mit einem Button, der eine Benachrichtigung auslöst, wenn er geklickt wird. Vaadin Flow bietet eine Java-basierte Programmierung von Benutzeroberflächen.
## Hilla
Hilla kombiniert ein Spring Boot Java Backend mit einem reaktiven TypeScript Frontend. Hier ist ein Beispiel für die Verwendung des Lit-Frameworks in Hilla:
In diesem TypeScript-Code verwenden wir das Lit-Framework, um eine einfache Komponente mit einem Button zu erstellen. Lit ermöglicht die schnelle Erstellung von Web-Komponenten.
## Benutzerregistrierung und Anmeldung
### Thymeleaf mit HTMX
In diesem Codebeispiel haben wir eine Seite erstellt, die sowohl die Benutzerregistrierung als auch die Anmeldung ermöglicht. Hier sind die wichtigsten Teile des Codes:
- **Registrierungsformular**: Wir haben ein Formular erstellt, das beim Absenden eine POST-Anfrage an /register sendet. Das th:htmx-Attribut ermöglicht die Verwendung von HTMX für die serverseitige Interaktion. Das Ergebnis der Registrierung wird in einem bestimmten
-Element angezeigt.
- **Anmeldeformular**: Ähnlich wie bei der Registrierung haben wir ein Formular für die Anmeldung erstellt. Die Anmeldedaten werden ebenfalls an den Server gesendet, und das Ergebnis wird im entsprechenden
-Element angezeigt.
- **Benutzerstatus**: Wir haben Bedingungen eingefügt, um den Benutzerstatus zu überprüfen. Wenn ein Benutzer angemeldet ist, wird eine Willkommensnachricht mit dem Benutzernamen und ein Link zur Abmeldung angezeigt. Andernfalls werden die Registrierungs- und Anmeldeformulare angezeigt.
### Vaadin Flow
In diesem Codebeispiel haben wir zwei Vaadin Flow Views erstellt, um die Benutzerregistrierung und Anmeldung zu implementieren:
- **LoginView**: Diese View enthält ein Textfeld für den Benutzernamen, ein Passwortfeld und einen Anmeldebutton. Beim Klicken des Anmeldebuttons wird die Methode loginUser() aufgerufen, die die Anmelde-Logik implementiert.
- **RegisterView**: Diese View enthält ein Textfeld für den Benutzernamen, ein Passwortfeld und einen Registrierungsbutton. Beim Klicken des Registrierungsbuttons wird die Methode registerUser() aufgerufen, die die Registrierungs-Logik implementiert.
### Hilla
In diesem Codebeispiel haben wir zwei LitElement-Komponenten erstellt, um die Benutzerregistrierung und Anmeldung mit Hilla umzusetzen:
- **RegisterView**: Diese Komponente enthält Eingabefelder für den Benutzernamen und das Passwort sowie einen Registrierungsbutton. Beim Klicken des Buttons wird die Methode register() aufgerufen, die die Registrierungsfunktion aufruft.
- **LoginView**: Ähnlich wie bei der Registrierung enthält diese Komponente Eingabefelder für Benutzernamen und Passwort sowie einen Anmeldebutton. Die Methode login() wird beim Klicken des Buttons aufgerufen und ruft die Anmeldefunktion auf.
Die eigentliche Implementierung der Registrierungs- und Anmeldefunktionen erfolgt in den entsprechenden Methoden mithilfe von externen API-Aufrufen (zum Beispiel registerUser und loginUser).
## Datenverwaltung und Anzeige
### Thymeleaf mit HTMX
In diesem Codebeispiel haben wir eine Seite erstellt, um die Datenverwaltung und Anzeige zu demonstrieren:
- **Datenanzeige**: Wir verwenden die Thymeleaf-Schleife th:each zum Durchlaufen der dataList, die die darzustellenden Daten enthält. Für jedes Datenobjekt wird ein
erstellt, das den Namen des Elements anzeigt, sowie ein „Löschen“-Button. Beim Klicken des „Löschen“-Buttons wird das entsprechende Datenobjekt entfernt.
- **Datenhinzufügung**: Wir haben ein Formular erstellt, das beim Absenden eine POST-Anfrage an /addItem sendet, um ein neues Element zur Datenliste hinzuzufügen. Das Ergebnis wird im
mit der ID dataList angezeigt.
### Vaadin Flow
- **Datenanzeige**: Wir haben eine Grid-Komponente erstellt, um die Daten in tabellarischer Form anzuzeigen. Die Methode addColumn fügt eine Spalte hinzu, um die Daten darzustellen.
- **Datenhinzufügung**: Wir haben ein Eingabefeld und einen Button hinzugefügt, um neue Daten zur Liste hinzuzufügen. Beim Klicken des Buttons wird die Methode addData aufgerufen, die die Daten zur Liste hinzufügt und die Grid-Komponente aktualisiert.
### Hilla
- **Datenanzeige**: Im firstUpdated-Lifecycle-Hook rufen wir die Methode getDataList() auf, um die Datenliste abzurufen und in der Property dataList zu speichern. Diese Daten werden dann mithilfe von map im Template in Form einer ungeordneten Liste dargestellt.
- **Datenhinzufügung**: Wir haben ein Eingabefeld und einen Button hinzugefügt, um neue Daten zur Liste hinzuzufügen. Beim Klicken des Buttons wird die Methode addData() aufgerufen, die die Methode addDataItem() aufruft, um das neue Element hinzuzufügen, und anschließend die Datenliste aktualisiert.
## Formulare und Validierung
### Thymeleaf mit HTMX
- **Name**: Das Eingabefeld für den Namen enthält die Attribute required, minlength und maxlength, um die Eingabe zu validieren. Das pattern-Attribut definiert eine RegEx für erlaubte Zeichen (Buchstaben und Leerzeichen). Fehlermeldungen werden mit dem th:errors-Tag angezeigt, wenn die Validierung fehlschlägt.
- **E-Mail**: Ähnlich wie beim Namen ist das Eingabefeld für die E-Mail mit dem Attribut required versehen. Fehlermeldungen werden ebenfalls mit th:errors angezeigt.
- **Formularabsenden**: Das Formular wird beim Absenden mithilfe von HTMX validiert und an den Server gesendet. Das Ergebnis wird im
