Jonas Hahn - Blog und Referenzen

Monitoring ist wie Rasen mähen

2026-09-25T00:00:00+02:00

1. Monitoring ist wie Rasen mähen – warum man nie fertig ist

Ist das Monitoring erst einmal aufgesetzt und eingeschwungen, ist die Freude groß: Alle wichtigen Metriken auf dem Dashboard, keine offenen Alerts. Arbeit erledigt.

Leider ist es nicht so einfach. Ein Monitoring lebt davon, dauerhaft gepflegt zu werden. Neue Systeme kommen dazu, die Last verändert sich, neue Versionen werden deployt, Alerts wollen nachjustiert werden. Und die anfangs gute Alert-Moral bröckelt, weil gerade ein neuer Kunde onboarded oder ein wichtiges Feature gebaut wird.

Es ist wie beim Rasen: Nur weil man einmal gemäht hat, bleibt er nicht für immer kurz. Zwei Wochen nicht gemäht, und das Unkraut wächst. Nach einem Monat verholzt es, nach einem halben Jahr steht dort ein kleiner Wald. Was anfangs eine Fingerübung war, wird zum Kraftakt, der sich immer schwerer einplanen lässt – also macht es niemand.

Deshalb: dranbleiben. Monitoring aktuell halten, regelmäßig aufräumen, Auffälligkeiten nachgehen. Und wenn es doch einmal verwildert ist (das passiert jedem), nicht resignieren, sondern den Rhythmus wieder aufnehmen.

2. Der “Broken Windows”-Effekt – warum Kleinigkeiten zählen

Eine saubere Straße, ein Fenster geht kaputt, niemand repariert es. Andere sehen das kaputte Fenster und kümmern sich auch weniger. Weitere Fenster gehen zu Bruch – am Ende stehen verfallene Häuser und brennende Autos.

Im Betrieb sind die zerbrochenen Fenster die kleinen Dinge: ein Alert, den alle ignorieren. Pods, die „halt manchmal“ neu starten. Speicher, der dauerhaft am Limit läuft. Fehler im Log, die „schon immer da waren“. Werden die kleinen Dinge erst einmal hingenommen, kann man sie irgendwann nicht mehr von den großen unterscheiden. Und plötzlich verbringt man mehr Zeit damit, das System am Laufen zu halten, als es weiterzuentwickeln.

3. Der Schmetterlingseffekt – jede Kleinigkeit ist ein Geschenk

Ein Beispiel, das ich so oder so ähnlich schon mehrfach erlebt habe: 30 Pods laufen, ab und zu startet einer ohne erkennbaren Grund neu. Der Service läuft ja weiter, also kümmert sich niemand darum. Dann kommt Last, und die Plattform steht plötzlich komplett. Unter Stress wird neu gestartet, hoch- und runterskaliert – und die eigentliche Ursache wird wieder nicht gefunden.

Die seltenen Neustarts waren der Flügelschlag des Schmetterlings: ein frühes Signal für ein tieferliegendes Problem. Ich sehe solche kleinen Auffälligkeiten deshalb als Geschenk. Man bekommt einen Hinweis, dass etwas nicht stimmt, und hat noch die Ruhe, der Ursache in aller Gründlichkeit nachzugehen. Später, mitten im Incident, hat man diese Ruhe nicht mehr.

4. Der Junge, der „Wolf!“ rief – jede Benachrichtigung muss zählen

Ein Hirtenjunge ruft zum Spaß „Wolf! Wolf!“ und amüsiert sich, wenn die Dorfbewohner angerannt kommen. Als eines Tages wirklich ein Wolf auftaucht, glaubt ihm niemand mehr.

Der Hirtenjunge ist das Monitoring. Wenn Alerts kommen, bei denen es heißt „den kann man ignorieren“, werden irgendwann alle Alerts ignoriert – bis die Kunden anfangen zu rufen. Meine Faustregeln:

Alerts sofort beheben. Geht das nicht schnell, den Alert bewusst stummschalten (Downtime/Acknowledge) und ein Ticket daran hängen.
Nur benachrichtigen, was sofortiges Handeln erfordert. Alles andere gehört aufs Dashboard, nicht in den Chat-Kanal oder auf den Pager. Sonst stumpft man gegen das ständige „Ping! Ping! Ping!“ ab – und der Wolf freut sich über ein Festmahl.

Fazit

Ein gutes Monitoring ist kein Projekt mit Enddatum, sondern eine Gewohnheit. Regelmäßig mähen, kaputte Fenster reparieren, auf die kleinen Flügelschläge achten und nur „Wolf!“ rufen, wenn wirklich einer da ist. Dann wird aus dem ständigen Gefühl, dass gleich etwas Schlimmes passiert, eine Plattform, bei der ein Ausfall wieder die Überraschung ist – und nicht der Normalfall.

There is no silver bullet – warum jede Entscheidung ein Kompromiss ist

2026-05-16T00:00:00+02:00

1. Die Wunderwaffe, die es nicht gibt

Im Volksglauben gibt es genau ein Mittel gegen Werwölfe: die Silberkugel. Ein Schuss, und das Problem ist gelöst. Fred Brooks hat dieses Bild 1986 in seinem Aufsatz „No Silver Bullet“ auf die Softwareentwicklung übertragen: Es gibt keine einzelne Technik, die Softwareentwicklung auf einen Schlag um ein Vielfaches schneller, einfacher oder zuverlässiger macht.

Trotzdem begegnet mir die Suche nach der Silberkugel ständig. Kubernetes soll die Betriebsprobleme lösen, Microservices die Wartbarkeit, die Cloud die Kosten, KI die Entwicklungsgeschwindigkeit. All das kann helfen – aber nichts davon gibt es umsonst.

2. Jeder Vorteil hat seinen Preis

Jede Entscheidung, die man in Architektur und Betrieb trifft, verschiebt Gewichte. Man gewinnt auf der einen Seite und bezahlt auf der anderen. Das ist kein Zeichen einer schlechten Entscheidung, sondern schlicht Physik. Schlecht wird eine Entscheidung erst, wenn man den Preis nicht kennt – oder so tut, als gäbe es keinen.

Ein paar Beispiele, die mir in Projekten immer wieder begegnen:

Entscheidung	Vorteil	Preis
Mehr Redundanz	Ausfallsicherheit	Mehr Komplexität, höhere Kosten, Fragen der Datenkonsistenz
Caching	Geschwindigkeit, entlastete Datenbank	Veraltete Daten, schwierige Invalidierung
Microservices	Unabhängige Deployments und Skalierung	Verteiltes System: Netzwerkfehler, Tracing, Konsistenz
Strikte Resource Limits	Vorhersagbarkeit, Schutz der Nachbarn	Weniger Spielraum bei Lastspitzen, Throttling
Autoscaling	Passt sich der Last an	Kaltstarts, schwankende Kosten, schwerer vorhersagbar
Aggressive Health Checks	Fehler werden schnell erkannt	Fehlalarme und Neustart-Kaskaden unter Last
Normalisiertes Datenmodell	Keine Redundanz, klare Konsistenz	Viele Joins, langsamere Leseabfragen

3. Das CAP-Theorem – der Klassiker unter den Kompromissen

Besonders schön sieht man das Prinzip bei verteilten Systemen. Das CAP-Theorem sagt: Ein verteiltes System kann nicht gleichzeitig Consistency (alle Knoten liefern denselben, aktuellen Stand), Availability (jede Anfrage bekommt eine Antwort) und Partition Tolerance (das System funktioniert weiter, wenn das Netzwerk zwischen den Knoten ausfällt) garantieren.

Oft wird das als „wähle zwei aus drei“ zitiert. Genauer ist: Netzwerkausfälle passieren, man kann sie sich nicht aussuchen. Die eigentliche Frage lautet also: Was soll das System tun, wenn die Verbindung zwischen den Knoten abreißt?

Ein Onlineshop, der „noch 5 auf Lager“ anzeigt, obwohl es nur noch 4 sind, ist ärgerlich, aber verkraftbar – hier ist Verfügbarkeit wichtiger. Ein Kontostand, der doppelt abgebucht werden kann, ist es nicht – hier gewinnt die Konsistenz. Dieselbe Frage, zwei richtige Antworten, je nach Kontext.

Auch Kafka stellt einen vor diese Wahl: Mit acks=all und min.insync.replicas=2 lehnt der Broker Schreibzugriffe lieber ab, als Daten auf nur einer Kopie zu speichern. Und unclean.leader.election.enable entscheidet, ob eine Partition lieber nicht verfügbar ist oder mit einem veralteten Replikat weiterläuft und dabei Daten verliert.

Übrigens hört der Kompromiss nicht auf, wenn das Netzwerk funktioniert. Die Erweiterung PACELC ergänzt: Auch im Normalbetrieb muss man zwischen Latenz und Consistency abwägen. Jede Bestätigung durch ein weiteres Replikat macht die Daten sicherer – und die Antwort langsamer.

4. Stabilität oder Geschwindigkeit?

Ein Beispiel aus dem Alltag vieler Teams ist der Release-Prozess. Wer auf Stabilität optimiert, arbeitet mit Release-Branches, Tags und geplanten Releases mit manuellen Tests. Man weiß genau, was ausgeliefert wird, und Rollbacks sind sauber. Der Preis: langsamere Iteration und viel Verwaltungsaufwand.

Wer auf Geschwindigkeit optimiert, arbeitet auf einem einzigen Branch, und jede Änderung geht automatisch in Produktion. Das Feedback kommt schnell, die Pipeline macht die Arbeit. Der Preis: Man setzt alles auf Testabdeckung und Automatisierung – und was durchrutscht, rutscht direkt in Produktion.

Kann man nicht beides haben? Doch – aber auch das hat seinen Preis. Feature Flags, Canary-Releases, gutes Monitoring und automatische Rollbacks machen schnelle Releases sicher. Dafür muss man sie aufbauen, betreiben und verstehen. Die obere rechte Ecke ist erreichbar, aber teuer erkauft.

Keiner der Ansätze ist falsch. Ein reguliertes Unternehmen braucht vielleicht den ersten, ein junges Startup würde mit ihm nicht überleben.

5. Wenn alle alles wollen

Richtig spannend wird es, wenn die Kompromisse nicht nur technisch sind, sondern Menschen dahinterstehen. Der Fachbereich möchte jede Woche neue Features, der Betrieb am liebsten gar keine Änderungen mehr. Die Security will jede Bibliothek sofort patchen und gleichzeitig alles abschotten, was wiederum jedes Deployment verlangsamt. Das Controlling möchte die Server bis zum Anschlag auslasten, die Nutzer erwarten, dass alles immer sofort antwortet – auch in der Lastspitze, für die man die Reserve gebraucht hätte. Der Datenschutz fordert, so wenig Daten wie möglich zu speichern und sie früh zu löschen, die Revision will alles jahrelang nachvollziehen können. Die Entwicklungsteams wollen ihre Technologien frei wählen, die Architektur hätte gern eine einheitliche Plattform. Und alle wollen das Ganze bis zum nächsten Quartal – natürlich ohne zusätzliches Budget.

Jede dieser Anforderungen ist für sich genommen berechtigt. Zusammen sind sie unerfüllbar. Wer versucht, allen gleichzeitig gerecht zu werden, baut ein System, das alles ein bisschen und nichts richtig kann.

6. Wie man klug abwägt

Wenn es die Silberkugel nicht gibt, bleibt nur eines: bewusst entscheiden. Was mir dabei hilft:

Ziele priorisieren, nicht nur sammeln. „Alles ist wichtig“ ist keine Priorisierung. Eine klare Reihenfolge, etwa „Datensicherheit vor Verfügbarkeit vor Time-to-Market“, macht viele Entscheidungen fast von selbst.
Den Kontext ernst nehmen. Was in einem Projekt die perfekte Lösung war, kann im nächsten genau falsch sein. Best Practices sind Ausgangspunkte, keine Gesetze.
Den Preis benennen. Zu jeder Entscheidung gehört die Frage: Was geben wir dafür auf? Wer den Nachteil kennt, kann ihn überwachen und abfedern.
Umkehrbarkeit beachten. Entscheidungen, die sich leicht rückgängig machen lassen, darf man schnell treffen. Bei Datenmodell, Datenbank oder Cloud-Anbieter lohnt es sich, gründlich nachzudenken.
Entscheidungen dokumentieren. Ein kurzer Architecture Decision Record mit Alternativen und bewusst in Kauf genommenen Nachteilen erspart später lange Diskussionen darüber, „wer sich das denn ausgedacht hat“.
Regelmäßig überprüfen. Last, Team und Anforderungen ändern sich. Was vor zwei Jahren der richtige Kompromiss war, ist es heute vielleicht nicht mehr.

Fazit

Es gibt keine Silberkugel – weder in der Technik noch in der Organisation. Jeder Vorteil hat einen Preis, und die eigentliche Kunst besteht nicht darin, die perfekte Lösung zu finden, sondern darin, den Preis zu kennen, ihn bewusst zu bezahlen und die Entscheidung wieder aufzugreifen, wenn sich die Lage ändert.

IT Archäologie - Der Umgang mit Legacy Systemen

2025-02-04T00:00:00+01:00

Legacy-Systeme sind wie digitale Ruinen – tief in den IT-Landschaften vieler Unternehmen verankert. Sie laufen oft seit Jahrzehnten, niemand weiß mehr genau, wie sie funktionieren, und trotzdem sind sie geschäftskritisch. Ein Update? Unmöglich. Eine Ablösung? Ein Albtraum.

Wie gehst du damit um? Abwarten, modernisieren oder ersetzen? In diesem Beitrag erfährst du, wie du Legacy-Systeme analysierst, Risiken minimierst und sinnvolle Strategien für den Umgang mit IT-Altlasten entwickelst.

Inhaltsverzeichnis

Inhaltsverzeichnis

1. Einleitung – Warum Legacy-Systeme uns noch lange begleiten werden (und warum das spannend ist)

Alte Software stirbt nicht – sie wird nur durch neue ersetzt, die irgendwann selbst alt wird. Und genau hier liegt das Paradox: Sobald ein System stabil, zuverlässig und in der Praxis bewährt ist, ist es bereits auf dem Weg zum Legacy-System.

Ein neues System mag moderner, sicherer oder effizienter sein, aber es kann selten von Anfang an alles, was das alte konnte. Über Jahre oder Jahrzehnte hinweg wurde das bestehende System optimiert, angepasst und von den Nutzer:innen verinnerlicht. Die Geschäftsprozesse haben sich daran ausgerichtet, Workarounds sind entstanden, und niemand denkt mehr über viele Abläufe nach – sie funktionieren einfach.

Irgendwann kommen jedoch die typischen Herausforderungen: Der Support läuft aus, das Wissen darüber schwindet, Sicherheitslücken tauchen auf, und eine Nachfolge muss her. Doch statt das als notwendiges Übel zu sehen, kann genau das der spannendste Teil der Arbeit mit Legacy-Systemen sein.

Denn sich mit einem alten System zu beschäftigen, ist wie eine Mischung aus Detektivarbeit, Archäologie und Puzzlen:
🕵️ Warum wurde etwas genau so umgesetzt?
📜 Welche historischen Entscheidungen stecken in diesem Code?
🧩 Wie hängen die einzelnen Teile zusammen – und was passiert, wenn man eines verändert?

Wer sich darauf einlässt, entdeckt oft faszinierende Lösungen, kreative Workarounds und überraschend clevere Ansätze, die unter den damaligen Bedingungen die beste Wahl waren. Statt sich über vermeintliche Unzulänglichkeiten zu ärgern, kann es sogar Spaß machen, sich in die damalige Denkweise hineinzuversetzen und nachzuvollziehen, warum etwas genau so gebaut wurde.

Und das Beste daran: Diese Systeme laufen nicht ohne Grund seit Jahrzehnten. Sie haben sich bewährt – und sie zu verstehen, heißt, eine kritische Grundlage der IT-Welt zu entschlüsseln.

Dieser Kreislauf aus Verstehen, Modernisieren und Ablösen wird sich nie ganz auflösen – aber wer sich mit Legacy-Systemen richtig auseinandersetzt, kann diesen Übergang bewusster und kontrollierter gestalten. In diesem Beitrag erfährst du, wie du alte Systeme analysierst, Wissen sicherst und den richtigen Umgang mit IT-Altlasten findest. Und wer weiß? Vielleicht macht es dir sogar mehr Spaß, als du denkst. 😉

2. Spurensuche: Was tut das System – und warum?

Bevor du an einem Legacy-System etwas änderst, musst du verstehen, warum es überhaupt so funktioniert, wie es funktioniert. Ein alter Code, der auf den ersten Blick unsinnig erscheint, könnte eine tief verwurzelte fachliche Anforderung umsetzen – oder einen historischen Workaround enthalten, der essenziell für den Betrieb ist.

Historische und fachliche Hintergründe verstehen

Legacy-Systeme sind selten das Ergebnis eines perfekten Plans. Sie sind über Jahre oder Jahrzehnte gewachsen, geprägt von Geschäftsentscheidungen, technischen Einschränkungen und pragmatischen Lösungen. Daher ist es entscheidend, sich in die Denkweise der ursprünglichen Entwickler:innen und Nutzer:innen hineinzuversetzen.

Fragen, die du klären solltest:

Warum wurde das System ursprünglich entwickelt? War es eine interne Lösung, ein externer Standard oder ein Notbehelf, der einfach nie ersetzt wurde?
Welche Geschäftsprozesse hängen daran? Welche Abteilungen und Nutzer:innen sind darauf angewiesen, und was passiert, wenn das System ausfällt?
Welche alten Anforderungen gibt es noch? Oft sind Regeln und Prozesse in Software gegossen, die so nicht mehr dokumentiert sind, aber im Alltag unverzichtbar sind.

Eine Möglichkeit, sich dem System zu nähern, ist das Gespräch mit langjährigen Mitarbeiter:innen. Sie wissen oft nicht, wie der Code funktioniert, aber sie können erklären, warum das System so genutzt wird.

Technische Abhängigkeiten analysieren

Neben den fachlichen Hintergründen sind auch die technischen Abhängigkeiten kritisch. Viele Legacy-Systeme sind eng mit anderen Anwendungen oder Datenbanken verflochten, und Änderungen an einer Stelle können unerwartete Folgen haben.

Wichtige Aspekte der Analyse:

Welche externen Systeme greifen auf das Legacy-System zu? Gibt es Schnittstellen zu anderen Softwarelösungen oder automatisierte Prozesse, die davon abhängen?
Welche Technologien und Frameworks werden genutzt? Manche alte Bibliotheken sind nicht mehr kompatibel mit modernen Umgebungen, was eine Migration erschwert.
Gibt es proprietäre oder maßgeschneiderte Lösungen? Selbstgeschriebene Module oder alte Hardware können die Modernisierung verkomplizieren.

Hier helfen Tools zur Code-Analyse, Dependency-Scanner oder einfach detaillierte Logfiles, um nachzuvollziehen, welche Komponenten miteinander kommunizieren.

Am Ende dieser Spurensuche solltest du ein klares Bild davon haben, warum das System so ist, wie es ist – und welche Risiken eine Veränderung mit sich bringt. Erst dann kannst du fundierte Entscheidungen treffen, ob eine Modernisierung, Migration oder eine schrittweise Ablösung sinnvoll ist.

3. Die Jagd nach Dokumentation – Was ist noch auffindbar?

Eines der größten Probleme bei Legacy-Systemen: Die ursprüngliche Dokumentation ist oft unvollständig, veraltet oder schlicht nicht mehr auffindbar. Doch bevor du das System komplett auseinandernehmen musst, lohnt es sich, nach Spuren zu suchen. Manchmal gibt es versteckte Schätze – alte Handbücher, vergessene Wikis oder Kommentare im Code, die Hinweise auf die Funktionsweise geben.

Alte Handbücher, Kommentare im Code und versteckte Schätze

Auch wenn niemand genau weiß, wie das System funktioniert, bedeutet das nicht, dass es keine Dokumentation gibt. Du musst sie nur finden.

Mögliche Quellen:

Archivierte Handbücher oder interne Wikis – Oft schlummern alte PDFs oder Word-Dokumente irgendwo auf Netzlaufwerken oder in E-Mail-Anhängen. Frage gezielt nach früheren Unterlagen, selbst wenn sie veraltet sind.
Kommentare im Code – Manchmal sind sie Gold wert, manchmal sind sie nutzlos oder sogar irreführend. Aber sie können Hinweise auf wichtige Geschäftslogik oder frühere Probleme geben.
Alte Tickets oder Change-Logs – Falls es ein Ticket-System gibt, kann es nützlich sein, alte Änderungsanfragen durchzusehen. Sie verraten oft, warum bestimmte Entscheidungen getroffen wurden.
Datenbankstrukturen und Skripte – Wer keine funktionale Dokumentation hat, kann manchmal durch Datenbank-Schemata und gespeicherte Prozeduren die ursprüngliche Systemlogik rekonstruieren.

Es ist wichtig, alle gefundenen Informationen kritisch zu hinterfragen. Legacy-Dokumentation ist selten fehlerfrei. Manche Infos stammen aus einer Zeit, als das System noch in einem ganz anderen Zustand war. Nutze sie als Orientierung, aber verlasse dich nicht blind darauf.

Reverse Engineering als letzte Rettung

Wenn keine Dokumentation existiert – oder sie völlig unbrauchbar ist –, bleibt nur der Weg des Reverse Engineering. Das bedeutet, das System Stück für Stück auseinanderzunehmen, um herauszufinden, wie es funktioniert.

Möglichkeiten des Reverse Engineering:

Code-Analyse – Falls der Quellcode vorhanden ist, kann statische Code-Analyse helfen, Abhängigkeiten, kritische Funktionen und unerwartete Verknüpfungen zu identifizieren.
Logging und Monitoring – Durch das gezielte Beobachten von Logs und Systemverhalten lassen sich wichtige Prozesse rekonstruieren. Welche Abfragen laufen gegen die Datenbank? Welche API-Aufrufe gibt es?
Blackbox-Testing – Falls kein Zugriff auf den Code besteht, können gezielte Tests mit Eingaben und erwarteten Ausgaben helfen, verborgene Logik zu verstehen.
Alte Versionen vergleichen – Falls frühere Versionen des Systems verfügbar sind, lohnt sich ein Vergleich. Welche Änderungen wurden vorgenommen? Gibt es Code, der historisch gewachsen ist und nun keine Funktion mehr hat?

Reverse Engineering ist mühsam, aber es hilft, die fehlenden Puzzlestücke zusammenzusetzen. Und sobald du eine bessere Vorstellung vom System hast, solltest du unbedingt eine eigene neue Dokumentation erstellen – denn wenn du es jetzt nicht tust, wird es später noch schwieriger.

4. Wissensträger aufspüren – Wer erinnert sich noch?

Ein Legacy-System ist mehr als nur Code – es ist das Ergebnis von jahrelanger Erfahrung, unzähligen Entscheidungen und oft auch Workarounds, die nur wenigen bekannt sind. Wenn du verstehen willst, wie es wirklich funktioniert, kommst du an den Menschen, die es gebaut, gewartet oder genutzt haben, nicht vorbei. Auch wenn das System alt ist, gibt es fast immer noch jemanden, der sich daran erinnert – du musst diese Personen nur finden.

Ehemalige Entwickler:innen, langjährige Mitarbeiter:innen und externe Expert:innen

Viele Legacy-Systeme wurden von Teams entwickelt, die längst nicht mehr existieren. Aber das bedeutet nicht, dass ihr Wissen verloren ist. Oft sind frühere Entwickler:innen noch im Unternehmen tätig, nur eben in anderen Abteilungen oder Projekten. Auch langjährige Mitarbeiter:innen aus der Fachabteilung sind wertvolle Quellen – sie haben das System vielleicht nie programmiert, aber sie wissen, warum bestimmte Prozesse so laufen, wie sie laufen.

Wen du suchen solltest:

Ehemalige Entwickler:innen und Administrator:innen – Sie können erklären, warum bestimmte Design-Entscheidungen getroffen wurden.
Langjährige Nutzer:innen – Sie kennen versteckte Funktionen, Abhängigkeiten und typische Fehlerbilder.
Externe Dienstleister oder Berater:innen – Falls das System von einem externen Unternehmen entwickelt wurde, gibt es möglicherweise noch Ansprechpartner:innen.
Mitarbeiter:innen kurz vor der Rente – Oft haben genau sie das tiefste Wissen über das System, das ansonsten verloren gehen könnte.

Der Schlüssel ist, diese Personen aktiv zu befragen, bevor ihr Wissen unwiederbringlich verschwindet.

Wissen sichern, bevor es verloren geht

Sobald du Wissensträger:innen gefunden hast, solltest du so viel wie möglich dokumentieren. Ein lockeres Gespräch hilft dir zwar beim Verständnis, aber wenn du die Informationen nicht systematisch sicherst, sind sie bald wieder vergessen.

Gute Methoden zur Wissenssicherung:

Interviews führen und dokumentieren – Lass dir Abläufe, Hintergründe und typische Probleme erklären und schreibe alles mit.
Alte E-Mails, Notizen oder Protokolle durchsuchen – Manche Entscheidungen sind dokumentiert, nur eben nicht da, wo du sie erwartest.
Diagramme und Skizzen erstellen – Viele Prozesse lassen sich besser visuell erfassen als durch lange Textbeschreibungen.
Schritt-für-Schritt-Anleitungen aus Nutzer:innen-Sicht erstellen – Was heute für dich klar ist, könnte in wenigen Jahren wieder Rätsel aufgeben.

Dabei ist es wichtig, Informationen aus verschiedenen Quellen zu kombinieren. Selten kennt eine einzelne Person das gesamte System – oft hat jede:r nur ein Puzzlestück.

Trust Nobody: Warum „Dazu gibt es keine Doku“ fast nie stimmt

Ein Satz, den du oft hören wirst: „Dazu gibt es keine Dokumentation.“ Oder: „Das hat noch nie jemand dokumentiert.“ Glaube das nicht!

In den allermeisten Fällen existiert irgendwo Dokumentation – sie wurde nur vergessen, nicht gepflegt oder ist schwer auffindbar. Vielleicht steht sie in einem alten Wiki, vielleicht in einer E-Mail-Kette, vielleicht auf Papier in einem Ordner im Archiv. Manchmal steckt die Dokumentation auch im Code selbst, in Konfigurationsdateien oder in alten Ticket-Systemen.

Typische Irrtümer:

„Niemand weiß, wie das funktioniert.“ → Jemand wusste es mal. Die Frage ist: Wer war das?
„Es gibt keine Dokumentation.“ → Es gibt wahrscheinlich Fragmente – sie müssen nur gefunden oder rekonstruiert werden.
„Das hat noch nie jemand angefasst.“ → Wenn es läuft, hat es jemand irgendwann zum Laufen gebracht. Diese Person hatte eine Idee, wie es funktionieren sollte.

Der beste Ansatz ist also: Fragen, suchen und niemals akzeptieren, dass es gar keine Informationen gibt. Fast immer gibt es mehr, als es auf den ersten Blick scheint – du musst nur hartnäckig genug sein.

5. Vom hohen Ross herunterkommen – Legacy mit Respekt begegnen

Wer sich mit Legacy-Systemen beschäftigt, stolpert schnell über absurde Konstrukte, veraltete Technologien und Instabilitäten, die nach heutigen Maßstäben schwer verständlich sind. Der Reflex ist oft, sich darüber lustig zu machen: „Wie konnte man sowas jemals so umsetzen?“ oder „Das ist ja völliger Wahnsinn!“

Doch dieser Blickwinkel hilft nicht weiter. Stattdessen ist es wichtig, sich in die damalige Zeit und die damaligen technologischen Möglichkeiten hineinzuversetzen. Legacy-Code ist selten das Ergebnis von Inkompetenz – vielmehr ist es ein Produkt seiner Zeit, entstanden unter bestimmten Rahmenbedingungen, wirtschaftlichen Zwängen und technischen Limits.

Die Umstände verstehen, anstatt vorschnell zu urteilen

Als das System entwickelt wurde, gab es andere Hardware, andere Software und andere Prioritäten. Vielleicht war Speicherplatz teuer, vielleicht war die Rechenleistung begrenzt, vielleicht gab es keine bessere Lösung als genau diese. Manchmal war ein scheinbar chaotischer Workaround die einzige Möglichkeit, um das Geschäft am Laufen zu halten.

Wichtige Fragen, um den historischen Kontext zu verstehen:

Welche technologischen Einschränkungen gab es damals? Nicht alles, was heute trivial ist, war es damals auch. Speicherplatz, Rechenleistung und Netzwerkanbindungen waren oft extreme Engpässe.
Welche geschäftlichen Anforderungen standen im Vordergrund? Manche Systeme wurden in kürzester Zeit unter immensem Druck entwickelt, um einen wichtigen Kunden zu gewinnen oder eine Marktchance nicht zu verpassen.
Welche Alternativen hätte es damals gegeben? Vielleicht gab es schlicht keine besseren Lösungen – oder die aktuell beste Praxis war eine andere als heute.

Wer diese Fragen stellt, kann oft erkennen, dass viele der alten Entscheidungen Sinn ergaben. Sie sind nicht zufällig oder aus Unwissenheit entstanden, sondern hatten ihre Berechtigung.

Respekt für die Menschen, die das System betreiben

Nicht nur die Technologie ist alt – auch die Menschen, die das System täglich nutzen und betreiben, haben sich über Jahre daran gewöhnt. Viele von ihnen haben tiefes Wissen über Abläufe, Stolperfallen und Workarounds, das nicht einfach in eine neue Software übertragen werden kann.

Wichtige Erkenntnisse für die Arbeit mit Legacy-Systemen:

Niemand ist „schuld“ am aktuellen Zustand. Ein System wächst mit den Jahren, und oft gab es nie den perfekten Moment für eine vollständige Ablösung.
Der aktuelle Zustand ist nicht per se schlecht. Er hat vielleicht Schwächen, aber er hält das Geschäft am Laufen und zahlt die Gehälter.
Eine schlechte neue Lösung ist schlimmer als ein stabiler alter Wust. Ein altes System, das verstanden wird, ist oft wertvoller als ein modernes, das nicht zuverlässig funktioniert.
Die Menschen, die es betreiben, wissen oft mehr als du denkst. Sie haben über Jahre gelernt, mit den Eigenheiten des Systems umzugehen. Ihre Erfahrung ist essenziell für jede Veränderung.

Das bedeutet nicht, dass Legacy-Systeme unantastbar sind – aber es bedeutet, dass jede Veränderung mit Respekt und Verständnis angegangen werden sollte. Wer glaubt, alles besser zu wissen, wird schnell scheitern. Wer hingegen die Vergangenheit versteht und mit den aktuellen Betreiber:innen zusammenarbeitet, kann nachhaltig verbessern, ohne wertvolles Wissen und bewährte Abläufe zu zerstören.

6. Eigene Dokumentation erstellen – und verbessern

Legacy-Systeme haben oft eine alte Dokumentation – und selbst wenn sie voller Fehler oder Lücken ist, hat sie trotzdem einen Wert. Sie einfach zu überschreiben oder zu „korrigieren“ wäre riskant, denn oft enthalten auch fehlerhafte oder unvollständige Dokumente wertvolle historische Informationen. Gleichzeitig darf es beim nächsten Mal nicht zwei widersprüchliche Versionen geben. Die Herausforderung besteht also darin, das alte Wissen zu bewahren, es aber durch eine neue, verlässliche Dokumentation zu ergänzen.

Die alte Doku als historische Referenz erhalten

Grundsatz: Die ursprüngliche Dokumentation bleibt unangetastet und wird nicht mit neuen Erkenntnissen „verschlimmbessert“. Statt sie zu überarbeiten, sollte sie als historische Quelle betrachtet und klar als solche gekennzeichnet werden.

Wie du das umsetzt:

Originale archivieren – Falls möglich, eine unveränderte Kopie der alten Doku an einem sicheren Ort speichern.
Versionierung nutzen – Eine neue Dokumentation sollte nicht die alte ersetzen, sondern ergänzen, etwa durch klare Versionsbezeichnungen („Legacy-Doku – Stand 2005“ vs. „System-Doku – aktualisiert 2025“).
„Read-Only“-Modus für alte Dokus – In einem Wiki oder Dokumentationssystem kann die alte Doku schreibgeschützt bereitgestellt werden, damit sie nicht versehentlich verändert wird.
Hinweise einfügen – Falls Fehler oder veraltete Informationen bekannt sind, können ergänzende Anmerkungen oder Warnhinweise hinzugefügt werden, aber ohne den Originaltext zu überschreiben.

Eine neue, verlässliche Dokumentation aufbauen

Da die alte Doku nicht verändert wird, muss die neue Dokumentation sauber getrennt, aber eng verknüpft mit der alten existieren. Die neue Doku sollte aus verschiedenen Quellen gespeist werden und als aktuelle, zuverlässige Wissensbasis dienen.

So vermeidest du widersprüchliche Versionen:

Quellen sauber kennzeichnen – Falls neue Erkenntnisse aus Gesprächen mit Nutzer:innen oder aus Reverse Engineering stammen, sollte das in der neuen Doku klar gemacht werden.
Unterschiede zwischen alter und neuer Doku dokumentieren – Falls es Widersprüche gibt, sollte in der neuen Doku ein Abschnitt stehen, der die Abweichungen erklärt („In der alten Doku steht X, aber in der Praxis ist es Y“).
Alte und neue Doku verlinken – Damit niemand mit zwei isolierten Versionen arbeiten muss, sollte die neue Doku klar auf die alte verweisen („Historische Doku zu diesem Modul befindet sich hier: …“).
Begrenzte Verantwortlichkeit klären – Wer aktualisiert die neue Dokumentation? Wer trägt die Verantwortung, dass neue Erkenntnisse sauber dokumentiert werden, ohne das alte Wissen zu überschreiben?

Das Wissen aus verschiedenen Quellen bündeln

Während die alte Doku oft nur einen Teilaspekt eines Systems abbildet, kann die neue Doku durch weitere Quellen ergänzt werden:

Code-Kommentare analysieren – Gibt es versteckte Hinweise oder unerwartete Logik?
Interviews mit erfahrenen Nutzer:innen und Entwickler:innen – Wo gibt es Workarounds oder mündlich überliefertes Wissen?
Beobachtungen durch Logs und Systemverhalten – Welche Prozesse laufen tatsächlich ab?
Reverse Engineering und Tests – Welche Annahmen aus der alten Doku stimmen noch, welche nicht?

Diese Erkenntnisse sollten in die neue Dokumentation einfließen – aber immer mit Quellenangaben und klarer Kennzeichnung, was wirklich belegt ist und was nur vermutet wird.

Fazit: Die Vergangenheit bewahren, die Zukunft dokumentieren

Eine alte Dokumentation ist ein historisches Artefakt – sie mag ungenau sein, aber sie erzählt, wie das System ursprünglich gedacht war. Sie sollte nicht mit Halbwissen überschrieben werden, sondern als unveränderliche Quelle erhalten bleiben. Gleichzeitig muss es eine verlässliche neue Doku geben, die das System so beschreibt, wie es heute funktioniert.

Wenn du es richtig machst:
✅ Die alte Doku bleibt erhalten und wird als Referenz genutzt.
✅ Die neue Doku ist klar strukturiert, aktuell und widerspricht der alten nicht einfach, sondern erklärt Abweichungen.
✅ Niemand muss sich mehr durch zwei konkurrierende Versionen kämpfen – alle Infos sind an einem Ort, gut verlinkt und verständlich dokumentiert.

So stellst du sicher, dass beim nächsten Mal nicht wieder jemand bei null anfängt.

7. Strategien für den Umgang mit Legacy-Systemen

Legacy-Systeme sind unvermeidlich – die Frage ist nicht, ob man sie modernisiert, sondern wie. Irgendwann kommt der Punkt, an dem das alte System an seine Grenzen stößt: Hardware läuft aus dem Support, Sicherheitslücken häufen sich, und neue Anforderungen lassen sich kaum noch umsetzen. Dann stellt sich die zentrale Frage: Modernisieren, migrieren oder ersetzen? Jede dieser Strategien hat Vor- und Nachteile, und die richtige Wahl hängt von vielen Faktoren ab.

Modernisieren: Das Bestehende verbessern

Die sanfteste Strategie ist die Modernisierung – also das schrittweise Anpassen und Optimieren des bestehenden Systems, ohne es vollständig abzulösen.

Typische Maßnahmen:
✅ Code-Refactoring, um Wartbarkeit zu verbessern
✅ Austausch veralteter Komponenten (z. B. Datenbank-Updates, Schnittstellenmodernisierung)
✅ Virtualisierung oder Containerisierung, um alte Software stabiler laufen zu lassen
✅ Automatisierte Tests einführen, um Änderungen sicherer zu machen

Wann ist das sinnvoll?

Wenn das System stabil läuft und weiterhin gut genutzt wird
Wenn die Kernlogik noch funktioniert, aber technische Schulden beseitigt werden müssen
Wenn eine vollständige Ablösung zu teuer oder riskant ist

Risiken:

Der Modernisierungsaufwand kann unterschätzt werden
Es bleibt immer noch ein altes System – mit alten Problemen
Irgendwann stößt man trotzdem an eine Grenze

Modernisierung ist oft ein guter Mittelweg, wenn ein System noch längere Zeit genutzt werden soll, aber dringend eine technische Auffrischung braucht.

Migrieren: Schrittweise auf eine neue Plattform überführen

Migration bedeutet, das System in Teilen auf eine modernere Plattform oder Technologie zu überführen, ohne es komplett neu zu entwickeln.

Typische Ansätze:
✅ Schrittweiser Umzug auf eine neue Architektur (z. B. von On-Premise zu Cloud)
✅ Modularisierung – das alte System entkoppeln und einzelne Komponenten ersetzen
✅ Umschalten auf moderne Schnittstellen (z. B. APIs statt direkter Datenbankzugriffe)

Wann ist das sinnvoll?

Wenn das alte System technisch nicht mehr tragbar ist, aber nicht auf einen Schlag ersetzt werden kann
Wenn bestimmte Komponenten erneuert werden müssen, aber der Rest noch funktioniert
Wenn eine sanfte Transition nötig ist, um Geschäftsrisiken zu minimieren

Risiken:

Migrationsprojekte ziehen sich oft länger als geplant
Hybrid-Phasen (alter und neuer Code parallel) können komplex sein
Altdaten und Abhängigkeiten machen den Wechsel schwierig

Migration kann eine clevere Strategie sein, wenn das Endziel eine neue Plattform ist, aber ein „Big Bang“-Wechsel zu riskant wäre.

Ersetzen: Komplette Neuentwicklung

Die radikalste, aber oft auch nachhaltigste Lösung ist ein kompletter Neustart: Das alte System wird ersetzt, die Geschäftslogik neu gedacht, und moderne Technologien kommen zum Einsatz.

Wann ist das sinnvoll?

Wenn das alte System unwartbar ist und nicht mehr weiterbetrieben werden kann
Wenn Geschäftsprozesse sich so stark verändert haben, dass das alte System nicht mehr passt
Wenn eine langfristige Strategie auf eine komplett neue Technologie setzt

Risiken:
🚨 Sehr hohe Kosten und Entwicklungsaufwand
🚨 Gefahr, wichtige Details aus dem alten System zu übersehen
🚨 Widerstand von Nutzer:innen, die mit dem alten System vertraut sind

Schlimmer als ein altes System ist ein neues, das nicht funktioniert!
Deshalb ist es essenziell, von Anfang an die Fachabteilungen einzubinden, um sicherzustellen, dass das neue System wirklich das kann, was gebraucht wird – und nicht nur das, was „modern“ klingt.

Risiken und Chancen abwägen

Egal, welche Strategie du wählst: Jede hat ihre Fallstricke.

Kritische Fragen, bevor du entscheidest:
🔹 Wie lange soll das System noch genutzt werden?
🔹 Wie abhängig sind andere Systeme davon?
🔹 Gibt es noch Expert:innen, die das alte System verstehen?
🔹 Wie hoch sind die Kosten und Risiken eines kompletten Wechsels?
🔹 Welche Ressourcen stehen zur Verfügung?

Manchmal reicht eine Modernisierung, manchmal ist eine schrittweise Migration die beste Lösung. Und manchmal führt kein Weg an einem kompletten Ersatz vorbei. Entscheidend ist, nicht einfach aus einem Bauchgefühl heraus zu handeln, sondern mit einer klaren Strategie.

Fazit: Es gibt keinen Königsweg – nur die beste Entscheidung für deine Situation

Jedes Unternehmen, jedes System und jede Situation ist anders. Die richtige Strategie hängt von den technischen Gegebenheiten, dem Budget und den Geschäftszielen ab.

💡 Die Kunst liegt nicht darin, Legacy-Systeme zu hassen – sondern sie zu verstehen und mit ihnen sinnvoll umzugehen.

Denn egal, wie modern das neue System ist – eines Tages wird es selbst zum Legacy-System werden. 😉

8. Entscheidungen gemeinsam treffen – Das Team einbinden

Die Entscheidung, was mit einem Legacy-System passiert, darf nicht im Alleingang getroffen werden. Die besten Strategien scheitern, wenn das bestehende Team – die Menschen, die täglich mit dem System arbeiten – nicht eingebunden wird. Sie kennen die Schwachstellen, wissen, was im Alltag wirklich gebraucht wird, und haben oft wertvolle Erfahrung mit Workarounds, die nicht in der Dokumentation stehen.

Warum ist das so wichtig?
✅ Die Entscheidung wird von denen mitgetragen, die sie umsetzen müssen.
✅ Kritisches Wissen über das System bleibt erhalten.
✅ Widerstände werden früh erkannt und können berücksichtigt werden.
✅ Es entstehen bessere Lösungen, weil verschiedene Perspektiven eingebracht werden.

Die 6-Hüte-Methode von de Bono für fundierte Entscheidungen

Bei komplexen Entscheidungen lohnt es sich, die 6-Hüte-Methode von Edward de Bono anzuwenden. Diese Methode hilft, verschiedene Blickwinkel systematisch zu betrachten, anstatt vorschnelle oder emotional getriebene Entscheidungen zu treffen.

👒 Die sechs Denk-Hüte:

Weiß → Fakten, Daten und objektive Informationen
Rot → Emotionen, Bauchgefühl und Intuition
Schwarz → Risiken, Probleme und kritische Aspekte
Gelb → Chancen, Vorteile und positive Aspekte
Grün → Kreative Ideen und neue Lösungsansätze
Blau → Prozesssteuerung, Struktur und Überblick behalten

Durch diese Technik wird sichergestellt, dass alle Aspekte einer Entscheidung durchdacht werden – nicht nur die technischen, sondern auch die menschlichen und geschäftlichen.

Systemisches Konsensieren – Die beste Lösung mit geringstem Widerstand

Eine weitere Methode, um tragfähige Entscheidungen zu treffen, ist systemisches Konsensieren. Dabei geht es nicht darum, die lauteste Meinung oder die Mehrheit durchzusetzen, sondern eine Lösung zu finden, die den geringsten Widerstand im Team erzeugt.

Wie funktioniert systemisches Konsensieren?

Alle Beteiligten schlagen Lösungen vor.
Jede:r bewertet jede Lösung – nicht nach Zustimmung, sondern nach Widerstand (Skala von 0 bis 10).
Die Lösung mit dem geringsten Gesamt-Widerstand wird gewählt.

Warum ist das sinnvoll?
🔹 Starke Widerstände werden sichtbar und können diskutiert werden.
🔹 Die Lösung ist nachhaltig, weil sie von den meisten mitgetragen wird.
🔹 Es wird verhindert, dass Einzelne Entscheidungen dominieren oder übergangen werden.

Gerade bei Legacy-Systemen, die viele Betroffene haben, sorgt systemisches Konsensieren dafür, dass die Veränderung nicht als Bedrohung, sondern als gemeinsame Lösung wahrgenommen wird.

Fazit: Entscheidungen nicht über Köpfe hinweg treffen

Ein Legacy-System mag technisch überholt sein – aber die Menschen, die es betreiben, sind der Schlüssel zum Erfolg. Wer die Expert:innen vor Ort ignoriert, riskiert schlechte Entscheidungen, Widerstände und teure Fehlschläge.

💡 Eine durchdachte Strategie beginnt mit einem gemeinsamen Verständnis und endet mit einer Entscheidung, die alle mittragen.

Und egal, ob modernisiert, migriert oder ersetzt wird: Die beste neue Lösung ist die, die funktioniert – und nicht die, die am „modernsten“ klingt.

9. IT-Archäologie als Schlüssel zur digitalen Zukunft

Legacy-Systeme sind keine Altlasten, die einfach entsorgt werden können – sie sind das digitale Fundament, auf dem Unternehmen über Jahre oder sogar Jahrzehnte gewachsen sind. Wer sie ignoriert oder nur als Problem betrachtet, verkennt ihren Wert. IT-Archäologie bedeutet, diese Systeme mit Respekt zu analysieren, ihre Geschichte zu verstehen und den richtigen Umgang mit ihnen zu finden.

Verstehen, bevor man verändert

Eines der größten Risiken bei der Ablösung oder Modernisierung eines alten Systems ist es, nicht zu wissen, was genau geändert wird. Jede Zeile Code, jede technische Entscheidung und jede historisch gewachsene Struktur hatte einmal einen guten Grund – auch wenn er heute nicht mehr offensichtlich ist. Wer einfach loslegt, ohne diesen Kontext zu verstehen, riskiert gravierende Fehler.

Deshalb ist die wichtigste Lektion: Bevor du entscheidest, was mit einem Legacy-System passiert, musst du verstehen, warum es so ist, wie es ist.

Respekt für das, was funktioniert

Ein altes System mag aus heutiger Sicht fehleranfällig, ineffizient oder schwer wartbar sein – aber es läuft. Es hält das Geschäft am Laufen, sichert Arbeitsplätze und funktioniert oft stabiler, als viele glauben. Schlimmer als ein „Legacy-Wust“ ist eine schlecht durchdachte neue Lösung, die nicht ausgereift ist.

Wer Legacy-Systeme überhastet abschaltet, ohne eine stabile Alternative zu haben, riskiert Chaos und Produktivitätsverluste. Deshalb sollte jede Veränderung wohlüberlegt, gut dokumentiert und mit dem bestehenden Team abgestimmt sein.

Entscheidungen gemeinsam treffen

Ein IT-System ist nicht nur eine technische Struktur, sondern auch ein soziales System. Die Menschen, die es betreiben, haben sich über Jahre daran gewöhnt, wissen, wo die Stolperfallen sind, und haben Lösungen für Probleme gefunden, die nie dokumentiert wurden.

Wer über das Schicksal eines Legacy-Systems entscheidet, ohne die Menschen einzubeziehen, die damit arbeiten, trifft fast immer die falsche Wahl.

Methoden wie die 6-Hüte-Methode von de Bono oder systemisches Konsensieren helfen, unterschiedliche Perspektiven in die Entscheidung einzubeziehen und Lösungen zu finden, die von allen mitgetragen werden.

IT-Archäologie als Investition in die Zukunft

Jedes System, das heute als modern gilt, wird irgendwann selbst zum Legacy-System. Die Art und Weise, wie wir heute mit alten Systemen umgehen, bestimmt, wie zukünftige Generationen mit unseren heutigen Lösungen arbeiten werden. Wer jetzt sorgfältig dokumentiert, Wissen sichert und nachvollziehbare Entscheidungen trifft, spart zukünftigen Teams Zeit, Geld und Frustration.

IT-Archäologie ist deshalb kein nostalgischer Blick zurück – sondern eine notwendige Strategie, um die digitale Zukunft stabil und nachhaltig zu gestalten.

Der Kreislauf endet nie – und das ist okay

Es gibt keine endgültige Lösung für das „Legacy-Problem“. Jedes neue System wird irgendwann selbst alt. Deshalb geht es nicht darum, ein für alle Mal aufzuräumen, sondern darum, einen bewussten und respektvollen Umgang mit IT-Geschichte zu entwickeln.

💡 Die beste Vorbereitung auf die Zukunft ist ein kluger Umgang mit der Vergangenheit.

Und vielleicht sind die Systeme, über die wir heute lächeln, in 20 Jahren das Fundament, auf dem die nächste Generation aufbaut.

📌 Anhang: Checkliste für den Umgang mit Legacy-Systemen

🕵️ 1. Erste Analyse: Was tut das System und warum?

✅ System identifizieren: Welche geschäftskritischen Prozesse hängen daran?
✅ Historische Hintergründe klären: Warum wurde es ursprünglich entwickelt?
✅ Technische Abhängigkeiten analysieren: Welche Systeme greifen darauf zu?
✅ Datenbankstrukturen, API-Schnittstellen und externe Verbindungen prüfen
✅ Prüfen, ob noch Support oder Wartungsverträge existieren

📚 2. Dokumentation suchen und sichern

✅ Existierende Dokumentation aufspüren und archivieren (nicht überschreiben!)
✅ Alte Handbücher, interne Wikis, Change-Logs oder Tickets durchsuchen
✅ Code-Kommentare analysieren: Sind sie nützlich oder irreführend?
✅ Reverse Engineering als letzte Rettung: Falls keine Doku existiert, das System aktiv beobachten und analysieren
✅ Falls mehrere Versionen der Doku existieren: Versionierung klären, alte Doku unverändert archivieren

🗣️ 3. Wissensträger:innen finden und befragen

✅ Mitarbeiter:innen und Entwickler:innen befragen, die das System kennen
✅ Explizit auch langjährige Nutzer:innen einbeziehen – oft kennen sie Workarounds und Kniffe, die nicht dokumentiert sind
✅ Ehemalige Entwickler:innen oder externe Dienstleister:innen kontaktieren
✅ Wichtige Fragen stellen:

Welche Probleme gibt es regelmäßig?
Gibt es mündlich überliefertes Wissen, das nie dokumentiert wurde?
Welche Funktionen sind kritisch für das Geschäft?

📝 4. Eigene Dokumentation erstellen (ohne alte Doku zu zerstören!)

✅ Alte Dokumentation niemals direkt überschreiben – sie bleibt als historische Referenz erhalten
✅ Eigene Notizen in einer neuen Doku strukturieren
✅ Ergänzende Anmerkungen zur alten Doku schreiben (Fehler, veraltete Annahmen, tatsächliches Verhalten)
✅ Diagramme oder Ablaufschemata erstellen, um Prozesse verständlicher zu machen
✅ FAQ-Sektion mit häufigen Problemen und Lösungen einfügen

🤔 5. Entscheidung vorbereiten: Was tun mit dem System?

✅ Ziel definieren: Soll das System modernisiert, migriert oder ersetzt werden?
✅ Alle technischen, wirtschaftlichen und personellen Faktoren abwägen
✅ Verschiedene Lösungen durchspielen und Risiken analysieren
✅ Team einbinden: Entscheidung nicht über die Köpfe der Betroffenen hinweg treffen!
✅ 6-Hüte-Methode von de Bono nutzen, um verschiedene Perspektiven zu berücksichtigen
✅ Systemisches Konsensieren anwenden, um eine tragfähige Lösung mit geringstem Widerstand zu finden

⚙️ 6. Umsetzung der gewählten Strategie

🔹 Wenn das System modernisiert wird:
✅ Code-Refactoring planen und schrittweise umsetzen
✅ Technische Schulden beseitigen, ohne das System instabil zu machen
✅ Virtualisierung oder Containerisierung prüfen, um alte Umgebung stabil zu halten

🔹 Wenn das System migriert wird:
✅ Migrationsstrategie definieren: Parallelbetrieb oder schrittweiser Wechsel?
✅ Datenmigration sicherstellen: Wie werden Altdaten ins neue System überführt?
✅ Automatisierte Tests und Staging-Umgebung aufsetzen, um Fehler frühzeitig zu erkennen

🔹 Wenn das System ersetzt wird:
✅ Sicherstellen, dass alle kritischen Funktionen auch im neuen System vorhanden sind
✅ Pilotbetrieb oder schrittweise Einführung planen, um Risiken zu minimieren
✅ Schulung der Nutzer:innen: Sind alle mit der neuen Lösung vertraut?
✅ Legacy-System nicht sofort abschalten – eine Übergangsphase einplanen!

🎯 7. Abschluss: Sicherstellen, dass das Wissen erhalten bleibt

✅ Finale Dokumentation erstellen – verständlich und aktuell
✅ Wissensträger:innen zur Überprüfung einbinden
✅ Altsystem entweder geordnet archivieren oder sauber abschalten
✅ Lessons Learned dokumentieren: Welche Fehler können in Zukunft vermieden werden?
✅ Sicherstellen, dass die neue Dokumentation gepflegt wird, damit das neue System nicht auch zum unverständlichen Legacy-Problem wird

🛠️ Fazit: Die beste Strategie ist vorausschauendes Handeln

💡 Legacy-Systeme sind nicht einfach nur „Altlasten“ – sie sind bewährte Werkzeuge, die mit Bedacht behandelt werden müssen. Diese Checkliste hilft dir, einen klaren und strukturierten Umgang mit ihnen zu finden.

Und vergiss nicht: Das neue System von heute wird irgendwann selbst zum Legacy-System von morgen. Die Entscheidungen, die du jetzt triffst, bestimmen, wie leicht oder schwer es künftigen Teams fallen wird, damit umzugehen. 😉

Produktionsreife Software Entwicklung

2024-11-09T00:00:00+01:00

Software wird entwickelt und irgendwann läuft diese in produktiven Verhältnissen. Doch was heißt es wirklich produktionsreif Software zu entwickeln. Was, wenn man Software Entwicklung nicht angeht wie der erste Mensch der das Rad entwickelt, sondern auf dem Wissen und der Erfahrung der letzten 60 Jahre aufbaut.

Produktionsreife Software Entwicklung

Software ist nicht produktionsreif, der gesamte Entwicklungsprozess muss produktionsreif sein, inklusive dem Betrieb und allem drum herum. Software ist kein Stuhl der gebaut wird und dann klaglos seinen Dienst tut. Software ist ein ständig lebendes Produkt, welches kontinuierlich weiterentwickelt werden muss (mindestens Bugfixes und Security Upgrades).

Ein Stillstand der Weiterentwicklung bedeutet das langsame Sterben der Software. Entsprechend muss die Software nicht zu einem bestimmten Zeitpunkt gewisse Kriterien erfüllen. Der gesamte Entwicklungsprozess muss diese Kriterien erfüllen und dauerhaft erhalten.

Indikatoren produktiven Denkens

Respekt vor den Nutzer:innen und den Kosten von Ausfällen

Wenn man länger in der Branche tätig ist, ist es oft überraschend und schockierend mit welcher Nonchalance Entwickler:innen und Systemadministrator:innen bereit sind Ausfälle in Kauf zu nehmen. Deployments werden ohne Ankündigung rausgehauen. Tests werden nicht geschrieben und beim ersten Rollout zerbröselt das neue Feature zwischen den Fingern. Bestehende Funktionalität wird im neuen Release kaputt gemacht. Hauptsache das Scrum-Ziel wurde mit Ach-und-Krach noch erreicht. Vorwärts immer, rückwärts nimmer. Dabei ist es unerheblich ob 20 oder 200 Leute betroffen sind, ob ein Ausfall 50.000€ oder 5 Millionen kostet. Es ist extrem schwer ein Bewusstsein hierfür zu schaffen, ich war in Firmen in denen Angestellte die Aussage brachten “XYZ ist ja eh nicht so wichtig, das ist ja das alte System”. Leider war das alte System die Basis der gesamten Firma und für 100% des Umsatzes verantwortlich. Ohne das “unwichtige” System hätte die Firma innerhalb weniger Tage zu machen können.

Oder, verantwortlich für die Business Intelligence Plattform der gesamten Firma: “Wir sind ja nicht das Hauptprodukt und “nur” BI, ist ja nicht so wichtig”. Die Live Optimierung welche auf der BI Landschaft basierte verbesserte das Firmenergebnis um ca. 20%. Die Ziele der 300 Mitarbeiter:innen waren stark an die Zahlen aus dem BI Tool gekoppelt. Die Geschäftsführung traf ihre Entscheidungen anhand der Zahlen der BI Statistiken.

Der ständige Kampf gegen Unwissen und Ignoranz

Es ist eine ständige Sisyphus-Arbeit das Bewusstsein zu schaffen für die Auswirkungen von Ausfällen, die Wichtigkeit von Systemen und Geschäftsprozessen. Jedes Jahr gehen Angestellte und kommen neue hinzu, externe Mitarbeiter:innen verstärken Projekte. Teams werden umstrukturiert. Bestehende Mitarbeiter:innen werden nachlässig oder waren es schon immer.

Was kann man tun?

Verständnis aufbauen für die zentralen Geschäftsprozesse der Firma und die Auswirkungen von Ausfällen
Bei Ausfällen dieses Verständnis immer wieder mit dem Team teilen - nicht als Vorwurf, sondern als reine Fakten und mit starkem Appell, dass Maßnahmen geschaffen werden müssen, diese Art von Ausfällen zukünftig zu verhindern
Immer wieder das aktuelle Verständnis in Präsentationen und Folien einbauen
Direkten Kontakt mit den “Opfern” herstellen - beim gemütlichen Feierabend-Bier, etc. wer live mitbekommt, dass Menschen nicht arbeiten können handelt verantwortungsbewusster

Berücksichtigung des “Dreisatzes” Dev, Staging, Produktion

Auch hier bin ich jedes Mal wieder überrascht wie hemdsärmelig teilweise Teams in Firmen agieren die schon Jahrzehnte im Geschäft sind. Da wird die Software das erste Mal richtig in Produktion getestet - von Hand. Dann gibt es noch alle möglichen Zwischenlösungen. So wird zum Beispiel eine Staging Umgebung eingerichtet, jedoch keine Dev-Umgebung. Daher ist die Staging-Umgebung zu instabil um vernünftige Integrationstests zu fahren und faktisch wird wieder auf Prod getestet. Oder es gibt zwar alle drei Umgebungen, aber die Daten der unterschiedlichen Services sind auf Dev und Staging so unzureichend, dass ein Test wieder nicht möglich ist.

In einer Firma hatten wir den Galgenhumor Spruch: “Straight to PROD. Why not!”

Ein vernünftiger Rollout Prozess

Gehen wir davon aus, dass es gelungen ist die drei Umgebungen Dev, Staging und Produktion alle und sinnvoll aufzusetzen. Rollt man Änderungen nun gleichzeitig auf allen 3 Umgebungen aus hat man - wer hats erraten - nichts gewonnen.

Wie wirds gemacht

Features werden lokal und auf der Dev-Umgebung entwickelt
Sobald alles funktioniert und der Branch in Main gemerged wurde und Main stabil auf Dev läuft wird ein git-Tag erstellt
Diese getaggte Version wird nun auf Staging ausgerollt und getestet
Nach Erfolg wird exakt dieser Tag auf Produktion ausgerollt

Fehler sind unvermeidlich

Teils wird so getan als ob man Fehler vermeiden könnte, oder Fehler optional sind und durch “sauberes” Arbeiten verhindert werden könnten. Dies ist eine Illusion. Standard-Software ist durchzogen von einer unglaublichen Menge an Bugs. Selbst Software im Hochsicherheitsumfeld (Flugzeuge, Raumfahrt, etc.) hat Bugs trotz des unglaublichen Aufwandes der hier getrieben wird diese zu verhindern. Ebenso beim Rollout, etc. Fehler passieren die ganze Zeit und es ist keine Frage ob diese passieren sondern nur wann. Meist wenn man es am wenigsten braucht. Also braucht man Prozesse die diese Fehler frühzeitig sichtbar machen und eine Behebung möglich machen. Beim Rollout müssen alle Betroffenen gewarnt sein: Stichwort Wartungsfenster mit Ankündigung.

Lösungen

Feste Prozesse sorgen dafür, dass Fehler frühzeitig gefunden werden
Die Dev und Staging Umgebungen müssen es ermöglichen realistische Tests zu fahren
Deployments - auch auf Staging - werden angekündigt, sodass alle Nutzer:innen sich darauf einstellen können

Hohe Deploymentgeschwindigkeit trotz sauberer Prozesse

Das Wort “Prozess” klingt unglaublich träge und verstaubt. Das ist was die großen Firmen tun die in der Vergangenheit feststecken denkt man sich, man denkt mit Schrecken an 3 wöchige CAP (Change Advisory Board) Meetings, die außer heißer Luft nichts produzieren. Ein Prozess ist einfach ein definiertes Vorgehen, welches einmalig festgelegt wird, damit Fehler reduziert werden. Ein Abweichen vom Prozess darf nur erfolgen durch Modifikation des Prozesses. Dies verhindert, dass Mitarbeiter:innen in einem Anflug von Selbstüberschätzung Dinge kaputt machen.

Das heißt nicht, dass man ITIL oder anderen existierenden Frameworks folgen muss. Es gibt auch sehr einfache Prozesse die extrem schnell sind.

Beispiel für einen einfachen Prozess

Entwickelt wird auf Dev in einem Featurebranch
Nach erfolgreichem Review (alternativ: freies mergen nach eigenem Ermessen der Entwickler:in) wird in den main-Branch integriert
Auf Staging werden keine Featurebranches deployt, ausschließlich Tags des main-Branches
Das Deployment auf Staging wird angekündigt (z.B. automatisiert durch die Deployment-Pipeline)
Auf Staging erfolgt eine Abnahme - welcher Art auch immer - durch die Endnutzer:innen
Das Deployment auf Production wird angekündigt (z.B. automatisiert durch die Deployment-Pipeline, besser jedoch mit mehr Vorlauf)
Auf der Produktionsumgebung werden ausschließlich Tags deployt welche auf Staging entsprechend von Nutzer:innen abgenommen wurden

Mögliche Einwände

Hier nur ein paar Beispiele für übliche Einwände. Die Antworten sollen zeigen, dass zwar die Symptome real sind, die Lösung jedoch nicht ist den Prozess aufzuweichen, sondern dafür zu sorgen, dass der Prozess funktioniert. Wenn man mit dieser Perspektive an die Probleme ran geht, dann findet man andere Lösungen, als wenn es nur darum geht “Ausnahmen” zu genehmigen.

Auf Dev kann ich nicht vernünftig testen, mein Feature-Branch muss auf Staging laufen –> Die Dev Umgebung muss so verändert werden, dass die Tests auf Dev aussagekräftig sind.
Dann muss ich ja dauernd in main mergen und Tags bauen, wenn ich noch Bugs finde. –> Die Testabdeckung im Code muss verbessert werden, sodass Fehler nicht erst auf Staging bemerkt werden, die Dev Umgebung muss so verändert werden, dass die Tests auf Dev aussagekräftig sind.
Wenn ich auf die Endnutzer:innen Tests warte komme ich nicht weiter –> in gewissen Rahmen kann der Test auch auchs Endnutzer:innen Perspektive von den Entwickler:innen durchgeführt werden.

Betrieb wird mit betrachtet

Oft liegt der Fokus ausschließlich auf der Entwicklung. Features werden am laufenden Band produziert, doch wer kümmert sich darum, dass die Software auch läuft und wirklich den geplanten Mehrwert liefern kann?

Es braucht ein Betriebskonzept welches die wichtigsten Fragen beantwortet:

Wie stellt man fest, dass etwas nicht funktioniert (Best-Case: Monitoring, Worst-Case: Leute beschweren sich)
Wer kümmert sich darum Bugs nachzuverfolgen/nachzustellen
Gibt es einen Vertretungsplan, wenn diese Person ausfällt
Es werden dauerhaft Ressourcen durch Betrieb gebunden, das muss beachtet und eingeplant werden

Monitoring & Alerting

Um einen reibungslosen Betrieb zu gewährleisten ist ein Monitoring der wichtigsten Applikations-Kennzahlen und System-Kennwerte unerlässlich.

Bei außerplanmäßigen Abweichungen soll alarmiert werden, damit das Betriebsteam proaktiv reagieren kann.

Backup

Der Service schnurrt, die User sind zufrieden, es könnte nicht schöner sein. Dann brennt das Rechenzentrum ab ( Feuer bei OVH ).

Wie bei Fehlern sind auch Ausfälle und kompletter Datenverlust unvermeidlich. Es wird passieren, entweder technisch, durch Mitarbeiter:innen oder externe Angreifer:innen.

Je größer der Mehrwert, desto größer der Schaden im Worst-Case Szenario. Wenn eine Applikation kein Backup benötigt ist sie sinnlos - oder nur Erfüllungsgehilf:in für eine andere Applikation, welche dann aber entsprechendes Backup benötigt.

Bewusstsein schaffen für:

Was sind unsere wichtigsten Daten und Abläufe
Wie können wir im Fehlerfall den Schaden gering halten
Regelmäßiges Durchspielen des Ernstfalls. Der Klassiker: wir haben ein Backup, aber wir haben noch nie versucht den Restore durchzuführen. Ein Freund von mir meinte mal: “Niemand will ein Backup … die Leute wollen den Restore!”. Oder anders formuliert: Ohne erfolgreichen Restore ist ein Backup absolut wertlos.

Wert und ständige Kommunikation

Die Wertschöpfung einer Applikation und die positiven Effekte sollten beständig und transparent nach innen und außen kommuniziert werden. Hier geht es nicht darum Fake-News zu verbreiten und Luft-Schlösser zu bauen, sondern klar und realistisch die Wertschöpfung zu kommunizieren.

Es ist wichtig in ständigem Kontakt mit den Nutzer:innen und Profiteur:innen der Applikation zu bleiben. Durch direkte Kontakte, regelmäßige - bevorzugt auch lockere und entspannte - Treffen, Chat-Rooms und Ticket-Systeme. Es muss klar sein, wenn der gewünschte Mehrwert nicht mehr der Realität entspricht. Wenn die Nutzer:innen unzufrieden werden.

Neutralität der Sache

Wir sind Menschen und keine Vulkanier (siehe Star Trek, Mr. Spock) wir handeln und verhalten uns nicht rein rational. Wenn jemand Fragen stellt, sich beschwert, Vorgänge kritisiert so haben viele Menschen instinktiv das Bedürfnis sich zu verteidigen und die vorgebrachten Themen kleinzureden, zu ignorieren oder wegzudiskutieren.

Wir sollten versuchen zuzuhören und versuchen neutral zu bewerten ob eine Wahrheit in den Beschwerden oder Vorschlägen steckt. Die Diskussionen gehen um eine Sache und die Realität lässt sich nicht leugnen.

Wir können erklären warum wir die Realität nicht ändern können, oder wir können mehr Ressourcen aufwenden um eine Änderung möglich zu machen - mit potentiell negativen Konsequenzen für andere Projekte/Features da Zeit gebunden wird.

Letztlich ist es am Ende eine reine Sache der Priorisierung.

Statt:

Statt “Ich habe keine Zeit es dir zu erklären, mach es einfach so wie ich dir sage”: Wir haben das aus Grund XYZ so gemacht, hier findest du Informationen. Das war der einfachste Weg, falls du eine bessere Lösung findest, gib gerne Bescheid, damit wir das neu evaluieren können.
Statt “Das muss so sein”: Aus Gründen XYZ ist die Situation gerade so. Wenn wir Feature ABC zurückstellen können wir versuchen die Situation zu verbessern.
Statt “Warum stellst du so Fragen”: Weiß ich gerade nicht aus dem Kopf, ich schicke dir später die Informationen (und dann auch wirklich schicken!)

Wir wollen alle das Gleiche: Einen Mehrwert schaffen für andere Leute und hierbei das Beste Ergebnis erzielen, was für uns möglich ist.

Keine Lust!

Ich bin sicher, bei den Wörtern “Prozess” und “Backup + Restore” hat die Hälfte die den Artikel liest innerlich bereits gekotzt. Die Etablierung von Prozessen und das einrichten von Backups und regelmäßiges testen von Restores ist ungefähr so spannend und beliebt wie die Reinigung einer Latrine.

Das muss jedoch nicht so sein. Es ist eine Freude eine Applikation und Systeme zu sehen die wie ein Kätzchen schnurren. Es ist toll, wenn die Nutzer:innen zufrieden sind und einem immer wieder sagen wie schön es ist sich endlich auf ein System verlassen zu können. Wenn man den direkten positiven Mehrwert der eigenen Arbeit erlebt. Es ist befriedigend zu wissen, dass man im Katastrophenfall die Anwendung innerhalb von ein paar Stunden from-scratch wieder hochziehen kann. Nicht theoretisch, vielleicht, sondern sicher. Weil man es ausprobiert hat. Viele Male.

Das Management kann hier viel beitragen, indem saubere Vorgänge nicht als Feature-Bremsen gesehen werden, sondern als essentieller Bestandteil den geschafften Wert anderen Menschen zugänglich zu machen und dauerhaft zu erhalten.

Testing und Test-Driven-Development (TDD)

2024-10-17T00:00:00+02:00

In der Theorie sind Tests sehr wichtig für funktionierenden Code. Warum werden diese dann oft nur widerwillig geschrieben und was für Praktiken erleichtern das schreiben von Tests?

Wir schauen uns die Hintergründe für die Unlust am Testen an und versuchen Hürden zu identifizieren und abzubauen.

Ich stelle die Methode vor die für mich persönlich am Besten funktioniert und wir sehen uns Code-Beispiele an.

Warum Testing?

Jedem der schonmal Software geschrieben hat muss man nicht erklären warum man nach dem Programmieren nochmal ausprobieren muss ob denn alles auch so funktioniert wie geplant.

Software hat Fehler, unser Wissen ist begrenzt, wir wollen wissen “tut es”.

Dieses “Durchklicken” oder “Ausprobieren” (z.B. Rest-API Calls abfeuern, etc.) ist schon der Kern des Testing und absolut natürlich.

Wir haben eine gewisse Erwartung was passieren soll (Testfall) und probieren aus ob unsere Erwartung erfüllt wird.

Automatisiertes Testen, der nächst logische Schritt

Sehr schnell wird es sehr aufwändig alle Tests manuell durchzuführen. Es wird unübersichtlich man wird unaufmerksam und macht Fehler. Nicht mehr alle Tests werden jedes Mal durchgeführt.

Eigentlich wollen wir nach jeder Änderung am Code wissen ob dieser noch funktioniert. Die einzig nachhaltige Lösung: Wir müssen die Tests automatisieren.

Von der Theorie zur Praxis

In der Theorie gehen in der Regel die meisten noch mit: Ja klar brauchen wir Tests. In der Praxis wird es dann schnell dünn. Tests schreiben ist eine Qual. Hektisch werden von den Entwickler:innen noch schnell ein paar Tests dazu gebaut, damit die Definition of Done erfüllt ist und die Build-Metriken besser aussehen.

Doch warum ist das so?

Tests schreiben ist schwer

Gute Tests zu schreiben ist schwer. Test-Code ist den gleichen Regeln unterworfen wie funktionaler Code, man braucht viele Jahre Erfahrung um einfach und schnell Tests zu schreiben. Zusätzlich erfordert das Schreiben von Tests jedoch noch ein tiefes Verständnis von Abläufen und Abhängigkeiten und oftmals offenbart das Schreiben der Tests größere Baustellen in der Architektur. Dies ist zwar ein sehr positiver Nebeneffekt von Tests, viele Entwickler:innen sind jedoch davon überfordert. Nun müssen auch noch Entscheidungen über Architektur-Refactorings getroffen werden. Dabei wollte man nur kurz … . Wird das Refactoring aber nicht durchgeführt kann oft der Test nur schwer geschrieben werden oder ist in der Ausführung unzuverlässig.

So much to do, so little time: Funktionalität vs. Zuverlässigkeit

Beim Schreiben von Software ist der Tag eigentlich immer randvoll gepackt mit Aufgaben. Die Feature-Liste ist lang, der Druck diese zeitnah zu implementieren groß. Tests sind unsichtbar, der neue Button in der UI, der neue REST-API Endpunkt sind sichtbar. Für Außenstehende ist die Qualität der geschriebenen Tests nicht nachvollziehbar. Die des Codes auch nicht, aber zumindest gibt es einen Interaktionspunkt und man kann sagen: es tut was es soll, oder es tut nicht, was es soll.

Durch jahrzehnte lange Praxis an unzureichenden Tests und schlechtem Code sind die Fachbereiche und das Management abgestumpft. Es ist völlig “normal”, dass Software am Anfang nicht das tut was von ihr erwartet wird. Selbst in Bereichen mit unverhandelbaren völlig klaren Spezifikationen ist die Experimentalinformatik an der Tagesordung.

Keine Maurer:in würde sich dazu hetzen lassen zu wenig Mörtel zu verwenden und die Mauer schief zu bauen. In der Software-Entwicklung ist das an der Tagesordnung. Die Folge ist eine Bug-Dichte auf peinlichstem Niveau.

Die Gratwanderung: Fast-Prototyping vs. schlampige Arbeit

Im letzten Absatz habe ich von Experimentalinformatik im negativen Kontext gesprochen, doch diese gibt es auch im positiven Kontext. Oft sind die fachlichen Anforderungen anfangs noch unklar, ebenso wie die Code Architektur. In diesem Zustand bereits Tests zu schreiben verlangsamt den Entwicklungsprozess extrem, größere Umbauten erfordern auch größere Änderungen am Test-Code.

Ich finde es völlig nachvollziehbar, dass man anfangs ohne Tests startet bis sich eine Struktur herauskristallisiert hat die man verfolgen möchte. Spätestens wenn ein Stück Software in den produktiven Betrieb geht müssen jedoch Tests existieren.

Man braucht keine große Fantasie um sich vorzustellen, dass hier gern eine Abkürzung genommen wird.

Der Code wird schlecht oder gar nicht automatisiert getestet in Produktion abgeliefert.

Test Driven Development

Es gibt eine Bewegung, die diesem Problem durch eine radikale Lösung entgegen tritt. Test Driven Development beschreibt den Ansatz zuerst einen Test zu schreiben der die fachliche Spezifikation in Test-Code gießt und erst danach die Spezifikation als funktionalen Code zu implementieren.

Durch dieses Vorgehen werden mehrere Fliegen mit einer Klappe geschlagen:

Tests existieren von Anfang an und können am Ende nicht einfach weggelassen werden
Dadurch, dass zum Zeitpunkt des Test schreibens der funktionale Code noch nicht existiert reduziert sich das Risiko Details der technischen Implementierung im Test-Code abzuprüfen. Stattdessen beschränkt man sich auf die fachliche Anforderung was die Test-Cases klarer zu lesen und robuster gegen Veränderung macht

Das klingt doch alles toll, warum wird es nicht mehr gemacht. Meine persönliche Erfahrung mit Test Driven Development war folgende:

Befinde ich mich noch in der “Selbstfindungsphase” der Software, wo die Funktionalität und Architektur noch unklar ist verlangsamt das Schreiben der Tests die Entwicklung extrem und bringt wenig Mehrwert
Sobald die Architektur und Funktionalität klar ist bringt Test Driven Development einen großen Vorteil und deckt oft auch Fehler links und rechts des eigentlich neuen Codes auf

Test Coverage

Ein vieldiskutiertes Thema ist das Thema Test Coverage. In jedem Projekt werden ein paar Stunden mit der Diskussion verschwendet welche Art von Test-Coverage Metrik man denn nun meine. Wenn ich von Test-Coverage spreche geht es immer um Line-Coverage.

Ich möchte wissen ob all der Code den ich geschrieben habe mindestens von einem Test durchlaufen wird.

Wichtig zu verstehen ist, dass die Test Coverage keinerlei Aussage über die Qualität von Tests geben kann und auch kein Maß für Vollständigkeit ist.

Auf Grund einer schnell quasi unendlich großen Möglichkeit an Kombinationen durch verschiedene Eingabewerte und Infrastruktur-Abhängigkeiten ist es nicht möglich Code vollständig zu testen.

Die Test-Coverage beschreibt jedoch eine andere Metrik. Es ist eine Mindestanforderung.

Nun kann man sich überlegen: Wieviel Prozent des Codes der geschrieben wurde soll von einem Test durchlaufen werden (durchlaufen! nicht unbedingt getestet). Die Antwort ist klar: 100%. Jeder Code der geschrieben wurde sollte mindestens 1 mal während dem Abfahren der Tests “besucht” werden.

100% Testabdeckung klingt gigantisch und so als ob man etwas großes erreicht hätte. In Wahrheit ist es eine Mindestanforderung.

Warum haben dann viele Teams die Tools zur automatischen Code Analyse verwenden wie Sonar ein Coverage Target von 85% oder 90%?

Dies liegt vorwiegend am nächsten Punkt.

Infrastruktur-Abhängigkeiten sind teuer und komplex (aber notwendig)

Man stelle sich vor einen Test für diese Funktion zu schreiben. Easy.

1
2
3

public static int add(int a, int b) {
    return a + b;
}

Nun stelle man sich vor einen Test für die selbe Funktion zu schreiben, jedoch kommen die Input Werte aus einer Kafka-Message und man möchte explizit den Infrastruktur Teil der Software mit testen. Horror.

Es gibt verschiedene Grade des Schmerzes. Man kann verschiedene Mock-Szenarien erstellen, oder gleich einen oder mehrere Test-Container mit Kafka (+ Zookeeper) hochfahren. Zu testen gilt auch was passiert in Fällen von fehlerhaften Messages, etc. . Zwischen jedem Test muss evtl. der Kafka Container komplett abgerissen und neu aufgesetzt werden.

Die Tests werden langsam, ressourcen-intensiv und fehleranfällig.

In der Realität ist man leider dazu gezwungen diese Tests trotzdem zu schreiben. Viele Bugs hängen mit der Infrastruktur zusammen und gerade eine korrekte Fehlerbehandlung ist extrem wichtig. Manche Funktionalität lässt sich nur extrem schwer mocken, auch in diesen Fällen braucht man die originale Infrastruktur. z.B. via Test-Containers.

Behavior Driven Development - BDD - Die fachliche Logik als “First Class Citizen”

Eine andere interessante Bewegung die mein Verständnis von Testing komplett verändert hat ist BDD (Behavior Driven Development).

Bei BDD stehen die fachlichen Anforderungen im Vordergrund, die fachliche Beschreibung wird ohne jeglichen Code erstellt und kann auch für sich selbst stehen.

Automatisierte Tests testen dann die fachliche Beschreibung ab.

Bekannt ist der für BDD typische Dreisatz GIVEN - WHEN - THEN.

GIVEN beschreibt das Grundsetup was man benötigt um das Verhalten abzuprüfen. WHEN -> THEN beschreibt das erwartete Verhalten.

@Test
void SHOULD_increase_deposit_balance_WHEN_positive_amount_is_deposited() {
    // Given: a bank account with an initial balance of $100
    BankAccount account = new BankAccount(100);

    // When: a deposit of $50 is made
    int depositAmount = 50;
    account.deposit(depositAmount);

    // Then: the balance should be increased by $50, resulting in $150
    assertEquals(150, account.getBalance());
}

Schaut man sich jetzt alleine die Kommentare an ist dies eine für Business Analysten verständliche Beschreibung des Testcases.

1
2
3

// Given: a bank account with an initial balance of $100
// When: a deposit of $50 is made
// Then: the balance should be increased by $50, resulting in $150

Es gibt Tools with z.B. Fitnesse die diese Informationen in einer Wiki Form darstellbar machen.

Naming der Tests

Hier gibt es viele Konventionen, mir persönlich ist nur wichtig, dass man eine Idee davon bekommt was im Test passiert, ich habe mich für die Should ... When Konvention entschieden.

1
2
3

shouldThrowExceptionWhenInputIsNull()
shouldReturnDefaultValueWhenSettingIsMissing()
shouldSendEmailNotificationToAllUsersWhenSystemReachesThresholdLimit()

Meine persönlicher Testing Workflow und bewusste Trade-Offs die ich eingehe

Wenig Tooling

Als ich angefangen habe mich mit Testing zu beschäftigen wollte ich alles richtig machen, BDD Frameworks, Cucumber, etc. . Hat man hier keine Routine hält man sich stark auf, neue Frameworks oder Techniken in existierende Codebases oder Teams einzuführen ist ein langwieriger Prozess.

Ich bin dazu übergegangen kein oder wenig existierendes Tooling zu verwenden. Die wichtigsten Themen wie BDD, Test-Naming und Coverage Metriken kann man einfach im Code durch Kommentare und Funktionen der IDE (Coverage) abdecken.

Mit gutem Beispiel voran gehen

Eigentlich alle Entwickler:innen mit denen ich gesprochen habe wollen Tests schreiben. Oft sind es die äußeren Umstände die dies verhindern und fehlende Praxis.

Hier kann man einfach mit gutem Beispiel voran gehen und selbst nach bestem Wissen und Gewissen gute Arbeit abliefern. So gibt es in der Codebase immer mehr Beispiele die es anderen leichter machen sich daran zu orientieren und dann ebenfalls Tests zu schreiben.

Wenn man dann noch diese Arbeit gelegentlich vorstellt, Pair-Programmings macht und das Team-Management dabei unterstützt Tests nicht als separaten Teil eines Features (Feature + Test), sondern als Teil des Features zu kommunizieren, dann ist bereits viel gewonnen.

So wie die Maurer:in nicht eine Mauer baut die umfallen kann und danach schaut ob sie gerade ist und steht. Genauso bauen wir keine Software und schauen danach ob sie funktioniert. Tests sind unvermeidlicher Teil der Entwicklung und die Konsequenz sie nicht zu haben ist fehlerhafter und unwartbarer Code.

100% Testabdeckung … im Business Code

Ich versuche eine Testabdeckung von 100% im Business Teil der Software zu erreichen. Wenn dieser sauber geschnitten ist hat er keine Abhängigkeiten zu Infrastrukturkomponenten, und entsprechend ist es einfach und sogar erforderlich hier 100% zu erreichen um die fachlichen Anforderungen zu erfüllen.

Im Anschluss versuche ich 100% Testabdeckung im Infrastruktur “Glue-Code” zu erreichen. Komme ich an Punkte die einen großen Arbeitsaufwand bedeuten überspringe ich diese Parts und verschiebe sie auf später.

Solche größeren Blöcke können dann vernünftig in der Zeitplanung eingeplant werden.

Durch diesen gemischten Ansatz erreicht man ein sehr großes Vertrauen in die Codebase der Business-Logik, bei gleichzeitig überschaubarem Zeitaufwand.

Angenehmer Nebeneffekt: Man wird nicht frustriert durch kompliziertes Test-Setup der Infrastruktur-Tests.

Bug Test Driven Development

Während es schwierig ist von Anfang an Test-Driven zu arbeiten habe ich mir angewöhnt ausnahmslos bei Bugs test-driven zu arbeiten.

Einen Bug muss man sowieso reproduzieren. Erst reproduziere ich ihn aus User-Sicht. Dann reproduziere ich ihn aus Code-Sicht via das Schreiben eines Tests.

Dabei lerne ich bereits sehr viel über den internen Aufbau des Codes, sprich 80% der Zeit hätte ich sowieso reinstecken müssen um mir den Code anzusehen um den Bug zu fixen.

Der Bugfix selbst ist dann oft relativ schnell erledigt. Der Vorteil: ab jetzt kann dieser Bug nie wieder unbemerkt auftreten. Ein weiterer Vorteil: langsam aber stetig steigt die Test-Coverage in der gesamten Codebase.

Todo-Liste von offenen Themen

Ich führe eine kurze Todoliste von Themen die aktuell noch nicht angegangen werden können aber wichtig sind und versuche regelmäßig Punkte davon abzuarbeiten. z.B.:

Kafka Integrationtest mit Test Containers

Konsequentes BDD und Benennung von Tests

Ich versuche, wo möglich, High-Level Tests aus Business Perspektive zu schreiben. Das heißt die Tests sollten auf Business-Service Ebene Business Cases abfragen und nicht nur auf technische Ebene die Funktionalität einzelner Funktionen.

Das hat den Vorteil, dass diese Tests die Anforderungen des Fachbereichs sicherstellen und auch nach starken Refactorings noch weiter funktionieren ohne umgebaut werden zu müssen.

Architektur, Entwicklung und Deployment einer IoT Cloud-Infrastruktur

2023-09-01T00:00:00+02:00

Für einen Kunden, der Optimierungs-Dienstleistungen für Windparks anbietet, entwarf ich eine maßgeschneiderte IoT-Cloudlösung. Dabei entwickelte ich alle Cloud-Komponenten, von der Auswahl der Hardware der Edge-Geräte über die sichere Übertragung der Daten in die Cloud bis zur Anreicherung und Verarbeitung der Rohdaten im Cloud-Produkt.

Übersicht über das Projekt

In mehreren Terminen erarbeitete ich mit dem Kunden sowie externen Dienstleistungsfirmen des Kunden die Kernanforderungen der Lösung:

Auslesen der Rohdaten aus den Endsystemen (Windkraftanlagen, Externe Sensor-Arrays)
Einfache Wartung und Update der Agent-Software
Sichere Datenübertragung in die Cloud
Prüfen und Sicherstellen der Datenintegrität mit Option fehlerhafte Daten zu reprozessieren
Anreicherung der Rohdaten mit zusätzlichen Datenquellen
Ansteuerung der Windkraftanlagen mit optimierten Leistungsparametern
Skalierbar von PoC auf beliebig viele Windparks in Deutschland

Meine Leistungen

Klärung der Anforderung und der Definition des Umfangs des Proof-of-Concept (PoC)
Auswahl und Zusammenbau der Hardware-Komponenten
Cloud Architektur und Dokumentation der einzelnen Komponenten
Entwicklung der einzelnen Cloud-Komponenten (Python Microservices)
Setup der Infrastruktur-Komponenten (VPN, MQTT, Kafka, Kubernetes, Terraform)
Schulung der Angestellten des Kunden

Features

Echtzeit-Datenverarbeitung: Mit Kafka’s Stream-Processing-Fähigkeiten werden Daten von den Sensoren der Windkraftanlagen in Echtzeit erfasst und verarbeitet.
Skalierbarkeit: Die Architektur ermöglicht es, problemlos von einem einzigen Windrad bis zu einem ganzen Windpark mit Hunderten von Turbinen zu skalieren, ohne Leistungseinbußen.
Fehlererkennung: Automatische Erkennung von Anomalien in den Eingangsdaten.
Optimierte Energieerzeugung: Die Datenanalyse ermöglicht die Optimierung des Betriebs, um die Stromerzeugung zu maximieren.
Sicherheit: Erweiterte Sicherheitsprotokolle sorgen für den Schutz der Datenübertragung und Speicherung.
Integration mit anderen Systemen: Die IoT-Cloud kann einfach mit anderen Systemen, Wettervorhersage-Tools und Energiemanagement-Plattformen integriert werden.

Dank dieser Features ermöglicht die IoT-Cloud für Windparks eine robuste und zuverlässige Überwachung, Verwaltung und Optimierung von Windenergieanlagen. Es handelt sich um ein unverzichtbares Tool für moderne Windparkbetreiber, die Technologie nutzen möchten, um die Effizienz und Produktivität ihrer Anlagen zu steigern.

Technologien

Django, Pandas, Terraform, Ansible, Docker, Hetzner Cloud

Echtzeit Datenbank für Business Intelligence

2023-08-30T00:00:00+02:00

Der Kunde - einer der größten Digital Publisher in Deutschland - betreibt seit vielen Jahren eine Echtzeit-Datenbank in welcher eine Vielzahl an Geschäftskennzahlen und Statistiken, wie zum Beispiel das Echtzeit-Tracking der aufgerufenen Artikel und Seiten gespeichert werden. Im Lauf der Zeit wurde die Datenbank langsamer und die Anzahl der Ausfälle häufte sich. Monitoring war nur rudimentär über das System der Hersteller-Firma vorhanden. Ich habe eine individuelle Monitoring-Lösung für den Kunden entwickelt und konsequent alle auftretenden Probleme behandelt. Durch die Schulung der Angestellten des Unternehmens konnte die Lösung erfolgreich dauerhaft etabliert werden.

Übersicht über das Projekt

Der Kunde betreibt einen Druid Cluster mit 40 Nodes, 26 TB an Daten, 500 Reports und 150 Dashboards. Immer wieder treten den Produktionsbetrieb gefährdende Ausfälle auf. Teils melden die Nutzenden der Dashboards lange Ladezeiten und abbrechende Queries.

Der Hersteller der Datenbank bietet ein rudimentäres Monitoring an, was detailliert Daten erfasst, jedoch nicht an das Monitoring und Alerting des Kunden angebunden ist.

Meine Leistungen

Entwicklung eines Prometheus Monitoring Exporters
- Hauptaufgabe war Design und die Entwicklung eines Prometheus Exporters, welcher speziell die für die Kundenumgebung relevanten Metriken via Druid-REST-Api ausliest und Prometheus zur Verfügung stellt
Entwicklung von Grafana Dashboards und Alerts
- Die Erstellung speziell angepasster Grafana-Dashboards und Feintuning der Alerts war eine weitere wichtige Aufgabe
Apache Druid – Operations (Erweiterung des Clusters, Debugging von Fehlern, Housekeeping/Maintenance)
- Übernahme von Betriebsaufgaben für den Cluster, von der Erweiterung über die Fehleranalyse bis zur Wartung
Entwicklung von Imply Druid Ingestions und Pivot Dashboards
- Umsetzung von Druid Ingestions und Pivot Dashboards, die zugleich ein tieferes Verständnis der fachlichen Besonderheiten für das Monitoring lieferten
Schulung der Angestellten
- Um Monitoring Systeme effektiv zu nutzen ist es essentiell, dass alle Angestellten das System kennen und Alarme so schnell wie möglich behandeln. Durch wiederholte Schulungen habe ich sichergestellt, dass der maximale Nutzen aus dem System gezogen werden konnte.

Verbesserungen

Reduktion der Ausfälle: Die Ausfälle konnten annähernd auf 0 reduziert werden. Bei vereinzelt auftretenden Beeinträchtigungen der Leistung konnte dank dem Monitoring System schnell die Ursache ausfindig gemacht werden.
Right-Sizing: Durch die erhobenen Metriken konnte die Ressourcen-Nutzung der Plattform auf den optimalen Wert angepasst werden.
Klare Kommunikation: Durch speziell eingerichtete Kommunikationskanäle werden die End-Anwendenden zeitnah über Wartungsmaßnahmen und Ausfälle informiert.

Technologien

Imply Druid, Apache Kafka, Java, Gradle, Spring Boot, Kubernetes, Imply Pivot, Grafana, Prometheus

Data Services Real-Time Stream Processing (Apache Kafka)

2023-08-29T00:00:00+02:00

Der Kunde betreibt eine Real-Time Streaming Plattform basierend auf Apache Kafka, um die Eingangs-Daten in Echtzeit mit zusätzlichen Informationen anzureichern. Bei mehreren laufenden Stream Prozessoren gab es Probleme mit der Qualität der Daten der Drittanbieter. Ich analysierte und überarbeitete die existierenden Prozessoren und entwickelte neue Prozessoren.

Übersicht über das Projekt

Der Kunde betreibt mehrere auf Java, Spring Boot und Kafka Streams basierende Stream Prozessoren. Einige lieferten von der Quelle abweichende Daten, andere mussten um neue Features erweitert werden.

Meine Leistungen

Entwicklung und Erweiterung von API Crawlern basierend auf Spring Boot und Kafka (Google, Facebook, IVW)
- Debugging der Abweichung zwischen Quelle und Daten in den Kunden-Systemen
- Anpassung/Erstellung von Crawlern/neuen Features nach den Kundenanforderungen
Echtzeit-Stream-Verarbeitung und -Transformation mit Kafka-Streams
Erstellen und Aktualisierung der Dokumentation, Hinzufügen von Tests
- Die existierenden Crawler und Stream Prozessoren waren nur rudimentär oder gar nicht dokumentiert. Ich erstellte oder erweiterte die Dokumentation, sodass die Angestellten des Kunden jederzeit in der Lage sind selbstständig Änderungen an den Projekten vorzunehmen.
- Ebenso erweiterte ich die Test-Cases der Projekte um eine robustere Entwicklung zu ermöglichen.

Verbesserungen

Wiederherstellung der Datenintegrität: Die Ursache für die Unterschiede zwischen Quelle und Kundensystemen konnte ausfindig gemacht und behoben werden.
Einbau lang benötigter Features: Durch Protokoll-Erweiterungen standen zusätzliche Informationen zur Verfügung, welche ich nutzbar gemacht habe.
Umfassende Dokumentation: Durch die umfassende neu erstellte und ergänzte Dokumentation ist sichergestellt, dass die Services auch in Zukunft wartbar bleiben.

Technologien

Apache Kafka, Java, Gradle, Spring Boot, Kubernetes, Imply Druid, Imply Pivot, Grafana, Prometheus