# .SYNOPSIS Pusht pathOS-Analyse-Ergebnisse als Unterseiten nach Confluence .DESCRIPTION Erstellt Unterseiten unter der Seite "Analyse pathOS" (ID: 581013135) Kompatibel mit PowerShell 5.1 .USAGE powershell -ExecutionPolicy Bypass -File ".\project-audit\scripts\confluence-push.ps1" #> $ConfluenceUrl = "https://arija-confluence.jaas.service.deutschebahn.com" $SpaceKey = "BES" $ParentPageId = "581013135" $ApiBase = "$ConfluenceUrl/rest/api" $ScriptDir = Split-Path -Parent $MyInvocation.MyCommand.Path $ProjectDir = Split-Path -Parent $ScriptDir [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 Write-Host "============================================================" Write-Host " pathOS Analyse -> Confluence Push" Write-Host "============================================================" Write-Host " Ziel: $ConfluenceUrl/spaces/$SpaceKey/pages/$ParentPageId" Write-Host "" # Token aus .secrets laden (falls vorhanden) $SecretsPath = Join-Path $ScriptDir "..\.secrets" $PAT = $null if (Test-Path $SecretsPath) { Get-Content $SecretsPath | ForEach-Object { if ($_ -match "^CONFLUENCE_TOKEN=(.+)$") { $val = $Matches[1].Trim() if ($val -ne "HIER_TOKEN_EINTRAGEN") { $PAT = $val } } } } if (-not $PAT) { $PAT = Read-Host "Confluence PAT" } $Headers = @{ "Authorization" = "Bearer $PAT"; "Content-Type" = "application/json" } function Safe-String($val) { if ($null -eq $val) { return "" } return [string]$val } function HtmlEncode($text) { if ($null -eq $text) { return "" } return [System.Security.SecurityElement]::Escape($text) } # Umlaute als HTML-Entities ersetzen (PS5.1-sicher) function Fix-Umlauts($html) { if ($null -eq $html -or $html -eq "") { return $html } # Schritt 1: Englische/technische Woerter schuetzen $Protect = @( 'Israel','Michael','Raphael','Emmanuel','Manuel','Daniel','Samuel', 'Maurer','Enabler','enabler','Container','container','Cluster','cluster', 'User','user','Tracing','Staging','Logging','Alerting','Monitoring', 'Deployment','deployment','Security','security','Recovery','Discovery', 'Delivery','Pipeline','pipeline','Release','release', 'Performance','performance','Interface','interface', 'Service','service','Feature','feature','Issue','issue', 'value','true','blue','Due','due','Queue','queue', 'Unique','unique','Continue','continue', 'Funnel','Tunnel','tunnel','Buildpacks','Dockerfile', 'OpenSearch','Gherkin','Kubernetes','Helmfile','Renovate', 'Operate','Template','template','Tasklist', 'Smoke','smoke','Analyse','analyse','Analysis', 'Baseline','baseline','Namespace','namespace', 'Codebase','Database','database','Rescue','rescue', 'Oire','oire','Oire','Detailanalyse','detailanalyse', 'Unteranalyse','unteranalyse' ) foreach ($w in $Protect) { $html = $html.Replace($w, "PROTECT_$w") } # Schritt 2: Personen-Namen zuerst (exakt) $html = $html.Replace('Hoerpel', 'Hörpel') $html = $html.Replace('Ruecker', 'Rücker') $html = $html.Replace('Koehler', 'Köhler') $html = $html.Replace('Goendoer', 'Göndör') # Schritt 3: ss-Ligaturen $html = $html.Replace('Massnahme', 'Maßnahme') $html = $html.Replace('massnahme', 'maßnahme') $html = $html.Replace('Groesse', 'Größe') $html = $html.Replace('groesse', 'größe') $html = $html.Replace('gleichmaessig', 'gleichmäßig') $html = $html.Replace('regelmaessig', 'regelmäßig') $html = $html.Replace('schliessen', 'schließen') $html = $html.Replace('Schliessen', 'Schließen') # Schritt 4: ue-Muster $html = $html.Replace('Uebersicht', 'Übersicht') $html = $html.Replace('uebersicht', 'übersicht') $html = $html.Replace('Ueberblick', 'Überblick') $html = $html.Replace('ueberblick', 'überblick') $html = $html.Replace('Uebergreifend', 'Übergreifend') $html = $html.Replace('uebergreifend', 'übergreifend') $html = $html.Replace('Ueberwachung', 'Überwachung') $html = $html.Replace('ueberwachung', 'überwachung') $html = $html.Replace('Uebernahme', 'Übernahme') $html = $html.Replace('Ueberarbeitung', 'Überarbeitung') $html = $html.Replace('Ueber', 'Über') $html = $html.Replace('ueber', 'über') $html = $html.Replace('Pruefung', 'Prüfung') $html = $html.Replace('pruefung', 'prüfung') $html = $html.Replace('Pruef', 'Prüf') $html = $html.Replace('pruef', 'prüf') $html = $html.Replace('fuehrung', 'führung') $html = $html.Replace('Fuehrung', 'Führung') $html = $html.Replace('Ausfuehr', 'Ausführ') $html = $html.Replace('ausfuehr', 'ausführ') $html = $html.Replace('Einfuehr', 'Einführ') $html = $html.Replace('einfuehr', 'einführ') $html = $html.Replace('Verfueg', 'Verfüg') $html = $html.Replace('verfueg', 'verfüg') $html = $html.Replace('Abkuerz', 'Abkürz') $html = $html.Replace('abkuerz', 'abkürz') $html = $html.Replace('Verschluess', 'Verschlüss') $html = $html.Replace('verschluess', 'verschlüss') $html = $html.Replace('Schluess', 'Schlüss') $html = $html.Replace('schluess', 'schlüss') $html = $html.Replace('Verknuepf', 'Verknüpf') $html = $html.Replace('verknuepf', 'verknüpf') $html = $html.Replace('Unterstuetz', 'Unterstütz') $html = $html.Replace('unterstuetz', 'unterstütz') $html = $html.Replace('Stueck', 'Stück') $html = $html.Replace('stueck', 'stück') $html = $html.Replace('Luecke', 'Lücke') $html = $html.Replace('luecke', 'lücke') $html = $html.Replace('Rueckweg', 'Rückweg') $html = $html.Replace('rueckweg', 'rückweg') $html = $html.Replace('Rueckmeld', 'Rückmeld') $html = $html.Replace('rueckmeld', 'rückmeld') $html = $html.Replace('Frueh', 'Früh') $html = $html.Replace('frueh', 'früh') $html = $html.Replace('wuerde', 'würde') $html = $html.Replace('Wuerde', 'Würde') $html = $html.Replace('muessen', 'müssen') $html = $html.Replace('Muessen', 'Müssen') $html = $html.Replace('muesste', 'müsste') $html = $html.Replace('Muesste', 'Müsste') $html = $html.Replace('koennte', 'könnte') $html = $html.Replace('Koennte', 'Könnte') $html = $html.Replace('Nuetzlich', 'Nützlich') $html = $html.Replace('nuetzlich', 'nützlich') $html = $html.Replace('fuer ', 'für ') $html = $html.Replace('Fuer ', 'Für ') # Schritt 5: oe-Muster $html = $html.Replace('Loesung', 'Lösung') $html = $html.Replace('loesung', 'lösung') $html = $html.Replace('Erhoeh', 'Erhöh') $html = $html.Replace('erhoeh', 'erhöh') $html = $html.Replace('noetig', 'nötig') $html = $html.Replace('Noetig', 'Nötig') $html = $html.Replace('moeglich', 'möglich') $html = $html.Replace('Moeglich', 'Möglich') $html = $html.Replace('geloest', 'gelöst') $html = $html.Replace('hoechst', 'höchst') $html = $html.Replace('Hoechst', 'Höchst') $html = $html.Replace('koennen', 'können') $html = $html.Replace('Koennen', 'Können') $html = $html.Replace('Zugehoer', 'Zugehör') $html = $html.Replace('zugehoer', 'zugehör') $html = $html.Replace('gehoer', 'gehör') $html = $html.Replace('Behoerd', 'Behörd') $html = $html.Replace('behoerd', 'behörd') # Schritt 6: ae-Muster $html = $html.Replace('Aenderung', 'Änderung') $html = $html.Replace('aenderung', 'änderung') $html = $html.Replace('Aelteste', 'Älteste') $html = $html.Replace('aelteste', 'älteste') $html = $html.Replace('anfaellig', 'anfällig') $html = $html.Replace('Anfaellig', 'Anfällig') $html = $html.Replace('faellig', 'fällig') $html = $html.Replace('faehig', 'fähig') $html = $html.Replace('traeger', 'träger') $html = $html.Replace('Traeger', 'Träger') $html = $html.Replace('laenger', 'länger') $html = $html.Replace('Laenger', 'Länger') $html = $html.Replace('erklaer', 'erklär') $html = $html.Replace('klaer', 'klär') $html = $html.Replace('Klaer', 'Klär') $html = $html.Replace('verstaerk', 'verstärk') $html = $html.Replace('Verstaend', 'Verständ') $html = $html.Replace('verstaend', 'verständ') $html = $html.Replace('Abhaengig', 'Abhängig') $html = $html.Replace('abhaengig', 'abhängig') $html = $html.Replace('haeufig', 'häufig') $html = $html.Replace('Haeufig', 'Häufig') $html = $html.Replace('laeuft', 'läuft') $html = $html.Replace('Laeuft', 'Läuft') $html = $html.Replace('waere', 'wäre') $html = $html.Replace('Waere', 'Wäre') $html = $html.Replace('schaerfen', 'schärfen') $html = $html.Replace('Schaerfen', 'Schärfen') $html = $html.Replace('aufraeumen', 'aufräumen') $html = $html.Replace('Aufraeumen', 'Aufräumen') $html = $html.Replace('Verlaenger', 'Verlänger') $html = $html.Replace('verlaenger', 'verlänger') $html = $html.Replace('Naechst', 'Nächst') $html = $html.Replace('naechst', 'nächst') $html = $html.Replace('schaetz', 'schätz') $html = $html.Replace('Schaetz', 'Schätz') $html = $html.Replace('Qualitaet', 'Qualität') $html = $html.Replace('qualitaet', 'qualität') $html = $html.Replace('Aktivitaet', 'Aktivität') $html = $html.Replace('Stabilitaet', 'Stabilität') $html = $html.Replace('Komplexitaet', 'Komplexität') $html = $html.Replace('Prioritaet', 'Priorität') # Generisches -taet Suffix (Universitaet, Kapazitaet, etc.) $html = $html -replace '([a-z])taet\b', '$1tät' # Schritt 7: Schutz aufheben $html = $html.Replace('PROTECT_', '') return $html } function Create-Or-Update-Page { param([string]$Title, [string]$HtmlBody, [string]$ParentId) # Umlaute automatisch konvertieren $HtmlBody = Fix-Umlauts $HtmlBody # Pruefen ob Seite existiert $SearchUri = "$ApiBase/content?spaceKey=$SpaceKey&title=$([Uri]::EscapeDataString($Title))&type=page" try { $SearchResp = Invoke-WebRequest -Uri $SearchUri -Headers $Headers -UseBasicParsing -ErrorAction Stop $SearchData = $SearchResp.Content | ConvertFrom-Json } catch { Write-Host " FEHLER bei Suche: $($_.Exception.Message)" -ForegroundColor Red return $null } if ($SearchData.results -and $SearchData.results.Count -gt 0) { # Seite existiert - pruefen ob Inhalt sich geaendert hat $PageId = $SearchData.results[0].id try { $VerResp = Invoke-WebRequest -Uri "$ApiBase/content/$PageId`?expand=version,body.storage" -Headers $Headers -UseBasicParsing -ErrorAction Stop $VerData = $VerResp.Content | ConvertFrom-Json $Version = $VerData.version.number + 1 $CurrentBody = "" if ($VerData.body -and $VerData.body.storage) { $CurrentBody = $VerData.body.storage.value } # Vergleich: HTML-normalisiert (Tags, Entities, Whitespace) $NormCurrent = ($CurrentBody -replace '<[^>]+>' -replace '&\w+;' -replace '\s+', ' ').Trim() $NormNew = ($HtmlBody -replace '<[^>]+>' -replace '&\w+;' -replace '\s+', ' ').Trim() if ($NormCurrent -eq $NormNew) { Write-Host " Keine Aenderung (ID: $PageId)" -ForegroundColor DarkGray return $PageId } } catch { $Version = $SearchData.results[0].version.number + 1 } Write-Host " Aktualisiere (ID: $PageId, Version: $Version)..." -NoNewline $Body = @{ version = @{ number = $Version } title = $Title type = "page" body = @{ storage = @{ value = $HtmlBody representation = "storage" } } } | ConvertTo-Json -Depth 10 try { $Resp = Invoke-WebRequest -Uri "$ApiBase/content/$PageId" -Method Put -Headers $Headers -Body ([System.Text.Encoding]::UTF8.GetBytes($Body)) -UseBasicParsing -ErrorAction Stop Write-Host " OK" -ForegroundColor Green return ($Resp.Content | ConvertFrom-Json).id } catch { Write-Host " FEHLER: $($_.Exception.Message)" -ForegroundColor Red return $null } } else { # Neue Seite erstellen Write-Host " Erstelle neue Seite..." -NoNewline $Body = @{ type = "page" title = $Title space = @{ key = $SpaceKey } ancestors = @(@{ id = $ParentId }) body = @{ storage = @{ value = $HtmlBody representation = "storage" } } } | ConvertTo-Json -Depth 10 try { $Resp = Invoke-WebRequest -Uri "$ApiBase/content" -Method Post -Headers $Headers -Body ([System.Text.Encoding]::UTF8.GetBytes($Body)) -UseBasicParsing -ErrorAction Stop Write-Host " OK" -ForegroundColor Green return ($Resp.Content | ConvertFrom-Json).id } catch { Write-Host " FEHLER: $($_.Exception.Message)" -ForegroundColor Red return $null } } } # ============================================================ # SEITENINHALTE DEFINIEREN # ============================================================ Write-Host "" Write-Host ">> Teste Verbindung..." -ForegroundColor Yellow try { $TestResp = Invoke-WebRequest -Uri "$ApiBase/content/$ParentPageId" -Headers $Headers -UseBasicParsing -ErrorAction Stop $TestData = $TestResp.Content | ConvertFrom-Json Write-Host " Zielseite gefunden: $($TestData.title)" -ForegroundColor Green } catch { Write-Host " Verbindung fehlgeschlagen: $($_.Exception.Message)" -ForegroundColor Red exit 1 } # --- Seite 1: Uebersicht --- Write-Host "" Write-Host ">> Seite 1: Uebersicht und Gesamtbild" -ForegroundColor Yellow $OverviewHtml = @"
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Basis: 167 GitLab-Projekte, 143 Confluence-Seiten, Runbook (arc42)
Dieses Dokument wird iterativ erweitert. Aktuelle Phase: Domain Discovery + Technische Erstanalyse.
pathOS (ehemals "Bestellsystem") ist die Nachfolgeplattform des Trassenportal Netz (TPN) - dem seit 2002 produktiven System zur Trassenbestellung bei DB InfraGO. pathOS modernisiert den gesamten Bestellprozess fuer Zugtrassen.
EVU-Kunden bestellen ueber pathOS Trassen (Fahrwege) auf dem deutschen Schienennetz. Das System verarbeitet Anmeldungen, koordiniert mit dem Fahrplan, erstellt Angebote und verwaltet Vertraege.
| Kennzahl | Wert |
|---|---|
| GitLab-Projekte gesamt | 167 |
| Davon aktiv (< 6 Monate) | ~109 |
| Davon archiviert | 32 |
| Untergruppen | 9 (APIs, Apps, Docs, Infra, Libraries, Mocks, QA, Sandbox, Tools) |
| Hauptsprache | Java / Spring Boot (47 Projekte) |
| Build-System | Maven (83 Projekte) |
| Containerisiert | 46 Projekte mit Dockerfile |
| Umgebungen | 17+ (DEV, ABN, PROD Stages) |
| Externe Schnittstellen | 15+ |
| Kafka-Topics | 25+ |
| ADRs | 75 |
| Confluence-Seiten (pathOS Space) | 143+ |
| Schicht | Technologie |
|---|---|
| Frontend | Angular, TypeScript, SCSS |
| Backend | Java, Spring Boot |
| Workflow | Camunda 8 (BPMN) |
| Messaging | Apache Kafka (AWS MSK) |
| Datenbank | PostgreSQL (AWS RDS), OpenSearch |
| Identity | Keycloak (Test), DB WebSSO / Entra ID (Prod) |
| Container | Docker, Kubernetes (AWS EKS via CNP) |
| CI/CD | GitLab CI, Helm, Helmfile, Cloud Native Buildpacks |
| Monitoring | Prometheus, Grafana, Talo (Logging), Tempo (Tracing) |
| Security | Trivy, OWASP ZAP, Fortify, SonarQube, DefectDojo, Renovate |
| Datenformat | TAF/TAP TSI (EU-Standard), TDM (internes Modell) |
| Team | Verantwortung |
|---|---|
| Team Zero | TAF/TAP Schnittstellen, Stammdaten (Common Interface, Stammdaten-Bereitstellung) |
| Team 404 | Bestellportal (Portal UI, Portal Middleware) |
| Team CIB | Prozesse und Backend (Steuerung Vertrieb, Auftrags-Verwaltung) |
| Team STeam | Infrastruktur, DevOps, Security (CI/CD, Deployment, Keycloak, Monitoring) |
| Team BSSUPPORT | 2nd Level Support |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Basierend auf GitLab-Inventar, Confluence-Analyse und Runbook
53 technische Themen, davon 17 MUSS (UKA/GELV), 24 MUSS 2026, 12 SOLL.
Status: 7 in Arbeit, 16 zu erledigen (mit Ticket), 30 ohne Ticket.
| # | Thema | Status | PI |
|---|---|---|---|
| 1.1 | Umstellung Kubernetes-Cluster/Namespaces | In Arbeit | PI 40 |
| 1.2 | Anbindung Netcool (Betriebsueberwachung) | Funnel | PI 40/41 |
| 1.3 | Laufzeit-Artefakte aus ECR statt Artifactory | Funnel | PI 41 |
| 2.1 | Vereinfachung Staging | Kein Ticket | PI 41 |
| 3.1 | Security-Groups auf egress-Ebene | Kein Ticket | PI 41 |
| 3.2 | Konzept Secret-Rotation | Kein Ticket | PI 41 |
| 4.1 | Umsetzung Monitoring-Konzept | In Arbeit | PI 40-42 |
| 5.1 | Camunda Point-in-Time-Recovery | Validierung | PI 39/40 |
| 5.2 | Desaster-Recovery-Test 3 | Validierung | PI 39/40 |
| 5.3 | Notfall-Recovery-Test (kompletter Neuaufbau) | Kein Ticket | PI 40/41 |
| 6.1 | ADR 72: Anbindung TraPo und C&R | Analysis | PI 40/41 |
| 7.1 | AV-Trasse: Full-Table-Scans vermeiden | Kein Ticket | PI 41 |
| 8.1 | Upgrade Spring Boot 4 (EOL 3.5: Juni 2026!) | Funnel | PI 40 |
| 8.2 | Upgrade Camunda 8.8 | Kein Ticket | PI 41 |
| 9.1 | Weiterentwicklung Testvorgehen (ADR-70) | In Arbeit | PI 40/41 |
| 9.2 | LuP Neo: Neu-Konzeption | Analysis | PI 41 |
| 10.1 | Ausarbeitung Runbook | In Arbeit | PI 41 |
167 Projekte in 9 Untergruppen. Generiert am $(Get-Date -Format 'yyyy-MM-dd').
| Gruppe | Anzahl | Beschreibung |
|---|---|---|
| apis/ | 37 | API-Definitionen, OpenAPI-Specs, Datenmodelle |
| apps/ | 19 | Laufende Services und Anwendungen |
| docs/ | 7 | Dokumentation, Runbook, Schemas |
| infra/ | 47 | Deployment, CI/CD, Helm Charts, Keycloak, Monitoring |
| libraries/ | 7 | Shared Libraries (core-components, logging, signatures) |
| mocks/ | 11 | Mock-Services fuer Tests |
| qa/ | 15 | Tests (System, Integration, Performance, Security) |
| sandbox/ | 13 | Experimente, PoCs, Pipeline-Tests |
| tools/ | 10 | Hilfswerkzeuge (Camunda, Kafka, Migration) |
| Sprache | Projekte |
|---|---|
| Java | 47 |
| Dockerfile | 46 |
| Shell | 22 |
| Python | 15 |
| Gherkin | 14 |
| JavaScript/TypeScript | 10 |
| Status | Anzahl |
|---|---|
| Aktiv (letzte 6 Monate) | ~109 |
| Inaktiv (6M+) | 21 |
| Inaktiv (1Y+) | 5 |
| Archiviert | 32 |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Alphabetisch sortiert
| Abkuerzung | Bedeutung |
|---|---|
| AC | AbrechnungsCockpit Trasse |
| ADR | Architecture Decision Record |
| AV / AVT | Auftrags-Verwaltung-Trasse |
| BaDiFa | Bahndigitale Fahrplanung |
| BEP | TrassenProduktPruefenUndErgaenzen (Bestelleingangspruefung) |
| BNetzA | Bundesnetzagentur |
| CI | Common Interface (TAF/TAP TSI) |
| CNP | Cloud Native Platform |
| CRD | Common Reference Data (RNE) |
| EIU | Eisenbahninfrastrukturunternehmen |
| ERegG | Eisenbahnregulierungsgesetz |
| EVU | Eisenbahnverkehrsunternehmen |
| GELV | Gelegenheitsverkehr (Meilenstein) |
| GFD-Z | Gelegenheitsfahrdienstleistung Zentral |
| IFP | Integrierte FahrPlanbearbeitung |
| IM | Infrastruktur-Manager (M15) |
| ISGW | Internet Service Gateway |
| KDV | Kundendatenverwaltung (CRM) |
| KOMBau | Kommunikationsplattform Bau |
| NEP | Netzfahrplan-Erstellungsprozess (NEP1 = erste Anmeldephase, NEP2 = zweite) |
| NAÄ | Netzausgeloeste Aenderungen (Aenderungen an Trassen durch den Infrastrukturbetreiber) |
| NuR | Nutzer- und Rechteverwaltung (Einfachbahn) |
| NVN | Neuverkehrsnachlass (Rabatt-Tool) |
| PI | Program Increment (SAFe) |
| PMW | Portal MiddleWare |
| PzP | Punkt-zu-Punkt Rabatte |
| RNE | RailNetEurope |
| RuT-K | Rechnerunterstuetzte Trassenkonstruktion |
| SIPS | Security Infrastructure Proxy Service (Access Proxy) |
| SNB | Schienennetz-Benutzungsbedingungen (Network Statement) |
| SV | Steuerung Vertrieb (Camunda-Prozess) |
| TADEF | TAF/TAP DEFinition (Connector) |
| TDM | Trassen-Daten-Modell (internes Datenformat) |
| TPN | Trassenportal Netz (Altsystem seit 2002) |
| TPS | Trassenpreis-Service (Rabatt) |
| TTT | TAF/TAP TSI (Telematics Applications for Freight/Passengers - Technical Specification for Interoperability) |
| TTTneo | Neue Umsetzungsstrategie TTT (Trassenmanagement) |
| ujBau | Unterjaehriger Baufahrplan |
| UKA | Unternehmenskritische Anwendung |
| VDV | Vertragsdaten-Verteiler |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Systemkontext nach C4-Methodik
Das Diagramm zeigt den Systemkontext von pathOS mit allen internen Komponenten und externen Schnittstellen. Farbkodierung: Gruen = Portal/Benutzer, Gelb = Prozesse/Fahrplan, Blau = Backend/Daten, Rot = TAF-TAP/Altsystem, Orange = Infrastruktur.
Interne Komponenten (pathOS)
|
Externe Systeme
|
| Dienst | Technologie | Details |
|---|---|---|
| Container-Orchestrierung | AWS EKS via CNP | Mehrere Cluster (DEV, ABN, PROD) |
| Messaging | Apache Kafka (AWS MSK) | 12+ Cluster, 25+ Topics |
| Datenbank | PostgreSQL (AWS RDS) | 3 Cluster in PROD (SV, AV, Rest) |
| Suchengine | OpenSearch | Fuer Camunda Operate/Tasklist/Zeebe |
| Identity | Keycloak (Test) / DB WebSSO (Prod) | OIDC, Entra ID |
| CI/CD | GitLab CI, Helm, Helmfile | 167 Repositories |
| Monitoring | Prometheus, Grafana, Talo, Tempo | Metriken, Logging, Tracing |
Business Owner: Andre Knie | Methodik: Iterativ (Gather - Analyze - Condense - Explore)
Dieses Projekt analysiert systematisch die ~140 GitLab-Projekte, Confluence-Dokumentation und Architektur von pathOS. Ziel: Klares Gesamtbild, Problemanalyse und priorisierte Roadmap.
| Phase | Beschreibung | Status |
|---|---|---|
| Phase 1: Domain Discovery | Domaene verstehen, Daten sammeln, erstes Gesamtbild | ✅ Abgeschlossen (80 Min) |
| Phase 2: Technischer Deep Dive | Code-Analyse, Dependencies, Architektur-Bewertung | ✅ Abgeschlossen (55 Min) |
| Phase 3: Team & Workflow | Team-Mapping, Entwicklungsworkflows, Reorganisation | ✅ Abgeschlossen (30 Min) |
| Phase 4: Roadmap & Aktionsplan | Priorisierte Massnahmen, Management-Praesentation | ☐ Geplant |
Datum: 2026-04-22 | Dauer: ~80 Minuten (09:00-10:20)
| # | Aufgabe | Status | Zeitraum | Dauer |
|---|---|---|---|---|
| 0 | Workspace-Setup, Interview, Scope/Rules/Glossar | ✅ | 09:00-09:10 | ~10 Min |
| 1 | Oeffentliche Quellen recherchieren + Domaenenwissen | ✅ | 09:10-09:15 | ~5 Min |
| 2 | GitLab-Zugang + Inventory-Script (Python -> PS5.1 Fixes) | ✅ | 09:15-09:30 | ~15 Min |
| 3 | GitLab-Inventory ausfuehren + Erstanalyse (167 Projekte) | ✅ | 09:30-09:35 | ~5 Min |
| 4 | Confluence-Zugang + Export-Script (Encoding-Fixes) | ✅ | 09:35-09:45 | ~10 Min |
| 5 | Confluence-Export (143 Seiten) + Schluesselseiten analysieren | ✅ | 09:45-09:50 | ~5 Min |
| 6 | Gesamtbild + Architektur-Diagramme | ✅ | 09:50-09:55 | ~5 Min |
| 7 | Runbook einlesen und analysieren (arc42, ~346KB) | ✅ | 09:55-10:00 | ~5 Min |
| 8 | Confluence-Push-Script + 5 Seiten publiziert | ✅ | 10:00-10:08 | ~8 Min |
| 9 | UKA-Korrektur + Architekturskizze + Fortschritt-Seite | ✅ | 10:08-10:20 | ~12 Min |
| Gesamt Iteration 01 | 09:00-10:20 | ~80 Min |
Datum: 2026-04-22 | Dauer: ~55 Minuten (10:45-11:40)
| # | Aufgabe | Status | Zeitraum | Dauer |
|---|---|---|---|---|
| 1 | Kern-Service READMEs analysieren (apps/) | ✅ | 10:45-10:50 | ~5 Min |
| 2 | pom.xml / package.json ziehen (23 Projekte, Script) | ✅ | 10:50-11:00 | ~10 Min |
| 3 | Spring Boot + Java Versionen erfassen | ✅ | 11:00-11:05 | ~5 Min |
| 4 | Dependency-Graph zwischen Services erstellen | ✅ | 11:05-11:10 | ~5 Min |
| 5 | Shared Libraries + CVE-Patches analysieren | ✅ | 11:10-11:20 | ~10 Min |
| 6 | Technische Gesundheits-Scorecard erstellen | ✅ | 11:20-11:30 | ~10 Min |
| 7 | Ergebnisse dokumentieren + Confluence vorbereitet | ✅ | 11:30-11:40 | ~10 Min |
| Gesamt Iteration 02 | 10:45-11:40 | ~55 Min |
Datum: 2026-04-22 | Dauer: ~30 Minuten (14:06-14:36)
| # | Aufgabe | Status | Zeitraum | Dauer |
|---|---|---|---|---|
| 1 | Team-zu-Projekt-Mapping aus Runbook + Confluence | ✅ | 14:06-14:15 | ~9 Min |
| 2 | Umgebungs-Workflow analysieren (17+ Umgebungen) | ✅ | 14:15-14:20 | ~5 Min |
| 3 | Release-Prozess + Engpaesse identifizieren | ✅ | 14:20-14:28 | ~8 Min |
| 4 | Reorganisations-Empfehlungen + Confluence vorbereitet | ✅ | 14:28-14:36 | ~8 Min |
| Gesamt Iteration 03 | 14:06-14:36 | ~30 Min |
| Ergebnis | Details |
|---|---|
| GitLab-Inventar | 167 Projekte inventarisiert, klassifiziert, Sprachen/Tags erfasst |
| Confluence-Export | 143 Seiten exportiert (Markdown + HTML) |
| Runbook-Analyse | Komplettes arc42-Dokument (~346KB) eingelesen und ausgewertet |
| Domaenenwissen | Oeffentliche Quellen zu Trassenbestellung, ERegG, SNB recherchiert |
| Glossar | 35+ Abkuerzungen und Fachbegriffe dokumentiert |
| Problemfelder | 5 Hauptprobleme identifiziert (Deployment, Doku, Tech Debt, Altsystem, Teams) |
| Architekturskizze | Systemkontext mit allen Komponenten und Schnittstellen |
| Confluence-Seiten | 7 Seiten unter "Analyse pathOS" publiziert |
| Option | Beschreibung | Geschaetzter Aufwand |
|---|---|---|
| Architektur-Diagramme verfeinern | draw.io Diagramm erstellen, Datenfluss detaillieren | ~30 Min |
| Team-zu-Projekt-Mapping | Welches Team besitzt welche Repos? Basis fuer Reorganisation | ~45 Min |
| Deep Dive Kern-Services | pom.xml, Dependencies, Code-Metriken der wichtigsten Services | ~60 Min |
| Geschaeftsprozesse vertiefen | Vorstudie Kapitel 3-5, BPMN-Prozesse aus Confluence | ~45 Min |
| Management-Praesentation | Erste Folien/Confluence-Homepage fuer Management Board | ~30 Min |
Zentrale Anlaufstellen fuer das pathOS-Projekt und die Analyse.
| System | URL | Beschreibung |
|---|---|---|
| GitLab (pathOS) | git.tech.rz.db.de/bestellsystem1 | 167 Projekte, 9 Untergruppen |
| Confluence (pathOS Space) | Confluence BES Space | Fachliche und technische Dokumentation |
| Runbook (Architektur) | Runbook Architektur | arc42-Architekturdokumentation (aktuell) |
| Portal UI (Produktion) | pathos.app.db.de | Produktives Bestellportal |
| Portal UI (KTU/Test) | pathos-iat.app.db.de | Kundentestumgebung ABN1 |
| Portal UI (EVU-Test) | pathos-test.app.db.de | EVU-Integrationstests ABN8 |
| Common Interface (Prod) | api.pathos.dbinfrago.com | TAF/TAP SOAP-Schnittstelle |
| Stammdaten (Prod) | sb.pathos.dbinfrago.com | Stammdaten-REST-API fuer EVUs |
| Jira | arija.jaas.service.deutschebahn.com | Ticketsystem (O2CBS-, O2CSYS-, TTTI-Projekte) |
| Kafka UI (DEV) | kafka-ui.bsz-dev.cnp-test.comp.db.de | Kafka-Topics Entwicklung |
| Kafka UI (ABN) | kafka-ui.bsz-abn.cnp-test.comp.db.de | Kafka-Topics Abnahme |
| SonarQube | (intern) | Code-Qualitaet |
| DefectDojo | vistadojo-prd2-igo.vista.comp.db.de | Schwachstellenverwaltung |
| Grafana (Monitoring) | (via CNP) | Metriken, Logging, Tracing |
| Quelle | URL | Beschreibung |
|---|---|---|
| DB InfraGO | dbinfrago.com | Unternehmensseite |
| DB InfraGO GitHub | github.com/dbinfrago | Oeffentliche Repos (Capella, OpenStation, etc.) |
| Network Statement (SNB) | SNB / Network Statement | Vertragliche Grundlage Trassennutzung |
| Bundesnetzagentur (Schiene) | BNetzA Trassenpreise | Regulierung und Trassenpreise |
| DB API Marketplace | developers.deutschebahn.com | Oeffentliche DB APIs |
| TAF/TAP TSI (RNE) | (RNE Website) | EU-Standard fuer Trassenanmeldung |
| Dokument | Ort | Beschreibung |
|---|---|---|
| Lokaler Workspace | project-audit/ | Alle Rohdaten, Scripts, Analysen |
| GitLab-Inventar | project-audit/data/gitlab-inventory/ | 167 Projekte als JSON, CSV, Markdown |
| Confluence-Export | project-audit/data/confluence-export/ | 143 Seiten als Markdown + HTML |
| Analysen | project-audit/analysis/ | Gesamtbild, Runbook-Analyse, Diagramme |
| Scripts | project-audit/scripts/ | GitLab-Inventory, Confluence-Export, Push |
Szenario: Ein EVU-Sachbearbeiter bestellt eine Trasse im Gelegenheitsverkehr ueber das Bestellportal.
Dieser Happy Path zeigt den idealen Ablauf ohne Fehler, Ablehnungen oder Sonderfaelle. Er illustriert den Datenfluss durch alle beteiligten IT-Systeme aus Kundensicht.
| 1. Login Portal oeffnen DB WebSSO |
➔ | 2. Planung Route waehlen Entwurf erstellen |
➔ | 3. Anmeldung Train erstellen Absenden |
➔ | 4. Warten Status: In Bearbeitung |
➔ | 5. Angebot Preis + Laufweg pruefen |
➔ | 6. Annehmen Vertrag abschliessen |
➔ | 7. Vertrag einsehen PDF laden |
| Kundensicht | Oeffnet pathos.app.db.de, wird zu DB WebSSO weitergeleitet, gibt Benutzername + Passwort + 2. Faktor ein |
|---|---|
| IT-Systeme | SIPS Access Proxy ➔ DB WebSSO (Entra ID) ➔ Portal UI ➔ Portal Middleware (Token-Validierung) ➔ NuR-Service (Kundennummern laden) |
| Daten | JWT Token, Benutzerrolle, zugeordnete Kundennummern |
| Protokoll | OIDC (OpenID Connect), REST |
| Kundensicht | Waehlt Start-/Zielbahnhof, Datum, Zuggattung, Geschwindigkeit. Sieht Route auf Karte. Kann Entwurf speichern. |
|---|---|
| IT-Systeme | Portal UI ➔ Portal Middleware (Stammdaten aus Cache) ➔ Stammdaten-Bereitstellung (Betriebsstellen, Strecken, Zuggattungen) ➔ GeoServer (Kartendarstellung) |
| Daten | Betriebsstellen, Streckenklassen, Zuggattungen, Triebfahrzeuge, Ordnungsrahmen |
| Protokoll | REST/JSON (intern), WMS/WFS (GeoServer) |
| Kundensicht | Klickt "Anmeldung absenden". Sieht Bestaetigung mit Vorgangsnummer. |
|---|---|
| IT-Systeme | Portal UI ➔ Portal Middleware (Validierung) ➔ Kafka (Topic: eingangsnachricht) ➔ Steuerung Vertrieb (Camunda-Prozessinstanz starten) ➔ Auftrags-Verwaltung (Train + PathRequest speichern) |
| Daten | Train-Objekt (TDM JSON), PathRequest, TrainID, Kundennummer |
| Protokoll | REST ➔ Kafka ➔ REST |
| Kundensicht | Sieht Status "In Bearbeitung" im Portal. Kann andere Anmeldungen bearbeiten. |
|---|---|
| IT-Systeme |
|
| Daten | PathRequest ➔ Produktionsauftrag ➔ Path + PathDetailsMessage ➔ Trassenpreis ➔ VertragsAngebot |
| Protokoll | Kafka (async), REST (sync) |
| Kundensicht | Erhaelt Benachrichtigung (oder sieht neuen Status im Portal). Oeffnet Angebot: Laufweg, Verkehrstage, Trassenpreis. |
|---|---|
| IT-Systeme | Portal UI ➔ Portal Middleware ➔ Auftrags-Verwaltung (REST: Auftraege-API) - Angebot mit PathDetails laden |
| Daten | VertragsAngebot (PathDetailsMessage), Trassenpreis, Laufweg, Verkehrstage |
| Protokoll | REST/JSON |
| Kundensicht | Klickt "Angebot annehmen". Sieht Bestaetigung: Vertrag geschlossen. |
|---|---|
| IT-Systeme | Portal UI ➔ Portal Middleware ➔ Kafka (eingangsnachricht) ➔ Steuerung Vertrieb (Camunda: Annahme-Schritt) ➔ Auftrags-Verwaltung (ProduktVertrag erstellen, Kafka: auftragsverwaltung) |
| Daten | Annahme-Nachricht ➔ ProduktVertrag (TDM) |
| Protokoll | REST ➔ Kafka ➔ REST |
| Kundensicht | Sieht Vertrag im Portal. Kann PDF herunterladen. Trasse ist gebucht. |
|---|---|
| IT-Systeme |
|
| Daten | ProduktVertrag, Abrechnungsdaten, Vertragsdaten fuer Stationsportal, TBV-Pruefung |
| Protokoll | REST, Kafka |
| Schritt | Beteiligte Systeme | Kernobjekt | Dauer (GELV) |
|---|---|---|---|
| 1. Login | Portal, WebSSO, NuR | JWT Token | Sekunden |
| 2. Planung | Portal, Stammdaten, GeoServer | Entwurf | Minuten |
| 3. Anmeldung | Portal, SV, AV | Train + PathRequest | Sekunden |
| 4. Verarbeitung | SV, BEP, IFP, TPN/BaDiFa, AC | Produktionsauftrag ➔ PathDetails | Minuten-Stunden |
| 5. Angebot | Portal, AV | VertragsAngebot | Sekunden |
| 6. Annahme | Portal, SV, AV | ProduktVertrag | Sekunden |
| 7. Vertrag | Portal, AV, AC, Archiv, Stationsportal, TBV | ProduktVertrag + Abrechnung | Sekunden-Minuten |
Hinweis: Bei Netzfahrplan-Anmeldungen (NFPL) dauert Schritt 4 deutlich laenger (Wochen bis Monate), da die Fahrplankonstruktion im Rahmen des Jahresfahrplans erfolgt. Zusaetzlich gibt es VNP/ENP-Signale und ein Koordinierungsverfahren bei Konflikten.
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Basis: 23 pom.xml + 1 package.json der Kern-Services
| Kategorie | Bewertung | Details |
|---|---|---|
| Java-Version | 🟡 | 21 in Services, aber Parent-POM noch auf 17. Inkonsistenz. |
| Spring Boot | 🟡 | 3.5.13 auf Master — Upgrade auf 4.0.5 laeuft aktiv. Portal fertig, CI/SV/AV in Arbeit. EOL 3.5: Juni 2026. |
| Camunda | 🟢 | 8.8.22 - aktuell, Upgrade auf 8.9 geplant |
| Angular | 🟢 | 21.2.4 - sehr aktuell |
| Dependencies | 🟢 | Renovate aktiv, CVEs werden gepatcht |
| Versionskonsistenz | 🟡 | SV hat eigenen Parent-POM, Cucumber/OTel Versionen divergieren |
| Modularitaet | 🟡 | SV mit 18 Maven-Modulen sehr komplex |
| API-Versionierung | 🟢 | Saubere OpenAPI-basierte Versionierung (data-model v10.0.0) |
| Security | 🟢 | Aktive CVE-Patches, Signature-Libs, OAuth2, Mutual SSL |
| Feature Toggles | 🟢 | Togglz integriert in SV und AV |
| Monitoring | 🟢 | OpenTelemetry, Micrometer, Prometheus |
| Testing | 🟡 | Cucumber + JUnit + WireMock, Testkonzept in Ueberarbeitung (ADR-70) |
| Komponente | Version | Risiko |
|---|---|---|
| Java | 17 (Parent) / 21 (Services) | Parent noch auf 17 |
| Spring Boot | 3.5.13 (Master) → 4.0.5 (in Arbeit) | Upgrade laeuft, EOL Juni 2026 |
| Camunda 8 | 8.8.22 | OK |
| Angular | 21.2.4 | OK |
| PostgreSQL Driver | 42.7.10 | OK |
| Flyway | 11.20.3 | OK |
| Log4j2 | 2.25.4 | OK |
| Jackson | 2.21.2 | OK |
| OpenAPI Generator | 7.21.0 | OK |
| AWS SDK | 2.42.34 | OK |
| TypeScript | ~5.9.2 | OK |
Folgende CVEs wurden aktiv in den pom.xml-Dateien gepatcht:
18 Maven-Module: testutils, model-process, model, tdm-utils, kafka-utils, i18n, api-adapter, persistence, monitoring-utils, process-configuration, camunda-interface, camunda8, application, camunda8-jobworker, assemblies, kit, kafka, feature-toggle
10+ interne API-Dependencies: trassenanmeldung (v8.11.0), versandauftrag (v3.11.0), versandergebnis (v2.14.0), vertriebsauftraege (v8.3.0), produktionsauftrag (v3.5.0), eventmodel (v3.2.0), kundendaten (v2.9.0), objectinfomessage (v2.11.0), data-model (v10.0.0), camunda-events (v2.2.0)
| Prio | Empfehlung | Begruendung |
|---|---|---|
| HOCH | Spring Boot 4 Upgrade abschliessen | EOL 3.5 ist Juni 2026. Upgrade laeuft aktiv (Portal fertig, CI/SV/AV in Arbeit). Ziel: 4.0.5 |
| KRITISCH | Parent-POM Konsolidierung | SV nutzt eigenen Parent. Divergenz fuehrt zu Inkonsistenzen. |
| HOCH | Java-Version im Parent auf 21 | Alle Services nutzen bereits 21, Parent hinkt hinterher. |
| HOCH | Cucumber-Version vereinheitlichen | 7.34.3 vs 7.23.0 zwischen Parent und SV. |
| HOCH | SV-Modularitaet pruefen | 18 Module ist sehr viel. Konsolidierungspotenzial? |
| MITTEL | OpenTelemetry synchronisieren | 2.27.0 vs 2.26.1 zwischen Parent und SV |
| MITTEL | Testkonzept modernisieren | ADR-70 in Arbeit, Cucumber -> JUnit Migration |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Basis: Runbook, Confluence, GitLab-Berechtigungen
Seit PI 39 neue Struktur: Team STeam wurde aufgeloest. Stattdessen gibt es ein OPs-Team mit 2 festen + rotierenden Mitgliedern aus allen Teams. Die STeam-Aufgaben wurden auf die Entwicklungsteams verteilt.
| Team | Subdomaene | Kern-Verantwortung | Projekte (ca.) |
|---|---|---|---|
| Team Zero | TAF/TAP Schnittstellen | Common Interface, Stammdaten, TAF/TAP-TDM-Konverter, TBV-Konverter + OPs-Anteil | ~12 |
| Team 404 | Bestellportal | Portal UI (Angular), Portal Middleware + OPs-Anteil | ~4 |
| Team CIB | Prozesse + Backend | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector + OPs-Anteil | ~15 |
| Team OPs (NEU) | Infrastruktur / DevOps | CI/CD, Deployment, Monitoring, Security. 2 feste + rotierende Mitglieder | ~47 (verteilt) |
| AUFGELOEST seit PI 39 - Aufgaben verteilt auf alle Teams + OPs | |||
| Team BSSUPPORT | Support | 2nd Level Support | 0 (Jira) |
| Team FbF | Fachliche Betriebsfuehrung | Fachlicher Betrieb, Konfiguration | 0 |
| Stage | Umgebungen | Zweck |
|---|---|---|
| DEV | BU, EU, BASE-AT, IEU, SIT, SIT2, LUP, Demo | Entwicklung, Review, Integration, Performance |
| ABN | E2E, SAT1-3, ABN1-2-4-8, PREPROD | TTT-Integration, Kundentests, Abnahme |
| PROD | PROD | Produktionsumgebung (SL Gold) |
17+ Umgebungen mit jeweils eigenem Kafka-Cluster, DB-Instanz und Keycloak.
| ID | Engpass | Schwere | Details |
|---|---|---|---|
| E1 | Deployment-Bottleneck | KRITISCH | 17+ Umgebungen, manuelle Orchestrierung, kein Auto-Smoketest, TTT-Abstimmung noetig |
| E2 | OPs-Team Kapazitaet | HOCH | Nur 2 feste Mitglieder fuer 47 Infra-Projekte. Rotierende Besetzung birgt Wissensverlust-Risiko. |
| E3 | Cross-Team Dependencies | HOCH | 10+ interne APIs, kein Contract Testing (ADR-50 obsolet), Schnittstellenaenderungen erfordern Koordination |
| E4 | TTT-Abhaengigkeit | MITTEL | Releases muessen mit TTT-Releasemanagement abgestimmt werden |
| E5 | Wissenskonzentration | MITTEL | DevOps-Know-How erst seit 02/2025 im Aufbau, Ziel "You build it, you run it" noch nicht erreicht |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Konsolidierung aller Findings aus Phase 1-3
Management Summary: pathOS ist ein funktionierendes, aktiv entwickeltes System mit solidem Tech-Stack. Die Hauptrisiken liegen nicht im Code, sondern in der operativen Komplexitaet: 17+ Umgebungen, 47 Infra-Projekte bei einem Team, Spring Boot EOL in 2 Monaten, Parallelbetrieb mit Altsystem TPN.
| # | Aktion | Begruendung | Aufwand |
|---|---|---|---|
| A1 | Spring Boot 4 Upgrade abschliessen | EOL 3.5 ist Juni 2026. Upgrade laeuft aktiv (Portal fertig, CI/SV/AV in Arbeit, Ziel: 4.0.5). | HOCH (1-2 Sprints verbleibend) |
| A2 | Parent-POM Java auf 21 anheben | Inkonsistenz: Parent=17, Services=21 | NIEDRIG (1 Tag) |
| A3 | Parent-POM Konsolidierung pruefen | SV hat eigenen Parent, Versionsdivergenzen | MITTEL (1 Sprint) |
| # | Aktion | Begruendung | Aufwand |
|---|---|---|---|
| A4 | Deployment-Automatisierung | Smoketests, Release-Checkliste in Pipeline | MITTEL (2 Sprints) |
| A5 | DevOps-Wissen verteilen | Jedes Team 2+ Personen mit Deployment-Faehigkeit | MITTEL (laufend) |
| A6 | Camunda 8.8 auf 8.9 Upgrade | Roadmap Item 8.2 | MITTEL (1-2 Sprints) |
| A7 | Monitoring-Konzept abschliessen | Roadmap Item 4.1, seit PI 39 | MITTEL (1 Sprint) |
| A8 | Disaster-Recovery-Test 3 | Roadmap Item 5.2/5.3 | MITTEL (1 Sprint) |
| A9 | Secret-Rotation Konzept | Roadmap Item 3.2 | MITTEL (1 Sprint) |
| A10 | AppMesh-Alternative | AWS EOL 2026 | Abhaengig von CNP |
| A11 | Repo-Beschreibungen ergaenzen | 60% ohne Beschreibung | NIEDRIG (1 Tag) |
| A12 | Archivierte Repos aufraeumen | 32 archivierte Projekte | NIEDRIG (1 Tag) |
| # | Aktion | Begruendung | Aufwand |
|---|---|---|---|
| A13 | Infra-Verantwortung aufteilen | STeam als Bottleneck entlasten | HOCH (mehrere PIs) |
| A14 | Contract Testing einfuehren | 10+ APIs ohne Contract Tests | MITTEL (2-3 Sprints) |
| A15 | Umgebungen konsolidieren | 17+ pruefen, SAT1/2/3 zusammenlegen? | MITTEL (1-2 Sprints) |
| A16 | Full-Table-Scans in AV beheben | Roadmap Item 7.1 | MITTEL (1-2 Sprints) |
| A17 | Daten-Partitionierung Fahrplanjahr | Roadmap Item 7.2, bis Maerz 2027 | HOCH (2-3 Sprints) |
| A18 | Keycloak-Projekte konsolidieren | 5+ separate Repos | NIEDRIG (1 Sprint) |
| A19 | API-Versionierung formalisieren | Roadmap Item 6.4 | MITTEL (1 Sprint) |
| A20 | GitLab-Repos restrukturieren | Roadmap Item 6.7 | MITTEL (1-2 Sprints) |
| # | Aktion | Begruendung | Aufwand |
|---|---|---|---|
| A21 | Team-Schnitt an Subdomaenen | Klare Ownership pro Bounded Context | HOCH (Orga) |
| A22 | STeam wird Platform Team | Self-Service-Tools statt Bottleneck | HOCH (Orga) |
| A23 | TTT-Entkopplung | Eigene E2E-Tests | HOCH (mehrere PIs) |
| A24 | TPN-Abloesung abschliessen | Parallelbetrieb beenden | SEHR HOCH |
| Risiko | Wahrscheinlichkeit | Impact | Massnahme |
|---|---|---|---|
| Spring Boot EOL (Upgrade laeuft) | MITTEL (Upgrade aktiv) | HOCH | A1 — Portal fertig, CI/SV/AV in Arbeit |
| AppMesh EOL ohne Alternative | MITTEL | HOCH | A10 |
| Deployment-Ausfall durch Komplexitaet | MITTEL | HOCH | A4, A5, A15 |
| STeam-Mitarbeiter verlassen Projekt | MITTEL | KRITISCH | A5, A13, A22 |
| DB-Performance bei Wachstum | MITTEL | HOCH | A16, A17 |
| Security-Incident (veraltete Deps) | NIEDRIG | HOCH | Renovate aktiv |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | 1949 Issues ueber 7 Team-Projekte + ART-Board (90 Tage)
| Team | Key | Issues | Fertig | In Arbeit | Offen | Bugs | Enabler | Completion |
|---|---|---|---|---|---|---|---|---|
| Team 404 | O2C404 | 500 | 315 | 33 | 152 | 165 | 53 | 63% |
| Team Zero | O2CZERO | 417 | 251 | 15 | 151 | 64 | 56 | 60% |
| OPs Squad | O2COS | 379 | 292 | 14 | 73 | 116 | 60 | 77% |
| Team CIB | O2CCIB | 342 | 239 | 13 | 90 | 67 | 16 | 70% |
| DevOps | O2CDEVOPS | 289 | 158 | 39 | 92 | 27 | 156 | 55% |
| QA/Test | O2CQST | 14 | 11 | 0 | 3 | 0 | 1 | 79% |
| O2CSYS | 8 | 5 | 0 | 3 | 0 | 4 | 63% | |
| GESAMT | 1949 | 1271 | 114 | 564 | 439 | 346 | 65% |
Assignees im OPs-Board kommen aus allen Teams:
| Person | Stamm-Team | OPs-Issues |
|---|---|---|
| Steven Meixner | Zero | 27 |
| Hans-Henning Ramberger | CIB | 23 |
| Jonas Koehler | CIB | 19 |
| Henrik Scholl | OPs (fest) | 19 |
| Kathrin Schleich | Zero | 12 |
| Diego Da Costa Souza | 404 | 10 |
| Frank Lemke | Zero | 10 |
| Team | Aktive Personen | Kern (>10 Issues) | Top-Contributor |
|---|---|---|---|
| Team 404 | 15 | 7 | Ana Cvitkovic (78) |
| Team CIB | 16 | 6 | Bishara Jaser (73) |
| Team Zero | 9 | 6 | Steven Meixner (64) |
| OPs Squad | 23 (rotierend) | 7 | Steven Meixner (27) |
| DevOps | 7 | 3 | Jan Lubenow (114!) |
| Quelle | Beschreibung | Status |
|---|---|---|
| TTTI Board | Uebergreifende Issues pathOS <> TTT-Verbund | Naechste Iteration |
| TTTSol Board | Fachliche Klaerungen | Naechste Iteration |
| Support-Board | Kunden-Issues, anderes Jira, wird neu aufgesetzt | Naechste Iteration |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Wird regelmaessig aktualisiert
Dieses Backlog dokumentiert alle offenen Aufgaben, laufende Arbeiten und moegliche Erweiterungen des pathOS Portfolio-Audits. Status: 🟢 In Progress | 🟡 Bald | ⚪ Irgendwann
| # | Aufgabe | Beschreibung | Seit |
|---|---|---|---|
| 1 | Personal-Analyse verfeinern | Tenure-Daten vollstaendig (176 Personen). Bug-Causation-Methodik dokumentiert. Naechster Schritt: Git-Contributions korrelieren. | 27.04. |
| 2 | Confluence-Seiten pflegen | 22 Seiten + Stammseite aktiv. Regelmaessige Updates bei neuen Erkenntnissen. | 22.04. |
| 3 | Knowledge Graph erweitern | SQLite-DB mit 35 Nodes, 29 Edges. Jira-Exports und SonarQube-Metriken einpflegen. | 27.04. |
| # | Aufgabe | Beschreibung | Prioritaet |
|---|---|---|---|
| 4 | Management-Praesentation | Kompakte Zusammenfassung fuer Management Board: Status, Findings, Herausforderungen, naechste Schritte. Als Confluence-Seite. | HOCH |
| 5 | Team-Reorganisation vertiefen | Konkrete Vorschlaege basierend auf Velocity + Personendaten. OPs-Rotation optimieren, SPOF-Risiken adressieren. | HOCH |
| 6 | Code-Qualitaet / SonarQube vertiefen | Testabdeckung pro Team/Service. Coverage-Trends. Kritische Smells priorisieren (S1192 in SV: 976 Duplikate). | HOCH |
| 7 | VDV-Erweiterung Abrechnung klaeren | Welche Daten, Schnittstelle zu AC, Business Owner treibt an. 5 blocked High-Priority Tickets in TTTSol. | MITTEL |
| 8 | Confluence Seiten 1-5 Inhalt aktualisieren | Inhalte teilweise veraltet (noch aus Iteration 1). Mit aktuellen Erkenntnissen anreichern. | MITTEL |
| # | Aufgabe | Beschreibung | Abhaengigkeit |
|---|---|---|---|
| 9 | Support-Board analysieren | Anderes Jira-System, wird gerade neu aufgesetzt. 2nd-Level-Support-Tickets auswerten. | Neues Board muss stehen |
| 10 | Performance-Daten | Produktions-Metriken (Response Times, Error Rates), LuP-Ergebnisse. Prometheus/Grafana-Zugang noetig. | Zugang zu Monitoring |
| 11 | Geschaeftsprozesse (BPMN) vertiefen | Camunda-Prozesse aus Confluence dokumentiert. Tiefere Analyse der Prozess-Instanzen und Fehlerquoten. | Camunda-Zugang |
| 12 | draw.io Diagramme einbetten | Architektur-Diagramm als draw.io Macro in Confluence einbetten (manuell). | Keine |
| 13 | Git-Contributions analysieren | Commit-Frequenz, Code-Ownership pro Service, Bus-Faktor berechnen. | GitLab API |
| 14 | Dependency-Analyse | Abhaengigkeiten zwischen Services (Kafka-Topics, REST-Calls). Service-Mesh-Topologie. | Keine |
| 15 | Incident-Analyse | Produktions-Incidents seit Go-Live (Dez 2025). MTTR, Haeufigkeit, betroffene Services. | Incident-Daten |
| 16 | Kosten-Analyse | AWS-Kosten pro Service/Team. Optimierungspotenzial (Right-Sizing, Reserved Instances). | AWS Cost Explorer Zugang |
| 17 | Automatisierte Reports | Woechentlicher/monatlicher Report-Generator (Velocity, Bug-Rate, SonarQube-Trends). | Stabile Datenbasis |
| 18 | Test-Seite loeschen | "TEST Umlaut-Pruefung" (ID: 583338908) von Confluence entfernen. | Keine |
| Datum | Meilenstein |
|---|---|
| 22.04.2026 | Domain Discovery: 167 GitLab-Projekte, 143 Confluence-Seiten, Runbook analysiert |
| 22.04.2026 | Technical Deep Dive: 23 pom.xml, Dependency-Versionen, Tech-Stack dokumentiert |
| 23.04.2026 | TTT-Programm: Go-Live Dez 2025, Hypercare, 8 Programmrisiken dokumentiert |
| 23.04.2026 | Velocity 12 Monate: 4875 Issues, Go-Live-Effekt, Team-Trends identifiziert |
| 24.04.2026 | SonarQube: 74 Projekte, Smells-Detail, Coverage pro Team |
| 24.04.2026 | Geschaeftsprozesse: BPMN-Flows aus Camunda/Confluence dokumentiert |
| 24.04.2026 | Produkt-Roadmap konsolidiert (PO-Input + technische Roadmap) |
| 27.04.2026 | Personal-Analyse: Tenure (176 Personen), Bug-Korrelation, Risiko-Matrix |
| 27.04.2026 | Knowledge Graph + Skills aufgesetzt (SQLite, FTS5, 3 Kiro-Skills) |
| 30.04.2026 | Tenure vollstaendig, Bug-Causation Methodik dokumentiert, Backlog erstellt |
| Quelle | Umfang | Status |
|---|---|---|
| GitLab | 167 Projekte | ✅ Inventarisiert |
| Confluence (BES Space) | 143 Seiten | ✅ Exportiert |
| Confluence (TTSI Space) | 44 Seiten | ✅ Exportiert |
| Runbook (arc42) | ~346KB | ✅ Eingelesen |
| pom.xml / package.json | 23 + 1 | ✅ Analysiert |
| SonarQube | 74 Projekte + Smells | ✅ Analysiert |
| Jira (alle Boards) | 24.700 Issues | ✅ Analysiert |
| Velocity (12 Monate) | 4875 Issues | ✅ Analysiert |
| Tenure-Daten | 176 Personen | ✅ Vollstaendig |
| Support-Board | Anderes Jira | ⚠ Wird neu aufgesetzt |
| Performance-Daten | Produktion | ❌ Kein Zugang |
| Incident-Daten | Seit Go-Live | ❌ Kein Zugang |
| AWS-Kosten | Cost Explorer | ❌ Kein Zugang |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Business Owner: Andre Knie
pathOS ist seit Dezember 2025 produktiv (Go/No-Go Sep 2025 positiv). Das System ist funktionierend und aktiv entwickelt mit solidem Tech-Stack und guter Security. Die Hauptrisiken liegen in der operativen Komplexitaet und Personenabhaengigkeiten — nicht im Code selbst.
| Bereich | Status | Details |
|---|---|---|
| Produktivbetrieb | 🟢 Stabil | Seit Dez 2025 produktiv. Verlaengerte Hypercare laeuft noch. NEP2 stabil. |
| Spring Boot Upgrade | 🟡 In Arbeit | EOL 3.5: Juni 2026. Portal fertig, CI/SV/AV in Arbeit. Alle 3 Teams beteiligt. |
| Portal-Qualitaet (404) | 🟡 Kritisch | Bug-Rate 33% (steigend). Frontend-Qualitaetsproblem. 2 Entwickler mit >69% Bug-Anteil. |
| Backend (CIB) | 🟢 Gut | Bug-Rate von 36% auf 9% gesunken. Erfolgsgeschichte nach Go-Live. |
| Schnittstellen (Zero) | 🟢 Stabil | Niedrigste Bug-Rate (15%). Beste Code-Qualitaet (91.8% Coverage). |
| DevOps SPOF | 🔴 Risiko | Jan Lubenow = 39% aller DevOps-Issues. Kritischer Single Point of Failure. |
| Datum | Meilenstein |
|---|---|
| Dez 2025 | 🟢 Go-Live pathOS (produktiv) |
| Sep 2025 | 🟢 Go/No-Go positiv |
| Apr 2026 | 🟢 Spring Boot 4 Portal abgeschlossen |
| Apr 2026 | 🟡 Portfolio-Audit gestartet (167 Projekte, 24.7K Issues analysiert) |
| Apr 2026 | 🟡 Personal-Analyse: 176 Personen, Tenure, Bug-Korrelation |
| # | Finding | Evidenz | Bewertung |
|---|---|---|---|
| 1 | Portal-Frontend hat systematisches Qualitaetsproblem | Bug-Rate 33% (steigend), 2 Devs mit >69% Bug-Anteil, QA wenig aktiv. Tenure korreliert NICHT mit Qualitaet. | KRITISCH |
| 2 | DevOps ist personenabhaengig | Jan Lubenow: 39% aller Issues, 1222 Issues gesamt. Kein gleichwertiger Backup. | KRITISCH |
| 3 | CIB zeigt: Stabilisierung ist moeglich | Bug-Rate von 36% (Jan) auf 9% (Apr). Kern-Trio (Bishara/Saurav/Jonas) mit >93% Done-Rate. | POSITIV |
| 4 | Zero liefert beste Code-Qualitaet | 4.2 Smells/1K LoC, 91.8% Coverage. Stabiles Team + gute Praktiken = niedrige Bug-Rate. | POSITIV |
| 5 | OPs-Rotation belastet Zero ueberproportional | 3 von 5 Rotatoren kommen aus Zero. Steven Meixner: 91 Issues (Zero + OPs). | MITTEL |
| 6 | Inaktive Mitglieder blockieren Kapazitaet | Norbert Maurer (83% offen), Alexander Petioky (1 Issue/90d), Luca Caracciolo (QA, 5 Issues). | MITTEL |
| # | Risiko | Tickets | Situation |
|---|---|---|---|
| 1 | Implizite Annahme NAÄ | TTTSOL-2184 (Highest) O2CCIB-6931 (offen) | Kunden versprochen, dass sie den Standard-Prozess erleben. CIB-Umsetzung auf naechsten PI geschoben. Fachlich TopThema, technisch unpriorisiert. |
| 2 | 20h Zug — Abrechnung | TTTSOL-1677 (High) TTTSOL-2149 (BLOCKED) | Loesung funktioniert nicht. Abrechnung des 20h-Zugs ist blockiert. Korrekte Abrechnung nicht moeglich. |
| 3 | Abrechnung TTT / AC Trasse | 41 offene Tickets 8 davon Highest | Grundlegendes Risiko: Nicht korrekt abrechnen zu koennen. Taskforce-FplW aktiv. Tobias Gehrmann bearbeitet 3 Highest-Tickets. |
| # | Massnahme | Ziel | Zeithorizont |
|---|---|---|---|
| 1 | Jan Lubenow entlasten | Wissenstransfer auf David Steinkopff + Henrik Scholl. Kein Einzelner >25%. | Sofort |
| 2 | Portal-Qualitaet steigern | Code-Reviews Emmanuel/Leon. QA aktivieren. Frontend-Testautomatisierung. | PI 40 |
| 3 | Steven Meixner entlasten | OPs-Rotation auf CIB/404 ausweiten. Zero-Kernarbeit schuetzen. | PI 40/41 |
| 4 | Spring Boot 4 abschliessen | CI, SV, AV auf 4.0.5. Deadline: Juni 2026 (EOL). | PI 40 |
| 5 | CIB Best Practices teilen | Bishara/Saurav/Jonas als Mentoren fuer 404. Arbeitsweise uebertragen. | PI 41 |
| Thema | Apr | Mai | Jun | Jul | Aug | Sep | Okt | Nov | Dez | Jan 27 | Feb | Mär | Apr | Mai | Jun |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FACHLICHE MEILENSTEINE | |||||||||||||||
| Hypercare (verl.) | |||||||||||||||
| NEP2 | |||||||||||||||
| GelV | |||||||||||||||
| ujBau | |||||||||||||||
| FplJ 28 Vorbereitung | |||||||||||||||
| SL Silber Plus | ▲ | ||||||||||||||
| TECHNISCHE MEILENSTEINE | |||||||||||||||
| Spring Boot 4 | EOL | ||||||||||||||
| Camunda 8.9 | |||||||||||||||
| Monitoring + Netcool | |||||||||||||||
| DR-Test + Secrets | |||||||||||||||
| Deployment-Autom. | |||||||||||||||
| Daten-Partitionierung | |||||||||||||||
| Team-Reorg | |||||||||||||||
| TPN-Abloesung | |||||||||||||||
Kritisch In Arbeit Geplant Strategisch
| Quelle | Umfang |
|---|---|
| GitLab-Projekte | 167 (automatisiert inventarisiert) |
| Confluence-Seiten | 187 (BES + TTSI Space) |
| Jira-Issues | 24.700 (Bulk-Export, 176 Personen) |
| SonarQube | 74 Projekte (Smells + Coverage) |
| Runbook/arc42 | ~346KB Architekturdokumentation |
| pom.xml / package.json | 23 + 1 (Versionsanalyse) |
Durchgefuehrt in 5 Sessions (Apr 2026). Alle Detail-Ergebnisse in den Unterseiten dokumentiert.
"@ $Page15Id = Create-Or-Update-Page -Title "Management Summary" -HtmlBody $MgmtHtml -ParentId $ParentPageId # --- Seite 16: TTT-Programm und NEP2 --- Write-Host "" Write-Host ">> Seite 16: TTT-Programm und NEP2" -ForegroundColor Yellow $TttHtml = @"Stand: $(Get-Date -Format 'yyyy-MM-dd') | Quelle: TTSI Confluence Space
Status: pathOS ist seit Dezember 2025 produktiv (FplJ 27). Go/No-Go war September 2025 — positiv entschieden. Aktuell: Verlaengerte Hypercare + NEP2.
TTT (TAF/TAP TSI — Telematics Applications for Freight / Telematics Applications for Passengers, Technical Specification for Interoperability) ist das uebergreifende Programm zur Einfuehrung des europaeischen Standards fuer Trassenbestellung bei DB InfraGO. Regulatorisch verpflichtend (EU-Verordnungen). Bereits 4x verschoben seit 2014. ~400 Marktteilnehmer muessen gleichzeitig umgestellt werden.
| Value Team | Bereich | System |
|---|---|---|
| O2C (Order2Cash) | Vertrieb | pathOS — Trassenbestellung |
| C2S (Capacity2Schedule) | Fahrplan | Fahrplanung, Kapazitaetsmanagement |
| S2O (Schedule2Operate) | Betrieb | Betriebliche Meldungen |
| Meilenstein | Bedeutung | Status |
|---|---|---|
| Go/No-Go | Entscheidung September 2025 | ✅ Positiv entschieden |
| Go-Live FplJ 27 | Fahrplanwechsel Dezember 2025 | ✅ Produktiv seit ~4 Monaten |
| NEP1 | Netzfahrplan-Erstbestellung | ✅ Abgeschlossen |
| Hypercare | Verlaengerte Stabilisierungsphase | ⚠ Laeuft noch |
| NEP2 | Netzfahrplan Phase 2 | ⚠ Aktuell in Arbeit |
| GelV | Gelegenheitsverkehr | ⚠ In Umsetzung |
| ujBau | Umgebungsjahresbau | In Planung |
| Datum | Ereignis | Status |
|---|---|---|
| August 2025 | Messung vor Stellungnahmeverfahren | ✅ |
| September 2025 | Messung nach Stellungnahmeverfahren | ✅ |
| September 2025 | Go/No-Go Entscheidung — POSITIV | ✅ |
| Dezember 2025 | Fahrplanwechsel — Go-Live FplJ 27 | ✅ |
| Seit Dezember 2025 | Hypercare (verlaengert) | ⚠ Laeuft noch |
Diese Risiken wurden vor dem Go-Live (Dez 2025) identifiziert. Einige sind durch den erfolgreichen Go-Live mitigiert, andere bestehen in veraenderter Form weiter.
| ID | Risiko | Status nach Go-Live |
|---|---|---|
| TTTSOL-52 | Unrealistische Go-Live-Entscheidung | ✅ Go-Live war erfolgreich |
| TTTSOL-51 | Rueckstand bei funktionalen Anforderungen | ⚠ NEP2 + GelV noch in Arbeit |
| TTTSOL-50 | Budgetrisiken | ⚠ Weiterhin relevant |
| TTTSOL-48 | Ressourcenengpaesse | ⚠ Weiterhin relevant (Konkurrenz mit anderen Themen) |
| TTTSOL-47 | Mangelnde Qualitaetssicherung | ⚠ 165 Portal-Bugs, 476 TTTI-Issues offen |
| TTTSOL-44 | Ueberplanung ujBau (110 Capabilities) | ⚠ Weiterhin relevant |
| ✅ Go-Live Dez 2025 |
➔ | JETZT Hypercare + NEP2 |
➔ | Jun 2026 Spring Boot 4 (EOL 3.5!) |
➔ | Aug 2026 SL Silber Plus Hypercare Ende |
➔ | H2 2026 GelV, ujBau FplJ 28 |
➔ | 2027 Team-Reorg TPN-Abloesung |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | pathOS ist seit Dezember 2025 produktiv (FplJ 27)
Status: pathOS ist seit ~4 Monaten produktiv. Go-Live war Dezember 2025. Wir befinden uns in verlaengerter Hypercare + NEP2. Service Level Silber Plus wird ab August 2026 erwartet.
| Apr-Jun 2026 JETZT Stabilisieren Spring Boot 4 NEP2 |
➔ | Jul-Sep 2026 Haerten SL Silber Plus Hypercare Ende GelV |
➔ | Okt-Dez 2026 Skalieren ujBau FplJ 28 Vorb. |
➔ | Jan-Jun 2027 Weiterentwickeln Team-Reorg TPN-Abloesung |
Spring Boot 3.5 EOL ist Juni 2026. Upgrade muss jetzt laufen.
| # | Aktion | Deadline | Team |
|---|---|---|---|
| A1 | Spring Boot 4 Upgrade | Juni 2026 (EOL 3.5) | Alle — LAEUFT! Portal fertig, CI/SV/AV in Arbeit |
| A2 | Parent-POM Java 21 + Konsolidierung | Mai 2026 | OPs |
| A3 | NEP2 Funktionalitaet liefern | Laufend | CIB, Zero |
| A4 | Hypercare-Bugs abarbeiten | Laufend | Alle |
| A5 | Monitoring + Netcool | Juni 2026 | OPs |
| A7 | Portal-Bugs reduzieren (165 Bugs!) | Laufend | 404 |
| # | Aktion | Deadline | Team |
|---|---|---|---|
| B1 | Hypercare beenden | Juli 2026 | Alle |
| B2 | Service Level Silber Plus erreichen | August 2026 | OPs |
| B3 | DR-Test 3 + Secret-Rotation | Juli 2026 | OPs |
| B5 | Camunda 8.9 + AV Performance | Aug 2026 | CIB |
| B7 | Deployment-Automatisierung | Aug 2026 | OPs + alle |
| B8 | GelV Erweiterungen | Sep 2026 | CIB, 404 |
| B10 | AppMesh-Alternative | Sep 2026 | OPs/CNP |
| # | Aktion | Deadline | Team |
|---|---|---|---|
| C1 | Daten-Partitionierung Fahrplanjahr | Dez 2026 | CIB |
| C2 | ujBau-Funktionalitaet | Laufend | CIB, Zero |
| C3 | Umgebungen konsolidieren (17+ reduzieren) | Nov 2026 | OPs |
| C4 | Contract Testing einfuehren | Okt 2026 | Alle |
| C6 | FplJ 28 Vorbereitung | Dez 2026 | Alle |
| # | Aktion | Zeitraum | Team |
|---|---|---|---|
| D1 | Team-Reorganisation | Q1 2027 | PM/RTE |
| D2 | OPs wird Platform Team | Q1 2027 | PM/RTE |
| D4 | GitLab-Repos restrukturieren | Q1 2027 | OPs |
| D6 | TPN vollstaendig abloesen | Q2 2027 | Zero, CIB |
| D7 | TTT-Entkopplung | Q2 2027 | Alle |
| Team / Thema | Apr 26 | Mai | Jun | Jul | Aug | Sep | Okt | Nov | Dez | Jan 27 | Feb | Mär | Apr | Mai | Jun |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TEAM 404 (Portal) | |||||||||||||||
| Spring Boot 4 | |||||||||||||||
| NEP2 Portal-Features | |||||||||||||||
| Portal-Bugs (165!) | |||||||||||||||
| GelV Portal | |||||||||||||||
| ujBau Portal | |||||||||||||||
| TEAM CIB (Prozesse/Backend) | |||||||||||||||
| Spring Boot 4 (SV) | |||||||||||||||
| NEP2 Prozesse | |||||||||||||||
| Camunda 8.9 | |||||||||||||||
| AV Full-Table-Scans | |||||||||||||||
| Daten-Partitionierung | |||||||||||||||
| GelV Backend | |||||||||||||||
| TEAM ZERO (TAF/TAP) | |||||||||||||||
| Spring Boot 4 (CI/AV) | |||||||||||||||
| NEP2 Schnittstellen | |||||||||||||||
| EVU-Onboarding | |||||||||||||||
| TPN-Abloesung | |||||||||||||||
| OPs / DevOps | |||||||||||||||
| Monitoring + Netcool | |||||||||||||||
| DR-Test + Secrets | |||||||||||||||
| SL Silber Plus | ▲ | ||||||||||||||
| Deployment-Autom. | |||||||||||||||
| AppMesh-Alternative | |||||||||||||||
| Umgebungen reduzieren | |||||||||||||||
| UEBERGREIFEND / ORGA | |||||||||||||||
| Hypercare (verl.) | |||||||||||||||
| TTTI-Bugs (42) | |||||||||||||||
| Contract Testing | |||||||||||||||
| Team-Reorganisation | |||||||||||||||
| Platform Team | |||||||||||||||
Kritisch/Aktiv In Arbeit Geplant Strategisch ▲ = Meilenstein
| Zeitraum | Fokus | Kritischste Aktion |
|---|---|---|
| Apr-Jun 2026 | Stabilisieren | Spring Boot 4 (EOL Juni!), NEP2, Hypercare-Bugs |
| Jul-Sep 2026 | Haerten | SL Silber Plus (Aug), Hypercare beenden, GelV |
| Okt-Dez 2026 | Skalieren | Daten-Partitionierung, ujBau, FplJ 28 |
| Jan-Jun 2027 | Weiterentwickeln | Team-Reorg, Platform Team, TPN-Abloesung |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | 1000 Issues gesamt, 558 offen
Bewertung: Der "Rueckstau" von 558 offenen Issues ist weniger dramatisch als es aussieht. Der Grossteil sind ungefuehrte Tests (311) und organisatorische Aufgaben (171). Die 42 echten Bugs sind der relevante Handlungsbedarf.
| Typ | Anzahl | Anteil | Bewertung |
|---|---|---|---|
| Test Execution | 220 | 39% | Geplante Testlaeufe, noch nicht durchgefuehrt |
| Aufgabe | 171 | 31% | Organisatorische/koordinative Items |
| Test | 91 | 16% | Testfall-Definitionen |
| Bug | 42 | 8% | Echte Fehler — relevanter Handlungsbedarf |
| Test Plan / Test Set | 28 | 5% | Test-Organisation |
| Story | 6 | 1% | Feature-Anforderungen |
| Status | Anzahl | Bewertung |
|---|---|---|
| Ready for Release | 5 | Quasi geloest |
| Test | 9 | Fix wird getestet |
| In Bearbeitung | 10 | Wird aktiv bearbeitet |
| Offen | 12 | Noch nicht angefasst |
| Blocked | 6 | Blockiert durch Abhaengigkeiten |
| Key | Status | Beschreibung |
|---|---|---|
| TTTI-8102 | Offen | C-Kundennummern koennen nicht an GFD-Z uebergeben werden |
| TTTI-7983 | Ready | Camunda Tasklist PROD: Technischer Fehler TPN-TTTRelatedPlannedTransportId null |
| TTTI-7982 | Ready | Camunda Tasklist PROD: pathID kann nicht aufgeloest werden |
| TTTI-7200 | Ready | NAE wird nicht an Kunden uebergeben |
| Key | Status | Beschreibung |
|---|---|---|
| TTTI-7949 | In Bearbeitung | Kundenclient: Aenderung nur auf Primaervertrag ausloesbar |
| TTTI-7025 | Blocked | TPN wirft Fehler bei Pruefung Bestellung in Abgeschlossen |
| TTTI-7297 | In Bearbeitung | Postkorb: Zugnummer-Spalte zeigt falsch Rot |
| Key | Status | Beschreibung |
|---|---|---|
| TTTI-6572 | Offen | Netzausgeloeste Aenderung kommt nicht an (pathOS/TPN) |
| TTTI-8143 | Blocked | VT fuer Bautrasse werden nicht ausgestanzt |
| TTTI-5654 | Blocked | JourneyLocationTypeCode 05 nicht in PDM vorhanden |
| TTTI-7890 | Offen | Bautrasse bleibt im Phasenstatus FPE offen |
| Key | Status | Beschreibung |
|---|---|---|
| TTTI-8005 | In Bearbeitung | Aufteilen scheitert (vmtl. wg. VZReg am EinbruchsBf) |
| TTTI-7986 | In Bearbeitung | Fpl26: Berichte scheitern mit Timeout |
| Typ | Anzahl |
|---|---|
| Aufgabe | 21 |
| Test | 7 |
| Bug | 6 |
| Story | 1 |
Primaer organisatorische Blocker und Abhaengigkeiten zu anderen Systemen (TPN, GFD-Z, ujBau-Tools).
| Label | Anzahl | Bedeutung |
|---|---|---|
| TTT_MUSS | 21 | Muss-Anforderungen fuer TTT |
| FAHRPLAN | 17 | Fahrplan-Integration |
| TTT_ujBau | 10 | Bau-bezogene Integration |
| TTT_Kunde | 8 | Kundenseitige Themen |
| EVU_SST_TTT | 8 | EVU-Schnittstellen-Tests |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Zeitraum: April 2025 — April 2026 | 4875 Issues analysiert
| Monat | 404 | CIB | Zero | OPs | DevOps | Total | Bugs | Bug% | Kontext |
|---|---|---|---|---|---|---|---|---|---|
| 2025-05 | 108 | 86 | 154 | — | 13 | 361 | 37 | 10% | Entwicklung |
| 2025-06 | 77 | 63 | 110 | — | 32 | 282 | 34 | 12% | Entwicklung |
| 2025-07 | 137 | 88 | 167 | — | 84 | 476 | 83 | 17% | Pre-Go/No-Go |
| 2025-08 | 90 | 41 | 182 | — | 99 | 412 | 65 | 16% | Go/No-Go Vorb. |
| 2025-09 | 160 | 82 | 119 | — | 78 | 439 | 71 | 16% | Go/No-Go positiv |
| 2025-10 | 158 | 78 | 128 | — | 57 | 421 | 81 | 19% | Pre-Go-Live |
| 2025-11 | 178 | 119 | 92 | — | 69 | 458 | 104 | 23% | Pre-Go-Live Peak |
| 2025-12 | 97 | 48 | 100 | — | 45 | 290 | 73 | 25% | GO-LIVE |
| 2026-01 | 134 | 83 | 98 | 39 | 117 | 471 | 96 | 20% | Hypercare |
| 2026-02 | 102 | 54 | 79 | 88 | 38 | 361 | 103 | 29% | Hypercare Peak |
| 2026-03 | 172 | 74 | 100 | 127 | 57 | 530 | 117 | 22% | Stabilisierung |
| 2026-04* | 108 | 80 | 52 | 51 | 26 | 317 | 64 | 20% | Normalisierung |
*April noch nicht abgeschlossen
| Phase | Zeitraum | Bug-Rate | Bewertung |
|---|---|---|---|
| Entwicklung | Apr-Jun 2025 | 10-14% | Normal |
| Pre-Go-Live | Jul-Nov 2025 | 16-23% | Steigend (erwartbar) |
| Go-Live | Dez 2025 | 25% | Go-Live Stress |
| Hypercare Peak | Feb 2026 | 29% | Hoechster Wert! |
| Normalisierung | Apr 2026 | 20% | Sinkend, aber noch hoch |
Bug-Rate steigt seit Go-Live (22% → 33%). Portal ist Kundenfacing — Bugs werden direkt von EVUs gemeldet.
| Person | Total | Done | Open | Bugs | Bewertung |
|---|---|---|---|---|---|
| Ana Cvitkovic | 78 | 71 | 7 | 3 | ⭐ Top-Performer: Hoechster Output, niedrigste Bug-Rate |
| Jasmin Keskin | 45 | 33 | 12 | 19 | Hohe Bug-Zuweisung (42%) |
| Emmanuel Kontcheu Tagne | 42 | 32 | 10 | 29 | ⚠ 69% Bugs! Primaer Bug-Fixer |
| Diego Da Costa Souza | 41 | 30 | 11 | 6 | Spring Boot 4 Portal — erledigt |
| Leon Hoerpel | 35 | 22 | 13 | 25 | 71% Bugs, hoher Backlog |
| Dominik Ruecker | 31 | 19 | 12 | 16 | 52% Bugs |
| Annette Halbhuber | 26 | 13 | 13 | 12 | 50% offen, 46% Bugs |
| Simon Reitinger | 15 | 15 | 0 | 11 | 100% Done, primaer Bug-Fixer |
| Marcel Hufgard | 8 | 4 | 4 | 0 | Geringe Sichtbarkeit |
| 4 weitere | 4 | 0-5 | — | 0 | Kaum sichtbar (je 0-1 Issues) |
Bug-Rate sinkt dramatisch (36% Jan → 9% April). Backend stabilisiert sich. Positiver Trend.
| Person | Total | Done | Open | Bugs | Bewertung |
|---|---|---|---|---|---|
| Bishara Jaser | 73 | 68 | 5 | 16 | ⭐ Top-Performer: 93% Done, solide Bug-Rate |
| Saurav Kumar | 48 | 45 | 3 | 4 | ⭐ 94% Done, nur 8% Bugs |
| Jonas Koehler | 34 | 34 | 0 | 14 | 100% Done, 41% Bugs |
| Dong-Won Han | 20 | 16 | 4 | 2 | Solide |
| Hans-Henning Ramberger | 16 | 16 | 0 | 0 | 100% Done, 0 Bugs — Enabler/Infra? |
| Vasileios Dimitriadis | 11 | 9 | 2 | 5 | 45% Bugs |
| Christian Meins | 9 | 6 | 3 | 7 | 78% Bugs! |
| Harry Braun | 5 | 0 | 4 | 0 | ⚠ Spring Boot 4 SV — alles offen |
| 5 weitere | 1-6 | — | — | — | Geringe Sichtbarkeit |
| Person | Total | Done | Open | Bugs | Bewertung |
|---|---|---|---|---|---|
| Steven Meixner | 64 | 63 | 1 | 21 | ⭐ 98% Done, auch 27 OPs-Issues — Allrounder |
| Bing Shi | 63 | 52 | 11 | 4 | ⭐ Hoher Output, nur 6% Bugs |
| Frank Lemke | 49 | 43 | 6 | 6 | Solide, auch OPs-Beitraege |
| Kathrin Schleich | 27 | 26 | 1 | 7 | 96% Done |
| Michael Weisberg | 23 | 11 | 12 | 0 | ⚠ 52% offen — Backlog-Problem? |
| Bernd Klebl | 16 | 6 | 10 | 6 | ⚠ 63% offen |
| Norbert Maurer [X] | 12 | 2 | 10 | 0 | ⚠ 83% offen, [X] = extern/ausgeschieden? |
Jan Lubenow: 114 von 289 Issues (39%). Kritische Personenabhaengigkeit.
| Person | Total | Done | Open | Bugs | Bewertung |
|---|---|---|---|---|---|
| Jan Lubenow | 114 | 82 | 32 | 13 | ⚠ 39% aller DevOps-Issues! Single Point of Failure |
| David Steinkopff | 18 | 9 | 9 | 2 | 50% offen |
| Henrik Scholl | 10 | 10 | 0 | 0 | 100% Done |
| 4 weitere | 6-8 | — | — | — | Geringe Sichtbarkeit |
| Erkenntnis | Details | Handlungsbedarf |
|---|---|---|
| Jan Lubenow = DevOps SPOF | 39% aller DevOps-Issues, 32 offen | Wissenstransfer, zweite Person aufbauen |
| Team 404 Bug-Rate steigt | 33% im Maerz, Portal ist Kundenfacing | Qualitaetsmassnahmen, mehr Testing |
| Norbert Maurer [X] — 83% offen | 12 Issues, 10 offen, markiert mit [X] | Klaeren: Ausgeschieden? Issues umverteilen |
| Michael Weisberg — 52% offen | 23 Issues in Zero, 12 offen | Backlog pruefen, ggf. umpriorisieren |
| Harry Braun — SB4 SV alles offen | 5 Issues, 0 Done, 4 offen | Spring Boot 4 SV-Upgrade blockiert? |
| Ana Cvitkovic = 404 MVP | 78 Issues, 71 Done, nur 3 Bugs | Anerkennung, Wissenstransfer foerdern |
| CIB stabilisiert sich | Bug-Rate 36% → 9% | Positiver Trend, beibehalten |
| Steven Meixner = Zero+OPs Allrounder | 64 Zero + 27 OPs = 91 Issues | Wertvoll, aber Ueberlastungsrisiko |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | 74 Projekte (Master/Main Branches)
| Team | Lines of Code | Bugs | Vulns | Code Smells | Smells/1K Lines | Avg Coverage | QGate OK | QGate ERROR |
|---|---|---|---|---|---|---|---|---|
| Team CIB | 119K | 15 | 0 | 2737 | 23.0 | 85.7% | 3 | 5 |
| Team 404 | 71K | 7 | 0 | 450 | 6.4 | 83.2% | 0 | 3 |
| Team Zero | 49K | 2 | 0 | 209 | 4.2 | 91.8% | 7 | 3 |
| OPs | 4K | 1 | 6 | 191 | 45.4 | 0% | 1 | 3 |
| Shared Libs | 4K | 0 | 0 | 32 | 8.5 | 0% | 1 | 4 |
Team Zero = Beste Code-Qualitaet: Niedrigste Smell-Dichte (4.2/1K), hoechste Coverage (91.8%), nur 2 Bugs, 7 von 10 Projekten bestehen Quality Gate.
Team CIB = Hoechste technische Schuld: 2737 Code Smells bei 119K Lines (23/1K). Primaer durch Steuerung-Vertrieb (93K Lines, 2214 Smells). Coverage ist gut (85.7%), aber die Smell-Dichte ist 5x hoeher als bei Zero.
Team 404 = Solide: 6.4 Smells/1K ist akzeptabel. Coverage 83.2%. Aber: Kein einziges Projekt besteht das Quality Gate (0 OK, 3 ERROR).
| Service | Team | Lines | Bugs | Smells | Coverage | Dupl% | QGate |
|---|---|---|---|---|---|---|---|
| steuerung-vertrieb | CIB | 93K | 3 | 2214 | 81.6% | 3.8% | ERROR |
| portal-ui | 404 | 43K | 4 | 77 | 85.8% | 2.7% | ERROR |
| tadef-connector | Zero | 28K | 0 | 99 | 0.0% | 5.3% | ERROR |
| portal-middleware | 404 | 26K | 1 | 343 | 81.4% | 1.2% | ERROR |
| auftrags-verwaltung-trasse | CIB | 8.4K | 0 | 102 | 86.2% | 2.3% | OK |
| archivierungsservice | CIB | 6.7K | 2 | 83 | 78.8% | 4.7% | ERROR |
| taftap-tdm-konverter | Zero | 6.6K | 0 | 26 | 90.6% | 0.0% | OK |
| stammdaten-bereitstellung | Zero | 5K | 0 | 13 | 82.0% | 2.4% | OK |
| common-interface | Zero | 4K | 0 | 37 | 93.8% | 0.0% | OK |
| kundendaten-bereitstellung | Zero | 1.8K | 0 | 2 | 96.9% | 0.0% | OK |
| vertragsdaten-verteiler | CIB | 342 | 0 | 3 | 97.2% | 0.0% | OK |
| Finding | Details | Handlungsbedarf |
|---|---|---|
| tadef-connector: 0% Coverage | 28K Lines ohne einen einzigen Test | HOCH: Tests schreiben oder Risiko akzeptieren |
| SV: 2214 Code Smells | 23 Smells pro 1000 Lines, 5x hoeher als Zero | MITTEL: Refactoring-Sprint einplanen |
| Team 404: 0 QGate OK | Kein Portal-Projekt besteht das Quality Gate | MITTEL: QGate-Kriterien pruefen |
| OPs: 6 Vulnerabilities | In database-setup und Infra-Tools | MITTEL: Security-Fixes |
| Zero: Vorbildlich | 4.2 Smells/1K, 91.8% Coverage, 7/10 QGate OK | Best Practice teilen |
| Team | Code-Qualitaet | Interpretation |
|---|---|---|
| Team Zero | ⭐ Sehr gut | Hohe Coverage, wenig Smells, sauberer Code. Erfahrenes Team mit starkem Qualitaetsbewusstsein. |
| Team 404 | 🟡 Gut | Akzeptable Smell-Dichte, gute Coverage. Aber QGate-Failures deuten auf neue Features ohne vollstaendige Qualitaetspruefung. |
| Team CIB | 🟡 Gemischt | SV ist der Problembereich (2214 Smells). Andere CIB-Projekte (AV, VDV) sind sauber. SV-Komplexitaet (18 Module, Camunda) erklaert teilweise die Smell-Dichte. |
| OPs | 🔴 Verbesserungswuerdig | Infra-Code hat 6 Vulnerabilities und hohe Smell-Dichte. Aber: Infra-Code hat andere Qualitaetsanforderungen als Applikationscode. |
| Team | Coverage | Jira Bug-Rate (90d) | Korrelation? |
|---|---|---|---|
| 404 | 84.2% | 33% (steigend) | NEIN — Hohe Coverage, trotzdem viele Bugs |
| CIB | 78.2% | 20% (sinkend) | Teilweise — Niedrigere Coverage, aber Bug-Rate sinkt |
| Zero | 91.8% | 15% (stabil) | JA — Beste Coverage = wenigste Bugs |
Fazit: Team 404 hat gute Coverage aber die hoechste Bug-Rate. Das Problem liegt in der Testqualitaet (Edge Cases, Integration, E2E) — nicht in der Testquantitaet.
| Library | Lines | Coverage | Genutzt von |
|---|---|---|---|
| core-components-kafka | 1.567 | 0% | Allen Kafka-Services |
| core-components-common | 1.096 | 0% | Allen Services |
| signature-database | 1.091 | 0% | Signatur-Validierung |
| signature-message | 622 | 0% | Signatur-Validierung |
Risiko: Ein Bug in diesen Libraries betrifft das gesamte System. Empfehlung: Coverage auf >90% bringen.
Stand: $(Get-Date -Format 'yyyy-MM-dd') | 452 Branches ueber 13 Services
| Metrik | Wert | Bewertung |
|---|---|---|
| Branches gesamt | 452 | |
| Aktiv (≤30 Tage) | 166 | Gesunde Aktivitaet |
| Stale (>60 Tage) | 246 | Aufraeumen noetig! |
| Spring Boot 4 Branches | 9 (alle aktiv) | Upgrade laeuft |
| Renovate-Branches | 95 (68 frisch) | Bot funktioniert |
| Aeltester Branch | 1114 Tage (portal-ui) | 3+ Jahre! |
| Entwickler | Branches | Services | Bemerkung |
|---|---|---|---|
| Leon Hoerpel | 25 | 9 Services | Breiteste Streuung, aber 71% Bug-Rate |
| Jonas Koehler | 13 | 4 Services | Vielseitig, 100% Done-Rate |
| Diego Da Costa Souza | 6 | Portal (UI + MW) | Spring Boot 4 Portal |
| Steven Meixner | 6 | 5 Services (Zero) | Allrounder, SPOF-Risiko |
| Bishara Jaser | 4 | Archivierung, SV | Leistungstraeger CIB |
| Saurav Kumar | 3 | IFP, PMW, SV | Spring Boot 4 SV |
| Service | Branch | Bearbeiter | Status |
|---|---|---|---|
| Portal (UI + MW) | renovate/spring-and-hibernate | Bot + Diego | ✅ Fertig |
| Steuerung Vertrieb | feat/O2CCIB-8031-springboot-4 | Saurav Kumar | 🟡 In Arbeit |
| Archivierungsservice | feat/O2CCIB-8031-springboot-4 | Hans-Henning Ramberger | 🟡 In Arbeit |
| IFP-Connector | feat/O2CCIB-8031-springboot-4 | (CIB) | 🟡 In Arbeit |
| AV-Trasse | test/O2CZERO-7043 | (Zero) | 🟡 Test-Phase |
portal-ui: 101 stale Branches — aeltester 1114 Tage (3 Jahre!). Empfehlung: Alle Branches >6 Monate loeschen.
246 stale Branches gesamt — erhoehen Merge-Konflikte. Regelmaessiges Cleanup empfohlen (monatlich Branches >90d pruefen).
Stand: $(Get-Date -Format 'yyyy-MM-dd') | 10 Kern-Services, Cross-Projekt-Analyse
| # | Rule | Beschreibung | Total | Hauptverursacher | Root Cause |
|---|---|---|---|---|---|
| 1 | S1192 | String-Duplikate (hardcoded statt Konstanten) | 1078 | SV (976!) | Fehlende String-Konstanten. Einfachster Quick-Win. |
| 2 | S100 | Methoden-Namenskonvention verletzt | 429 | SV (300), Camunda BW (90) | Vermutlich generierter Code (OpenAPI) oder Altlasten. |
| 3 | S1874 | Deprecated API Usage | 210 | SV (188), AV (22) | Veraltete APIs nach Framework-Upgrades nicht nachgezogen. |
| 4 | S1104 | Public Fields (statt private + Getter) | 168 | SV (61), Camunda BW (46), TADEF (33) | DTOs/Models ohne Encapsulation. Oft bei generierten Klassen. |
| 5 | S1118 | Utility Class ohne private Constructor | 99 | SV (56), verteilt | Einfacher Fix: Private Constructor hinzufuegen. |
| 6 | S1117 | Local Variable Shadows Field | 92 | SV (78) | Gleiche Variablennamen in Methode und Klasse. Bug-Risiko. |
| 7 | S115 | Constant Naming Convention | 76 | PMW (36), SV (35) | Namenskonventionen nicht eingehalten. Gleiche Root Cause. |
| 8 | S116 | Field Naming Convention | 67 | SV (58) | |
| 9 | S1135 | TODO/FIXME Kommentare | 61 | SV (46), AV (10) | Unerledigte technische Schuld im Code dokumentiert. |
| 10 | S3776 | Cognitive Complexity zu hoch | 55 | PMW (28), SV (21) | Methoden zu komplex. Wichtigster Wartbarkeits-Indikator! |
Steuerung Vertrieb dominiert: SV verursacht 976 von 1078 String-Duplikaten, 300 von 429 Namenskonventions-Verletzungen, 188 von 210 Deprecated-API-Nutzungen. Das ist der mit Abstand groesste Hebel fuer Verbesserung.
| Muster | Rules | Total | Empfehlung |
|---|---|---|---|
| String-Hygiene | S1192 | 1078 | Strings in Konstanten extrahieren. Kann teilweise automatisiert werden (IDE Refactoring). |
| Namenskonventionen | S100, S115, S116 | 572 | Pruefen ob generierter Code (OpenAPI) die Ursache ist. Falls ja: Generator-Config anpassen. Falls nein: Rename-Refactoring. |
| Deprecated APIs | S1874 | 210 | Nach Spring Boot 4 Upgrade systematisch deprecated Calls ersetzen. |
| Encapsulation | S1104, S1118 | 267 | Public Fields privatisieren, Utility-Constructors. Niedrighaengende Fruechte. |
| Komplexitaet | S3776 | 55 | Komplexe Methoden aufteilen. Hoechste Prioritaet fuer Wartbarkeit. PMW und SV. |
| Tech Debt Marker | S1135 | 61 | TODOs reviewen: Erledigen oder als Tickets erfassen und aus Code entfernen. |
| Rule | Count | Beschreibung |
|---|---|---|
| S1192 | 976 | String-Duplikate |
| S100 | 300 | Methoden-Namenskonvention |
| S1874 | 188 | Deprecated API |
| S3252 | 79 | Static member access via instance |
| S1117 | 78 | Variable shadows field |
| Rule | Count | Beschreibung |
|---|---|---|
| S1854 | 40 | Unused assignments |
| S1481 | 39 | Unused local variables |
| S115 | 36 | Constant naming |
| S3776 | 28 | Cognitive complexity |
| S6353 | 23 | Regex simplification |
| Rule | Count | Beschreibung |
|---|---|---|
| S4325 | 15 | Unnecessary type assertion (TS) |
| AvoidCommentedOutCode | 12 | Auskommentierter Code |
| S1135 | 12 | TODO comments |
| S1128 | 8 | Unused imports |
| S4623 | 7 | Undefined should not be passed as argument |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Quellen: Vorstudie (Kap. 3), Runbook (Kap. 6), TTSI Fachliche Dokumentation
| NEP1 Erstbestellung FCFS-Vorteil ✅ Abgeschlossen |
➔ | NEP2 Phase 2 Koordinierung ⚠ Aktuell |
➔ | VNP Vorlaeufiger Netzfahrplan |
➔ | ENP Endgueltiger Netzfahrplan |
➔ | GelV Gelegenheits- verkehr (24/7) ✅ Produktiv |
| Prozess | Beschreibung | pathOS-Rolle |
|---|---|---|
| LN34-01 Netzfahrplan | Jaehrliche Erstellung (NEP1, NEP2, VNP, ENP) | Anmeldung, Angebot, Vertrag |
| LN34-03 Gelegenheitsverkehr | Kurzfristige Bestellungen (48h bis 4 Wochen) | Vollstaendiger Bestellprozess |
| LN34-02 Rahmenvertrag | Mehrjaehrige Kapazitaet (auslaufend, letzte bis 2031) | Begrenzt (Verweis auf bestehende RV) |
| LN34-07 Kapazitaetsmanagement | Betriebsprogrammstudien | Nicht direkt in pathOS |
| # | Schritt | Akteur | System | Nachricht/Aktion | Details |
|---|---|---|---|---|---|
| 1 | Planung | EVU | Portal UI | Route, Stammdaten, Entwurf | Stammdaten aus SB, Karte aus GeoServer |
| 2 | Anmeldung | EVU | Portal/CI | PathRequestMessage | Train + PathRequest erstellen, Validierung in PMW |
| 3 | BEP-Pruefung | pathOS | SV → BEP | FahrlagePruefen (REST) | Automatische Plausibilitaetspruefung |
| 4 | Konstruktion | Fahrplan | SV → IFP → TPN/BaDiFa | Produktionsauftrag (Kafka) | Fahrplankonstruktion, kann Minuten bis Wochen dauern |
| 5 | Angebot | Fahrplan | TPN → IFP → SV | Vertriebsauftrag (Kafka) | PathDetailsMessage mit Laufweg |
| 6 | Preis | pathOS | SV → AC Trasse | ermittleTrassenPreis (REST) | Verbindliche Preisauskunft |
| 7 | Angebot pruefen | EVU | Portal/CI | PathDetailsMessage anzeigen | Laufweg, Verkehrstage, Preis |
| 8 | Annehmen | EVU | Portal/CI | Annahme | ProduktVertrag wird erstellt |
| 9 | Nachverarbeitung | pathOS | AV, AC, Archiv, VDV | Vertrag, Abrechnung, Archiv | Stationsportal, TBV, ggf. Abrechnung ueber VDV |
| Vorfall | Beschreibung | Besonderheit |
|---|---|---|
| Netzausgeloeste Aenderung (NAE) | DB InfraGO aendert/storniert Trassen (z.B. Bauarbeiten) | Ausgeloest durch Fahrplan, nicht EVU. Verzoegert. |
| Vertragsaenderung (VAEND) | Aenderungen nach Vertragsschluss (Zeit, Raum, Storno) | Erfordert neues Train-Objekt nach Vertragsschluss |
| ujBau | Bau-bezogene Trassenbestellungen | Bautrassen, GPE-Stellungnahmen, KOMBau-Plattform |
| Rahmenvertrag | Verweis auf bestehende RV bei NEP-Anmeldung | Auslaufend (letzte bis 2031), kein Neuabschluss |
| VERTRIEB (pathOS) | FAHRPLAN (TPN/BaDiFa) | BETRIEB (S2O) |
|---|---|---|
| Trassenanmeldung ➔ ➔ Konstruktionsergebnis Angebot an EVU Vertragsschluss ➔ Abrechnung (AC) Archivierung |
➔ Konstruktionsauftrag Konstruktionsergebnis ➔ ➔ Fahrplanveroeffentlichung |
➔ Betriebsplanung ➔ Betriebliche Meldungen |
| Thema | Status | Beschreibung |
|---|---|---|
| Buendelprodukte | Vision | Trasse + Anlage + Stationshalt + Energie in einem Bestellvorgang |
| Click&Ride Integration | ADR-72, in Arbeit | Vereinfachte GelV-Bestellung |
| TraPo-Anbindung | ADR-74, in Arbeit | Neues Trassenportal |
| VDV fuer Abrechnung | Strategisch | Vertragsdaten-Verteiler auch fuer AC Trasse |
| Rolling Planning | Langfristig | Nachfolger Rahmenvertraege (TTR-Projekt) |
Stand: 2026-04-24 | Quellen: PO-Input (CIB, Zero, 404), BO-Sicht, Technische Analyse, Jira
Diese Roadmap konsolidiert die Team-Roadmaps der POs mit der BO-Sicht und den technischen Findings. Sie ersetzt die rein technische Roadmap (Seite 16) durch eine ganzheitliche Produkt-Perspektive.
| Feld | Kernfrage | Massnahmen |
|---|---|---|
| Support-Enablement | Was braucht der Support, was muss er liefern? | Tools, Zugang, Wissen, SLAs, Eskalationswege |
| Monitoring | Was fehlt dem OPs Squad? | Grafana Boards, Alerting, Netcool |
| Axt schaerfen | Wie steigern wir Entwicklungseffizienz? | Smells reduzieren, Tests ausbauen, Pipelines beschleunigen |
| Feature-Enablement | Welche Features brauchen Support und Squad? | Vorpruefung, Fehlermeldungen, Suchfunktion |
| Organisatorische Regeln | Welche Regeln fuer Support und Squad? | Deployment-Verantwortung, Wissenstransfer |
| Fachlichkeits-Loop | Wie kommt Kundenfeedback schneller ins Produkt? | Feedback-Prozess, fachliches Verstaendnis aufbauen |
| Thema | Apr | Mai | Jun | Jul | Aug | Sep | Okt | Nov | Dez | Jan | Feb | Mar | Apr | Mai | Jun |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| STABILISIEREN (Hypercare beenden) | |||||||||||||||
| Spring Boot 4 | |||||||||||||||
| Monitoring + Alerting | |||||||||||||||
| Support-Enablement | |||||||||||||||
| Portal-Bugs (165) | |||||||||||||||
| HAERTEN (Qualitaet + Effizienz) | |||||||||||||||
| Vorpruefung Portal | |||||||||||||||
| Aenderungswesen final. | |||||||||||||||
| Fehlermeldungen-Konzept | |||||||||||||||
| Smells reduzieren (SV) | |||||||||||||||
| Tests ausbauen | |||||||||||||||
| RV aufraeumen | |||||||||||||||
| ERWEITERN (Kundenmehrwert) | |||||||||||||||
| Uebersichtsseite Vorg. | |||||||||||||||
| Expertenmodus | |||||||||||||||
| Massenkopie Takt | |||||||||||||||
| E-Mail Benachrichtig. | |||||||||||||||
| Suchfunktion | |||||||||||||||
| Click&Ride | |||||||||||||||
| RouteUpdate-Prozess | |||||||||||||||
| WEITERENTWICKELN (Langfristig) | |||||||||||||||
| Entkopplung Zuglaufp. | |||||||||||||||
| Ersatz Msg Routing ID | |||||||||||||||
| LuP neu | |||||||||||||||
| Team-Reorganisation | |||||||||||||||
Kritisch Kurzfristig Mittelfristig Langfristig
Hypercare beenden, Monitoring aufbauen, Support enablen.
| Thema | Team | Details |
|---|---|---|
| Spring Boot 4 abschliessen | Alle | Portal fertig, CI/SV/AV in Arbeit. EOL 3.5: Juni 2026. |
| Monitoring + Alerting | OPs, Zero | Grafana Boards nutzbar machen, Netcool, Logs anpassen. Kein Dauerzustand. |
| Support-Enablement | BSSUPPORT, OPs | Was braucht Support? Tools, Zugang, Wissen, SLAs, Eskalationswege definieren. |
| Portal-Bugs reduzieren | 404 | 165 Bugs, 33% Bug-Rate. Stabilisierung vor neuen Features. |
| Workarounds TTK aufraeumen | Zero | Technische Schuld aus Go-Live Phase. |
| Verschluesselung einschalten | Zero | Security-Anforderung. |
Qualitaet steigern, Entwicklungseffizienz erhoehen, "Axt schaerfen".
| Thema | Team | Details |
|---|---|---|
| Vorpruefung Portal | CIB, 404 | Button "Vorpruefung": PMW+SV+BEP Validierung vor Absenden. Hohe Kundenwirkung. |
| Aenderungswesen finalisieren | CIB | Parallele Aenderungsbestellungen validieren. Mit Fahrplan abgestimmt. |
| Fehlermeldungen-Konzept | 404 | Verstaendliche, benutzerfreundliche Meldungen. Reduziert Support-Aufwand. |
| Smells reduzieren (SV) | CIB | 2214 Code Smells, 976 String-Duplikate. IDE-Refactoring. |
| Automatisierte Tests ausbauen | 404, alle | Deutlich erweitern. Testumgebung mit TPN dauerhaft bereitstellen. |
| Rahmenvertraege aufraeumen | CIB | Prozesse/Tests ausbauen. Reduziert Pipeline-Laufzeiten. |
| Camunda 8.9 | CIB | Nach 8.8 ist vor 8.9. Support-Zeitraeume beachten. |
| Performance AV | Zero | Full-Table-Scans, Optimierung. |
Kundenmehrwert liefern, nachgelieferte Features umsetzen.
| Thema | Team | Details |
|---|---|---|
| Uebersichtsseite Vorgaenge | 404 | Zusammengehoerige Vorgaenge gruppiert nach RouteID. |
| Expertenmodus | 404 | Kompakte Maske fuer erfahrene Nutzer. |
| Massenkopie Taktbestellungen | 404 | Mehrere Takte per Massenkopierfunktion. |
| E-Mail Benachrichtigungen | 404 | Bei NAE oder Angebotseingang. |
| Suchfunktion | 404 | Leistungsfaehige Suche integrieren. |
| Click&Ride Anbindung | CIB, Zero | ADR-72. SUBP arbeitet bereits an Teilen. |
| RouteUpdate-Prozess | CIB | Nach Go-Live verschoben. Gross. |
| §22 ERegG | CIB | Eintritt Drittunternehmen. |
| Stationsportal fertigstellen | Zero | Anbindung abschliessen. |
| PCS aufraeumen + Rueckweg | Zero | Gross. |
Strategische Themen, grosse Umbauten.
| Thema | Team | Details |
|---|---|---|
| Entkopplung Zuglaufpunkte/Zugcharakteristik | 404 | Vererbungslogik entfernen. Gross. |
| Ersatz Message Routing ID | Zero | SenderReference, iRFP. Gross. |
| LuP neu | Zero | Komplett neu. Gross. |
| XSD 3.5.2 | Zero | Kann gross werden. |
| TDM aufraeumen | Zero | Technische Schuld. |
| Team-Reorganisation | PM/RTE | Subdomaenen-Schnitt, Platform Team. |
| Abrechnung klaeren | CIB | VDV-Erweiterung oder andere Loesung. Unklar. |
| Thema | Team |
|---|---|
| Bug Fix + Support | Alle |
| Lieferungen testen, bauen, dokumentieren | Alle |
| Framework-Updates (Camunda, Spring, Angular) | Alle |
| Neue Mitarbeiter aufgleisen | Alle |
| Fachlichkeits-Loop: Kundenfeedback schneller ins Produkt | 404, CIB, FbF |
Stand: 2026-04-30 | Quellen: Jira (90d + 12M), Rollen-Mapping (BO-Input), Tenure-Daten (176 Personen, 24.7K Issues)
Diese Analyse korreliert Personaldaten (Rollen, Tenure, Aktivitaet) mit Bug-Raten und Qualitaetskennzahlen pro Team und Entwickler.
| Team | Personen | Kern-Devs | Bug-Rate (90d) | Bug-Rate (12M) | Trend | Bewertung |
|---|---|---|---|---|---|---|
| Team 404 | 10 | 7 | 33% | 25% | ↑ Steigend | KRITISCH |
| Team CIB | 13 | 6 | 20% | 23% | ↓ Sinkend | GUT |
| Team Zero | 9 | 6 | 15% | 15% | → Stabil | GUT |
| OPs Squad | 7+ rot. | 2 fest | 31% | 27% | ↓ Sinkend | BEOBACHTEN |
| DevOps | 7 | 3 | 9% | 7% | → Stabil | OK (SPOF) |
Hoechste Bug-Rate (33%), steigend seit Go-Live. Portal ist kundenseitig — Bugs werden direkt von EVUs gemeldet.
| Person | Rolle | Seit | Issues (90d) | Bug-Anteil | Done% | Bewertung |
|---|---|---|---|---|---|---|
| Ana Cvitkovic | Business Engineer | 2021-08 | 78 | niedrig | hoch | TOP — Anker des Teams |
| Jasmin Keskin | Frontend Dev | 2021-08 | 45 | 42% | mittel | Bug-anfaellig |
| Emmanuel Kontcheu Tagne | Frontend Dev | 2021-08 | 42 | 69% | mittel | KRITISCH |
| Diego Da Costa Souza | Frontend Dev | 2021-09 | 41 | mittel | mittel | Spring Boot 4 Portal |
| Leon Hoerpel | Dev | 2023-03 | 35 | 71% | mittel | KRITISCH |
| Dominik Ruecker | Backend Dev | 2021-08 | 31 | mittel | mittel | Veteran (434 Issues) |
| Annette Halbhuber | Lead Dev | 2021-09 | 26 | niedrig | hoch | Stabil, Lead |
| Simon Reitinger | Dev | 2025-11 | 15 | 0% | 100% | Exzellenter Start |
| Marcel Hufgard | PO | 2021-12 | 8 | — | — | Product Owner |
| Luca Caracciolo | QA | 2021-09 | 5 | — | — | Wenig aktiv |
Kernproblem: Emmanuel (69% Bugs) und Leon (71% Bugs) arbeiten beide im Frontend. Das Portal-Frontend hat ein systematisches Qualitaetsproblem. QA (Luca) ist wenig aktiv — Testabdeckung unzureichend.
Bug-Rate von 36% (Jan) auf 9% (Apr) gesunken. Backend stabilisiert sich nach Go-Live.
| Person | Rolle | Seit | Issues (90d) | Bug-Anteil | Done% | Bewertung |
|---|---|---|---|---|---|---|
| Bishara Jaser | Dev | 2022-08 | 73 | niedrig | 93% | TOP — Leistungstraeger |
| Saurav Kumar | Dev | 2022-01 | 48 | 8% | 94% | TOP — niedrigste Bug-Rate |
| Jonas Koehler | Dev | 2024-04 | 34 | niedrig | 100% | Exzellent |
| Dong-Won Han | Dev | 2021-09 | 20 | mittel | mittel | Veteran |
| Hans-Henning Ramberger | Dev | 2024-05 | 16 | mittel | mittel | Auch OPs |
| Vasileios Dimitriadis | Dev | 2023-11 | 11 | mittel | mittel | Wenig aktiv |
| Christian Meins | PO | 2021-10 | 9 | — | — | Product Owner |
| Harry Braun | Dev | 2025-12 | 5 | mittel | mittel | SB4 SV |
| Olaf Becken | Business Engineer | 2024-05 | 5 | — | — | |
| Alexander Petioky | Dev | 2021-10 | 1 | — | — | Kaum aktiv |
Kern-Trio: Bishara + Saurav + Jonas (155 Issues, >93% Done). Deren Arbeitsweise sollte als Vorbild fuer andere Teams dienen.
Niedrigste Bug-Rate (15%), stabiler Output. Beste SonarQube-Qualitaet (4.2 Smells/1K, 91.8% Coverage).
| Person | Rolle | Seit | Issues (90d) | Bug-Anteil | Bewertung |
|---|---|---|---|---|---|
| Steven Meixner | Dev | 2022-07 | 64 + 27 OPs | niedrig | TOP — Allrounder (SPOF!) |
| Bing Shi | Dev | 2022-04 | 63 | niedrig | Stark |
| Frank Lemke | Dev | 2022-12 | 49 | niedrig | Auch OPs |
| Kathrin Schleich | Dev | 2021-09 | 27 | niedrig | Auch OPs |
| Michael Weisberg | Test | 2024-11 | 23 | — | 52% offen |
| Bernd Klebl | PO | 2021-09 | 16 | — | Auch OPs |
| Norbert Maurer | Dev | 2021-11 | 12 | — | 83% offen — ausgeschieden? |
Jan Lubenow = 39% aller DevOps-Issues — kritischster Single Point of Failure im gesamten Programm.
| Person | Rolle | Seit | Issues (90d) | Anteil |
|---|---|---|---|---|
| Jan Lubenow | Lead Dev | 2022-09 | 114 | 39% |
| David Steinkopff | Dev | 2023-03 | 18 | 6% |
| Henrik Scholl | Dev | 2024-10 | 10 | 3% |
| Christian Prause | Dev | 2025-08 | 7 | 2% |
| Patrick Lewandowski | Dev | 2025-07 | 6 | 2% |
| Michael Mh Jahn | Dev | 2022-01 | 6 | 2% |
| Sebastian Goendoer | Dev | 2023-05 | 3 | 1% |
| Team | Hypothese: Laenger dabei = weniger Bugs? | Ergebnis |
|---|---|---|
| Team 404 | Emmanuel (56 Mon., 69% Bugs), Leon (37 Mon., 71%), Simon (5 Mon., 0%) | WIDERLEGT — Systematisches Problem |
| Team CIB | Saurav (51 Monate, 8% Bugs), Bishara (44 Monate, niedrig) | BESTAETIGT — Erfahrung + gute Prozesse |
| Team Zero | Alle Veteranen niedrige Bug-Rate, beste SonarQube-Werte | BESTAETIGT — Stabiles Team + Praktiken |
Fazit: Tenure allein erklaert die Bug-Rate nicht. Team 404 hat ein systematisches Frontend-Qualitaetsproblem, das nicht durch Erfahrung geloest wird. CIB und Zero zeigen, dass gute Prozesse + Erfahrung zusammen wirken.
Die Bug-Raten in den Team-Tabellen basieren auf dem Anteil der Bug-Tickets an den zugewiesenen Issues einer Person (90 Tage). Separate Causation-CSVs verwenden eine Korrelationsmethodik (14-Tage-Fenster), die Raten >100% erzeugt und nur als relative Gewichtung innerhalb eines Teams nuetzlich ist.
| Risiko | Person(en) | Impact | Massnahme |
|---|---|---|---|
| SPOF DevOps | Jan Lubenow (39%) | Deployment, CI/CD, Infra | Wissenstransfer, Dokumentation |
| SPOF Zero/OPs | Steven Meixner (91 Issues) | TAF/TAP + Infrastruktur | Entlastung, Backup aufbauen |
| Bug-Verursacher 404 | Emmanuel (69%), Leon (71%) | Portal-Qualitaet | Code-Reviews, Pair Programming |
| Risiko | Person(en) | Impact | Massnahme |
|---|---|---|---|
| QA-Engpass 404 | Luca Caracciolo (5 Issues) | Testabdeckung Portal | Aktivieren oder ersetzen |
| Test-Backlog Zero | Michael Weisberg (52% offen) | Testabdeckung TAF/TAP | Priorisierung |
| Inaktive Mitglieder | Norbert Maurer, Alexander Petioky | Offene Issues, Wissen | Status klaeren |
Stand: $(Get-Date -Format 'yyyy-MM-dd') | Quelle: Jira (Labels TopThema, Konzernreporting, Taskforce-FplW, TTT_Kunde)
Diese Seite zeigt geschaeftskritische Risiken die ueber rein technische Probleme hinausgehen: Kundenversprechen, regulatorische Anforderungen, Eskalationen, Abrechnungsrisiken. Wird woechentlich aktualisiert.
| # | Ticket | Thema | Status | Impact / Risiko |
|---|---|---|---|---|
| 1 | TTTSOL-2184 O2CCIB-6931 | Implizite Annahme NAÄ | Highest Umsetzung geschoben | Kundenversprechen gebrochen. EVUs erleben nicht den Standard-Prozess. Fernverkehr + Regio betroffen. |
| 2 | TTTSOL-1677 TTTSOL-2149 | 20h Zug — Abrechnung | High BLOCKED | Loesung funktioniert nicht. Korrekte Abrechnung nicht moeglich. Cargo betroffen. |
| 3 | TTTSOL-2186 | DB Cargo Eskalation CIO Board | Highest In Bearbeitung | PCS + gestaffelter VNP-Versand. Eskaliert bis CIO-Ebene. Konzernreporting. |
| 4 | TTTSOL-2035 TTTSOL-2147 TTTSOL-2148 | Abrechnung TTT / AC Trasse | Highest (3x) Taskforce aktiv | 41 offene Tickets, 8 Highest. Grundlegendes Risiko: Nicht korrekt abrechnen zu koennen. |
| 5 | TTTSOL-1956 | Vertragskorrektur in die Vergangenheit | Highest In Bearbeitung | Rueckwirkende Korrekturen = Abrechnungsrisiko. Konzernreporting. |
| # | Ticket | Thema | Status | Impact / Risiko |
|---|---|---|---|---|
| 6 | TTTSOL-1900 TTTSOL-2185 | Mittiger Teilausfall (SEV) | Highest Taskforce | Fernverkehr: Kein Workaround fuer SEV-Faelle. Betrieb + E2E-Test betroffen. |
| 7 | TTTSOL-1819 | Ad-hoc Verkehre <1h (FV) | BLOCKED TopThema | Fernverkehr kann kurzfristige Zuege nicht bestellen. Konzernreporting. |
| 8 | TTTSOL-1853 | Teilstorno in LeiDaF | Highest Taskforce | Stornierungen werden nicht verarbeitet. Fahrplanwechsel betroffen. |
| 9 | TTTSOL-1683 | OTN-Vergabe Fpl 2027 | Highest Taskforce | Fahrplan 2027 betroffen. Muss vor Fahrplanwechsel geloest sein. |
| 10 | TTTSOL-1707 | Nachtsprung auf Fremd-EIU | Highest In Bearbeitung | Sonderfall innerdeutsch. Handover-Problem. |
| 11 | TTTSOL-433 | TrainID mit anderer Trasse verknuepfen | High TopThema | Alternativangebote. Konzernreporting + Kundenkommunikation. |
| # | Ticket | Thema | Status | Impact / Risiko |
|---|---|---|---|---|
| 12 | TTTI-7811 | KV-Profile loeschen nicht moeglich | Zeitkritisch | TPN-Import betroffen. Kunde gemeldet. |
| 13 | TTTI-8171 | PROD Operate-Incident ConstraintViolation | High, Offen | Produktions-Incident. Kunde betroffen. |
| 14 | TTTI-7751 | IFP-Connector: value too long | High, In Bearbeitung | Datenintegritaet. Kunde gemeldet. |
| 15 | TTTSOL-2043 | OIM-Aktualisierung nicht unterstuetzt | High, Review | DB Cargo + Kundenkommunikation. InfraGO-Entscheidung. |
| Metrik | Wert | Trend |
|---|---|---|
| TopThema (offen) | 3 | → Stabil |
| Konzernreporting (offen) | 26 | → |
| Taskforce-FplW (offen) | 15 | → |
| TTT_Kunde (offen) | 65 | → |
| Blocked + High/Highest | 38 | → |
| TTT_offenePunkte + Highest | 13 | → |
| TTT_MUSS (offen) | 196 | → |
Geschaeftskritische Risiken werden ueber folgende Jira-Signale identifiziert:
Script: jira-critical-scan.py — wird woechentlich ausgefuehrt.
Business Owner: Andre Knie | Start: 2026-04-22 | Stand: $(Get-Date -Format 'yyyy-MM-dd')
Systematische Analyse der pathOS-Plattform (167 GitLab-Projekte, 24.700 Jira-Issues, 187 Confluence-Seiten, SonarQube, Runbook). pathOS ist seit Dezember 2025 produktiv (Go/No-Go Sep 2025 positiv). Aktuell: Verlaengerte Hypercare + NEP2 + Spring Boot 4 Upgrade.
| Risiko | Ticket | Status | Impact |
|---|---|---|---|
| Implizite Annahme NAÄ | TTTSOL-2184 / O2CCIB-6931 | Fachlich Highest, Umsetzung auf naechsten PI geschoben | Kundenversprechen nicht eingehalten. EVUs erleben nicht den Standard-Prozess. |
| 20h Zug — Abrechnung | TTTSOL-1677 / TTTSOL-2149 | TTTSOL-2149 BLOCKED | Loesung funktioniert nicht. Korrekte Abrechnung nicht moeglich. |
| Abrechnung TTT / AC Trasse | 41 offene Tickets (8 Highest) | Taskforce aktiv | Grundlegendes Risiko: Nicht korrekt abrechnen zu koennen. |
|
Kompakte Zusammenfassung: Status, Findings, Herausforderungen, naechste Schritte. Fuer Management Board. |
Priorisierte Aktionen und Zeitplaene bis Mitte 2027. |
| Bereich | Inhalt |
|---|---|
| Architektur, Komponenten, Customer Journey, GitLab-Landschaft, Glossar | |
| Versionen, SonarQube (Coverage vs. Bug-Rate), Branch-Analyse, Technische Roadmap | |
| Team-Struktur, 12-Monats-Velocity, Personal-Analyse (176 Personen), Risiko-Matrix | |
| TAF/TAP TSI Kontext, NEP2, TTTI-Integration, Geschaeftskritische Risiken | |
| Aktionsplan (24 Massnahmen), Produkt-Roadmap, Audit-Backlog |
| Datum | Was |
|---|---|
| 30.04.2026 | Geschaeftskritische Risiken (NAÄ, 20h Zug, Abrechnung) aufgenommen |
| 30.04.2026 | Branch-Analyse (452 Branches, 13 Services, Spring Boot 4 Status) |
| 30.04.2026 | SonarQube Deep Dive: Coverage erklaert Bug-Rate nicht |
| 30.04.2026 | Personal-Analyse: Tenure vollstaendig (176 Personen) |
| 27.04.2026 | Knowledge Graph + Skills aufgesetzt |
| 24.04.2026 | SonarQube, Geschaeftsprozesse, Produkt-Roadmap |
| 23.04.2026 | TTT-Programm, TTTI, Velocity 12M, Team-Personenanalyse |
| 22.04.2026 | Domain Discovery, Tech Deep Dive, Team-Analyse, Roadmap |