Migrate all repos into monorepo context folders
Bahn: aisupport, Analyse-O2C-C2S, awesome-bahn-mcp-servers, beam-mcp,
Confluence_Bot, db-planet-mcp-server, O2C-Harness, project-audit,
Projekt-KIQ-HP, teamlandkarte-mcp
Dhive: Jury-Voting
Privat: CV, NoteGraph (NOTE: NoteGraph needs complete redo after consolidation)
Shared: AI-Orchestrator, OrgMyLife, power_skills_and_more
Shared/references: symphony (read-only)
Bahn repos remain available as independent remotes - this monorepo
pulls them in via subtree, the originals are untouched.
This commit is contained in:
@@ -0,0 +1,28 @@
|
||||
# Analysen - Uebersicht
|
||||
|
||||
> Alle Analyse-Dokumente des pathOS Portfolio-Audits
|
||||
|
||||
## Aktuelle Analysen
|
||||
|
||||
| Datei | Thema | Aktuell? |
|
||||
|-------|-------|----------|
|
||||
| strategische-notizen.md | VDV-Erweiterung Abrechnung, NEP2 Status | Ja |
|
||||
| velocity-12m-analyse.md | 12-Monats-Velocity alle Teams | Ja |
|
||||
| jira-teams-deepdive.md | Team-Boards, Assignees, Personenanalyse | Ja |
|
||||
| jira-boards-fachlich-ttti.md | TTTSol + TTTI Deep Dive | Ja |
|
||||
| ttsi-programm-analyse.md | TTT-Programm, Go/No-Go, Risiken | Ja (Go-Live korrigiert) |
|
||||
| roadmap-uebergreifend-und-pathos.md | Roadmap Apr 2026 - Mitte 2027 | Ja |
|
||||
| runbook-analyse.md | arc42 Runbook Zusammenfassung | Ja |
|
||||
|
||||
## Aeltere Analysen (in aktuelle integriert)
|
||||
|
||||
| Datei | Thema | Hinweis |
|
||||
|-------|-------|---------|
|
||||
| iteration-01-gesamtbild.md | Erstes Gesamtbild Tag 1 | Integriert in Confluence Seiten 1-5 |
|
||||
| iteration-01-gitlab-erstanalyse.md | GitLab Erstanalyse | Integriert in Confluence Seite 4 |
|
||||
| iteration-02-technical-deepdive.md | pom.xml Analyse | Integriert in Confluence Seite 10 |
|
||||
| iteration-03-team-workflow.md | Team-Mapping | Integriert in Confluence Seite 11 |
|
||||
| iteration-04-roadmap-aktionsplan.md | Erster Aktionsplan | Integriert in Confluence Seite 12 |
|
||||
| architektur-diagramme.md | Mermaid-Diagramme | Integriert in Confluence Seite 6 |
|
||||
| velocity-analyse.md | 90-Tage Velocity (ersetzt durch 12m) | Ersetzt durch velocity-12m-analyse.md |
|
||||
| jira-analyse-zusammenfassung.md | ART-Board Analyse | Integriert in Confluence Seite 13 |
|
||||
@@ -0,0 +1,256 @@
|
||||
# Architektur-Diagramme pathOS
|
||||
|
||||
> Stand: 2026-04-22 | Basis: GitLab-Inventar + Confluence-Analyse
|
||||
|
||||
---
|
||||
|
||||
## 1. Systemkontext (C4 Level 1)
|
||||
|
||||
Zeigt pathOS im Kontext seiner Nutzer und externen Systeme.
|
||||
|
||||
```mermaid
|
||||
C4Context
|
||||
title pathOS - Systemkontext
|
||||
|
||||
Person(evu, "EVU-Sachbearbeiter", "Bestellt Trassen ueber Web-Portal oder API")
|
||||
Person(kb, "DB Kundenbetreuer", "Bearbeitet Bestellungen im Auftrag von EVU")
|
||||
Person(fbf, "Fachliche Betriebsfuehrung", "Konfiguration und Monitoring")
|
||||
Person(at, "Aufgabentraeger", "Lesender Zugriff auf Bestellungen")
|
||||
|
||||
System(pathos, "pathOS", "Plattform zur Trassenbestellung")
|
||||
|
||||
System_Ext(tpn, "TPN", "Trassenportal Netz (Altsystem)")
|
||||
System_Ext(badifa, "BaDiFa", "Fahrplankonstruktion & Kapazitaetsmanagement")
|
||||
System_Ext(ac, "AC Trasse", "AbrechnungsCockpit: Preise, Abrechnung, Belege")
|
||||
System_Ext(im, "Infrastruktur-Manager (M15)", "Stammdaten: Betriebsstellen, Strecken, Tfz")
|
||||
System_Ext(kdv, "KDV", "Kundendatenverwaltung (CRM)")
|
||||
System_Ext(nur, "NuR / eBRS-AD", "Nutzer- und Rechteverwaltung")
|
||||
System_Ext(rne, "RNE / CRD", "Europaeische Referenzdaten")
|
||||
System_Ext(geo, "GeoServer", "Kartendarstellung")
|
||||
System_Ext(nemo, "Netzmonitor / SAPBINe", "Auftragsdaten-Konsument")
|
||||
System_Ext(cr, "Click&Ride", "Vereinfachte Bestellung")
|
||||
System_Ext(sp, "Stationsportal", "Vertragsdaten-Konsument")
|
||||
|
||||
Rel(evu, pathos, "Bestellt Trassen", "HTTPS / TAF-TAP TSI")
|
||||
Rel(kb, pathos, "Bearbeitet Bestellungen", "HTTPS")
|
||||
Rel(fbf, pathos, "Konfiguriert", "HTTPS")
|
||||
Rel(at, pathos, "Liest Bestellungen", "HTTPS")
|
||||
|
||||
Rel(pathos, tpn, "Datensynchronisation", "Kafka / API")
|
||||
Rel(pathos, badifa, "Fahrplanauftraege", "API")
|
||||
Rel(pathos, ac, "Preisanfragen, Abrechnung", "API")
|
||||
Rel(pathos, im, "Stammdaten", "API")
|
||||
Rel(pathos, kdv, "Kundendaten", "API")
|
||||
Rel(pathos, nur, "Authentifizierung", "OIDC / API")
|
||||
Rel(pathos, rne, "Referenzdaten", "Internet / API")
|
||||
Rel(pathos, geo, "Karten / Routen", "WMS / WFS")
|
||||
Rel(pathos, nemo, "Auftragsdaten", "API")
|
||||
Rel(pathos, cr, "Bestellungen", "API")
|
||||
Rel(pathos, sp, "Vertragsdaten", "API")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 2. Container-Diagramm (C4 Level 2)
|
||||
|
||||
Zeigt die internen Komponenten von pathOS.
|
||||
|
||||
```mermaid
|
||||
C4Container
|
||||
title pathOS - Container-Diagramm
|
||||
|
||||
Person(user, "EVU / Kundenbetreuer")
|
||||
|
||||
Container_Boundary(pathos, "pathOS") {
|
||||
Container(ui, "Portal UI", "TypeScript, Angular", "Benutzeroberflaeche fuer Trassenbestellung")
|
||||
Container(pmw, "Portal Middleware", "Java, Spring Boot", "Backend fuer Portal UI, API-Gateway")
|
||||
Container(sv, "Steuerung Vertrieb", "Java, Camunda 8", "Workflow-Engine: Orchestriert den Bestellprozess")
|
||||
Container(avt, "Auftrags-Verwaltung Trasse", "Java, Spring Boot", "CRUD fuer Trassenbestellungen und Auftraege")
|
||||
Container(as, "Auftrag-Service", "Java, Spring Boot", "Auftragsverarbeitung und Kafka-Events")
|
||||
Container(ci, "Common Interface", "Java, Spring Boot", "TAF/TAP TSI Schnittstelle fuer EVU-Systeme")
|
||||
Container(ifp, "IFP-Connector", "Java, Spring Boot", "Anbindung Integrierte Fahrplanbearbeitung")
|
||||
Container(tadef, "TADEF-Connector", "Java, Spring Boot", "TAF/TAP Definition Connector")
|
||||
Container(kdb, "Kundendaten-Bereitstellung", "Java, Spring Boot", "Adapter fuer Kundendaten")
|
||||
Container(sdb, "Stammdaten-Bereitstellung", "Java, Spring Boot", "Adapter fuer Stammdaten")
|
||||
Container(rnb, "Rabattnummern-Bereitstellung", "Java, Spring Boot", "Rabattnummern-Service")
|
||||
Container(vdv, "Vertragsdaten-Verteiler", "Java, Spring Boot", "Verteilt Vertragsdaten an Drittsysteme")
|
||||
Container(arch, "Archivierungsservice", "Java, Spring Boot", "Archiviert Nachrichten und Prozessdaten")
|
||||
Container(tbv, "TBV-Absicherung-Konverter", "Java, Spring Boot", "Tunnelbegegnungsverbot-Pruefung")
|
||||
Container(ttk, "TAF/TAP-TDM-Konverter", "Java, Spring Boot", "Konvertiert zwischen TDM und TAF/TAP")
|
||||
Container(kc, "Keycloak", "Keycloak", "Identity & Access Management")
|
||||
ContainerDb(db, "PostgreSQL", "PostgreSQL", "Auftrags- und Stammdaten")
|
||||
ContainerQueue(kafka, "Apache Kafka", "AWS MSK", "Event-Streaming zwischen Services")
|
||||
}
|
||||
|
||||
Rel(user, ui, "HTTPS")
|
||||
Rel(ui, pmw, "REST API")
|
||||
Rel(pmw, sv, "REST / Kafka")
|
||||
Rel(sv, avt, "REST / Kafka")
|
||||
Rel(sv, ci, "REST / Kafka")
|
||||
Rel(sv, as, "Kafka")
|
||||
Rel(avt, db, "JDBC")
|
||||
Rel(as, kafka, "Produce/Consume")
|
||||
Rel(ci, kafka, "Produce/Consume")
|
||||
Rel(arch, kafka, "Consume")
|
||||
Rel(kdb, kafka, "Produce")
|
||||
Rel(sdb, kafka, "Produce")
|
||||
Rel(user, kc, "OIDC Login")
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. Deployment-Diagramm
|
||||
|
||||
```mermaid
|
||||
C4Deployment
|
||||
title pathOS - Deployment (AWS EKS)
|
||||
|
||||
Deployment_Node(aws, "AWS Cloud") {
|
||||
Deployment_Node(eks, "EKS Kubernetes Cluster") {
|
||||
Deployment_Node(ns_app, "Namespace: pathOS-Apps") {
|
||||
Container(c_ui, "portal-ui", "Container")
|
||||
Container(c_pmw, "portal-middleware", "Container")
|
||||
Container(c_sv, "steuerung-vertrieb", "Container")
|
||||
Container(c_avt, "auftrags-verwaltung-trasse", "Container")
|
||||
Container(c_as, "auftrag-service", "Container")
|
||||
Container(c_ci, "common-interface", "Container")
|
||||
Container(c_ifp, "ifp-connector", "Container")
|
||||
Container(c_kdb, "kundendaten-bereitstellung", "Container")
|
||||
Container(c_sdb, "stammdaten-bereitstellung", "Container")
|
||||
Container(c_vdv, "vertragsdaten-verteiler", "Container")
|
||||
Container(c_arch, "archivierungsservice", "Container")
|
||||
Container(c_tbv, "tbv-absicherung-konverter", "Container")
|
||||
Container(c_ttk, "taftap-tdm-konverter", "Container")
|
||||
Container(c_rnb, "rabattnummern-bereitstellung", "Container")
|
||||
Container(c_tadef, "tadef-connector", "Container")
|
||||
}
|
||||
Deployment_Node(ns_infra, "Namespace: pathOS-Infra") {
|
||||
Container(c_kc, "Keycloak", "Container")
|
||||
Container(c_cam, "Camunda 8", "Container")
|
||||
}
|
||||
}
|
||||
Deployment_Node(rds, "AWS RDS") {
|
||||
ContainerDb(c_db, "PostgreSQL", "Managed DB")
|
||||
}
|
||||
Deployment_Node(msk, "AWS MSK") {
|
||||
ContainerQueue(c_kafka, "Apache Kafka", "Managed Kafka")
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. Datenfluss: Trassenbestellung (vereinfacht)
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant EVU as EVU-Kunde
|
||||
participant UI as Portal UI
|
||||
participant PMW as Portal Middleware
|
||||
participant SV as Steuerung Vertrieb
|
||||
participant AVT as Auftrags-Verwaltung
|
||||
participant CI as Common Interface
|
||||
participant BEP as BEP (KonBel-K)
|
||||
participant BaDiFa as BaDiFa
|
||||
participant AC as AC Trasse
|
||||
|
||||
EVU->>UI: Trassenanmeldung erstellen
|
||||
UI->>PMW: POST /anmeldung
|
||||
PMW->>SV: Starte Bestellprozess
|
||||
SV->>AVT: Erstelle Train + PathRequest
|
||||
AVT-->>SV: Auftrag erstellt
|
||||
|
||||
SV->>CI: Sende PathRequestMessage
|
||||
CI->>BEP: FahrlagePruefen
|
||||
BEP-->>CI: Pruefergebnis
|
||||
|
||||
SV->>BaDiFa: erteileFahrplanKonstruktionsAuftrag
|
||||
BaDiFa-->>SV: PathDetailsMessage (Path-Objekt)
|
||||
|
||||
SV->>AC: ermittleTrassenPreis
|
||||
AC-->>SV: Preisinformation
|
||||
|
||||
SV->>AVT: Erstelle VertragsAngebot
|
||||
SV->>PMW: Angebot bereit
|
||||
PMW->>UI: Zeige Angebot
|
||||
UI->>EVU: Angebot zur Pruefung
|
||||
|
||||
EVU->>UI: Angebot annehmen
|
||||
UI->>PMW: Annahme
|
||||
PMW->>SV: Vertragsschluss
|
||||
SV->>AVT: Erstelle ProduktVertrag
|
||||
SV->>AC: abrechneVertragsAenderung
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. Projektstruktur-Uebersicht (vereinfacht)
|
||||
|
||||
```mermaid
|
||||
mindmap
|
||||
root((pathOS))
|
||||
APIs (37)
|
||||
Trassenanmeldung
|
||||
Auftraege
|
||||
Stammdaten
|
||||
Kundendaten
|
||||
Abrechnung
|
||||
TAF/TAP
|
||||
Portal
|
||||
Apps (19)
|
||||
Portal UI
|
||||
Portal Middleware
|
||||
Steuerung Vertrieb
|
||||
Auftrags-Verwaltung
|
||||
Common Interface
|
||||
Connectors
|
||||
Infra (47)
|
||||
Helm Charts
|
||||
Keycloak 5+
|
||||
CI/CD Pipelines
|
||||
Monitoring
|
||||
Deployment
|
||||
Database Setup
|
||||
Libraries (7)
|
||||
Core Components
|
||||
Logging
|
||||
Signatures
|
||||
Mocks (11)
|
||||
IFP Mock
|
||||
IM Mock
|
||||
KDV Mock
|
||||
BEP Mock
|
||||
QA (15)
|
||||
System Tests
|
||||
Integration Tests
|
||||
Performance Tests
|
||||
Security Scans
|
||||
Tools (10)
|
||||
Camunda Client
|
||||
Kafka Replay
|
||||
Migration Tools
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. Problemzonen-Heatmap
|
||||
|
||||
```mermaid
|
||||
quadrantChart
|
||||
title Problemzonen: Aufwand vs. Kritikalitaet
|
||||
x-axis "Geringer Aufwand" --> "Hoher Aufwand"
|
||||
y-axis "Geringe Kritikalitaet" --> "Hohe Kritikalitaet"
|
||||
|
||||
"Spring Boot 4 Upgrade": [0.6, 0.95]
|
||||
"Deployment-Vereinfachung": [0.85, 0.9]
|
||||
"Secret-Rotation": [0.5, 0.85]
|
||||
"AppMesh-Abloesung": [0.7, 0.8]
|
||||
"Monitoring-Konzept": [0.6, 0.8]
|
||||
"Disaster Recovery": [0.75, 0.85]
|
||||
"DB Full-Table-Scans": [0.4, 0.7]
|
||||
"Repo-Beschreibungen": [0.15, 0.3]
|
||||
"Archivierte Repos aufraeumen": [0.1, 0.15]
|
||||
"Keycloak-Konsolidierung": [0.5, 0.4]
|
||||
"API-Versionierung": [0.6, 0.5]
|
||||
"GitLab-Restrukturierung": [0.65, 0.35]
|
||||
```
|
||||
@@ -0,0 +1,149 @@
|
||||
# Geschaeftsprozesse pathOS
|
||||
|
||||
> Stand: 2026-04-24 | Quellen: Vorstudie (Kap. 3), Runbook (Kap. 6), TTSI Fachliche Dokumentation
|
||||
|
||||
---
|
||||
|
||||
## 1. Ueberblick: Leistungsprozesse
|
||||
|
||||
pathOS unterstuetzt die Leistungsprozesse "LN 34 Fahrplan und Kapazitaetsmanagement":
|
||||
|
||||
| Prozess | Beschreibung | pathOS-Rolle |
|
||||
|---------|-------------|-------------|
|
||||
| **LN34-01 Netzfahrplan erstellen** | Jaehrliche Erstellung des Netzfahrplans (NEP1, NEP2, VNP, ENP) | Trassenanmeldung, Angebotserstellung, Vertragsschluss |
|
||||
| **LN34-02 Rahmenvertrag erstellen** | Mehrjaehrige Kapazitaetszusicherungen (auslaufend, letzte bis 2031) | Begrenzte Unterstuetzung (Verweis auf bestehende RV) |
|
||||
| **LN34-03 Gelegenheitsverkehr** | Kurzfristige Trassenbestellungen ausserhalb Netzfahrplan | Vollstaendiger Bestellprozess (Happy Path) |
|
||||
| LN34-07 Kapazitaetsmanagement | Betriebsprogrammstudien | Nicht direkt in pathOS |
|
||||
|
||||
## 2. Fahrplanphasen (Netzfahrplan)
|
||||
|
||||
```
|
||||
Anmeldefrist
|
||||
(2. Mo April)
|
||||
|
|
||||
NEP1 | NEP2 VNP ENP GelV
|
||||
(Erstbestellung) | (Phase 2) (Vorlaeufig) (Endgueltig) (Laufend)
|
||||
──────────────────────►|──────────►──────────►──────────►──────────►
|
||||
First-come-first-serve | Koordinierung Veroeffentl. Inkrafttreten
|
||||
Vorteil bei Konflikten | bei Konflikten (Dezember)
|
||||
```
|
||||
|
||||
| Phase | Zeitraum | Beschreibung | Status in pathOS |
|
||||
|-------|----------|-------------|-----------------|
|
||||
| **NEP1** | Bis Anmeldefrist | Erstbestellung, FCFS-Vorteil | ✅ Abgeschlossen |
|
||||
| **NEP2** | Nach Anmeldefrist | Zweite Phase, Koordinierungsverfahren | ⏳ Aktuell |
|
||||
| **VNP** | Nach Koordinierung | Vorlaeufiger Netzfahrplan veroeffentlicht | Geplant |
|
||||
| **ENP** | Nach Stellungnahme | Endgueltiger Netzfahrplan | Geplant |
|
||||
| **GelV** | Laufend (24/7) | Kurzfristige Bestellungen | ✅ Produktiv |
|
||||
|
||||
## 3. Kernprozess: Trassenbestellung (End-to-End)
|
||||
|
||||
### Aus Kundensicht (EVU)
|
||||
|
||||
1. **Planung** — Route waehlen, Stammdaten laden, Entwurf erstellen
|
||||
2. **Anmeldung** — Train-Objekt erstellen, PathRequest absenden
|
||||
3. **Warten** — Bestelleingangspruefung (BEP), Fahrplankonstruktion
|
||||
4. **Angebot pruefen** — PathDetailsMessage mit Laufweg und Preis
|
||||
5. **Annehmen/Ablehnen** — Vertragsschluss oder Ueberarbeitung
|
||||
6. **Vertrag** — ProduktVertrag, Abrechnung, Archivierung
|
||||
|
||||
### Aus Systemsicht (pathOS)
|
||||
|
||||
```
|
||||
EVU ──► Portal/CI ──► Steuerung Vertrieb (Camunda) ──► BEP (Pruefung)
|
||||
| |
|
||||
├──► IFP-Connector ──► TPN/BaDiFa (Konstruktion)
|
||||
| |
|
||||
◄──── PathDetailsMessage ◄─────┘
|
||||
|
|
||||
├──► AC Trasse (Preis)
|
||||
├──► Auftrags-Verwaltung (Speicherung)
|
||||
├──► Archivierungsservice (AC Archiv)
|
||||
└──► Vertragsdaten-Verteiler (Stationsportal, ggf. Abrechnung)
|
||||
```
|
||||
|
||||
## 4. Geschaeftsvorfaelle im Detail
|
||||
|
||||
### 4.1 Netzfahrplan-Anmeldung (NEP)
|
||||
|
||||
| Schritt | Akteur | System | Nachricht |
|
||||
|---------|--------|--------|-----------|
|
||||
| Anmeldung erstellen | EVU | Portal/CI | PathRequestMessage |
|
||||
| BEP pruefen | pathOS | BEP (KonBel-K) | FahrlagePruefen |
|
||||
| Konstruktionsauftrag | pathOS | TPN/BaDiFa | Produktionsauftrag (Kafka) |
|
||||
| Konstruktion | Fahrplan | BaDiFa/RuT-K | — |
|
||||
| Angebot erstellen | Fahrplan | TPN | Vertriebsauftrag (Kafka) |
|
||||
| Preis ermitteln | pathOS | AC Trasse | ermittleTrassenPreis |
|
||||
| Angebot an EVU | pathOS | Portal/CI | PathDetailsMessage |
|
||||
| Annahme/Ablehnung | EVU | Portal/CI | Annahme/Ablehnung |
|
||||
| Vertrag | pathOS | AV | ProduktVertrag |
|
||||
| Abrechnung | pathOS | AC Trasse | abrechneVertragsAenderung |
|
||||
|
||||
### 4.2 Gelegenheitsverkehr (GelV)
|
||||
|
||||
Identisch zu NEP, aber:
|
||||
- Kurzfristigere Fristen (48h bis 4 Wochen)
|
||||
- Automatische Konstruktion moeglich (Click&Ride)
|
||||
- Kein Koordinierungsverfahren
|
||||
- Hoehere Dringlichkeit
|
||||
|
||||
### 4.3 Netzausgeloeste Aenderungen (NAE)
|
||||
|
||||
Besonderheit: DB InfraGO kann Trassen aendern oder stornieren (z.B. bei Bauarbeiten).
|
||||
- Ausgeloest durch Fahrplan, nicht durch EVU
|
||||
- Verzoegert (nicht sofort nach Anmeldung)
|
||||
- Erfordert Benachrichtigung des EVU
|
||||
|
||||
### 4.4 Vertragsaenderungen (VAEND)
|
||||
|
||||
Nach Vertragsschluss koennen Aenderungen noetig sein:
|
||||
- Zeitliche Aenderungen (Verkehrstage)
|
||||
- Raeumliche Aenderungen (Laufweg)
|
||||
- Stornierungen (teil oder ganz)
|
||||
- Erfordern neues Train-Objekt nach Vertragsschluss
|
||||
|
||||
### 4.5 ujBau (Umgebungsjahresbau)
|
||||
|
||||
Bau-bezogene Trassenbestellungen:
|
||||
- Bautrassen, Leertrassen
|
||||
- GPE-Stellungnahmen (Grossplanungsereignisse)
|
||||
- Netzausgeloeste Aenderungen wegen Bauarbeiten
|
||||
- Kommunikation ueber KOMBau-Plattform
|
||||
|
||||
## 5. Beteiligte Akteure und Rollen
|
||||
|
||||
### Externe Akteure
|
||||
| Akteur | Rolle | System |
|
||||
|--------|-------|--------|
|
||||
| EVU-Sachbearbeiter | Bestellt Trassen | Portal / CI |
|
||||
| EVU-Poweruser | Verwaltet Benutzer | NuR / Infraportal |
|
||||
| Aufgabentraeger | Lesender Zugriff | Portal |
|
||||
|
||||
### Interne Akteure (DB InfraGO)
|
||||
| Akteur | Rolle | System |
|
||||
|--------|-------|--------|
|
||||
| Kundenbetreuer | Bearbeitet im Auftrag von EVU | Portal |
|
||||
| Trassenkonstrukteur | Konstruiert Fahrplan | TPN/BaDiFa/RuT-K |
|
||||
| Koordinator | Steuert Konstruktionsauftraege | TPN (KK-Client) |
|
||||
| Fachliche Betriebsfuehrung (FBF) | Konfiguration, Monitoring | Portal (Admin) |
|
||||
|
||||
## 6. Datenfluss zwischen Domaenen
|
||||
|
||||
```
|
||||
VERTRIEB (pathOS) FAHRPLAN (TPN/BaDiFa) BETRIEB (S2O)
|
||||
───────────────── ───────────────────── ──────────────
|
||||
Trassenanmeldung ──────► Konstruktionsauftrag
|
||||
◄────── Konstruktionsergebnis
|
||||
Angebot an EVU
|
||||
Vertragsschluss ──────► Fahrplanveroeffentlichung ──► Betriebsplanung
|
||||
Abrechnung (AC)
|
||||
Archivierung
|
||||
```
|
||||
|
||||
## 7. Offene Punkte / Erweiterungen
|
||||
|
||||
- **Buendelprodukte**: Trasse + Anlage + Stationshalt + Energie in einem Bestellvorgang (Vision, nicht im MVP)
|
||||
- **Rolling Planning**: Nachfolger Rahmenvertraege aus TTR-Projekt
|
||||
- **Click&Ride Integration**: ADR-72, technische Anbindung in Arbeit
|
||||
- **TraPo-Anbindung**: ADR-74, neues Trassenportal
|
||||
- **Abrechnungs-Erweiterung**: VDV auch fuer AC Trasse (strategische Ueberlegung)
|
||||
@@ -0,0 +1,199 @@
|
||||
# Iteration 01 — Gesamtbild pathOS
|
||||
|
||||
> Stand: 2026-04-22 | Quellen: 167 GitLab-Projekte + 143 Confluence-Seiten
|
||||
|
||||
---
|
||||
|
||||
## 1. Was ist pathOS?
|
||||
|
||||
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.
|
||||
|
||||
### Kernaufgabe
|
||||
EVU-Kunden (Eisenbahnverkehrsunternehmen) bestellen ueber pathOS Trassen (Fahrwege) auf dem deutschen Schienennetz. Das System verarbeitet Anmeldungen, koordiniert mit dem Fahrplan, erstellt Angebote und verwaltet Vertraege.
|
||||
|
||||
### Kanaele
|
||||
- **Web-Portal** (portal-ui) — Benutzeroberflaeche fuer EVU-Sachbearbeiter und DB-Kundenbetreuer
|
||||
- **API / Common Interface** — TAF/TAP TSI-konforme Schnittstelle fuer EVU-Drittsysteme
|
||||
- **Click&Ride** — Vereinfachte Bestellung fuer eintaegigen Gelegenheitsverkehr
|
||||
|
||||
---
|
||||
|
||||
## 2. Systemlandschaft (aus GitLab + Confluence)
|
||||
|
||||
### Kern-Services (bestellsystem1/apps)
|
||||
|
||||
```
|
||||
portal-ui ──> portal-middleware ──> steuerung-vertrieb (Camunda)
|
||||
│
|
||||
┌────────────────────┼────────────────────┐
|
||||
▼ ▼ ▼
|
||||
auftrags-verwaltung common-interface kundendaten-
|
||||
-trasse (TAF/TAP TSI) bereitstellung
|
||||
│ │ │
|
||||
▼ ▼ ▼
|
||||
Auftrag-Service ifp-connector stammdaten-
|
||||
│ bereitstellung
|
||||
▼
|
||||
vertragsdaten-verteiler
|
||||
archivierungsservice
|
||||
tbv-absicherung-konverter
|
||||
taftap-tdm-konverter
|
||||
rabattnummern-bereitstellung
|
||||
```
|
||||
|
||||
### Externe Systeme (22 Schnittstellen laut Vorstudie)
|
||||
|
||||
| System | Funktion | Richtung |
|
||||
|--------|----------|----------|
|
||||
| **TPN** (Trassenportal Netz) | Altsystem, paralleler Betrieb | Bidirektional |
|
||||
| **BaDiFa** (Fahrplankonstruktion) | Fahrplanauftraege, Kapazitaetsbuchung | Bidirektional |
|
||||
| **KonBel-K / M13** | Bestelleingangspruefung (BEP), Routensuche | Consumer |
|
||||
| **AC** (AbrechnungsCockpit Trasse) | Preise, Abrechnung, Belege | Consumer |
|
||||
| **KDV** (Kundendatenverwaltung) | Kundenstammdaten | Consumer |
|
||||
| **IM / M15** (Infrastruktur-Manager) | Betriebsstellen, Strecken, Stammdaten | Consumer |
|
||||
| **CRD** (Common Reference Data / RNE) | Company_ID, Location_ID | Consumer |
|
||||
| **GeoServer** | Kartendarstellung, Routenvisualisierung | Consumer |
|
||||
| **eBRS-AD / iMan** | Benutzerverwaltung (intern/extern) | Consumer |
|
||||
| **NuR** (Nutzer- und Rechteverwaltung) | Einfachbahn-Berechtigungen | Consumer |
|
||||
| **Netzmonitor / SAPBINe** | Auftragsdaten-Bereitstellung | Provider |
|
||||
| **Stationsportal** | Vertragsdaten | Provider |
|
||||
| **Click&Ride** | Vereinfachte Bestellung | Bidirektional |
|
||||
| **TraPo** | Trassenportal (neu, ADR 72) | Geplant |
|
||||
| **KOMBau** | Kommunikation Bau | Geplant |
|
||||
|
||||
### Technologie-Stack
|
||||
|
||||
| Schicht | Technologie |
|
||||
|---------|-------------|
|
||||
| Frontend | TypeScript, Angular(?), SCSS |
|
||||
| Backend | Java, Spring Boot |
|
||||
| Workflow | Camunda 8 (Upgrade auf 8.8/8.9 geplant) |
|
||||
| Messaging | Apache Kafka (AWS MSK) |
|
||||
| Datenbank | PostgreSQL |
|
||||
| Identity | Keycloak |
|
||||
| Container | Docker, Kubernetes (AWS EKS) |
|
||||
| CI/CD | GitLab CI, Helm, Cloud Native Buildpacks |
|
||||
| Monitoring | Prometheus, Grafana, Netcool (geplant) |
|
||||
| Security | Trivy, OWASP ZAP, Fortify, SonarQube |
|
||||
| Datenformat | TAF/TAP TSI (europaeischer Standard) |
|
||||
|
||||
---
|
||||
|
||||
## 3. Fachliche Kernobjekte
|
||||
|
||||
Aus der Confluence-Dokumentation (Kapitel 4.3):
|
||||
|
||||
| Objekt | Ersteller | Beschreibung |
|
||||
|--------|-----------|-------------|
|
||||
| **Train** | EVU (Kunde) | Grundlegendes Objekt fuer Kundensicht. Beschreibt den Geschaeftsvorfall. |
|
||||
| **PathRequest** | EVU (Kunde) | Konkrete Trassenanmeldung, abgeleitet vom Train. 1:n Beziehung. |
|
||||
| **Path** | IM (DB InfraGO) | Zeit-Wege-Linie durch das Netz. Wird vom Infrastruktur-Manager erstellt. |
|
||||
| **PathDetailsMessage** | IM | Zuordnung Path zu PathRequest (1:n). |
|
||||
| **CaseReference** | Bilateral | Buendelung von Objekten (Taktverkehre, Baumassnamen, etc.) |
|
||||
|
||||
### Lebenszyklus
|
||||
1. EVU erstellt **Train** (Planungsphase)
|
||||
2. Train wird in **PathRequests** aufgesplittet (Anmeldung)
|
||||
3. IM erstellt **Path**-Objekte und sendet **PathDetailsMessages**
|
||||
4. Vertragsschluss fixiert die Objekte
|
||||
5. Nach Vertragsschluss: Aenderungen erfordern neue Train-Objekte
|
||||
|
||||
---
|
||||
|
||||
## 4. Technische Roadmap 2026 — Zusammenfassung
|
||||
|
||||
53 technische Themen, davon 17 MUSS (UKA/GELV), 24 MUSS 2026, 12 SOLL.
|
||||
|
||||
### Kritischste Themen (MUSS UKA/GELV)
|
||||
- Kubernetes-Cluster-Umstellung (1.1)
|
||||
- Betriebsueberwachung Netcool (1.2)
|
||||
- ECR statt Artifactory (1.3)
|
||||
- Vereinfachung Staging (2.1)
|
||||
- Security-Groups egress (3.1)
|
||||
- Secret-Rotation (3.2)
|
||||
- Monitoring-Konzept (4.1)
|
||||
- Camunda Point-in-Time-Recovery (5.1)
|
||||
- Disaster-Recovery-Tests (5.2, 5.3)
|
||||
- Spring Boot 4 Upgrade (8.1) — EOL Spring Boot 3.5: Juni 2026!
|
||||
- Camunda 8.8 Upgrade (8.2)
|
||||
- Runbook-Ausarbeitung (10.1)
|
||||
|
||||
### Deployment-Probleme (bestaetigt durch Confluence)
|
||||
- Deployment-Dauer auf TTT-ITU/TTT-KTU zu hoch
|
||||
- Keine dedizierte Verantwortung fuer Releases
|
||||
- Pipeline-Komplexitaet zu hoch
|
||||
- Code-Dopplung in Deployment-Scripten
|
||||
- Fehlende Automatisierung Release & Deployment
|
||||
|
||||
---
|
||||
|
||||
## 5. Identifizierte Problemfelder
|
||||
|
||||
### P1: Deployment-Komplexitaet (KRITISCH)
|
||||
- 47 Infra-Projekte (28% aller Repos)
|
||||
- 5+ separate Keycloak-Projekte
|
||||
- Deployment als "ein einziges Kubernetes-Deployment" ist Ziel, aber noch nicht erreicht
|
||||
- Manuelle Release-Orchestrierung ueber Teams-Kanal
|
||||
- Keine automatisierten Smoketests nach Deployment (erst seit 03/2026 in Arbeit)
|
||||
|
||||
### P2: Fehlende Dokumentation (HOCH)
|
||||
- ~60% der GitLab-Projekte ohne Beschreibung
|
||||
- Architektur-Dokumentation verweist auf Runbook (wird gerade neu erstellt)
|
||||
- Vorstudie von 2019 ist teilweise veraltet
|
||||
|
||||
### P3: Technische Schulden (HOCH)
|
||||
- Spring Boot 3.5 EOL Juni 2026 — Upgrade auf 4 noch im Funnel
|
||||
- Full-Table-Scans in Auftrags-Verwaltung-Trasse
|
||||
- Bidirektionale Abhaengigkeit CI/TTK - SV (ADR-56)
|
||||
- AppMesh AWS EOL 2026 — Alternative noch nicht umgesetzt
|
||||
- 30 von 53 Roadmap-Items haben noch kein Ticket
|
||||
|
||||
### P4: Altsystem-Abhaengigkeit (HOCH)
|
||||
- TPN (seit 2002) laeuft parallel
|
||||
- Datensynchronisation TPN <> pathOS noetig
|
||||
- Gleiche Ressourcen/Mitarbeiter fuer beide Systeme
|
||||
- TTTneo als Uebergangsloesung
|
||||
|
||||
### P5: Team-Struktur & Wissen (MITTEL)
|
||||
- DevOps-Know-How wird gerade aufgebaut
|
||||
- Rollierendes Deployment-Verantwortungssystem erst seit 06/2025
|
||||
- Teams: Zero, 404, CIB, STeam, BSSUPPORT (aus Confluence)
|
||||
|
||||
---
|
||||
|
||||
## 6. Abkuerzungen (geklaert aus Confluence)
|
||||
|
||||
| Abkuerzung | Bedeutung |
|
||||
|------------|-----------|
|
||||
| TPN | Trassenportal Netz (Altsystem seit 2002) |
|
||||
| BEP | TrassenProduktPruefenUndErgaenzen (Bestelleingangspruefung) |
|
||||
| IFP | Integrierte FahrPlanbearbeitung (Schnittstelle) |
|
||||
| TADEF | TAF/TAP DEFinition (Connector) |
|
||||
| PMW | Portal MiddleWare |
|
||||
| IM | Infrastruktur-Manager (M15) |
|
||||
| NuR | Nutzer- und Rechteverwaltung (Einfachbahn) |
|
||||
| TPS | Trassenpreis-Service (Rabatt) |
|
||||
| KDV | Kundendatenverwaltung |
|
||||
| AC | AbrechnungsCockpit Trasse |
|
||||
| BaDiFa | Bahndigitale Fahrplanung |
|
||||
| RuT-K | Rechnerunterstuetzte Trassenkonstruktion |
|
||||
| GFD-Z | Gelegenheitsfahrdienstleistung Zentral |
|
||||
| TTT | TAF/TAP TSI (Telematics Applications for Freight/Passengers - Technical Specification for Interoperability) |
|
||||
| TTTneo | Neue Umsetzungsstrategie fuer Trassenmanagement |
|
||||
| UKA | Unternehmenskritische Anwendung |
|
||||
| GELV | Gelegenheitsverkehr (Meilenstein) |
|
||||
| CI | Common Interface (TAF/TAP TSI) |
|
||||
| SV | Steuerung Vertrieb (Camunda-Prozess) |
|
||||
| CNP | Cloud Native Platform |
|
||||
| ADR | Architecture Decision Record |
|
||||
| PI | Program Increment (SAFe) |
|
||||
|
||||
---
|
||||
|
||||
## 7. Naechste Schritte
|
||||
|
||||
1. **Architektur-Diagramm** — Mermaid-Diagramm der Systemlandschaft erstellen
|
||||
2. **Team-Mapping** — Welches Team besitzt welche Projekte?
|
||||
3. **Dependency-Analyse** — pom.xml/build.gradle der Kern-Services analysieren
|
||||
4. **Runbook lesen** — Aktuelle Architektur-Dokumentation aus dem Runbook
|
||||
5. **Confluence vertiefen** — Weitere Seiten zu Geschaeftsprozessen, Vorstudie Kapitel 3-5
|
||||
@@ -0,0 +1,134 @@
|
||||
# Erstanalyse GitLab — pathOS / Bestellsystem
|
||||
|
||||
> Generiert: 2026-04-22 | Basis: 167 Projekte, 9 Untergruppen
|
||||
|
||||
---
|
||||
|
||||
## Überblick
|
||||
|
||||
| Kennzahl | Wert |
|
||||
|----------|------|
|
||||
| Projekte gesamt | 167 |
|
||||
| Davon aktiv (< 6 Monate) | ~109 |
|
||||
| Davon inaktiv (6M+) | ~26 |
|
||||
| Davon archiviert | 32 |
|
||||
| Untergruppen | 9 |
|
||||
| Hauptsprache | Java (47 Projekte) |
|
||||
| Build-System | Maven (83 Projekte) |
|
||||
| Containerisiert | 46 Projekte mit Dockerfile |
|
||||
|
||||
## Gruppenstruktur
|
||||
|
||||
```
|
||||
bestellsystem1/
|
||||
├── apis/ (37 Projekte) — API-Definitionen, OpenAPI-Specs, Datenmodelle
|
||||
├── apps/ (19 Projekte) — Laufende Services und Anwendungen
|
||||
├── docs/ (7 Projekte) — Dokumentation, Runbook, Schemas
|
||||
├── infra/ (47 Projekte) — Deployment, CI/CD, Helm Charts, Keycloak, Monitoring
|
||||
├── libraries/ (7 Projekte) — Shared Libraries (core-components, logging, signatures)
|
||||
├── mocks/ (11 Projekte) — Mock-Services für Tests
|
||||
├── qa/ (15 Projekte) — Tests (System, Integration, Performance, Security)
|
||||
├── sandbox/ (13 Projekte) — Experimente, PoCs, Pipeline-Tests
|
||||
└── tools/ (10 Projekte) — Hilfswerkzeuge (Camunda, Kafka, Migration)
|
||||
```
|
||||
|
||||
## Technologie-Stack
|
||||
|
||||
### Backend
|
||||
- **Java / Spring Boot** — Dominante Technologie (47 Projekte)
|
||||
- **Maven** — Build-System (83 Projekte, inkl. API-Definitionen)
|
||||
- **Kafka** — Event-Streaming (mehrere Kafka-bezogene Projekte: auftrag-service-kafka, core-components-kafka, kafka-message-replay, Kafka Topic Setup)
|
||||
- **Camunda** — Workflow-Engine (camunda-events, camunda-client, Camunda Backup, steuerung-vertrieb)
|
||||
- **PostgreSQL** — Datenbank (postgresql-chart, Database Setup)
|
||||
|
||||
### Frontend
|
||||
- **TypeScript / JavaScript** — portal-ui (Angular/React?)
|
||||
- **SCSS** — Styling
|
||||
- Nur 1 echtes Frontend-Projekt (portal-ui), Rest ist Backend
|
||||
|
||||
### Infrastruktur
|
||||
- **Kubernetes / Helm** — Deployment (bestellsystem-application, bestellsystem-deployment)
|
||||
- **Docker** — 46 Projekte containerisiert
|
||||
- **Keycloak** — Identity Management (5+ Keycloak-Projekte)
|
||||
- **AWS EKS** — Kubernetes auf AWS (deployment-cdaas-agent-eks)
|
||||
- **SonarQube** — Code-Qualität
|
||||
- **Trivy** — Container-Security-Scanning
|
||||
- **OWASP ZAP** — API-Security-Scanning
|
||||
- **Grafana / Prometheus** — Monitoring (prometheus-blackbox-exporter, prometheus-pushgateway)
|
||||
- **Artifactory** — Artifact-Management
|
||||
- **Renovate** — Dependency-Updates
|
||||
|
||||
### Datenformate & Standards
|
||||
- **TAF/TAP TSI** — Europäischer Standard für Trasseninformationen (taftap, taf-tap-schemas, taftap-tdm-konverter)
|
||||
- **TDM** — Trassendatenmodell (data-model)
|
||||
- **XML / JSON** — Konvertierung zwischen Formaten (tdm-prm-json2xml-konverter)
|
||||
|
||||
## Fachliche Domänen (aus Projektnamen abgeleitet)
|
||||
|
||||
### Kernprozess: Trassenbestellung
|
||||
- `trassenanmeldung` — Trassenanmeldung
|
||||
- `auftraege` / `Auftrag-Service` / `auftragsverwaltung` — Auftragsverwaltung
|
||||
- `auftrags-verwaltung-trasse` — Spezifisch für Trassenbestellungen
|
||||
- `steuerung-vertrieb` — Prozesssteuerung (Camunda-basiert)
|
||||
- `produktionsauftrag` — Produktionsaufträge
|
||||
- `versandauftrag` / `versandergebnis` — Versand von Aufträgen
|
||||
- `vertriebsauftraege` — Vertriebsaufträge
|
||||
|
||||
### Stammdaten & Kundendaten
|
||||
- `stammdaten-bereitstellung` / `stammdatenEVU` / `stammdatenPMW` / `StammdatenAdmin` — Stammdaten
|
||||
- `kundendaten` / `kundendaten-bereitstellung` / `bszkundendaten` — Kundendaten
|
||||
- `partnerverwaltung` / `partnerverwaltungAdmin` — Partnerverwaltung
|
||||
|
||||
### Externe Schnittstellen
|
||||
- `ifp-connector` / `ifp-mock` / `ifp-mock-messages` — IFP-Anbindung
|
||||
- `tadef-connector` — TADEF-Anbindung
|
||||
- `taftap` / `taftap-tdm-konverter` — TAF/TAP TSI Konvertierung
|
||||
- `common-interface` — DB-Vertrieb-spezifische TAF/TAP Implementierung
|
||||
- `abrechnung` / `abrechnung-connector` — Abrechnungssystem
|
||||
- `stationsportal` — Stationsportal-Anbindung
|
||||
- `pzp` — (unklar, zu klären)
|
||||
- `nvntool` — (unklar, zu klären)
|
||||
- `imcrdservice` / `imordnungsrahmen` / `imstammdaten` — Infrastrukturmanager-Anbindung
|
||||
|
||||
### Portal & UI
|
||||
- `portal-ui` — Benutzeroberfläche (einziges Frontend)
|
||||
- `portal-middleware` / `portal` — Portal-Backend/Middleware
|
||||
|
||||
### Sicherheit & Abrechnung
|
||||
- `tbv-absicherung` / `tbv-absicherung-konverter` — Tunnelbegegnungsverbot
|
||||
- `abrechnung` — Abrechnungsanbindung
|
||||
- `rabattnummern-bereitstellung` / `rabattnummernPMW` — Rabattsystem
|
||||
|
||||
## Erste Auffälligkeiten & Risiken
|
||||
|
||||
### 🔴 Kritisch
|
||||
1. **Viele Projekte ohne Beschreibung** — Ca. 60% der Projekte haben keine Beschreibung. Das erschwert Onboarding und Verständnis massiv.
|
||||
2. **Infra-Overhead** — 47 Infra-Projekte (28% aller Projekte!) deuten auf komplexes, möglicherweise fragmentiertes Deployment hin. Passt zu deiner Aussage "Deployment ist sehr zeitaufwändig".
|
||||
3. **Keycloak-Fragmentierung** — 5+ separate Keycloak-Projekte (keycloak, keycloak-config-cli-image, Keycloak Deployment, keycloak-scripts, keycloak-theme, Keycloak Setup). Konsolidierungspotenzial.
|
||||
|
||||
### 🟡 Hoch
|
||||
4. **32 archivierte Projekte** — Noch in der Gruppe, erzeugen Rauschen. Aufräumen oder in eigene Archiv-Gruppe verschieben.
|
||||
5. **21 inaktive Projekte (6M+)** — Unklar ob noch relevant oder vergessen.
|
||||
6. **Mock-Explosion** — 11 separate Mock-Projekte. Könnte auf fehlende Contract-Testing-Strategie hindeuten.
|
||||
7. **Sandbox mit 13 Projekten** — Einige davon archiviert, aber "pathOS MCP" und "kiro-test-review" sind interessant (KI-Integration?).
|
||||
|
||||
### 🟢 Positiv
|
||||
8. **Klare Gruppenstruktur** — APIs, Apps, Infra, Libraries, QA, Tools ist eine sinnvolle Aufteilung.
|
||||
9. **Security-Tooling vorhanden** — Trivy, OWASP ZAP, Fortify sind im Einsatz.
|
||||
10. **Renovate aktiv** — Automatische Dependency-Updates.
|
||||
11. **Aktive Entwicklung** — Die meisten Kernprojekte wurden in den letzten Tagen aktualisiert.
|
||||
|
||||
## Offene Fragen für nächste Iteration
|
||||
|
||||
1. Was ist **IFP**? (ifp-connector, ifp-mock)
|
||||
2. Was ist **TADEF**? (tadef-connector)
|
||||
3. Was ist **PZP**? (pzp)
|
||||
4. Was ist **NVN**? (nvntool)
|
||||
5. Was ist **PMW**? (Portal Middleware? stammdatenPMW, rabattnummernPMW)
|
||||
6. Was ist **IM**? (imcrdservice, imordnungsrahmen, imstammdaten — Infrastrukturmanager?)
|
||||
7. Was ist **NuR**? (nur-mock — "Nutzer- und Rechteverwaltung #Einfachbahn")
|
||||
8. Was ist **BEP**? (bep-mock)
|
||||
9. Was ist **TPS**? (tps-mock — "Rabatt")
|
||||
10. Wie sieht die Camunda-Prozesslandschaft aus? (steuerung-vertrieb)
|
||||
11. Wie viele Umgebungen gibt es? (umgebungs-konfiguration, staging)
|
||||
12. Wie sieht die Kafka-Topic-Landschaft aus? (msk-topic-permissions)
|
||||
@@ -0,0 +1,154 @@
|
||||
# Iteration 02 — Technischer Deep Dive: Ergebnisse
|
||||
|
||||
> Stand: 2026-04-22 | Basis: 23 pom.xml + 1 package.json der Kern-Services
|
||||
|
||||
---
|
||||
|
||||
## 1. Versionen und Abhaengigkeiten
|
||||
|
||||
### Zentrale Versionen (aus bestellsystem-parent-pom)
|
||||
|
||||
| Komponente | Version | Status | Risiko |
|
||||
|-----------|---------|--------|--------|
|
||||
| **Java** | 17 (Parent) / 21 (Services) | Migration laeuft | MITTEL — Parent noch auf 17, Services auf 21 |
|
||||
| **Spring Boot** | 3.5.13 | EOL Juni 2026! | KRITISCH — Upgrade auf 4.x dringend |
|
||||
| **Camunda 8** | 8.8.22 | Aktuell | OK — Upgrade auf 8.9 geplant |
|
||||
| **PostgreSQL Driver** | 42.7.10 | Aktuell | OK |
|
||||
| **Flyway** | 11.20.3 | Aktuell | OK |
|
||||
| **Log4j2** | 2.25.4 | Aktuell | OK |
|
||||
| **Jackson** | 2.21.2 | Aktuell | OK |
|
||||
| **OpenAPI Generator** | 7.21.0 | Aktuell | OK |
|
||||
| **Cucumber** | 7.34.3 (Parent) / 7.23.0 (SV) | Divergenz! | NIEDRIG — aber Inkonsistenz |
|
||||
| **JUnit** | 5.14.3 | Aktuell | OK |
|
||||
| **WireMock** | 3.13.2 | Aktuell | OK |
|
||||
| **MapStruct** | 1.6.3 | Aktuell | OK |
|
||||
| **OpenTelemetry** | 2.27.0 (Parent) / 2.26.1 (SV) | Divergenz | NIEDRIG |
|
||||
| **AWS SDK** | 2.42.34 (SV) | Aktuell | OK |
|
||||
| **Angular** | 21.2.4 | Aktuell | OK |
|
||||
| **TypeScript** | ~5.9.2 | Aktuell | OK |
|
||||
| **RxJS** | 7.8.2 | Aktuell | OK |
|
||||
|
||||
### Aktive CVE-Patches (aus pom.xml Kommentaren)
|
||||
|
||||
| CVE | Bibliothek | Fix-Version |
|
||||
|-----|-----------|-------------|
|
||||
| CVE-2025-48924 | commons-lang3 | 3.20.0 |
|
||||
| CVE-2025-53864 | nimbus-jose-jwt | 10.9 |
|
||||
| CVE-2025-66566 | lz4-java | 1.11.0 |
|
||||
| CVE-2026-1002 | vertx-core | 4.5.26 |
|
||||
| CVE-2025-12183 | lz4-java (Kafka) | at.yawk fork |
|
||||
| CVE-2026-40477/78 | thymeleaf (Togglz) | Excluded |
|
||||
| GHSA-* (diverse) | tomcat-embed-core | 10.1.54 |
|
||||
| GHSA-3pxv-* | log4j-core | 2.25.4 |
|
||||
|
||||
## 2. Architektur-Bewertung
|
||||
|
||||
### Parent-POM Struktur
|
||||
- **bestellsystem-parent-pom** (v0.12.50-SNAPSHOT): Zentrale Versionsverwaltung fuer alle Services
|
||||
- GroupId: `com.dbnetz.bestellsystem`
|
||||
- Definiert Spring Boot, Logging, Monitoring, OpenAPI, Test-Dependencies zentral
|
||||
- **Problem**: Parent-POM hat `java.version=17`, aber die meisten Services ueberschreiben auf `21`
|
||||
- **Problem**: Einige Services (SV) haben eigene Parent-POMs statt den gemeinsamen zu nutzen
|
||||
|
||||
### Steuerung-Vertrieb (Komplexester Service)
|
||||
- **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)
|
||||
- Eigener Parent-POM (nicht bestellsystem-parent-pom)
|
||||
- Camunda 8.8.22 integriert
|
||||
- Lombok + MapStruct
|
||||
- Feature Toggles via Togglz
|
||||
- AWS SDK fuer MSK/Kafka
|
||||
- 10+ interne API-Dependencies (trassenanmeldung, versandauftrag, versandergebnis, etc.)
|
||||
|
||||
### Auftrags-Verwaltung-Trasse
|
||||
- Nutzt bestellsystem-parent-pom (v1.8.0) als Parent
|
||||
- Kafka-Integration (Spring Kafka 3.3.14)
|
||||
- OAuth2 Resource Server (Spring Security)
|
||||
- Feature Toggles via Togglz
|
||||
- Signature-Database + Signature-Message (Nachrichtensignierung)
|
||||
- OpenAPI Code-Generierung aus data-model
|
||||
|
||||
### Portal UI
|
||||
- Angular 21.2.4 (sehr aktuell)
|
||||
- Eigene UI-Library: `@kuk/kuk-ui-library`
|
||||
- Portal-API: `@bestellsystem/portal-api` v4.0.0
|
||||
- OIDC Auth: `angular-auth-oidc-client`
|
||||
- PDF-Generierung: jspdf + jspdf-autotable
|
||||
- Cypress fuer E2E-Tests
|
||||
- Karma + Jasmine fuer Unit-Tests
|
||||
|
||||
## 3. Dependency-Graph (vereinfacht)
|
||||
|
||||
```
|
||||
bestellsystem-parent-pom (v0.12.50)
|
||||
|
|
||||
+-- auftrags-verwaltung-trasse (v1.7.1)
|
||||
| +-- auftragsverwaltung-api (v6.0.0)
|
||||
| +-- auftraege-api (v6.0.0)
|
||||
| +-- event-model-api (v3.3.0)
|
||||
| +-- data-model (v10.0.0)
|
||||
| +-- signature-database (v1.5.0)
|
||||
| +-- signature-message (v1.7.0)
|
||||
| +-- logging-util (v1.3.0)
|
||||
|
|
||||
+-- stammdaten-bereitstellung
|
||||
+-- kundendaten-bereitstellung
|
||||
+-- rabattnummern-bereitstellung
|
||||
+-- archivierungsservice
|
||||
+-- common-interface
|
||||
+-- taftap-tdm-konverter
|
||||
+-- tbv-absicherung-konverter
|
||||
+-- vertragsdaten-verteiler
|
||||
|
||||
steuerung-vertrieb (EIGENER Parent, v1.6.1)
|
||||
|
|
||||
+-- trassenanmeldung-api (v8.11.0)
|
||||
+-- versandauftrag-api (v3.11.0)
|
||||
+-- versandergebnis-api (v2.14.0)
|
||||
+-- vertriebsauftraege-api (v8.3.0)
|
||||
+-- produktionsauftrag-api (v3.5.0)
|
||||
+-- eventmodel-api (v3.2.0)
|
||||
+-- kundendaten-api (v2.9.0)
|
||||
+-- objectinfomessage-api (v2.11.0)
|
||||
+-- data-model (v10.0.0)
|
||||
+-- camunda-events (v2.2.0)
|
||||
+-- signature-message (v1.7.0)
|
||||
+-- core-components-common (v1.6.1)
|
||||
+-- core-components-kafka (v1.2.1)
|
||||
|
||||
portal-ui (Angular 21, v1.9.1)
|
||||
+-- @bestellsystem/portal-api (v4.0.0)
|
||||
+-- @kuk/kuk-ui-library (v0.45.0)
|
||||
```
|
||||
|
||||
## 4. Technische Gesundheits-Scorecard
|
||||
|
||||
| Kategorie | Bewertung | Details |
|
||||
|-----------|-----------|---------|
|
||||
| **Java-Version** | 🟡 | 21 in Services, aber Parent noch auf 17. Inkonsistenz. |
|
||||
| **Spring Boot** | 🔴 | 3.5.13 — EOL Juni 2026. Upgrade auf 4.x ist KRITISCH. |
|
||||
| **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 Modulen sehr komplex, andere Services einfacher |
|
||||
| **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 integriert |
|
||||
| **Testing** | 🟡 | Cucumber + JUnit + WireMock, aber Testkonzept in Ueberarbeitung (ADR-70) |
|
||||
|
||||
## 5. Handlungsempfehlungen (priorisiert)
|
||||
|
||||
### KRITISCH
|
||||
1. **Spring Boot 4 Upgrade** — EOL 3.5 ist Juni 2026. Muss sofort beginnen. Betrifft ALLE Services.
|
||||
2. **Parent-POM Konsolidierung** — SV sollte den gemeinsamen Parent nutzen oder die Divergenz bewusst dokumentieren.
|
||||
|
||||
### HOCH
|
||||
3. **Java-Version im Parent auf 21 anheben** — Alle Services nutzen bereits 21, Parent hinkt hinterher.
|
||||
4. **Cucumber-Version vereinheitlichen** — 7.34.3 vs 7.23.0 zwischen Parent und SV.
|
||||
5. **SV-Modularitaet pruefen** — 18 Module ist sehr viel. Gibt es Konsolidierungspotenzial?
|
||||
|
||||
### MITTEL
|
||||
6. **OpenTelemetry-Version synchronisieren** — 2.27.0 vs 2.26.1
|
||||
7. **Testkonzept-Modernisierung** — ADR-70 ist in Arbeit, Umstieg von Cucumber auf Plain JUnit in Teilen geplant
|
||||
8. **data-model v10.0.0** — Zentrale Abhaengigkeit, Aenderungen haben Breitenwirkung
|
||||
@@ -0,0 +1,192 @@
|
||||
# Iteration 03 — Team & Workflow Analyse
|
||||
|
||||
> Stand: 2026-04-22 | Quellen: Runbook, Confluence, GitLab-Berechtigungen
|
||||
|
||||
---
|
||||
|
||||
## 1. Team-Struktur (IST)
|
||||
|
||||
### Entwicklungsteams
|
||||
|
||||
**ACHTUNG: Seit PI 39 neue Struktur! STeam wurde aufgeloest.**
|
||||
|
||||
| Team | Subdomaene | Kern-Verantwortung | Aenderung PI 39 |
|
||||
|------|-----------|-------------------|----------------|
|
||||
| **Team Zero** | TAF/TAP Schnittstellen | Common Interface, Stammdaten, TAF/TAP-TDM-Konverter | Unveraendert + OPs-Anteil |
|
||||
| **Team 404** | Bestellportal | Portal UI (Angular), Portal Middleware | Unveraendert + OPs-Anteil |
|
||||
| **Team CIB** | Prozesse + Backend | Steuerung Vertrieb (Camunda), Auftrags-Verwaltung, IFP-Connector | Unveraendert + OPs-Anteil |
|
||||
| **~~Team STeam~~** | ~~Infrastruktur~~ | ~~CI/CD, Deployment, Keycloak, Monitoring~~ | **AUFGELOEST seit PI 39** |
|
||||
| **Team OPs (NEU)** | Infrastruktur / DevOps | CI/CD, Deployment, Monitoring, Security | 2 feste + rotierende Mitglieder aus allen Teams |
|
||||
| **Team BSSUPPORT (SuBP)** | Support | 2nd Level Support | Unveraendert |
|
||||
| **Team FbF** | Fachliche Betriebsfuehrung | Fachlicher Betrieb, Konfiguration | Unveraendert |
|
||||
|
||||
> **Wichtig**: Die STeam-Aufgaben (47 Infra-Projekte) wurden auf die Entwicklungsteams verteilt. Das OPs-Team hat nur 2 feste Mitglieder und wird durch rotierende Mitglieder aus allen Teams bestueckt. Details zur Verteilung muessen aus Jira (O2CBS, PI 39+) verifiziert werden.
|
||||
|
||||
### Uebergreifende Rollen (aus Confluence)
|
||||
|
||||
| Rolle | Funktion |
|
||||
|-------|---------|
|
||||
| Produktmanagement (PM) | Strategische Produktsteuerung |
|
||||
| Product Owner (PO) | Pro Team, fachliche Priorisierung |
|
||||
| Systemarchitekt | Architekturentscheidungen, ADRs |
|
||||
| Release Train Engineer (RTE) | SAFe-Koordination, PI-Planung |
|
||||
| QA-Lead / Testmanager | Teststrategie, Testkoordination |
|
||||
| Scrum Master | Pro Team, Prozessbegleitung |
|
||||
| Business Engineer | Fachliche Anforderungen |
|
||||
|
||||
### Hinweis aus Runbook
|
||||
> "Es gibt keine 1:1 Entsprechung zwischen den Entwickler-Teams und Domaenen. Ein Grund ist der Wunsch nach einer ausgewogenen Auslastung der Teams."
|
||||
|
||||
## 2. Team-zu-Projekt-Mapping
|
||||
|
||||
### Team Zero (TAF/TAP Schnittstellen)
|
||||
**Projekte (geschaetzt basierend auf Subdomaene):**
|
||||
- apps/common-interface
|
||||
- apps/stammdaten-bereitstellung
|
||||
- apps/taftap-tdm-konverter
|
||||
- apps/tbv-absicherung-konverter
|
||||
- apis/taftap, apis/data-model, apis/stammdatenEVU, apis/stammdatenPMW
|
||||
- apis/versandauftrag, apis/versandergebnis, apis/eingangsnachricht
|
||||
- mocks/bep-mock, mocks/im-mock
|
||||
- docs/taf-tap-schemas
|
||||
|
||||
### Team 404 (Bestellportal)
|
||||
**Projekte:**
|
||||
- apps/portal-ui
|
||||
- apps/portal-middleware
|
||||
- apis/portal
|
||||
- apis/auftraege
|
||||
|
||||
### Team CIB (Prozesse + Backend)
|
||||
**Projekte:**
|
||||
- apps/steuerung-vertrieb
|
||||
- apps/auftrags-verwaltung-trasse
|
||||
- apps/Auftrag-Service (NEU, erstellt 19.04.2026!)
|
||||
- apps/ifp-connector
|
||||
- apps/kundendaten-bereitstellung
|
||||
- apps/rabattnummern-bereitstellung
|
||||
- apps/vertragsdaten-verteiler
|
||||
- apps/archivierungsservice
|
||||
- apps/tadef-connector
|
||||
- apis/auftragsverwaltung, apis/trassenanmeldung, apis/produktionsauftrag
|
||||
- apis/kundendaten, apis/event-model, apis/camunda-events
|
||||
|
||||
### Team STeam (Infrastruktur)
|
||||
**Projekte (47 infra/ + diverse):**
|
||||
- infra/bestellsystem-deployment (ZENTRAL)
|
||||
- infra/bestellsystem-application (Helm Chart)
|
||||
- infra/ci-files
|
||||
- infra/Keycloak* (5+ Projekte)
|
||||
- infra/Database Setup, Kafka Topic Setup, C8 Backup
|
||||
- infra/staging, infra/testing
|
||||
- infra/renovate-exec
|
||||
- infra/infrastruktur-scripte, infrastruktur-basis-container
|
||||
- infra/fortify-util, token-check, token-rotation
|
||||
- infra/deployment-sonarqube, deployment-kafka-ui
|
||||
- tools/camunda-client, kafka-message-replay
|
||||
- docs/Runbook, docs/installierte-versionen
|
||||
|
||||
### Team BSSUPPORT
|
||||
**Projekte:**
|
||||
- Primaer Jira-Tickets (BSSUPPORT-Projekt)
|
||||
- Kein eigenes GitLab-Repo
|
||||
|
||||
## 3. Regeltermine und Kommunikation
|
||||
|
||||
### ART-Ebene (woechentlich/zweiwoechentlich)
|
||||
| Termin | Rhythmus | Teilnehmer |
|
||||
|--------|---------|------------|
|
||||
| pathOS Product Sync | Woechentlich, Do 10-11 | PM, PO, Architekt, QA-Lead, RTE, FBF |
|
||||
| PO/PM Sync | Woechentlich, Di | PO, PM, TaskForce |
|
||||
| BS Trio Sync | Woechentlich, Mi 10-10:45 | RTE, PM, Architekt |
|
||||
| Trio + Fachbereich | Woechentlich, Mi 10:45-11 | + FBF |
|
||||
| System Demo | Zweiwoechentlich, Di 11-12 | Alle Teams + Stakeholder |
|
||||
| Architekturrunde | Zweiwoechentlich, Fr 11-12 | Vertreter aller Teams + Architekt |
|
||||
| CI/CD Jour Fixe | Zweiwoechentlich, Mo 14-15 | Vertreter aller Teams + Architekt |
|
||||
| Testing Jour Fixe | Zweiwoechentlich, Mo 14-15 | Testmanager, Tester aller Teams |
|
||||
| DevOps CoP | Zweiwoechentlich, Mi 13-14 | Entwickler (offen) |
|
||||
|
||||
### Team-Ebene (pro Team)
|
||||
- Daily (taeglich, 15 Min)
|
||||
- Sprint Planning (zweiwoechentlich)
|
||||
- Refinement (zweiwoechentlich)
|
||||
- Sprint Review (zweiwoechentlich)
|
||||
- Sprint Retro (zweiwoechentlich)
|
||||
- Test Jour Fixe (zweiwoechentlich)
|
||||
|
||||
## 4. Release- und Deployment-Workflow
|
||||
|
||||
### Umgebungs-Pipeline (17+ Umgebungen)
|
||||
```
|
||||
DEV Stage:
|
||||
BU (Build) → EU (Review) → BASE-AT (Integrationstest)
|
||||
→ IEU (Integrierte Entwicklung, auto-deploy bei Master-Merge)
|
||||
→ SIT (Systemintegration mit TPN)
|
||||
→ SIT2 (automatisierte SIT)
|
||||
→ LUP (Last & Performance)
|
||||
|
||||
ABN Stage (TTT-abgestimmt):
|
||||
E2E (TTT-ITU1) → SAT1 (Alarm ITU) → SAT2 (Release ITU)
|
||||
→ ABN1 (TTT-KTU, Kundentests) → ABN2 (Release ABN)
|
||||
→ ABN4 (Alarm-Patches) → ABN8 (EVU-Tests)
|
||||
→ PREPROD (Sondertests mit Fahrplan-IT)
|
||||
|
||||
PROD Stage:
|
||||
PROD (Produktionsumgebung)
|
||||
```
|
||||
|
||||
### Release-Prozess
|
||||
- **BS-Release** = Bundle aus Microservice-Versionen (z.B. R23.12.00)
|
||||
- **App-Release** = Einzelner Microservice (Semantic Versioning)
|
||||
- **Hotfix** = Aus Release-Tag, eigener Branch, Merge zurueck in Master
|
||||
- **Staging**: DEV → ABN → PROD (mit TTT-Abstimmung)
|
||||
- **Deployment-Verantwortung**: Rollierend, 1 PO pro Sprint (seit 06/2025)
|
||||
- **Kommunikation**: MS Teams Kanal "pathOS Release"
|
||||
- **Dokumentation**: Confluence-Seite pro BS-Release mit Checkliste
|
||||
|
||||
## 5. Identifizierte Engpaesse
|
||||
|
||||
### E1: Deployment-Bottleneck (KRITISCH)
|
||||
- 17+ Umgebungen, jede mit eigenem Setup
|
||||
- Deployment auf TTT-Umgebungen erfordert Abstimmung mit externem TTT-Releasemanagement
|
||||
- Manuelle Orchestrierung ueber MS Teams
|
||||
- Kein automatisierter Smoketest nach Deployment (erst seit 03/2026 in Arbeit)
|
||||
- bestellsystem-deployment Repo ist ZENTRAL und komplex (Smarty 61%, Python 35%, Shell 4%)
|
||||
|
||||
### E2: Team STeam als Single Point of Failure (HOCH)
|
||||
- STeam verantwortet 47 Infra-Projekte
|
||||
- Keycloak, Deployment, CI/CD, Monitoring, Security, Artifactory, CNP — alles bei einem Team
|
||||
- DevOps-Wissenstransfer an andere Teams erst seit 02/2025 aktiv
|
||||
- Rufbereitschaft soll von STeam + Ben/Harram gestellt werden
|
||||
|
||||
### E3: Cross-Team Dependencies (HOCH)
|
||||
- Schnittstellenaenderungen zwischen Teams erfordern Koordination (z.B. SV-API aendert sich → 404 und Zero muessen nachziehen)
|
||||
- Kein Contract Testing (ADR-50 war geplant, wurde als "Obsolet" markiert)
|
||||
- 10+ interne APIs mit eigenen Versionen
|
||||
|
||||
### E4: TTT-Abhaengigkeit (MITTEL)
|
||||
- Releases muessen mit TTT-Releasemanagement abgestimmt werden
|
||||
- Eigene Umgebungen (SAT1, SAT2, ABN1, ABN2) fuer TTT-Integration
|
||||
- TPN-Anbindung ueber Kafka erfordert Umgebungsverschaltung
|
||||
|
||||
### E5: Wissenskonzentration (MITTEL)
|
||||
- Runbook Kap. 8.36 listet umfangreichen DevOps-Wissensbedarf
|
||||
- "Meist schlafen reine Betriebler schlecht" — Zitat aus Runbook
|
||||
- Ziel: "You build it, you run it" — aber noch nicht erreicht
|
||||
|
||||
## 6. Reorganisations-Empfehlungen
|
||||
|
||||
### Kurzfristig (naechste PIs)
|
||||
1. **DevOps-Wissen verteilen**: Jedes Team sollte mindestens 2 Personen mit Deployment-Faehigkeit haben
|
||||
2. **Deployment-Automatisierung**: Smoketests nach jedem Deployment automatisieren
|
||||
3. **Release-Checkliste digitalisieren**: Confluence-Checkliste in Pipeline integrieren
|
||||
|
||||
### Mittelfristig (2-3 PIs)
|
||||
4. **Infra-Verantwortung aufteilen**: Teams uebernehmen Infra fuer ihre eigenen Services (STeam wird Enabler statt Bottleneck)
|
||||
5. **Contract Testing einfuehren**: Pact oder aehnliches zwischen den Teams
|
||||
6. **Umgebungen reduzieren**: 17+ ist zu viel. Pruefen ob SAT1/SAT2/SAT3 konsolidiert werden koennen
|
||||
|
||||
### Langfristig (6+ Monate)
|
||||
7. **Team-Schnitt an Subdomaenen ausrichten**: Klare Ownership pro Bounded Context
|
||||
8. **Platform Team**: STeam wird zum Platform Team das Self-Service-Tools bereitstellt
|
||||
9. **TTT-Entkopplung**: Eigene E2E-Tests die TTT-Abhaengigkeit reduzieren
|
||||
@@ -0,0 +1,100 @@
|
||||
# Roadmap & Aktionsplan pathOS
|
||||
|
||||
> Stand: 2026-04-22 | Konsolidierung aller Findings aus Phase 1-3
|
||||
|
||||
---
|
||||
|
||||
## Management Summary
|
||||
|
||||
pathOS ist ein funktionierendes, aktiv entwickeltes System mit solidem Tech-Stack (Java 21, Spring Boot, Angular 21, Camunda 8, Kafka, Kubernetes). Die Architektur ist gut dokumentiert (arc42 Runbook, 75 ADRs) und Security wird ernst genommen (Renovate, Trivy, Fortify, DefectDojo).
|
||||
|
||||
**Die Hauptrisiken liegen nicht im Code, sondern in der operativen Komplexitaet:**
|
||||
- 17+ Umgebungen mit manueller Orchestrierung
|
||||
- 47 Infra-Projekte bei einem Team (STeam)
|
||||
- Spring Boot EOL in 2 Monaten
|
||||
- Parallelbetrieb mit Altsystem TPN
|
||||
|
||||
---
|
||||
|
||||
## Priorisierter Aktionsplan
|
||||
|
||||
### SOFORT (naechste 2 Monate, vor Spring Boot EOL)
|
||||
|
||||
| # | Aktion | Begruendung | Aufwand | Verantwortlich |
|
||||
|---|--------|-------------|---------|---------------|
|
||||
| A1 | **Spring Boot 4 Upgrade starten** | EOL 3.5 ist Juni 2026. Betrifft alle Services. | HOCH (2-4 Sprints) | Alle Teams |
|
||||
| A2 | **Parent-POM Java auf 21 anheben** | Inkonsistenz: Parent=17, Services=21 | NIEDRIG (1 Tag) | STeam |
|
||||
| A3 | **Parent-POM Konsolidierung pruefen** | SV hat eigenen Parent → Versionsdivergenzen | MITTEL (1 Sprint) | CIB + STeam |
|
||||
|
||||
### KURZFRISTIG (naechste 2-3 PIs)
|
||||
|
||||
| # | Aktion | Begruendung | Aufwand | Verantwortlich |
|
||||
|---|--------|-------------|---------|---------------|
|
||||
| A4 | **Deployment-Automatisierung** | Smoketests nach Deployment, Release-Checkliste in Pipeline | MITTEL (2 Sprints) | STeam + alle |
|
||||
| A5 | **DevOps-Wissen verteilen** | Jedes Team 2+ Personen mit Deployment-Faehigkeit | MITTEL (laufend) | Alle Teams |
|
||||
| A6 | **Camunda 8.8 → 8.9 Upgrade** | Roadmap Item 8.2, inkl. PITR | MITTEL (1-2 Sprints) | CIB |
|
||||
| A7 | **Monitoring-Konzept abschliessen** | Roadmap Item 4.1, in Arbeit seit PI 39 | MITTEL (1 Sprint) | STeam |
|
||||
| A8 | **Disaster-Recovery-Test 3** | Roadmap Item 5.2/5.3, Validierung auf Staging | MITTEL (1 Sprint) | STeam |
|
||||
| A9 | **Secret-Rotation Konzept** | Roadmap Item 3.2, kein Ticket | MITTEL (1 Sprint) | STeam |
|
||||
| A10 | **AppMesh-Alternative** | AWS EOL 2026, CNP arbeitet daran | ABHAENGIG von CNP | STeam |
|
||||
| A11 | **Repo-Beschreibungen ergaenzen** | 60% ohne Beschreibung, Quick Win | NIEDRIG (1 Tag) | Alle Teams |
|
||||
| A12 | **Archivierte Repos aufraeumen** | 32 archivierte Projekte erzeugen Rauschen | NIEDRIG (1 Tag) | STeam |
|
||||
|
||||
### MITTELFRISTIG (3-6 Monate)
|
||||
|
||||
| # | Aktion | Begruendung | Aufwand | Verantwortlich |
|
||||
|---|--------|-------------|---------|---------------|
|
||||
| A13 | **Infra-Verantwortung aufteilen** | STeam als Bottleneck entlasten, Teams uebernehmen eigene Infra | HOCH (mehrere PIs) | Alle Teams |
|
||||
| A14 | **Contract Testing einfuehren** | 10+ APIs ohne Contract Tests, ADR-50 war obsolet | MITTEL (2-3 Sprints) | Alle Teams |
|
||||
| A15 | **Umgebungen konsolidieren** | 17+ ist zu viel, SAT1/SAT2/SAT3 pruefen | MITTEL (1-2 Sprints) | STeam |
|
||||
| A16 | **Full-Table-Scans in AV beheben** | Roadmap Item 7.1, Performance-Problem | MITTEL (1-2 Sprints) | CIB |
|
||||
| A17 | **Daten-Partitionierung nach Fahrplanjahr** | Roadmap Item 7.2, bis Maerz 2027 | HOCH (2-3 Sprints) | CIB |
|
||||
| A18 | **Keycloak-Projekte konsolidieren** | 5+ separate Repos | NIEDRIG (1 Sprint) | STeam |
|
||||
| A19 | **API-Versionierung formalisieren** | Roadmap Item 6.4 | MITTEL (1 Sprint) | Alle Teams |
|
||||
| A20 | **GitLab-Repos restrukturieren** | Roadmap Item 6.7 | MITTEL (1-2 Sprints) | STeam |
|
||||
|
||||
### LANGFRISTIG (6+ Monate)
|
||||
|
||||
| # | Aktion | Begruendung | Aufwand | Verantwortlich |
|
||||
|---|--------|-------------|---------|---------------|
|
||||
| A21 | **Team-Schnitt an Subdomaenen** | Klare Ownership pro Bounded Context | HOCH (Orga) | PM/RTE |
|
||||
| A22 | **STeam → Platform Team** | Self-Service-Tools statt Bottleneck | HOCH (Orga) | PM/RTE |
|
||||
| A23 | **TTT-Entkopplung** | Eigene E2E-Tests, weniger TTT-Abhaengigkeit | HOCH (mehrere PIs) | Alle Teams |
|
||||
| A24 | **TPN-Abloesung abschliessen** | Parallelbetrieb beenden | SEHR HOCH | Programm-Ebene |
|
||||
|
||||
---
|
||||
|
||||
## Risiko-Matrix
|
||||
|
||||
| Risiko | Wahrscheinlichkeit | Impact | Massnahme |
|
||||
|--------|-------------------|--------|-----------|
|
||||
| Spring Boot EOL ohne Upgrade | HOCH (2 Monate) | KRITISCH | A1: Sofort starten |
|
||||
| AppMesh EOL ohne Alternative | MITTEL | HOCH | A10: CNP-Abhaengigkeit |
|
||||
| Deployment-Ausfall durch Komplexitaet | MITTEL | HOCH | A4, A5, A15 |
|
||||
| STeam-Mitarbeiter verlassen Projekt | MITTEL | KRITISCH | A5, A13, A22 |
|
||||
| Datenbank-Performance bei Wachstum | MITTEL | HOCH | A16, A17 |
|
||||
| Security-Incident durch veraltete Deps | NIEDRIG (Renovate aktiv) | HOCH | Laufend |
|
||||
|
||||
---
|
||||
|
||||
## Zeitplan-Uebersicht
|
||||
|
||||
```
|
||||
Apr 2026 ████ Phase 1-3 Analyse (HEUTE)
|
||||
Mai 2026 ████ A1: Spring Boot 4 Upgrade beginnen
|
||||
██ A2: Parent-POM Java 21
|
||||
██ A11: Repo-Beschreibungen
|
||||
Jun 2026 ████ A1: Spring Boot 4 Upgrade (EOL!)
|
||||
███ A4: Deployment-Automatisierung
|
||||
██ A6: Camunda 8.9
|
||||
Jul 2026 ███ A7: Monitoring abschliessen
|
||||
███ A8: DR-Test 3
|
||||
██ A9: Secret-Rotation
|
||||
Aug 2026 ███ A13: Infra-Verantwortung aufteilen (Start)
|
||||
██ A14: Contract Testing (Start)
|
||||
Sep 2026 ███ A15: Umgebungen konsolidieren
|
||||
██ A16: Full-Table-Scans
|
||||
Okt 2026 ███ A17: Daten-Partitionierung (Start)
|
||||
██ A19: API-Versionierung
|
||||
Q1 2027 ████ A21-A24: Langfristige Massnahmen
|
||||
```
|
||||
@@ -0,0 +1,81 @@
|
||||
# Jira-Analyse pathOS — Zusammenfassung
|
||||
|
||||
> Stand: 2026-04-22 | 330 Issues (letzte 90 Tage), 9 Komponenten, 2 Boards
|
||||
|
||||
---
|
||||
|
||||
## Backlog-Verteilung nach Komponente
|
||||
|
||||
| Komponente | Issues (90d) | Zuordnung |
|
||||
|-----------|-------------|-----------|
|
||||
| SteuerungVertrieb | 38 (27%) | Team CIB |
|
||||
| Portal_UI | 32 (23%) | Team 404 |
|
||||
| Portal-MW | 30 (21%) | Team 404 |
|
||||
| CommonInterface | 27 (19%) | Team Zero |
|
||||
| AuftragsVerwaltung | 11 (8%) | Team CIB |
|
||||
| StammdatenBereitstellung | 4 (3%) | Team Zero |
|
||||
| ci | 0 | OPs / uebergreifend |
|
||||
| Preisauskunft | 0 | Unklar |
|
||||
| StammdatenAdapter | 0 | Veraltet? |
|
||||
|
||||
**Erkenntnis**: Portal (UI+MW) hat zusammen 62 Issues (44%) — groesster Arbeitsbereich. SV hat 38 (27%). CI hat 27 (19%).
|
||||
|
||||
## Backlog nach Typ
|
||||
|
||||
| Typ | Anzahl | Anteil |
|
||||
|-----|--------|--------|
|
||||
| Feature | 71 | 22% |
|
||||
| Aufgabe | 71 | 22% |
|
||||
| Enabler | 67 | 20% |
|
||||
| Test Execution | 57 | 17% |
|
||||
| Test | 28 | 8% |
|
||||
| Risk | 16 | 5% |
|
||||
| Sonstige | 20 | 6% |
|
||||
|
||||
**Erkenntnis**: Enabler (67) sind fast so viele wie Features (71). Hoher technischer Overhead.
|
||||
|
||||
## Backlog nach Status
|
||||
|
||||
| Status | Anzahl | Anteil |
|
||||
|--------|--------|--------|
|
||||
| Fertig | 190 | 58% |
|
||||
| Funnel | 70 | 21% |
|
||||
| Implementation | 30 | 9% |
|
||||
| Analysis | 8 | 2% |
|
||||
| Offen | 7 | 2% |
|
||||
| Sonstige | 25 | 8% |
|
||||
|
||||
**Erkenntnis**: 70 Items im Funnel (21%) — grosser Backlog an ungeplanten Items.
|
||||
|
||||
## Wichtigste Labels
|
||||
|
||||
| Label | Anzahl | Bedeutung |
|
||||
|-------|--------|-----------|
|
||||
| **Deployment** | 62 | Deployment-bezogene Arbeit — bestaetigt Engpass E1 |
|
||||
| **pathOS_GoLive_MUSS** | 57 | Go-Live-kritische Items |
|
||||
| **O2C-BS-Architektur** | 28 | Architektur-Themen |
|
||||
| **TTT_NEP1** | 28 | Netzfahrplan-Erstbestellung |
|
||||
| **Release** | 23 | Release-Management |
|
||||
| **pathOS_GoLive_SOLL** | 16 | Go-Live wuenschenswert |
|
||||
| **TS4_Stabilitaet** | 14 | Stabilitaets-Themen |
|
||||
| **TTT_PathOS_Reporting** | 13 | Reporting-Anforderungen |
|
||||
| **TTTneo** | 7 | TTTneo-Integration |
|
||||
| **Hotfix** | 5 | Hotfix-Bedarf |
|
||||
|
||||
**Erkenntnis**: 62 Deployment-Items + 57 GoLive-MUSS + 23 Release = Deployment/Release dominiert den Backlog.
|
||||
|
||||
## Neue Team-Struktur (seit PI 39)
|
||||
|
||||
Aus Jira-Komponenten + Interview:
|
||||
|
||||
### Komponenten → Teams (aktuell)
|
||||
- **Team 404**: Portal_UI (32) + Portal-MW (30) = **62 Issues**
|
||||
- **Team CIB**: SteuerungVertrieb (38) + AuftragsVerwaltung (11) = **49 Issues**
|
||||
- **Team Zero**: CommonInterface (27) + StammdatenBereitstellung (4) = **31 Issues**
|
||||
- **Team OPs**: Deployment (62 Label) + ci-Komponente — **uebergreifend, rotierend**
|
||||
|
||||
### Beobachtungen
|
||||
1. Keine Jira-Komponente "OPs" oder "Infrastruktur" — OPs-Arbeit laeuft ueber Labels (Deployment, Release)
|
||||
2. Keine Komponenten-Leads zugewiesen — alle UNASSIGNED
|
||||
3. "Preisauskunft" und "StammdatenAdapter" haben 0 Issues — moeglicherweise veraltet
|
||||
4. Kein separates Board pro Team sichtbar — nur 2 Kanban-Boards (Bugs + Program)
|
||||
@@ -0,0 +1,109 @@
|
||||
# Fachliches Board + TTTI Board — Analyse
|
||||
|
||||
> Stand: 2026-04-22
|
||||
|
||||
---
|
||||
|
||||
## 1. TTT Klaerungsthemen (Board 2791, "Fachliches Board")
|
||||
|
||||
**566 Aufgaben** — reines Kanban-Board fuer fachliche Klaerungen im TTT-Verbund.
|
||||
|
||||
### Status
|
||||
- Fertig: 469 (83%)
|
||||
- In Bearbeitung: 40
|
||||
- Offen: 33
|
||||
- Review: 13
|
||||
- Blocked: 11
|
||||
|
||||
### Top-Themen (aus Labels)
|
||||
| Label | Anzahl | Bedeutung |
|
||||
|-------|--------|-----------|
|
||||
| TTT_offenePunkte | 521 | Fast alle Issues sind offene TTT-Punkte |
|
||||
| TTT_NEP1 | 254 | Netzfahrplan-Erstbestellung — groesstes Thema |
|
||||
| Dokumentation | 206 | Dokumentationsbedarf |
|
||||
| TTT_ujBau | 174 | Umgebungsjahresbau |
|
||||
| Konzernreporting | 159 | Reporting-Anforderungen |
|
||||
| Kundenkommunikation | 139 | Kommunikation mit EVUs |
|
||||
| Liste_FV_Regio | 120 | Fernverkehr/Regio-spezifisch |
|
||||
| TTTneo_offenePunkte | 100 | TTTneo-spezifische Klaerungen |
|
||||
| RTB | 67 | Rahmenvertragsbestellung? |
|
||||
| TTT_Markttest | 66 | Markttests |
|
||||
| TTT_KUNDE | 56 | Kundenspezifische Themen |
|
||||
| DBCargo | 53 | DB Cargo spezifisch |
|
||||
| iRFP | 52 | Internationaler Fahrplan? |
|
||||
| Umsetzung | 52 | Umsetzungsthemen |
|
||||
|
||||
### Erkenntnisse fuer naechste Iteration
|
||||
- **NEP1 (Netzfahrplan-Erstbestellung)** ist abgeschlossen. Aktuell laeuft **NEP2**. Die 254 Issues sind historisch, aber zeigen den Umfang solcher Meilensteine.
|
||||
- **Dokumentation** ist ein grosses Thema (206 Issues) — bestaetigt Problemfeld P2
|
||||
- **Kundenkommunikation** (139) zeigt, dass EVU-Onboarding ein signifikanter Aufwand ist
|
||||
- **Konzernreporting** (159) — Reporting ist ein eigenes grosses Thema
|
||||
- **Kundenspezifische Labels**: DBCargo (53), Transdev (43), DBFernverkehr (40), DBRegio (31) — verschiedene EVUs haben unterschiedliche Anforderungen
|
||||
|
||||
---
|
||||
|
||||
## 2. TTT Intern Board (Board 1487, "TTTI")
|
||||
|
||||
**1000 Issues** — Scrum-Board fuer TTT-interne Arbeit (Test, Integration, Bugs).
|
||||
|
||||
### Status — ALARM!
|
||||
- **Offen: 476 (48%)** — Fast die Haelfte aller Issues ist offen!
|
||||
- Fertig: 442 (44%)
|
||||
- Blocked: 35
|
||||
- In Bearbeitung: 33
|
||||
- Ready for Release: 5
|
||||
|
||||
### Typ-Verteilung
|
||||
| Typ | Anzahl | Anteil |
|
||||
|-----|--------|--------|
|
||||
| Test | 295 | 30% |
|
||||
| Test Execution | 234 | 23% |
|
||||
| Aufgabe | 222 | 22% |
|
||||
| **Bug** | **190** | **19%** |
|
||||
| Story | 27 | 3% |
|
||||
| Test Plan | 19 | 2% |
|
||||
|
||||
### Top-Labels
|
||||
| Label | Anzahl | Bedeutung |
|
||||
|-------|--------|-----------|
|
||||
| SyncJiraOctaneTTT | 99 | Sync mit Octane (ALM-Tool) |
|
||||
| ART_ue_GTests | 67 | ART-uebergreifende Tests |
|
||||
| TTT_NEP1 | 53 | Netzfahrplan |
|
||||
| TTT_NEP1_Trassenanmeldung | 50 | Trassenanmeldung NEP1 |
|
||||
| TTT_ujBau | 50 | Umgebungsjahresbau |
|
||||
| ITU_TTTneo | 47 | TTTneo auf ITU |
|
||||
| KTU_TTTneo | 38 | TTTneo auf KTU |
|
||||
| TTT_Kunde | 36 | Kundentests |
|
||||
| GELV | 30 | Gelegenheitsverkehr |
|
||||
| EVU_SST_TTT | 30 | EVU-Schnittstellen-Tests |
|
||||
| bnetza | 21 | Bundesnetzagentur-relevant |
|
||||
| TTT_MUSS | 21 | Muss-Anforderungen |
|
||||
| FAHRPLAN | 20 | Fahrplan-Integration |
|
||||
|
||||
### Erkenntnisse fuer naechste Iteration
|
||||
- **190 Bugs im TTTI-Board** — das sind uebergreifende Integrations-Bugs zwischen pathOS und TTT-Systemen
|
||||
- **476 offene Issues (48%)** — massiver Rueckstau bei TTT-Integration
|
||||
- **Test-lastig**: 295 Tests + 234 Test Executions = 53% des Boards ist Testing
|
||||
- **SyncJiraOctaneTTT** (99) — es gibt ein paralleles ALM-Tool (Octane) bei TTT, Sync ist ein Thema
|
||||
- **bnetza** (21) — Bundesnetzagentur-relevante Anforderungen werden hier getrackt
|
||||
- **GELV** (30) — Gelegenheitsverkehr hat eigene Test-Issues
|
||||
|
||||
---
|
||||
|
||||
## 3. Zusammenfassung: Was bedeutet das fuer pathOS?
|
||||
|
||||
### Quantitativ
|
||||
| Board | Issues | Offen | Bugs | Hauptthema |
|
||||
|-------|--------|-------|------|-----------|
|
||||
| Team-Boards (7) | 1949 | 564 | 439 | Entwicklung + OPs |
|
||||
| ART-Board (O2CBS) | 330 | 70 | — | Uebergreifend |
|
||||
| Fachliches Board | 566 | 44 | — | Fachliche Klaerungen |
|
||||
| TTTI Board | 1000 | 476 | 190 | TTT-Integration + Test |
|
||||
| **GESAMT** | **3845** | **1154** | **629+** | |
|
||||
|
||||
### Qualitativ
|
||||
1. **TTT-Integration ist der groesste Engpass**: 476 offene TTTI-Issues + 190 Bugs
|
||||
2. **NEP1 ist abgeschlossen, NEP2 laeuft**: 335+ historische NEP1-Issues zeigen den Umfang. NEP2-Fortschritt muss in naechster Iteration geprueft werden.
|
||||
3. **Testing ist ein Riesenthema**: 529 Test/Test-Execution Issues allein im TTTI-Board
|
||||
4. **Kundenkommunikation** braucht eigene Aufmerksamkeit (139 Issues)
|
||||
5. **Reporting** ist ein unterschaetztes Thema (159 + 13 = 172 Issues)
|
||||
@@ -0,0 +1,74 @@
|
||||
# Jira Team-Boards Deep Dive
|
||||
|
||||
> Stand: 2026-04-22 | 1949 Issues ueber 7 Team-Projekte (90 Tage)
|
||||
|
||||
---
|
||||
|
||||
## Gesamtuebersicht
|
||||
|
||||
| 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% |
|
||||
| STeam (ehem.) | O2CSYS | 8 | 5 | 0 | 3 | 0 | 4 | 63% |
|
||||
| **GESAMT** | | **1949** | **1271** | **114** | **564** | **439** | **346** | **65%** |
|
||||
|
||||
## Kritische Erkenntnisse
|
||||
|
||||
### 1. Bug-Explosion bei Team 404 und OPs
|
||||
- **Team 404: 165 Bugs** (33% aller Issues!) — Portal hat massive Qualitaetsprobleme
|
||||
- **OPs: 116 Bugs** (31%) — Infrastruktur-Stabilitaet
|
||||
- Team CIB: 67 Bugs (20%) — moderater Anteil
|
||||
- Team Zero: 64 Bugs (15%) — niedrigster Anteil
|
||||
|
||||
### 2. DevOps ist fast nur Enabler
|
||||
- **O2CDEVOPS: 156 Enabler von 289 Issues (54%)** — reiner technischer Overhead
|
||||
- Nur 27 Bugs, 7 Tasks — kaum fachliche Arbeit
|
||||
- **Jan Lubenow allein: 114 von 289 Issues (39%)** — extreme Personenabhaengigkeit!
|
||||
|
||||
### 3. OPs-Team Verteilung bestaetigt Rotation
|
||||
OPs-Assignees kommen aus allen Teams:
|
||||
- Steven Meixner (Zero): 27 Issues
|
||||
- Hans-Henning Ramberger (CIB): 23 Issues
|
||||
- Jonas Koehler (CIB): 19 Issues
|
||||
- Henrik Scholl (STeam/fest): 19 Issues
|
||||
- Kathrin Schleich (Zero): 12 Issues
|
||||
- Diego Da Costa Souza (404): 10 Issues
|
||||
- Frank Lemke (Zero): 10 Issues
|
||||
→ **Bestaetigt: Rotation aus allen Teams, Henrik Scholl als fester Kern**
|
||||
|
||||
### 4. STeam praktisch aufgeloest
|
||||
- O2CSYS: Nur noch 8 Issues, 3 Personen (Sebastian Goendoer, Michael Jahn, Henrik Scholl)
|
||||
- Arbeit ist nach O2COS und O2CDEVOPS migriert
|
||||
|
||||
### 5. Personenabhaengigkeiten (Top-Contributor pro Team)
|
||||
| Team | Person | Issues | Anteil am Team |
|
||||
|------|--------|--------|---------------|
|
||||
| 404 | Ana Cvitkovic | 78 | 16% |
|
||||
| CIB | Bishara Jaser | 73 | 21% |
|
||||
| Zero | Steven Meixner | 64 | 15% |
|
||||
| OPs | Steven Meixner | 27 | 7% |
|
||||
| DevOps | **Jan Lubenow** | **114** | **39%** |
|
||||
|
||||
→ **Jan Lubenow im DevOps-Board ist ein kritischer Single Point of Failure**
|
||||
|
||||
### 6. Teamgroessen (geschaetzt aus Assignees)
|
||||
| Team | Aktive Assignees | Kern (>10 Issues) |
|
||||
|------|-----------------|-------------------|
|
||||
| Team 404 | 15 | 7 |
|
||||
| Team CIB | 16 | 6 |
|
||||
| Team Zero | 9 | 6 |
|
||||
| OPs Squad | 23 (rotierend) | 7 |
|
||||
| DevOps | 7 | 3 |
|
||||
|
||||
## Offene Punkte fuer naechste Iteration
|
||||
|
||||
1. **TTTI Board** — Uebergreifende Issues zwischen pathOS und TTT-Verbund. Muss analysiert werden.
|
||||
2. **TTTSol Board** — Fachliche Klaerungen. Muss analysiert werden.
|
||||
3. **Support-Board** — Lebt in anderem Jira, wird gerade neu aufgesetzt. Enthaelt Kunden-Issues.
|
||||
4. **Sprint-Velocity** — Kanban-Boards haben keine Sprints (400er Fehler). Muss ueber Agile Hive Plugin geprueft werden.
|
||||
5. **Feature-Count ist 0** — Vermutlich werden Features auf ART-Ebene (O2CBS) getrackt, nicht auf Team-Ebene.
|
||||
@@ -0,0 +1,307 @@
|
||||
# Meilensteinplan pathOS — 12 Monate (Jun 2026 – Mai 2027)
|
||||
|
||||
> Stand: 2026-05-12 | Status: ENTWURF
|
||||
> Vision: pathOS als Kernplattform eines integrierten InfraGO-Bestellportals
|
||||
> Prioritaeten: Stabilitaet → Regulatorik → Kunden-Features
|
||||
> Kapazitaet: ~400 Issues/Monat (alle Teams), ~35 Personen
|
||||
|
||||
---
|
||||
|
||||
## Ueberblick: 4 Phasen
|
||||
|
||||
```
|
||||
Jun 2026 Aug 2026 Dez 2026 Maerz 2027 Mai 2027
|
||||
│ │ │ │ │
|
||||
├─── Phase 1 ────┤─── Phase 2 ────┤─── Phase 3 ────┤─── Phase 4 ────┤
|
||||
│ STABILISIEREN │ NORMALBETRIEB │ SKALIEREN │ INTEGRIEREN │
|
||||
│ │ + REGULATORIK │ + REORG │ + VISION │
|
||||
│ │ │ │ │
|
||||
│ Spring Boot 4 │ SL Silber+ │ FplJ 28 │ Rechnungsbeg. │
|
||||
│ Fuehrungswechsel│ Hypercare Ende │ GelV-Erw. │ TTT Jan 27 │
|
||||
│ Bug-Rate senken │ Abrechnung fix │ Team-Umstellung │ TrassenOrder │
|
||||
│ │ │ abgeschlossen │ Integration │
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Phase 1: STABILISIEREN (Jun – Jul 2026)
|
||||
|
||||
**Ziel**: Technische Schulden abbauen, Hypercare beenden, Fuehrungswechsel vorbereiten
|
||||
|
||||
### Meilenstein M1: Spring Boot 4 abgeschlossen (30. Jun 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| SV, AV, IFP auf Spring Boot 4 | CIB (Saurav, Hans-Henning) | 🔄 In Arbeit |
|
||||
| CI, AV-Trasse auf Spring Boot 4 | Zero (O2CZERO-7043) | 🔄 In Arbeit |
|
||||
| Alle Services auf Java 21 | Alle | Teilweise |
|
||||
| Regressionstests nach Upgrade | QA + Teams | Offen |
|
||||
|
||||
**Risiko**: EOL 3.5 ist Juni 2026 — kein Security-Support mehr danach. MUSS-Termin.
|
||||
|
||||
### Meilenstein M2: Bug-Rate Portal unter 25% (31. Jul 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| Entkopplung Zuglaufpunkte/Zugcharakteristik (Hauptursache) | 404 | Offen |
|
||||
| Fehlermeldungen-Konzept umsetzen | 404 | Offen |
|
||||
| E2E-Tests (Playwright) fuer Top-10-Flows | 404 | Offen |
|
||||
| Testumgebung mit TPN dauerhaft verfuegbar | 404 + OPs | Offen |
|
||||
|
||||
**Kontext**: Bug-Rate 404 liegt bei 33% (steigend). Hauptursache ist die Vererbungslogik Zuglaufpunkte/Zugcharakteristik. Ohne Fix bleibt die Rate hoch.
|
||||
|
||||
### Meilenstein M3: Fuehrungswechsel + Hypercare-Ende (Jul 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| Neue Fuehrung eingesetzt | Management | Offen |
|
||||
| Hypercare-Kriterien definiert und erfuellt | PO + BO | Offen |
|
||||
| Uebergang zu Normalbetrieb dokumentiert | Alle | Offen |
|
||||
| Support-Prozesse definiert (Eskalation, SLAs) | BSSUPPORT + OPs | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Phase 2: NORMALBETRIEB + REGULATORIK (Aug – Nov 2026)
|
||||
|
||||
**Ziel**: Vertragliche Pflichten erfuellen, Abrechnung stabilisieren, Team-Reorg starten
|
||||
|
||||
### Meilenstein M4: Service Level Silber Plus erreicht (31. Aug 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| Netcool-Anbindung produktiv | OPs | 🔄 In Arbeit |
|
||||
| Monitoring-Konzept abgeschlossen | OPs + Zero | 🔄 In Arbeit |
|
||||
| Disaster-Recovery-Test 3 bestanden | OPs | 🔄 Validierung |
|
||||
| Deployment-Automatisierung (Smoketests) | OPs/DevOps | 🔄 In Arbeit |
|
||||
| Secret-Rotation implementiert | OPs | Offen |
|
||||
| Kubernetes-Namespaces umgestellt | OPs | 🔄 In Arbeit |
|
||||
|
||||
**Risiko**: Vertragsverletzung bei Versaeumnis. Keine Verhandlungsmasse.
|
||||
|
||||
### Meilenstein M5: Abrechnung TTT produktionsreif (31. Okt 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| 20h-Zug Abrechnung (TTTSOL-2149) entblockt + geloest | CIB | ❌ Blocked |
|
||||
| Zugtrasse mit Umleitung ohne VT-Wechsel (TTTSOL-2147) | CIB | Offen |
|
||||
| Abrechnung fremde Infrastruktur (TTTSOL-2148) | CIB | Offen |
|
||||
| Neue Zugnummer Umleitungsfall (TTTSOL-2035) | CIB | 🔄 In Arbeit |
|
||||
| VDV-Erweiterung fuer AC Trasse (strategisch) | CIB + Zero | Offen |
|
||||
| Vertragskorrektur rueckwirkend (TTTSOL-1956) | CIB | 🔄 In Arbeit |
|
||||
| Alle 41 Abrechnungs-Tickets priorisiert und geplant | CIB PO | Offen |
|
||||
|
||||
**Kontext**: Rechnungsbeginn TTT ist Januar 2027. Bis Oktober muessen die kritischen Faelle geloest und getestet sein. November/Dezember ist Buffer fuer Regressionstests.
|
||||
|
||||
### Meilenstein M6: NAÄ implizite Annahme produktiv (30. Sep 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| O2CCIB-6931 assigned und implementiert | CIB | ⚠️ Geschoben |
|
||||
| Prozess-Design mit Fachbereich abgestimmt | CIB BA | Offen |
|
||||
| E2E-Test NAÄ-Szenario | CIB + 404 | Offen |
|
||||
|
||||
**Kontext**: Kundenversprechen. Wurde bereits auf PI 41 geschoben. Darf nicht nochmal rutschen.
|
||||
|
||||
### Meilenstein M7: Team-Reorg Phase 1 — OpsDev-Team formiert (30. Sep 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| OpsDev-Team definiert (~6 Personen) | Management + Leads | Offen |
|
||||
| OpsDev-Lead benannt | Management | Offen |
|
||||
| Jan Lubenow Wissenstransfer an David + Henrik (50% abgeschlossen) | DevOps | ⚠️ Kritisch |
|
||||
| Bug-Triage-Prozess definiert (OpsDev → fachliche Teams) | OpsDev-Lead | Offen |
|
||||
| OPs-Rotation beendet (feste Zuordnung) | Management | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Phase 3: SKALIEREN + REORG (Dez 2026 – Feb 2027)
|
||||
|
||||
**Ziel**: Fahrplanwechsel absichern, Team-Umstellung abschliessen, Plattform-Denken etablieren
|
||||
|
||||
### Meilenstein M8: Fahrplanwechsel FplJ 28 erfolgreich (Dez 2026)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| GelV-Erweiterungen (TTT-Meilenstein) | CIB + Zero | Offen |
|
||||
| OTN-Vergabe Fpl 2027 (TTTSOL-1683) | CIB | 🔄 In Arbeit |
|
||||
| ujBau Funktionalitaet | Alle | 🔄 In Arbeit |
|
||||
| FplJ-28-spezifische Validierungen getestet | QA | Offen |
|
||||
| Daten-Partitionierung (Performance bei wachsenden Daten) | CIB/Zero | Offen |
|
||||
|
||||
**Risiko**: Fahrplanwechsel ist ein harter externer Termin. Kein Verschieben moeglich.
|
||||
|
||||
### Meilenstein M9: Rechnungsbeginn TTT (Jan 2027)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| Alle kritischen Abrechnungsfaelle geloest (aus M5) | CIB | Abhaengig von M5 |
|
||||
| Rechnungslauf erfolgreich getestet (Staging) | CIB + QA | Offen |
|
||||
| Monitoring fuer Abrechnungsfehler aktiv | OPs/OpsDev | Offen |
|
||||
| Fallback-Prozess bei Abrechnungsfehlern definiert | CIB + BO | Offen |
|
||||
|
||||
### Meilenstein M10: Team-Reorg abgeschlossen (31. Jan 2027)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| 2 fachliche Teams formiert ("Bestellen" + "Verarbeiten") | Management | Offen |
|
||||
| Service-Ownership klar zugeordnet | Team-Leads | Offen |
|
||||
| PO-Struktur definiert (1 PO pro Team oder uebergreifend) | Management | Offen |
|
||||
| Wissenstransfer abgeschlossen (wer kennt welchen Code) | Alle | Offen |
|
||||
| Erste Sprints in neuer Struktur erfolgreich | Teams | Offen |
|
||||
| Metriken definiert (Bug-Rate, Durchlaufzeit, Deployment-Freq.) | BO + Leads | Offen |
|
||||
|
||||
**Hinweis**: Reorg NACH Fahrplanwechsel abschliessen — nicht waehrend des kritischen Zeitraums umbauen.
|
||||
|
||||
---
|
||||
|
||||
## Phase 4: INTEGRIEREN + VISION (Feb – Mai 2027)
|
||||
|
||||
**Ziel**: TrassenOrder-Learnings integrieren, Plattform-Architektur vorbereiten, Kundenzufriedenheit steigern
|
||||
|
||||
### Meilenstein M11: TrassenOrder-Integration definiert (28. Feb 2027)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| TrassenOrder Livegang evaluiert (Q4 2026) | TraPo + BO | Offen |
|
||||
| Abgrenzung pathOS/TrassenOrder dokumentiert | POs + Architektur | Offen |
|
||||
| API-Vertrag zwischen pathOS und TrassenOrder definiert | CIB/Zero + TraPo | Offen |
|
||||
| Entscheidung: GelV bei pathOS oder TraPo? | BO + Management | Offen |
|
||||
| Uebernahme-Szenario TraPo → pathOS-Team bewertet | Management | Offen |
|
||||
|
||||
### Meilenstein M12: Plattform-Architektur-Vision (31. Maerz 2027)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| Architektur-Vision "Integriertes Bestellportal" dokumentiert | Architektur + BO | Offen |
|
||||
| Kernkomponenten als integrierbare Module identifiziert | Architektur | Offen |
|
||||
| Schnittstellen-Strategie (API-First) definiert | Architektur + Teams | Offen |
|
||||
| Roadmap fuer Anlage + Nebenleistungen (naechste 12M) | BO + POs | Offen |
|
||||
| TPN-Abloesung Zeitplan konkretisiert | POs + Kunden | Offen |
|
||||
|
||||
### Meilenstein M13: Kundenzufriedenheit messbar verbessert (Mai 2027)
|
||||
| Was | Wer | Status |
|
||||
|-----|-----|--------|
|
||||
| Bug-Rate Portal unter 15% (von 33%) | 404 / Team "Bestellen" | Offen |
|
||||
| Vorpruefung Portal produktiv (C8) | CIB + 404 | Offen |
|
||||
| Expertenmodus verfuegbar | 404 | Offen |
|
||||
| Uebersichtsseite Vorgaenge live | 404 | Offen |
|
||||
| Kundenfeedback-Loop etabliert (regelmaessig) | PO + UX | Offen |
|
||||
| NPS oder CSAT Baseline gemessen | PO + BO | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Abhaengigkeiten und kritischer Pfad
|
||||
|
||||
```
|
||||
M1 (Spring Boot) ──────────────────────────────────────────────────────────────
|
||||
│
|
||||
▼
|
||||
M2 (Bug-Rate) ─────────────────────────────────── M13 (Kundenzufriedenheit)
|
||||
│
|
||||
▼
|
||||
M3 (Fuehrungswechsel) ──► M7 (OpsDev) ──► M10 (Reorg komplett)
|
||||
│
|
||||
M4 (SL Silber+) ◄── unabhaengig ▼
|
||||
M11 (TrassenOrder)
|
||||
M5 (Abrechnung) ──► M9 (Rechnungsbeginn) │
|
||||
│ ▼
|
||||
▼ M12 (Plattform-Vision)
|
||||
M6 (NAÄ) ◄── unabhaengig
|
||||
M13 (Kundenzufriedenheit)
|
||||
M8 (FplJ 28) ◄── abhaengig von M5, M6
|
||||
```
|
||||
|
||||
### Kritischer Pfad
|
||||
1. **M1 → M4**: Spring Boot 4 muss fertig sein bevor SL Silber+ moeglich ist (Security-Compliance)
|
||||
2. **M5 → M9**: Abrechnung muss bis Oktober stehen fuer Rechnungsbeginn Januar
|
||||
3. **M3 → M7 → M10**: Fuehrungswechsel ermoeglicht Reorg, Reorg nach Fahrplanwechsel abschliessen
|
||||
4. **M8**: Fahrplanwechsel ist externer Fixpunkt — alles andere muss drumherum geplant werden
|
||||
|
||||
---
|
||||
|
||||
## Risiko-Matrix
|
||||
|
||||
| Risiko | Wahrscheinlichkeit | Impact | Mitigation |
|
||||
|--------|-------------------|--------|------------|
|
||||
| Spring Boot 4 nicht rechtzeitig fertig | Niedrig (laeuft) | KRITISCH | Fokus, keine Ablenkung |
|
||||
| Abrechnung bleibt blocked (20h-Zug) | HOCH | KRITISCH | Eskalation an TTT-Programm, Workaround |
|
||||
| SL Silber+ Deadline gerissen | Mittel | HOCH | Frueh mit UKA abstimmen, Teilabnahme? |
|
||||
| Reorg destabilisiert Teams | Mittel | HOCH | Sukzessiv, nicht Big Bang. Nach FplJ. |
|
||||
| TrassenOrder scheitert/pivotiert | Mittel | MITTEL | pathOS bleibt autark, GelV intern weiter |
|
||||
| Jan Lubenow faellt aus (SPOF) | Niedrig | KRITISCH | Wissenstransfer ab sofort priorisieren |
|
||||
| Bug-Rate 404 steigt weiter | HOCH | HOCH | Entkopplung Zuglaufpunkte priorisieren |
|
||||
| Fahrplanwechsel-Probleme | Niedrig | KRITISCH | Fruehe Tests, Staging-Validierung |
|
||||
|
||||
---
|
||||
|
||||
## Kapazitaetsplanung (grob)
|
||||
|
||||
### Phase 1 (Jun-Jul): ~800 Issues Kapazitaet
|
||||
| Fokus | Anteil | Issues |
|
||||
|-------|--------|--------|
|
||||
| Stabilitaet (Bugs, Spring Boot) | 50% | ~400 |
|
||||
| Regulatorik (NAÄ, Abrechnung) | 30% | ~240 |
|
||||
| Infrastruktur (SL-Vorbereitung) | 20% | ~160 |
|
||||
|
||||
### Phase 2 (Aug-Nov): ~1600 Issues Kapazitaet
|
||||
| Fokus | Anteil | Issues |
|
||||
|-------|--------|--------|
|
||||
| Regulatorik (Abrechnung, SL, FplJ-Vorb.) | 40% | ~640 |
|
||||
| Stabilitaet (Bug-Rate, Tests) | 25% | ~400 |
|
||||
| Features (NAÄ, Vorpruefung, GelV) | 25% | ~400 |
|
||||
| Reorg-Vorbereitung | 10% | ~160 |
|
||||
|
||||
### Phase 3 (Dez-Feb): ~1200 Issues Kapazitaet
|
||||
| Fokus | Anteil | Issues |
|
||||
|-------|--------|--------|
|
||||
| Fahrplanwechsel + Abrechnung | 40% | ~480 |
|
||||
| Reorg-Durchfuehrung | 20% | ~240 |
|
||||
| Stabilitaet + Bugs | 20% | ~240 |
|
||||
| Features | 20% | ~240 |
|
||||
|
||||
### Phase 4 (Maerz-Mai): ~1200 Issues Kapazitaet
|
||||
| Fokus | Anteil | Issues |
|
||||
|-------|--------|--------|
|
||||
| Kunden-Features | 40% | ~480 |
|
||||
| Plattform-Architektur | 25% | ~300 |
|
||||
| Stabilitaet | 20% | ~240 |
|
||||
| TrassenOrder-Integration | 15% | ~180 |
|
||||
|
||||
---
|
||||
|
||||
## Zusammenhang mit Team-Reorganisation
|
||||
|
||||
### Zeitplan Reorg (sukzessiv)
|
||||
|
||||
| Zeitraum | Schritt | Risiko |
|
||||
|----------|---------|--------|
|
||||
| **Jul 2026** | Fuehrungswechsel, Vision kommunizieren | Niedrig |
|
||||
| **Aug-Sep 2026** | OpsDev-Team formieren (aus OPs + DevOps-Teilen) | Mittel |
|
||||
| **Okt 2026** | OPs-Rotation beenden, feste Zuordnung | Niedrig |
|
||||
| **Nov 2026** | Fachliche Teams vorbereiten (Service-Mapping, Wissenstransfer) | Mittel |
|
||||
| **Jan 2027** | Umstellung auf 2 fachliche Teams ("Bestellen" + "Verarbeiten") | Hoch |
|
||||
| **Feb 2027** | Erste Sprints in neuer Struktur, Nachjustierung | Mittel |
|
||||
| **Maerz 2027** | TrassenOrder-Team-Integration bewerten | Mittel |
|
||||
|
||||
### Warum NACH dem Fahrplanwechsel?
|
||||
- Fahrplanwechsel (Dez 2026) ist der riskanteste externe Termin
|
||||
- Teams muessen in bekannter Struktur arbeiten wenn es kritisch wird
|
||||
- Reorg waehrend Hochlast = Produktivitaetsverlust + Risiko
|
||||
- Januar ist traditionell ruhiger (nach FplJ-Wechsel) — guter Zeitpunkt fuer Umstellung
|
||||
|
||||
---
|
||||
|
||||
## Offene Entscheidungen (mit BO/Management zu klaeren)
|
||||
|
||||
| # | Entscheidung | Deadline | Wer entscheidet |
|
||||
|---|-------------|----------|-----------------|
|
||||
| 1 | Wer wird neue Fuehrung? | Jun 2026 | Management |
|
||||
| 2 | OpsDev-Lead: Intern oder extern? | Jul 2026 | Management |
|
||||
| 3 | SV-Monolith: Aufteilen oder einem Team zuordnen? | Okt 2026 | Architektur + BO |
|
||||
| 4 | PO-Struktur: 1 pro Team oder uebergreifend? | Nov 2026 | BO |
|
||||
| 5 | TrassenOrder: Eigenes Team oder Integration in pathOS? | Feb 2027 | BO + Management |
|
||||
| 6 | GelV-Ownership: pathOS oder TraPo? | Feb 2027 | BO |
|
||||
| 7 | Naechste Domaene nach Trasse (Anlage? Nebenleistungen?) | Maerz 2027 | BO + Strategie |
|
||||
|
||||
---
|
||||
|
||||
## Metriken zur Erfolgsmessung
|
||||
|
||||
| Metrik | Baseline (Mai 2026) | Ziel M6 (Sep 2026) | Ziel M10 (Jan 2027) | Ziel M13 (Mai 2027) |
|
||||
|--------|---------------------|---------------------|----------------------|---------------------|
|
||||
| Bug-Rate Portal | 33% | 25% | 20% | <15% |
|
||||
| Bug-Rate Gesamt | 20% | 18% | 15% | <12% |
|
||||
| Deployment-Frequenz | ? (messen!) | 1x/Woche | 2x/Woche | Taeglich moeglich |
|
||||
| Mean Time to Recovery | ? (messen!) | <4h | <2h | <1h |
|
||||
| Offene Highest-Tickets | 8+ | <5 | <3 | 0 |
|
||||
| SPOF-Index (>30% eines Bereichs) | 2 (Jan, Steven) | 1 | 0 | 0 |
|
||||
| Kundenzufriedenheit (NPS/CSAT) | Nicht gemessen | Baseline messen | +10 Punkte | +20 Punkte |
|
||||
|
||||
@@ -0,0 +1,298 @@
|
||||
# Personal- und Bug-Analyse pathOS
|
||||
|
||||
> Stand: 2026-04-30 | Quellen: Jira (90d + 12M), Rollen-Mapping (BO-Input), Tenure-Daten (176 Personen, 24.7K Issues)
|
||||
|
||||
---
|
||||
|
||||
## 1. Team-Gesundheit im Ueberblick
|
||||
|
||||
| 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+ rotierend | 2 fest | 31% | 27% | Sinkend | BEOBACHTEN |
|
||||
| DevOps | 7 | 3 | 9% | 7% | Stabil | OK (aber SPOF) |
|
||||
|
||||
---
|
||||
|
||||
## 2. Detailanalyse pro Team
|
||||
|
||||
### Team 404 (Portal) — KRITISCH
|
||||
|
||||
**Kernproblem**: 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 — hoechste Bug-Rate |
|
||||
| Diego Da Costa Souza | Frontend Dev | 2021-09 | 41 | mittel | mittel | Spring Boot 4 Portal |
|
||||
| Leon Hoerpel | Dev | 2023-03 | 35 | 71% | mittel | KRITISCH — sehr hohe Bug-Rate |
|
||||
| Dominik Ruecker | Backend Dev | 2021-08 | 31 | mittel | mittel | Veteran (434 Issues gesamt) |
|
||||
| Annette Halbhuber | Lead Dev | 2021-09 | 26 | niedrig | hoch | Stabil, Lead-Funktion |
|
||||
| Simon Reitinger | Dev | 2025-11 | 15 | 0% | 100% | NEU — exzellenter Start |
|
||||
| Marcel Hufgard | PO | 2021-12 | 8 | — | — | Product Owner |
|
||||
| Luca Caracciolo | QA | 2021-09 | 5 | — | — | Wenig aktiv |
|
||||
|
||||
**Analyse**:
|
||||
- Emmanuel (69% Bugs) und Leon (71% Bugs) sind die Hauptverursacher der hohen Bug-Rate
|
||||
- Beide arbeiten im Frontend — das Portal-Frontend hat ein systematisches Qualitaetsproblem
|
||||
- Ana Cvitkovic ist der stabilisierende Faktor (Business Engineer, niedrige Bug-Rate, hoher Output)
|
||||
- Simon Reitinger (seit Nov 2025) zeigt 100% Done-Rate — vielversprechend
|
||||
- Luca Caracciolo (QA) ist wenig aktiv — QA-Kapazitaet moeglicherweise unzureichend
|
||||
|
||||
**Empfehlung**:
|
||||
1. Code-Reviews fuer Emmanuel und Leon verstaerken (Pair Programming mit Annette)
|
||||
2. QA-Kapazitaet erhoehen (Luca aktivieren oder zusaetzliche QA-Ressource)
|
||||
3. Frontend-spezifische Testautomatisierung ausbauen
|
||||
4. Fehlermeldungen-Konzept (PO-Input 404) wuerde Kundenfeedback-Loop verbessern
|
||||
|
||||
### Team CIB (Prozesse/Backend) — ERFOLGSGESCHICHTE
|
||||
|
||||
**Kernaussage**: 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 | Spring Boot 4 SV |
|
||||
| Olaf Becken | Business Engineer | 2024-05 | 5 | — | — | |
|
||||
| Alexander Petioky | Dev | 2021-10 | 1 | — | — | Kaum aktiv |
|
||||
|
||||
**Analyse**:
|
||||
- Bishara + Saurav + Jonas bilden ein starkes Kern-Trio (155 Issues, >93% Done)
|
||||
- Die sinkende Bug-Rate zeigt, dass das Team aus den Go-Live-Problemen gelernt hat
|
||||
- SV hat zwar 2214 SonarQube-Smells, aber die Bug-Rate sinkt trotzdem — Smells != Bugs
|
||||
- Harry Braun arbeitet am Spring Boot 4 Upgrade fuer SV — wichtige Enabler-Arbeit
|
||||
- Alexander Petioky ist praktisch inaktiv (1 Issue in 90 Tagen)
|
||||
|
||||
**Empfehlung**:
|
||||
1. Bishara/Saurav/Jonas als Mentoren fuer andere Teams einsetzen (Best Practices teilen)
|
||||
2. SV-Smells systematisch abbauen (S1192: 976 String-Duplikate) — langfristig
|
||||
3. Alexander Petioky: Rolle klaeren (noch im Team?)
|
||||
|
||||
### Team Zero (TAF/TAP) — STABIL
|
||||
|
||||
**Kernaussage**: Niedrigste Bug-Rate (15%), stabiler Output. Beste SonarQube-Qualitaet (4.2 Smells/1K, 91.8% Coverage).
|
||||
|
||||
| Person | Rolle | Seit | Issues (90d) | Bug-Anteil | Done% | Bewertung |
|
||||
|--------|-------|------|-------------|------------|-------|-----------|
|
||||
| Steven Meixner | Dev | 2022-07 | 64 + 27 OPs | niedrig | hoch | TOP — Allrounder, auch OPs |
|
||||
| Bing Shi | Dev | 2022-04 | 63 | niedrig | hoch | Stark, ACAT-Verwalter |
|
||||
| Frank Lemke | Dev | 2022-12 | 49 | niedrig | hoch | Auch OPs |
|
||||
| Kathrin Schleich | Dev | 2021-09 | 27 | niedrig | hoch | Auch OPs |
|
||||
| Michael Weisberg | Test | 2024-11 | 23 | — | 52% | 52% offen — Engpass? |
|
||||
| Bernd Klebl | PO | 2021-09 | 16 | — | — | Auch OPs |
|
||||
| Norbert Maurer | Dev | 2021-11 | 12 | — | 83% offen | Ausgeschieden? |
|
||||
|
||||
**Analyse**:
|
||||
- Steven Meixner ist der Allrounder (64 Zero + 27 OPs = 91 Issues) — aber auch SPOF-Risiko
|
||||
- Norbert Maurer hat 83% offene Issues und ist "wenig aktiv" — vermutlich ausgeschieden
|
||||
- Michael Weisberg (Test) hat 52% offene Issues — Test-Engpass
|
||||
- Team Zero liefert die beste Code-Qualitaet (SonarQube) — Vorbild fuer andere Teams
|
||||
- 4 von 7 Personen rotieren auch in OPs — hohe Belastung
|
||||
|
||||
**Empfehlung**:
|
||||
1. Norbert Maurer: Status klaeren, offene Issues umverteilen
|
||||
2. Michael Weisberg: Test-Backlog priorisieren, ggf. Unterstuetzung
|
||||
3. Steven Meixner entlasten (OPs-Rotation reduzieren) — SPOF-Risiko
|
||||
4. Best Practices (Code-Qualitaet, Coverage) an andere Teams weitergeben
|
||||
|
||||
### OPs Squad — IM AUFBAU
|
||||
|
||||
**Kernaussage**: Seit PI 39 (ersetzt aufgeloestes STeam). 2 feste + rotierende Mitglieder.
|
||||
|
||||
| Person | Rolle | Herkunft | OPs-Issues (90d) | Bewertung |
|
||||
|--------|-------|----------|-----------------|-----------|
|
||||
| Henrik Scholl | Dev (fest) | STeam | 19 + 10 | Kern-Mitglied |
|
||||
| David Steinkopff | Dev | 404 | 7 + 18 | |
|
||||
| Steven Meixner | Dev (rotierend) | Zero | 27 | Haeufigster Rotator |
|
||||
| Hans-Henning Ramberger | Dev (rotierend) | CIB | 23 | |
|
||||
| Jonas Koehler | Dev (rotierend) | CIB | 19 | |
|
||||
| Kathrin Schleich | Dev (rotierend) | Zero | 12 | |
|
||||
| Frank Lemke | Dev (rotierend) | Zero | 10 | |
|
||||
|
||||
**Analyse**:
|
||||
- Rotation funktioniert, aber Zero stellt die meisten Rotatoren (3 von 5)
|
||||
- Henrik Scholl als einziger fester Kern — zweiter SPOF neben Jan Lubenow
|
||||
- Bug-Rate sinkt (51% Feb → 29% Apr) — Infrastruktur stabilisiert sich
|
||||
|
||||
### DevOps — SPOF-RISIKO
|
||||
|
||||
| Person | Rolle | Seit | Issues (90d) | Anteil | Bewertung |
|
||||
|--------|-------|------|-------------|--------|-----------|
|
||||
| Jan Lubenow | Lead Dev | 2022-09 | 114 | 39% | KRITISCHER SPOF |
|
||||
| David Steinkopff | Dev | 2023-03 | 18 | 6% | |
|
||||
| Christian Prause | Dev | 2025-08 | 7 | 2% | |
|
||||
| Michael Mh Jahn | Dev | 2022-01 | 6 | 2% | Veteran (126 Issues) |
|
||||
| Sebastian Goendoer | Dev | 2023-05 | 3 | 1% | Ehem. STeam, wenig aktiv |
|
||||
| Patrick Lewandowski | Dev | 2025-07 | 6 | 2% | |
|
||||
| Henrik Scholl | Dev | 2024-10 | 10 | 3% | Auch OPs fest |
|
||||
|
||||
**Analyse**:
|
||||
- **Jan Lubenow = 39% aller DevOps-Issues** — kritischster SPOF im gesamten Programm
|
||||
- Wenn Jan ausfaellt, hat das Team ein massives Problem
|
||||
- 44% Enabler-Rate ist erwartet (das ist die Aufgabe des Teams)
|
||||
- Sebastian Goendoer (ehem. STeam) ist kaum noch aktiv (3 Issues)
|
||||
|
||||
**Empfehlung**:
|
||||
1. DRINGEND: Wissenstransfer von Jan Lubenow auf mindestens 2 weitere Personen
|
||||
2. DevOps-Dokumentation (Runbook) beschleunigen
|
||||
3. Automatisierung erhoehen um manuelle DevOps-Arbeit zu reduzieren
|
||||
|
||||
---
|
||||
|
||||
## 3. Uebergreifende Rollen
|
||||
|
||||
| Person | Rolle | Sichtbar in | Seit | Bewertung |
|
||||
|--------|-------|-------------|------|-----------|
|
||||
| Thorsten Volland | Architekt | CIB, QA, DevOps | 2021-08 | Veteran, ADR-Verantwortung |
|
||||
| Roger Zimmermann | Anwendungsmanager | Uebergreifend | 2025-04 | Wenig aktiv (10 Issues) |
|
||||
|
||||
---
|
||||
|
||||
## 4. Tenure-Analyse (Betriebszugehoerigkeit)
|
||||
|
||||
### Veteranen (seit Projektstart 2021)
|
||||
| Person | Team | Seit | Monate | Rolle |
|
||||
|--------|------|------|--------|-------|
|
||||
| Jasmin Keskin | 404 | 2021-08 | 56 | Frontend Dev |
|
||||
| Ana Cvitkovic | 404 | 2021-08 | 56 | Business Engineer |
|
||||
| Emmanuel Kontcheu Tagne | 404 | 2021-08 | 56 | Frontend Dev |
|
||||
| Dominik Ruecker | 404 | 2021-08 | 56 | Backend Dev |
|
||||
| Thorsten Volland | Uebergreifend | 2021-08 | 56 | Architekt |
|
||||
| Diego Da Costa Souza | 404 | 2021-09 | 55 | Frontend Dev |
|
||||
| Annette Halbhuber | 404 | 2021-09 | 55 | Lead Dev |
|
||||
| Luca Caracciolo | 404 | 2021-09 | 55 | QA |
|
||||
| Dong-Won Han | CIB | 2021-09 | 55 | Dev |
|
||||
| Bernd Klebl | Zero | 2021-09 | 55 | PO |
|
||||
| Kathrin Schleich | Zero | 2021-09 | 55 | Dev |
|
||||
| Alexander Petioky | CIB | 2021-10 | 54 | Dev |
|
||||
| Christian Meins | CIB | 2021-10 | 54 | PO |
|
||||
| Norbert Maurer | Zero | 2021-11 | 53 | Dev |
|
||||
| Marcel Hufgard | 404 | 2021-12 | 52 | PO |
|
||||
|
||||
### Mittlere Zugehoerigkeit (2022-2023)
|
||||
| Person | Team | Seit | Monate | Rolle |
|
||||
|--------|------|------|--------|-------|
|
||||
| Saurav Kumar | CIB | 2022-01 | 51 | Dev |
|
||||
| Michael Mh Jahn | DevOps | 2022-01 | 51 | Dev |
|
||||
| Bing Shi | Zero | 2022-04 | 48 | Dev |
|
||||
| Steven Meixner | Zero | 2022-07 | 45 | Dev |
|
||||
| Bishara Jaser | CIB | 2022-08 | 44 | Dev |
|
||||
| Jan Lubenow | DevOps | 2022-09 | 43 | Lead Dev |
|
||||
| Frank Lemke | Zero | 2022-12 | 40 | Dev |
|
||||
| Leon Hoerpel | 404 | 2023-03 | 37 | Dev |
|
||||
| David Steinkopff | 404/DevOps | 2023-03 | 37 | Dev |
|
||||
| Sebastian Goendoer | OPs | 2023-05 | 35 | Dev |
|
||||
| Vasileios Dimitriadis | CIB | 2023-11 | 29 | Dev |
|
||||
|
||||
### Neuere Mitglieder (2024+)
|
||||
| Person | Team | Seit | Monate | Rolle |
|
||||
|--------|------|------|--------|-------|
|
||||
| Jonas Koehler | CIB | 2024-04 | 24 | Dev |
|
||||
| Hans-Henning Ramberger | CIB | 2024-05 | 23 | Dev |
|
||||
| Olaf Becken | CIB | 2024-05 | 23 | Business Engineer |
|
||||
| Henrik Scholl | OPs | 2024-10 | 18 | Dev |
|
||||
| Michael Weisberg | Zero | 2024-11 | 17 | Test |
|
||||
| Roger Zimmermann | Uebergreifend | 2025-04 | 12 | Anwendungsmanager |
|
||||
| Patrick Lewandowski | DevOps | 2025-07 | 9 | Dev |
|
||||
| Christian Prause | DevOps | 2025-08 | 8 | Dev |
|
||||
| Simon Reitinger | 404 | 2025-11 | 5 | Dev |
|
||||
| Harry Braun | CIB | 2025-12 | 4 | Dev |
|
||||
|
||||
### Tenure-Daten vollstaendig
|
||||
Alle relevanten Teammitglieder konnten ueber die Bulk-Abfrage (24.7K Issues) identifiziert werden.
|
||||
|
||||
**Hinweis zu Harry Braun**: Erstes Jira-Ticket erst 2025-12-01 (O2CCIB-7723) — moeglicherweise vorher unter anderem Account aktiv oder erst spaet ins Jira-Projekt aufgenommen. Die Angabe "seit 2023-01" aus frueheren Quellen konnte nicht bestaetigt werden.
|
||||
|
||||
---
|
||||
|
||||
## 5. Korrelation: Tenure vs. Bug-Rate
|
||||
|
||||
### Hypothese: Laengere Zugehoerigkeit = weniger Bugs?
|
||||
|
||||
**Team 404 (widerlegt die Hypothese)**:
|
||||
- Emmanuel (56 Monate, 69% Bugs) — Veteran mit hoechster Bug-Rate!
|
||||
- Jasmin (56 Monate, 42% Bugs) — Veteran mit hoher Bug-Rate
|
||||
- Dominik Ruecker (56 Monate, mittel) — Veteran, moderate Bug-Rate
|
||||
- Leon (37 Monate, 71% Bugs) — Mittlere Zugehoerigkeit, hoechste Bug-Rate
|
||||
- Simon (5 Monate, 0% Bugs) — Neuester Mitarbeiter, beste Quote
|
||||
|
||||
→ Bei Team 404 korreliert Tenure NICHT mit Qualitaet. Das Problem ist systematisch (Frontend-Komplexitaet, fehlende Tests, Portal-Architektur).
|
||||
|
||||
**Team CIB (bestaetigt teilweise)**:
|
||||
- Saurav (51 Monate, 8% Bugs) — Veteran mit exzellenter Quote
|
||||
- Bishara (44 Monate, niedrig) — Erfahren und stabil
|
||||
- Neuere Mitglieder haben hoehere Bug-Raten
|
||||
|
||||
→ Bei CIB hilft Erfahrung, aber das Team hat auch bessere Prozesse (Code-Reviews, Camunda-Expertise).
|
||||
|
||||
**Team Zero (bestaetigt)**:
|
||||
- Alle Veteranen haben niedrige Bug-Raten
|
||||
- Beste SonarQube-Qualitaet korreliert mit stabiler Teamzusammensetzung
|
||||
|
||||
→ Zero zeigt: Stabiles Team + gute Praktiken = niedrige Bug-Rate.
|
||||
|
||||
---
|
||||
|
||||
## 6. Risiko-Matrix Personal
|
||||
|
||||
### KRITISCH (sofort handeln)
|
||||
| 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 |
|
||||
|
||||
### HOCH (kurzfristig)
|
||||
| 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, Unterstuetzung |
|
||||
| Inaktive Mitglieder | Norbert Maurer, Alexander Petioky | Offene Issues, Wissen | Status klaeren, Issues umverteilen |
|
||||
|
||||
### MITTEL (mittelfristig)
|
||||
| Risiko | Person(en) | Impact | Massnahme |
|
||||
|--------|-----------|--------|-----------|
|
||||
| OPs-Rotation belastet Zero | 4 Zero-Mitglieder rotieren | Zero-Kapazitaet | Rotation gleichmaessiger verteilen |
|
||||
| Wenig CIB-Rotatoren in OPs | Nur 2 CIB-Mitglieder | OPs-Wissensbreite | Mehr CIB-Beteiligung |
|
||||
| Henrik Scholl allein fest in OPs | Einziger fester Kern | OPs-Kontinuitaet | Zweiten festen Kern aufbauen |
|
||||
|
||||
---
|
||||
|
||||
## 8. Methodische Hinweise
|
||||
|
||||
### Bug-Rate in Abschnitt 2 (Team-Tabellen)
|
||||
Die Bug-Raten in den Team-Tabellen (z.B. "Emmanuel 69%") basieren auf dem **Anteil der Bug-Tickets an den zugewiesenen Issues** einer Person in den letzten 90 Tagen. Das ist eine direkte Messung: Wie viel Prozent der Arbeit einer Person besteht aus Bug-Fixes vs. Features/Aufgaben.
|
||||
|
||||
### Bug-Causation-Daten (CSV-Dateien)
|
||||
Die separaten Causation-CSVs (`O2C404-causation.csv` etc.) verwenden eine andere Methodik: Fuer jeden Bug wird geschaut, welche Entwickler in den 14 Tagen davor ein Feature abgeschlossen haben. Das ergibt **Korrelation, nicht Kausalitaet**:
|
||||
- Ein Bug wird mit ALLEN Entwicklern korreliert, die zeitnah Features lieferten
|
||||
- Daher sind "Bug-Raten" >100% moeglich (z.B. 506% bei Jasmin Keskin)
|
||||
- Die Daten zeigen: **Wer viel liefert, korreliert mit vielen Bugs** — das ist trivial
|
||||
- Nuetzlich ist die Daten nur als **relative Gewichtung innerhalb eines Teams**
|
||||
|
||||
**Fazit**: Die Bug-Raten in Abschnitt 2 (direkte Zuordnung) sind aussagekraeftiger als die Causation-Korrelation. Die Causation-Daten bestaetigen lediglich, dass Team 404 insgesamt die meisten Bugs produziert.
|
||||
|
||||
---
|
||||
|
||||
## 9. Zusammenfassung und Handlungsempfehlungen
|
||||
|
||||
### Top 5 Massnahmen (priorisiert)
|
||||
|
||||
1. **Jan Lubenow entlasten** — Wissenstransfer auf David Steinkopff + Henrik Scholl. DevOps-Runbook beschleunigen. Ziel: Kein Einzelner >25% der Issues.
|
||||
|
||||
2. **Portal-Qualitaet steigern (404)** — Code-Reviews fuer Emmanuel/Leon verstaerken. Frontend-Testautomatisierung ausbauen. QA (Luca) aktivieren. Fehlermeldungen-Konzept umsetzen.
|
||||
|
||||
3. **Steven Meixner entlasten** — OPs-Rotation auf CIB/404 ausweiten. Steven soll sich auf Zero-Kernarbeit konzentrieren koennen.
|
||||
|
||||
4. **Inaktive klaeren** — Norbert Maurer (Zero), Alexander Petioky (CIB), Sebastian Goendoer (OPs): Status klaeren, offene Issues umverteilen.
|
||||
|
||||
5. **CIB Best Practices teilen** — Bishara/Saurav/Jonas als Mentoren. Deren Arbeitsweise (93%+ Done, <10% Bugs) als Vorbild fuer 404.
|
||||
@@ -0,0 +1,92 @@
|
||||
# Personen und Rollen — pathOS
|
||||
|
||||
> Stand: 2026-04-24 | Quelle: BO-Input + Runbook + Jira
|
||||
|
||||
## Team 404 (Portal)
|
||||
|
||||
| Person | Rolle | Jira-Issues (90d) | Anmerkung |
|
||||
|--------|-------|-------------------|-----------|
|
||||
| Marcel Hufgard | PO | 8 | Product Owner |
|
||||
| Claudia Mariana Mare | Scrum Master | 1 | |
|
||||
| Ana Cvitkovic | Business Engineer | 78 | Top-Performer, niedrigste Bug-Rate |
|
||||
| Luca Caracciolo | QA | 5 | |
|
||||
| Annette Halbhuber | Lead Dev | 26 | |
|
||||
| Emmanuel Kontcheu Tagne | Frontend Dev | 42 | 69% Bugs |
|
||||
| Diego Da Costa Souza | Frontend Dev | 41 | Spring Boot 4 Portal |
|
||||
| Dominik Ruecker | Backend Dev | 31 | |
|
||||
| Jasmin Keskin | Frontend Dev | 45 | 42% Bugs |
|
||||
| Leon Hoerpel | Dev | 35 | 71% Bugs |
|
||||
| Simon Reitinger | Dev | 15 | 100% Done |
|
||||
|
||||
## Team CIB (Prozesse/Backend)
|
||||
|
||||
| Person | Rolle | Jira-Issues (90d) | Anmerkung |
|
||||
|--------|-------|-------------------|-----------|
|
||||
| Christian Meins | PO | 9 | Product Owner |
|
||||
| Nicole (?) | Scrum Master | — | |
|
||||
| Olaf Becken | Business Engineer | 5 | |
|
||||
| Bishara Jaser | Dev | 73 | Top-Performer, 93% Done |
|
||||
| Saurav Kumar | Dev | 48 | 94% Done, nur 8% Bugs |
|
||||
| Jonas Koehler | Dev | 34 | 100% Done |
|
||||
| Dong-Won Han | Dev | 20 | |
|
||||
| Hans-Henning Ramberger | Dev | 16 | Auch OPs |
|
||||
| Alexander Petioky | Dev | 1 | |
|
||||
| Vasileios Dimitriadis | Dev | 11 | |
|
||||
| Harry Braun | Dev | 5 | Spring Boot 4 SV |
|
||||
| Jun Tao | Test | 1 | |
|
||||
| Martin Schnell | Test | 2 | |
|
||||
|
||||
## Team Zero (TAF/TAP)
|
||||
|
||||
| Person | Rolle | Jira-Issues (90d) | Anmerkung |
|
||||
|--------|-------|-------------------|-----------|
|
||||
| Bernd Klebl | PO | 16 | Auch OPs |
|
||||
| Bianca Pretor | Scrum Master | 1 | |
|
||||
| Steven Meixner | Dev | 64 + 27 OPs | Allrounder, auch OPs |
|
||||
| Bing Shi | Dev | 63 | ACAT-Verwalter |
|
||||
| Frank Lemke | Dev | 49 | Auch OPs |
|
||||
| Kathrin Schleich | Dev | 27 | Auch OPs |
|
||||
| Norbert Maurer [X] | Dev | 12 | 83% offen — ausgeschieden? |
|
||||
| Michael Weisberg | Test | 23 | 52% offen |
|
||||
| Aleksandr Kil | Dev | — | |
|
||||
|
||||
## OPs / DevOps
|
||||
|
||||
| Person | Rolle | Jira-Issues (90d) | Anmerkung |
|
||||
|--------|-------|-------------------|-----------|
|
||||
| Jan Lubenow | Lead Dev (DevOps) | 114 | 39% aller DevOps-Issues — SPOF |
|
||||
| Henrik Scholl | Dev (OPs fest) | 19 + 10 | |
|
||||
| David Steinkopff | Dev | 7 + 18 | |
|
||||
| Sebastian Goendoer | Dev (ehem. STeam) | 3 | ACAT-Verwalter |
|
||||
| Michael Mh Jahn | Dev (ehem. STeam) | 2 + 6 | |
|
||||
| Christian Prause | Dev | 4 + 7 | |
|
||||
| Patrick Lewandowski | Dev | 1 + 6 | |
|
||||
|
||||
## Uebergreifend
|
||||
|
||||
| Person | Rolle | Team | Anmerkung |
|
||||
|--------|-------|------|-----------|
|
||||
| Thorsten Volland | Architekt | Uebergreifend | In CIB, QA, DevOps sichtbar |
|
||||
| Roger Zimmermann | Anwendungsmanager | Uebergreifend | |
|
||||
| Karsten (?) | QA Lead | Uebergreifend | |
|
||||
| Gouada (?) | Test Automation | Uebergreifend | |
|
||||
| Christian (?) | Business Engineer | Uebergreifend | |
|
||||
| Ben (?) | FBF | Betriebsfuehrung | |
|
||||
| Harram (?) | FBF | Betriebsfuehrung | |
|
||||
| Korbinian (?) | Scrum Master | ? | |
|
||||
|
||||
## Rollen-Verteilung Zusammenfassung
|
||||
|
||||
| Rolle | Anzahl | Personen |
|
||||
|-------|--------|----------|
|
||||
| PO | 3 | Marcel (404), Christian (CIB), Bernd (Zero) |
|
||||
| Scrum Master | 3+ | Claudia (404), Nicole (CIB), Bianca (Zero), Korbinian (?) |
|
||||
| Business Engineer | 3 | Ana (404), Olaf (CIB), Christian (uebergreifend) |
|
||||
| Lead Dev | 2 | Annette (404), Jan (DevOps) |
|
||||
| Architekt | 1 | Thorsten Volland |
|
||||
| Dev (Frontend) | 3 | Emmanuel, Diego, Jasmin (alle 404) |
|
||||
| Dev (Backend) | ~15 | Dominik, Bishara, Saurav, Jonas, etc. |
|
||||
| QA/Test | 5+ | Luca (404), Jun (CIB), Martin (CIB), Michael W (Zero), Gouada |
|
||||
| QA Lead | 1 | Karsten |
|
||||
| FBF | 2 | Ben, Harram |
|
||||
| Anwendungsmanager | 1 | Roger |
|
||||
@@ -0,0 +1,170 @@
|
||||
# PO-Roadmap-Input — Konsolidierung
|
||||
|
||||
> Stand: 2026-04-24 | Quelle: Direkte PO-Rueckmeldungen (CIB, Zero, 404)
|
||||
|
||||
---
|
||||
|
||||
## Team CIB (PO-Input)
|
||||
|
||||
### Laufend / Kurzfristig
|
||||
| Thema | Details | Prioritaet | Abhaengigkeit |
|
||||
|-------|---------|-----------|--------------|
|
||||
| **Camunda Updates** | Nach 8.8 kommt 8.9, 8.10 usw. Weniger Aufwand als 8.8, aber Support-Zeitraeume beachten. Gilt fuer alle Frameworks. | Laufend | — |
|
||||
| **Click&Ride** | SUBP arbeitet bereits an Teilen. Naechstes PI: Was fehlt noch, wer macht es? | Kurzfristig | ADR-72, SUBP |
|
||||
| **Aenderungswesen finalisieren** | Parallele Aenderungsbestellungen auf ueberschneidende Verkehrstage validieren. Mit Fahrplan abgestimmt, zeitlich noch nicht umgesetzt. | Kurzfristig | Fahrplan |
|
||||
| **Vorpruefung Portal** | Button "Vorpruefung" im Portal: Bestellung durchlaeuft PMW+SV+BEP Validierung VOR Absenden. Kunde bekommt Rueckmeldung in Sekunden. Verhindert "Haengenbleiben in Systemkette". | Kurzfristig | 404 (Portal), BEP |
|
||||
| **Monitoring & Alerting** | Systemzustandspruefung soll kein Dauerzustand sein. Henrik verantwortlich. | Kurzfristig | OPs/Henrik |
|
||||
| **Abrechnung** | Unklar: Erst pathOS-Anbindung geplant, dann eingestampft (GFD-Z als Quelle), jetzt doch Daten von pathOS noetig. Potenzial fuer groesseren Aufwand. | Unklar | AC Trasse, GFD-Z |
|
||||
|
||||
### Nachgeliefert nach Go-Live ("reichen wir nach")
|
||||
| Thema | Details | Groesse |
|
||||
|-------|---------|---------|
|
||||
| **RouteUpdate-Prozess** | Noch nicht implementiert | Gross |
|
||||
| **§22 ERegG** | Eintritt Drittunternehmen in bestehenden Vertrag | Mittel |
|
||||
| **Leistungsverweigerung** | Durchsetzung einer Leistungsverweigerung | Mittel |
|
||||
|
||||
### Technische/Fachliche Schulden
|
||||
| Thema | Details |
|
||||
|-------|---------|
|
||||
| Security Requirements | Enabler-Parkplatz |
|
||||
| Fachliche Workarounds | z.B. Mehrfach-Beanstandung: Nur erste wird an TPN weitergeleitet, Rest landet im "Papierkorb" |
|
||||
| **Rahmenvertraege aufraeumen** | RV wird in anderem System abgebildet. Prozesse und Tests ausbauen → reduziert Pflegeaufwand und Pipeline-Laufzeiten |
|
||||
|
||||
---
|
||||
|
||||
## Team Zero (PO-Input)
|
||||
|
||||
### Immer (Laufend)
|
||||
- Bug Fix, Support
|
||||
- Lieferungen testen, bauen, dokumentieren (optimieren)
|
||||
- Wartung: Aktualisierung Komponenten (aktuell Spring Boot 4), kleine Anforderungen (z.B. Portal)
|
||||
|
||||
### Kurzfristig
|
||||
| Thema | Details |
|
||||
|-------|---------|
|
||||
| Neue Mitarbeiter aufgleisen | Onboarding |
|
||||
| Ausgleichszeit | — |
|
||||
| **Workarounds TTK aufraeumen** | Technische Schuld |
|
||||
| **Performance Optimierung AV** | Auftrags-Verwaltung |
|
||||
| **Verschluesselung einschalten** | Security |
|
||||
|
||||
### Mittelfristig
|
||||
| Thema | Details | Groesse |
|
||||
|-------|---------|---------|
|
||||
| **Monitoring** | Grafana Boards wieder nutzbar, Logs anpassen | Mittel |
|
||||
| **Runbook** | Aktualisieren | Mittel |
|
||||
| **PCS aufraeumen + Rueckweg** | Gestaltung Rueckweg | Gross |
|
||||
| **Stationsportal Anbindung** | Fertigstellen | Mittel |
|
||||
| **LuP VNP Versand** | Last- und Performance fuer VNP | Mittel |
|
||||
|
||||
### Langfristig
|
||||
| Thema | Details | Groesse |
|
||||
|-------|---------|---------|
|
||||
| **Click&Ride Anbindung** | — | Gross |
|
||||
| **Infrastruktur Revisionen** | Verarbeiten | Mittel |
|
||||
| **CI/TTK Error archivieren** | — | Klein |
|
||||
| **Ersatz Message Routing ID** | z.B. SenderReference, iRFP Anforderungen | Gross |
|
||||
| **TDM aufraeumen** | — | Mittel |
|
||||
| **XSD Version 3.5.2** | Unterstuetzen | Kann gross werden |
|
||||
| **LuP neu** | Komplett neu | Gross |
|
||||
|
||||
---
|
||||
|
||||
## Team 404 (PO-Input)
|
||||
|
||||
### Funktionale Erweiterungen
|
||||
| Thema | Details | Groesse |
|
||||
|-------|---------|---------|
|
||||
| **Uebersichtsseite Vorgaenge** | Zusammengehoerige Vorgaenge gruppiert nach RouteID | Mittel |
|
||||
| **Vorab-Validierung** | BEP-Anbindung vor Absenden, PRM-ID nicht "verbrennen" | Mittel |
|
||||
| **Nutzerfuehrung** | Verkehrsart zu Beginn festlegen (SGV/SPNV), danach nicht aenderbar | Klein |
|
||||
| **Expertenmodus** | Kompakte Maske ohne Hilfestellungen fuer erfahrene Nutzer | Mittel |
|
||||
| **Massenkopie Taktbestellungen** | Mehrere Takte per Massenkopierfunktion | Mittel |
|
||||
| **Benachrichtigungen** | E-Mail bei NAE oder Angebotseingang | Mittel |
|
||||
| **Vorlagen ueberarbeiten** | Fehleranfaellig bei komplexen Vorgaengen, Konzept noetig | Mittel |
|
||||
| **Entkopplung Zuglaufpunkte/Zugcharakteristik** | Vererbungslogik entfernen (viele Fehler) | Gross |
|
||||
| **Vereinfachung Verknuepfungslogik** | Planned/RelatedPlanned IDs einfacher handhaben | Mittel |
|
||||
| **Auslands-/NE-Strecken** | Hilfe beim korrekten Anlegen inkl. Handoverpoints | Mittel |
|
||||
| **Kalenderfunktion** | Kunden tun sich schwer damit | Mittel |
|
||||
| **Fehlermeldungen** | Konzept fuer verstaendliche, benutzerfreundliche Meldungen | Mittel |
|
||||
| **Suchfunktion** | Leistungsfaehige Suche integrieren | Mittel |
|
||||
|
||||
### Qualitaet / Infrastruktur
|
||||
| Thema | Details |
|
||||
|-------|---------|
|
||||
| **TPN-Import optimieren** | Zu komplex, Unterschiede Alt/Neuwelt zu gross. Ansatz: Ausgewaehlte Kunden schicken 10 Vorgaenge als Vorlage. |
|
||||
| **Testumgebung mit TPN** | Dauerhaft verfuegbar fuer User Stories und Bug-Tests |
|
||||
| **Automatisierte Tests ausbauen** | Deutlich erweitern fuer fruehe Fehlererkennung |
|
||||
|
||||
---
|
||||
|
||||
## Abgleich mit bestehender Roadmap
|
||||
|
||||
### Bereits in unserer Roadmap
|
||||
| PO-Thema | Unsere Roadmap-Aktion | Status |
|
||||
|----------|----------------------|--------|
|
||||
| Camunda Updates | A6 (Camunda 8.9) | In Roadmap |
|
||||
| Click&Ride | ADR-72 | In Roadmap |
|
||||
| Monitoring | A7, B7 | In Roadmap |
|
||||
| Abrechnung/VDV | Strategische Notiz | Notiert |
|
||||
| Spring Boot 4 | A1 | Laeuft aktiv |
|
||||
| Performance AV | B4 (Full-Table-Scans) | In Roadmap |
|
||||
|
||||
### NEU aus PO-Input (nicht in Roadmap)
|
||||
| Thema | Team | Prioritaet | Groesse |
|
||||
|-------|------|-----------|---------|
|
||||
| **Vorpruefung Portal** | CIB+404 | HOCH | Mittel |
|
||||
| **Aenderungswesen finalisieren** | CIB | HOCH | Mittel |
|
||||
| **RouteUpdate-Prozess** | CIB | HOCH | Gross |
|
||||
| **§22 ERegG** | CIB | MITTEL | Mittel |
|
||||
| **Rahmenvertraege aufraeumen** | CIB | MITTEL | Klein |
|
||||
| **Mehrfach-Beanstandung Fix** | CIB | MITTEL | Klein |
|
||||
| **Uebersichtsseite Vorgaenge** | 404 | HOCH | Mittel |
|
||||
| **Expertenmodus** | 404 | MITTEL | Mittel |
|
||||
| **Massenkopie Taktbestellungen** | 404 | MITTEL | Mittel |
|
||||
| **Benachrichtigungen (E-Mail)** | 404 | MITTEL | Mittel |
|
||||
| **Entkopplung Zuglaufpunkte** | 404 | HOCH | Gross |
|
||||
| **Fehlermeldungen-Konzept** | 404 | HOCH | Mittel |
|
||||
| **Suchfunktion** | 404 | MITTEL | Mittel |
|
||||
| **PCS aufraeumen + Rueckweg** | Zero | MITTEL | Gross |
|
||||
| **Ersatz Message Routing ID** | Zero | LANGFRISTIG | Gross |
|
||||
| **XSD 3.5.2** | Zero | LANGFRISTIG | Gross? |
|
||||
| **LuP neu** | Zero | LANGFRISTIG | Gross |
|
||||
| **Testumgebung mit TPN** | 404 | HOCH | Mittel |
|
||||
| **Automatisierte Tests ausbauen** | 404 | HOCH | Laufend |
|
||||
|
||||
---
|
||||
|
||||
## Business Owner Sicht (BO-Input)
|
||||
|
||||
### Uebergreifende Fragestellungen
|
||||
|
||||
| # | Frage | Kontext |
|
||||
|---|-------|---------|
|
||||
| 1 | **Was fehlt im Support?** Was brauchen wir vom Support und was brauchen wir fuer den Support? | Support-Board wird neu aufgesetzt, BSSUPPORT-Team existiert |
|
||||
| 2 | **Monitoring fuer OPs Squad** — Wo steht das Monitoring und was fehlt noch? | Henrik verantwortlich, Grafana Boards teilweise nicht nutzbar (Zero-Input) |
|
||||
| 3 | **Axt schaerfen** — Was machen wir um die Entwicklungseffizienz zu steigern? | Bug-Rate 404 bei 33%, 2214 Smells in SV, Pipeline-Komplexitaet |
|
||||
| 4 | **Enablement-Features** — Welche konkreten Features brauchen Support und OPs Squad? | Fehlermeldungen-Konzept (404), Monitoring-Dashboards (Zero/OPs) |
|
||||
| 5 | **Organisatorische Regeln** — Was brauchen wir an Regeln fuer Support und Squad? | Rollierendes Deployment seit 06/2025, DevOps-Wissen im Aufbau |
|
||||
| 6 | **Fachlichkeit beschleunigen** — Bsp: NEP1 Anzeige-Bug. Wie kriegen wir fachliches Verstaendnis schneller und besser ins Produkt? | 165 Portal-Bugs, Kundenfeedback-Loop |
|
||||
|
||||
### Abgeleitete Handlungsfelder
|
||||
|
||||
| Handlungsfeld | Beschreibung | Betroffene Teams | Prioritaet |
|
||||
|--------------|-------------|-----------------|-----------|
|
||||
| **Support-Enablement** | Definieren was Support braucht (Tools, Zugang, Wissen, Prozesse) und was Support liefern muss (SLAs, Eskalation, Feedback-Loop) | BSSUPPORT, OPs, alle | HOCH |
|
||||
| **Monitoring-Luecken schliessen** | Grafana Boards nutzbar machen, Alerting ausbauen, Netcool-Anbindung | OPs, Zero | HOCH |
|
||||
| **Entwicklungseffizienz** | Smells reduzieren, Tests ausbauen, Pipeline beschleunigen, Rahmenvertraege aufraeumen | Alle | MITTEL |
|
||||
| **Feature-Enablement** | Vorpruefung Portal, Fehlermeldungen, Suchfunktion, Expertenmodus | 404, CIB | MITTEL |
|
||||
| **Organisatorische Regeln** | Deployment-Verantwortung, Support-Prozesse, Eskalationswege, Wissenstransfer | PM/RTE | HOCH |
|
||||
| **Fachlichkeits-Loop** | Wie kommt Kundenfeedback schneller in die Entwicklung? Wie wird fachliches Verstaendnis aufgebaut? | 404, CIB, FbF | HOCH |
|
||||
|
||||
### Zusammenhang mit bestehenden Erkenntnissen
|
||||
|
||||
Die BO-Sicht bestaetigt und verstaerkt mehrere Findings aus unserer Analyse:
|
||||
|
||||
1. **Bug-Rate 404 (33%)** → BO fragt "wie kriegen wir Fachlichkeit beschleunigt" → Fehlermeldungen-Konzept + Vorpruefung wuerden helfen
|
||||
2. **OPs als neues Team** → BO fragt "was braucht das Squad" → Monitoring-Luecken + organisatorische Regeln
|
||||
3. **Support wird neu aufgesetzt** → BO fragt "was fehlt" → Support-Enablement als eigenes Handlungsfeld
|
||||
4. **2214 Smells in SV** → BO fragt "Axt schaerfen" → Technische Schulden systematisch abbauen
|
||||
5. **Deployment-Komplexitaet** → BO fragt "organisatorische Regeln" → Deployment-Automatisierung + Verantwortung
|
||||
@@ -0,0 +1,146 @@
|
||||
# Roadmap-Tabelle — Alle Themen nach Team
|
||||
|
||||
> Stand: 2026-04-30 | Quellen: Technische Roadmap, PO-Input (CIB/Zero/404), BO-Input, Jira (TTTSol), Risiko-Radar
|
||||
|
||||
---
|
||||
|
||||
## Legende
|
||||
|
||||
- **Prio**: MUSS (regulatorisch/vertraglich), HOCH (geschaeftskritisch), MITTEL (wichtig), NIEDRIG (nice-to-have)
|
||||
- **Dauer**: S=Sprint (2W), M=Monat, Q=Quartal, L=Langfristig (>Q)
|
||||
- **Deadline**: Harte Deadline oder "PI xx" fuer weiche Planung
|
||||
|
||||
---
|
||||
|
||||
## Team CIB (Prozesse/Backend)
|
||||
|
||||
| # | Thema | Kurzfassung | Prio | Dauer | Deadline | Status |
|
||||
|---|-------|-------------|------|-------|----------|--------|
|
||||
| C1 | **Implizite Annahme NAÄ** | Kundenversprechen: Standard-Prozess fuer netzausgeloeste Aenderungen. O2CCIB-6931 unassigned, auf naechsten PI geschoben. | MUSS | M | PI 41 | ⚠️ Geschoben |
|
||||
| C2 | **Spring Boot 4 (SV, AV, IFP)** | EOL 3.5 Juni 2026. SV-Branch aktiv (Saurav), Archivierung (Hans-Henning), IFP in Arbeit. | MUSS | M | **Jun 2026** | 🔄 In Arbeit |
|
||||
| C3 | **Abrechnung TTT/AC Trasse** | 41 offene Tickets, 8 Highest. Grundrisiko: Nicht korrekt abrechnen koennen. Taskforce aktiv. | MUSS | Q | Laufend | 🔄 Taskforce |
|
||||
| C4 | **20h Zug Abrechnung** | TTTSOL-2149 BLOCKED. Loesung funktioniert nicht. | MUSS | M | PI 41 | ❌ Blocked |
|
||||
| C5 | **Vertragskorrektur rueckwirkend** | TTTSOL-1956 Highest. Konzernreporting. | HOCH | M | PI 41 | 🔄 In Arbeit |
|
||||
| C6 | **NEP2 Funktionalitaet** | Aktueller TTT-Meilenstein. Laeuft stabil. | HOCH | Q | Laufend | 🔄 Stabil |
|
||||
| C7 | **Aenderungswesen finalisieren** | Parallele Aenderungsbestellungen auf ueberschneidende Verkehrstage validieren. | HOCH | M | PI 41 | Offen |
|
||||
| C8 | **Vorpruefung Portal** | Button "Vorpruefung": Bestellung durchlaeuft Validierung VOR Absenden. Verhindert "Haengenbleiben". | HOCH | M | PI 41/42 | Offen |
|
||||
| C9 | **Click&Ride Anbindung** | ADR-72. SUBP arbeitet an Teilen. Was fehlt noch? | HOCH | Q | PI 41 | Teilweise |
|
||||
| C10 | **Camunda 8.9 Upgrade** | Support-Zeitraeume beachten. Weniger Aufwand als 8.8. | MITTEL | S | PI 41 | Offen |
|
||||
| C11 | **Full-Table-Scans AV** | Performance-Problem in Auftrags-Verwaltung-Trasse. | MITTEL | M | PI 41 | Offen |
|
||||
| C12 | **RouteUpdate-Prozess** | Noch nicht implementiert. Nachlieferung nach Go-Live. | MITTEL | Q | PI 42 | Offen |
|
||||
| C13 | **§22 ERegG** | Eintritt Drittunternehmen in bestehenden Vertrag. Regulatorisch. | MITTEL | M | PI 42 | Offen |
|
||||
| C14 | **Leistungsverweigerung** | Durchsetzung einer Leistungsverweigerung (Stufe 2). | MITTEL | M | PI 42 | Offen |
|
||||
| C15 | **Rahmenvertraege aufraeumen** | Reduziert Pflegeaufwand und Pipeline-Laufzeiten. | NIEDRIG | S | Irgendwann | Offen |
|
||||
| C16 | **Mehrfach-Beanstandung Fix** | Nur erste wird an TPN weitergeleitet, Rest im "Papierkorb". | NIEDRIG | S | Irgendwann | Offen |
|
||||
| C17 | **SV-Smells abbauen** | 2214 Smells, Top S1192 (976 String-Duplikate). Sprint-weise. | NIEDRIG | L | Laufend | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Team 404 (Portal)
|
||||
|
||||
| # | Thema | Kurzfassung | Prio | Dauer | Deadline | Status |
|
||||
|---|-------|-------------|------|-------|----------|--------|
|
||||
| P1 | **Portal-Bug-Rate senken** | 33% Bug-Rate, steigend. Emmanuel 69%, Leon 71%. Systematisches Frontend-Problem. | HOCH | L | Laufend | ⚠️ Kritisch |
|
||||
| P2 | **Entkopplung Zuglaufpunkte/Zugcharakteristik** | Vererbungslogik entfernen — Hauptquelle vieler Bugs. | HOCH | Q | PI 41/42 | Offen |
|
||||
| P3 | **Fehlermeldungen-Konzept** | Verstaendliche, benutzerfreundliche Meldungen. BO-Prioritaet. | HOCH | M | PI 41 | Offen |
|
||||
| P4 | **Uebersichtsseite Vorgaenge** | Zusammengehoerige Vorgaenge gruppiert nach RouteID. | HOCH | M | PI 41 | Offen |
|
||||
| P5 | **Automatisierte Tests ausbauen** | E2E-Tests (Playwright/Cypress) statt nur Unit-Tests. Coverage ist gut (84%), Testqualitaet nicht. | HOCH | L | Laufend | Offen |
|
||||
| P6 | **Testumgebung mit TPN** | Dauerhaft verfuegbar fuer User Stories und Bug-Tests. | HOCH | M | PI 41 | Offen |
|
||||
| P7 | **Vorab-Validierung (BEP)** | BEP-Anbindung vor Absenden, PRM-ID nicht "verbrennen". Zusammen mit CIB (C8). | HOCH | M | PI 41/42 | Offen |
|
||||
| P8 | **Benachrichtigungen (E-Mail)** | E-Mail bei NAÄ oder Angebotseingang. Kundenversprechen. | MITTEL | M | PI 42 | Offen |
|
||||
| P9 | **Expertenmodus** | Kompakte Maske ohne Hilfestellungen fuer erfahrene Nutzer. | MITTEL | M | PI 42 | Offen |
|
||||
| P10 | **Massenkopie Taktbestellungen** | Mehrere Takte per Massenkopierfunktion. | MITTEL | M | PI 42 | Offen |
|
||||
| P11 | **Suchfunktion** | Leistungsfaehige Suche integrieren. | MITTEL | M | PI 42 | Offen |
|
||||
| P12 | **Kalenderfunktion verbessern** | Kunden tun sich schwer damit. | MITTEL | S | PI 42 | Offen |
|
||||
| P13 | **Vereinfachung Verknuepfungslogik** | Planned/RelatedPlanned IDs einfacher handhaben. | MITTEL | M | PI 42 | Offen |
|
||||
| P14 | **Vorlagen ueberarbeiten** | Fehleranfaellig bei komplexen Vorgaengen. Konzept noetig. | MITTEL | M | PI 43 | Offen |
|
||||
| P15 | **Auslands-/NE-Strecken** | Hilfe beim korrekten Anlegen inkl. Handoverpoints. | NIEDRIG | M | Irgendwann | Offen |
|
||||
| P16 | **TPN-Import optimieren** | Zu komplex. Ansatz: Ausgewaehlte Kunden schicken 10 Vorgaenge als Vorlage. | NIEDRIG | Q | Irgendwann | Offen |
|
||||
| P17 | **Nutzerfuehrung** | Verkehrsart zu Beginn festlegen (SGV/SPNV). | NIEDRIG | S | Irgendwann | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Team Zero (TAF/TAP Schnittstellen)
|
||||
|
||||
| # | Thema | Kurzfassung | Prio | Dauer | Deadline | Status |
|
||||
|---|-------|-------------|------|-------|----------|--------|
|
||||
| Z1 | **Spring Boot 4 (CI, AV)** | AV-Trasse Test-Branch aktiv (O2CZERO-7043). | MUSS | M | **Jun 2026** | 🔄 In Arbeit |
|
||||
| Z2 | **NEP2 Schnittstellen** | Aktueller TTT-Meilenstein. | HOCH | Q | Laufend | 🔄 Stabil |
|
||||
| Z3 | **Workarounds TTK aufraeumen** | Technische Schuld aus Go-Live. | HOCH | M | PI 41 | Offen |
|
||||
| Z4 | **Performance Optimierung AV** | Auftrags-Verwaltung Performance. | HOCH | M | PI 41 | Offen |
|
||||
| Z5 | **Verschluesselung einschalten** | Security-Anforderung. | HOCH | S | PI 41 | Offen |
|
||||
| Z6 | **Monitoring (Grafana Boards)** | Wieder nutzbar machen, Logs anpassen. | MITTEL | M | PI 41 | Offen |
|
||||
| Z7 | **Stationsportal Anbindung** | Fertigstellen. | MITTEL | M | PI 41/42 | Offen |
|
||||
| Z8 | **LuP VNP Versand** | Last- und Performance fuer VNP. | MITTEL | M | PI 42 | Offen |
|
||||
| Z9 | **PCS aufraeumen + Rueckweg** | Gestaltung Rueckweg. Gross. | MITTEL | Q | PI 42/43 | Offen |
|
||||
| Z10 | **Runbook aktualisieren** | Dokumentation. | NIEDRIG | M | Laufend | Offen |
|
||||
| Z11 | **Click&Ride Anbindung** | Zusammen mit CIB (C9). | NIEDRIG | Q | PI 43+ | Offen |
|
||||
| Z12 | **Infrastruktur Revisionen** | Verarbeiten. | NIEDRIG | M | Irgendwann | Offen |
|
||||
| Z13 | **Ersatz Message Routing ID** | SenderReference, iRFP Anforderungen. Gross. | NIEDRIG | Q | Irgendwann | Offen |
|
||||
| Z14 | **XSD Version 3.5.2** | Unterstuetzen. Kann gross werden. | NIEDRIG | Q | Irgendwann | Offen |
|
||||
| Z15 | **LuP neu** | Komplett neu konzipieren. | NIEDRIG | L | Irgendwann | Offen |
|
||||
| Z16 | **TDM aufraeumen** | Datenmodell bereinigen. | NIEDRIG | M | Irgendwann | Offen |
|
||||
|
||||
---
|
||||
|
||||
## OPs Squad / DevOps (Infrastruktur)
|
||||
|
||||
| # | Thema | Kurzfassung | Prio | Dauer | Deadline | Status |
|
||||
|---|-------|-------------|------|-------|----------|--------|
|
||||
| O1 | **Netcool-Anbindung** | Betriebsueberwachung. UKA-Anforderung. | MUSS | M | PI 40/41 | 🔄 In Arbeit |
|
||||
| O2 | **Monitoring-Konzept abschliessen** | Umsetzung laeuft seit PI 40. | MUSS | M | PI 41 | 🔄 In Arbeit |
|
||||
| O3 | **Service Level Silber Plus** | Vertragliche Verpflichtung ab August 2026. | MUSS | Q | **Aug 2026** | Offen |
|
||||
| O4 | **Disaster-Recovery-Test 3** | SL-Voraussetzung. Validierung. | HOCH | M | PI 40/41 | 🔄 Validierung |
|
||||
| O5 | **Secret-Rotation** | Security-Konzept umsetzen. | HOCH | M | PI 41 | Offen |
|
||||
| O6 | **Deployment-Automatisierung** | Smoketests nach Deployment. Seit 03/2026 in Arbeit. | HOCH | Q | PI 41/42 | 🔄 In Arbeit |
|
||||
| O7 | **Kubernetes-Cluster/Namespaces** | Umstellung. UKA-Anforderung. | HOCH | M | PI 40 | 🔄 In Arbeit |
|
||||
| O8 | **Jan Lubenow entlasten** | SPOF: 39% aller DevOps-Issues. Wissenstransfer auf David + Henrik. | HOCH | L | Laufend | ⚠️ Kritisch |
|
||||
| O9 | **AppMesh-Alternative** | AWS EOL 2026. O2CBS-555. | MITTEL | Q | PI 42 | Offen |
|
||||
| O10 | **Umgebungen konsolidieren** | 17+ Umgebungen reduzieren. | MITTEL | Q | PI 42/43 | Offen |
|
||||
| O11 | **Keycloak-Projekte konsolidieren** | 5+ Repos vereinfachen. | NIEDRIG | M | Irgendwann | Offen |
|
||||
| O12 | **ECR statt Artifactory** | Laufzeit-Artefakte. UKA. | MITTEL | M | PI 41 | Offen |
|
||||
| O13 | **Security-Groups egress** | Netzwerk-Security. | MITTEL | M | PI 41 | Offen |
|
||||
| O14 | **Runbook beschleunigen** | DevOps-Dokumentation. | MITTEL | L | Laufend | 🔄 In Arbeit |
|
||||
|
||||
---
|
||||
|
||||
## Uebergreifend / Programm
|
||||
|
||||
| # | Thema | Kurzfassung | Prio | Dauer | Deadline | Status |
|
||||
|---|-------|-------------|------|-------|----------|--------|
|
||||
| U1 | **Hypercare beenden** | Normalbetrieb herstellen. | HOCH | — | Jul 2026 | Offen |
|
||||
| U2 | **GelV Erweiterungen** | TTT-Meilenstein ab Sep 2026. | HOCH | Q | Sep 2026 | Offen |
|
||||
| U3 | **ujBau Funktionalitaet** | TTT-Meilenstein. | HOCH | Q | Laufend | 🔄 In Arbeit |
|
||||
| U4 | **FplJ 28 Vorbereitung** | Naechster Fahrplanwechsel Dez 2026. | HOCH | Q | Dez 2026 | Offen |
|
||||
| U5 | **DB Cargo Eskalation CIO** | TTTSOL-2186. PCS + gestaffelter VNP. | HOCH | M | PI 41 | 🔄 In Arbeit |
|
||||
| U6 | **OTN-Vergabe Fpl 2027** | TTTSOL-1683. Muss vor Fahrplanwechsel geloest sein. | HOCH | M | Dez 2026 | 🔄 In Arbeit |
|
||||
| U7 | **Ad-hoc Verkehre <1h (FV)** | TTTSOL-1819. BLOCKED. TopThema. | HOCH | M | PI 41 | ❌ Blocked |
|
||||
| U8 | **Mittiger Teilausfall (SEV)** | TTTSOL-1900. Fernverkehr. Taskforce. | HOCH | M | PI 41 | 🔄 In Arbeit |
|
||||
| U9 | **Team-Reorganisation** | Subdomaenen-Schnitt, OPs → Platform Team. | MITTEL | Q | Q1 2027 | Offen |
|
||||
| U10 | **Support-Enablement** | Was braucht Support? Tools, Zugang, Prozesse. | MITTEL | M | PI 42 | Offen |
|
||||
| U11 | **Contract Testing** | Cross-Team Qualitaet. | NIEDRIG | Q | PI 43 | Offen |
|
||||
| U12 | **TPN vollstaendig abloesen** | Parallelbetrieb beenden. | NIEDRIG | L | Q2 2027 | Offen |
|
||||
| U13 | **Daten-Partitionierung** | Performance bei wachsenden Daten (nach Fahrplanjahr). | MITTEL | Q | Dez 2026 | Offen |
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung
|
||||
|
||||
| Team | MUSS | HOCH | MITTEL | NIEDRIG | Gesamt |
|
||||
|------|------|------|--------|---------|--------|
|
||||
| CIB | 4 | 5 | 5 | 3 | 17 |
|
||||
| 404 | 0 | 7 | 7 | 3 | 17 |
|
||||
| Zero | 1 | 4 | 4 | 7 | 16 |
|
||||
| OPs/DevOps | 3 | 5 | 4 | 2 | 14 |
|
||||
| Uebergreifend | 0 | 8 | 3 | 2 | 13 |
|
||||
| **Gesamt** | **8** | **29** | **23** | **17** | **77** |
|
||||
|
||||
### Kritischer Pfad (harte Deadlines)
|
||||
|
||||
| Deadline | Thema | Team | Konsequenz bei Versaeumnis |
|
||||
|----------|-------|------|---------------------------|
|
||||
| **Jun 2026** | Spring Boot 4 | Alle | Kein Security-Support mehr |
|
||||
| **Aug 2026** | SL Silber Plus | OPs | Vertragsverletzung |
|
||||
| **Dez 2026** | FplJ 28 | Alle | Fahrplanwechsel gefaehrdet |
|
||||
| Laufend | Abrechnung TTT | CIB | Falsche Rechnungen an Kunden |
|
||||
| Laufend | NAÄ implizite Annahme | CIB | Kundenversprechen gebrochen |
|
||||
@@ -0,0 +1,127 @@
|
||||
# Roadmap: TTT-Programm und pathOS
|
||||
|
||||
> Stand: 2026-04-23 | pathOS ist seit Dezember 2025 produktiv (FplJ 27)
|
||||
|
||||
---
|
||||
|
||||
## Aktueller Status
|
||||
|
||||
| Fakt | Details |
|
||||
|------|---------|
|
||||
| **Go-Live** | Dezember 2025 (Fahrplanwechsel FplJ 27) |
|
||||
| **Go/No-Go** | September 2025 — positiv entschieden |
|
||||
| **NEP1** | Abgeschlossen (vor Go-Live) |
|
||||
| **Aktuelle Phase** | Verlaengerte Hypercare + NEP2 |
|
||||
| **Produktiv seit** | ~4 Monate |
|
||||
| **Service Level** | DB Silber (seit Maerz 2026), Silber Plus (ab August 2026) |
|
||||
|
||||
---
|
||||
|
||||
## Teil 1: Uebergreifende TTT-Roadmap (April 2026 — Mitte 2027)
|
||||
|
||||
### Was liegt hinter uns
|
||||
- ✅ NEP1 Trassenanmeldung — abgeschlossen
|
||||
- ✅ Go/No-Go Entscheidung — September 2025, positiv
|
||||
- ✅ Go-Live FplJ 27 — Dezember 2025
|
||||
- ✅ Initiale Hypercare — Dezember 2025 bis Maerz 2026
|
||||
- ⏳ Verlaengerte Hypercare — seit Maerz 2026, laeuft noch
|
||||
|
||||
### Was liegt vor uns
|
||||
|
||||
```
|
||||
2026 2027
|
||||
Apr Mai Jun Jul Aug Sep Okt Nov Dez | Jan Feb Mär Apr Mai Jun
|
||||
| | | | | | | | | | | | | | | |
|
||||
JETZT |
|
||||
| |
|
||||
├── Verlaengerte Hypercare ──────────┤ |
|
||||
| | |
|
||||
├── NEP2 Umsetzung ─────────────────────────────────┤ |
|
||||
| | |
|
||||
├── Spring Boot 4 ──────────┤ | |
|
||||
| (EOL Jun) | | |
|
||||
| | | |
|
||||
| ├── SL Silber Plus ───────────────────────────────────────────────────────┤
|
||||
| | (ab Aug 2026) | |
|
||||
| | | |
|
||||
| | ├── GelV Erweiterungen ──────────────────┤
|
||||
| | | | |
|
||||
| | | ├── ujBau ──────────────────────────────────────┤
|
||||
| | | | | |
|
||||
| | | | ├── FplJ 28 Vorbereitung ───┤
|
||||
| | | | | |
|
||||
| | | | | Dez: Fahrplanwechsel 28
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Teil 2: pathOS-Roadmap (April 2026 — Mitte 2027)
|
||||
|
||||
### Phase A: JETZT (April-Juni 2026) — "Stabilisieren + Schulden abbauen"
|
||||
|
||||
pathOS ist produktiv, aber mit technischen Schulden und in verlaengerter Hypercare.
|
||||
|
||||
| # | Aktion | Deadline | Team | Begruendung |
|
||||
|---|--------|----------|------|-------------|
|
||||
| A1 | **Spring Boot 4 Upgrade** | **Juni 2026** (EOL!) | Alle | Kritischste technische Schuld |
|
||||
| A2 | Parent-POM Java 21 + Konsolidierung | Mai 2026 | OPs | Voraussetzung fuer SB4 |
|
||||
| A3 | **NEP2 Funktionalitaet liefern** | Laufend | CIB, Zero | Aktueller TTT-Meilenstein |
|
||||
| A4 | Hypercare-Bugs abarbeiten | Laufend | Alle | Produktionsstabilitaet |
|
||||
| A5 | Monitoring-Konzept abschliessen | Juni 2026 | OPs | Betriebsstabilitaet |
|
||||
| A6 | Netcool-Anbindung | Juni 2026 | OPs | Betriebsueberwachung |
|
||||
| A7 | Portal-Bugs reduzieren (165 Bugs!) | Laufend | 404 | Qualitaet |
|
||||
|
||||
### Phase B: Sommer 2026 (Juli-September) — "Haerten + Erweitern"
|
||||
|
||||
Hypercare beenden, Service Level Silber Plus erreichen, GelV erweitern.
|
||||
|
||||
| # | Aktion | Deadline | Team | Begruendung |
|
||||
|---|--------|----------|------|-------------|
|
||||
| B1 | **Hypercare beenden** | Juli 2026 | Alle | Normalbetrieb herstellen |
|
||||
| B2 | **Service Level Silber Plus** erreichen | **August 2026** | OPs | Vertragliche Verpflichtung |
|
||||
| B3 | Disaster-Recovery-Test 3 | Juli 2026 | OPs | SL-Voraussetzung |
|
||||
| B4 | Secret-Rotation umsetzen | Juli 2026 | OPs | Security |
|
||||
| B5 | Camunda 8.9 Upgrade | Aug 2026 | CIB | Stabilitaet |
|
||||
| B6 | Full-Table-Scans in AV beheben | Aug 2026 | CIB | Performance |
|
||||
| B7 | Deployment-Automatisierung (Smoketests) | Aug 2026 | OPs + alle | Deployment-Engpass |
|
||||
| B8 | **GelV Erweiterungen starten** | Sep 2026 | CIB, 404 | TTT-Meilenstein |
|
||||
| B9 | TTTI-Rueckstau abarbeiten (476 Issues) | Laufend | Alle | Integrationsstabilitaet |
|
||||
| B10 | AppMesh-Alternative | Sep 2026 | OPs/CNP | AWS EOL |
|
||||
|
||||
### Phase C: Herbst 2026 (Oktober-Dezember) — "Skalieren + FplJ 28 vorbereiten"
|
||||
|
||||
Normalbetrieb, Vorbereitung naechster Fahrplanwechsel.
|
||||
|
||||
| # | Aktion | Deadline | Team | Begruendung |
|
||||
|---|--------|----------|------|-------------|
|
||||
| C1 | Daten-Partitionierung nach Fahrplanjahr | Dez 2026 | CIB | Performance bei wachsenden Daten |
|
||||
| C2 | ujBau-Funktionalitaet liefern | Laufend | CIB, Zero | TTT-Meilenstein |
|
||||
| C3 | Umgebungen konsolidieren (17+ reduzieren) | Nov 2026 | OPs | Komplexitaet reduzieren |
|
||||
| C4 | Contract Testing einfuehren | Okt 2026 | Alle | Cross-Team Qualitaet |
|
||||
| C5 | Keycloak-Projekte konsolidieren | Nov 2026 | OPs | 5+ Repos vereinfachen |
|
||||
| C6 | FplJ 28 Vorbereitung | Dez 2026 | Alle | Naechster Fahrplanwechsel |
|
||||
|
||||
### Phase D: Fruehling 2027 (Januar-Juni) — "Weiterentwickeln + Reorganisieren"
|
||||
|
||||
Strategische Verbesserungen, Team-Reorganisation.
|
||||
|
||||
| # | Aktion | Zeitraum | Team | Begruendung |
|
||||
|---|--------|----------|------|-------------|
|
||||
| D1 | **Team-Reorganisation** (Subdomaenen-Schnitt) | Q1 2027 | PM/RTE | Klare Ownership |
|
||||
| D2 | **OPs → Platform Team** | Q1 2027 | PM/RTE | Self-Service statt Bottleneck |
|
||||
| D3 | API-Versionierung formalisieren | Q1 2027 | Alle | Schnittstellenstabilitaet |
|
||||
| D4 | GitLab-Repos restrukturieren | Q1 2027 | OPs | 167 Projekte aufraumen |
|
||||
| D5 | DevOps-Wissen weiter verteilen | Laufend | Alle | Resilienz |
|
||||
| D6 | TPN vollstaendig abloesen | Q2 2027 | Zero, CIB | Parallelbetrieb beenden |
|
||||
| D7 | TTT-Entkopplung (eigene E2E-Tests) | Q2 2027 | Alle | Unabhaengigkeit |
|
||||
|
||||
---
|
||||
|
||||
## Zusammenfassung: Kritischer Pfad ab JETZT
|
||||
|
||||
| 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 Vorbereitung |
|
||||
| **Jan-Jun 2027** | Weiterentwickeln | Team-Reorg, Platform Team, TPN-Abloesung |
|
||||
@@ -0,0 +1,201 @@
|
||||
# Runbook-Analyse — pathOS Architekturdokumentation
|
||||
|
||||
> Quelle: Runbook (arc42-Format), ~346KB, Stand April 2026
|
||||
> Analyse: 2026-04-22
|
||||
|
||||
---
|
||||
|
||||
## 1. Qualitaetsziele (Priorisiert)
|
||||
|
||||
| Prio | Ziel | Beschreibung |
|
||||
|------|------|-------------|
|
||||
| 1 | Diskriminierungsverbot | Gleichbehandlung DB-eigener und externer EVU (Performance, Verfuegbarkeit, Funktionalitaet) |
|
||||
| 2 | 24/7 Verfuegbarkeit | Unternehmenskritische Anwendung (UKA) mit SL1 (Gold), auch ausserhalb Geschaeftszeiten |
|
||||
| 3 | Interoperabilitaet | Kompatibel mit TAF/TAP TSI Standard und RNE Common Interface |
|
||||
| 4 | Mandantenfaehigkeit | Strikte Datentrennung nach Kundennummern |
|
||||
| 5 | Unveraenderbarkeit | Kundenauftraege nachvollziehbar und unveraenderbar |
|
||||
| 6 | Fehlertoleranz | Automatische Reaktion auf HW/SW-Fehler |
|
||||
| 7 | Kapazitaet | Genuegend Kapazitaet fuer Netzfahrplan-Deadlines |
|
||||
| 8 | Ressourcenverbrauch | Effiziente Nutzung, dynamische Skalierung |
|
||||
| 9 | Bedienbarkeit | Effizient fuer Power-User |
|
||||
| 10 | Erlernbarkeit | Leicht fuer Gelegenheitsnutzer |
|
||||
|
||||
## 2. Service Levels
|
||||
|
||||
| Umgebung | Service Level | Verfuegbarkeit | RTO |
|
||||
|----------|--------------|----------------|-----|
|
||||
| Produktion | DB Silber (ab 03/2026), Silber Plus (ab 08/2026) | 99.38% / 99.73% | 6h |
|
||||
| WGK-Ausweich | DB Bronze Plus | 98.90% | 24h |
|
||||
| Sonstige | DB Bronze | 98.75% | 24h |
|
||||
|
||||
## 3. Subdomaenen-Architektur
|
||||
|
||||
Das System ist in 4 Subdomaenen zerlegt:
|
||||
|
||||
### TAF/TAP Schnittstellen (Team Zero)
|
||||
- Common Interface (SOAP/XML, Mutual SSL)
|
||||
- TAF/TAP TDM Konverter
|
||||
- Partnerverwaltung, Zertifikatsverwaltung
|
||||
|
||||
### Bestellportal (Team 404)
|
||||
- Portal UI (Angular)
|
||||
- Portal Middleware (Spring Boot)
|
||||
- Entwuerfe und Vorlagen
|
||||
|
||||
### Prozesse (Team CIB)
|
||||
- Steuerung Vertrieb (Camunda 8, BPMN)
|
||||
- IFP Connector
|
||||
- Archivierungsservice
|
||||
|
||||
### Backend (Team CIB/Zero)
|
||||
- Auftrags-Verwaltung-Trasse
|
||||
- Kundendaten-Bereitstellung
|
||||
- Stammdaten-Bereitstellung
|
||||
- Rabattnummern-Bereitstellung
|
||||
- Vertragsdaten-Verteiler
|
||||
|
||||
## 4. Teams (aus Runbook bestaetigt)
|
||||
|
||||
| Team | Verantwortung | Schwerpunkt |
|
||||
|------|--------------|-------------|
|
||||
| Team Zero | TAF/TAP Schnittstellen, Stammdaten | Common Interface, Stammdaten-Bereitstellung |
|
||||
| Team 404 | Bestellportal | Portal UI, Portal Middleware |
|
||||
| Team CIB | Prozesse, Backend | Steuerung Vertrieb, Auftrags-Verwaltung |
|
||||
| Team STeam | Infrastruktur, DevOps, Security | CI/CD, Deployment, Keycloak, Monitoring |
|
||||
| Team BSSUPPORT | Support | 2nd Level Support |
|
||||
|
||||
## 5. Umgebungslandschaft (17+ Umgebungen!)
|
||||
|
||||
### DEV Stage
|
||||
- BU (Build-Umgebungen) — temporaer, pro MR
|
||||
- EU/BASE-* (Review) — temporaer, pro MR
|
||||
- Demo — dauerhaft, manuelle Tests
|
||||
- BASE-AT (Integrationstest) — temporaer, pro MR
|
||||
- LUP (Last & Performance) — temporaer
|
||||
- IEU (Integrierte Entwicklung) — dauerhaft, auto-deploy bei Master-Merge
|
||||
- SIT (Systemintegration) — dauerhaft, manuelles Deployment
|
||||
- SIT2 — dauerhaft, automatisiert
|
||||
|
||||
### ABN Stage
|
||||
- E2E (TTT-ITU1) — dauerhaft, TTT-abgestimmt
|
||||
- SAT1 (Alarm ITU) — dauerhaft, Hotfix-Tests
|
||||
- SAT2 (Release ITU) — dauerhaft, Feature-Release-Tests
|
||||
- SAT3 — dauerhaft, LuP/Pentest/DRT
|
||||
- ABN1 (TTT-KTU) — dauerhaft, Kundentests mit EVUs
|
||||
- ABN2 (Release ABN) — dauerhaft, TTT-E2E
|
||||
- ABN4 — dauerhaft, Alarm-Patches
|
||||
- ABN8 — dauerhaft, EVU-Integrationstests
|
||||
- PREPROD — dauerhaft, Sondertests mit Fahrplan-IT
|
||||
|
||||
### PROD Stage
|
||||
- PROD — Produktionsumgebung
|
||||
|
||||
**Erkenntnis**: 17+ Umgebungen erklaeren die Deployment-Komplexitaet!
|
||||
|
||||
## 6. Externe Schnittstellen (detailliert)
|
||||
|
||||
| Name | Technologie | Auth | SLA |
|
||||
|------|------------|------|-----|
|
||||
| EVU-Eingang | SOAP/XML | Mutual SSL (RNE-Zertifikate) | SL1 |
|
||||
| EVU-Ausgang | SOAP/XML | Mutual SSL | SL1 |
|
||||
| Portal-App | HTML5/REST | JWT (OIDC) | SL1 |
|
||||
| IM Stammdaten | REST/JSON | JWT, Client-ID/Secret | SL3+ |
|
||||
| Benutzer-Auth | OpenID Connect | Benutzername/Passwort | SL1 |
|
||||
| NuR-Service | REST/JSON | Entra ID Client-Credential | SL3 |
|
||||
| KDV (CRM) | REST/JSON | Basic-Auth | SL3 |
|
||||
| NVN-Tool | REST/JSON | Basic-Auth + JSON Token | SL3 |
|
||||
| TPN Produktionsauftraege | AWS MSK (Kafka) | IAM:Role | SL1 |
|
||||
| TPN Vertriebsauftraege | AWS MSK (Kafka) | IAM:Role | SL1 |
|
||||
| AC Trasse Archiv | REST/JSON | BizHub ClientID/Secret | SL3 |
|
||||
| Stammdaten extern | REST/JSON | Keine Auth | SL1 |
|
||||
| BEP | REST/JSON | BizHub ClientID/Secret | SL3 |
|
||||
| Stationsportal | AWS MSK (Kafka) | IAM:Role | SL1 |
|
||||
| TBV | AWS MSK (Kafka) | IAM:Role | SL1 |
|
||||
|
||||
## 7. Kafka-Topologie
|
||||
|
||||
### Interne Topics (25+)
|
||||
Wichtigste Datenfluesse:
|
||||
- eingangsnachricht: TTK/PMW → SV, Archivierungsservice
|
||||
- versandauftrag: SV → TTK, PMW
|
||||
- versandergebnis: CI/TTK → SV
|
||||
- auftragsverwaltung: SV → AV, TBV-Konverter, Archivierungsservice
|
||||
- produktionsauftrag-to-connector: SV → IFP-Connector
|
||||
- vertriebsauftrag-to-sv: IFP-Connector → SV
|
||||
- process-eingangsnachricht: SV → SV (Camunda)
|
||||
- camunda-events: Camunda Zeebe → SV
|
||||
- vertragsdaten-to-stationsportal: VDV → Stationsportal
|
||||
|
||||
### Kafka-Cluster (12+)
|
||||
- bsz-dev (IEU, SIT, Demo)
|
||||
- bsz-dev-e2e (E2E)
|
||||
- bsz-dev-2 (SIT, SIT2)
|
||||
- bsz-abn-abn1, abn2, sat1, sat2, sat3, abn8, preprod
|
||||
- bsz-prod
|
||||
|
||||
## 8. Datenbank-Architektur
|
||||
|
||||
### Produktions-Setup (3 separate Cluster!)
|
||||
- bsz-prod-production: Alle ausser SV, IFP, AV, PMW (db.m6gd.large, 200GB)
|
||||
- bsz-prod-production-avt: AV + PMW (db.m6gd.large, 200GB)
|
||||
- bsz-prod-production-sv: SV + IFP-Connector (db.m6gd.large, 200GB)
|
||||
|
||||
**Erkenntnis**: DB-Split nach Performance-Anforderungen (SV und AV sind die lastintensivsten)
|
||||
|
||||
### Persistenz-Strategie
|
||||
- Shared-Nothing: Jede Anwendung eigene DB
|
||||
- TAF/TAP-Daten als JSON/XML BLOBs (nicht relationales Modell!)
|
||||
- Flyway fuer Migrationen
|
||||
- Append-Only fuer Kundenauftraege (Unveraenderbarkeit)
|
||||
|
||||
## 9. Sicherheitsarchitektur
|
||||
|
||||
### Authentifizierung
|
||||
- Portal: DB WebSSO (OIDC) via SIPS Access Proxy + NuR
|
||||
- Common Interface: Mutual SSL mit RNE-Zertifikaten
|
||||
- Intern: Keycloak (Test), Entra ID (Prod)
|
||||
- Kafka: AWS IAM Roles
|
||||
- DB: Technische User pro Anwendung (DML only)
|
||||
|
||||
### Verschluesselung
|
||||
- TLS ueberall (ISGW → ALB → App)
|
||||
- Data-at-Rest: AWS-managed Encryption
|
||||
- Secrets: age + sops + Helm Secrets Plugin
|
||||
|
||||
### Mandantentrennung
|
||||
- Basierend auf Kundennummern
|
||||
- Alle Zugriffe gefiltert nach Berechtigungen
|
||||
- Backend-seitige Validierung (Browser nicht vertrauenswuerdig)
|
||||
|
||||
## 10. Bekannte Technische Schulden (aus Runbook)
|
||||
|
||||
| Kategorie | Problem | Massnahme |
|
||||
|-----------|---------|-----------|
|
||||
| TAF/TAP TSI | Veraltete Technologie (SOAP, unvollstaendige Specs) | CI als Adapter |
|
||||
| AppMesh | AWS EOL, CNP arbeitet an Alternative | O2CBS-555 |
|
||||
| CI/CD Pipelines | Zu komplex (pipeship + CNB) | Vereinfachungen |
|
||||
|
||||
## 11. Offene Punkte / Risiken (aus Runbook)
|
||||
|
||||
- Common Interface: SOAP als Altlast, bidirektionale async Kommunikation fragil
|
||||
- Stammdaten: Performance-Probleme beim Strecken-Import (zu viele kleinteilige API-Calls)
|
||||
- Portal-Middleware: Haeufige Schnittstellenaenderungen von SV und AV
|
||||
- Kundendaten/Rabattdaten: Koennen kurzzeitig veraltet sein (akzeptiert)
|
||||
- Performance: Keine systematische Performance-Messung bei mehreren Services
|
||||
- Click&Ride: Anbindungsdetails noch nicht geklaert
|
||||
- BEP: Anbindung noch in Arbeit
|
||||
|
||||
## 12. Architecture Decision Records (75 ADRs!)
|
||||
|
||||
Wichtigste aktive ADRs:
|
||||
- ADR-29: Internes Datenmodell TDM
|
||||
- ADR-35: Zugriffskontrolle interne Schnittstellen
|
||||
- ADR-36: Trennung Build/Deployment Pipelines
|
||||
- ADR-53: Hybride Anbindung Eingangskaenaele
|
||||
- ADR-56: CI an Backend ueber Kafka (In Arbeit)
|
||||
- ADR-58: Deployment und Release
|
||||
- ADR-61: Signieren von Nachrichten
|
||||
- ADR-63: Camunda 8 als Workflow Engine
|
||||
- ADR-70: Weiterentwicklung Testvorgehen (In Arbeit)
|
||||
- ADR-72: Click&Ride Anbindung (In Arbeit)
|
||||
- ADR-74: TrassenPortal Anbindung (In Arbeit)
|
||||
@@ -0,0 +1,142 @@
|
||||
# SonarQube Deep Dive — Code-Qualitaet pro Team
|
||||
|
||||
> Stand: 2026-04-30 | Quelle: SonarQube (74 Projekte, nur master/main Branches)
|
||||
|
||||
---
|
||||
|
||||
## 1. Ueberblick
|
||||
|
||||
| Team | Projekte | Lines of Code | Bugs | Smells | Smells/1K LoC | Coverage | QGate OK |
|
||||
|------|----------|---------------|------|--------|---------------|----------|----------|
|
||||
| **Team 404** | 2 | 68.313 | 5 | 420 | 6.1 | 84.2% | 0/2 |
|
||||
| **Team CIB** | 15 | 121.727 | 7 | 2.535 | 20.8 | 78.2% | 9/15 |
|
||||
| **Team Zero** | 9 | 37.927 | 0 | 152 | 4.0 | 21.8%* | 8/9 |
|
||||
| Shared Libs | 6 | 4.877 | 2 | 50 | 10.3 | 0% | 0/6 |
|
||||
| Andere/Infra | 41 | 28.813 | 13 | 600 | 20.8 | 33.6% | 29/41 |
|
||||
|
||||
*Zero Coverage-Durchschnitt verzerrt durch tadef-connector (27.6K Lines, 0% Coverage). Ohne tadef: 91.8% Coverage.
|
||||
|
||||
---
|
||||
|
||||
## 2. Detailanalyse pro Team
|
||||
|
||||
### Team 404 (Portal) — 68K Lines, 2 Services
|
||||
|
||||
| Service | Lines | Bugs | Smells | Coverage | QGate |
|
||||
|---------|-------|------|--------|----------|-------|
|
||||
| portal-ui (Angular) | 42.726 | 4 | 77 | 85.8% | ERROR |
|
||||
| portal-middleware | 25.587 | 1 | 343 | 81.4% | ERROR |
|
||||
|
||||
**Bewertung**:
|
||||
- Coverage ist gut (84-86%) — das Frontend-Qualitaetsproblem liegt NICHT an fehlenden Tests
|
||||
- Portal-Middleware hat 5x mehr Smells als Portal-UI (343 vs 77) bei halb so viel Code
|
||||
- Beide Services haben Quality Gate ERROR — vermutlich wegen Bugs (4+1=5)
|
||||
- **Kernaussage**: Die hohe Bug-Rate (33% aus Jira) korreliert NICHT mit schlechter Coverage. Das Problem ist eher in der Testqualitaet (was getestet wird) als in der Testquantitaet (wie viel getestet wird).
|
||||
|
||||
**Empfehlung**:
|
||||
- Portal-Middleware Smells reduzieren (343 bei 25K Lines = 13.4/1K — deutlich ueber Durchschnitt)
|
||||
- Bug-Ursachen analysieren: Sind es Regressions-Bugs (Tests fehlen fuer Edge Cases) oder Integrations-Bugs?
|
||||
|
||||
### Team CIB (Backend) — 122K Lines, 15 Services
|
||||
|
||||
| Service | Lines | Bugs | Smells | Coverage | QGate |
|
||||
|---------|-------|------|--------|----------|-------|
|
||||
| steuerung-vertrieb (SV) | 93.146 | 3 | **2.214** | 81.6% | ERROR |
|
||||
| auftrags-verwaltung-trasse | 8.430 | 0 | 102 | 86.2% | OK |
|
||||
| archivierungsservice | 6.733 | 2 | 83 | 78.8% | ERROR |
|
||||
| ifp-mock | 4.917 | 2 | 66 | 50.4% | ERROR |
|
||||
| kundendaten-bereitstellung | 1.834 | 0 | 2 | 96.9% | OK |
|
||||
| rabattnummern-bereitstellung | 1.374 | 0 | 9 | 86.3% | OK |
|
||||
| ifp-connector | 1.318 | 0 | 5 | 84.9% | OK |
|
||||
| auftrag-service-kafkamock | 2.221 | 0 | 35 | 0% | ERROR |
|
||||
| auftrag-service | 949 | 0 | 19 | 0% | ERROR |
|
||||
|
||||
**Bewertung**:
|
||||
- **SV ist das Sorgenkind**: 93K Lines, 2.214 Smells (23.8/1K LoC!) — mit Abstand hoechste technische Schuld
|
||||
- Aber: SV hat 81.6% Coverage und die Bug-Rate sinkt (36% → 9%) — die Smells verursachen keine Bugs
|
||||
- Kleinere Services (KDV, Rabatt, IFP-Connector) sind vorbildlich: >85% Coverage, <10 Smells
|
||||
- AV-Trasse: Gute Qualitaet (86.2% Coverage, 102 Smells bei 8.4K Lines)
|
||||
- 2 Services ohne Coverage (Mocks) — akzeptabel fuer Mock-Services
|
||||
|
||||
**Empfehlung**:
|
||||
- SV-Smells langfristig abbauen (Top-Regel S1192: 976 String-Duplikate — Refactoring-Kandidat)
|
||||
- Archivierungsservice: 2 Bugs fixen, Coverage von 78.8% auf >85% bringen
|
||||
- IFP-Mock: Coverage von 50.4% ist zu niedrig fuer einen Service der in Tests genutzt wird
|
||||
|
||||
### Team Zero (TAF/TAP) — 38K Lines, 9 Services
|
||||
|
||||
| Service | Lines | Bugs | Smells | Coverage | QGate |
|
||||
|---------|-------|------|--------|----------|-------|
|
||||
| tadef-connector | 27.646 | 0 | 99 | **0%** | ERROR |
|
||||
| stammdaten-bereitstellung | 5.042 | 0 | 13 | 82.0% | OK |
|
||||
| common-interface | 4.056 | 0 | 37 | 93.8% | OK |
|
||||
| taftap-tdm-konverter | 6.586 | 0 | 26 | 90.6% | OK |
|
||||
|
||||
**Bewertung**:
|
||||
- **0 Bugs** in allen Zero-Services — beste Qualitaet im Programm
|
||||
- tadef-connector (27.6K Lines, 0% Coverage) ist der einzige Ausreisser — vermutlich generierter Code oder Legacy
|
||||
- Ohne tadef: 4.0 Smells/1K LoC und 91.8% Coverage — Benchmark fuer andere Teams
|
||||
- Common Interface: 93.8% Coverage bei SOAP-Schnittstelle — beeindruckend
|
||||
|
||||
**Empfehlung**:
|
||||
- tadef-connector: Klaeren ob Coverage moeglich/sinnvoll ist (generierter Code?)
|
||||
- Zero als Qualitaets-Benchmark beibehalten und Best Practices dokumentieren
|
||||
|
||||
---
|
||||
|
||||
## 3. Shared Libraries — 0% Coverage
|
||||
|
||||
| Library | Lines | Smells | Coverage |
|
||||
|---------|-------|--------|----------|
|
||||
| core-components-kafka | 1.567 | 24 | 0% |
|
||||
| core-components-common | 1.096 | 5 | 0% |
|
||||
| signature-database | 1.091 | 12 | 0% |
|
||||
| signature-message | 622 | 5 | 0% |
|
||||
|
||||
**Bewertung**:
|
||||
- Alle Shared Libraries haben 0% Coverage — das ist ein Risiko
|
||||
- Diese Libraries werden von ALLEN Services genutzt — ein Bug hier betrifft das gesamte System
|
||||
- Insgesamt nur 4.877 Lines — ueberschaubar
|
||||
|
||||
**Empfehlung**:
|
||||
- DRINGEND: Tests fuer core-components-kafka und core-components-common schreiben
|
||||
- Shared Libraries sollten die hoechste Coverage haben (>90%), nicht die niedrigste
|
||||
|
||||
---
|
||||
|
||||
## 4. Quality Gate Failures — Zusammenfassung
|
||||
|
||||
| Grund | Projekte | Beispiele |
|
||||
|-------|----------|-----------|
|
||||
| Bugs > 0 | 8 | portal-ui (4), SV (3), archivierungsservice (2) |
|
||||
| Coverage = 0% | 12 | tadef-connector, Mocks, Shared Libs, Infra-Tools |
|
||||
| Coverage < Schwelle | 3 | ifp-mock (50.4%), archivierungsservice (78.8%) |
|
||||
|
||||
---
|
||||
|
||||
## 5. Korrelation: SonarQube vs. Jira Bug-Rate
|
||||
|
||||
| Team | SonarQube Bugs | SonarQube Coverage | Jira Bug-Rate (90d) | Korrelation? |
|
||||
|------|----------------|-------------------|---------------------|--------------|
|
||||
| 404 | 5 | 84.2% | 33% (steigend) | NEIN — hohe Coverage, trotzdem viele Bugs |
|
||||
| CIB | 7 | 78.2% | 20% (sinkend) | TEILWEISE — niedrigere Coverage, aber Bug-Rate sinkt |
|
||||
| Zero | 0 | 91.8%* | 15% (stabil) | JA — beste Coverage = wenigste Bugs |
|
||||
|
||||
**Fazit**: Coverage allein erklaert die Bug-Rate nicht. Team 404 hat gute Coverage (84%) aber die hoechste Bug-Rate. Das deutet auf:
|
||||
1. **Testqualitaet** — Tests pruefen nicht die richtigen Szenarien (Edge Cases, Integration)
|
||||
2. **Frontend-Komplexitaet** — Angular-UI hat andere Fehlerquellen als Backend (State Management, Async, Browser-Kompatibilitaet)
|
||||
3. **Fehlende E2E-Tests** — Unit-Tests allein reichen nicht fuer Portal-Qualitaet
|
||||
|
||||
---
|
||||
|
||||
## 6. Top-Empfehlungen (priorisiert)
|
||||
|
||||
1. **Shared Libraries testen** (DRINGEND) — 0% Coverage bei Code der ueberall genutzt wird. Risiko: Ein Bug hier betrifft alle Services.
|
||||
|
||||
2. **SV-Smells systematisch abbauen** — 2.214 Smells, Top-Regel S1192 (976 String-Duplikate). Sprint-weise 50-100 Smells pro PI reduzieren.
|
||||
|
||||
3. **Portal: Testqualitaet statt -quantitaet** — Coverage ist gut (84%). Problem sind fehlende Edge-Case-Tests und E2E-Tests. Empfehlung: Playwright/Cypress fuer kritische User Flows.
|
||||
|
||||
4. **tadef-connector klaeren** — 27.6K Lines ohne Coverage. Ist das generierter Code? Wenn ja: aus SonarQube-Metriken ausschliessen. Wenn nein: Tests schreiben.
|
||||
|
||||
5. **IFP-Mock Coverage erhoehen** — 50.4% ist zu niedrig fuer einen Mock-Service der in Integrationstests genutzt wird.
|
||||
@@ -0,0 +1,56 @@
|
||||
# Strategische Notizen — pathOS
|
||||
|
||||
> Laufende Sammlung von strategischen Entscheidungen und Ueberlegungen aus Gespraechen mit dem Business Owner
|
||||
|
||||
---
|
||||
|
||||
## 2026-04-23: Abrechnung und Vertragsdaten-Verteiler
|
||||
|
||||
**Kontext**: Die Abrechnungsthemen in TTTSol (TTTSOL-2149, -2147, -2148, -2035) sind auch fuer pathOS relevant.
|
||||
|
||||
**Strategische Ueberlegung**:
|
||||
- Der **Vertragsdaten-Verteiler (VDV)** soll moeglicherweise auch fuer die **Abrechnung** genutzt werden (aktuell nur Stationsportal)
|
||||
- Das wuerde den VDV zum zentralen Datenverteiler fuer alle Downstream-Systeme machen
|
||||
- Business Owner hat angeboten, die Abrechnungsthemen mit anzutreiben
|
||||
|
||||
**Implikationen fuer pathOS**:
|
||||
- VDV bekommt erweiterten Scope (nicht nur Stationsportal, auch AC Trasse)
|
||||
- Schnittstelle zu AC Trasse muss moeglicherweise ueberarbeitet werden
|
||||
- Aktuell laeuft Abrechnung ueber Steuerung-Vertrieb direkt an AC (REST) — VDV wuerde das entkoppeln
|
||||
- Kafka-basierte Verteilung (wie bei Stationsportal) waere konsistenter
|
||||
|
||||
**Offene TTTSol-Tickets Abrechnung (Blocked/Highest)**:
|
||||
- TTTSOL-2149: 20h-Zug Prozess in der Abrechnung (Blocked, High)
|
||||
- TTTSOL-2147: Zugtrasse mit Umleitung ohne VT-Wechsel (Highest, Offen)
|
||||
- TTTSOL-2148: Abrechnung der Zugtrasse mit fremder Infrastruktur (Highest, Offen)
|
||||
- TTTSOL-2035: Neue Zugnummer im Umleitungsfall mit VT-Wechsel (Highest, In Bearbeitung)
|
||||
- TTTSOL-1998: Anrechnung Trassenkosten bei zusaetzlichen Leistungen (High, In Bearbeitung)
|
||||
|
||||
**Naechste Schritte**:
|
||||
- [ ] Klaeren: Welche Abrechnungsdaten soll VDV liefern?
|
||||
- [ ] Klaeren: Wie aendert sich die Schnittstelle zu AC Trasse?
|
||||
- [ ] TTTSol-Abrechnungstickets tracken und bei Bedarf eskalieren
|
||||
|
||||
---
|
||||
|
||||
## 2026-04-23: NEP2 Status
|
||||
|
||||
**Fachlicher Kontext**:
|
||||
- NEP2 = Zweite Anmeldephase im Netzfahrplan-Prozess (zwischen NEP1 und VNP)
|
||||
- Fachlich identisch zu NEP1, aber ohne First-Come-First-Serve-Vorteil
|
||||
- Bei Konflikten greift das Koordinierungsverfahren / Streitbeilegung
|
||||
- Last in NEP1 ist deutlich hoeher als in NEP2
|
||||
|
||||
**Status**: Laeuft stabil, wenig neue Bugs. Kein separater Feature-Scope noetig.
|
||||
|
||||
**Bewertung**: NEP2 ist kein Risiko fuer pathOS. Das System hat die hoehere NEP1-Last ueberstanden. Positiver Indikator fuer Produktionsstabilitaet.
|
||||
|
||||
---
|
||||
|
||||
## TODO: Push-Script Optimierung
|
||||
|
||||
- **Problem**: ~15 von 21 Seiten werden bei jedem Push aktualisiert obwohl sich nur der Inhalt nicht geaendert hat
|
||||
- **Ursache 1**: Seiten mit `$(Get-Date)` aendern sich bei jedem Lauf (Datum im HTML)
|
||||
- **Ursache 2**: Confluence normalisiert HTML beim Speichern (Entities, Self-Closing Tags), dadurch schlaegt Textvergleich fehl
|
||||
- **Loesung**: Datum aus dem HTML entfernen (statisch setzen) oder Hash-basierter Vergleich mit Confluence-Labels
|
||||
- **Prioritaet**: Niedrig (funktioniert, nur unnoetige Versionen)
|
||||
@@ -0,0 +1,340 @@
|
||||
# Team-Reorganisation pathOS — Optionen und Bewertung
|
||||
|
||||
> Stand: 2026-04-30 | Status: Entwurf zur Diskussion
|
||||
|
||||
---
|
||||
|
||||
## 1. Ausgangslage
|
||||
|
||||
### Aktuelle Struktur (seit PI 39)
|
||||
| Team | Personen | Verantwortung | Services |
|
||||
|------|----------|---------------|----------|
|
||||
| Team 404 | ~10 | Portal UI + Middleware | 2 Services (68K LoC) |
|
||||
| Team CIB | ~13 | Prozesse, Backend | ~15 Services (122K LoC), Camunda |
|
||||
| Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 Services (38K LoC) |
|
||||
| OPs Squad | 2 fest + rotierend | Infrastruktur, Betrieb | Infra-Repos, Deployment |
|
||||
| DevOps | ~7 | CI/CD, Tooling | Pipelines, Helm, Monitoring |
|
||||
| BSSUPPORT | ? | 2nd Level Support | — |
|
||||
|
||||
### Probleme der aktuellen Struktur
|
||||
1. **SPOF**: Jan Lubenow (39% DevOps), Steven Meixner (Zero + OPs)
|
||||
2. **Ungleiche Last**: CIB hat 15 Services + Camunda + Abrechnung, Zero hat 9 Services aber rotiert staendig in OPs
|
||||
3. **Bug-Qualitaet**: 404 hat 33% Bug-Rate — systematisches Problem, nicht personenbezogen
|
||||
4. **OPs-Rotation belastet Zero**: 3 von 5 Rotatoren kommen aus Zero
|
||||
5. **Abhaengigkeiten**: CIB braucht 404 fuer Portal-Features, Zero braucht CIB fuer Prozess-Aenderungen
|
||||
6. **Kein klarer Feature-Owner**: Wer ist verantwortlich fuer ein Feature das Portal + Backend + Schnittstelle braucht?
|
||||
|
||||
---
|
||||
|
||||
## 2. Ziele der Reorganisation
|
||||
|
||||
### Primaere Ziele
|
||||
- Schnelle Umsetzungsgeschwindigkeit
|
||||
- Weniger Komplexitaet
|
||||
- Weniger Abhaengigkeiten zwischen Teams
|
||||
- Bessere Qualitaet
|
||||
- Bessere Verantwortlichkeit (Ownership)
|
||||
|
||||
### Nachrangige Ziele
|
||||
- Entwickler, BAs, POs, Scrummaster/TeamCoaches staerkenorientiert einsetzen
|
||||
- Wissen breiter verteilen (SPOF abbauen)
|
||||
- Flexibilitaet bei wechselnden Prioritaeten
|
||||
|
||||
---
|
||||
|
||||
## 3. Option A: OpsDev + Feature-Pool
|
||||
|
||||
### Modell
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ OpsDev Team (permanent, ~8-10 Personen) │
|
||||
│ Lead: OpsDev-Lead (kein PO) │
|
||||
│ Aufgaben: Betrieb, Bugs, kleine Features, Monitoring │
|
||||
│ Besetzung: 2 feste Ops + rotierende Devs aus Pool │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ Feature-Pool (~20-25 Personen) │
|
||||
│ Entwickler + BAs + Feature-POs │
|
||||
│ │
|
||||
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||
│ │Feature A │ │Feature B │ │Feature C │ ... │
|
||||
│ │3-5 Pers. │ │3-5 Pers. │ │3-5 Pers. │ │
|
||||
│ │PO + Devs │ │PO + Devs │ │PO + Devs │ │
|
||||
│ └──────────┘ └──────────┘ └──────────┘ │
|
||||
│ │
|
||||
│ Nach Feature-Abschluss: 1 Dev → OpsDev (Hypercare) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### Vorteile
|
||||
- **Klare Verantwortung**: Feature-Team ownt das Feature end-to-end (Portal + Backend + Schnittstelle)
|
||||
- **Keine Cross-Team-Abhaengigkeiten** fuer Features: Ein Team macht alles
|
||||
- **Flexibilitaet**: Pool kann nach Prioritaet umgeschichtet werden
|
||||
- **Wissenstransfer**: Hypercare-Phase zwingt Feature-Devs in den Betrieb
|
||||
- **Qualitaet**: Wer baut, betreibt (You build it, you run it — zeitversetzt)
|
||||
|
||||
### Nachteile
|
||||
- **Kontextwechsel**: Entwickler muessen mehrere Services kennen (Portal + Backend + CI)
|
||||
- **Onboarding-Aufwand**: Jedes Feature-Team braucht Einarbeitung in fremde Codebasis
|
||||
- **Kein stabiles Team**: Teambildung leidet wenn Teams staendig neu zusammengesetzt werden
|
||||
- **OpsDev wird Muellhalde**: Alle Bugs landen dort, kein Ownership fuer Ursachenbekaempfung
|
||||
- **PO-Overhead**: Jedes Feature braucht einen PO — bei 3-4 parallelen Features braucht man 3-4 POs
|
||||
- **Risiko**: Wenn Feature-Teams aufgeloest werden, geht Wissen verloren
|
||||
|
||||
### Bewertung gegenueber Zielen
|
||||
| Ziel | Bewertung | Begruendung |
|
||||
|------|-----------|-------------|
|
||||
| Geschwindigkeit | ⭐⭐⭐⭐ | Feature-Teams koennen autonom liefern |
|
||||
| Weniger Komplexitaet | ⭐⭐ | Pool-Management ist selbst komplex |
|
||||
| Weniger Abhaengigkeiten | ⭐⭐⭐⭐⭐ | Feature-Team hat alles was es braucht |
|
||||
| Bessere Qualitaet | ⭐⭐⭐ | Hypercare hilft, aber kein langfristiger Code-Owner |
|
||||
| Bessere Verantwortlichkeit | ⭐⭐⭐ | Gut fuer Features, schlecht fuer langfristige Service-Pflege |
|
||||
|
||||
---
|
||||
|
||||
## 4. Option B: Fachlicher Schnitt in 2 Teams
|
||||
|
||||
### Moegliche Schnitte
|
||||
|
||||
#### B1: Bestellung vs. Abwicklung
|
||||
|
||||
```
|
||||
Team "Bestellen" Team "Abwickeln"
|
||||
───────────────── ─────────────────
|
||||
Portal UI + MW Steuerung Vertrieb (Camunda)
|
||||
Common Interface (Eingang) Auftrags-Verwaltung
|
||||
Stammdaten-Bereitstellung IFP-Connector
|
||||
Kundendaten-Bereitstellung Vertragsdaten-Verteiler
|
||||
TAF/TAP-TDM-Konverter Archivierungsservice
|
||||
Abrechnung/AC-Anbindung
|
||||
|
||||
Fokus: Alles was der Kunde Fokus: Alles was nach der
|
||||
sieht und eingibt Bestellung passiert
|
||||
```
|
||||
|
||||
**Vorteile B1:**
|
||||
- Klarer Kundenfokus im Team "Bestellen" (Portal + Schnittstelle = Kundenkontakt)
|
||||
- Team "Abwickeln" kann sich auf Prozess-Korrektheit konzentrieren (Camunda, Abrechnung)
|
||||
- Natuerliche Grenze: Bestellung ist abgeschickt → Uebergabe an Abwicklung
|
||||
|
||||
**Nachteile B1:**
|
||||
- SV (93K LoC, 2214 Smells) ist ein Monolith — schwer zu teilen
|
||||
- Aenderungswesen (NAÄ) betrifft BEIDE Teams (Kunde bekommt Aenderung UND Prozess muss reagieren)
|
||||
- Team "Bestellen" hat Portal + CI + Stammdaten — sehr heterogener Tech-Stack (Angular + Java + SOAP)
|
||||
|
||||
#### B2: Netzfahrplan vs. Gelegenheitsverkehr
|
||||
|
||||
```
|
||||
Team "Netzfahrplan" Team "GelV + ujBau"
|
||||
───────────────── ─────────────────
|
||||
NEP1/NEP2 Prozesse Gelegenheitsverkehr
|
||||
Langfristige Bestellungen Click&Ride
|
||||
Koordinierungsverfahren ujBau (Baufahrplan)
|
||||
Kapazitaetsmanagement Ad-hoc Verkehre
|
||||
Kurzfristige Aenderungen
|
||||
```
|
||||
|
||||
**Vorteile B2:**
|
||||
- Fachlich sauberer Schnitt (unterschiedliche Fristen, Prozesse, Kunden)
|
||||
- GelV hat andere Anforderungen (Geschwindigkeit) als Netzfahrplan (Korrektheit)
|
||||
- Passt zu den TTT-Meilensteinen (NEP2 vs. GelV sind separate Streams)
|
||||
|
||||
**Nachteile B2:**
|
||||
- Technisch teilen sich beide denselben Code (SV, Portal, CI) — kein sauberer Service-Schnitt
|
||||
- Kleine Features betreffen oft beide Bereiche
|
||||
- GelV-Team waere deutlich kleiner (weniger Volumen)
|
||||
- NAÄ und Abrechnung betreffen beide
|
||||
|
||||
#### B3: Extern (Kundenschnittstelle) vs. Intern (Prozesse)
|
||||
|
||||
```
|
||||
Team "Aussen" (Kundenkontakt) Team "Innen" (Prozesse)
|
||||
───────────────── ─────────────────
|
||||
Portal UI + MW Steuerung Vertrieb
|
||||
Common Interface Auftrags-Verwaltung
|
||||
Click&Ride IFP-Connector
|
||||
Stammdaten (fuer Kunden) Vertragsdaten-Verteiler
|
||||
BSSUPPORT (2nd Level) Archivierungsservice
|
||||
Monitoring/Alerting
|
||||
|
||||
Fokus: Alles was Kunden Fokus: Alles was intern
|
||||
sehen und nutzen verarbeitet wird
|
||||
```
|
||||
|
||||
**Vorteile B3:**
|
||||
- Aehnlich wie B1, aber mit Support integriert → schnellere Bug-Behebung
|
||||
- Team "Aussen" kann Kundenfeedback direkt umsetzen
|
||||
- Team "Innen" kann sich auf Korrektheit und Performance konzentrieren
|
||||
|
||||
**Nachteile B3:**
|
||||
- Gleiche Probleme wie B1 (NAÄ betrifft beide, SV ist Monolith)
|
||||
- Support im Team "Aussen" bindet Kapazitaet
|
||||
|
||||
#### B4: Domäne "Trasse" vs. Domäne "Vertrag"
|
||||
|
||||
```
|
||||
Team "Trasse" Team "Vertrag"
|
||||
───────────────── ─────────────────
|
||||
Trassenanmeldung (Portal+CI) Angebot + Vertrag (SV)
|
||||
Trassenkonstruktion (IFP) Abrechnung
|
||||
Stammdaten Stornierung
|
||||
TAF/TAP Konvertierung Rahmenvertraege
|
||||
Vertragsdaten-Verteiler
|
||||
|
||||
Fokus: Vom Kundenwunsch Fokus: Vom Angebot bis
|
||||
bis zum Konstruktionsauftrag zur Rechnung
|
||||
```
|
||||
|
||||
**Vorteile B4:**
|
||||
- Sauberster fachlicher Schnitt entlang des Geschaeftsprozesses
|
||||
- Klare Uebergabe: Trasse ist konstruiert → Vertrag wird erstellt
|
||||
- Abrechnung (das groesste Risiko) hat ein dediziertes Team
|
||||
- Passt zur INB-Struktur (Bestellung vs. Entgelt)
|
||||
|
||||
**Nachteile B4:**
|
||||
- SV muesste aufgeteilt werden (Bestelleingang vs. Vertragsabschluss) — technisch schwierig
|
||||
- Portal zeigt sowohl Bestellungen als auch Vertraege — wo gehoert es hin?
|
||||
- Aenderungswesen (NAÄ) ist ein Querschnittsthema
|
||||
|
||||
---
|
||||
|
||||
## 5. Option C: Hybridmodell (OpsDev + 2 fachliche Teams)
|
||||
|
||||
### Modell
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────┐
|
||||
│ OpsDev Team (~6 Personen, permanent) │
|
||||
│ Lead: OpsDev-Lead │
|
||||
│ Betrieb, Deployment, Monitoring, Infrastruktur │
|
||||
│ Bug-Triage (weist Bugs an fachliche Teams zu) │
|
||||
└─────────────────────────────────────────────────────────┘
|
||||
|
||||
┌──────────────────────────┐ ┌──────────────────────────┐
|
||||
│ Team "Bestellen" │ │ Team "Verarbeiten" │
|
||||
│ ~12 Personen │ │ ~12 Personen │
|
||||
│ PO + BA + Devs │ │ PO + BA + Devs │
|
||||
│ │ │ │
|
||||
│ Portal UI + MW │ │ Steuerung Vertrieb │
|
||||
│ Common Interface │ │ Auftrags-Verwaltung │
|
||||
│ Stammdaten │ │ IFP-Connector │
|
||||
│ Kundendaten │ │ Archivierung │
|
||||
│ TAF/TAP Konverter │ │ Vertragsdaten │
|
||||
│ Click&Ride │ │ Abrechnung │
|
||||
│ │ │ Rabattnummern │
|
||||
│ Bugs: Portal, CI, STB │ │ Bugs: SV, AV, IFP │
|
||||
└──────────────────────────┘ └──────────────────────────┘
|
||||
```
|
||||
|
||||
### Vorteile
|
||||
- **Klare Ownership**: Jedes Team ownt seine Services dauerhaft (kein Wissensverlust)
|
||||
- **OpsDev entlastet**: Fachliche Teams fixen ihre eigenen Bugs, OpsDev nur Infrastruktur
|
||||
- **Fachlicher Schnitt**: "Bestellen" = Kundenkontakt, "Verarbeiten" = Backend-Prozesse
|
||||
- **Stabile Teams**: Teambildung moeglich, Wissen bleibt
|
||||
- **Skalierbar**: Bei Bedarf kann ein drittes Team abgespalten werden
|
||||
|
||||
### Nachteile
|
||||
- **NAÄ/Aenderungswesen**: Betrifft beide Teams — braucht Abstimmung
|
||||
- **Portal zeigt Vertragsdaten**: Team "Bestellen" muss fuer Anzeige auf Team "Verarbeiten" warten
|
||||
- **SV bleibt Monolith**: Gehoert komplett zu "Verarbeiten" — dort konzentriert sich die Komplexitaet
|
||||
|
||||
### Bewertung gegenueber Zielen
|
||||
| Ziel | Bewertung | Begruendung |
|
||||
|------|-----------|-------------|
|
||||
| Geschwindigkeit | ⭐⭐⭐⭐ | Zwei autonome Teams + OpsDev |
|
||||
| Weniger Komplexitaet | ⭐⭐⭐⭐ | Klare Zustaendigkeiten, weniger Koordination |
|
||||
| Weniger Abhaengigkeiten | ⭐⭐⭐ | Besser als heute, aber NAÄ bleibt Querschnitt |
|
||||
| Bessere Qualitaet | ⭐⭐⭐⭐ | Ownership = Verantwortung fuer Qualitaet |
|
||||
| Bessere Verantwortlichkeit | ⭐⭐⭐⭐⭐ | Jeder Service hat genau ein Team |
|
||||
|
||||
---
|
||||
|
||||
## 6. Option D: Spotify-Modell (Squads + Chapters + Guild)
|
||||
|
||||
### Modell
|
||||
- **Squads** (3-4): Feature-orientiert, temporaer zusammengesetzt
|
||||
- **Chapters**: Fachliche Heimat (Frontend, Backend, QA, Ops)
|
||||
- **Guild**: Uebergreifende Themen (Security, Performance, Architektur)
|
||||
|
||||
### Bewertung
|
||||
Fuer pathOS mit ~35 Personen ist das Spotify-Modell **zu komplex**. Es lohnt sich erst ab 50+ Personen. Die Overhead-Kosten (Chapter Leads, Guild Meetings) ueberwiegen den Nutzen.
|
||||
|
||||
**Nicht empfohlen.**
|
||||
|
||||
---
|
||||
|
||||
## 7. Gesamtbewertung
|
||||
|
||||
| Option | Geschwindigkeit | Komplexitaet | Abhaengigkeiten | Qualitaet | Ownership | Empfehlung |
|
||||
|--------|----------------|--------------|-----------------|-----------|-----------|------------|
|
||||
| **A: OpsDev + Pool** | ⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | Gut fuer Feature-Sprints, schlecht fuer Langfrist |
|
||||
| **B1: Bestellen/Abwickeln** | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | Solide, aber NAÄ-Problem |
|
||||
| **B4: Trasse/Vertrag** | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | Bester fachlicher Schnitt |
|
||||
| **C: Hybrid (OpsDev + 2)** | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | **Empfohlen** |
|
||||
| D: Spotify | ⭐⭐⭐ | ⭐ | ⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐ | Zu komplex fuer 35 Personen |
|
||||
|
||||
### Empfehlung: Option C (Hybrid) mit Elementen aus A
|
||||
|
||||
**Kernstruktur**: OpsDev (permanent) + 2 fachliche Teams (permanent)
|
||||
**Element aus A**: Fuer grosse Features (GelV, ujBau) temporaer 2-3 Personen aus beiden Teams zusammenziehen → nach Abschluss zurueck + 1 Person in Hypercare
|
||||
|
||||
---
|
||||
|
||||
## 8. Hinweise fuer weiteren Research
|
||||
|
||||
### Zu klaeren
|
||||
1. **SV aufteilen?** — Ist der Monolith (93K LoC) technisch teilbar? Oder muss ein Team ihn komplett ownen?
|
||||
2. **NAÄ als Querschnitt** — Braucht es ein dediziertes "NAÄ-Feature-Team" (temporaer) oder eine feste Zuordnung?
|
||||
3. **Portal-Ownership** — Portal zeigt Daten aus allen Services. Gehoert es zu "Bestellen" oder ist es ein eigener Querschnitt?
|
||||
4. **Abrechnung** — Ist AC Trasse ein eigenes Team wert? Oder bleibt es bei "Verarbeiten"?
|
||||
5. **Personelle Passung** — Wer kann/will wohin? Staerken-Mapping der 35 Personen.
|
||||
6. **Uebergangsphase** — Wie lange dauert die Umstellung? Produktivitaetsverlust waehrend Transition?
|
||||
7. **PO-Struktur** — 1 PO pro Team oder 1 uebergreifender PO + Feature-POs?
|
||||
8. **Metriken** — Wie messen wir ob die Reorg erfolgreich war? (Bug-Rate, Durchlaufzeit, Deployment-Frequenz)
|
||||
|
||||
### Daten die noch fehlen
|
||||
- Git-Contributions pro Person/Service (wer kennt welchen Code?)
|
||||
- Abhaengigkeits-Graph zwischen Services (Kafka-Topics, REST-Calls)
|
||||
- Kundenfeedback: Welche Features werden am meisten nachgefragt?
|
||||
- Camunda-Prozess-Instanzen: Wie oft laeuft welcher Prozess?
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 9. Faktor TrassenOrder (Team TraPo)
|
||||
|
||||
### Was ist TrassenOrder?
|
||||
- **Neues Produkt** innerhalb SAB (gleiche Einheit wie pathOS)
|
||||
- **Zweck**: Modernisiert den Bestellprozess fuer Gelegenheitsverkehr — medienbruchfreier Workflow
|
||||
- **Entwicklungsstart**: Januar 2026
|
||||
- **Livegang**: voraussichtlich Q4 2026
|
||||
- **Phase**: EXPLORE
|
||||
- **Team**: TraPo (eigenes Team in SAB)
|
||||
- **Jira**: TRAPO-Projekt (systelone)
|
||||
|
||||
### Ueberschneidung mit pathOS
|
||||
- pathOS hat bereits **Click&Ride** (Anlage 4.2.2 INB) fuer kurzfristigen GelV
|
||||
- ADR-72 (Click&Ride Anbindung) ist ein aktives CIB-Thema
|
||||
- GelV-Erweiterungen sind ein TTT-Meilenstein (ab Sep 2026)
|
||||
- TrassenOrder adressiert denselben Bereich — aber als separates Produkt
|
||||
|
||||
### Implikationen fuer die Reorganisation
|
||||
|
||||
**Fragen die geklaert werden muessen:**
|
||||
1. **Abgrenzung**: Was macht TrassenOrder, was macht pathOS/Click&Ride? Gibt es eine klare Grenze oder Ueberlappung?
|
||||
2. **Integration**: Wird TrassenOrder ein Frontend fuer pathOS-Backend? Oder ein komplett separates System?
|
||||
3. **Team-Zuordnung**: Gehoert GelV kuenftig zu TraPo oder zu pathOS? Oder beides?
|
||||
4. **Schnittstelle**: Braucht pathOS eine API fuer TrassenOrder? Wer baut/pflegt die?
|
||||
5. **Kannibalisierung**: Ersetzt TrassenOrder langfristig Click&Ride?
|
||||
|
||||
**Auswirkung auf Optionen:**
|
||||
- **Option A (Pool)**: TrassenOrder-Devs koennten Teil des Pools sein
|
||||
- **Option B (2 Teams)**: GelV-Schnitt (B2) wird fragwuerdig wenn TrassenOrder GelV uebernimmt
|
||||
- **Option C (Hybrid)**: Team "Bestellen" muesste Schnittstelle zu TrassenOrder definieren
|
||||
- **Generell**: Wenn TrassenOrder den GelV-Bereich uebernimmt, kann sich pathOS auf Netzfahrplan + ujBau konzentrieren — das vereinfacht den fachlichen Schnitt erheblich
|
||||
|
||||
### Empfehlung
|
||||
Vor der Reorg-Entscheidung **unbedingt mit TraPo-Team abstimmen**:
|
||||
- Roadmap-Abgleich (was baut wer bis wann?)
|
||||
- Schnittstellen-Definition (API-Vertrag zwischen pathOS und TrassenOrder)
|
||||
- Langfristige Vision: Ein System oder zwei?
|
||||
@@ -0,0 +1,98 @@
|
||||
# TAF/TAP TSI Programm — Analyse
|
||||
|
||||
> Stand: 2026-04-23 | Quelle: TTSI Confluence Space (44 Seiten exportiert)
|
||||
|
||||
---
|
||||
|
||||
## 1. Was ist das TTT-Programm?
|
||||
|
||||
TAF/TAP TSI (TTT) ist das uebergreifende Programm zur Einfuehrung des europaeischen Standards fuer Trassenbestellung und Betrieb bei DB InfraGO. Es ist **regulatorisch verpflichtend** (EU-Verordnungen 1305/2014 TAF TSI und 454/2011 TAP TSI).
|
||||
|
||||
### Kernfakten
|
||||
- **Ziel**: Einfuehrung TTT fuer Fahrplanjahr 2027 (FplJ 27)
|
||||
- **Auftraggeber**: Robert Arnhold (CIO/CDO DB InfraGO)
|
||||
- **Programmleitung**: Heike Sperber
|
||||
- **Bereits 4x verschoben** seit 2014 — letzte Neuplanung Oktober 2024
|
||||
- **Kein direkter Geschaeftsnutzen** ueber regulatorische Compliance hinaus
|
||||
- **Kein Parallelbetrieb moeglich** — muss von Anfang an stabil funktionieren
|
||||
- **~400 Marktteilnehmer** (EVUs) muessen gleichzeitig umgestellt werden
|
||||
|
||||
### Beteiligte Value Teams
|
||||
| Value Team | Bereich | Funktion |
|
||||
|-----------|---------|---------|
|
||||
| **O2C** (Order2Cash) | Vertrieb | Trassenbestellung & -abrechnung → **pathOS** |
|
||||
| **C2S** (Capacity2Schedule) | Fahrplan | Kapazitaetsmanagement & Fahrplanung |
|
||||
| **S2O** (Schedule2Operate) | Betrieb | Betriebliche Meldungen |
|
||||
|
||||
### Leistungsprozesse (Meilensteine)
|
||||
| Kuerzel | Bedeutung | Status |
|
||||
|---------|-----------|--------|
|
||||
| **NEP1** | Netzfahrplan-Erstbestellung | ✅ Abgeschlossen |
|
||||
| **NEP2** | Netzfahrplan Phase 2 | ⏳ Aktuell in Arbeit |
|
||||
| **GelV** | Gelegenheitsverkehr | ⏳ In Planung/Umsetzung |
|
||||
| **ujBau** | Umgebungsjahresbau | ⏳ In Planung/Umsetzung |
|
||||
|
||||
## 2. Go/No-Go Entscheidung FplJ 27
|
||||
|
||||
- **Status**: IN ARBEIT
|
||||
- **Zeitplan**:
|
||||
- Messung vor Stellungnahmeverfahren: 04.08.2026
|
||||
- Lenkungskreis: 06.08.2026
|
||||
- Messung nach Stellungnahmeverfahren: 15.09.2026
|
||||
- Entscheidungstermin: **16.09.2026**
|
||||
- **Perspektive**: "Mit 9 Monaten Vorlauf sicher sein, dass der GoLive erfolgreich sein wird"
|
||||
- **Kriterien**: Werden aktuell erarbeitet
|
||||
|
||||
## 3. Top-Programmrisiken
|
||||
|
||||
| ID | Risiko | Schwere |
|
||||
|----|--------|---------|
|
||||
| TTTSOL-52 | **Unrealistische Go-Live-Entscheidung** — Entscheidung auf Basis falscher Annahmen kann massive betriebliche Risiken ausloesen | KRITISCH |
|
||||
| TTTSOL-51 | **Rueckstand bei funktionalen Anforderungen** — Wirtschaftliche Nachteile und Reputationsschaeden durch weitere Verschiebungen | HOCH |
|
||||
| TTTSOL-50 | **Budgetrisiken** — Preissteigerungen bei gleichbleibendem Budget, Teams koennen nicht konstant bleiben | HOCH |
|
||||
| TTTSOL-49 | **Unzureichendes Abhaengigkeitsmanagement** — Fehlplanungen und Verzoegerungen | HOCH |
|
||||
| TTTSOL-48 | **Ressourcenengpaesse** — Konkurrenz mit anderen Themen (Annex VII, KaZu Novum) | HOCH |
|
||||
| TTTSOL-47 | **Mangelnde Qualitaetssicherung** — Wirtschaftliche und regulatorische Folgen | HOCH |
|
||||
| TTTSOL-44 | **Ueberplanung ujBau** — 110 Jobsize Capabilities nicht mit Kapazitaet hinterlegt | HOCH |
|
||||
| TTTSOL-42 | **Fehlende fachliche Steuerung** — Scope unvollstaendig heruntergebrochen | HOCH |
|
||||
|
||||
## 4. Roll-out und Hypercare
|
||||
|
||||
- **Hypercare geplant** nach Go-Live mit erhoehter Aufmerksamkeit
|
||||
- **Heisse Phase**: Punktuelle Rufbereitschaft/Wochenendarbeit bei Bugwelle
|
||||
- **Teamverfuegbarkeit**: Mindestens 08:00-18:00, ideal 07:00-19:00
|
||||
- **Kein Parallelbetrieb** — Fehler muessen sofort behoben werden
|
||||
|
||||
## 5. Risikomanagement-Struktur
|
||||
|
||||
Mehrstufig mit ROAM-Methodik:
|
||||
- **Team-Ebene**: Initiale Erfassung, Monitoring
|
||||
- **ART-Ebene**: Buendelung, Bewertung (O2CBS, C2S, S2O)
|
||||
- **Programmebene (PMO)**: Zentrale Steuerung, Eskalation an Lenkungskreis
|
||||
- **Jira-basiert**: TTTSOL-Projekt fuer Programmrisiken
|
||||
- **Woechentliches Risiko-Review** nach Arbeitsmeeting
|
||||
|
||||
## 6. Bedeutung fuer pathOS
|
||||
|
||||
pathOS ist der **O2C-Anteil** des TTT-Programms — die Trassenbestellung. Das bedeutet:
|
||||
|
||||
1. **Go/No-Go am 16.09.2026** betrifft pathOS direkt — das System muss bis dahin produktionsreif sein
|
||||
2. **Kein Parallelbetrieb** — pathOS muss TPN vollstaendig ersetzen koennen
|
||||
3. **NEP2 + GelV** sind die aktuellen Meilensteine die pathOS liefern muss
|
||||
4. **8 Programmrisiken** betreffen pathOS direkt oder indirekt
|
||||
5. **Hypercare** erfordert erhoehte Teamverfuegbarkeit nach Go-Live
|
||||
6. **Budgetrisiko** (TTTSOL-50) kann pathOS-Ressourcen betreffen
|
||||
7. **110 ungeplante Capabilities im ujBau** (TTTSOL-44) — Priorisierungskonflikt
|
||||
|
||||
### Zeitkritischer Pfad fuer pathOS
|
||||
```
|
||||
JETZT (Apr 2026)
|
||||
→ Spring Boot 4 Upgrade (MUSS vor Go-Live)
|
||||
→ NEP2 Funktionalitaet liefern
|
||||
→ GelV Funktionalitaet liefern
|
||||
|
||||
Aug 2026: Go/No-Go Messung 1
|
||||
Sep 2026: Go/No-Go Entscheidung (16.09.)
|
||||
Dez 2026: Fahrplanwechsel → Go-Live FplJ 27
|
||||
Jan 2027+: Hypercare
|
||||
```
|
||||
@@ -0,0 +1,78 @@
|
||||
# Velocity-Analyse pathOS (12 Monate)
|
||||
|
||||
> Stand: 2026-04-23 | Zeitraum: April 2025 - April 2026
|
||||
|
||||
---
|
||||
|
||||
## Gesamtdurchsatz pro Team (12 Monate)
|
||||
|
||||
| Team | Issues (12M) | Avg/Monat | Bugs (12M) | Bug% (12M) | Trend |
|
||||
|------|-------------|-----------|-----------|------------|-------|
|
||||
| Team 404 | 1537 | 118 | 391 | 25% | Stabil-hoch, Bug-Rate steigt |
|
||||
| Team Zero | 1409 | 108 | 210 | 15% | Stabil, Bug-Rate schwankt |
|
||||
| Team CIB | 905 | 70 | 204 | 23% | Steigend, Bug-Rate sinkt |
|
||||
| DevOps | 719 | 55 | 48 | 7% | Stabil |
|
||||
| OPs Squad | 305 | 76* | 83 | 27% | Neu seit Jan 2026 |
|
||||
| **GESAMT** | **4875** | **~400** | **936** | **19%** | |
|
||||
|
||||
*OPs erst seit Jan 2026 (4 Monate)
|
||||
|
||||
## Monatlicher Verlauf (alle Teams aggregiert)
|
||||
|
||||
| Monat | 404 | CIB | Zero | OPs | DevOps | **Total** | Bugs | Bug% | Kontext |
|
||||
|-------|-----|-----|------|-----|--------|-----------|------|------|---------|
|
||||
| 2025-04 | 16 | 9 | 28 | — | 4 | **57** | 8 | 14% | Ramp-up |
|
||||
| 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 Vorbereitung |
|
||||
| 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 Start |
|
||||
| 2026-02 | 102 | 54 | 79 | 88 | 38 | **361** | 103 | 29% | **Hypercare Peak** |
|
||||
| 2026-03 | 172 | 74 | 100 | 127 | 57 | **530** | 117 | 22% | Hypercare + NEP2 |
|
||||
| 2026-04* | 108 | 80 | 52 | 51 | 26 | **317** | 64 | 20% | Stabilisierung |
|
||||
|
||||
*April noch nicht abgeschlossen
|
||||
|
||||
## Erkenntnisse
|
||||
|
||||
### 1. Go-Live-Effekt klar sichtbar
|
||||
- **Nov 2025 (Pre-Go-Live)**: 458 Issues, 23% Bugs — hoechster Durchsatz vor Go-Live
|
||||
- **Dez 2025 (Go-Live)**: 290 Issues — Einbruch durch Deployment-Fokus
|
||||
- **Jan 2026 (Hypercare)**: 471 Issues — Sofort-Reaktion auf Produktionsprobleme
|
||||
- **Feb 2026**: 361 Issues, **29% Bug-Rate** — Hoechste Bug-Rate! Hypercare-Peak
|
||||
- **Maerz 2026**: 530 Issues — Hoechster Monat ueberhaupt, Hypercare + NEP2
|
||||
|
||||
### 2. Bug-Rate-Entwicklung
|
||||
```
|
||||
Apr-Jun 2025: 10-14% (Entwicklung, wenig Bugs)
|
||||
Jul-Sep 2025: 16-17% (Pre-Go-Live, Bugs steigen)
|
||||
Okt-Nov 2025: 19-23% (Pre-Go-Live Peak)
|
||||
Dez 2025: 25% (Go-Live)
|
||||
Jan 2026: 20% (Hypercare)
|
||||
Feb 2026: 29% (Hypercare Peak!)
|
||||
Maerz 2026: 22% (Stabilisierung)
|
||||
Apr 2026: 20% (Normalisierung)
|
||||
```
|
||||
Bug-Rate normalisiert sich nach dem Hypercare-Peak im Februar.
|
||||
|
||||
### 3. Team-spezifische Muster
|
||||
|
||||
**Team 404 (Portal)**: Bug-Rate steigt seit Go-Live (22% → 33% im Maerz). Portal ist das Kundenfacing-System — Bugs werden direkt von EVUs gemeldet. Besorgniserregend.
|
||||
|
||||
**Team CIB (Backend)**: Bug-Rate sinkt dramatisch (36% Jan → 9% April). Backend stabilisiert sich. Positiver Trend.
|
||||
|
||||
**Team Zero (TAF/TAP)**: Bug-Rate schwankt (31% Dez → 8% Jan → 21% Maerz → 12% April). Abhaengig von Schnittstellen-Aenderungen.
|
||||
|
||||
**OPs Squad**: Erst seit Jan 2026. Feb hatte 51% Bug-Rate (!) — Infrastruktur-Stabilisierung nach Go-Live. Jetzt bei 29%.
|
||||
|
||||
**DevOps**: Konstant niedrige Bug-Rate (1-16%). Primaer Enabler-Arbeit. Stabil.
|
||||
|
||||
### 4. Kapazitaets-Trend
|
||||
- **Vor Go-Live** (Mai-Nov 2025): ~400 Issues/Monat ueber 3 Teams + DevOps
|
||||
- **Nach Go-Live** (Jan-Apr 2026): ~420 Issues/Monat ueber 5 Teams (inkl. OPs)
|
||||
- **Netto**: Kapazitaet ist gleich geblieben, aber auf mehr Teams verteilt
|
||||
- **OPs absorbiert ~80 Issues/Monat** die vorher bei STeam lagen
|
||||
@@ -0,0 +1,55 @@
|
||||
# Velocity-Analyse pathOS Teams
|
||||
|
||||
> Stand: 2026-04-23 | Basis: Jira-Daten der letzten 90 Tage (7 Team-Boards)
|
||||
|
||||
---
|
||||
|
||||
## Durchsatz pro Team und Monat
|
||||
|
||||
| Team | Fertig (90d) | Offen | Bug% | Enabler% | Jan | Feb | Maerz | April* | Trend |
|
||||
|------|-------------|-------|------|----------|-----|-----|-------|--------|-------|
|
||||
| **Team 404** | 315 | 185 | **28%** | 7% | — | — | 153 | 162 | ↑ UP |
|
||||
| **Team CIB** | 239 | 103 | 20% | 3% | 17 | 66 | 76 | 80 | ↑ UP |
|
||||
| **Team Zero** | 251 | 166 | 17% | 7% | 12 | 75 | 108 | 56 | ↓ DOWN |
|
||||
| **OPs Squad** | 292 | 87 | **28%** | 10% | 29 | 88 | 120 | 55 | ↓ DOWN |
|
||||
| **DevOps** | 158 | 131 | 13% | **44%** | 32 | 39 | 61 | 26 | ↓ DOWN |
|
||||
| **GESAMT** | **1255** | **672** | 21% | 12% | 90 | 268 | 518 | 379 | — |
|
||||
|
||||
*April: Monat noch nicht abgeschlossen (Stand 23.04.)
|
||||
|
||||
## Erkenntnisse
|
||||
|
||||
### 1. Gesamtdurchsatz: ~130 Issues/Woche
|
||||
- 1255 Issues in 90 Tagen = ~14 Issues/Tag = ~70 Issues/Woche ueber alle Teams
|
||||
- Maerz war der produktivste Monat (518 Issues) — vermutlich Sprint-Ende/PI-Abschluss
|
||||
- April-Trend (379 bei 23 Tagen) hochgerechnet: ~500 Issues/Monat — stabil
|
||||
|
||||
### 2. Team 404 und CIB steigen — Zero, OPs, DevOps fallen
|
||||
- **404 steigt** (153 → 162): Portal-Arbeit nimmt zu, Spring Boot 4 Portal ist fertig
|
||||
- **CIB steigt** (76 → 80): Stetig wachsend seit Januar (17 → 80)
|
||||
- **Zero faellt** (108 → 56): Maerz-Peak (vermutlich NEP1-Abschluss), jetzt normalisiert
|
||||
- **OPs faellt** (120 → 55): Maerz-Peak (Hypercare-Bugs), jetzt weniger akut
|
||||
- **DevOps faellt** (61 → 26): Weniger Enabler-Arbeit noetig?
|
||||
|
||||
### 3. Bug-Raten sind besorgniserregend bei 404 und OPs
|
||||
- **Team 404: 28% Bugs** — fast jedes dritte erledigte Issue ist ein Bug
|
||||
- **OPs: 28% Bugs** — Infrastruktur-Stabilitaet
|
||||
- Team CIB: 20% — moderat
|
||||
- Team Zero: 17% — niedrigster Wert
|
||||
- DevOps: 13% — niedrig, aber 44% Enabler (technischer Overhead)
|
||||
|
||||
### 4. DevOps = 44% Enabler
|
||||
- Fast die Haelfte aller DevOps-Issues sind Enabler (technische Infrastruktur-Arbeit)
|
||||
- Nur 13% Bugs — DevOps arbeitet primaer an Tooling, nicht an Fehlerbehebung
|
||||
- Jan Lubenow allein: 114/289 Issues (39%) — kritische Personenabhaengigkeit
|
||||
|
||||
### 5. Backlog-Gesundheit
|
||||
| Team | Fertig | Offen | Completion Rate |
|
||||
|------|--------|-------|----------------|
|
||||
| OPs | 292 | 87 | **77%** — gesund |
|
||||
| CIB | 239 | 103 | **70%** — gesund |
|
||||
| 404 | 315 | 185 | **63%** — Backlog waechst |
|
||||
| Zero | 251 | 166 | **60%** — Backlog waechst |
|
||||
| DevOps | 158 | 131 | **55%** — Backlog waechst |
|
||||
|
||||
OPs und CIB haben gesunde Backlogs. 404, Zero und DevOps haben wachsende Backlogs.
|
||||
Reference in New Issue
Block a user