Wie ich eine übernommene Datenplattform prüfe, bevor ich die Modernisierung plane

Du übernimmst eine Datenplattform und sollst ihre Modernisierung planen? Ich fange bei den Geschäftsentscheidungen an, die von ihren Daten abhängen. Mit dem Betriebsteam verfolge ich den Datenfluss zurück zur Quelle und belege die Risiken. Daraus entsteht eine Reihenfolge für die Modernisierung, in der das Team die Abhängigkeiten zwischen den Arbeiten nachvollziehen kann.

Zum Einstieg lasse ich mir einen genutzten Report oder eine Anwendung zeigen. Wer braucht das Ergebnis, und was passiert, wenn die Daten veraltet sind? Von dieser Verwendung aus gehe ich den Weg durch die Transformation bis zur Quelle zurück. Dabei gleiche ich die Dokumentation mit dem laufenden System ab.

Anschließend zeigt mir ein Engineer eine kürzlich ausgelieferte Änderung auf diesem Weg. Ich frage nach, woran erkennbar war, dass sie in Produktion angekommen ist. Offene Verbindungen im Datenfluss markiere ich als ungeprüft und halte fest, wer sie klären kann. Die Karte enthält dann auch ihre eigenen Lücken.

Für diese Gespräche nutze ich die Platform-Discovery-Checkliste. Die Übersicht soll sich mit dem Team im Review korrigieren lassen; die zugehörigen Repositories verlinke ich direkt an den Verbindungen.

Bei der Strategie schaue ich auf die Zusagen ans Geschäft, die an der Plattform hängen. Wo konzentriert die geplante Arbeit das Lieferrisiko? Wenn eine Komponente bereits ersetzt wird, brauche ich die Abnahmebedingung für den neuen Weg. Dazu gehört die Frage, wie die bisherige Nutzung beendet werden soll und wer das verantwortet.

In der Architekturprüfung verfolge ich Fehler entlang des Datenflusses. Erkennt das Team einen ausgefallenen vorgelagerten Schritt, bevor dessen Ergebnis verwendet wird? Lässt sich ein fehlgeschlagener Lauf gefahrlos wiederholen? Zum Finding gehört das beobachtete Verhalten, damit später überprüfbar ist, ob die Korrektur greift.

Für Developer Experience gehe ich eine Änderung vom lokalen Checkout bis zum Deployment durch und schreibe Wartezeiten sowie fehlende Anleitungen auf. Wenn Zuständigkeiten außerhalb des Engineering-Teams den Ablauf bestimmen, hilft mir das Enterprise Product Operating Model, die nötigen Entscheidungen zu benennen.

Die Severity richtet sich danach, was passiert, wenn ein Finding offen bleibt. Den Aufwand für die Behebung halte ich separat fest. Sonst verdrängt eine umfangreiche Architekturarbeit leicht die kleine Korrektur, die bereits genutzte Daten verlässlicher macht.

Ich prüfe zum Beispiel Idempotenz: Ein wiederholter Lauf darf keine doppelten Effekte erzeugen. Bei Observability interessiert mich, ob das Team die Ankunft der Daten und die Nutzbarkeit des Ergebnisses beurteilen kann. Lassen sich solche Lücken lokal schließen, ordne ich die Korrektur vor dem Austausch der Orchestrierung ein. Verhindert die bestehende Runtime eine tragfähige Lösung, bekommt diese Abhängigkeit einen Eintrag in der Reihenfolge.

Mit dieser Checkliste sammle ich Belege. Bleibt ein Punkt offen, bekommt die Frage einen Owner, der die fehlende Information beschaffen kann.

• Halte fest, welche Geschäftsentscheidung ein genutzter Report oder eine Anwendung unterstützt und wer sie verantwortet.
• Verfolge den Datenfluss bis zur Quelle und verlinke die beteiligten Repositories.
• Gleiche den laufenden Weg mit der Dokumentation ab und markiere ungeprüfte Verbindungen.
• Lass dir eine kürzlich ausgelieferte Änderung von dem Engineer zeigen, der sie umgesetzt hat.
• Prüfe, was bei einem ausgefallenen oder verspäteten vorgelagerten Schritt passiert.
• Kläre, ob die Wiederholung eines fehlgeschlagenen Laufs das Datenergebnis verändert.
• Notiere, wer Fehlermeldungen erhält und über die Nutzbarkeit der Ergebnisse entscheidet.
• Erfasse Abhängigkeiten in der laufenden Roadmap, einschließlich bereits begonnener Ablösungen.
• Ergänze jedes Finding um einen Beleg und einen Owner, der die Korrektur überprüfen kann.
• Besprich das Severity-Ranking mit dem Team und halte die Abhängigkeiten der Modernisierung fest.

Diese Rubrik nutze ich über die Prüfbereiche hinweg. Die Beispielzeile ist hypothetisch und bezieht sich auf kein Kundensystem.

Severity	Was darunter fällt	Was daraus folgt
Kritisch	Ein laufender Fehler beeinträchtigt den Betrieb und muss eingedämmt werden.	In die Incident-Bearbeitung mit verantwortlicher Leitung überführen; die Roadmap separat besprechen.
Hoch	Ein erheblicher Betriebsausfall ist anhand der Belege plausibel, verlässliche Erkennung oder Wiederherstellung fehlt.	Behebung vor abhängiger Modernisierungsarbeit einplanen und die Prüfung der Korrektur vereinbaren.
Mittel	Eine belegte Lücke bei Lieferung oder Zuverlässigkeit hat eine tragfähige Übergangslösung.	Behebung mit Owner einplanen und festhalten, wann die Übergangslösung nicht mehr ausreicht.
Niedrig	Eine lokale Wartbarkeitslücke hat bislang keine belegte betriebliche Auswirkung.	Im zugeordneten Backlog halten und bei neuen Belegen erneut bewerten.
Hypothetisches Beispiel: Hoch	Ein Fehleralarm hat keinen Empfänger; eine ausgefallene Aktualisierung könnte unbemerkt bleiben.	Empfänger zuordnen und den Reaktionsweg prüfen, bevor weitere Workloads hinzukommen.

Ein laufender Incident braucht zunächst eine Eingrenzung des Schadens. Bei einer Plattform ohne reale Nutzung beginne ich mit Discovery zu den vorgesehenen Nutzern. Dort fehlt der betriebliche Datenfluss, an dem sich das Assessment orientieren könnte.

Auch der Zugang begrenzt die Aussage. Kann ich eine relevante Schicht weder einsehen noch mit ihrem Betreiber besprechen, bleibt der Befund ungeprüft. Im Assessment steht dann, welche Information fehlt und welcher Bereich dadurch offenbleibt.

Ein Plattform-Audit oder ein Roadmap-Reset gehört zu meinem Angebot Beratung & Sprints. Du erhältst das Assessment mit seinen Prüfgrenzen, nach Severity geordnete Findings und eine Modernisierungsreihenfolge als Grundlage für die Planung deines Teams. Vor Beginn legen wir fest, welchen Plattformbereich und welche anstehenden Entscheidungen der Auftrag abdeckt.

Der zugehörige Auftrag ist in meiner Bahlsen-Fallstudie beschrieben.