Meridian — wie es entstanden ist

Warum überhaupt

Wer Produktentwicklung steuert, kennt das Spiel: Eine Frage wie „Liefern wir gerade das Richtige, in vernünftiger Qualität, ohne dass die technische Schuld davonläuft?" — und um sie zu beantworten, klickt man sich durch Issue-Tracker, Git-Historie und ein Code-Quality-Tool und baut sich die Zahlen im Kopf zusammen. Jede Woche aufs Neue.

Ich wollte ein Dashboard, das diese Fragen beantwortet, ohne dass ich fünf Tabs offen habe. Und weil die Daten sensibel sind, sollte es self-hosted laufen — im Netz des Teams, nicht in irgendeiner Cloud.

Wie es entstand

Meridian ist in klaren Phasen gewachsen, jede mit eigenen Architekturentscheidungen. Erst das Fundament — Persistenz und Mandantentrennung — dann nach oben:

• Authentifizierung mit JWT und OIDC, damit man sich per Firmen-Login anmelden kann.
• Ein Setup-Wizard, der eine frische Instanz durch die Erstkonfiguration führt.
• Ein Modul-System, über das einzelne Auswertungen lizenziert freigeschaltet werden.
• Ein Connector-Framework, das Jira, GitHub und einen Code-Quality-Scanner anzapft.
• Ein asynchroner Sync-Worker, der die Daten regelmäßig einsammelt.
• Eine KPI-Engine mit Redis-Cache, die aus den Rohdaten die eigentlichen Kennzahlen rechnet.
• Mehrsprachigkeit und am Ende das Frontend mit fünf Dashboards.

Dazu gehört ein zweites, kleineres Projekt: der Remote-Service in Python/FastAPI. Er läuft bei mir und übernimmt zwei Dinge — die Lizenzprüfung für die Module und anonyme Branchen-Benchmarks: Die Core-Instanzen schicken aggregierte, pseudonymisierte Kennzahlen, und nur ab einer Mindest-Gruppengröße kommt ein Vergleichswert zurück. So sieht ein Team, wo es relativ zu anderen steht, ohne dass jemand identifizierbar wird.

Was gut lief

• Die Trennung in „Core läuft beim Kunden, Remote-Service läuft bei mir" hat das Datenschutz-Thema von Anfang an sauber gehalten.
• Das Connector-Framework als Abstraktion: ein neues Quellsystem anzubinden heißt jetzt, einen Connector zu schreiben — nicht das halbe System anzufassen.
• Eine Grace-Period: Fällt der Remote-Service aus, laufen die lizenzierten Module trotzdem eine Weile weiter. Kein harter Stopp wegen einer Netzwerkdelle.

Was nicht so gut lief

• Zwei Stacks parallel — Java/Spring auf der einen, Python/FastAPI auf der anderen Seite — ist mächtig, aber man pflegt eben auch zwei Welten.
• Die KPI-Formeln wirklich richtig hinzubekommen, ist überraschend knifflig: Was genau ist „Lead Time", was zählt als „abgeschlossen"? Da steckt mehr Definitionsarbeit drin als Code.
• Anonymität bei den Benchmarks ist kein Häkchen, sondern Sorgfalt — Mindest-Gruppengröße, Pseudonymisierung, keine Klarnamen. Lieber zu vorsichtig als einmal zu locker.