ankn/Orchestrator
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Migrate all repos into monorepo context folders

Browse Source 
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:
ankn
2026-06-30 20:39:52 +02:00
parent 2f2b295531
commit a5f8fb49ab
1717 changed files with 447332 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
bahn/project-audit/.gitignore
+21
View File
@@ -0,0 +1,21 @@
# Datenbank (wird aus Quelldaten regeneriert)
knowledge/pathos.db
# Secrets (NIEMALS committen!)
.secrets
# Grosse Datenexports (koennen regeneriert werden)
data/jira-export/issues.json
data/jira-velocity/*.json
data/sonarqube/*.json
# Confluence HTML-Exports (gross, regenerierbar)
data/confluence-export/pages/*.html
# Python
__pycache__/
*.pyc
# OS
Thumbs.db
.DS_Store
bahn/project-audit/.kiro/steering/standards.md
+46
View File
@@ -0,0 +1,46 @@
---
inclusion: auto
---
# Project-Audit Standards
## Quality Gates (before every commit)
1. `gitleaks detect --source . --no-git` — no secrets in code
2. `ruff check .` — linting passes (if configured)
3. No hardcoded tokens or URLs with credentials in scripts
## Conventional Commits
```
feat(analysis): add team velocity dashboard
fix(export): handle UTF-8 in Confluence page titles
data(confluence): update page export for PI 41
docs(readme): update analysis findings
```
## Security (CRITICAL)
- NEVER commit `.secrets` or token values
- Scripts read tokens from `../../.secrets` (workspace root)
- Confluence/Jira URLs are safe to commit, tokens are not
- Data exports must not contain personal data (emails, phone numbers)
## File Naming
- All filenames OneDrive-safe
- No brackets `()`, no `&`, no `@`, no `#`
- Replace umlauts: ä→ae, ö→oe, ü→ue
- Use hyphens for spaces in page-derived filenames
## Architecture
- Standalone Python scripts (no framework, no package)
- Each script reads from APIs and writes to local files
- Knowledge graph in `knowledge/` (SQLite via ingest.py)
- Data exports in `data/` (gitignored if large)
## DB GitLab
- Repo: https://git.tech.rz.db.de/AndreKnie/project-audit
- Push with GITLAB_TOKEN_AUDIT (write scope)
bahn/project-audit/NAECHSTE-SESSION.md
+148
View File
@@ -0,0 +1,148 @@
# Naechste Session — Startpunkt
> Letzte Session: 2026-05-07
> Datum korrigiert (System zeigt 07.05., nicht 30.04.)
## SOFORT bei Session-Start
1. **Git Push nachholen** — GitLab war im Maintenance (502). Ausfuehren:
```
python project-audit/scripts/git-push.py "Cleanup + TrassenOrder + Team-Reorg"
```
2. **systelone Confluence lesen** — Rate Limit sollte zurueckgesetzt sein:
```
python project-audit/scripts/trapo-read.py
```
## Was wurde in dieser Session erledigt
### Personal-Analyse finalisiert
- Tenure-Daten vollstaendig (176 Personen, 24.7K Issues)
- Bug-Causation Methodik dokumentiert
- Alle fehlenden Personen ergaenzt
### SonarQube Deep Dive + Branch-Analyse
- Coverage vs. Bug-Rate: Coverage erklaert Bug-Rate NICHT
- Shared Libraries: signature-* haben Tests, core-components-* NICHT
- 452 Branches, 166 aktiv, 246 stale, Spring Boot 4 auf 9 Branches
### Geschaeftskritische Risiken
- Systematischer Jira-Scan (TopThema, Konzernreporting, Taskforce-FplW)
- NAÄ implizite Annahme, 20h Zug, Abrechnung TTT/AC + 8 weitere
- Risiko-Radar als Confluence-Seite 23
### Roadmap-Tabelle
- 77 Themen, sortiert nach Team, mit Prio/Dauer/Deadline
- Confluence-Seite 24
### Team-Reorganisation
- 4 Optionen analysiert (A: Pool, B: Fachschnitt, C: Hybrid, D: Spotify)
- Empfehlung: Option C (OpsDev + 2 fachliche Teams)
- TrassenOrder (TraPo) als Testballon integriert
- Confluence-Seiten 25 + 26
### INB-Analyse gestartet
- 6 PDFs extrahiert (Hauptdokument + Anlagen)
- Erste Suche: Priorisierung, 20h-Zug, NAÄ gefunden
- Widerspruch "Expresstrasse" noch offen
### Pipeline + Tooling
- Pipeline aktualisiert (7 Schritte, API-Budget dokumentiert)
- BSSUPPORT Dashboard JQL-Abfragen erstellt
- Default Branch auf master umgestellt
- TTT = TAF/TAP TSI korrigiert, INB korrigiert, NAÄ ins Glossar
## Offene Punkte (priorisiert)
### Sofort (naechste Session)
1. **Git Push nachholen** (502 wegen Maintenance)
2. **TrassenOrder User Research laden** — trapo-read.py (systelone Rate Limit)
3. **INB-Widersprueche** — "Expresstrasse"/Priorisierung mit Andre klaeren
4. **Risiko-Radar aktualisieren** — jira-critical-scan.py
### Bald
5. Team-Reorganisation mit POs abstimmen
6. Roadmap-Tabelle validieren (77 Themen)
7. Confluence Seiten 1-5 Inhalt aktualisieren
8. INB vs. pathOS systematischer Abgleich
9. Knowledge-Base erweitern (TrassenOrder, INB, Risiken)
### Irgendwann
10. Support-Board (anderes Jira)
11. Performance-Daten (Zugang noetig)
12. Geschaeftsprozesse BPMN (Camunda-Zugang)
13. Git-Contributions
14. Incident-Analyse
15. Kosten-Analyse (AWS)
16. Branch-Cleanup empfehlen (246 stale)
17. Test-Seite loeschen (583338908)
18. BSSUPPORT Dashboard in Jira bauen
## Wiederkehrende Aufgaben
### Taeglich
- [ ] Knowledge-Base optimieren
- [ ] Confluence Backlog-Seite (14) aktualisieren
### Woechentlich
- [ ] Pipeline-Review
- [ ] Mini-Retro (project-audit/retro/)
- [ ] Risiko-Radar aktualisieren (jira-critical-scan.py)
## Confluence-Seiten (26 + Stammseite + 5 Kategorien)
| # | Seite | Status |
|---|-------|--------|
| 0 | Management Summary | Aktuell |
| 1-5 | Uebersicht, Probleme, Roadmap, GitLab, Glossar | Aktuell |
| 6-9 | Architektur, Fortschritt, Links, Customer Journey | Aktuell |
| 10-13 | Tech Deep Dive, Team Analyse, Roadmap, Jira | Aktuell |
| 14 | Audit-Backlog | Aktuell |
| 15-18 | TTT/NEP2, Roadmap gesamt, TTTI, Velocity | Aktuell |
| 19+19a | SonarQube + Branch-Analyse + Smells | Aktuell |
| 20-22 | Geschaeftsprozesse, Produkt-Roadmap, Personal-Analyse | Aktuell |
| 23 | Risiko-Radar | NEU |
| 24 | Roadmap-Tabelle (77 Themen) | NEU |
| 25 | Team-Reorganisation (Optionen) | NEU |
| 26 | Teams inkl. TrassenOrder | NEU |
## API-Budget (Richtwerte)
| System | Limit | Token in .secrets |
|--------|-------|-------------------|
| arija Jira | ~100/Tag | JIRA_TOKEN |
| arija Confluence | ~100/Tag | CONFLUENCE_TOKEN |
| systelone Jira+Confluence | ~10/Stunde! | JIRA_TOKEN_SAB / CONFLUENCE_SAB |
| GitLab | Kein bekanntes Limit | GITLAB_TOKEN_BESTELLSYSTEM / _AUDIT |
## Scripts (bereinigt)
| Script | Zweck |
|--------|-------|
| confluence-push.ps1 | Alle 24+ Seiten pushen |
| confluence-reorganize.ps1 | Kategorien sortieren |
| confluence-push-roadmap-tabelle.ps1 | Seite 24 |
| confluence-push-teamreorg.py | Seite 25 |
| confluence-push-teams-trapo.py | Seite 26 |
| confluence-check-pages.ps1 | Diagnose |
| confluence-delete-test.ps1 | Test-Seite loeschen |
| jira-critical-scan.py | Risiko-Radar (woechentlich) |
| jira-bssupport-releases.py | BSSUPPORT Bugs/Releases |
| jira-abrechnung.py | Abrechnungs-Tickets |
| gitlab-branches.py | Branch-Analyse (13 Services) |
| gitlab-check-libraries.py | Shared Libs CI/Tests |
| sonarqube-analyse.py | Coverage pro Team |
| inb-analyse.py | INB-PDFs extrahieren |
| inb-search.py | INB gezielt durchsuchen |
| trapo-read.py | TrassenOrder von systelone laden |
| git-push.py | Git Push via dulwich |
| check-remote.py | Remote-Repo Status pruefen |
| set-default-branch.py | Default Branch umstellen |
## Korrekturen diese Session
- TTT = TAF/TAP TSI (nicht Test/Technik/Transfer)
- INB = Infrastrukturnutzungsbedingungen (nicht SNB)
- NAÄ = Netzausgeloeste Aenderungen (neu im Glossar)
- Default Branch: main → master umgestellt
- API-Limits dokumentiert (systelone sehr restriktiv!)
- Datum: System zeigt 07.05.2026 (nicht 30.04. wie anfangs angenommen)
bahn/project-audit/analysis/UEBERSICHT.md
+28
View File
@@ -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 |
bahn/project-audit/analysis/architektur-diagramme.md
+256
View File
@@ -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]
```
bahn/project-audit/analysis/geschaeftsprozesse.md
+149
View File
@@ -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)
bahn/project-audit/analysis/iteration-01-gesamtbild.md
+199
View File
@@ -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
bahn/project-audit/analysis/iteration-01-gitlab-erstanalyse.md
+134
View File
@@ -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)
bahn/project-audit/analysis/iteration-02-technical-deepdive.md
+154
View File
@@ -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
bahn/project-audit/analysis/iteration-03-team-workflow.md
+192
View File
@@ -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
bahn/project-audit/analysis/iteration-04-roadmap-aktionsplan.md
+100
View File
@@ -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
```
bahn/project-audit/analysis/jira-analyse-zusammenfassung.md
+81
View File
@@ -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)
bahn/project-audit/analysis/jira-boards-fachlich-ttti.md
+109
View File
@@ -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)
bahn/project-audit/analysis/jira-teams-deepdive.md
+74
View File
@@ -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.
bahn/project-audit/analysis/meilensteinplan-12m.md
+307
View File
@@ -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 |
bahn/project-audit/analysis/personal-bug-analyse.md
+298
View File
@@ -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.
bahn/project-audit/analysis/personen-rollen.md
+92
View File
@@ -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 |
bahn/project-audit/analysis/po-roadmap-input.md
+170
View File
@@ -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
bahn/project-audit/analysis/roadmap-tabelle.md
+146
View File
@@ -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 |
bahn/project-audit/analysis/roadmap-uebergreifend-und-pathos.md
+127
View File
@@ -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 |
bahn/project-audit/analysis/runbook-analyse.md
+201
View File
@@ -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)
bahn/project-audit/analysis/sonarqube-deepdive.md
+142
View File
@@ -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.
bahn/project-audit/analysis/strategische-notizen.md
+56
View File
@@ -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)
bahn/project-audit/analysis/team-reorganisation.md
+340
View File
@@ -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?
bahn/project-audit/analysis/ttsi-programm-analyse.md
+98
View File
@@ -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
```
bahn/project-audit/analysis/velocity-12m-analyse.md
+78
View File
@@ -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
bahn/project-audit/analysis/velocity-analyse.md
+55
View File
@@ -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.
bahn/project-audit/data/INB-2027-Anlage-1-0-data.pdf
BIN
View File
Binary file not shown.
bahn/project-audit/data/INB-2027-Anlage-1-0-data.txt
+214
View File
@@ -0,0 +1,214 @@
Anlage 1.0 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
Abkürzungsverzeichnis
DB InfraGO AG
Zentrale
I.IBN
Anlage 1. 0 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
-Abkürzungsverzeichnis - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 2 von 5
Abkürzung Bezeichnung
Abs. Absatz
Abzw. Abzweig
AEG Allgemeines Eisenbahngesetz
AGB -GSMR -DL Allgemeinen Geschäftsbedingungen für GSM -R-Dienstleistungen
AktG Aktiengesetz
APN Anlagenportal -Netz
APS Anlagenpreissystem
ArbSchG Gesetz über die Durchführung von Maßnahmen des Arbeitsschutzes zur
Verbesserung der Sicherheit und des Gesundheitsschutzes der
Beschäftigten bei der Arbeit
aT außergewöhnliche Transporte
AwSV Verordnung über Anlagen zum Umgang mit wassergefährdenden Stoffen
BAV Bundesamt für Verkehr
BFBI Flughafentunnel Berlin -Brandenburg International
BBodS chG Gesetz zum Schutz vor schädlichen Bodenveränderungen und zur
Sanierung von Altlasten (Bundes -Bodenschutzgesetz )
BdS Betreiber der Schienenwege
Bf Bahnhof
Bft. Bahnhofsteil
BGB Bürgerliches Gesetzbuch
BMVBS Bundesministerium für Verkehr, Bau und Stadtentwicklung
BNetzA Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und
Eisenbahnen
BÜ Bahnübergang/Bahnübergänge
BZ Betriebszentrale
Bza Betrieb, Zugförderung und außergewöhnlich
Bza-Nr. Nummer der „Machbarkeitsstudie aT“
CID Corridor Information Document
CIP Customer Information Platform
CIS „Charging Information System“
DT AG Festnetz -Anschlussmöglichkeit
EBA Eisenbahn -Bundesamt
EBHaftPflV Verordnung übe r die Haftpflichtversicherung der Eisenbahnen
EBO Eisenbahn -Bau- und Betriebsordnung
EIGV Eisenbahn -Inbetriebnahmegenehmigungsverordnung
EIU Eisenbahninfrastrukturunternehmen
ENV Einzelnutzungsvertrag
ENV-SE Einzelnutzungsvertrag für Serviceeinrichtungen
EOW Elektrisch -ortsgestellte Weichen
ERTMS “European Rail Traffic Management System ”
Anlage 1. 0 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
-Abkürzungsverzeichnis - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 3 von 5 Abkürzung Bezeichnung
ERegG Eisenbahnregulierungsgesetz
ERFA Europäische Vereinigung für Güterverkehr
ESiV Eisenbahnsicherheitsverordnung
ESO Eisenbahns ignalordnung
ETCS „European Train Control System“
EU-VO Verordnung der Europäischen Union
EVU Eisenbahnverkehrsunternehmen
Fernbf Fernbahnhof
FTE Forum Train Europe
GeFo Leitung zum Anschluss eines ortsfesten GSM -R Fernsprechers
GGVSE B Gefahrgutverordnung Straße, Eisenbahnen und Binnen schifffahrt
GNT Geschwindigkeitsüberwachung für NeiTech -Züge
Grundsatz -INV Infrastrukturnutzungsvertrag, der Grundsätze des Vertragsverhäl tnisses
regelt
GSM -R “Global System for Mobile Communications – Rail”
Gz Güterzug
Hbf Hauptbahnhof
Hz Hertz
IBN Inbetriebnahme/Inbetriebnahmetermin
IKAs Informations - und Kommunikationssystem für Anlagenstörungen – IT-Tool
INB Infrastrukturnutzungsbedingungen der DB InfraGO AG (soweit ohne
Jahreszahl, handelt es sich um die aktuell geltenden)
ISR Infrastrukturregister
KonVEIV Konventioneller -Verkehr -Eisenbahn -Interoperabilitätsverordnung
(Verordnung über die Interoperabilität des konventionellen
transeuropäischen Eisenbahnsy stems zur Umsetzung der europäischen
Richtlinie 2001/16/EG)
KoRil Konzernrichtlinie
KV Kombinierter Verkehr
La Langsamfahrstelle
LaTPS Entgeltkomponente, die den lär mbezogenen Auswirkungen des
Zugbetriebs im Güterverkehr Rechnung trägt
LeiDis -NK Leitsystem zur Netzdisposition Kunde
Lü Lademaßüberschreitung
LZB Linienförmige Zugbeeinflussung
NBN Nutzungsbedingungen Netz der DB InfraGO AG
NBS Nutzungsbedingungen für die Serviceeinrichtungen der DB InfraGO AG
NFLS Notfallleitstelle
NL Nutzlänge
NZV Eisenbahn -Netzzugangsvereinbarung
ÖRil (Zp) Örtliche Richtlinien für das Zugpersonal
OSS One-Stop-Shop
Anlage 1. 0 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
-Abkürzungsverzeichnis - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 4 von 5 Abkürzung Bezeichnung
PaP Prearranged path
pathOS TAF/TAP -TSI-konformes Trassenanmeldesystem der DB InfraGO AG
Pbf. Personenbahnhof
PCS „Path Coordination System“
Pz Personenzug
PZB Punktförmige Zugbeeinflussung
Rbf. Rangierbahnhof
RIC Übereinkommen über die gegenseitige Benutzung der Personen - und
Gepäckwagen im internation alen Verkehr
RID Vero rdnung für die internationale Eisenbahnbeförderung gefährlicher
Güter
Ril Richtlinie
RiR Rangieren in Rangierfunkgruppen
RIS Reisendeninformationssystem
RIV Übereinkommen über die gegenseitige Benutzung der Güterwagen im
internationalen Ve rkehr
RNE RailNetEurope
RNI DB RegioNetz Infrastruktur GmbH
RoR Rangieren ohne Rangierfunkgruppen
SEV Schienenersatzverkehr
SFS Schnellfahrstrecke
SGV Schienengüterverkehr
SNB Schienennetz -Benutzungsbedingungen
SNV Stationsnutzungsvertrag
SPFV Schienenpersonenfernverkehr
SPNV Schienenpersonennahverkehr
SPV Schienenpersonenverkehr
TAF/TAP TSI Technische Spezifikation für die Interoperabilität Telematikanwendungen
für den Güter -/ Personenverkehr (Technical Specification for
Interoperability (TSI) relating to Telematics Applications for
Freight/Passenger Services (TAF/TAP) )
TEIV „Transeuropäische -Eisenbahn -Interoperabilitätsverordnung “
Tfz Triebfahrzeug
TIS „Train Information System“
TNB technische Netzzugangsbedingungen
TPN Trassenportal der DB InfraGO AG
TPS Trassenpreissystem
Trkm Trassenkilometer
TSI Technische Spezifikationen für die Interoperabilität
TTR Redesign of the international Timetabling Process
USchadG Gesetz über die Vermeidung und Sanierung von Umweltschäden
(Umweltschadensgesetz )
V Volt
Anlage 1. 0 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
-Abkürzungsverzeichnis - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 5 von 5 Abkürzung Bezeichnung
VDV Verband Deutscher Verkehrsunternehmen
VU Verspätungsursachen
ZB Zugangsberechtigte r
bahn/project-audit/data/INB-2027-Anlage-4-2-2-data.pdf
BIN
View File
Binary file not shown.
bahn/project-audit/data/INB-2027-Anlage-4-2-2-data.txt
+229
View File
@@ -0,0 +1,229 @@
Anlage 4.2 .2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen Click&Ride
Seite 1 von 5
Gültig ab: 13.12.2026
Die DB InfraGO AG bietet ab dem 17.12.2019 mit Click&Ride (C&R) eine neue Anwendung zur
Trassenanmeldung. Trassenanmeldungen über C&R sind nur für Trassen des Gelegenheitsver-
kehrs im Schienengüterverkehr , für Leerfahrten im Schienenpersonenverkehr und Überführungs-
fahrten im Schienengüter - und Schienenpersonenverkehr mit einer Frist von weniger als 5 Arbeits-
tagen vor gewünschter Abfahrtszeit möglich, sofern diese Trassenanmeldungen
 ausschließlich das Schienennetz der DB InfraGO AG und/oder die unter Abschnitt 9 aufge-
zählten Strecken, auf denen die DB InfraGO AG fahrplanbildend ist, nutzen,
 keinen Fall einer besonders aufwändigen Bearbeitung darstellen (ausgenommen sind Züge
des Kombinierten Verkehrs, die über C&R bestellbar sind) und
 keinen Ankunftszeitpunkt haben, der später als 23.59h am Folgetag des Abfahrtstages liegt.
(1) Zugang
Die Anmeldung zur Anwendung (das Login) erfolgt über das Infraportal . Näheres ist den Nutzungs-
bedingungen zum Infraportal (Anlage 3.4.3.1 der INB) zu entnehmen.
Um Click&Ride zu benutzen, navigieren Sie in Ihrem Browser1 einfach zu
https://clickandride.dbinfrago.com und melden sich mit Ihren Zugangsdaten an.
Click&Ride ist benutzbar auf Smartphones, Tablets und Desktop -Computern.
(2) Dokumentation
Die DB InfraGO AG stellt den angemeldeten Zugangsberechtigten in elektronischer Form ein aktu-
elles Handbuch zur Verfügung, das die wesentlichen Funktionen und Abläufe bei der Nutzung von
C&R beschreibt.
Weitere Informationen sind im Internet unter https://www.dbinfrago.com/clickandride erhältlich.
(3) Beratung
Die DB InfraGO AG berät und unterstützt ihre Kunden umfassend bei fachlichen und technischen
Fragen in Zusammenhang mit C&R. Die fachliche Betriebsführung steht telefonisch für Rückfragen
von Montag bis Freitag von 08.00 bis 15.30 Uhr zur Verfügung. Darüber hinaus können jederzeit
rund um die Uhr Rückfragen auch per E -Mail unter next-support@deutschebahn.com gestellt wer-
den.
(4) Verfügbarkeit
Der Zugang zu C&R steht grundsätzlich uneingeschränkt, d.h. 24 Stunden am Tag, 365 Tage im
Jahr, zur Verfügung. Hiervon ausgenommen sind notwendige geplante Wartungsfenster sowie Stö-
1 Aktuell ist Click&Ride auf den Webbrowser Chrome (Mobil und Desktop) optimiert. Mit anderen Webbrowsern kann eine
erfolgreiche Benutzung aktuell noch nicht gewährleistet werden.
Anlage 4.2.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen Click&Ride
Seite 2 von 5
Gültig ab: 13.12.2026
rungsfälle. Geplante Wartungsarbeiten werden, sofern möglich, in Tagesrandlagen bzw. nachts
durchgeführt.
Der Zugangsberechtigte ist selbst verantwortlich, die zur Nutzung von C&R notwendigen techni-
schen Voraussetzungen (z.B. Ladezustände, Tk -Abdeckung Arbeitsspeicher) zu erfüllen.
(5) Rückfallebene
Im Fall des technischen Ausfalls bzw. im Fall von Übertragungsstörungen von C&R steht für alle
Zugangsberechtigten als Rückfallebene die Trassenanmeldemöglichkeit über das Trassenanmelde-
system der DB InfraGO AG zur Verfügung.
(6) Datensicherheit
Für die Datensicherheit beim Zugang zu C&R ist der ZB durch Sicherstellen der ausschließlichen
Nutzung durch den/die befugten Mitarbeiter und/oder geeignete technische Vorkehrungen (Pass-
wortsicherung) zu gewährleisten.
Die Anwendung C&R hält keine kunden - bzw. nutzerbezogenen Daten vor. Solche Daten werden
aus angebundenen, internen Systemen der DB InfraGO AG bezogen und nur soweit für die Tra s-
senanfrage verwendet, wie dies für die Anmeldung, Konstruktion der jeweiligen Trasse und das sich
hierauf beziehende Angebot erforderlich ist. Ziff. 3.3.4.6 INB bleibt unberührt. Session -Daten wer-
den ausschließlich lokal auf den Endgeräten des ZB gespeichert und können dort nach Ende der
Session gelöscht werden.
(7) Missbräuchliche Verwendung
Der Kunde verpflichtet sich, die Anwendung C&R nicht missbräuchlich zu nutzen, insbesondere
 die Verfügbarkeit des C&R -Systems nicht durch übermäßig wiederholte (insbesondere in-
nerhalb kürzerer Zeit wiederholte) Anmeldungen und/oder automatische Anmeldesysteme zu
beeinträchtigen,
 keine Viren, unzulässige Werbesendungen, Ketteninformationen oder sexistische, rassisti-
sche oder anderweitig belästigende Kommentare zu übertragen,
 keine Rechte Dritter, insbesondere Rechte der genutzten TK -Unternehmen, Schutzrechte
(z.B. Urheber - und Markenrechte) zu verletzen,
 nicht gegen eisenbahnrechtliche Vorschriften und Regelungen des betrieblich -technischen
Regelwerks der DB InfraGO AG (vgl. Ziff. 3.2.1.2.3 INB) zu verstoßen.
Bei Zuwiderhandlungen behält sich die DB InfraGO AG vor, den Zugang zu C&R nutzerscharf zeit-
weilig zu sperren. Der betroffene ZB wird hierüber schriftlich in Kenntnis gesetzt.
Bei wiederholten oder besonders schwerwiegenden Missbräuchen sperrt die DB InfraGO AG den
Zugang endgültig.
(8) Laufzeit/Kündigung
Anlage 4.2.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen Click&Ride
Seite 3 von 5
Gültig ab: 13.12.2026
Nutzerzugänge zu C&R sind während des Vorliegens der Allgemeinen Zugangs voraussetzungen zu
den Schienenwegen der DB InfraGO AG gem. Ziff. 3.2 INB gültig. Entfallen die dort genannten Vo-
raussetzungen (z.B. durch Kündigung von Nutzungsverträgen), erfolgt eine automatische Sperrung
aller zugeordneten Zugänge. ZB oder einbezogene EVU, für die Regelungen nach Ziff. 5.9.2 INB
bestehen, sind von der Nutzung von C&R ausgeschlossen.
(9) Fahrplanbildende Strecken der DB InfraGO AG im Sinne von Ziffer 4.2.2 f) ers-
ter Aufzählungspunkt der INB und Anlage 4.2.2. Einleitungstext
Zusätzlich zu den DB InfraGO -eigenen Strecken können in C&R für folgende Strecken Trassenan-
meldungen abgegeben werden:
Streckennummer Strecke / Abschnitt
1043 Neumünster - Neumünster Süd AKN
1117 Lübeck -Kücknitz - Lübeck Skandinavienkai
1137 Brandenbaum - Lübeck Konstinbahnhof
1248 Hamburg -Veddel - Hamburg Süd
1253, 1294, 1295, 1296 Hamburg Süderelbbrücke - Hamburg -Waltershof
1254 Hamburg -Wilhelmsburg - Hamburg Hohe Schaar Süd
1293 Hamburg -Hausbruch - Hamburg -Hausbruch Mitte
1297 Hamburg Süd DB -Grenze - Hamburg Süd
1415, 9149 Bremen -Neustadt - Bremen -Grolland
1425 Bremen Inlandshafen Stw If - Bremen Stahlwerke
1554 Wilhelmshaven Ölweiche - Wilhelmshaven JadeWeserPort
1576 Emden - Emden Hbf Volkswagenwerk
1824 Einbeck -Salzderhelden - Einbeck Mitte
1922 Groß Gleidingen - Beddingen VPS
2316 Duisburg Sigle - Duisburg Hafen
2423, 2727 Düsseldorf -Gerresheim - Wuppertal -Dornap Abzw
2530 Neuss Pbf Westseite - Kaarster See
Anlage 4.2.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen Click&Ride
Seite 4 von 5
Gültig ab: 13.12.2026
Streckennummer Strecke / Abschnitt
2950 Hörne - Dissen -Bad Rothenfelde DB -Grenze
3443, 9498 Wörth (Rhein) - Wörth (Rhein) Alte Bahnmeisterei
4201 Eppingen - Stebbach
4220 Karlsruhe West - Karlsruhe Hafen
4228 Karlsruhe Rheinbrücke - Karlsruhe Rheinbrücke Raffinerien
4633 Tübingen Hbf - Herrenberg (ZÖA)
4841 Maulbronn West - Maulbronn
4850, 4851 Pforzheim Maihälden - Bad Wildbad
5865 Regensburg Hafenbrücke - Regensburg Bayernhafen
5941 Nürnberg -Eibach - Nürnberg Hafen
6264 Schwarzenberg (Erzgebirge) - Zwickau (Sachsen) Hbf
6426 Borstel (Kreis Stendal) - Niedergörne
6533 Fredersdorf (bei Berlin) - Rüdersdorf (bei Berlin)
6559, 6560 Wiesenau (Abzw) - Ziltendorf EKO - Ziltendorf
6623 Cranzahl - Annaberg -Buchholz
6624 Annaberg -Buchholz Süd - Schwarzenberg (Erzgebirge)
6626 Johanngeorgenstadt - Schwarzenberg (Erzgebirge)
6644 Annaberg -Buchholz - Flöha
6645 Chemnitz Süd - Aue (Sachsen)
6661 Kayna - Raitzhain
6718 Hohenebra - Ebeleben
6728 Bernterode West - Deuna Zementwerk Werkbahnhof
6775 Bergen auf Rügen - Putbus
Anlage 4.2.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen Click&Ride
Seite 5 von 5
Gültig ab: 13.12.2026
Streckennummer Strecke / Abschnitt
6949 Bentwisch - Poppendorf
7318 Passow (Uckermark) - Stendell (PCK)
7353 Wustermark Rbf Wot -Wustermark Rbf
7356 Wustermark Nord (GVZ) - Wustermark Awf
7476 Rommerskirchen RWE Power AG - Rommerskirchen
7630 Beddingen Nordkopf - Beddingen VPS - Beddingen
7636 Bremerhaven Kaiserhafen - Bremerhaven Nordhafen
7644, 7647 Kiel Hbf (Ss) - Kiel Süd (Ss)
7651 Hannover -Linden Hafen - Ha-Li Hafen SHH
7848 Espenhain DB -Grenze - Espenhain
9107 Kiel Süd (Ss) - Kiel Schulen am Langsee
9130 Bremerhaven Kaiserhafen - Bremerhaven Seehafen DB -Grenze
9133 Bremerhaven -Speckenbüttel - Bremerhaven Imsumer Deich
9134 Weddewarden - Bremerhaven Weddewarder
9146 Bremen Inlandshafen DB -Grenze - Bremen Inlandshafen
9170, 9173 Celle Nord DB -Grenze - Celle Nord
9412 Bruchsal - Ubstadt Mülldeponie
9603 Brühl Gbf - Brühl -Vochem
9609 Köln-Bickendorf - Köln-Ehrenfeld DB -Grenze
9617 Köln-Mülheim Grenze - Leverkusen Chemiepark NE
9706 Leuna Streckenwechsel 6810/Anschlussbahn - Lochau Werkbahnhof
MUEG
9707 Schmirchau Gbf - Raitzhain
❑
bahn/project-audit/data/INB-2027-Anlage-4-2-data.pdf
BIN
View File
Binary file not shown.
bahn/project-audit/data/INB-2027-Anlage-4-2-data.txt
+160
View File
@@ -0,0 +1,160 @@
Anlage 4.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen pathOS
Seite 1 von 3
Gültig ab: 13.12.2026
Zum Fahrplanjahr 2027 führt die DB InfraGO ein neues Trassenanmeldesystem ein (pathOS = path
Ordering System, entsprechend dem Begriff „path“ aus der TAF/TAP TSI), welches die EU -
Verordnungen TAF/TAP TSI umsetzt und künftig das Trassenanmelde - und Angebotsmedium der
DB InfraGO AG ist. Die DB InfraGO AG stellt allen Kunden über das Internet einen Zugang zum
Trassenanmeldesystem für die Anmeldung von Trassen und zur Entgegennahme von Angeboten
und Rückmeldungen bereit. Dieser Zugang (im folgenden Webportal genannt) richtet sich vorrangig
an Zugangsberechtigte (ZB) mit geringem oder unregelmäßigem Auftragsvolumen, welche über
keine eigene Software zur Kommunikation mit dem Trassenanmeldesystem über eine Schnittstelle
verfügen und ist vom Kunden über das Infraportal zu beantragen.
Weiterhin stellt die DB InfraGO AG eine einheitliche elektronische Schnittstelle für den Datenaus-
tausch zwischen einem IT -System des ZB und dem Trassenanmeldesystem der DB InfraGO zur
Anmeldung von Trassen und zur Entgegennahme von Angeboten und Rückmeldungen bereit. In
TAF/TAP spricht man an dieser Stelle auch vom sogenannten „Common Interface“. Mit der elektro-
nischen Schnittstelle richtet sich die DB InfraGO AG vorrangig an ZB mit großem und regelmäßi-
gem Auftragsvolumen.
(1) Antrag und Zugangsdaten
Die Anmeldung zur Anwendung pathOS erfolgt über das Infraportal. Näheres ist den Nutzungsbe-
dingungen zum Infraportal (Anlage 3.4.3.1) zu entnehmen. Voraussetzung ist u.a., dass der ZB ei-
nen Company Code hat (pro EVU bzw. ZB, dieser ist elementarer Bestandteil von TAF/TAP TSI)
und entsprechend für die relevanten Geschäftspartnernummern freigeschaltet ist (diese Freischal-
tung erfolgt im Infraportal durch die „Superuser“ der jeweiligen ZB selbst).
Ansprechpartner für alle Themen rund um die Userverwaltung ist die #Einfachbahn: Einfach-
bahn@deutschebahn.com
In pathOS ist die Zusammenarbeit verschiedener Nutzer innerhalb eines EVU einfach möglich –
man kann gegenseitige Anmeldungen sehen und sogar weiterbearbeiten. Eine separate „Vertreter-
regel“ entfällt.
Um das Trassenanmeldesystem zu benutzen, navigieren Sie in Ihrem Browser entweder zum
Infraportal oder direkt zur Log -In-Seite des neuen Trassenanmeldesystems.
Soweit die Schnittstelle genutzt werden soll, muss das genutzte Schnittstellenverfahrens des ZB
benannt werden und die erforderlichen Daten (z.B. Company Code, Verfahren etc.) übernommen
werden (Voraussetzung ist die bereits erfolgte Freigabe dieses Verfahrens durch die DB InfraGO
AG sowie, wenn erforderlich, der Erwerb eines RNE -Zertifikats durch den ZB selbst). Anschließend
erfolgt eine individuelle Freigabe des jeweiligen ZB. Ansprechpartner seitens DB InfraGO zu diesem
Thema ist die fachliche Betriebsführung von pathOS (s. Kapitel „Beratung“).
(2) Dokumentation
Die DB InfraGO AG stellt den angemeldeten ZB in elektronischer Form neben Installationshinwei-
sen ein aktuelles Handbuch zur Verfügung, das die wesentlichen Funktionen und Abläufe bei der
Anlage 4.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen pathOS
Seite 2 von 3
Gültig ab: 13.12.2026
Nutzung des Webportals beschreibt. Zusätzlich werden (primär um die Einführung zu begleiten)
Schulungsunterlagen in verschiedenen Formaten und Medien online bereitgestellt.
Für die Nutzung der Schnittstelle stellt die DB InfraGO AG in elektronischer Form eine aktuelle und
vollständige Schnittstellendokumentation zur Verfügung. Mit Einführung von TAF/TAP TSI spielen
hier auch europäische Gremien eine Rolle, denn im Regelfall 2x pro Jahr gibt es europaweit neue
Vorgaben für die zugrundeliegende XSD -Datei der Schnittstelle, die anschließend von der DB In-
fraGO auf Umsetzungsnotwendigkeit geprüft wird. Diese muss im Anschluss auch von den Schnitt-
stellenpartnern übernommen werden.
Alle relevanten Unterlagen sind im Internet unter https://www.dbinfrago.com/taf -tap-tsi sowie
http://www.dbinfrago.com/pathos erhältlich.
(3) Beratung
Die DB InfraGO AG berät und unterstützt ihre Kunden umfassend bei fachlichen und technischen
Fragen in Zusammenhang mit dem Trassenanmeldesystem pathOS durch die fachliche Betriebs-
führung von pathOS. Rückfragen können per E -Mail an pathOS@deutschebahn.com gestellt wer-
den.
(4) Zugang und Verfügbarkeit
Der Zugang zum Trassenanmeldesystem pathOS der DB InfraGO AG steht grundsätzlich uneinge-
schränkt, d.h. 24 Stunden am Tag, 365 Tage im Jahr, zur Verfügung. Hiervon ausgenommen sind
notwendige geplante Wartungsfenster sowie Störungsfälle. Geplante Wartungsarbeiten werden,
sofern möglich, stets in Tagesrandlagen bzw. nachts durchgeführt.
(5) Information
Die DB InfraGO AG informiert über das Stattfinden sowie die Dauer planmäßiger Einschränkungen
mit einem Vorlauf von mindestens 36 Stunden. Im Störungsfall erfolgt eine umgehende Information,
ggf. verbunden mit Handlungsempfehlungen.
Informationen über Änderungen der Schnittstellendokumentation erfolgen im Regelfall in Form einer
Vorinformation mindestens neun Monate und in verbindlicher Form mindestens sechs Monate vor
der Umsetzung.
(6) Rückfallebene
Während etwaiger Einschränkungen der Erreichbarkeit von pathOS steht für alle ZB als Rückfall-
ebene die Trassenanmeldemöglichkeit per Fax oder E -Mail an netzfahrplanerstel-
lung@deutschebahn.com zur Verfügung. Die für eine solche Trassenanmeldung erforderlichen
Formulare sind in der Richtlinie 402.0202 enthalten und werden auch im Internet zur Verfügung ge-
stellt: Formulare Trassenanmeldung .
Die zuständigen Ansprechpartner und Adressen sind auf den Internetseiten der DB InfraGO erhält-
lich: Trassenanmeldung GelV .
Anlage 4.2 zu den Infrastrukturnutzungsbedingungen der DB InfraGO
AG 2027
Nutzungsbedingungen pathOS
Seite 3 von 3
Gültig ab: 13.12.2026
(7) Datensicherheit beim Kunden und missbräuchliche Verwendung
Nach Erhalt des Zugangs zu pathOS ist der ZB verpflichtet, die Datensicherheit durch Sicherstellen
der ausschließlichen Nutzung durch befugte Mitarbeiter:innen zu gewährleisten.
Der Kunde verpflichtet sich, pathOS nicht missbräuchlich zu nutzen, insbesondere
• keine Viren, unzulässige Werbesendungen, Ketteninformationen oder sexistische, rassistische
oder anderweitig belästigende Kommentare zu übertragen,
• keine Rechte Dritter, insbesondere Rechte der genutzten TK -Unternehmen, Schutzrechte
(z.B. Urheber - und Markenrechte) zu verletzen,
• nicht gegen eisenbahnrechtliche Vorschriften und Regelungen des betrieblich -technischen
Regelwerks der DB InfraGO AG (siehe INB) zu verstoßen.
Bei Zuwiderhandlungen behält sich die DB InfraGO AG vor, den Zugang zu pathOS nutzerscharf
zeitweilig zu sperren. Der betroffene ZB wird hierüber schriftlich in Kenntnis gesetzt. Bei wiederhol-
ten oder besonders schwerwiegenden Missbräuchen sperrt die DB InfraGO AG den Zugang endgül-
tig.
(8) Mitteilungen des Kunden
Sofern sich beim ZB Zugangs - und Kommunikationsdaten (insbesondere die hinterlegte E -Mail-
Adresse) ändern bzw. seine Zugangsvoraussetzungen entfallen, ist er verpflichtet, dies im Kunden-
portal anzupassen und ggfs. die Kundenberatung der DB InfraGO darüber zu informieren. Über den
Superuser muss der ZB eigenständig Berechtigungen anpassen bzw. entfernen.
(9) Systemvoraussetzungen des Kunden
Der ZB ist selbst dafür verantwortlich, die zur Nutzung des Trassenanmeldesystems notwendigen
technischen Voraussetzungen zu erfüllen. Einzelheiten und Anforderungen hierzu können dem
Handbuch entnommen werden.
❑
bahn/project-audit/data/INB-2027-Anlage-5-2-data.pdf
BIN
View File
Binary file not shown.
bahn/project-audit/data/INB-2027-Anlage-5-2-data.txt
+1539
View File
File diff suppressed because it is too large Load Diff
bahn/project-audit/data/INB-2027-Anlage-5-3-data.pdf
BIN
View File
Binary file not shown.
bahn/project-audit/data/INB-2027-Anlage-5-3-data.txt
+890
View File
@@ -0,0 +1,890 @@
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH
Anlage 5.3a: Liste der Entgelte der DB InfraGO AG
Anlage 5.3b: Liste der Entgelte der DB RegioNetz Infrastruktur GmbH
Anlage 5.3c: Liste der Entgelte für die Nutzung von Personenbahnhöfen der DB RegioNetz
Infrastruktur GmbH
DB InfraGO AG
Zentrale
I.IBN
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 2 von 27
Anlage 5.3a: Liste der Entgelte der DB InfraGO AG
Entgelte Schiene ngüterverkehr
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt
Entgelt für Nicht -
stornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm ]
Standard 4,44 1,80 0,03 0,43 0,57 1,14 2,00 3,43 5,72
Sehr schwer 6,09 3,09 0,03 0,48 0,64 1,29 2,25 3,86 7,84
Gefahrgutganzzug 5,54 1,80 0,03 0,60 0,79 1,59 2,78 4,76 7,94
Güternahverkehr 2,68 1,19 0,03 0,26 0,34 0,68 1,20 2,05 3,42
Lokfahrt 2,68 0,96 0,03 0,29 0,38 0,77 1,34 2,30 3,84
Standard Z-Flex 4,24 1,80 0,03 0,40 0,53 1,06 1,86 3,19 5,32
Sehr schwer Z -Flex 5,89 3,09 0,03 0,45 0,60 1,21 2,11 3,62 7,59
Gefahrgutganzzug Z-Flex 5,34 1,80 0,03 0,57 0,75 1,51 2,64 4,52 7,54
Güternahverkehr Z-Flex 2,48 1,19 0,03 0,23 0,30 0,60 1,06 1,81 3,02
Standard Schnell 5,44 1,80 0,03 0,58 0,77 1,54 2,70 4,63 7,72
Gefahrgutganzzug Schnell 6,54 1,80 0,03 0,75 0,99 1,99 3,48 5,96 9,94
Güternahverkehr Schnell 3,68 1,19 0,03 0,41 0,54 1,08 1,90 3,25 5,42
Standard Z -Flex Schnell 5,24 1,80 0,03 0,55 0,73 1,46 2,56 4,39 7,32
Gefahrgutganzzug Z -Flex Schnell 6,34 1,80 0,03 0,72 0,95 1,91 3,34 5,72 9,54
Güternahverkehr Z -Flex Schnell 3,48 1,19 0,03 0,38 0,50 1,00 1,76 3,01 5,02
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 3 von 27
Entgelte Schienenpersonennahver kehr
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für Nicht -
stornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Lastf ahrt Baden -Württemberg 7,811 0,97 0,03 0,14 1,41 2,81 4,92 7,03 10,54
Lastfahrt Bayern 7,569 0,97 0,03 0,14 1,36 2,71 4,75 6,78 10,18
Lastfahrt Berlin 8,716 0,97 0,03 0,16 1,59 3,17 5,55 7,93 11,90
Lastfahrt Brandenburg 8,410 0,97 0,03 0,15 1,52 3,05 5,34 7,62 11,44
Lastfahrt Bremen 8,403 0,97 0,03 0,15 1,52 3,05 5,33 7,62 11,43
Lastfahrt Hamburg 7,716 0,97 0,03 0,14 1,39 2,77 4,85 6,93 10,40
Lastfahrt Hessen 7,525 0,97 0,03 0,13 1,35 2,70 4,72 6,74 10,11
Lastfahrt Mecklenburg -
Vorpommern 8,313 0,97 0,03 0,15 1,51 3,01 5,27 7,53 11,29
Lastfahrt Niedersachsen 7,836 0,97 0,03 0,14 1,41 2,82 4,94 7,05 10,58
Lastfahrt Nordrhein -Westfalen 7,594 0,97 0,03 0,14 1,36 2,72 4,77 6,81 10,21
Lastfahrt Rheinland -Pfalz 7,790 0,97 0,03 0,14 1,40 2,80 4,90 7,00 10,51
Lastfahrt Saarland 7,972 0,97 0,03 0,14 1,44 2,87 5,03 7,19 10,78
Lastfahrt Sachsen 8,039 0,97 0,03 0,15 1,45 2,90 5,08 7,25 10,88
Lastfahrt Sachsen -Anhalt 7,835 0,97 0,03 0,14 1,41 2,82 4,93 7,05 10,57
Lastfahrt Schleswig -Holstein 7,943 0,97 0,03 0,14 1,43 2,86 5,01 7,16 10,74
Lastfahrt Thüringen 7,927 0,97 0,03 0,14 1,43 2,86 5,00 7,14 10,71
Leerfahrt Baden -Württemberg 4,269 0,96 0,03 0,07 0,70 1,40 2,45 3,51 5,26
Leerfahrt Bayern 4,268 0,96 0,03 0,07 0,70 1,40 2,45 3,50 5,26
Leerfahrt Berlin 4,407 0,96 0,03 0,07 0,73 1,46 2,55 3,64 5,47
Leerfahrt Brandenburg 4,647 0,96 0,03 0,08 0,78 1,55 2,72 3,88 5,83
Leerfahrt Bremen 4,580 0,96 0,03 0,08 0,76 1,53 2,67 3,82 5,73
Leerfahrt Hamburg 4,218 0,96 0,03 0,07 0,69 1,38 2,42 3,45 5,18
Leerfahrt Hessen 4,320 0,96 0,03 0,07 0,71 1,42 2,49 3,56 5,34
Leerfahrt Mecklenburg - 4,465 0,96 0,03 0,07 0,74 1,48 2,59 3,70 5,55
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 4 von 27
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für Nicht -
stornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Vorpommern
Leerfahrt Niedersachsen 4,656 0,96 0,03 0,08 0,78 1,56 2,72 3,89 5,84
Leerfahrt Nordrhein -Westfalen 4,280 0,96 0,03 0,07 0,70 1,41 2,46 3,52 5,28
Leerfahrt Rheinland -Pfalz 4,242 0,96 0,03 0,07 0,70 1,39 2,44 3,48 5,22
Leerfahrt Saarland 3,621 0,96 0,03 0,06 0,57 1,14 2,00 2,86 4,29
Leerfahrt Sachsen 4,305 0,96 0,03 0,07 0,71 1,42 2,48 3,54 5,31
Leerfahrt Sachsen -Anhalt 4,386 0,96 0,03 0,07 0,72 1,45 2,54 3,62 5,43
Leerfahrt Schleswig -Holstein 4,336 0,96 0,03 0,07 0,71 1,43 2,50 3,57 5,36
Leerfahrt Thüringen 4,394 0,96 0,03 0,07 0,73 1,45 2,54 3,63 5,45
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 5 von 27
Entgelte Schienenpersonenfernverkehr
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Basic 6,56 1,41 0,02 0,11 1,06 2,13 3,72 5,32 7,98
Basic Schnell 9,56 1,41 0,02 0,17 1,66 3,33 5,82 8,32 12,48
Nacht 3,59 1,41 0,02 0,05 0,47 0,94 1,64 2,35 3,52
Nacht Schnell 6,59 1,41 0,02 0,11 1,07 2,14 3,74 5,35 8,02
Charter/Nostalgie 3,53 0,97 0,03 0,05 0,55 1,10 1,92 2,74 4,11
Punkt -zu-Punkt 5,02 1,41 0,02 0,08 0,76 1,51 2,64 3,78 5,67
Leer-/Lokfahrt 3,53 0,96 0,02 0,05 0,46 0,91 1,60 2,28 3,42
Leer-/Lokfahrt Schnell 6,53 0,96 0,02 0,11 1,06 2,11 3,70 5,28 7,92
Metro Tag Min (bis inkl. 100 km/h) 8,34 1,41 0,02 0,14 1,42 2,84 4,97 7,10 10,65
Metro Tag Mittel (101 km/h) 8,49 1,41 0,02 0,14 1,45 2,90 5,07 7,24 10,86
Metro Tag Mittel (102 km/h) 8,63 1,41 0,02 0,15 1,48 2,95 5,17 7,39 11,08
Metro Tag Mittel (103 km/h) 8,77 1,41 0,02 0,15 1,51 3,01 5,27 7,53 11,29
Metro Tag Mittel (104 km/h) 8,91 1,41 0,02 0,15 1,53 3,07 5,37 7,67 11,51
Metro Tag Mittel (105 km/h) 9,06 1,41 0,02 0,16 1,56 3,13 5,47 7,81 11,72
Metro Tag Mittel (106 km/h) 9,20 1,41 0,02 0,16 1,59 3,18 5,57 7,96 11,93
Metro Tag Mittel (107 km/h) 9,34 1,41 0,02 0,16 1,62 3,24 5,67 8,10 12,15
Metro Tag Mittel (108 km/h) 9,48 1,41 0,02 0,16 1,65 3,30 5,77 8,24 12,36
Metro Tag Mittel (109 km/h) 9,63 1,41 0,02 0,17 1,68 3,35 5,87 8,38 12,58
Metro Tag Mittel (110 km/h) 9,77 1,41 0,02 0,17 1,71 3,41 5,97 8,53 12,79
Metro Tag Mittel (111 km/h) 9,91 1,41 0,02 0,17 1,73 3,47 6,07 8,67 13,00
Metro Tag Mittel (112 km/h) 10,05 1,41 0,02 0,18 1,76 3,52 6,17 8,81 13,22
Metro Tag Mittel (113 km/h) 10,20 1,41 0,02 0,18 1,79 3,58 6,27 8,95 13,43
Metro Tag Mittel (114 km/h) 10,34 1,41 0,02 0,18 1,82 3,64 6,37 9,10 13,65
Metro Tag Mittel (115 km/h) 10,48 1,41 0,02 0,18 1,85 3,70 6,47 9,24 13,86
Metro Tag Mittel (116 km/h) 10,62 1,41 0,02 0,19 1,88 3,75 6,57 9,38 14,07
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 6 von 27
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel (117 km/h) 10,77 1,41 0,02 0,19 1,91 3,81 6,67 9,53 14,29
Metro Tag Mittel (118 km/h) 10,91 1,41 0,02 0,19 1,93 3,87 6,77 9,67 14,50
Metro Tag Mittel (119 km/h) 11,05 1,41 0,02 0,20 1,96 3,92 6,87 9,81 14,72
Metro Tag Mittel (120 km/h) 11,20 1,41 0,02 0,20 1,99 3,98 6,97 9,95 14,93
Metro Tag Mittel (121 km/h) 11,34 1,41 0,02 0,20 2,02 4,04 7,07 10,10 15,14
Metro Tag Mittel (122 km/h) 11,48 1,41 0,02 0,20 2,05 4,10 7,17 10,24 15,36
Metro Tag Mittel (123 km/h) 11,62 1,41 0,02 0,21 2,08 4,15 7,27 10,38 15,57
Metro Tag Mittel (124 km/h) 11,77 1,41 0,02 0,21 2,10 4,21 7,37 10,52 15,79
Metro Tag Mittel (125 km/h) 11,91 1,41 0,02 0,21 2,13 4,27 7,47 10,67 16,00
Metro Tag Mittel (126 km/h) 12,05 1,41 0,02 0,22 2,16 4,32 7,57 10,81 16,21
Metro Tag Mittel (127 km/h) 12,19 1,41 0,02 0,22 2,19 4,38 7,67 10,95 16,43
Metro Tag Mittel (128 km/h) 12,34 1,41 0,02 0,22 2,22 4,44 7,77 11,09 16,64
Metro Tag Mittel (129 km/h) 12,48 1,41 0,02 0,22 2,25 4,49 7,87 11,24 16,86
Metro Tag Mittel (130 km/h) 12,62 1,41 0,02 0,23 2,28 4,55 7,97 11,38 17,07
Metro Tag Mittel (131 km/h) 12,76 1,41 0,02 0,23 2,30 4,61 8,07 11,52 17,28
Metro Tag Mittel (132 km/h) 12,91 1,41 0,02 0,23 2,33 4,67 8,17 11,67 17,50
Metro Tag Mittel (133 km/h) 13,05 1,41 0,02 0,24 2,36 4,72 8,27 11,81 17,71
Metro Tag Mittel (134 km/h) 13,19 1,41 0,02 0,24 2,39 4,78 8,37 11,95 17,93
Metro Tag Mittel (135 km/h) 13,34 1,41 0,02 0,24 2,42 4,84 8,47 12,09 18,14
Metro Tag Mittel (136 km/h) 13,48 1,41 0,02 0,24 2,45 4,89 8,56 12,24 18,35
Metro Tag Mittel (137 km/h) 13,62 1,41 0,02 0,25 2,48 4,95 8,66 12,38 18,57
Metro Tag Mittel (138 km/h) 13,76 1,41 0,02 0,25 2,50 5,01 8,76 12,52 18,78
Metro Tag Mittel (139 km/h) 13,91 1,41 0,02 0,25 2,53 5,07 8,86 12,66 19,00
Metro Tag Mittel (140 km/h) 14,05 1,41 0,02 0,26 2,56 5,12 8,96 12,81 19,21
Metro Tag Mittel (141 km/h) 14,19 1,41 0,02 0,26 2,59 5,18 9,06 12,95 19,42
Metro Tag Mittel (142 km/h) 14,33 1,41 0,02 0,26 2,62 5,24 9,16 13,09 19,64
Metro Tag Mittel (143 km/h) 14,48 1,41 0,02 0,26 2,65 5,29 9,26 13,23 19,85
Metro Tag Mittel (144 km/h) 14,62 1,41 0,02 0,27 2,68 5,35 9,36 13,38 20,07
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 7 von 27
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel (145 km/h) 14,76 1,41 0,02 0,27 2,70 5,41 9,46 13,52 20,28
Metro Tag Mittel (146 km/h) 14,90 1,41 0,02 0,27 2,73 5,46 9,56 13,66 20,49
Metro Tag Mittel (147 km/h) 15,05 1,41 0,02 0,28 2,76 5,52 9,66 13,80 20,71
Metro Tag Mittel (148 km/h) 15,19 1,41 0,02 0,28 2,79 5,58 9,76 13,95 20,92
Metro Tag Mittel (149 km/h) 15,33 1,41 0,02 0,28 2,82 5,64 9,86 14,09 21,14
Metro Tag Mittel (150 km/h) 15,47 1,41 0,02 0,28 2,85 5,69 9,96 14,23 21,35
Metro Tag Mittel (151 km/h) 15,62 1,41 0,02 0,29 2,88 5,75 10,06 14,38 21,56
Metro Tag Mittel (152 km/h) 15,76 1,41 0,02 0,29 2,90 5,81 10,16 14,52 21,78
Metro Tag Mittel (153 km/h) 15,90 1,41 0,02 0,29 2,93 5,86 10,26 14,66 21,99
Metro Tag Mittel (154 km/h) 16,05 1,41 0,02 0,30 2,96 5,92 10,36 14,80 22,20
Metro Tag Mittel (155 km/h) 16,19 1,41 0,02 0,30 2,99 5,98 10,46 14,95 22,42
Metro Tag Mittel (156 km/h) 16,33 1,41 0,02 0,30 3,02 6,04 10,56 15,09 22,63
Metro Tag Mittel (157 km/h) 16,47 1,41 0,02 0,30 3,05 6,09 10,66 15,23 22,85
Metro Tag Mittel (158 km/h) 16,62 1,41 0,02 0,31 3,07 6,15 10,76 15,37 23,06
Metro Tag Mittel (159 km/h) 16,76 1,41 0,02 0,31 3,10 6,21 10,86 15,52 23,27
Metro Tag Max (ab 160 km/h) 16,90 1,41 0,02 0,31 3,13 6,26 10,96 15,66 23,49
Metro Tag Min Schnell (bis 100 km/h) 11,34 1,41 0,02 0,20 2,02 4,04 7,07 10,10 15,15
Metro Tag Mittel Schnell (101 km/h) 11,49 1,41 0,02 0,20 2,05 4,10 7,17 10,24 15,36
Metro Tag Mittel Schnell (102 km/h) 11,63 1,41 0,02 0,21 2,08 4,15 7,27 10,39 15,58
Metro Tag Mittel Schnell (103 km/h) 11,77 1,41 0,02 0,21 2,11 4,21 7,37 10,53 15,79
Metro Tag Mittel Schnell (104 km/h) 11,91 1,41 0,02 0,21 2,13 4,27 7,47 10,67 16,01
Metro Tag Mittel Schnell (105 km/h) 12,06 1,41 0,02 0,22 2,16 4,33 7,57 10,81 16,22
Metro Tag Mittel Schnell (106 km/h) 12,20 1,41 0,02 0,22 2,19 4,38 7,67 10,96 16,43
Metro Tag Mittel Schnell (107 km/h) 12,34 1,41 0,02 0,22 2,22 4,44 7,77 11,10 16,65
Metro Tag Mittel Schnell (108 km/h) 12,48 1,41 0,02 0,22 2,25 4,50 7,87 11,24 16,86
Metro Tag Mittel Schnell (109 km/h) 12,63 1,41 0,02 0,23 2,28 4,55 7,97 11,38 17,08
Metro Tag Mittel Schnell (110 km/h) 12,77 1,41 0,02 0,23 2,31 4,61 8,07 11,53 17,29
Metro Tag Mittel Schnell (111 km/h) 12,91 1,41 0,02 0,23 2,33 4,67 8,17 11,67 17,50
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 8 von 27
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel Schnell (112 km/h) 13,05 1,41 0,02 0,24 2,36 4,72 8,27 11,81 17,72
Metro Tag Mittel Schnell (113 km/h) 13,20 1,41 0,02 0,24 2,39 4,78 8,37 11,95 17,93
Metro Tag Mittel Schnell (114 km/h) 13,34 1,41 0,02 0,24 2,42 4,84 8,47 12,10 18,15
Metro Tag Mittel Schnell (115 km/h) 13,48 1,41 0,02 0,24 2,45 4,90 8,57 12,24 18,36
Metro Tag Mittel Schnell (116 km/h) 13,62 1,41 0,02 0,25 2,48 4,95 8,67 12,38 18,57
Metro Tag Mittel Schnell (117 km/h) 13,77 1,41 0,02 0,25 2,51 5,01 8,77 12,53 18,79
Metro Tag Mittel Schnell (118 km/h) 13,91 1,41 0,02 0,25 2,53 5,07 8,87 12,67 19,00
Metro Tag Mittel Schnell (119 km/h) 14,05 1,41 0,02 0,26 2,56 5,12 8,97 12,81 19,22
Metro Tag Mittel Schnell (120 km/h) 14,20 1,41 0,02 0,26 2,59 5,18 9,07 12,95 19,43
Metro Tag Mittel Schnell (121 km/h) 14,34 1,41 0,02 0,26 2,62 5,24 9,17 13,10 19,64
Metro Tag Mittel Schnell (122 km/h) 14,48 1,41 0,02 0,26 2,65 5,30 9,27 13,24 19,86
Metro Tag Mittel Schnell (123 km/h) 14,62 1,41 0,02 0,27 2,68 5,35 9,37 13,38 20,07
Metro Tag Mittel Schnell (124 km/h) 14,77 1,41 0,02 0,27 2,70 5,41 9,47 13,52 20,29
Metro Tag Mittel Schnell (125 km/h) 14,91 1,41 0,02 0,27 2,73 5,47 9,57 13,67 20,50
Metro Tag Mittel Schnell (126 km/h) 15,05 1,41 0,02 0,28 2,76 5,52 9,67 13,81 20,71
Metro Tag Mittel Schnell (127 km/h) 15,19 1,41 0,02 0,28 2,79 5,58 9,77 13,95 20,93
Metro Tag Mittel Schnell (128 km/h) 15,34 1,41 0,02 0,28 2,82 5,64 9,87 14,09 21,14
Metro Tag Mittel Schnell (129 km/h) 15,48 1,41 0,02 0,28 2,85 5,69 9,97 14,24 21,36
Metro Tag Mittel Schnell (130 km/h) 15,62 1,41 0,02 0,29 2,88 5,75 10,07 14,38 21,57
Metro Tag Mittel Schnell (131 km/h) 15,76 1,41 0,02 0,29 2,90 5,81 10,17 14,52 21,78
Metro Tag Mittel Schnell (132 km/h) 15,91 1,41 0,02 0,29 2,93 5,87 10,27 14,67 22,00
Metro Tag Mittel Schnell (133 km/h) 16,05 1,41 0,02 0,30 2,96 5,92 10,37 14,81 22,21
Metro Tag Mittel Schnell (134 km/h) 16,19 1,41 0,02 0,30 2,99 5,98 10,47 14,95 22,43
Metro Tag Mittel Schnell (135 km/h) 16,34 1,41 0,02 0,30 3,02 6,04 10,57 15,09 22,64
Metro Tag Mittel Schnell (136 km/h) 16,48 1,41 0,02 0,30 3,05 6,09 10,66 15,24 22,85
Metro Tag Mittel Schnell (137 km/h) 16,62 1,41 0,02 0,31 3,08 6,15 10,76 15,38 23,07
Metro Tag Mittel Schnell (138 km/h) 16,76 1,41 0,02 0,31 3,10 6,21 10,86 15,52 23,28
Metro Tag Mittel Schnell (139 km/h) 16,91 1,41 0,02 0,31 3,13 6,27 10,96 15,66 23,50
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 9 von 27
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel Schnell (140 km/h) 17,05 1,41 0,02 0,32 3,16 6,32 11,06 15,81 23,71
Metro Tag Mittel Schnell (141 km/h) 17,19 1,41 0,02 0,32 3,19 6,38 11,16 15,95 23,92
Metro Tag Mittel Schnell (142 km/h) 17,33 1,41 0,02 0,32 3,22 6,44 11,26 16,09 24,14
Metro Tag Mittel Schnell (143 km/h) 17,48 1,41 0,02 0,32 3,25 6,49 11,36 16,23 24,35
Metro Tag Mittel Schnell (144 km/h) 17,62 1,41 0,02 0,33 3,28 6,55 11,46 16,38 24,57
Metro Tag Mittel Schnell (145 km/h) 17,76 1,41 0,02 0,33 3,30 6,61 11,56 16,52 24,78
Metro Tag Mittel Schnell (146 km/h) 17,90 1,41 0,02 0,33 3,33 6,66 11,66 16,66 24,99
Metro Tag Mittel Schnell (147 km/h) 18,05 1,41 0,02 0,34 3,36 6,72 11,76 16,80 25,21
Metro Tag Mittel Schnell (148 km/h) 18,19 1,41 0,02 0,34 3,39 6,78 11,86 16,95 25,42
Metro Tag Mittel Schnell (149 km/h) 18,33 1,41 0,02 0,34 3,42 6,84 11,96 17,09 25,64
Metro Tag Mittel Schnell (150 km/h) 18,47 1,41 0,02 0,34 3,45 6,89 12,06 17,23 25,85
Metro Tag Mittel Schnell (151 km/h) 18,62 1,41 0,02 0,35 3,48 6,95 12,16 17,38 26,06
Metro Tag Mittel Schnell (152 km/h) 18,76 1,41 0,02 0,35 3,50 7,01 12,26 17,52 26,28
Metro Tag Mittel Schnell (153 km/h) 18,90 1,41 0,02 0,35 3,53 7,06 12,36 17,66 26,49
Metro Tag Mittel Schnell (154 km/h) 19,05 1,41 0,02 0,36 3,56 7,12 12,46 17,80 26,70
Metro Tag Mittel Schnell (155 km/h) 19,19 1,41 0,02 0,36 3,59 7,18 12,56 17,95 26,92
Metro Tag Mittel Schnell (156 km/h) 19,33 1,41 0,02 0,36 3,62 7,24 12,66 18,09 27,13
Metro Tag Mittel Schnell (157 km/h) 19,47 1,41 0,02 0,36 3,65 7,29 12,76 18,23 27,35
Metro Tag Mittel Schnell (158 km/h) 19,62 1,41 0,02 0,37 3,67 7,35 12,86 18,37 27,56
Metro Tag Mittel Schnell (159 km/h) 19,76 1,41 0,02 0,37 3,70 7,41 12,96 18,52 27,77
Metro Tag Max Schnell (ab 160 km/h) 19,90 1,41 0,02 0,37 3,73 7,46 13,06 18,66 27,99
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 10 von 27
Anlage 5.3b: Liste der Entgelte der DB RegioNetz Infrastruktur GmbH
Entgelte Schienengüterverkehr
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt
Entgelt für
Nicht -
stornierung ≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Standard 4,44 1,80 0,03 0,43 0,57 1,14 2,00 3,43 5,72
Sehr schwer 6,09 3,09 0,03 0,48 0,64 1,29 2,25 3,86 7,84
Gefahrgutganzzug 5,54 1,80 0,03 0,60 0,79 1,59 2,78 4,76 7,94
Güternahverkehr 2,68 1,19 0,03 0,26 0,34 0,68 1,20 2,05 3,42
Lokfahrt 2,68 0,96 0,03 0,29 0,38 0,77 1,34 2,30 3,84
Standard Z-Flex 4,24 1,80 0,03 0,40 0,53 1,06 1,86 3,19 5,32
Sehr schwer Z -Flex 5,89 3,09 0,03 0,45 0,60 1,21 2,11 3,62 7,59
Gefahrgutganzzug Z-Flex 5,34 1,80 0,03 0,57 0,75 1,51 2,64 4,52 7,54
Güternahverkehr Z-Flex 2,48 1,19 0,03 0,23 0,30 0,60 1,06 1,81 3,02
Standard Schnell 5,44 1,80 0,03 0,58 0,77 1,54 2,70 4,63 7,72
Gefahrgutganzzug Schnell 6,54 1,80 0,03 0,75 0,99 1,99 3,48 5,96 9,94
Güternahverkehr Schnell 3,68 1,19 0,03 0,41 0,54 1,08 1,90 3,25 5,42
Standard Z -Flex Schnell 5,24 1,80 0,03 0,55 0,73 1,46 2,56 4,39 7,32
Gefahrgutganzzug Z -Flex Schnell 6,34 1,80 0,03 0,72 0,95 1,91 3,34 5,72 9,54
Güternahverkehr Z -Flex Schnell 3,48 1,19 0,03 0,38 0,50 1,00 1,76 3,01 5,02
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 11 von 27
Entgelte Schienenpersonennahverkehr
Segment Entgelt uKZ Fahrplan -
kosten Stornierungsentgelt
Entgelt für Nicht -
stornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Lastfahrt Baden -Württemberg 7,811 0,97 0,03 0,14 1,41 2,81 4,92 7,03 10,54
Lastfahrt Bayern 7,569 0,97 0,03 0,14 1,36 2,71 4,75 6,78 10,18
Lastfahrt Hessen 7,525 0,97 0,03 0,13 1,35 2,70 4,72 6,74 10,11
Lastfahrt Nordrhein -Westfalen 7,594 0,97 0,03 0,14 1,36 2,72 4,77 6,81 10,21
Lastfahrt Sachsen 8,039 0,97 0,03 0,15 1,45 2,90 5,08 7,25 10,88
Lastfahrt Thüringen 7,927 0,97 0,03 0,14 1,43 2,86 5,00 7,14 10,71
Leerfahrt Baden -Württemberg 4,269 0,96 0,03 0,07 0,70 1,40 2,45 3,51 5,26
Leerfahrt Bayern 4,268 0,96 0,03 0,07 0,70 1,40 2,45 3,50 5,26
Leerfahrt Hessen 4,320 0,96 0,03 0,07 0,71 1,42 2,49 3,56 5,34
Leerfahrt Nordrhein -Westfalen 4,280 0,96 0,03 0,07 0,70 1,41 2,46 3,52 5,28
Leerfahrt Sachsen 4,305 0,96 0,03 0,07 0,71 1,42 2,48 3,54 5,31
Leerfahrt Thüringen 4,394 0,96 0,03 0,07 0,73 1,45 2,54 3,63 5,45
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 12 von 27
Entgelte Schienenpersonenfernverkehr
Segment Entgelt uKZ Fahrplan -
koste n Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Basic 6,56 1,41 0,02 0,11 1,06 2,13 3,72 5,32 7,98
Basic Schnell 9,56 1,41 0,02 0,17 1,66 3,33 5,82 8,32 12,48
Nacht 3,59 1,41 0,02 0,05 0,47 0,94 1,64 2,35 3,52
Nacht Schnell 6,59 1,41 0,02 0,11 1,07 2,14 3,74 5,35 8,02
Charter/Nostalgie 3,53 0,97 0,03 0,05 0,55 1,10 1,92 2,74 4,11
Punkt -zu-Punkt 5,02 1,41 0,02 0,08 0,76 1,51 2,64 3,78 5,67
Leer-/Lokfahrt 3,53 0,96 0,02 0,05 0,46 0,91 1,60 2,28 3,42
Leer-/Lokfahrt Schnell 6,53 0,96 0,02 0,11 1,06 2,11 3,70 5,28 7,92
Metro Tag Min (bis inkl. 100 km/h) 8,34 1,41 0,02 0,14 1,42 2,84 4,97 7,10 10,65
Metro Tag Mittel (101 km/h) 8,49 1,41 0,02 0,14 1,45 2,90 5,07 7,24 10,86
Metro Tag Mittel (102 km/h) 8,63 1,41 0,02 0,15 1,48 2,95 5,17 7,39 11,08
Metro Tag Mittel (103 km/h) 8,77 1,41 0,02 0,15 1,51 3,01 5,27 7,53 11,29
Metro Tag Mittel (104 km/h) 8,91 1,41 0,02 0,15 1,53 3,07 5,37 7,67 11,51
Metro Tag Mittel (105 km/h) 9,06 1,41 0,02 0,16 1,56 3,13 5,47 7,81 11,72
Metro Tag Mittel (106 km/h) 9,20 1,41 0,02 0,16 1,59 3,18 5,57 7,96 11,93
Metro Tag Mittel (107 km/h) 9,34 1,41 0,02 0,16 1,62 3,24 5,67 8,10 12,15
Metro Tag Mittel (108 km/h) 9,48 1,41 0,02 0,16 1,65 3,30 5,77 8,24 12,36
Metro Tag Mittel (109 km/h) 9,63 1,41 0,02 0,17 1,68 3,35 5,87 8,38 12,58
Metro Tag Mittel (110 km/h) 9,77 1,41 0,02 0,17 1,71 3,41 5,97 8,53 12,79
Metro Tag Mittel (111 km/h) 9,91 1,41 0,02 0,17 1,73 3,47 6,07 8,67 13,00
Metro Tag Mittel (112 km/h) 10,05 1,41 0,02 0,18 1,76 3,52 6,17 8,81 13,22
Metro Tag Mittel (113 km/h) 10,20 1,41 0,02 0,18 1,79 3,58 6,27 8,95 13,43
Metro Tag Mittel (114 km/h) 10,34 1,41 0,02 0,18 1,82 3,64 6,37 9,10 13,65
Metro Tag Mittel (115 km/h) 10,48 1,41 0,02 0,18 1,85 3,70 6,47 9,24 13,86
Metro Tag Mittel (116 km/h) 10,62 1,41 0,02 0,19 1,88 3,75 6,57 9,38 14,07
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 13 von 27
Segment Entgelt uKZ Fahrplan -
koste n Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel (117 km/h) 10,77 1,41 0,02 0,19 1,91 3,81 6,67 9,53 14,29
Metro Tag Mittel (118 km/h) 10,91 1,41 0,02 0,19 1,93 3,87 6,77 9,67 14,50
Metro Tag Mittel (119 km/h) 11,05 1,41 0,02 0,20 1,96 3,92 6,87 9,81 14,72
Metro Tag Mittel (120 km/h) 11,20 1,41 0,02 0,20 1,99 3,98 6,97 9,95 14,93
Metro Tag Mittel (121 km/h) 11,34 1,41 0,02 0,20 2,02 4,04 7,07 10,10 15,14
Metro Tag Mittel (122 km/h) 11,48 1,41 0,02 0,20 2,05 4,10 7,17 10,24 15,36
Metro Tag Mittel (123 km/h) 11,62 1,41 0,02 0,21 2,08 4,15 7,27 10,38 15,57
Metro Tag Mittel (124 km/h) 11,77 1,41 0,02 0,21 2,10 4,21 7,37 10,52 15,79
Metro Tag Mittel (125 km/h) 11,91 1,41 0,02 0,21 2,13 4,27 7,47 10,67 16,00
Metro Tag Mittel (126 km/h) 12,05 1,41 0,02 0,22 2,16 4,32 7,57 10,81 16,21
Metro Tag Mittel (127 km/h) 12,19 1,41 0,02 0,22 2,19 4,38 7,67 10,95 16,43
Metro Tag Mittel (128 km/h) 12,34 1,41 0,02 0,22 2,22 4,44 7,77 11,09 16,64
Metro Tag Mittel (129 km/h) 12,48 1,41 0,02 0,22 2,25 4,49 7,87 11,24 16,86
Metro Tag Mittel (130 km/h) 12,62 1,41 0,02 0,23 2,28 4,55 7,97 11,38 17,07
Metro Tag Mittel (131 km/h) 12,76 1,41 0,02 0,23 2,30 4,61 8,07 11,52 17,28
Metro Tag Mittel (132 km/h) 12,91 1,41 0,02 0,23 2,33 4,67 8,17 11,67 17,50
Metro Tag Mittel (133 km/h) 13,05 1,41 0,02 0,24 2,36 4,72 8,27 11,81 17,71
Metro Tag Mittel (134 km/h) 13,19 1,41 0,02 0,24 2,39 4,78 8,37 11,95 17,93
Metro Tag Mittel (135 km/h) 13,34 1,41 0,02 0,24 2,42 4,84 8,47 12,09 18,14
Metro Tag Mittel (136 km/h) 13,48 1,41 0,02 0,24 2,45 4,89 8,56 12,24 18,35
Metro Tag Mittel (137 km/h) 13,62 1,41 0,02 0,25 2,48 4,95 8,66 12,38 18,57
Metro Tag Mittel (138 km/h) 13,76 1,41 0,02 0,25 2,50 5,01 8,76 12,52 18,78
Metro Tag Mittel (139 km/h) 13,91 1,41 0,02 0,25 2,53 5,07 8,86 12,66 19,00
Metro Tag Mittel (140 km/h) 14,05 1,41 0,02 0,26 2,56 5,12 8,96 12,81 19,21
Metro Tag Mittel (141 km/h) 14,19 1,41 0,02 0,26 2,59 5,18 9,06 12,95 19,42
Metro Tag Mittel (142 km/h) 14,33 1,41 0,02 0,26 2,62 5,24 9,16 13,09 19,64
Metro Tag Mittel (143 km/h) 14,48 1,41 0,02 0,26 2,65 5,29 9,26 13,23 19,85
Metro Tag Mittel (144 km/h) 14,62 1,41 0,02 0,27 2,68 5,35 9,36 13,38 20,07
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 14 von 27
Segment Entgelt uKZ Fahrplan -
koste n Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel (145 km/h) 14,76 1,41 0,02 0,27 2,70 5,41 9,46 13,52 20,28
Metro Tag Mittel (146 km/h) 14,90 1,41 0,02 0,27 2,73 5,46 9,56 13,66 20,49
Metro Tag Mittel (147 km/h) 15,05 1,41 0,02 0,28 2,76 5,52 9,66 13,80 20,71
Metro Tag Mittel (148 km/h) 15,19 1,41 0,02 0,28 2,79 5,58 9,76 13,95 20,92
Metro Tag Mittel (149 km/h) 15,33 1,41 0,02 0,28 2,82 5,64 9,86 14,09 21,14
Metro Tag Mittel (150 km/h) 15,47 1,41 0,02 0,28 2,85 5,69 9,96 14,23 21,35
Metro Tag Mittel (151 km/h) 15,62 1,41 0,02 0,29 2,88 5,75 10,06 14,38 21,56
Metro Tag Mittel (152 km/h) 15,76 1,41 0,02 0,29 2,90 5,81 10,16 14,52 21,78
Metro Tag Mittel (153 km/h) 15,90 1,41 0,02 0,29 2,93 5,86 10,26 14,66 21,99
Metro Tag Mittel (154 km/h) 16,05 1,41 0,02 0,30 2,96 5,92 10,36 14,80 22,20
Metro Tag Mittel (155 km/h) 16,19 1,41 0,02 0,30 2,99 5,98 10,46 14,95 22,42
Metro Tag Mittel (156 km/h) 16,33 1,41 0,02 0,30 3,02 6,04 10,56 15,09 22,63
Metro Tag Mittel (157 km/h) 16,47 1,41 0,02 0,30 3,05 6,09 10,66 15,23 22,85
Metro Tag Mittel (158 km/h) 16,62 1,41 0,02 0,31 3,07 6,15 10,76 15,37 23,06
Metro Tag Mittel (159 km/h) 16,76 1,41 0,02 0,31 3,10 6,21 10,86 15,52 23,27
Metro Tag Max (ab 160 km/h) 16,90 1,41 0,02 0,31 3,13 6,26 10,96 15,66 23,49
Metro Tag Min Schnell (bis 100 km/h) 11,34 1,41 0,02 0,20 2,02 4,04 7,07 10,10 15,15
Metro Tag Mittel Schnell (101 km/h) 11,49 1,41 0,02 0,20 2,05 4,10 7,17 10,24 15,36
Metro Tag Mittel Schnell (102 km/h) 11,63 1,41 0,02 0,21 2,08 4,15 7,27 10,39 15,58
Metro Tag Mittel Schnell (103 km/h) 11,77 1,41 0,02 0,21 2,11 4,21 7,37 10,53 15,79
Metro Tag Mittel Schnell (104 km/h) 11,91 1,41 0,02 0,21 2,13 4,27 7,47 10,67 16,01
Metro Tag Mittel Schnell (105 km/h) 12,06 1,41 0,02 0,22 2,16 4,33 7,57 10,81 16,22
Metro Tag Mittel Schnell (106 km/h) 12,20 1,41 0,02 0,22 2,19 4,38 7,67 10,96 16,43
Metro Tag Mittel Schnell (107 km/h) 12,34 1,41 0,02 0,22 2,22 4,44 7,77 11,10 16,65
Metro Tag Mittel Schnell (108 km/h) 12,48 1,41 0,02 0,22 2,25 4,50 7,87 11,24 16,86
Metro Tag Mittel Schnell (109 km/h) 12,63 1,41 0,02 0,23 2,28 4,55 7,97 11,38 17,08
Metro Tag Mittel Schnell (110 km/h) 12,77 1,41 0,02 0,23 2,31 4,61 8,07 11,53 17,29
Metro Tag Mittel Schnell (111 km/h) 12,91 1,41 0,02 0,23 2,33 4,67 8,17 11,67 17,50
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 15 von 27
Segment Entgelt uKZ Fahrplan -
koste n Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel Schnell (112 km/h) 13,05 1,41 0,02 0,24 2,36 4,72 8,27 11,81 17,72
Metro Tag Mittel Schnell (113 km/h) 13,20 1,41 0,02 0,24 2,39 4,78 8,37 11,95 17,93
Metro Tag Mittel Schnell (114 km/h) 13,34 1,41 0,02 0,24 2,42 4,84 8,47 12,10 18,15
Metro Tag Mittel Schnell (115 km/h) 13,48 1,41 0,02 0,24 2,45 4,90 8,57 12,24 18,36
Metro Tag Mittel Schnell (116 km/h) 13,62 1,41 0,02 0,25 2,48 4,95 8,67 12,38 18,57
Metro Tag Mittel Schnell (117 km/h) 13,77 1,41 0,02 0,25 2,51 5,01 8,77 12,53 18,79
Metro Tag Mittel Schnell (118 km/h) 13,91 1,41 0,02 0,25 2,53 5,07 8,87 12,67 19,00
Metro Tag Mittel Schnell (119 km/h) 14,05 1,41 0,02 0,26 2,56 5,12 8,97 12,81 19,22
Metro Tag Mittel Schnell (120 km/h) 14,20 1,41 0,02 0,26 2,59 5,18 9,07 12,95 19,43
Metro Tag Mittel Schnell (121 km/h) 14,34 1,41 0,02 0,26 2,62 5,24 9,17 13,10 19,64
Metro Tag Mittel Schnell (122 km/h) 14,48 1,41 0,02 0,26 2,65 5,30 9,27 13,24 19,86
Metro Tag Mittel Schnell (123 km/h) 14,62 1,41 0,02 0,27 2,68 5,35 9,37 13,38 20,07
Metro Tag Mittel Schnell (124 km/h) 14,77 1,41 0,02 0,27 2,70 5,41 9,47 13,52 20,29
Metro Tag Mittel Schnell (125 km/h) 14,91 1,41 0,02 0,27 2,73 5,47 9,57 13,67 20,50
Metro Tag Mittel Schnell (126 km/h) 15,05 1,41 0,02 0,28 2,76 5,52 9,67 13,81 20,71
Metro Tag Mittel Schnell (127 km/h) 15,19 1,41 0,02 0,28 2,79 5,58 9,77 13,95 20,93
Metro Tag Mittel Schnell (128 km/h) 15,34 1,41 0,02 0,28 2,82 5,64 9,87 14,09 21,14
Metro Tag Mittel Schnell (129 km/h) 15,48 1,41 0,02 0,28 2,85 5,69 9,97 14,24 21,36
Metro Tag Mittel Schnell (130 km/h) 15,62 1,41 0,02 0,29 2,88 5,75 10,07 14,38 21,57
Metro Tag Mittel Schnell (131 km/h) 15,76 1,41 0,02 0,29 2,90 5,81 10,17 14,52 21,78
Metro Tag Mittel Schnell (132 km/h) 15,91 1,41 0,02 0,29 2,93 5,87 10,27 14,67 22,00
Metro Tag Mittel Schnell (133 km/h) 16,05 1,41 0,02 0,30 2,96 5,92 10,37 14,81 22,21
Metro Tag Mittel Schnell (134 km/h) 16,19 1,41 0,02 0,30 2,99 5,98 10,47 14,95 22,43
Metro Tag Mittel Schnell (135 km/h) 16,34 1,41 0,02 0,30 3,02 6,04 10,57 15,09 22,64
Metro Tag Mittel Schnell (136 km/h) 16,48 1,41 0,02 0,30 3,05 6,09 10,66 15,24 22,85
Metro Tag Mittel Schnell (137 km/h) 16,62 1,41 0,02 0,31 3,08 6,15 10,76 15,38 23,07
Metro Tag Mittel Schnell (138 km/h) 16,76 1,41 0,02 0,31 3,10 6,21 10,86 15,52 23,28
Metro Tag Mittel Schnell (139 km/h) 16,91 1,41 0,02 0,31 3,13 6,27 10,96 15,66 23,50
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 16 von 27
Segment Entgelt uKZ Fahrplan -
koste n Stornierungsentgelt Entgelt für
Nichtstornierung
≥ 31 Tage 30 - 5 Tage 4 Tage - 24 h < 24h + 20h
[EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm] [EUR/Trkm]
Metro Tag Mittel Schnell (140 km/h) 17,05 1,41 0,02 0,32 3,16 6,32 11,06 15,81 23,71
Metro Tag Mittel Schnell (141 km/h) 17,19 1,41 0,02 0,32 3,19 6,38 11,16 15,95 23,92
Metro Tag Mittel Schnell (142 km/h) 17,33 1,41 0,02 0,32 3,22 6,44 11,26 16,09 24,14
Metro Tag Mittel Schnell (143 km/h) 17,48 1,41 0,02 0,32 3,25 6,49 11,36 16,23 24,35
Metro Tag Mittel Schnell (144 km/h) 17,62 1,41 0,02 0,33 3,28 6,55 11,46 16,38 24,57
Metro Tag Mittel Schnell (145 km/h) 17,76 1,41 0,02 0,33 3,30 6,61 11,56 16,52 24,78
Metro Tag Mittel Schnell (146 km/h) 17,90 1,41 0,02 0,33 3,33 6,66 11,66 16,66 24,99
Metro Tag Mittel Schnell (147 km/h) 18,05 1,41 0,02 0,34 3,36 6,72 11,76 16,80 25,21
Metro Tag Mittel Schnell (148 km/h) 18,19 1,41 0,02 0,34 3,39 6,78 11,86 16,95 25,42
Metro Tag Mittel Schnell (149 km/h) 18,33 1,41 0,02 0,34 3,42 6,84 11,96 17,09 25,64
Metro Tag Mittel Schnell (150 km/h) 18,47 1,41 0,02 0,34 3,45 6,89 12,06 17,23 25,85
Metro Tag Mittel Schnell (151 km/h) 18,62 1,41 0,02 0,35 3,48 6,95 12,16 17,38 26,06
Metro Tag Mittel Schnell (152 km/h) 18,76 1,41 0,02 0,35 3,50 7,01 12,26 17,52 26,28
Metro Tag Mittel Schnell (153 km/h) 18,90 1,41 0,02 0,35 3,53 7,06 12,36 17,66 26,49
Metro Tag Mittel Schnell (154 km/h) 19,05 1,41 0,02 0,36 3,56 7,12 12,46 17,80 26,70
Metro Tag Mittel Schnell (155 km/h) 19,19 1,41 0,02 0,36 3,59 7,18 12,56 17,95 26,92
Metro Tag Mittel Schnell (156 km/h) 19,33 1,41 0,02 0,36 3,62 7,24 12,66 18,09 27,13
Metro Tag Mittel Schnell (157 km/h) 19,47 1,41 0,02 0,36 3,65 7,29 12,76 18,23 27,35
Metro Tag Mittel Schnell (158 km/h) 19,62 1,41 0,02 0,37 3,67 7,35 12,86 18,37 27,56
Metro Tag Mittel Schnell (159 km/h) 19,76 1,41 0,02 0,37 3,70 7,41 12,96 18,52 27,77
Metro Tag Max Schnell (ab 160 km/h) 19,90 1,41 0,02 0,37 3,73 7,46 13,06 18,66 27,99
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 17 von 27
Anlage 5.3 c: Liste der Entgelte für die Nutzung von Personenbahnhöfen der DB RegioNetz Infrastruktur
GmbH
Verkehrsstation (Vst) Bundesland Regio -Netz Kategorie Preis ab
01.01.25 EP x 1,03 Preis ab
01.01.26
Ahnatal -Casselbreite Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Ahnatal -Heckershausen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Ahnatal -Weimar Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Aich (Niederbay) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Altenhasungen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Altenmarkt (Alz) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Altötting Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Amorbach Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Annaberg -Buchholz Mitte Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Annaberg -Buchholz Süd Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Annaberg -Buchholz unt Bahnhof Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Antonsthal Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Anzenkirchen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Aschaffenburg -Obernau Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Aue (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Aue (Sachs) Erzgebirgsstadion Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Bad Arolsen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Bad Birnbach Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Bad Höhenstadt Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Bad Laasphe Nordrhein -Westfalen Kurhessenbahn (KHB) KHB 3 2,09 € 2,1571 € 2,16 €
Bad Laasphe -Niederlaasphe Nordrhein -Westfalen Kurhessenbahn (KHB) KHB 3 2,09 € 2,1571 € 2,16 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 18 von 27
Bad Mergentheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Bad Schlema Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Bad Wildungen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Bärenstein (Kr Annaberg) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Bayerbach Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Bechstedt -Trippstein Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Bibelöd Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Biedenkopf Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Biedenkopf Schulzentrum Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Biedenkopf -Wallau Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Birkenbringhausen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Blaufelden Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Blumenau Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Bödigheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Breitenbrunn (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Buchen im Odenwald Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Buchen Ost Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Buchenau (Lahn) Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Burghausen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Burgkirchen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Burkhardtsdorf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Burkhardtsdorf Mitte Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Cainsdorf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Caldern Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Chemnitz -Erfenschlag Mitte Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Chemnitz -Erfenschlag Ost Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Chemnitz -Reichenhain Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 19 von 27
Collenberg Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Cranzahl Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Cursdorf Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Distelhausen Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Dittersdorf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Dittigheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Dorfchemnitz (b Zwönitz) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Dorfprozelten Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Edelfingen Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Edling Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Eggenfelden Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Eggenfelden Mitte Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Egglkofen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Ehringen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Einsiedel Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Einsiedel August -Bebel -Platz Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Einsiedel Brauerei Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Einsiedel Gymnasium Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Eisenärzt Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Elpersheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Engertsham Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Erdmannsdorf -Augustusburg Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Erla Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Erlabrunn (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Erlenbach am Main Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Ernsthausen (Kr Frankenberg) Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Fährbrücke Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 20 von 27
Falkenau (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Faulbach (Main) Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Feudingen Nordrhein -Westfalen Kurhessenbahn (KHB) KHB 3 2,09 € 2,1571 € 2,16 €
Flöha -Plaue Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Floßmühle Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Forsting Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Frankenberg (Eder) Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Frankenberg (Eder) Goßberg Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Frankenberg (Eder) Viermünden Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Freudenberg -Kirschfurt Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Fridolfing Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Friedensdorf (Lahn) Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Fritzlar Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Fürstenwald Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Fürstenzell Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Gamburg Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Garching (Alz) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Gars (Inn) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Geisenhausen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Gendorf Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Glanzstoffwerke Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Goßfelden Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Grünhainichen -Borstendorf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Grünstädtel Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Hainstadt (Baden) Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Hartenstein Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Hasloch am Main Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 21 von 27
Hebertsfelden Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Heiligenstatt Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Hennersdorf (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Hetzdorf (Flöhatal) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Hochhausen Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Hohenfichte Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Höpfling Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Hörpolding Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Hufschlag Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Igersheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Jettenbach Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Johanngeorgenstadt Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Julbach Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Karpfham Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Kastl (Oberbay) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Katzhütte Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Kemtau Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Kirchanschöring Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Kirchweidach Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Kleinheubach Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Kleinwallstadt Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Klingenberg am Main Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Kloster Bronnbach Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Korbach Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Korbach Süd Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Külte -Wetterburg Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Lahntal -Sarnau Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 22 von 27
Landshut (Bay) Süd Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Laudenbach (Württ) Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Laudenbach am Main Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Laufen (Oberbay) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Lauter (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Leimstruth Nordrhein -Westfalen Kurhessenbahn (KHB) KHB 3 2,09 € 2,1571 € 2,16 €
Lengefeld -Rauenstein Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Leubsdorf (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Lichtenhain a d Bergbahn Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Lößnitz ob Bf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Lößnitz unt Bf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Mandern Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Marienberg (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Markelsheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Markersbach (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Marktl Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Massing Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Matzing Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Meinersdorf (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Mellenbach -Glasbach Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Mengeringhausen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Meuselbach -Schwarzmühle Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Miltenberg Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Miltenberg -Breitendiel Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Mühldorf (Oberbay) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Münchhausen Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Nennigmühle Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 23 von 27
Neuhausen (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Neukirchen (Inn) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Neumarkt -St Veit Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Neuötting Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Neustift (b Passau) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Niederstetten Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Niederzwönitz Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Niklashausen Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Oberelsungen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Obernburg -Elsenfeld Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Oberndorf (Kr Wittgenstein) Nordrhein -Westfalen Kurhessenbahn (KHB) KHB 3 2,09 € 2,1571 € 2,16 €
Oberweißbach -Deesbach Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Obstfelderschmiede Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Olbernhau Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Olbernhau West Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Olbernhau -Grünthal Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Otting Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Pfarrkirchen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Pockau Strobelmühle Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Pockau -Lengefeld Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Pocking Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Ramerberg Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Raschau (b Schwarzenberg) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Reicholzheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Reifland -Wünschendorf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Rippberg Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Rohrbach (Oberbay) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 24 von 27
Rosenheim Hochschule Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Rot am See Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Rott (Inn) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Ruhpolding Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Ruhstorf Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Satteldorf Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Schalchen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Schameder Nordrhein -Westfalen Kurhessenbahn (KHB) KHB 3 2,09 € 2,1571 € 2,16 €
Scharfenstein Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Schechen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Scheibenberg Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Schlettau (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Schneeberg im Odenwald Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Schrozberg Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Schwarzburg Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Schwarzenberg (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Schwarzenberg (Erzgeb) Hp Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Schwarzenberg -Neuwelt Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Sehma Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Seiboldsdorf Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Siegsdorf Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Silberstraße Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Simbach (Inn) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Simtshausen Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Sitzendorf -Unterweißbach Thüringen Oberweißbacher Berg - und Schwarzatalbahn OBS 1,16 € 1,1947 € 1,19 €
Soyen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Stadtprozelten Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 25 von 27
Stein a d Traun Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Steinhöring Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Sterzhausen Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Sulzbach am Main Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Sulzbach (Inn) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Tacherting Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Tauberbischofsheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Thalheim (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Thalheim (Erzgeb) Mitte Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Thermalbad Wiesenbad Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Tittmoning -Wiesmühl Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Töging (Inn) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Traundorf Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Traunreut Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Traunstein Klinikum Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Trostberg Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Tulling Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Tüßling Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Twiste Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Ungedanken Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Unteraschau Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Usseln Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Vilsbiburg Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Vöhl Ederbringhausen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Vöhl Herzhausen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Vöhl Schmittlotheim Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Vöhl Thalitter Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 26 von 27
Volkmarsen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Waging Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Waldkirchen (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Waldkraiburg -Kraiburg Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Walldürn Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Wallhausen (Württ) Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Walthersdorf (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Warmbad Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Wasserburg (Inn) Bahnhof Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Wega Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Weibhausen Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Weikersheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Weilbach in Unterfranken Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Wertheim Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Wertheim -Bestenheid Baden -Württemberg Westfrankenbahn (WFB) WFB 1 2,00 € 2,0575 € 2,06 €
Wetter (Hess -Nass) Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Wiesa (Erzgeb) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Wiesenburg (Sachs) Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Wiesenfeld Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Wiesmühl (Alz) Bayern Südostbayernbahn (SOB) SOB 2,50 € 2,5774 € 2,58 €
Wilhelmshütte (Lahn) Hessen Kurhessenbahn (KHB) KHB 2 1,71 € 1,7588 € 1,76 €
Wilischthal Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Wilkau -Haßlau Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Willingen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Willingen -Stryck Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Witzschdorf Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Wolfhagen Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Anlage 5.3 zu den Infrastrukturnutzungsbedingungen der DB InfraGO AG 2027
- Liste der Entgelte der DB InfraGO AG und der DB RegioNetz Infrastruktur GmbH - Gültig ab 13.12.2026
Redaktionsstand: 14.12.2025 Seite 27 von 27
Wolkenstein Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Wörth am Main Bayern Westfrankenbahn (WFB) WFB 2 1,71 € 1,7588 € 1,76 €
Zennern Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Zierenberg Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Zierenberg -Rosental Hessen Kurhessenbahn (KHB) KHB 1 1,79 € 1,8473 € 1,85 €
Zöblitz -Pobershau Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Zschopau Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Zschopau Ost Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Zwickau -Schedewitz Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
Zwönitz Sachsen Erzgebirgsbahn (EGB) EGB 1,69 € 1,7367 € 1,74 €
bahn/project-audit/data/INB-2027-Hauptdokument-data.pdf
BIN
View File
Binary file not shown.
bahn/project-audit/data/INB-2027-Hauptdokument-data.txt
+10955
View File
File diff suppressed because it is too large Load Diff
bahn/project-audit/data/confluence-export/pages/105775927_2020-12-14 Userstory Pipeline Planning.md
+59
View File
@@ -0,0 +1,59 @@
# 2020-12-14 Userstory Pipeline Planning
> Confluence Page ID: 105775927
> Version: 4
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2020-12-14 Userstory Pipeline Planning
> Labels: meeting-notes
---
## Datum
Anwesend:       
## Abstimmung des internen Datenformats
In Vorbereitung auf PI 19 muss entschieden werden, in welchem Format die Daten bestellsystemintern vorgehalten und verarbeitet werden. Zielgrößen sind Wartbarkeit, Versionierbarkeit und Minimierung von Abhängigkeiten nach außen. 
## Fragestellung
Folgende Alternativen stehen zur Entscheidung: 
| | Variante |
- Neues internes Datenmodell | 2. Interne Verwendung von TAF/TAP | 3. Portal-Datenmodell
| | Bewertung |
- Vorleistung wegen fehlendem IFP-Modell notwendig
- Konvertierung
- CI von TAF/TAP XML
- SV zum IFP- und AC-Modell
- Portal-MW aus dem eigenen Modell (kann ggfls. auch umgestellt werden)
- SV und AV müssten umgestellt werden, da sie aktuell noch TAF/TAP XML nutzen |
- Konvertierung
- SV von TAF/TAP XML zu IFP- und AC-Modell
- Portal-MW aus dem eigenen Modell zu TAF/TAP XML
- Update der TAF/TAP Versionen weiterhin problematisch
- spätere Migration auf 1 oder 3 möglich, aber relativ aufwändig |
- Qualität und Reifegrad unklar
- Konvertierung
- CI von TAF/TAP XML zum Portal-Modell
- SV vom Portal-Modell zu IFP und AC
Variante 1: Neues internes Datenmodell
Variante 2: Interne Nutzung von TAF/TAP
Variante 3: Portal-Datenmodell
## Entscheidung
Die Wahl fiel auf Variante 1. Diese soll möglichst nah am TAF/TAP-Modell gehalten werden, da dieses fachlich richtig erscheint und es zumindest innerhalb der Vertriebs-Domäne wenig Veranlassung gibt, davon abzuweichen. In PI 19 soll das interne Datenmodell nahe an TAF/TAP weiterentwickelt werden (größtenteils BE-Tätigkeit). Mögliche Anpassungen / Weiterentwicklungen sind: 
- Entfernung von Redundanzen (z.B. Location-Code und -Name)
- Präzisierung des Datentyps bei nationalen Parametern, die in TAF/TAP immer als Zeichenkette modelliert sind.
- Interne Umstellung von xml auf json
## Vorbereitung PI-Planning
Zu den in PI 19 vorgesehenen Features gibt es folgende Anpassungen: 
- Anbindung Bestellsystem an IFP: Muss auf einen technischen Durchstich beschränkt werden, weil seitens IFP die Schnittstelle in PI 19 noch nicht implementiert wird und fraglich ist, ob die Modellierung in PI 19 feststeht. 
- Einführung eines internen Datenmodells: siehe oben
- Anbindung Portal an Backend: Wird aus PI 19 geschoben, weil das interne Datenmodell noch nicht klar ist.
- Geschäftsprozess Gelegenheitsverkehr in Camunda abbilden (Single PRM): Aufgaben aus PI 18 müssen noch umgesetzt werden. Im Fokus ist hier der Prozess bis Vertragsschluss. Nachträgliche Vertragsanpassungen / Stornierungen sind nicht Teil des Features. 
- Umgang mit 1:n an Vertriebsschnittstelle: Schwappt aus PI 18 rüber.Â
bahn/project-audit/data/confluence-export/pages/112328767_2021-02-01 Besprechungsnotizen AC Trasse- Bestellsystem.md
+50
View File
@@ -0,0 +1,50 @@
# 2021-02-01 Besprechungsnotizen AC Trasse- Bestellsystem
> Confluence Page ID: 112328767
> Version: 3
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2021-02-01 Besprechungsnotizen AC Trasse- Bestellsystem
> Labels: meeting-notes
---
## Datum
## Teilnehmer
-
@erwähnen Sie eine Person, um diese als Teilnehmer hinzuzufügen und darüber zu informieren.
## Zusammenfassung der Ergebnisse 
-
Folgend noch mal die Zusammenfassung der Ergebnisse vom Termin am 17.12.20:
- Es wird 2 Services zwischen dem Bestellsystem und AC geben:
- Service BestellsystemAdapterAbrechnung -> Preisauskunft, Abrechnung, Vertragsänderungen, Ablehnung von Angebote für Abrechnung Angebotserstellungsentgelt, Prüfung Bonität vor Versand Vertragsbestätigung
- Service BestellsystemAdapterDokumentation -> Kaufmännisch revisionssichere Dokumentation und Archivierung des rechnungsbegründenden Unterlagen aus dem Verkaufsprozess
- Der BestellsystemAdapterAbrechnung wird sich an dem von TAF/TAP TSI abgeleiteten Formats des Bestellsystem orientieren. Sobald auf Seiten des Bestellsystem PathRequest und PathDetailMessage beschrieben sind kann in AC-Trasse basierend darauf eine OpenAp 3.0-Defintion des Service bereitstellen und mit der Umsetzung beginnen.
- Der Service BestellsystemAdapterDokumentation benötigt die Original-Nachrichten, die in Kommunikation mit dem Kunden empfangen oder versendet werden. Wie dies genau auszusehen hat, v.a. bei Eingaben des PathRequest in der UI des Bestellsystems, muss noch mit PWC abgestimmt werden. Im Nachgang wird AC eine OpenApi-Definition bereitstellen und den Service umsetzen
- Roadmap
- 01/21 – Abstimmung Anforderungen für kaufmännische Dokumentation der Bestellsystem-Verkaufsbelege mit PWC
- 02/21 – Bereitstellung des Service BestellsystemAdapterDokumentation
- 03/21 - Umsetzung des Service BestellsystemAdapterDokumentation fertig
- Ab 04/21 – Konzeption und Umsetzung des Service BestellsystemAdapterAbrechnung
## Handlungspunkte
2
incomplete
Offene Punkte für die Detaillierung der Roadmap:
- Wann kann der Service BestellsystemAdapterDokumentation in der Integration mit dem Bestellsystem getestet werden?
- Wann wird die Konzeption des Bestellsystem - internen PathRequest und PathDetail – Fachobjekte abgeschlossen sein, damit die Konzeption des Service BestellsystemAdapterAbrechnung im Detail beginnen kann?
1
incomplete
 
- Wir gehen davon aus, dass integrierte Tests zu ~Dokumentation im PI 21 (ca. Q3 dieses Jahr) laufen können
- Eine Indikation, wie es mit dem BS-internen OM aussieht, sollte bis Ende Februar lieferbar sein. Ausspezifiziert (im agilen Wortsinn) soll es Ende PI 19, also Ende März, sein. Ich schlage vor, dass wir euch da regelmäßig auf Stand halten, dann könnt Ihr eventuell schon vorab in die Konzeption einsteigen.
bahn/project-audit/data/confluence-export/pages/115016236_14 Besprechungsnotizen Vorstudie.md
+10
View File
@@ -0,0 +1,10 @@
# 14 Besprechungsnotizen Vorstudie
> Confluence Page ID: 115016236
> Version: 2
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie
> Labels:
---
bahn/project-audit/data/confluence-export/pages/116555799_Architekturrunde PathOS.md
+985
View File
@@ -0,0 +1,985 @@
# Architekturrunde PathOS
> Confluence Page ID: 116555799
> Version: 743
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Architekturrunde PathOS
> Labels:
---
Dies ist der Regeltermin um über anstehende Architekturentscheidungen zu sprechen und diese voranzutreiben.
Die Ablage der Entscheidungen erfolgt weiterhin in Gitlab.
Eine Auflistung hier soll primär der Vorbereitung der Termine dienen, insbesondere um sicherzustellen, dass relevante Entscheider dabei sind.
Die aktuelle Version der Architekturbeschreibung findet man hier.
Ältere Termine sind im  zu finden.
## ADRs in Arbeit
| | Nr | Titel | Branch | MR
| | ADR-72 | Technische Anbindung von Click&Ride an PathOS | <Master> |
| | ADR-74 | Technische Anbindung von TrassenPortal an PathOS | <Master> |
| | ADR-75 | Maximierung Verfügbarkeit der genutzten Container-Registries |
| https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/merge_requests/553
## Agenda-Backlog
## Agenda 10.4.2026
- Yellow-Lane soll perspektivisch abgeschaltet werden
- Beginn mit ITU Anfang Mai
- weitere Informationen folgen
- Staging-Pipelines: Momentan laufen die Staging Pipelines auch für HF-Pipelines, dass führt dazu, dass HF-Versionen auf Base, IEU, SIT und E2E eingetragen werden, obwohl sie ggf. nicht mehr mit der jetzigen Release-Version kompatibel sind und ältere Funktionalitäten beinhalten.
- keine automatische Übernahme von Hotfiix-Versionen in Base-, IEU- und SITx-Umgebungen 
- Steuerungsparameter an Pipeline, um das Verhalten zu überschreiben
- Ticket bei SUPB anlegen
- API-Projekt data-model:  
- Das Projekt hat die falsche groupId: https://git.tech.rz.db.de/bestellsystem1/apis/data-model/-/blob/master/pom.xml?ref_type=heads#L12
- wurde bereits korrigiert → muss in den Apps berücksichtigt werden
- Zyklische Abhängigkeit: 
- https://git.tech.rz.db.de/bestellsystem1/apis/api-parent-pom/-/blob/main/pom.xml?ref_type=heads#L473
- https://git.tech.rz.db.de/bestellsystem1/apis/data-model/-/blob/master/pom.xml?ref_type=heads#L8
- data-model-Abhängigkeit in api-parent-pom soll entfernt werden
## Agenda 6.3.2026
- Vorstellung Entwurf ADR-72 Technische Anbindung von Click&Ride und TrassenPortal an PathOS
- Weiterentwicklung Systemtest
- Schritt 1: Umstellung auf Plain-JUnit (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CDEVOPS-794)
- Schritt 2: TestDataContext entzerren (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CDEVOPS-795)
- Bing/Team-Zero: Kafka-Topic Option "retentionMS" vereinheitlichen?
- Aktuell in Prod: Topic Tbv-Absicherung mit 365 Tage und alle andere Topics mit 7 Tage. 
- Normale Topics: Standard 7 Tage, bei fachlich abweichender Anforderung wie z.B. TBV oder Stationsportal auch höhere Werte
- Error-/DLTs: Standard 30 Tage
- Einen einheitlichen Wert für die ABN/SAT-Umgebungen zu finden?
- Information: TBV ist eine sensible Schnittstelle. Änderungen an der Konfiguration bitte nicht ohne Rücksprache durchführen!
- Information: Mit TBV ist eine abweichende Retention vereinbart, deshalb muss die Konfiguration so bestehen bleiben.
- David/Team-Subp: Sub-Artefakte wie libraries oder apis automatisiert veröffentlichen
- Aktuell wurde von Subp Seite eine Umstellung der Pipeline auf "release by tagging only" vorbereitet
- Das wurde der CI/CD Runde kritisiert, weil damit zusätzlich nach allen Renovate MRs noch zusätzlich zum Zeitpunkt X manuell eine Version getaggt werden muss und nachgelagert dann alle Apps auf diese neue Version updaten muss. 
- Man möchte das weiterhin der stable Branch ins release-Artifactory veröffentlicht wird. 
- Fragen:
- will man das prinzipiell von der Architekturrunde?
- wie werden die Version dann gebildet? aktuell ist bspw. bei apis der stable Branch ein semver Pre-Release "next"
- Diskussionsergebnis:
- Libraries: Händisches Tagging bei manuellen Änderungen, Automatismus bei Renovate-Bot-Anpassungen
- APIs: Händisches Tagging grundsätzlich sinnvoll zwecks Nachvollziehbarkeit bei Bestellsystem-Releases.
## Agenda 6.2.2026
- Aktuelle Situation in den Pipelines: wurde durch die SIT2 die Situation aus Sicht der Teams besser?
- Hat geholfen → Pipelines sind nicht mehr blockiert, wenn manuelle Tests auf der SIT stattfinden
- SAT 3 für LuPs und DRT (temporär)
- Integration der AV in die Portal-Middleware (das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-647)
- Refactoring und Code-Cleanup in Portal-Middleware vorab
- SAB-Team benötigt ggf. die AV
- Höhere Priorisierung von Themen zur Verbesserung der Qualitätssicherung von PathOS
- Henrik/OpsSquad: Metrics und Alerts
- JVM-Metrics notwendig, um den tatsächlichen Speicherverbrauch auswerten zu können
- Jonas/CIB: Umstellung auf https://git.tech.rz.db.de/devex/hardenedimages
- Vorschlag Jonas: Verwendung ab Java 25 
- Enabler für Umstellung erstellen →  
- Vorschlag Christian P.: Parallele Pipeline zum Testen der nächsten Major-Version
- Auf Applikations-Ebene in MR-Pipelines
- Auf Deployment-Ebene wäre es nochmal zu prüfen
- Testgrenzen klarer fassen → ,  
- API-Informationen in Release-/Hotfix-Tickets mit aufnehmen (Sicherstellung der Abwärtskompatibilität)
- eigener Abschnitt für APIs
## Agenda 1.12.2025
- Henning/CIB: Spring Boot 4 Upgrade (Spring Boot 3 OSS EOL 2026-06)
- Thema für PI 40 → Enabler → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-1001
- Separater Enabler für JUnit 5 → JUnit 6 → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-1002
- Saurav/CIB: Gibt es ein definiertes Konzept oder einen Plan für die Migration auf Camunda 8.8 oder 8.x? In diese Versionen sind zahlreiche Breaking Changes enthalten, die möglicherweise zu Datenverlust in der Produktion führen könnten.
https://docs.camunda.io/docs/apis-tools/migration-manuals/
- Analyse der notwendigen Migrationsschritte hinsichtlich Aufwand und Risiko im Bestellsystem → Team CIB,  
- Saurav/CIB: Die Blockierungen der SIT Runners führen dazu, dass die gesamte Pipeline stillsteht. Gibt es einen Plan, dieses Problem vor der Produktivsetzung zu verbessern?
- Automatisierte SITs nur noch in der Tag-Pipeline; nicht mehr in der Master-Pipeline →  
- Frank/Zero: Logging von Messages (Datenschutz)
- Personenbezogene Daten in Logs sind zu maskieren
## Agenda 17.11.2025
- STeam: PostMortem Rotation Artifactory Token
- Tokens sollten über Releaseprozess rotiert werden, was aber aus nicht ganz geklärten Gründen nicht funktioniert hat. Frage: Was ist konkret schief gegangen und wie können wir sicherstellen, dass es beim nächsten Mal klappt?
- Secrets wurden in umgebungs-konfiguration nicht vollständig ersetzt
- TODO: Secrets aufräumen, auf fehlerhafte Secret-Namen prüfen  
- TODO: Struktur in bestellsystem-ops für alle Umgebungen/Cluster usw. vereinheitlichen  
- Manager-Rolle in Artifactory benötigt, um neue Tokens zu generieren (→ Berechtigungen prüfen )
- Dead Letter Topics:
- Einheitliches Namensschema: <Ursprungstopic>-<Consumer>-error
- Dokumentation  
## Agenda 17.10.2025
## Agenda-Backlog
- Martin / STeam: ADR für ECR-Nutzung ist in Writing
- Entscheidung → ECR nur als Backup
                         → ECR nur für Prod und Tests in Preprod (alle 3-4 Monate)
- Martin/STeam, was genau soll eigentlich der Systemzustands-Check mit dem Developer Portal machen?
- in der Praxis sehe ich das nur als Check darauf ob Secret-Leaks erkannt werden.
- alles weitere erlebe ich persönlich nur als sinnloses Abtippen von bekannt false positive Zahlen aus einem Dashboard in einen Teams-Kanal.
→ nur Secrets in DXC Portal prüfen und Security Findings nur aus Trivy/Aqua betrachten
→ Henning macht Doku  
- Einheitliches Hotfix-Vorgehen
- Vorlage aus CIB besprechen
- Änderungen am Vorgehen abstimmen und beschließen siehe: https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/merge_requests/431
- CDaaS-Update via Renovate automatisieren? Yay or nay? Soll heissen: Wie können wir hier autoamtisieren, ohne gegen den Releaseprozess zu arbeiten?
- Wenn nein, gibt es Teilaufgaben eines Updates, die sich automatisieren lassen, ohne die Releaseprozess zu "gefährden"?
→ update in höheren Versionen via Release Prozess
→ ja updates via Renovate
- Zusammenlegung der APIs in ein Multi-Modul-Maven-Projekt
→ erstmal nicht umsetzen
## Agenda 19.09.2025
- Hotfix-Releases: Problematisch, dass durch reguläre Releases die SIT gesperrt ist
- Abwägung der Prioritäten von Hotfix + Release
- Um Sperrzeiten herum arbeiten
- SITs automatisieren
- Java 25: EOL Java 21 Amazon Corretto ist 31.10.2030 bzw. Eclipse Temurin ist 31.12.2029 → Umstellung auf Java 25 nach Go-Live
- Martin / STeam: brauchen wir den infra/infrastruktur-kafka-container noch?
- das ist ein Bitnami-Image mit Security-Findings ohne Updates, und wir haben aktuell keinen 1:1-Ersatz dafür
- wir schlagen vor das Image und Repo zu löschen
- AFAIK gab es drei Use-Cases:
- Helm kafka-setup-Jobs => wurde durch neues Tool ersetzt
- Topics Debugging => wurde durch kafbat/kafka-ui ersetzt
- Tool-Image für Notfall-Debugging und Runbook-Scripte => wurde vermutlich nicht vorbereitet, ist im Runbook nicht dokumentiert => noch relevant?
- Entscheidung: Wird nicht mehr benötigt; kann archiviert werden
- Auch aus versions.yaml entfernen
- Martin / STeam: ADR für ECR-Nutzung ist in Writing
- Gerne mit- und gegenlesen. Wir haben aktuell grob drei offene Fragen vor einem Einbau von Amazon ECR als Ergänzung zu Artifactory als OCI-Image-Speicher.
- Richtlinien-Klärung: können wir ECR-Repos im Prod-AWS-Account für alle Stages benutzen? Wie kleinteilig müssen wir die Zugriffspolicies schreiben?
- Design-Entscheidung: ab welcher Stage wollen wir ECR anstatt Artifactory nutzen?
- Design-Entscheidung: in welchen CI-Pipelines wollen wir Images nach ECR kopieren? Zentral in der staging-Pipeline, oder verteilt in allen Build-Repos und mehr?
- TODO für alle: ADR lesen bis Architekturrunde am 17.10.2025; wird dort diskutiert
- Martin / STeam: wer bekommt Zugriff auf unsere Kafka-UIs?
- die Zugriffsrechte sind inzwischen alle auf GitLab-Gruppen abgebildet und die werden von Thorsten verwaltet. Der technische Teil ist also schon verbessert.
- Haben wir Regeln wer hier genau Zugriff braucht und bekommt?
- Zugriffsvergabe über ART Trio → Anfragen weiterleiten
## Agenda 05.09.2025
- Frank / Team Zero: zu klärende Fragen aus Refinement / Daily:
- O2CZERO-2221 Talo Logging - ist das noch aktuell
- Umgang mit dem GET "/"
- und schließen sich kurz
- Martin / STeam: wir brauchen bessere und einheitlichere Log-Levels
- Beobachtung aus dem Systemzustands-Check, der täglich zeigt wie wenig hilfreich unsere Logs sind
- falsche Nutzer-Eingaben sind keine (System-)Errors
- ein einmaliger Verbindungs-Retry (z.Bsp. bei REST-API) ist kein Error
- Entscheidung: Prüfen der Logausgaben in allen Teams. Error nur bei technischen Fehlern, die einen Eingriff benötigen; nicht in den beschriebenen Fällen.
-
## Agenda 08.08.2025
- Access-Proxy - wie geht es weiter?
- Access-Proxy ist bestellt. Aktuelle Hindernisse durch noch nicht aktivierten Leistungsschein
- Access-Proxy läuft unter anderen Hostnamen:
- PROD: pathos.app.db.de
- TEST: pathos-test.app.db.de → pathos-test-portal-ui.bsz-abn.cnp-test.comp.db.de
- In Arbeit:
- Aufbau neue EVU-Test mit Access-Proxy
- Vorübergehender Parallelbetrieb alte und neue EVU-Test
- Kundenkommunikation
-  Systemzustandsmeldung
- Wie gehen die einzelnen Teams mit den Rückmeldungen um?
- Ist nachvollziehbar, dass die gemeldeten neuen Fehler behandelt (entweder neues Ticket oder nicht relevant) wurden?
- Anpassungen an Übersicht 
- Nummerierungsspalte hinzugefügt
- Neue Einträge werden hintenangestellt
- ExternalDNS ausbauen → neue URLs für betroffene Umgebungen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1436
- Schritt 1: IEU
- Anpassung ankündigen
- Anpassung vornehmen
- Anpassung validieren und dokumentieren
- Schritt 2: SIT
- Anpassung SIT mit Stakeholdern zeitlich abstimmen
- Anpassung vornehmen
- Anpassung validieren und dokumentieren
- Kommunikation an Stakeholder
- Schritt 3: E2E
- Ankündigen
- Durchführen
- Validieren und dokumentieren
- Frank T./Staging für Nicht-Apps
- E.g. curl, infrastruktur-basis-container, flyway
- Aktuell passiert dies entweder manuell per renovate (ohne Staging, z.B. curl oder flyway landen parallel auf allen Umgebungen – ohne Testing auf unteren Testumgebungen wie IEU) oder manuell (mit Stagingmöglichkeit, z.B. infrastruktur-basis-container)
-
- Das führt dazu, dass wir...
- Kein Staging für wichtige Images haben
- CVEs mitschleifen, z.B. O2CSYS-1720
- Wie wollen wir es lösen?
- Vorschläge
- Staging Staging (Repo/Pipeline) ausbauen
- Für unsere eigenen Images (nicht Apps, z.B. infrastruktur-basis-container)
- Für andere Images (z.B. curl)
- Manuellen Prozess aufsetzen und durchsetzen
- Renovate-Updates auf bestellsystem-deployment
- Update erst nur auf IEU, danach reguläres Staging (nochmal verifizieren )
## Agenda 25.07.2025
- Release 23.07. - Lessons Learned: SIT nicht mehr an E2E angleichen, sondern an Release-Stand
- aktueller Zustand 
- SIT → erfolgreich → Versionsstand übernommen in SIT-versions.yaml → keine Übernahme + Deployment auf E2E
- neues Deployment auf die SIT nimmt effektiven Versionsstand der E2E als Ausgangspunkt für das Deployment; nicht den SIT-Versionsstand
- NICHT Release-Stand
- benötigter Zustand
- SIT → erfolgreich → Versionsstand übernehmen nach SIT versions.yaml
- Ausgangspunkt für Deployments auf SIT ist SIT versions.yml und nicht mehr die E2E versions.yaml
- Deployments auf E2E und folgende Umgebungen per Full-Update von SIT
- Manuelle Änderungen an der SIT versions.yaml nur noch in begründeten Ausnahmefällen
- Umsetzung bei STeam → Review bei SUBP   schreibt Enabler → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1792
- Fragen aus Team Zero/Steam: Was ist der Stand für E2E oder was ist geplant?
- E2E wird als Umgebung für TTT-IEU verwendet
- Zukünftig wieder automatisches Bespielen der E2E
- Brauchen wir ein echtes Zertifikat für Demo (aktuell ist dort eines für ABN1)?
- Nein → Testzertifikat verwenden
- Keystores müssen korrigiert werden →  
- ein Testzertifikat für mehrere Umgebungen ist erstmal ausreichend
- Anpassung des EVU-Recorders später zur Prüfung von Client-Zertifikaten (Mutual SSL)
- Steven / Zero: Sollen wir weiterhin User mit lesendem DB Zugriff für ITT/Quest gestatten? Kann das nicht über evu-recorder erfolgen? Datenbankzugriffe (extern) - O2C | Order2Cash - ariJa Confluence  
- Temporär für TTT-Testumgebungen Lesezugriff ok
- Anfang September Anforderungen bzgl. Zugriff auf PathOS Informationen durch ITT/Quest klären und Folgelösung konzipieren  
- : Uninstall base-Umgebungen jeden Abend
- Nach Umbauten am Deployment erfolgen diese deutlich schneller (~ 6 Minuten)
- Uninstall auf base-Umgebungen abends (bis auf PVCs)
- Deployment erfolgt manuell bei Bedarf (Starten der Pipeline in bestellsystem-deployment)
- Uhrzeit für das Uninstall: 20:00 Uhr
- Rollback des Portal-Releases
- Unterschiedliche Handhabung leerer Arrays: [] vs null
- Wenn required true → immer ein Array setzen
- Wenn required false → kann null sein, kann ein leeres oder ein gefülltes Array sein
- Kein automatisches Umwandeln von leeren Arrays auf null mehr im Bestellsystem
## Agenda 27.06.2025
- Martin / STeam: Klärung Service-Verfügbarkeit einzelner Komponenten und Auswirkung auf Gesamt-Bestellsystem-Verfügbarkeit
- Hintergrund: wir aktualisieren mal wieder die Kubernetes-Version und müssen dafür alle K8s-Nodes neustarten. In einem "Kubernetes-Design" funktioniert das komplett ohne Downtime bzw. Service-Unterbrechung, weil alle Komponenten mit mindestens zwei Pods laufen sollten und K8s dafür sorgt dass immer einer davon online bleibt.
- In unseren Umgebungen sehen wir allerdings mehrere Komponenten mit nur einem Pod, z.Bsp. in (dev-)E2E:
- Stammdaten-Bereitstellung
- TTK
- Camunda-Services
- Frage 1: sind das bei SB und TTK nur Deployment-Bugs, die wir schnell hochskalieren können? Oder gibt es noch Bugs, die mehr Replicas verhindern?
- Deployment-Bug → Umstellen auf Replica 2 → stellt das um → infra/bestellsystem-deployment MR 2051
- Frage 2: sind die Camunda-Komponenten so gut gekapselt, dass ein Neustart unproblematisch ist (z.Bsp. weil SV alle Requests queued)?
- Nach aktuellem Kenntnisstand ja
- Themen SUBP-Team:
- Umstellungen Bestellsystem-Deployment 
- Ausbau AppMesh zur Vereinfachung Bestellsystem-Deployment
- application-setup, database-setup-full werden nach bestellsystem-application umgezogen
- Vereinheitlichung der Umgebungskonfigurationen
- DNS-Konfiguration
- Lokales Bestellsystem + lokale Systemtests
- TTTneo-Kompatibilität VNP/ENP
- DRT-Maßnahmen
- Aufbau PROD
- Überblick/Kanban Board: https://arija.jaas.service.deutschebahn.com/secure/RapidBoard.jspa?rapidView=2569
- trivy-operator über CNP "bestellen" →  
- NodePools wären anzupassen (expiration time z.B. 60 m → 30 m)
- Ggf. E2E?
- Bitte an alle: Base-Umgebungen bei Nichtnutzung abräumen
- kein Cleanup, aber tägliches Downscale wäre eine Option → prüfen, ob einfache Umsetzung möglich  
- alternativ: Alerts, wenn Base-Umgebungen mehr als 2 Tage "laufen"
## Agenda 13.06.2025
150
- Planung Umgebungsmapping TTTneo ITU/KTU (siehe Präsentation)
- ADR 71 - Authentifikation und Autorisierung im Bestellportal (siehe Präsentation)
- ARD 70 - Weiteres Vorgehen bzgl. System- und Systemintegrationstests → Testing Jour Fixe
- Aus DRT:
- Wie Verhalten sich unsere Services bzw. einzelne Services wenn Kafka (ähnliches Szenario bei Keycloak mitdenken) nicht verfügbar ist? Wann Soll sich das Gesamtsystem auf nicht mehr verfügbar stellen? 
- Erste Betrachtung:
- PM: Ohne Kafka nur Lesezugriff (Hinweis an Nutzer wäre sinnvoll) / Ohne DB → nicht verfügbar
- CI: Ohne Kafka /ohne DB → nicht verfügbar
- TTK: Ohne Kafka → nicht verfügbar
- SV: Ohne Kafka /ohne DB (RDS, Zeebee, Opensearch) → nicht verfügbar
- Weiteres Vorgehen: 
- Services in einzelnen Teams betrachten, Abhängigkeiten identifizieren
- Besprechung im nächster Architekturrunde
- Verhalten in Anwendungen prüfen bzgl. Nicht-Verfügbarkeit einzelner Infrastrukturservices (z.B. Kafka oder RDS) → Transaktionsklammer richtig gesetzt? Fehlt Transaktionsklammer?
- Services in einzelnen Teams auf entsprechendes Fehlerhandlung und Transaktionssicherheit prüfen
## Agenda 26.05.2025
- Disaster Recovery Test - Vorbereitungen
- Preprod vorbereiten
- Protokoll aus 2024:
- Aktuelles Testprotokoll:
- Anpassungen zur Senkung der Cloud Kosten
- Zeigen Wirkung: https://grafana-v2.cnp.comp.db.de/d/de2jmcogii8zkd/aws-cloud-costs?orgId=69&from=now-14d&to=now
- Probleme auf IEU wurden behoben
- Auswirkungen bitte aufmerksam beobachten, bei Problemen Meldung an STeam
- Frank L. Critical/High Findings im Developer-Portal: Findings aus gelöschten Branches? / Keine Änderung durch Container-Umbau? Nimmt er Caches?
- Findings aus gelöschten Branches? → Change Request bereits an Umsetzungsteam vom Developer Portal gestellt, Findings aus gelöschten Branches zu entfernen
- Keine Änderung durch Container-Umbau? Nimmt er Caches? → Scan manuell anstoßen, sonst nur 1 Scan pro Woche
- Fragestellung: wie geht man mit Branches um, für die es noch keinen MR gibt?
- Fokus auf Master-Branch
- Thorsten: Hostnamen sind keine Secrets → keine verschlüsselten Hostnamen in der Konfiguration
- Ticket erstellen und einplanen
- Frank T.: (Wiedervorlage, da Inhalt am Thema vorbei besprochen worden ist) Müssen wir das Thema readOnlyRootFilesystem auch für GitLab CDAAS Runner einhalten?
- Für Kaniko (und dann später auch buildah) verstoßen wir gegen die Regel runAsNonRoot
- GitLab Runner Job PODs sind nur kurzlebige ad-hoc "Batch Jobs", braucht es dafür wirklich eine Änderung?
- Die Änderung wäre recht aufwändig, da wir für jeden Job prüfen müssen, wohin er schreibt und ob da nicht bereits Daten liegen, die recovered werden müssten, sollte man es mittels "EmptyDirMount" lösen...
- Könnten wir das beim CISO (oder so) erfragen? Oder gibt es für GitLab Runner Job PODs eine Ausnahme?
- FALSCH: "Thema ist in Ticket O2CSYS-1666 aufgenommen. Sollte angegangen werden, wenn die restlichen MUSS-Themen erledigt sind." → runAsNonRoot != readOnlyRootFilesystem
- Regelung nach Rücksprache:
- Gitlab-Runner müssen readOnlyRootFilesystem einhalten
- Job-Runner-Pods müssen das nicht einhalten
- Frank T.: CNB Ausbau / Maven Wrapper und sonstige Ergänzungen
- Wir müssen darüber reden, da die Richtung unklar ist, wohin die individuellen App Repos sich hinentwickeln sollen
- CNB Ausbau war nicht geplant und kostet viel Aufwand
- Maven Wrapper eingeführt (Pipeship)
- CIB macht es wieder ganz anders
- Keine Einheitliche Lösung
- Caching in 404 fehlt (noch)
- Fat-Jar ohne Layer
- TODO: Dokumentation
- Einplanung in PI 37: Vereinheitlichung der Lösung (Anpassung CI-Files) + Berücksichtigung von System-(Integrations-)Tests
## Agenda 16.05.2025
- Bing/STeam: Überprüfen und ggfs. Reduzieren der Anwendungsmetriken sowie Metriken der C8-Services (z.B. zeebe). Siehe auch das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1651 
- Zeebe schreibt viele Metriken
- Vorschlag:
- Schritt 1: Deaktivieren auf den Umgebungen außer E2E und EVU-E2E →  
- Schritt 2: Analysieren, wie die Metriken konfiguriert und reduziert werden können → Team CIB, erstellt ein Ticket
- Spring-Metriken reduzieren (an Team 404-Umsetzung orientieren)
- in Team CIB und 404 schon in den jeweiligen Anwendungen umgesetzt
- in Team Zero noch offen → Ticket ergänzen  
- Thorsten: Abhängigkeit zu CXF / Generell: Umgang mit Dependencies / bestellsystem-parent-pom  →  
- Verwendung von CXF, Guava prüfen
- Entfernen aus bestellsystem-parent-pom und prüfen, welche Anwendungen damit Probleme haben
- Mehr mit Dependency Management arbeiten
- Überschreiben von in Spring Boot definierten Versionen vermeiden (erzeugt Inkompatibilitäten)
- Aufteilung in BOM (bestellsystem-bom) und core-dependencies (bestellsystem-parent-pom) 
- Entwurf in Branch → Testen in den Projekten → Merge auf Master
- Frank L.: Datenbankgröße (z.b. aktuell in IEU ca. 8 GB).
- Idee: Auslagern der Json-Blobs auf S3
- Vor Go-Live keine Kapazität
- Später nochmal betrachten
- Partitionen nutzen, um Datenmenge besser zu handhaben
## Agenda 28.04.2025
- CNP-Risiken von C2S - welche sollten wir für PathOS übernehmen?
-
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-32
- Probleme eher beim Aufbau neuer Umgebungen → weniger während des Betriebs
-
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-35
- Risiko aufnehmen, allerdings geringe Wahrscheinlichkeit und geringerer Impact → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-662
-
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-36
- Probleme eher beim Aufbau neuer Umgebungen → weniger während des Betriebs
-
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-29
- Risiko aufnehmen, geringere Wahrscheinlichkeit, gleicher Impact → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-663
-
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-33
- Trennung von CNP-API-basierten Deployments und Bestellsystem-Deployments
- Probleme werden in Testumgebungen erkannt → keine Auswirkungen auf Betrieb
-
https://arija.jaas.service.deutschebahn.com/browse/C2SPT-28
- Mitigiert durch CNP-interne Limits → aber grundsätzlich auch ein RIsiko für PathOS → übernehmen → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-664
- Security-Scanner:
- Umgang mit False Positives
- Fortify & Branches → als "False Positive" geschlossene Findings können auf anderem Branch wieder auftauchen
- Entscheidung
- Markieren in den jeweiligen Tool (Fortify) bzw. Hinterlegen einer entsprechenden Tool-Konfiguration im Git-Repo
- Bzgl. Fortify, siehe auch: https://git.tech.rz.db.de/bestellsystem1/docs/dokumentation/-/wikis/Umgang-mit-Fortify-Ergebnissen#user-content-tag-not-an-issue-link-auf-gitlab
- DevPortal-Scanner (Grype, Gitleaks und Compliance) bzw. Trivy in der Bearbeitung priorisieren
- Info: portal-ui cnb-builder enthält veraltete Chrome-Version
## Agenda 23.04.2025
- SITs:
- Access Denied beim Zugriff auf Kafka
- + STeam schauen sich das gemeinsam an
- Setzen des Offsets für einen Kafka-Consumer: welche Lösung wollen wir umsetzen? Hintergrund: Wir (Zero) hätten das zu einer schnellen Problembehebung in der E2E gebraucht, aber keinen aktuell gangbaren Weg gefunden (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-5498).
- , + STeam evaluieren eine Lösung (kafka-consumer-groups.sh)
- Frank T.: Müssen wir das Thema readOnlyRootFilesystem auch für GitLab CDAAS Runner einhalten?
- Für Kaniko (und dann später auch buildah) verstoßen wir gegen die Regel runAsNonRoot
- GitLab Runner Job PODs sind nur kurzlebige ad-hoc "Batch Jobs", braucht es dafür wirklich eine Änderung?
- Die Änderung wäre recht aufwändig, da wir für jeden Job prüfen müssen, wohin er schreibt und ob da nicht bereits Daten liegen, die recovered werden müssten, sollte man es mittels "EmptyDirMount" lösen...
- Könnten wir das beim CISO (oder so) erfragen? Oder gibt es für GitLab Runner Job PODs eine Ausnahme?
- Thema ist in Ticket O2CSYS-1666 aufgenommen. Sollte angegangen werden, wenn die restlichen MUSS-Themen erledigt sind.
- Breaking Changes API
- Breaking Changes vermeiden → Abwärtskompatibilität leben und üben
- Kompatiblitätstests erstellen (alte Nachrichtenversionen müssen noch funktionieren)
- Vulnerabilities regelmäßig prüfen
- Tools:
- Developer Portal: https://dp.dxc.comp.db.de/
- Defect Dojo: https://vistadojo-prd2-igo.vista.comp.db.de/
- Vorgehen:
- zu Beginn für jedes Team: 1x pro Woche Vulnerabilities prüfen und behandeln (entweder beheben oder entsprechend dokumentieren)
- zunächst Behebung auf Master-Branch
- bis Ende des PIs konsequente Behebung auch auf E2E + EVU-E2E (bzw. SAT1) + alle anderen Umgebungen
- bestehende + neue Vulnerabilities der Stufe hoch und kritisch abbauen bis Ende Sprint 3
- bestehende + neue Vulnerabilities der Stufe kritisch, hoch und medium abbauen bis Ende PI 36
- Frequenz steigern auf 1x pro Tag in PI 37
## Agenda 04.04.2025
- Sebastian / STeam: Haben wir Backup bzw. Recoverystrategien für alle Produkte? RDS/Postgres adressieren wir in PI36 schon. Was ist mit dem Rest? Frage kam auf bzgl unserer Kafkas, stellt sich aber sicherlich auch für Zeebe, Opensearch, ...
- Bzgl der Kafkas haben wir die Option, diese als "stateless" zu deklarieren (und somit die Verantwortung auf die einzelnen Apps zu verlagern) oder entsprechende Backup- und Recoverystrategien zu etablieren.
- Aktuell keine Unterstützung für MSK-Backups über die CNP API. Wäre relevant für einen gleichzeitigen Datenverlust von RDS und MSK. Wahrscheinlichkeit verschwindend gering. Dennoch: zukünftig Anforderung an CNP stellen
- Momentan Behandlung als Kommunikationsmedium
- Zeebe, Opensearch → Camunda → das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-556 in PI 36 ( fachliche Betrachtung in Enabler ergänzen)
- Martin / STeam: mit den verschiedenen ServiceAccounts und IAM Roles per-Service ist etwas mehr Setup-Aufwand in der CNP-API (d.h. in bestellsystem-ops) notwendig
- wir wünschen uns dass wir trotzdem alle Roles für alle Umgebungen erzeugen (also auch eine IAM-Role "prod-ifp-mock", obwohl in Prod eigentlich nie ein Mock laufen sollte)
- Begründung: die Einheitlichkeit und Konsistenz der Umgebungen führt zu weniger Komplexität und ermöglicht mehr Automatisierung. Das finden wir wichtiger als die initiale Arbeitsersparnis einzelne Teile wegzulassen.
- das gleiche gilt im Prinzip auch für die MSK Consumer/Producer Policies. Es wäre schön wenn die auch über alle Umgebungen hinweg gleich sind. Da könnte "Least Privilege" aber ein Gegenargument sein.
- Entscheidung: Für alle Umgebungen außer PROD ok (inkl. MSK Consumer/Producer Policies). PROD sollte separat behandelt/betrachtet werden.
- Martin / STeam: wann finden wir denn Zeit für die Doku der Kafka-Topics (vgl. 7.2.)
- im Runbook ist leider immer noch ein Fragezeichen, und viele seitdem neue Topics sind nicht eingetragen
- STeam kann das Erstellen der Policies übernehmen (Anfang in bestellsystem-ops MR 709), aber nur wenn wir die nötigen Infos bekommen
- würde es uns helfen, wenn wir in bestellsystem-deployment in der _environment.yaml.gotmpl die Attribute 'producer' und 'consumer' einfügen?
- Wurde erledigt  
## Agenda 07.03.2025
- Neue Umgebungen für TTTneo bzw. Parallelbetrieb TTTneo/TTTclassic 
- 8 Umgebungen von TTTneo müssen angebunden werden (1 DEV, 1 TU, 2 SAT, 3 AU, 1 PROD)
- TTTclassic benötigt weiterhin 2 Umgebungen für ITU und KTU
- pathOS hat aktuell 7 integrative Umgebungen
- Staging für TTTneo vs. TTTclassic
- TTTneo-Staging; Anpassung bisheriges Staging: ABN* + PREPROD nach E2E (nicht mehr parallel und als komplettes BS)?
- TTTclassic-Staging: Staging-Prozess für ITU + KTU (möglichst einfach, da nur temporär)
- Nachrichtensignatur an externe Systeme. Erarbeitung eines Vorschlags zum Schlüsseltausch mit Drittsystemen.
- Drittsysteme: TPN Adapter, KOMBau, TBV, Archivierung, Abrechnung
- Schlüsseltausch mit externen Systemen:
- Variante Kafka-Topic
- Variante Artifactory: Öffentliche Schlüssel + Bibliothek für andere Verfahren zur Verfügung stellen
- JSON-Struktur in Signatur-Header vermeiden → Aufteilung in 2 HTTP-Header  
- Kurze Frage zu CM-MAEP: Management-Endpoints absichern oder deaktivieren das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3419
- Teams:
- Prüfen, dass nur relevante Actuator-Endpoints freigeschaltet sind
- Über Ingress-Konfiguration und Network Policies festlegen, auf welche Endpoints zugegriffen werden darf und durch welches System der Zugriff erfolgen darf
- Prüfen, welche Ingresses überhaupt noch benötigt werden (z.B. NuR-Mock)
- Wiedervorlage, Martin/STeam: Umstrukturieren der GitLab-Gruppen
- Update tools/ vs. infra/:
- Wir haben keine sinnvolle Kategorisierung gefunden; deshalb möchte ich den Vorschlag zum Neu-Sortieren zurückziehen.
- Wir möchten tools/service-certificate-generator nach infra/ verschieben.
- Update libraries/ und mocks/:
- Vorschlag in Teams-Nachricht: GitLab-Gruppen-Änderungen Vorschlag zu den besprochene...
- Wenn es keine Einwände gibt, dann kann ich die neuen Untergruppen sofort anlegen und die Repos entsprechend verschiebene.
- Auswirkung: Update der git remote URLs notwendig, ggf. Update von Doku und Readmes notwendig
- Deadline 14.03.2025 zum Review von Martins Vorschlag. Gibt es keine Einwände, wird sein Vorschlag so umgesetzt.
## Agenda 21.02.2025
- Frank/Zero: Umgang mit Lup-Metriken (Mimir-Zugang), siehe Reaktion auf https://arija.jaas.service.deutschebahn.com/servicedesk/customer/portal/11/CNPSUP-4400
- CNP möchte zeitnah einen alternativen Vorschlag zur Anbindung machen, damit wir den im PIP einplanen können.
- verfolgt die Infos im Ticket und bringt Updates in Team Zero und in zukünftiger Architekturrunde ein
-
Martin/STeam: Im Kontext von Compliance und scm-info überlegen wir wie wir mit archivierten GitLab-Projekten umgehen (O2CSYS-1521).
-
anstatt uralte Repositories nochmal anzufassen würden wir die lieber alle löschen
- archivierte Repositories, die nicht mehr benötigt werden, werden ab 24.02. gelöscht (kann 30 Tage rückgängig gemacht werden)
- möchte jemand noch archivierte Repos behalten? (ich wäre selbst dafür infra/bestellsystem-deployment-helm bzw. dessen commit-History zu behalten, das ist aber auch das einzige)
- @alle: Rückmeldung an STeam asap für noch benötigte archivierte Repositories
- Frank/Team Zero: Umgang mit den Cluster-internen Keycloak-Logins auf Evu-E2E und Evu-Test, siehe auch: 
Kathrin Schleich: Applikationen in Evu-Test und Evu-E2E nicht via Thunderclient zu...
veröffentlicht in VT Order2Cash / Team STeam am Dienstag, 11. Februar 2025 16:06
- Ggf. Möglichkeit über /etc/hosts Workaround (Vorschlag von )
- nimmt das Thema nochmal mit in Team Zero. Bessere Analysefähigkeit über Logging/Monitoring schaffen, damit wir auch in Testumgebungen die Möglichkeiten der späteren Produktionsumgebung nutzen und dadurch ggf. vorhandene Lücken frühzeitig aufdecken.
- Martin/STeam: Wäre es sinnvoll unsere GitLab-Gruppen weiter zu entwickeln?
- tools/ sind "Externe Tools, die wir nicht selbst pflegen", da sind jetzt seit Jahren keine zum rne-common-interface und den excel-tools (werden die benutzt?) hinzugekommen.
- Vorschlag: Gruppe für alle (intern + ggf. extern) Tools nutzen. Dann wäre da auch der "Service-Certificate-generator" wieder richtig, und vieles aus infra/ könnte dahin umziehen (fortify-util, installierte-versionen-image, ...)
- TODO STeam: konkreter Vorschlag per Teams-Channel, weitere Diskussion dann ggf. in folgender Architekturrunde
- apps/ enhält jetzt doch einige Java-Libraries (die aber auch keine APIs sind)
- Entscheidung: Gruppe 'libraries/' anlegen. Da passen dann signature-database, logging-utils, parent-pom rein...
- Entscheidung: Gruppe 'mocks/' anlegen (für ifp-mock, nur-mock, evu-recorder...). 
- TODO STeam:
372
complete
konkreter Vorschlag per Teams-Channel zum Review
- Ausfallfreie Secret-Rotation (siehe Keycloak); wie sieht es mit den anderen Infrastrukturkomponenten aus?
- Keycloak: Ausrollen neuer Secrets bisher nicht ausfallfrei
- prinzipielles Vorgehen:
- neue Secrets erstellen, alte Secrets weiterverwenden
- Keycloak: speziell 2. Paar ClientID und ClientSecret erstellen (z.B. portal-ui → portal-ui-b)
- Apps auf neue Secrets umstellen
- alte Secrets löschen
- Enabler (Team Zero):
373
incomplete
dedizierter Test der Secret-Rotation bei der Service-2-Service-Authentifizierung auf statischer Umgebung inkl. A/B-Deployment & Doku  
- PostgreSQL:
374
incomplete
Enabler im Backlog von Team STeam
- Bei der Dokumentation von Secrets im Runbook an ausfallfreie Secret-Rotation denken; Besonderheiten/Probleme in Architekturrunde einbringen
## Agenda 07.02.2025
- Thorsten: Branching für parallelen Betrieb von TTTclassic und TTTneo
- Zu einem Zeitpunkt X soll ein Branch von SV für TTTclassic erstellt werden. Zeitpunkt X = zu TTTclassic inkompatible Änderungen an den Prozessen von SV für TTTneo
- TTTclassic: Betrieb des Bestellsystems auf dem letzten funktionierenden Stand auf einer Umgebung. Wartung von Bestellsystem auf diesem Stand hinsichtlich Schwachstellen weiterhin notwendig.
- TTTneo: Umstellung des Stagings auf TTTneo
- Offene Fragen:
- Können die Wartungsaufwände reduziert werden? Z.B. Relevante Architekturänderungen (z.B. PM ↔ SV über Kafka) vor Zeitpunkt X, reine Wartung nur für SV + IFP-Connector, andere Komponenten werden immer mit neuen Versionen und Features versehen.
- Umstellung auf Kafka zwischen PM und SV (O2CBS-487) sollte vor dem Branchen umgesetzt werden. bei Planung berücksichtigen
- Welche Umgebung wird für TTTclassic verwendet? Benötigen wir eine neue?
- ABN2, es sei denn es gibt neue Anfordungern vonseiten C2S
- Wie gestalten wir das Staging/Deployment von TTTclassic?
- Idee: Reguläres Deployment auf ABN2 bis auf Steuerung-Vertrieb. Manuelles Deployment für Steuerung-Vertrieb.
- Martin/STeam: CNP bittet uns weniger Metriken zu erfassen, die Datenmenge führt zu instabilen Grafana-Agents (CNPSUP-4363)
- persönliche Vermutung: wir haben viele default-Metriken (aus Spring/Micrometer, OpenTelemetry, AppMesh, ...) von denen wir nicht mal wissen ob sie nützlich sind und wie wir sie abschalten könnten
- wie können wir damit umgehen?
- Scraping-Intervall auf mindestens 30 sec. setzen
- Enabler: Anhand eines Service (+ ggf. Steuerung-Vertrieb) prüfen, welche Metriken wir schreiben   (→ das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-588)  
- Martin/Sebastian/STeam: Einheitliche Benennung Kafkatopics: Wir sollten ggf ein einheitliches Format für die Benennung unserer Kafkatopics einführen. Hier sind wir aktuell recht uneinheitlich. Ggf analog zu https://www.confluent.io/learn/kafka-topic-naming-convention/?
- Aktuell listet das Runbook die folgenden Topics: https://bestellsystem1.gitpages.tech.rz.db.de/docs/runbook/02-architecture/07_deployment_view.html#chapter-internal-systems
- Es existieren aber auch andere wie zB  "tbvAbsicherung" oder "versandErgebnis"
- Der CNP-Validator bemängelt Großbuchstaben in Topics. STeam geht hier auf die CNP zu, das zu ändern das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1484 und CNPSUP-4362 (offizielle Doku von Kafka sieht keine derartige Limitierung vor) => der Validator ist angepasst  
- TODO für Zero und CIB: Vereinheitlichung der Topic-Namen "tbvAbsicherung" und "versandErgebnis" auf Kleinschreibung mit Bindestrichen
- TODO Überprüfung der Topic-Namen im Runbook (alle Teams)
- Frank T. / Henrik Scholl: Laut Richtlinie darf die ABN und PROD Umgebung nur via PAN benutzt werden
- Laut CNP ist es nur PROD, dass nur per PAN benutzt werden darf
- Das merkt man ja auch an der Zugriffskonfig – DB Admin User für PROD verpflichtend
- "Für Editor bzw. Schreibberechtigungen in der CNP-PROD-Umgebung (allgemein in PROD-Umgebungen) dürften nur privilegierte 2er Account-ACAT-Gruppen eingetragen werden (beginnend mit der Zeichenkette gmu). Die Autorisierung von nicht-privilegierten ACAT-Gruppen ist nicht gestattet. (Bitte den Support bei Spezialfällen kontaktieren.)"
- https://cnp.gitpages.tech.rz.db.de/core/docs/cnp/latest/cnp-q-a-session/acat.html
- Systel Richtlinie: https://dbsw.sharepoint.com/sites/sw-informationsecuritydbsystel/SitePages/Nav%20(Confluence)/Vorgaben%20in%20Arbeit/Privileged%20Access%20Management.aspx#:~:text=f%C3%BCr&text=pan&text=welche&text=Umgebungen
- Ist das ein Clash DB InfraGO (geltend für CNP) vs. DB Systel?
- Enabler: Umstellung Umgebungen auf der ABN-Stage auf PAN-Client (→ das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-589)  
## Agenda 27.01.2025
- Access-Proxy:
- Infos: https://db-planet.deutschebahn.com/pages/sipsteam/apps/content/application-proxy-mobile-app-gateway
- Funktioniert für B2B Guests, siehe https://db-planet.deutschebahn.com/pages/b2b-accessmanagement/apps/content/b2b-accessmanagement
- NuR-Benutzer werden als B2B Guests angelegt → Nutzung des Access-Proxys möglich
- TTTneo: Durchstich Bestellsystem → TPN über eigenes MSK-Cluster letzte Woche erfolgreich. Allerdings musste MSK-Cluster in primäres Subnetz gestellt werden.
- Wenn wir das für TPN grundsätzlich über unser MSK-Cluster umsetzen, müssen wir das für alle Umgebungen anpassen, die an TTTneo/TPN angebunden werden. Werden hier Probleme erwartet? Gibt es alternative Vorschläge?
- TPN kann kurzfristig kein eigenes MSK-Cluster betreiben.
- Trennung internes/externes MSK-Cluster? Betrachtung Berechtigungen & Backup/Recovery notwendig.
- Entscheidung: Wahl der Alternative: 1 MSK-Cluster im primären Subnetz mit Einschränkung der IP-Range
- Schrittweise Umstellung von JDK 17 auf JDK 21 (Corretto)
- Können die RDS-Instanzen aus dem primären Subnetz genommen werden (zumindest in höheren Umgebungen)?
- Anmerkung Martin/STeam: wenn wir die Subnetze ändern, dann kann die fachliche Betriebsführung nicht mehr drauf zugreifen (vgl. O2CZERO-4892)
- Entscheidung: Festlegung der Vorgehensweise im Zusammenhang mit der späteren DevOps-Betriebsführung → dann ausführliche Dokumentation
- Martin / STeam: Stage von ABN2 ändern?
- Wenn wir auf ABN2 den Durchstich zu TTTneo herstellen wollen und dafür doch noch Anpassungen erwarten, dann wollen wir vermutlich öfter als im 2 Wochen Release-Zyklus neue Image-Versionen deployen.
- Wäre es sinnvoll ABN2 dafür im Staging-Prozess anders einzusortieren, auf Ebene von SIT oder IEU?
- Entscheidung: Abwarten bis das weitere Vorgehen bzgl. TTTneo geklärt ist. Bis dahin keine Änderungen an ABN2.
- Bing / STeam: PR-LPRV: Anwendungsspezifische Consumer/Producerrechte für Kafkatopics: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1471
- Dokumentation der Producer/Consumer im Runbook: https://bestellsystem1.gitpages.tech.rz.db.de/docs/runbook/02-architecture/07_deployment_view.html#_kafka
- TODO für alle Teams: Prüfung, dass die Dokumentation im Runbook korrekt ist
- TODO für alle Teams: Übernahme der Konfiguration, KOMBau-Konfig kann als Blaupause verwendet werden (Consumer.yaml, Producer.yaml)
- Frank L. / Zero: Fehlerbehandlung Validierungsfehler (evtl. auch für andere Fehler: gibt es best Practices - Fehlertopics scheinen mir nicht immer optimal)
- Schema-Validierung bei Producer und Consumer
- Nicht-lesbare Nachrichten in DLQ-Topic sammeln, Monitoring auf diesem Topic mit Alert, ggf. Verarbeitung weiterer Nachrichten von diesem Topic stoppen
## Agenda 29.11.2024
- Frank/Martin/STeam: Artifactory-Downtime am 7.12.
- Problemstellung 
- CNP-Maßnahmen dazu, Daniel Werdermann: 07.12.2024: Artifactory Update + Downtime
- Wollen wir das Bestellsystem weiterentwicklen um künftig besser damit umzugehen?
- für den Betrieb
- für Dev-Pipelines?
- Wir hatten schon über ECR als zusätzliche OCI-Quelle gesprochen, doch das nützt uns relativ wenig weil wir auch Datei- und Helm-Repos benötigen. Und für Dev dann auch Maven+NPM.
- Lösungsfindung:
- Kopieren der Images nach ECR über entsprechenden Pipeship-Job
- SL-Ausschluss (in SL-Dokumentation mit aufnehmen): Wenn Artifactory ausfällt, können wir keinen Hotfix erstellen
- Durchstarten von Nodes beim Ausfall von Artifactory möglich
- Helm-Charts entweder (wäre zu testen)
- in S3 über Helm S3-Plugin (Race-Condition bei index.yaml-Editierung)
- oder in ECR (siehe https://docs.aws.amazon.com/AmazonECR/latest/userguide/push-oci-artifact.html)
- Enabler:
- Umgang Nicht-OCI-Artefakte bei Verwendung von ECR (CA-Zertifikaten usw.)
- Helm-Charts S3 vs ECR
- ECR in Pipelines einbinden
- auf Jan bzgl. Access-Proxy für Portal zugehen (längere Patchfristen)
- Nach Erstklärung → Wiedervorlage in Architekturrunde
-  DR-Test:
- Camunda-Backup-Konzept (siehe https://docs.camunda.io/docs/self-managed/operational-guides/backup-restore/zeebe-backup-and-restore/)
- Team CIB: Backup-Vorgehen testen und dokumentieren → Enabler für PI 36
- DB-Schnitt:
- am Ende vom DR-Test liefen 2 DB-Cluster parallel → Migration im laufenden Betrieb wäre notwendig
- DB-Schnitt doch anders wählen?
- zu beachten:
-
DB Gold: 99,91% Verfügbarkeit im Jahresmittel, RTO: 2 Stunden
Erwartete Datenbank-Größe (AVT): ca. 2 TB
- Zugriff auf die Datenbank nur von PAN aus - dort maximale Storage-Size: 50 GB
- UKA-Ausfall-Zeit-Ziel pro Jahr: <12 Minuten
- ADR ausarbeiten → + Architekturrunde
- DB-Instanztyp:
- Multi-AZ RDS DB-Cluster empfindlich für deaktivierte KMS-Keys
- Risikoabwägung: Instanztyp beibehalten oder Alternativen nochmal in Betracht ziehen?
- ADR bzgl. DB-Cluster überarbeiten: + Architekturrunde
- Norbert: Wo sollen wir Alles dokumentieren? (Confluence, Runbook, GIT)
- Testprotokolle: Weiterhin in Confluence
- Wiederanlaufpläne: im Runbook
## Agenda 15.11.2024
- DR-Test-Dokumentation: https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=386382061
- Martin/STeam: Unsere Anwendungen haben sehr unterschiedliche Datenbank-Einstellungen in den application.yml-Dateien (spring.flyway, spring.jpa, spring.datasource). Können/wollen wir das mal vereinheitlichen?
- Timeout-Werte und sonstige relevante DB-Parameter möglichst vereinheitlichen und im Configuration-Management-Abschnitt dokumentieren
- /   / Konfiguration in Teamanwendungen betrachten und Abweichungen von Default-Werten begründen
- Wiedervorlage in nächster Architekturrunde
- STeam: Archivieren von bestellsystem-deployment-helm
- Wird von Team 404 noch verwendet
- Kann noch nicht archiviert werden
- Empfehlung: Überschreiben der Werte in der values.yml
- ZAP-Test wird von AT/Review-Umgebung über ci-files auf andere Umgebung umgestellt. Team STeam stellt neue Version von ci-files zur Verfügung (Zeitpunkt abhängig von DR-Test-Umfang).
- CI & TTK prüfen im health-Check ob Partnerdaten vorhanden sind, dies führt zu Problemen im neuen Kubernetes-Job zum Befüllen der Daten in der KB (Team ZERO)
- Health-Check unabhängig von vorhandenen Partnerdaten → Smoketest prüft Validität der Partnerdaten nach dem Deployment
- Alternativ: Einspielen der Partnerdaten via Sidecar
- Weiteres Tracking des Themas in CI/CD-Runde
- Diego/Team 404: WebSSO für E2E-Umgebungen: Das Portal unterstützt Keycloak und WebSSO als Login-Maske, aber WebSSO wird momentan nirgendwo verwendet. Sollen wir für (einige) E2E-Umgebungen nicht WebSSO einsetzen? WebSSO kann nicht automatisch getestet werden, aber für Umgebungen mit ausschließlichen manuellen Tests kann es Sinn machen, WebSSO als Login-Maske zu konfigurieren.
- Prüfung, ob ABN1 oder ABN2 an WebSSO angebunden werden kann
## Agenda 01.11.2024
- Flyway: Entscheidung für Umsetzungsvariante
- Enscheidung: Variante 4 per Default, Variante 1 bei Bedarf (wie z.B. SV)
- Flyway-Bibliotheken müssen aus Images entfernt werden
- Bei lokaler Entwicklung ggf. mit Maven-Profilen arbeiten
- CNB: wird beibehalten mit Ausnahme von SV und zukünftig ggf. Projekten mit Bedarf an Multi-Modul/-Image-Umsetzung.
- Systemtests laufen maßgeblich auf Base-Umgebungen. Änderungen an Systemtests führen zu einem MR. dessen Pipeline die Tests auf IEU ausführt
- Pipeline-Id + ENVIRONMENT-Wert anpassen/überschreiben
- & stimmen sich bilateral ab
- Diego: Wie gehen wir mit der Token-Rotation für den Azure-AD-Token um, den die PM für die Verbindung mit NuR verwendet? Momentan muss der Token nach 1 Jahr ersetzt werden.
- Im Entwicklungshandbuch zu dokumentieren
- Martin/STeam: Wann wollen wir nochmal PostgreSQL updaten? Und wie oft wollen wir das vor dem Live-Gang noch machen? → geklärt?
- ein Update auf v16 wäre sinnvoll, wollen wir das machen und wann? Liegt in PI34S5: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1318
- ab Ende 2024 könnten wir auch auf v17 gehen: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1319
- Background: PostgreSQL released jährlich im September/Oktober und unterstützt major Versionen für 5 Jahre, der AWS-RDS-Support für Versionen läuft immer ein paar Monate nach. Generell ist es wünschenswert jetzt im Dev-Stadium eine möglichst neue Version zu benutzen, damit im Live-Betrieb möglichst viel Flexibilität und Zeit bis zu einem Zwangs-Update bleibt.
- STeam: ZAP Scans in Build-Pipeline oder anderem Kontext?
- In Enabler das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1325 wurde ein Trigger-Job in bestellsystem-deployment umgesetzt. Der Trigger-Job triggert die Gitlab-Repo owasp-zap-scanner um die Zap-API-Scans und Zap-Baseline-Scans auszuführen. Bsp. Pipeline: https://git.tech.rz.db.de/bestellsystem1/infra/bestellsystem-deployment/-/pipelines/39649981
- Zur Abstimmung: Gegen welche Umgebung (nach welchem Deployment) soll der Trigger-Job angestoßen werden. Wäre IEU an der Stelle passend? Info: die Zap-Scans dauert es ca. 30 Min
- Entscheidung:
- Tests auf Umgebung IEU
- Einschränkung der Tests nur bei Änderungen von Services mit Zugriff aus dem Internet: Common Interface, Portal-Middleware, Stammdaten-Bereitstellung
- zukünftige Alternative für Whitesource?
## Agenda 11.10.2024
- Lösungsansatz für AT/Review-Deployment in Bezug auf der Umstellung auf Helmfile abstimmen: Alternative Lösung und aktuelle Nutzung der AT/Review-Umgebung findet man in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1324
- Nutzung der Umgebungen: 
- Nutzung der AT-/Review-Umgebung maßgeblich für ZAP-Scans → kann auf Base-Umgebung stattfinden (sinnvoll: Durchführung in bsz-abn-Umgebungen)
- Team 404: Nutzung für Cypress-Tests → kann auf Base-Umgebung stattfinden
- Team CIB: Nutzung für KITs → Deployment bereits separat umgesetzt
- Varianten
- Variante 1: Beibehaltung der AT/Review-Umgebungen
- Replizierung von Helmfiles in die jeweiligen Projekte notwendig
- Durch die Projektteams umzusetzen
- Variante 2: Verwendung der Base-AT-Umgebung für Cypress- und KI-Tests
- Zentrale Verwaltung der Deployment-Konfiguration in bestellsystem-deployment
- "Basiskonfiguration" wird von STeam erstellt
- Aufwand vergleichbar zu Variante 1
- Entscheidung:
- Umstellung auf Variante 2
- Vorgehen wird in CI/CD-Runde detailliert
- Vereinheitlichung (KITs von SV) nachrangig zu Umstellung von z.B. Team 404 Cypress-Tests
- Flyway
- Umsetzungsvarianten:
- Variante 1 (siehe SV): separates Maven-Modul + separates Container-Image, Images werden via Dockerfile erstellt
- Ablauf
- Beim Erstellen der Images im Buildprozess wird auf Dockerfile zurückgegriffen. Dabei wir direkt ein separates Flywayscripts-Image für SV gebaut. Siehe Diagramm.
- Beim Helm-Deployment wird ein Kubernetes-Job ausgeführt, der das Image startet. Dadurch wird automatisch die Migration durchgeführt. Anschließend wird der Container wieder beendet. Siehe Diagramm.
- Vorteile/Nachteile:
- Vorteile:
- Application Image enthält keine unbenötigten Dateien (Flyway-Skripte)
- Flywayscripts-Image wird parallel zu Application-Image gebaut
- Nachteile:
- Umbau des Buildprozesses in allen Projekten notwendig (siehe Umstellung CNB → Dockerfile)
- Updates/Wartung alles Images muss durch das jeweilige Projektteam sichergestellt werden
- Variante 2: Image dynamisch erstellten und Flyway-Migrationsskripte aus Applikations-Image auslesen
- Ablauf
- In der CI/CD-Pipeline werden nach dem Erstellen des OCI Images der Application die Flyway-Skripte aus dem Image als Artefakte herausgeschrieben. Im Folgeschritt wird dynamisch ein Flywayskripte-Image gebaut (siehe Diagramm); kann ggf. parallelisiert werden.
- Die Ausführung kann wie in Variante 1 erfolgen.
- Vorteile/Nachteile
- Vorteile:
- Funktioniert auch mit CNB → Anpassungen maßgeblich in CI/CD-Pipeline
- Nachteile:
- Erhöht weiter die Logik/Komplexität der Pipeline
- Variante 3: Kombination aus CNB für Applikation + Dockerfile für Flywayscripts-Image
- Ablauf
- In jedem Projekt mit Flywayskripten wird ein Dockerfile ergänzt für das Erstellen eines Flywayscripts-Images. Der Buildprozess wird so angepasst, dass er zusätzlich zum Application Image ein Flywayscripts-Image bauen kann (unter Verwendung des Dockerfiles)
- Die Ausführung kann wie in Variante 1 erfolgen.
- Vorteile/Nachteile
- Vorteile
- Application Image enthält keine unbenötigten Dateien (Flyway-Skripte)
- Nachteile
- Updates/Wartung des Flywayscript-Images muss durch das jeweilige Projektteam sichergestellt werden
- Zusätzliche Logik in Pipeline bzgl. Entscheidung: CNB, Dockerbuild oder Kombination aus CNB + Docker
- Martin: Wissen wir eigentlich dass wir zwingend ein eigenes Image für die Flyway-Scripte brauchen? sonst schlage ich vor
Variante 4: Der Build bleibt so wie jetzt, wir schreiben nur einen eigenen Flyway-Setup-Job
- Ablauf
- Wir bauen die Anwendung wie bisher
- Beim Deployment starten wir einen Flyway-Job und mounten die Scripte aus unserem Application Image
- Vorteile/Nachteile
- Vorteile
- Keine Änderung am Build-Prozess nötig
- Keine zusätzlichen Images zu pflegen und abzusichern (unter der Annahme dass die Open Source Flyway Images okaye Qualität haben)
- Nachteile
- Application Image enthält die Flyway-Skripte, die könnte man als unbenötigten Dateien sehen
- Entscheidung:
- Annahme Minimal Image: Keine Flyway-Bibliotheken. Flyway-Migrations-Skripte (*.sql) können enthalten sein.
- Entscheidung zwischen Varianten 3 oder 4. Team Zero und Team 404 besprechen das nochmal im Team.
- Deployment-Job vs. Init-Container zu klären
- Extra Termin für Thema
- CNB (Fortsetzung)
- Weiteres Vorgehen abhängig von Entscheidung zu Flyway
- Wollen/Brauchen wir eine einheitliche Lösung im Bestellsystem oder ist es ok, wenn einzelne Projekte bei Bedarf vom "Standard" abweichen (Bsp. aktuell: SV)?
- Entscheidung: tbd
## Agenda 27.09.2024
- CI-Files in den Projekten auf Version 3.6.0 aktualisieren (helmfile + C8) bis heute EOB
- CNB: behindernde Einschränkungen von CNB bzgl. Multi-Modul-Projekten und Multi-Image-Projekten; (wie) lässt sich das mit CNB lösen? Was ist die Alternative?
- target-Verzeichnis in build_application_image_heroku hartkodiert
- Stellen: 
- https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L533
- https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L534
- https://git.tech.rz.db.de/bestellsystem1/infra/ci-files/-/blob/master/dist/git/customize-job-build_application_image_heroku.yaml?ref_type=heads#L773
- Für Projekte konfigurierbar machen?
- Job kann pro Ausführung nur 1 Image bauen. Werden mehrere Images benötigt, mehrmalige Ausführung notwendig → negative Auswirkung auf Performance in der Pipeline
- Test-Report aus dem Build wird verworfen → zusätzliche Logik in Pipeline für Testauswertung notwendig
- Job-Komplexität: build_application_image_heroku hat ca. 900 Zeilen, Build-Job in SV: 40 Zeilen + 180 Zeilen in 5 Dockerfiles
- Image-Größe: mit CNB > 500 MB, nach Umstellung auf Dockerfile ~300 MB
- Abgesehen vom Umstellungsaufwand: Mit welchen Nachteilen müssten wir leben, wenn wir auf CNB verzichten?
- SV-Variante des Image-Bauens nachvollziehen und in STeam diskutieren
- Wiedervorlage in Architekturrunde am 11.10.
- End of support für AWS AppMesh am 30.09.2026 im Zusammenhang mit das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-6343
- Ticket O2CCIB-6343 zurückstellen, bis eine Entscheidung über das weitere Vorgehen getroffen wurde. Danach einplanen.
- Review von ADR-67, https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/blob/feat/O2CZERO-4414-adr-anbindung-stationsportal/02-architecture/103-adrs/0067-datenbereitstellung-stationsportal.adoc?ref_type=heads
- Frank (aus CI/CD-Runde): Prod und Dev Repos für Apis (renovate erstellt aktuell MRs für alles)
- Ziel für alle Projekte: Renovate berücksichtigt nur "getaggte" Versionen von APIs 
- Gewünscht ist: nur die "getagged" Versionen  sollen released werden. => also Benutzen des ADR58-Release-Workflows auch für APIs und Libraries => O2CSYS-1210
- Einfache Variante: Eine CI/CD-Pipeline, Ziel-Repository ist abhängig von Tag (→ Prod) oder "Nicht Tag" (→ Dev)
- nochmal in STeam abstimmen
- Frank L./Team Zero: Talo-Logging nur für Cockpit? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-2221
- Neue Variante von Netcool/Cockpit verwenden: nur definierte Alarme an Netcool senden, nicht mehr das komplette Log; Talo-Logging damit nicht mehr notwendig
- stellt Links zur Dokumentation zur Verfügung
- Wiedervorlage in Architekturrunde am 11.10.
- STeam/Michael: Kafka-ui generell (intern) deployen? Hilft beim prüfen der Funktionalität von MSK
- Kafka-UI steht auf dem Dev-Cluster bereit. Was ist mit generell gemeint?
- In ABN und PROD müssen die Zugriffsrechte minimal sein (Least-Privilege-Prinzip) → keine Schreib- oder Löschrechte
- Bereitstellung aktuell über Port-Forwarding; Zurverfügungstellung ohne Port-Forwarding nur mit entsprechender Authentifizierung (z.B. Anbindung an Keycloak)
- Klärung mit Michael, Umsetzungskonzept
## Agenda 06.09.2024
- Festlegung von Trust Boundaries → Teil der Bedrohungsanalyse mit Security Engineers Anfang Oktober
- PI 33: Produktionsumgebung: Jeder Services läuft mit einem eigenen Datenbank-Cluster? (siehe auch 8.4.2024)
- ADR-65. Aufteilung der Datenbank-Instanzen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-493 
- eigene DB für SV + IFP-Connector
- Status ändern auf Akzeptiert
- ADR 66 - Nutzung von helmfile das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-505
- Thema in PI 34 einplanen
- Team-Enabler für Umstellung erstellt ; jedes Team soll min 1 Service umstellen
- Feedback zu ADR wird noch gegeben (von Team STeam)
- Frank L./Team Zero: Besprechung des ADR Datenbereitstellung für das Stationsportal https://git.tech.rz.db.de/bestellsystem1/docs/runbook/-/blob/feat/O2CZERO-4414-adr-anbindung-stationsportal/02-architecture/103-adrs/0067-datenbereitstellung-stationsportal.adoc?ref_type=heads  WICHTIG - noch vor PI-Planning 34
- Keine Logik in SV zur "Filterung" von Nachrichten für externe Systeme (Nachrichtenstatus)
- Konverter sollten alle Nachrichten aus dem AV-Topic lesen und Filterung selbst vornehmen
- Datenstruktur für Stationsportal (für aktuelles Vertragsdaten-Dritte-Topic) wird im Laufe von PI 34 geklärt (und im ADR nachdokumentiert)
- passt ADR an
## Agenda 09.08.2024
- Ankündigung von STeam: Zusammenlegung der DEV-Datenbanken sowie Zusammenlegung der Datenbanken  EVU-Test und EVU-E2E (ADR-59)
- Umstellungsdetails:
- Umsetzung: PI 33 O2CBS - S4 - O2CSYS, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1123
- Nur Daten von Keycloak werden mitgenommen
- Downtime für Umschwenken von IEU/SIT/E2E wird in Teams-Kanal angekündigt
- Wie ist der Kommunikationskanal über Downtime für Umschwenken von EVU-Test/EVU-E2E? Keine Daten werden mitgenommen außer KeyCloak!
- Abstimmung bzgl. E2E und EVU*-Umgebungen mit TTT-Koordinatoren notwendig!
- Keine Umstellung von SIT, E2E, EVU-Test und EVU-E2E bis 4.9. (Zeitpunkt Entscheidung Go-Live 2025)
- SV-Datenbank wird nach Camunda-8-Umstellung sowieso gelöscht
- Info: Update von CA-Cert durch Amazon am 22.8. (Hintergrund/Links in O2CSYS-871 und O2CSYS-1068)
- Einbindung Netzgrafik in das Bestellportal - Fortsetzung
- Frontend über Angular-Bibliothek
- Abhängigkeit durch Angular-Version
- Datenaustausch (relevante Netzdaten) über Kafka
- Backend
- berechnet Netzgrafiken - teilweise anhand von Benutzerfiltern; dauert teilweise 3-4 Minuten (ressourcenlastig)
- Vorschläge zur Umsetzungsvarianten von KuK:
- Bibliothek zur Einbindung in eine BS-eigene Komponente
- Netzlotse wird als Docker Image zur Verfügung gestellt und in das Bestellsystem-Deployment eingebunden
- Konsequenzen der KuK-Vorschläge: Betrieb "fremder" Komponenten im Bestellsystem mit sämtlichen Konsequenzen
- Alternative: Betrieb des Netzlotsen durch KuK
- Zugriff über synchrone Schnittstelle auf Netzlotse (durch z.B. Portal-Middleware)
- KuK müsste auch SL Gold anbieten
- Variante: Netzlotse bei KuK betreiben und als optionales Feature behandeln; vorberechnete Netzgrafiken zwischenspeichern; wenn nicht verfügbar keine Filteroption
- Feature-Ticket ergänzen
- Aus Security-Assessment: Code-Review Enforcement in Gitlab?
- Gegen Enforcement spricht die schnelle Fehlerbehebung im Falle eines Notfalls
- Kein Enforcement in Gitlab um Fehlerbehebungen nicht zu behindern
- Code-Reviews sind bereits Bestandteil der DoD
- Rückfrage bei Security Engineers bzgl. Formulierung in DoD
- Neue Umgebungen: Was ist der Prozess / was sind die Zuständigkeiten des Deployments und der Konfiguration (und des Monitorings) für das deployment der bsz-Apps? Hintergrund: PREPROD ist noch nicht vollständig mit allen bsz-Apps bespielt worden. Insbesondere die Konfiguration der Apps untereinander ist von Interesse! Wunsch: Vorgehen für ABN1/ABN2/PROD planen.
- Smoketest:
- Je 1 Bestellung über beide Eingangskanäle (CI und Portal-UI) auslösen und prüfen, ob sie in den entsprechenden Kafka-Topics (→ IFP) ankommen
- Bei Produktion: Abstimmung mit TTT notwendig
- Abstimmung mit und  
- Gemeines Review der Umgebungskonfiguration mit allen Teams pro Umgebung und bei Bedarf
- Dokumentation der Umgebungen im Runbook
## Agenda 12.07.2024
- Einbindung Netzgrafik in das Bestellportal
- C2S Capability: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eC2SLS-2090
- Netzgrafik Beispiel: https://netzlotse-frontend-kuk-iat.cnp-test.comp.db.de/netzgrafik
- DB Backup & Recovery: Störfälle, Wiederherstellung, Konsequenzen
- Kein DB-Split, da es bei Wiederherstellung die Komplexität deutlich erhöht
- Eingänge von SV sollten auf Kafka basieren
- Kafka-Backup separat zu betrachten
- RocksDB in Camunda 8 berücksichtigen!
## Agenda 17.05.2024
- Aktueller Stand Systemtests
- Aufgabe für das kommende Sprint-Planning: Klärung bei 404 und CIB, ob Jan 1-2 Tage bzgl. Selenium-Tests aushilft
- Erste Ausführung mit dynamischen Umgebungen immer noch häufig fehlerhaft? → zunächst Selenium-Problematik betrachten
- ART-Enabler für PI 33 vorbereiten  
- O2CBS-353: Die Systemtests sind in Anlehnung an die KITs von SV refaktoriert
- Aus PI 33 Planung entfernen
- Umstellung Architekturdokumentation
- Architekturdokumentation ins Runbook übernehmen, bisheriges Repository archivieren
- O2CBS-408: Vorbereitung Produktivsetzung: Ausarbeitung des Runbooks
- Testdaten für Kundendaten-Bereitstellung (bis 300 Partner über SQL in Datenbank insert): Die SQLs in Helm-Chart oder in Artifactory? siehe ADR 47
- Falls es eine Pflegeschnittstelle gibt → Testdatenimport über Schnittstelle
- Daten, die in integrativen Umgebungen aus externen Systemen geladen werden, werden über (Wire-)Mocks zur Verfügung gestellt
- Neuer ADR + Enabler  
## Agenda 19.04.2024
- Runbook-Vorstellung:
- Git-Repo: https://git.tech.rz.db.de/bestellsystem1/docs/runbook
- Gerenderte Variante: https://bestellsystem1.gitpages.tech.rz.db.de/-/docs/runbook/-/jobs/207310721/artifacts/public/doctoolchain/04-runbook/05-processes/01-configuration-management.html
- TTT-Produktivsetzung in Confluence: https://arija-confluence.jaas.service.deutschebahn.com/pages/viewpage.action?pageId=316973165
## Agenda 8.04.2024
- Frage von Team Zero: Gibt es eigentlich ein Rechte- und Rollenkonzept für das neue Bestellsystem?
- Dokumentation für Entwicklungs-/Betriebsrollen
- Dokumentation technischer Benutzer und Rollen
- Dokumentation für CI
- Dokumentation für Portal
- : Template für Dokumentation + Enabler erstellen
- Produktionsumgebung: Jeder Services läuft mit einem eigenen Datenbank-Cluster? (Problem in der Metrikerhebung der Stammdatenbereitstellung führt zu systemweiten Problemen)
- Ein Datenbank-Cluster für alle Services: weniger Wartungsaufwand, konsistenter Datenbankstand über komplettes Bestellsystem
- Ein Datenbank-Cluster pro Microservice: bessere Isolation (Burst-Balance), überschaubarere Größe bei Backups/Snapshots, individuelle Skalierung
- Informationen sammeln bzgl. Wartungsaufwänden
- Arbeitsorganisation im Betrieb berücksichtigen: ein Team für ein DB-Cluster zuständig? Oder arbeiten mehrere Teams an einem DB-Cluster?
- Last- und Performancetests hinsichtlich Datenskalierung auswerten
- Datenmigration bei ggf. notwendigen Cluster-Strukturänderungen berücksichtigen!
- : Wiedervorlage in PI 33
## Agenda 22.03.2024
- Klärung, ob bestellsystem-parent-pom in der Form weiterbestehen sollte
- Enge Abhängigkeiten führen zu manuellem Anpassungs- und Testaufwand
- Zentrale Stelle zum Aktualisieren von Abhängigkeiten (z.B. für APIs und bei Schwachstellen)
- Camunda in SV "bremst" Aktualisierung von bestellsystem-parent-pom
- Vorschlag: PoC in einem IP-Sprint
- Thema wird in CI/CD-Runde mit aufgenommen ( : in Agenda eintragen)
- Aus Problem Solving: Versionsnummern von Releases noch nicht gut von Snapshots zu unterscheiden
- Fragestellung: Was ist der Nutzen des Timestamps in der aktuellen Versionsnummer? Wird das irgendwo zwangsläufig benötigt?
- Vorschlag:
- Bei Trigger durch Git-Tag: Name des Tags
- Bei Trigger auf Master-Branch: Basis-Versionsnummer gemäß POM + „-m-PIPELINE_ID-COMMIT-SHA-SHORT“ + „-SNAPSHOT“
- Bei Trigger auf Nicht-Master-Branch (z.B. "feat/"): Basis-Versionsnummer gemäß POM + „-b-PIPELINE_ID-COMMIT-SHA-SHORT“ + „-SNAPSHOT“
- Bei "-SNAPSHOT"-Suffix in den Abhängigkeiten kann Create-Release-Tag-Job abbrechen (Prüfung der Abhängigkeiten wäre einzubauen)
- Weitere Frage:
- Verwendung von Maven-Release-Plugin? Ggf. besser: Version-Plugin, da Release-Plugin auch Git-Operationen vorsieht; außerdem muss NPM-Projekt (Portal UI) berücksichtigt werden
- Separater Termin ( : einladen)
- ACAT: Wir müssen wohl die ACAT Gruppen neu definieren...
- Warum? Wir haben für das WRITING nur gmu Gruppen, welche einen Admin Account brauchen → separater Termin ( )
- Betreibervorgaben werden nochmal geprüft ( )
- Martin/STeam: hat unser Keycloak eigentlich noch irgendwelche Verbindungen zu Nachbarsystemen (mit Systel-TLS-Zertifikaten)?
- in der Vergangenheit benutzten wir den eBRS-AD, das ist lange deaktiviert, oder? → Systel-TLS-Zertifikate können entfernt werden
- wir würden dann gerne unser keycloak-Login-Theme und das custom-CA-Cert-Setup aus dem Deployment entfernen, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1018
- erst nach Umstellung auf WebSSO in EVU-Testumgebungen umsetzen
## Agenda 8.03.2024
- DoD: Abnahme der Story in integrierter Umgebung vs. ADR 58
- Entscheidung:
- IEU Deployment in Testing-Pipeline aufnehmen (unabhängig vom E2E-Stand) → Abnahme kann weiterhin auf IEU stattfinden
- erfolgreiches IEU-Deployment ist nicht notwendig für erfolgreichen Abschluss der Pipeline
- Systemtests werden auf IEU nicht erneut ausgeführt bei Trigger durch Testing-Pipeline
- das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1020
- Abhängigkeiten zwischen Projekten beim Deployment
- zwischenzeitlich über manuelle Anpassung in bestellsystem-deployment.
- Lösung über Multi-Artefakt-Projekte.
- Neuer Enabler für STeam: PoC für Portal-UI + Portal-Middleware das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-1043
- das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CBS-338
- Aufgabenteilung zwischen Teams Zero und CIB
- Ideen bzgl. API-Umsetzung 
- Serialisierungsmechanismus (vor Deserialisierung auf Server-Seite bzw. nach Serialisierung auf Client-Seite Byte-Stream verwenden) erweitern (REST + Kafka); ggf. über Aspekte
- Einheitlich konfigurierter ObjectMapper von Jackson
- Ideen bzgl. Datenbank
- Felder/Entitäten über Annotations inkludieren/exkludieren
- Relevante Felder konkatenieren und aus Ergebnis die Signatur erstellen; Reihenfolge der Felder muss beim Speichern der Metadaten zur Signatur berücksichtigt werden → beim Auslesen wird in Metainformationen gespeicherte Reihenfolge zur Validierung gespeichert
- Bei Assoziationen zu anderen Tabellen Grenze bei Fremdschlüsseln ziehen (assoziierte Entität wird nicht signiert/validiert)
- Konzept → ADR
## Agenda 23.02.2024
- klären, wie Kafka in den base-at-Umgebungen zukünftig aufgesetzt wird
-  → Frage: Wer löscht die Kafka-Topics in base-at ? (siehe Agenda 2.2.) 
- das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-977
- Entscheidung: Variante 3 - eigene Kafka-Cluster pro Umgebung / Verwendung von MSK auf den statischen Umgebungen (IEU, SIT, ...)
- Martin/STeam: wir hatten beim PI-Planning die Anregung mitgenommen den Workflow unserer Security-Scanner in der Pipeline zu überarbeiten, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-838
- jetzt haben wir ein Enabler-Ticket mit vielen Gedanken aus dem PIP, aber seitdem keine Stakeholder die irgendwelche Anforderungen formulieren und konkretisieren
- Frage hier in die Runde: was wollen wir ändern?
- Ticket in PI32 neu betrachten (nach weiteren Tests mit DefectDojo)
- Entscheidung: Security-Scanner sollen per Default nur noch auf Master-Branch laufen
- Folgende Security-Scanner nur in Master-Branch: Fortify, Whitesource, trivy, OWASP ZAP
- neues Ticket für STeam in PI31 das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-987 anstelle von O2CSYS-838 (verschoben nach PI 32)
- Martin/STeam: wollen wir auch für die Libraries und APIs die geplanten neuen Release-Prepare-Jobs übernehmen? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-896
- bei Libraries natürlich ohne Testing- und Staging-Pipelines und Deployment
- passende Funktion die wir nutzen können: nur bei Git Tag Upload ins Prod-Repo, GitLab-Release mit Changelog, bei Bedarf auch Jira-Lösungsversion
- Entscheidung: Kein akuter Handlungsbedarf. Neubetrachtung bei Diskussion über Refactoring von gemeinsam verwendeten JAR-Dateien/Bibliotheken
- MSK Sizing
- erste Maßnahme: Speicherplatz erhöhen (30 GB), perspektivisch größeren Wert wählen als RDS
- → Monitoring der Volumeauslastung prüfen
- → Retention-Property prüfen
- → Auto-Scaling-Konfiguration prüfen ( )
- → Gehen Nachrichten beim Hochskalieren des Speichers verloren? ( )
## Agenda 9.02.2024
- DevOps: Synergien mit C2S möglich und gewünscht?
- Vorstellung: Virtuelle ART-übergreifende Teams zur Optimierung der Bereitschaftszeit in der Betriebsführung
- ART-übergreifende fachliche Betriebsführung sinnvoll
- technische Betriebsführung als ART-eigenes virtuelles Team
- Michael/STeam: Multireplicafähigkeit von Bestellsystem-Service Stack in Namespaces bsz-ieu/bsz-sit/bsz-e2e etc. - Was wäre noch zu tun um alle mind. 2x auszuführen? 
- Portal-Middleware in bsz-sit (Grund: BBZ + Metrik, BBZ soll durch NuR abgelöst werden, ggf. alternativ Metrik aus-/umbauen bzw. Test im system-integration-test deaktivieren)
- taftap-tdm-konverter → noch in Entwicklung + nicht eingebunden in Tests → wird multireplicafähig
- e2e Namespace → kann hochskaliert werden
- stammdaten-bereitstellung → Ticket für Multireplicafähigkeit: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-3391
## Agenda 2.02.2024
- Klärung notwendig: Partnerkonfiguration im CI / TTK (Team-Zero)
- Partnerkonfiguration in CI; keine erneute Zertifikatsprüfung in TTK
- Klärung mit KomBau, ob Zertifikate weitergeleitet werden müssen  
- Enabler zur Umstellung der Partnerkonfiguration von Yaml auf ein dauerhaft gut wartbares Konfigurationskonzept
- Enabler zur Prüfung des kompletten Subjects (nicht nur CN)
- Frage: Wer löscht die Kafka-Topics in base-at ?
- Muss Kafka-Server dafür gestoppt werden? (https://stackoverflow.com/questions/33537950/how-can-i-delete-a-topic-in-apache-kafka/33538299#33538299)
- prüft bis zur nächsten Architekturrunde, was zum Löschen von Topics notwendig ist (Standalone-Kafka + MSK)
- Technische Dokumentation: Wo und Wie? (Team Zero)
- Strukturiere Ablage von Dokumentation von Microservices + ggf. Betriebshandbuch  
- Martin/STeam: Benennung neuer Services
- wir wünschen uns dass unsere Services bzw. Komponenten präfixfreie Namen bekommen. Weil wir besonders in den Helm-Charts viel mit Text-Präfixen und Suffixen arbeiten, befürchten wir sonst Kollisionen.
- Ein kompletter Service-Name sollte nicht Präfix eines anderen Service-Namens sein
- und können wir uns im Bestellsystem auf eine Schreibweise von "konnektor" oder "connector" einigen? Anscheinend sind die ADR 57 (Kombau) Enablertickets da nicht einheitlich.
- Beachtung einheitlicher Schreibweise
- Git-Tags:
- Format release-vX.Y.Z führt zu Problemen in den Pipelines → Vorschlag: Versionsnummern ohne Präfix verwenden X.Y.Z
- Umsetzung ohne Präfix; bei Problemen erneut betrachten
- Bing/STeam: CNP-MSK bei Base-Umgebung: wollte mit Euch kurz diskutieren, ob CNP-MSK (oder Bestellsystem-Kafka) in Base-Umgebung insbesondere bei System-Tests verwendet werden soll.
- Wunsch wäre CNP-MSK zu nutzen
- Abhängigkeit zum Thema "Löschen von Topics" (siehe oben)
- Besprechung in CI/CD-Runde  
## Agenda 19.01.2024
- Dringend: Umgang mit Versandergebnis nach der Trennung CI / TTK
- Entscheidung: Versandergebnis über eigenes Kafka-Topic von CI → TTK bzw. CI → KomBau
- Daniel/CIB: Konzept zu Kompatibilitätstests https://git.tech.rz.db.de/bestellsystem1/docs/architektur/-/merge_requests/220 für das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-4746 vorstellen
- ELK Stack (ELK ähnliches Stack) als KombauMock
- stattdessen Kafka-Consumer in System Tests einbinden
- EVU-Test-Umgebung: Nachrichten an KomBau verbleiben in Kafka-Topic; können mithilfe Kafka UI betrachtet werden
- Camunda 8: Anforderungen an CNP (z.B. OpenSearch)
- Security-Requirements-Prüfung: Annette, ggf. Diego, Jan, Bing+1, Frank oder Norbert
bahn/project-audit/data/confluence-export/pages/121274378_Abstimmungen mit Cloud Native Platform CNP.md
+391
View File
@@ -0,0 +1,391 @@
# Abstimmungen mit Cloud Native Platform (CNP)
> Confluence Page ID: 121274378
> Version: 191
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Abstimmungen mit Cloud Native Platform (CNP)
> Labels:
---
## DIESE TERMINREIHE FINDET NACH 19.5.2022 ERSTMAL NICHT MEHR STATT, DA CNP-ABSTIMMUNGEN INS SYSTEM-TEAM GEWANDERT SIND
## Allgemeine Infos
CNP - Cloud Native Platform ist unsere Zielplattform für den Produktionsbetrieb, anstelle der noch für die Entwicklung genutzten DBCS - DB Container Services.
Unsere Ansprechpartner:  (PL CNP),  (Architekt CNP), (technischer Ansprechpartner), (PMO - insb. Teams und Planet-Freischaltungen)
Direkte Anfragen und Support über Teams CNP DB Netz - Bestellsystem (privat - Freischaltung erforderlich)
Ab 4.5.21 neuer Regeltermin 9:00-9:45 (organsisiert von )
Monitoring/Status: CNP-Grafana-Dashboards
Dokumentation auf den CNP Confluence Seiten
## Impediments im Bestellsystem/System Team
das I.NVI IT Lifecycle Management Toolissuekey,summary,statuskey,summary,status20project = O2CSYS AND summary ~ CNP AND issuetype = Impediment AND ((status = Fertig AND updated >= -3w) OR status != Fertig) ORDER BY status ASC, updated ASC, priority DESC d1143f0d-33c0-3f1c-b44b-7720150f306e
## Themenspeicher
-
Unter-Themensammlung Monitoring
- können wir über die K8s-API eigene Prometheus- bzw. Alertmanager-Regeln einpflegen? (Die CRDs sind ja vorhanden.) → Anleitung/Prozess vorhanden?  
- Prometheus bzw Servicemonitor Doku gibt es, wird von referenziert.
- Alertmanager Regeln Doku bzw Konfiguration über k8s Objekte gibt es noch nicht. Bzw ist diese nicht CNP Endanwender "ready".
- können wir einen Grafana-API-Key (für einen technischen Benutzer) bekommen, um Annotations (für Deployments) zu senden?  
- können wir eine Grafana Tempo Instanz für Anwendungs-Tracing gestartet (und in Grafana als Datenquelle konfiguriert) bekommen?
- wenn wir per ServiceMonitor  K8s-Label erfassen, dann bekommen die in Prometheus einen Namensprefix (label_app_kubernetes_io_instance) und wir können sie nicht mit Werten aus der CNP-Metrik kube_pod_labels (app_kubernetes_io_instance) korrelieren (beschrieben in O2CZERO-13). Es wäre schöner und für uns benutzbarer wenn das gleich wäre.
## Agenda 19.5.2022
- Dringende Themen
- Sean: OIDC-Login => siehe das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-285 für Ursachen und einen Workaround. Die richtige Lösung kommt erst mit dem Wechsel des AWS-Accounts.
- Konstantin: Wir planen den Umzug in den neuen AWS-Account am Anfang des PI 25 durchzuführen. Aktuell laufen im System-Team Readyness-Tests für die bereitgestellten Cluster.
- Größere Ausfälle sind nicht geplant, aber es werden sich insbesondere die URLs ändern.
- Alte Todos durchgehen!!!
- Konstantin: Fortführung des Termins?
- Zusammenlegung mit der CI/CD Runde beschlossen.
- Ad hoc Themen im Teams Kanal (CNP-Bestellsystem oder Systemteam)
- Klärungstermine bei Bedarf.
- Für spezielle Themen gibt es u.a. die CoP.
## Termin 05.05.2022
Teilnehmer:  
- Dringende Themen
- Bishara: Grafana-Logs beinhalten nur die Daten der letzten 2-3 Stunden.
- Martin: das gleiche Problem ist uns bei Metriken aufgefallen.
- Sean: heute Nacht gab es einen Ausfall in der Infrastruktur (Cortex), daher vermutlich der Datenverlust.
- Wunsch: mind. eine Woche Aufbewahrung, bei Metriken mind. ein Monat oder noch viel länger.
181
complete
: nimmt die Anforderung an CNP mit. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-291
- Martin: Es gab mehrere Ausfälle in den letzten Wochen. Es betraf vor allem Load Balancer (Ingress Setup) und Router. (vgl. vom 29.4)
- Sean: hervorgerufen wurde das durch eine IP-Adressenknappheit in einem Subnetz.
- Sean: Es gab Probleme beim Abrechnen der Infrastruktur.
- Natalia: Es gab spürbaren Kostenanstieg beim Bestellsystem. Untere Stages sollten idealerweise nachts und am Wochenende Umgebungen heruntergefahren werden.
182
complete
: erstellt ein Ticket
Bestellsystem-Ticket dazu: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-288
- Martin: wir haben weiterhin den Wunsch nach Cluster-Autoscaling.
183
complete
: Impediment zwecks Tracking anlegen. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-266
- Natalia: Die Vorgaben zu Patch/Schwachstellen-Management sind bis 1.7 umzusetzen.
- Konstantin: es gibt noch offene Fragen bzgl. der konkreten Details.
- Natalia: prüft, ob ein Stand für alle CNP-Verfahren eingeholt werden kann und mit Richtlinien-Verantwortlichen ein FAQ-Termin nötig ist
- Natalia: Es gibt bzgl. Security diese Punkte zu erfüllen:
- Anbindung an SIEM (Security, Incident und Event-Management) => passiert auf der Infrastruktur-Ebene vgl. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-158
- Konfiguration und Asset-Management: das muss normalerweise automatisiert im SESAM-Tool gepflegt werden. Prüfen, ob das beim Bestellsystem funktioniert.
184
complete
wird separat mit Konstantin geklärt. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-292
- Registrierung der Internet-Verbindungen: erfüllt, da alle Verbindungen über ISGW bzw. Web-Proxy laufen.
- Khalid: Der Bedarf für CloudSearch bzw. OpenSearch hat sich beim Bestellsystem erstmal erledigt. Wir setzen direkt Lucene als interne Bibliothek ein.
## Termin 7.04.2022
Teilnehmer:  
- Dringende Themen?
- Qualys-Scan zu Spring4Shell? => müsste in Masterdata sichbar sein => fragt Emilia
- Heute nachmittag werden unsere K8s-Nodes aktualisiert, also alles einmal neugestartet
- Wie können wir künftig den Grafana- und EKS-/K8s-Zugriff verwalten?
- K8s-Benutzer für uns lesbar unter bestellsystem-ops/.../user.yaml
- Grafana-Teams (d.h. Gruppenzugehörigkeiten) nur für CNP editierbar, Ordner-Zugriffe können wir selbst vergeben
- wir benutzen faktisch nur Ordner Bestellsystem
- ergänzt das im Entwicklungshandbuch, Onboarding-und-Offboarding
- Roadmap für Tracing bzw. CNP-Bereitstellung von Grafana Tempo?
- frühestens in PI25, siehe Themenspeicher
## Termin 10.03.2022
Teilnehmer:  
- Besprechung Tehmenspeicher
- Aktuelle Probleme?
- Cognito
- Integration mit eBRS fragwürdig. 
-   wartet Termin mit ELBA zu u.A. Cognito ab.
- Info zu AWS Account Migration die in unbestimmter Zukunft ansteht.
- können wir in Grafana Zugriff auf die "Explore"-Funktion bekommen? → Status: Abhängigkeit von der Mandantenfähigkeit des Monitoring Backends.  Ticket CNP: das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eCNP-2521
-   gibt allen Cluster Nutzern "Editor" Rechte. → erledigt
- Für alle Nutzer, welche auch cluster zugriff haben (siehehttps://git.tech.rz.db.de/cnp/bestellsystem/bestellsystem-ops/-/blob/master/bestellsystem-dev/cnp-crossplane-v3/provider-kubernetes/user.yaml) wurde der Zugriff als Editor eingerichtet. Mit Ausnahme von  "jasminkeskin", da sie sich noch nicht bei der Grafana  Instanz https://grafana.cnp.comp.db.de/ angemeldet hat.
## Termin 24.02.2022
Teilnehmer: Annette, Diego, Natalia, Martin, Frank, Konstantin, Sean
- Aktuelle Punkte
- Natalia: CNP-Neuigkeiten
- Stabilisierung von Logging und Monitoring => Umstieg auf AWS AMG und AMP geplant. Die Migration beginnt im April.
- Wichtigste Features sind Mandantenfähigkeit und längere Log-Aufbewahrung.
- Credentials Store Service ist bereit zur Nutzung
173
complete
: Link zur Doku posten: hier?
- CNP-API wird um neue Dienste erweitert, AWS SNS, Cognito,  AWS Transfer  Gateway
174
complete
: Termin mit ELBA und Konstantin organisieren
-  Cloudwatch-Metriken werden in Grafana integriert (bis Ende Q1)
175
complete
: bitte mitnehmen, dass zunächst die "Standardmetriken" für RDS, SQS und S3 wichtig fürs Bestellsystem sind => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-156
- Fehlende Fargate-Metriken sind in Analyse
- Die Nutzung von App-Mesh wird gerade für IFP vereinfacht.
- Es gibt bei IFP eine Vorlage für ein Terraform-basierte Konfiguration und Deployment von Keycloak
- Das ist aktuell noch nicht relevant fürs Bestellsystem, kann sich aber später ändern.
- ArgoCD-basiertes Deployment wird bereits bei anderen Verfahren eingesetzt
- Beim Bestellsystem aktuell noch nicht relevant.
- Natalia: Das CNP-Team und die Kommunikation sowie Integration mit den Systemteams soll neu organisiert werden.
176
complete
Sean: Morgen findet eine CNP-interne Veranstaltung statt, die Infos werden nächste Woche verteilt.
## Termin 10.02.2022
Teilnehmer: Sean, Martin, Diego, Annette, Frank, Konstantin
- Aktuelle Punkte
- Sean: Cluster-Nodes sollten runterskaliert werden, da Fargate inzwischen wieder funktioniert.
163
complete
: Ticket anlegen oder finden => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-290
-  Sean: Time-based Autoscaling wäre wünschenswert. Aktuell ist es problematisch, da wir zum einen keinen Überblick über reale Kosten haben, zum anderen aber auch unsere Umgebungen nicht nachts herunterfahren.
164
complete
: Ticket schreiben und mit Natalia (bzw. CNP-Betrieb) die Prio und Rahmenbedingungen klären. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-266
- Aus dem Themenspeicher
- kann die Verfügbarkeit des Monitorings seitens CNP "überwacht" werden? => s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-126
- Martin: Wo kann ich unsere SSO-Benutzeraccounts sehen?
- einige Entwickler brauchen noch Zugriff (auf EKS/K8s und Grafana): emmanuelkontcheutagn, norbertmaurer, aleksandrkil
- fügt diese hinzu. Ich muss nach meinem Urlaub 
- Martin: Update, 2022-02-10: mit unseren erweiterten K8s-Zugriffsrechten sehe ich (und Frank) jetzt die Liste im rolebinding/bestellsystem-user
165
complete
: die Anlage und Prüfung der Benutzer im Entwicklerhandbuch dokumentieren.
- Frank: CNP-API sollte (auch) in unserem Cluster laufen, damit wir unsere Pipelines vereinfachen können.
- Das wird aktuell in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-119 geprüft.
## Termin 27.01.2022
Teilnehmer: Natalia, Sean, Martin, Annette, Diego, Bishara, Bing
- Aktuelle Punkte
- Muss Keycloak wegen des log4j-Themas aktualisiert werden, obwohl laut Wildfly Keycloak nicht betroffen ist?
- Nein, wir vertrauen dem Hersteller und aktualisieren Keycloak regulär auf die neuste Version nach dem Pentest (d.h. im Februar)
- Benutzer-Liste für den Zugriff auf den BSZ-Cluster und Grafana
- Norbert und Aleksandr sind schon drin, Emmanuel ist der nächste, Frank Lemke fehlt noch
- CNP arbeitet an einer neuen Lösung mit Benutzer-Anlage über CNP-API
- vorläufig sollen die Anfragen über den CNP-BSZ-Teams-Kanal eingesteuert werden.
- Logs fehlen
- Aktuell sind die Entwickler im Blindflug, insb. was die EVU-Test-Umgebung angeht
- : analysiert gerade, Zieltermin 28.1 EOB
- Ingress-Limit verhindert aktuell den Zugriff auf neue Review-Umgebungen via ALB (s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-39)
- Ist in Bearbeitung durch das CNP-OPS Team.
- CIB: Können wir auf das Localstack (in den Umgebungen) verzichten? Aktuell wird es benutzt um SQS und S3 zu emulieren. Künftig sollen SQS-Queues und S3-Buckets aus der Pipeline im CNP-Cluster angelegt werden.
- Konzeptionell ist das noch nicht final geklärt, wie man das am besten macht.
- Der Wunsch-Weg der CNP läuft über anwendungsspezifische Crossplane-Compositions.
- Alternativ könnte man auch client-side Tools nutzen, wie pulumi, terraform oder aws cdk8s
- Sean und Martin schauen sich das an in das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-38
- Evaluation von neuen AWS-Diensten kann künftig in einer AWS-Sandbox durchgeführt werden, z.B. für OpenSearch oder CloudSearch.
- Neuigkeiten bzgl. Fargate (s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-22)
- : prüft den Status
## Termin 20.01.2022
Teilnehmer: Martin, Frank, Konstantin, Sean, Natalia
- Offene Bugs (siehe oben)
- OO-33 Logging => (Loki) im Bestfall bis Montag 24.1 gelöst
- OO-21 Monitoring => (Cortex) langfristig ein Umstieg auf einen AWS-Managed-Service
- hier fehlt aktuell noch Alarmierung in CNP, um ohne Kundenmeldung einen Monitoring-Ausfall zu erkennen und reagieren zu können.
- OO-XY Aktuelle Probleme mit dem Propagieren von DNS-Records => bedingt durch einen Crossplane-Update, hier soll ein Patch ausgerollt werden
- allgemeines Vorgehen mit OO-Tickets
- : mittelfristig sollen alle aus dem System-Team Tickets in CNP-Jira anlegen können. Bestellsystem-bezogene Tickets sollen allgemein lesbar sein.
- : aktuell offene Tickets durchgehen und mit CNP-Jira verlinken bzw. aktualisieren.
- Folgetermin/Serie
- erstmal wöchentlich Do 11:30-12:00
- künftig wäre sogar eine Stunde wünschenswert
## Termin 04.01.2022
Teilnehmende: Martin, Annette, Bishara, Sean
Status:
- Allgemeiner Sync
- bestellsystem-dev monitoring ist offline. → keine Metriken. →  
- prüft Punkte aus Tehmenspeicher.
## Termin 7.12.2021
Teilnehmer: Martin, Annette, Diego, Bishara, Konstantin (CNP-Vertreter abwesend)
- Diego: AT- und Review-Umgebungen laufen noch auf DBCS.
- Martin: Migration steht noch aus.
- Martin: Monitoring funktioniert wieder. Leider kann es jederzeit wieder Ausfälle geben, solange CNP nicht die neue Lösung eingeführt hat (Hannes Blut ist dran). Die aktuelle Lösung von CNP ist noch nicht mandantenfähig.
- Martin: Probleme mit Fargate-Selektoren (das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-22) wird evtl. doch zusätzliche EC2-Instanzen als Fallback erfordern.
- Martin: Der Plan mit der Migration von DBCS bis Ende Januar steht weiterhin. Um riskante Änderungen vor den Feiertagen zu vermeiden, starten wir damit erst Anfang Januar.
- Konstantin: Systemteam hat nun ein eigenes Jira-Projekt
## Termin 23.11.2021 
- Dringende Themen:
- Pentest-Vorbereitung für Januar
155
complete
Keycloak läuft (danke ALB), Härtungsemepfehlungen kommen
156
complete
DNS-Namen sind beauftragt, Bestätigung fehlt
157
complete
Intranet-Zugang reicht für Pentester oder externe IP-Adressen?
158
complete
Zieltermin für die Umgebung und Freischaltungen ist vor 15.12 (als Plan B 1. Jnauar woche)
- Sean: App-Mesh kommt voran. BS hat erst ab Februar Ressourcen um das zu testen.
- Martin/Konstantin: welche Anforderungen gibt es für unsere Systeme über die Weihnachtsfeiertage?
-  kein Abschalten von Umgebungen nötig
- CNP macht kein "Projekturlaub"
- Natalia: Status des Umzugs der unteren Stages auf CNP?
- Martin: feste Umgebungen wurden umgezogen, Build-Jobs sind in Arbeit, dynamische Umgebungen sind noch zu tun, DNS siehe unten
- Frist ist 31.1.22
- Konstantin: Teilnahme des neuen Systemteams an PI-Refinements und Plannings. PI Planning 8-9.12
- Kern-Systemteam nimmt am PI Planning als eigenes Team teil (insb. nicht als Teil von Team Zero). Für andere Teams auf Zuruf. Keine durchgehende Break-Out Session. 
- Ziel: Dependencies zu anderen Teams und Objectives formulieren.
- Neues Jira Projekt benötigt "O2C | Systemteam" (Alternativ: Ausgliederung des Feature-Teams).
- Eine Mail an Holger und Bernd
159
complete
: Mail verfassen
- Martin: wir haben (mal wieder) Beratungsbedarf zu GitLab-Runnern.
Wir haben aktuell kein konfigurierbares Helm-Template für unsere GitLab-Runner in den EKS-Clustern, das heißt wir müssen jetzt auf jeden Fall Arbeit in einen Helm-Chart investieren, die Frage ist in welche Richtung?
- aktuell: wir benutzen eine veraltete Kopie des IPF-Setups. Wird von IFP/MoQ-AP nicht unterstützt, ist damit praktisch ein Bestellsystem-eigenes Projekte und unsinnig fortzuführen.
- pro: -
- con: Insellösung, wollen wir nicht dauerhaft selbst weiter entwickeln.
- CDaaS: die hatte uns ihren Agent mit Helm-Chart empfohlen, leider können wir Labels und Ressources nicht konfigurieren und müssten da Merge Requests öffnen
- pro: potentieller Support und Integration mit pipeship (sops/CICRED)
- con: CDaaS fokussiert die Entwicklung auf DBCS, wir wissen nicht ob sie unsere Merge Requests überhaupt akzeptieren
- GitLab Community Chart: das wird inzwischen von MoQ-AP empfohlen
- pro: sehr generisch, für alle Use-Cases passend
- con: sehr generisch, ohne "DB-Vorkonfigurations-Layer" haben wir vieles selbst einzustellen
- unklar: Setup ohne CDaaS (=weniger Kosten und theoretisch weniger Support, den wir noch nie nutzen konnten)
- Zusammensetzen mit IFP (Andreas Leicher) und ELBA (Jochen  Bachmann)
160
complete
organisiert einen Termin mit Martin =>s. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-43
- Martin: wir stellen den Feature Request external-dns als DNS-Controller laufen zu lassen.
Je mehr wir mit unseren EKS-Clustern arbeiten desto mehr sehen wir dass eine DNS-Verwaltung per CNP-API nicht praktikabel ist. – Wir können kein einziges Helm-Chart einfach nachnutzen, sondern müssen dafür jede einzelne CI-Pipeline erweitern, um mit eigenen Skripten in verschiedenen Clustern zu arbeiten. Das ist bei uns viel Aufwand, viel busywork, und komplett ohne Wertschöpfung.
Das bisherige Setup war alles ein netter Proof-of-Concept, aber es kann nicht so bleiben.
- Konstantin: BS hat vor es auszuprobieren das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-49
- Sean/Natalia: diskutieren das innerhalb von CNP. => Wiedervorlage und konkrete Planung am 7.12 
## Termin 15.11.2021 (Ersatztermin für 9.11)
Teilnehmer: Sean, Martin, Annette, Diego, Konstantin, Bing
- Aktuelles
- Sean: CNP macht ggfls. ab 15.12 bis Jahresende Projekturlaub
- Martin: wir haben am 18.11. einen großen Demo-Termin. Gehen wir davon aus dass wir den auf CNP zeigen können und alles stabil ist (DNS, Loadbalancer, Monitoring), oder sollten wir dafür lieber eine DBCS-Installation vorbereiten?
- Sean: Probleme mit RDS-Secretes liegen an den Namespaces (sie werden nativ in Crossplane angelegt und sind für CNP-API-Nutzer nicht sichtbar). Die Lösung kommt, wenn Datenbanken über die CNP-API angelegt werden.
141
complete
Martin: Es gab Probleme bei Anlage von Datenbanken über CNP API. Fehlersuche zusammen mit Sean geplant.
- Martin: gibt es schon einen Workflow um neue Entwickler einzutragen?
- neue Accountnamen im Bestellsystem sind: emmanuelkontcheutagn, norbertmaurer, aleksandrkil
- die bitte in die OIDC-Listen für bestellsystem-dev und bestellsystem-evu-test eintragen (das liegt nicht im Git-Repo bestellsystem-ops, oder?)
- das gleiche dann in Grafana. – Da benutze ich bisher schon meine Admin-Rechte um zusätzliche Nutzer in die Dashboard-Ordner"bestellsystem" und "bestellsystem-testing" einzutragen. Bei Gelegenheit könnten wir die Listen benutzen um die Benutzer-Gruppe "bestellsystem" zu aktualisieren.
- Das Vorgehen für neue Benutzer sollte dokumentiert werden.
142
incomplete
: generisch für CNP
143
complete
: im Entwicklerhandbuch
- Konstantin: Pentest fürs Portal findet am 24-28.1.2022 statt (durchgeführt vom TÜV), Kickoff entweder im Dezember oder Anfang/Mitte Januar. Todos bis dahin (vgl. auch das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-7)  
144
complete
bedingte Freischaltung fürs Intranet und ausgewählte Pentester-IPs (direkt SecApps anschreiben, CNP in CC), möglichst vor Ende November.
145
complete
Keycloak-Setup vervollständigen
- Konstantin: Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation)
146
complete
Status intern bei CNP erfragen
- Martin/Konstantin: restliche (auch dynamische in der Pipeline generierte) Umgebungen müssen von DBCS auf CNP umgezogen werden. Die Deadline ist 31.1.22, danach erlischt der Support für die von uns genutzten DBCS-Cluster.
147
complete
: Blocker bzw. größere Todos sind CNP transparent zu machen.
- Natalia: ist eine Migration auf DBCS v2 geplant? Nein, (siehe auch Punkt 6) das Bestellsystem plant direkt auf CNP zu gehen.
- Martin: gibt es dokumentierte StorageClasses für PersistentVolumes?
Übergangsweise (solange wir das RDS-Setup nicht in der CI-Pipeline haben) werden wir PostgreSQL-Instanzen im Cluster starten und möglicherweise möchten wir für einige persistenten Speicher aktvieren.
148
incomplete
: EBS kann bereitgestellt werden.
149
complete
: prüfen, ob (und wann) wir von eigenen PostgreSQL Instanzen auf RDS wechseln (insb. wegen Secrets und Performance).
- Martin: Dauer zur Bereitstellung von DNS-Einträgen
- wir haben den Eindruck dass DNS-Einträge (nach Anlegen per CNP-API) innerhalb des EKS-Clusters (bzw. AWS-Accounts) relativ schnell verfügbar sind,
- beim Entwickler-Zugriff per VPN (Nameserver 10.174.0.8 und 10.174.0.40) dauert es dann sehr lange bis der Name aufgelöst und eine URL abgefragt werden kann
- lässt sich das Antwortverhalten für Benutzer verbessern?
- so wie es jetzt ist wird es schwierig unsere Build- und Test-Pipelines zu benutzen
- Natalia: die CNP-API wird am Donnerstag (18.11 um 12:30) vorgestellt.
- Wann wird eine API-Dokumentation bereitgestellt?
150
complete
: prüft, wann eine API-Doku bereitgestellt werden kann.
bahn/project-audit/data/confluence-export/pages/133399373_Kombinierte Roadmap.md
+275
View File
@@ -0,0 +1,275 @@
# Kombinierte Roadmap
> Confluence Page ID: 133399373
> Version: 441
> Pfad: /pathOS/Roadmap Bestellsystem/Kombinierte Roadmap
> Labels:
---
Neue Roadmap im iObeya
Ab 01.08.2023: Die kombinierte Roadmap wird in iObeya weitergeführt. Hinweise und Erklärvideos zur Nutzung von iObeya finden sich u.a. in der ariJa Wissensdatenbank.
VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! VERALTET! Bitte in iObeya nachschauen! 
Die Roadmap dient der mittelfristigen Planbarkeit, sodass man einen Überblick über zukünftig umzusetzende Funktionalitäten erhalten kann. Sie ist ein lebendes Dokument und wird fortlaufend erneuert. An dieser Stelle wird der aktuelle Stand hinterlegt. 
| | Lieferartefakte BS aus
TTT-Roadmap |
| NP1_2 | BP_2 |
NP1_3
BP_3
AK_1 |
NP2_1
NP2_2
AK_2 |
|
|
|
| Produktion? |
|
|
|
|
|
| | PI/Quartal | 26 - Q4/2022 | 27 - Q1/2023 | 28 - Q2/2023 | 29 - Q3/2023 | 30 - Q4/2023 | 31 - Q1/2024 | 32 - Q2/2024 | 33 - Q3/2024 | 34 -  Q4/2024 | 35- Q1/2025 | 36 | 37 | 38 | später |
|
| |
404 |
- Portalunterstützung für Vertragsänderungendas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-188
- PI 26 Portalverbesserungendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-210
- Last- und Performance-Tests (LuP) für Portal -weitere Abdeckung das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-171
- Anzeige von Nicht-Konstruierbarkeiten
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-142 
- Testbarkeit Netzfahrplan (Manipulation des Eingangszeitpunkts in PM) O2C404-1173
- Unterstützung für Änderungsbestellungen nach Vertragsschlussdas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-335 |
- VNP und ENP im Portal anzeigen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-365
- EVU am Zuglaufpunkt festlegen (z.B. durchführendes EVU)  das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-295
- Anbindung Rabattnummernservice (API NVN-Tool) 
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-78
- Portalverbesserungen
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-367 |
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-485
- Changelogs und Releaseprozess konzipieren das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-25
- Anzeige fachlicher Fehlermeldungen im Portal
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-476
- Unterstützung Stornierung in Portal und Middleware das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-332
- Nutzung von Spring Boot 3.0.X das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-432
- Schutz durch Web Application Firewall begleitendas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-496
- Erstellung Tooltipp-Hilfe für den externen Benutzer
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-472
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-491
- Portalverbesserungen PI28das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-473
- Einstiegsseite - Willkommen im neuen Portal - Dashboarddas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-477
- Tracing mit CNP Integrierendas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-442 |
- PMW: Umsetzung einer Paginierung für abgerufene Aufträge
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-273
- Portalverbesserungen PI29 das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-570
- Erstellung Tooltipp-Hilfe-Modus für den externen Benutzer das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-580
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-597
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-220
- Anbindung Änderungsprozesse das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-298
- Unterstützung für Änderungsbestellungen nach Vertragsschluss
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-335
- Anmeldung von Trassen mit multiplen Anteilen im Plannetz DB Netz (Multi PRM Anmeldung)
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-482
- BS: Umstieg von TMT auf Xray das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-619 |
- Unterstützung für Änderungsbestellungen nach Vertragsschluss das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-646
- Tastaturbedienung  das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-571
- Portalverbesserungendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-645
- Daten aus TPN importierendas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-647
- Umzug der BBZ Schnittstelle vorbereiten das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-648
- Stammdaten-Suche erfolgt über die Stammdaten-Bereitstellung das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-127
- Anmeldung von Trassen mit multiplen Anteilen im Plannetz DB Netz (Multi PRM Anmeldung)
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-482
- Arbeiten mit Verträgen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-140 |
- Netzausgelöste Ablehnung nach Fristablauf zur Angebotsannahme das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-296
- Netzausgelöste Änderungendas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-589
- das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-294
- Umgang mit Case Reference  das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-290
- Arbeiten mit Vorlagen (Nicht  Entwurfe)  das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-591
- Kontaktinformationen im Portal vorbefüllen
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-92 |
|
|
|
|
|
|
|
- Anbindung Kundenportal (SSO, Login)
- Wann können wir mit mehreren CompanyCodes im Portal rechnen? 
- 2te Nfpl Phase
3-Tg. Schreiben
- Fristenberechnung im Gelegenheitsverkehr und Netzfahrplan 
- Kartendarstellung - Anbindung an Trassenfinder (15 PT an Einfachbahn)
- Vorgangs-Detailansicht anpassen (Datenexport Detail, Status im Prozess grafisch anzeigen/nicht anzeigen?.)
- Eintritt Dritter in einen Vertrag (§22 ERegG) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-608
- Rahmenvertragsanmeldungen komplett- Eingabe einer Anmeldung zum Kapazitätsrahmenvertrag das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-138
- Rahmenvertragsanmeldungen Änderungsprozesse
- Zugriff Vertragszustände  C&R - Synchron-  (keine Aktionen von ZB im BPortal möglich)
- O2C-590 Bedienhilfe das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-590
-  Willkommen- Kategorie: Wie finde ich mich im neuen Portal zurecht das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-609 |
- Nicht im Scope: es wird nicht mehr benötigt. Anbindung des OTN Generators (Vergabe und/oder Belegung einer Zugnummer)das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-579 |
| |
CIB |
- Prozess Vertragsschluss Netzfahrplan (ENP) umsetzen
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-91
- BEP-Anbindungdas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-271
- Anbindung Produktionsauftrags-SST 0.12.0
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-64
-
E2E-Tests (inkl. Umsysteme) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-195 |
- Rahmenvertragsanmeldungen komplett
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-66
- Unhappy Path IFP-SSTs
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-324 |
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-485
- Abruf von Preisinformationen aus AC Trasse
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-8
- Changelogs und Releaseprozess konzipieren das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-25
- DevOps Workshop - Folgetermin Team CIB das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-487
- Nutzung von Spring Boot 3.0.X das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-432
- Unhappy Path IFP-SSTs
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-324
- Verarbeiten von Fehlermessages
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-497
- Stornierungen von Trassenverträgen (EVU-seitig)
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-330
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-491
- Fertigstellen der IFP-Schnittstellen
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-42 |
- Änderungsbestellungen (EVU-seitig)das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-272
- Umsetzung noch offener Validierungen in SV  das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-576
- Verbesserung BEPdas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-596
- das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-597
- BS: Umstieg von TMT auf Xray das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-619 |
- Zweite Anmeldephase Netzfahrplan das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-282
- PoC Produktions- und Vertriebsauftrags-SST in Kafka
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-643
- Fristüberwachung (zu klären, ob Umsetzung in Teilprozessen oder als übergreifender Prozess) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-286
- Unhappy Path (Reaktion auf Error Messages durch EVU, unvollständige Änderungsbestellungen) (ZU KONKRETISIEREN) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-285
- Fehlende Vertriebsaufträge das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-498
- Verarbeiten von ErrorMessages von EVU
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-499 |
- Netzausgelöste Änderung das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-283
- Prozesstransfer in nachgelagerte Prozessphase bei Eingang nicht fristgemäßer Änderungsbestellung [
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-481
- 3-Tages-Schreiben im Netzfahrplan |
- Route Update Prozessdas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-287  |
|
|
|
|
|
|
- Kommunikation mit Nachbar-EIU das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-288
- Referenzierung auf Rahmenverträge im Netzfahrplan
- Validierung 1:n zwischen ReferenceTrain und Route das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-291
- CaseReference KundenObjekte abrufen und speichern das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-290
- QoL für Betriebsführung und Support das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-310
- Unhappy Path (Reaktion auf Error Messages durch EVU, unvollständige Änderungsbestellungen) (ZU KONKRETISIEREN)
- Umsetzung erster Systemintegrationstests mit IFPdas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-377 |
|
| |
Zero |
- Versionsanhebung CI das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-297
- Austausch einfacher Nachrichten mit PCS das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-193 |
- Nutzung von Spring Boot 3.0.X das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-432
- Tracing-Informationen in Grafana initial bereitstellen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-169 |
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-485
- Changelogs und Releaseprozess konzipieren das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-25
- Tracing-Informationen in die Anwendungen integrieren
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-431
- Finales Aufbereiten der Stammdatendas I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-534
- LuP (PushGateway nutzen) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-343
- S-Bahn Berlin (Durchstich)
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-316
- Anbindung BI-Systeme
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-154
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-491
- Support
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-549 |
- Kundendatenvalidierung fertigstellen
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-65
- ObjectInfoMessages 
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-638
- Tracing
- Anbindung Bestellsystem an Abrechnung das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-284
- das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-597
- LuP (PushGateway nutzen) das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-343
- BS: Umstieg von TMT auf Xray das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-619
- Support
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-621 |
- S-Bahn Berlin (Durchstich)
das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-316 |
|
|
|
|
|
|
|
|
- Vorjahresdaten importieren
- Anbindung Click&Ride |
|
| | STeam
|
|
|
- PEN-Test E2E-Umgebung (Jun/Jul 2023) vorbereiten das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-485
- Vorgaben zu Patch- und Schwachstellenmanagement umsetzen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-18
- Changelogs und Releaseprozess konzipieren das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-25
- Security Scans installieren/aktualisieren das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-489
- Verschlüsselung interner Schnittstellen in IEW und EVU vertesten das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-486
- Prototyp Dashboard "Wie gehts dem Bestellsystem"
das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-491
- Tracing-Informationen in Grafana initial bereitstellen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-169
- CI/CD-Verbesserungen das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-488 |
- BS: Umstieg von TMT auf Xray das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-619 |
|
|
|
|
|
|
|
|
|
|
|
| |
Teamzuordnung offen |
|
Anbindung des Konstruktionssystems für EVU-Tests das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-366  
ART-übergreifende E2E-Tests das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C-375
Staging einführen   das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-136
- Tracing das I.NVI IT Lifecycle Management Toolissuekey,summary,issuetype,created,updated,duedate,assignee,reporter,priority,status,resolutionkey,summary,type,created,updated,due,assignee,reporter,priority,status,resolutiond1143f0d-33c0-3f1c-b44b-7720150f306eO2C-169 |
| Stabilisierung der Systeme mit C2S |
|
|
|
|
|
|
|
|
| Abnahmetests |
|
bahn/project-audit/data/confluence-export/pages/160729047_Archiv Achitekturrunde.md
+1994
View File
File diff suppressed because it is too large Load Diff
bahn/project-audit/data/confluence-export/pages/161972468_Archiv CNP JF.md
+880
View File
@@ -0,0 +1,880 @@
# Archiv CNP JF
> Confluence Page ID: 161972468
> Version: 2
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Abstimmungen mit Cloud Native Platform (CNP)/Archiv CNP JF
> Labels:
---
## Termin 26.10.2021
Teilnehmen: Annette, Bing, Bishara, Diego, Konstantin, Sean, Martin
- Aktuelles:
- Portal in EVU-Test: Pen-Test noch ohne Termin. Der früheste mögliche Termin ist derzeit Anfang Januar. Ein Anbieter steht allerdings noch aus. Je nach Ergebnis müssen wir eine Verschiebung oder eine bedingte Freischaltung vor dem Pentest prüfen.
- Kurzer Review der Punkte vom 12.10.
- Konstantin: Tracking von Bugs und Zulieferungen könnte künftig über Jira erfolgen, sobald beide (Bestellsystem und CNP) auf das neue NVI-Jira migriert sind.
→ im Prinzip haben wir jetzt gegenseitig JIRA-Zugriff zwischen CNP und Bestellsystem
- Umsetzung Container-Vorgaben
- welche Frist gilt für das Bestellsystem: 1.1.2022
- Wie ist die Arbeitsteilung zwischen CNP und ARTs?
- aktuell größte Lücke: privilegierte Container für Kaniko notwendig
- Gibt es bei CNP schon einen Plan damit umzugehen?
- Vorschlag/Planung Bestellsystem: ein eigener Namespace für Kaniko, und nur in diesem Namespace privilegierte Container zulassen. – damit können wir dann alle nicht-Build-Umgebungen absichern.
- Martin: Ich habe neue Namespaces im Cluster bestellsystem-dev erstellt
- Als Kürzel habe ich bsz  benutzt (angelehnt an den Projektnamen in Beam),
- Kann bei Gelegenheit jemand bestätigen dass das Erstellen mit kubectl hnc create  so richtig war?
-
Ziel ist später nur noch in bsz-kaniko "privilegierte" Container zu benötigen (mangels besserer Container-Build-Lösung)
-
neue Namespace-Liste zur Info:
- mit den neuen Namspaces haben wir auch begonnen zusätzliche Anwendungs-Installationen in bestellsystem-dev zu starten. Aktuell unsere 'vertriebsdemo', danach folgt 'IEU'.
- Frage dazu: hilft es wenn wir in bestellsystem-ops die SubnamespaceAnchor Objekte einpflegen?
→ Ja, sollte per MR eingetragen werden.
- Martin: Ingress Controller in bestellsystem-evu-test
Der ALB-Ingress-Controller funktioniert in bestellsystem-dev gut und löst unsere offenen Probleme (HTTP-Header, Cluster-Erreichbarkeit, Portnummern im Hostnamen). Jetzt müssen wir auch bestellsystem-evu-test aktualisieren.
→ Sean und Martin aktualisieren evu-test am Donnerstag
- Martin: wenn ich jetzt mehr Anwendungs-Installationen starte, dann brauche ich ein paar Monitoring-Daten von der RDS-Instanz um zu bemerken wenn wir die überlasten. (In Grafana finde ich nur eine Kombau-RDS, nicht unsere bestellsystem-dev).
- Martin: aktuell haben wir Probleme mit DNS-Einträgen per CNP-API. → Bei Sean bereits angefragt und in Arbeit.
## Termin 12.10.2021
## Hinweis: Konstantin und Martin sind im Urlaub
Teilnehmen: Natalia, Annette, Bing, Bishara, Frank, Diego
- Aktuelles:
- Aktuelle Ingress-Probleme sind gelöst. 
- Die Umstellung des Endpoints notwendig (Sean geht auf Diego zu)
- Probleme mit der Testumgebung: IP-Adressen-Problem ist gelöst
- Änderung des DNS-/Route53-Setups in Arbeit, das 63-Zeichen-Limit ist gelöst
- Martin: Nachfrage zu Secrets:→ kein Update
- Martin: Nachfrage zu Git-Secrets→ kein Update
- Bishara/Martin: MasterData Proxy-Eintrag-->E-Mail via Natalia an Ops-Team
- Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation)→kein Update.
- Ist jetzt als Service angeboten, wird mit IDBF vertestet
- Ziel: zum Jahresende für das Bestellsystem zum Testen bereitstellen
- Überblick über den Rest des Themenspeichers.
- Monitoring: in Entwicklung→ kein Update
- Pen-Test-Termin→ Vertrag ist da, Termine sollen vereinbart werden, Kick-Off-Termin soll organisert werden (Annete)
- SIEM-Anbindung:
- OS-Ebene: keine ToDo's 
- App-Ebene: ab 2022 notwendig, Abstimmung mit SCIRT
- Migration von Build- und Dev-Umgebungen von DBCS auf CNP
- Dynamische DNS-Einträge und Ingress-Controller.
- Verhalten der Cluster unter Last: Fargate vs. Cluster-Autoscaling (erstmal time-based)→ Anforderungen an Umgebungen sollen spezifiziert werden (BE→Bing, FE→Diego, Annete))
- (weitgehender) Verzicht auf priviligierte Container erfordert eigenes Anlegen von Namespaces (Martin hat Rechte zum Anlegen der Subnamespaces).
- Konfiguration von OPA (Spezifizieren, was damit gemeint ist). → das heißt zum Beispiel Verhindern von privilegierten Containern außerhalb des Kaniko-Namespaces.
## Termin 28.09.2021
Teilnehmen: Natalia, Annette, Bing, Bishara, Edmond, Konstantin, Martin
- Aktuelles:
- Aktuelle Ingress-Probleme: mit Hannes (als Seans Vertretung) halb in Arbeit
- künftige Termine/Zusammenarbeit. CNP & Projekt Dailies geplant.
- Änderung des DNS-/Route53-Setups in Arbeit, das 63-Zeichen-Limit könnte wieder obsolet sein.
- Übersicht aktuelle Tickets, die im Bestellsystem als externe Abhängigkeit Dinge blockieren
- Martin: Nachfrage zu Secrets:
- Können wir bitte irgendwo dokumentieren wie Secrets gespeichert werden müssen, um den DB-Vorgaben zu entsprechen?
- Bisher schreiben wir unsere Secrets nur in die K8s-API, unter der Annahme dass das reicht, also dass die Daten dann nicht im K8s-etcd, sondern im AWS-SecretsManager gespeichert werden.
- Unter  wird zusätzlich ein Secrets Claim per CNP-API beschrieben. Brauchen wir sowas auch, oder ist das schon automatisiert?
- muss nochmal genauer besprochen werden → Folgeticket oder -Termin
- Martin: Nachfrage zu Git-Secrets
- Bei der Beschäftigung mit der pipeship-Implementierung für Secrets in Git-Repositories (mit PGP als Backend) sind uns Probleme aufgefallen.
- Als Alternative wird ein AWS KMS-Schlüssel vorgeschlagen, das erscheint mir schwierig ohne AWS-Credentials für alle Entwickler.
- Gibt es von CNP eine empfohlene Lösung, wie wir verschlüsselte Daten in Git an eine Laufzeitumgebung koppeln können?
- muss nochmal genauer besprochen werden → Folgeticket oder -Termin
- Bishara/Martin: Wir brauchen nochmal ein MasterData-Update (Proxy-Freigabe), wer kann uns das eintragen?
- wir wollen von Anwendung "bestellsystem-commoninterface-test.dbnetze.com" aus zugreifen auf Hostnamen "commoninterface-dev.cos-test.comp.db.de"
- → E-Mail via Natalia an Ops-Team
- Status Service-Mesh (Blocker für die Verschlüsselung und Zugriffskontrolle der internen Kommunikation).
- Ist jetzt als Service angeboten, wird mit IDBF vertestet
- Ziel: zum Jahresende für das Bestellsystem zum Testen bereitstellen
- Überblick über den Rest des Themenspeichers.
- Monitoring: in Entwicklung, braucht nochmal ein Update
- DNS-Namen für das Portal in EVU-Test sind bestätigt
- Pen-Test-Termin weiter offen (?)
## Termin 14.09.2021
## Teilnehmer: Natalia, Sean, Martin, Bishara, Diego, Konstantin
- Todos aus alten Terminen durchgehen
- Nächste Schritte bzgl. X-Forward-Proto
128
complete
: versucht den Header im LB zu setzen (Infos zum Nachstellen des Fehlers siehe das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-2), siehe auch das CNP-Ticket
- Vorgehen zum Tracken von Bugs
- Bestellsystem tracket externe Abhängigkeit im neuen Jira
- CNP plant ebenfalls auf das gleiche Jira umzusteigen: künftig kann Jira-intern verlinkt werden.
- Natalia: die Einhaltung der Container-Richtlinien wurden für die DB-netz bis zum 1.1.2022 ausgesetzt. CNP arbeitet aktuell die Plattform-Vorgaben durch.
- Martin erstellt gerade eine Todo-Liste, das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-53
- Größte Baustelle ist Patch- und Schwachstellenmanagement (eingeplant für Q4).
- Logging-Forwarding Richtung SIEM muss noch geklärt und eingeplant werden (komplex, aktuell bei IDBF in Besprechung).
129
complete
soll für 2022 eingeplant werden. => das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-158
- Konstantin: zur Info: wir suchen derzeit Termine für Bedrohungsanalyse+Pentest Portal für Q4
- Dynamische DNS-Einträge: Namensstruktur muss sich ändern.
130
complete
: gibt Sean Bescheid (voraussichtlich ab 17.9). => neue Namen festgelegt, durch PI-Planning leider erst spät umgesetzt
- Zentraler Identity Provider
- Diskussionen mit Jan-Sören Papp laufen aktuell.
## Termin 31.08.2021
Teilnehmer: Bernd, Sean, Martin, Bishara, Diego
- Sean: Probleme mit HTTP-Header X-Forward-Proto sollten spätestens bis 10.8 behoben sein. → Blocked by https://github.com/kubernetes/cloud-provider-aws/issues/234#issuecomment-885789048
- Martin: Zugang zur CNP-API bekommen, technischer User fehlt noch.  Zugang zur CNP-API wird prinzipiell für alle Entwickler benötigt (erstmal reichen Martin, Bing, Diego, Bishara). Die API-Doku ist bisher nur als FAQ verfügbar.
123
complete
 : TechUser und Freischaltungen bis 1.9
- Martin: Monitoring ist wieder in Bestellsystem-Dev ausgefallen.
- Sean: CNP hat einen neuen Monitoring-Experten (Hannes Blut). Die Kommunikation läuft aber erstmal weiter über Sean bzw. den CNP/Bestellsystem Teams-Kanal.
- Umstieg auf Aurora. Hier steht noch Aurora v1 (ginge sofort) oder v2 zur Auswahl (ist noch nicht von AWS freigegeben).
124
complete
: schickt eine kurze Info an Martin zu Aurora v1 (v1 reicht erstmal).
## Termin 24.08.2021
Teilnehmer: Sean, Harald, Martin, Bing, Konstantin
- Sean: Beim Monitoring sind größere Setup-Änderungen inkl. Zugriffsrechte bis 13.September geplant.
- Dann sollten auch Anpassungen der Dashboard durch Projekte möglich sein.
- Sean: Ingress Controller sollten bis ca. 27.8 zum Testen bereit stehen.
- EVU-Test bzw. Portal im Internet: Nach der SOAP-Schnittstelle wollen wir auch unser Web-Portal für Test-Partner (und dazu Keycloak) im Internet publizieren. Erster Merge-Request für DNS-Namen ist angelegt, die weiteren Schritte (Pen-Test, ISGW, folgen später).
- Martin: Merge-Request vorbereitet. Installation der Portal-UI, MW und Keycloak in der evu-test-umgebung laufen.
112
complete
: Ausrollen der Änderungen aus dem Merge-Request.
- Sean: Absicherung der Keycloak-Masken und f5-Konfiguration sollten mit Secure-Access-Services. Im Rahmen der ISGW-Vorgespräche.
113
complete
: ISGW-Team anschreiben und Anforderungen klären.
- Konstantin: Planung der Penetrationstest. Bestellsystem geht direkt auf NVI6 zu (Natalia/Harald/Sean in CC).
114
complete
: NVI6 (Florian) anschreiben und Termine abstimmen.
- Martin: brauchen wir einen anderen LB fürs Portal? Annahme: nein, die Unterscheidung nur im ISGW.
- Netzwerk-Problem von EKS-Cluster zu ELB/Envoy→ siehe Termin 27.07.2021, Punkt 5
115
incomplete
schaut sich das an. Analysen haben bisher nichts ergeben. Die E-Mail-Kommunikation an Martin+Konstantin weiterleiten. das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eOO-3
- FYI, Nach ersten Erfahrungen mit SQS wollen wir unser Setup vereinfachen. Dazu verzichten wir künftig auf die dead-letter-queues und wahrscheinlich auch auf die FiFo-Queues (erfordert noch Absprache). → Erster Merge Request zum Hinzufügen der neuen Queues.
- Künftige Termine: Im Bestellsystem haben wir jetzt einen 3-Wochen-Sprint. Um Kollision mit unseren Sprint-Terminen zu vermeiden würden wir alle folgenden Termine gerne um eine Woche verschieben, also nächste Abstimmungstermine am 31.8., 14.9. usw.
116
complete
: verschiebt die nächsten Termine um eine Woche vor.
- CNP-API für Self-Service.
117
complete
gibt Martin Zugriff auf die API zum Ausprobieren.
- Jetzt mit mehr Entwickler-Zugriff auf EKS wünschen wir uns ein Benutzer-Dashboard, könnt Ihr das was empfehlen?
Wir können vermutlich selbst K8s-Dashboard oder k8dash starten...; aber bei der korrekten Konfiguration und einer OIDC-Anbindung (am besten an GitLab) würden wir lieber eine bestehende Vorlage nehmen anstatt alles selbst zu bauen und zu debuggen.
- Sean: lens (wird aktuell beim Bestellsystem verprobt).
- Martin: Session-Timeouts sind bei kubectl extrem kurz.
118
complete
: prüft, ob ein Hochsetzen möglich ist.
## Termin 10.08.2021
- Service Mesh oder Ingress Controller: gibt es Neuigkeiten?
- Service Mesh wird von neuem Kollegen implementiert, noch keine Termine
- OIDC/Identity Provider: gibt es Neuigkeiten?
- weiter in Arbeit, noch keine Termine
- BBZ-API-Erreichbarkeit: gibt es Neuigkeiten?
104
complete
untersucht das weiter
- Pentest-Maßnahmen: gibt es Neuigkeiten?
- TLS-Cipherliste am Loadbalancer
- Zugriffsbeschränkung auf ISGW
- HTTP-API-Pfade → ist in Envoy konfiguriert 
## Termin 27.07.2021
- Pentest-Maßnahmen seitens CNP prüfen
- Nur ISGW soll auf Cluster-LB zugreifen dürfen (siehe ISGW-Doku für Port-Ranges)
Nachtrag: einfacher Test mit Kommando curl -v https://evu-test-common-interface-bestellsystem-evu-test.cnp.comp.db.de/LIServices/LIHBMessage
- TLS-Konfiguration in Cluster-LB härten => durch den oberen Punkt ist das vermutlich weniger kritisch, sollte außerdem ein allgemeines Thema für den LB sein.
- Nur ausgewählte Pfade am LB durchlassen:
-
Das sollten "/LIServices/*", "/LIMessageProcessing/*" sein (mit Entwicklern gegenprüfen)
- Merge Request: https://git.tech.rz.db.de/cnp/bestellsystem/bestellsystem-ops/-/merge_requests/27
- Netzwerk-Probleme zu .eip.comp.db.de
- wir benutzen eine API zur BenutzerBerechtigungsZuordnung (BBZ) unter https://awseip2iapigw103.eip.comp.db.de:5556/
- Der Proxy webproxy.comp.db.de erlaubt keine Verbindungen dorthin,
- Ohne Proxy bekommen wir keine Verbindung, nur einen Timeout (aus bestellsystem-dev und bestellsystem-evu-test)
- ==> weitergegeben an Ops
- dynamische DNS-Einträge: recht dringend, CNP arbeitet an einem Fallback (für Verfahren ohne Mesh) => siehe 13.07 => wartet auf CNP PI Planning
- Schwachstellenmanagement (vgl. hier). Gibt es hier schon beispielhafte Prozesse in den anderen Projekten?
- aktuell leben wir das bereits für Bibliotheken (Whitesource) sowie SonarQube-Findings
- Fortify ist in Arbeit
- Umgang mit Container-images ist schwieriger wegen der Abhängigkeiten
- ==> es folgt ein CNP-Termin zum einheitlichen Umgang mit Security-Scannern und -Meldungen
- ==> Wiedervorlage im September?
- mögliche Netzwerk-Problem von EKS-Cluster zu ELB/Envoy?
- Verbindungen von DBCS/VPN an unsere Loadbalancer-URLs (z.Bsp. https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/history/heartbeat) funktionieren, ebenso Verbindungen aus dem jeweils anderen Cluster (bestellsystem-dev oder bestellsystem-evu-test).
- Verbindungen aus dem jeweils eigenen Cluster sind oft fehlerhaft und bekommen einen Fehler curl: (52) Empty reply from server , also
- von bestellsystem-dev Request an https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/history/heartbeat
- von bestellsystem-evu-test Request an https://evu-test-common-interface-bestellsystem-evu-test.cnp.comp.db.de/history/heartbeat
-
Nachtrag, 25.8.: in bestellsystem-evu-test haben wir jetzt einen festen Pod-Namen, da kann ich eine Kommandozeile zum Reproduzieren angeben:
120
complete
mit Bitte um Fehlersuche im Envoy oder im AWS-Setup
- Wir sehen immer wieder Probleme beim Starten von GitLab-Build-Pods in bestellsystem-dev.
- DNS-Namensschema
- Aktueller Stand Bestellsystem: wir vergeben für statische Deployments DNS-Namen nach Schema "<anwendungsumgebung>-<servicename>-<namespace>.cnp.comp.db.de" (z.Bsp. https://cnp-common-interface-bestellsystem-fargate.cnp.comp.db.de/)
- Wir benutzen (künftig) auch pipeship für die CI-Pipeline, das vergibt temporäre Deploymentnamen aus Projekt- und Branch-Name (z.Bsp. `common-interface-review-build-pipe-13ekrh`) ==> damit wird es auch viele "unstrukturierte" Namen geben.
- Wir verstehen den Wunsch noch das EKS-Cluster einzucodieren, aber zumindest in den temporären Build-/Test-Installationen bleibt uns praktisch kein Platz dafür. – Ist das wirklich notwendig, oder finden wir andere Wege dafür (vielleicht ein weiteres Element im Domain-Part, oder eine K8s-Annotation)?
- ==> wird bei CNP weiter besprochen und refined
## Termin 16.07.2021 (Sonderthema Monitoring)
- Bedarf an einer Grafana-Instanz mit Schreibrechten für Entwickler.
- Ideen des Bestellsystems sind hier dokumentiert (primär eigene Instanzen basierend auf MaaS).
- Alternativvorschlag CNP: Zugriff auf die "Beta" Instanz des Grafana inkl. Schreibrechte 
93
complete
: Infos zum Beta-Grafana verteilen
- Input der Daten aus DBCS wünschenswert (falls nicht zu kompliziert)
94
complete
, : prüfen zusammen ob Federation über Cortex-Endpoint funktioniert
- Alert-Manager: In Arbeit bei CNP?
- CloudWatch-Metriken für RDS/SQS/S3 in Grafana benötigt (Ein Muss für DevOps)
- Zentrales Monitoring: ist primär ein CNP-Thema, keine unmittelbaren Projekt-Todos.
## Termin 13.07.2021
- Punkte aus den alten Terminen
- Sean: http/2 sollte von AWS/K8s/ISGW unterstützt werden
- Martin: Probleme mit Monitoring
87
complete
: prüft es. Monitoring ist derzeit im Umbau.
- Martin: ADR zu Aurora geschickt. Passt für CNP.
- Aurora RDS ist die aktuelle Lösung.
- Martin: Protokoll-Header X-Forward-Proto via Merge-Request hat noch nicht funktioniert.
88
complete
prüft das
- Natalia: Service-Mesh sollte besser als automatisierte Variante bereitgestellt werden.
- Aktuelles Ziel: Bereitstellung App Mesh bis Mitte August
- Abhängigkeiten
- SSL für inter-service Kommunikation: ist nicht arg dringend
- dynamische DNS-Einträge: recht dringend, CNP arbeitet an einem Fallback (für Verfahren ohne Mesh)
89
complete
Wiedervorlage in 2 Wochen
- Bestellsystem-Entwickler-Zugriff
- Um mehr Wissen in unseren Teams zu verteilen würden wir gerne unseren Entwicklern mehr Zugriff gewähren.
- im Teams-Kanal 'Bestellsystem' möchten wir Bishara Jaser und Frank Fk Thiele hinzufügen,
- im GitLab-Repo 'bestellsystem-ops' würden wir denen auch Lese-Zugriff geben. Entweder der ganzen Gruppe Bestellsystem (falls das nicht "zu offen" ist), oder einzeln den Benutzern Bing Shi, Bishara Jaser und Frank Fk Thiele
- S3 Object Lifecycle
wir benutzen unsere S3-Buckets nur für temporäre Daten, die für SQS zu groß sind. Um die Verwaltung zu vereinfachen sollen die Daten nach bestimmter Zeit (in aktuellen Umgebungen nach 14 Tagen) gelöscht werden. → Merge Request in bestellsystem-ops
- Konstantin: Pentest wurde durchgeführt.
- Spannendste Ergebnisse und nächste Schritte besprechen.
- fachliche Themen
- Header-Handling im ISGW
- Absicherung der Strecke ISGW → ELB
- SecurityGroup/ACL damit nur der ISGW auf ELB zugreifen darf
90
incomplete
einrichten ab 19.07 => danach Prüfung durch Entwickler, dass der interne Zugriff nicht mehr funktioniert.
- prüfen, ob das für die EVU-Test-Umgebung ein Problem ist. Debug-Zugriff auf andere Umgebungen problematisch.
- Annahme: interner Zugriff sollte nur über K8s-Proxy erfolgen. (Alternative wären 2 ELBs)
- Folge-Aktionen
- Bericht wird bis 17.7 erwartet
- Verteilung an: CNP, NVI6 (db.netz.csac@deutschebahn.com)).
- Freigabe durch NVI41
- Plan: ab 1.8 soll EVU-Test extern verfügbar sein.
- Konstantin: Status der Abstimmungen mit eBRS/MyNet/Kundenportal bzgl. der Einführung der SSO/MFA - aktuell nutzen wir als Workaround Keycloak. Falls keine Lösung von eBRS kommt, muss Keycloak (oder Alternative) zum Live-Gang durch das Projekt oder CNP  betrieben werden.
- In Q3/Q4 wäre ein Pen-Test fürs Portal inkl. Keycloak  fällig.
- 2 Freischaltungen notwendig: Portal + Login
- evtl. schon mit der Keycloak-Alternative von CNP (siehe unten)
- Vorlauf
- ISGW ca. 1 Monat
- Natalia: Keycloak braucht einen Support-Vertrag
- Sean: arbeite gerade an einer AuthNAuthZ (A&A)-Lösung (als Alternative u.a. zu Keycloak)
91
complete
: Wiedervorlage in 2 Wochen
92
complete
: schickt Sean Doku und Gitlab-Links zu Keycloak zu: hier
## Termin 29.06.2021
- Diverses
- Aktuelles Thema: gibt es Erfahrungen mit http/2? Unsere Entwickler haben das als Performance-Optimierung fürs Bestellportal identifiziert. Wir befürchten aber, dass dies von Proxies, LBs oder ISGW nicht unterstützt werden könnte.
75
complete
: prüfen, ob das im ELB aktiviert werden kann.
- Wechsel von RDS zu Aurora
- Optionen: Aurora RDS vs. Aurora Serverless
76
complete
: beim nächsten Termin ADR vorstellen
- Stand EVU-Test Umgebung.
- Erledigte Punkte
- Weitere notwendige AWS-Dienste für EVU-Testumgebung bestellsystem-evu-test:  – Anmerkung Martin: ist inzwischen soweit erledigt, oder?
- RDS-Datenbank (kleine Instanz so wie für bestellsystem-dev)
- eigene Diskussion: im AWS-Kontext scheint Aurora der bessere Datenbank-Service zu sein, den würden wir gerne vertesten.
- wir sind uns unsicher ob gerade dies eine gute Test-Umgebung ist, können wir da noch Monitoring für bekommen?
- Meinung von Seite CNP? Habt Ihr Empfehlungen oder Präferenzen?
- aktueller Status? –> laut bestellsystem-ops-Repo ist die RDS-Instanz eingerichtet, aber Martin hat noch kein Login-Passwort
- die SQS-Zugriffsrechte stimmen noch nicht ganz, siehe Merge Request in bestellsystem-ops
- DNS-Namen passen noch nicht, siehe Merge Request in bestellsystem-ops
- Offen
- Protokoll-Header X-Forward-Proto (muss https statt http sein).
77
complete
: konfigurieren in ELB
- Zertifikate für PEN-Tester.
78
complete
 versucht Test-Zertifikate von RNE zu bekommen. Alternativ kann man die eigenen Zertifikate nutzen.
- Roadmap Pipelines auf CNP (Migration von DBCS zu CNP)  – Was wäre noch nötig, um das Bestellsystem im PI21 (~Q3) nach CNP umzuziehen?
- Management-API (kein Blocker fürs Bestellsystem) 
- : Aktuell in Konzeption, PoC in Juli
- separate (dezentrale) Management-APIs für Projekte notwendig. Lieferung bis Ende August möglich.
- Die DNS-Einträge blockieren uns aktuell, weil automatische Tests per HTTPS so nicht funktionieren
- Abhängigkeit zu Service-Mesh. Manuelle Bereitstellung (wie bei IFP) nicht empfohlen
79
complete
 Wiedervorlage in 2 Wochen.
- Workaround mit Cluster-local URLs funktioniert nicht für alle Use Cases (z.B. Cypress)
- Alternative mit Ingress-Controller (ohne Service Mesh)
80
complete
prüft bis 13.7
- API-Zugriff um SQS-Queues anzulegen wäre hilfreich, aber nicht dringend notwendig (damit würden wir gerne localstack ersetzen)
- siehe Management API oben.
- Es wäre gut dafür im Cluster `bestellsystem-dev` neue Namespaces anzulegen (zur Info, in Abstimmung bei Martin und Sean):
- build – dies ist dann der einzige Namespace in dem wir "Container als Root"-Rechte für Kaniko brauchen, sowie Zugriff zum GitLab-S3-Cache
- ieu – unsere pre-prod Installationsumgebung, bräuchte dann SQS/S3 und RDS als Dienste
- Last-/Performance-Test?
- Fargate oder extra-Cluster? Fargate für die initiale LuP Entwicklung ok.
- Keycloak-Betrieb auf CNP: Erfahrungen und Optionen.
- dex statt Keycloak intern in CNP verwendet.
- Siehe IAM-Portal und ADR
- PoC in CNP geplant ab 5.7
- Bestellsystem unterstützt mit Ressourcen (Martin und ein Entwickler/in aus Team 404).
## Termin 22.06.2021
- Anmerkung von : Web-Proxy-Policy webproxy.comp.db.de
- nicht dringend, aber im Rahmen des EVU-Test-Setups aufgefallen: Anscheinend benutzt der Bahn-Web-Proxy verschiedene Policies für DBCS und CNP?
- Test-Anfrage: https_proxy='http://webproxy.comp.db.de:8080' curl -v https://bestellsystem-commoninterface-test.dbnetze.com/history/heartbeat
- lokal per VPN => timeout, ist OK, weder EVU-Test noch Proxy sind allgemein zugänglich
- in DBCS mit webproxy.comp.db.de => HTTP 404 von ISGW, soweit OK, wenn das ISGW-Setup noch nicht fertig ist
- in CNP mit webproxy.comp.db.de => `curl: (56) Received HTTP code 403 from proxy after CONNECT`, mit Header `X-Squid-Error: ERR_ACCESS_DENIED 0`
- im Virtuellen Desktop (VDS) => `curl: (56) Received HTTP code 403 from proxy after CONNECT`, mit Header `X-Squid-Error: ERR_ACCESS_DENIED 0`
- Ist also kein "Problem" mit CNP, sondern eher ein zusätzlicher Zugriff aus DBCS.
- Nachtrag: aus Sicht Bestellsystem wünschen wir uns eine allgemeine Verfügbarkeit im internen Bahn-Netz (besonders auch per VPN und VDS), damit wir selbst einfach testen können
- ISGW funktioniert noch nicht.
- Endpunkt leitet nicht → Aktuell noch ein HTTP 404 → TODO  fragt bei ISGW nach ob der interne Endpunkt aufgelöst werden kann.
-
Custom SSL Zertifikat ist noch nicht gesetzt. → self signed cert → Zu klären ob das i.O. ist. → Erledigtbashaktueller Stand, Request mit RNE-Client-Zertifikattrue CONNECT bestellsystem-commoninterface-test.dbnetze.com:443 HTTP/1.1
> Host: bestellsystem-commoninterface-test.dbnetze.com:443
> User-Agent: curl/7.67.0
> Proxy-Connection: Keep-Alive
>
GET /history/heartbeat HTTP/1.1
> Host: bestellsystem-commoninterface-test.dbnetze.com
> User-Agent: curl/7.67.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
- Vereinbarung war dass im header  X-Client-Cert header mit eingetragen → können wir erst testen wenn die Requests an unsere Services durchkommen
-
offener punkt ist der redirect von https auf http
Nachtrag dazu:
→ Envoy sendet der Anwendung den falschen Header X-Forwarded-Proto: httpHTTP-Request Headertrue
68
complete
können wir das in der Envoy-Config ändern? Als schnellen Fix für den EVU-Test könnten wir den Header immer überschreiben, weil wir von externen Clients nie HTTP-Verbindungen erwarten.
- Wir brauchen eine Lösung für den Container-Image-Build.   nimmt  
Hatten wir im März aufgeschoben, ist jetzt aber notwendig weil Kaniko nur mit root-Rechten im Container funktioniert; das kollidiert mit der OPA-Policy.
- perspektivisch ggf. in seperatem namespace
- Enovy Config wird nach dem PenTest umkonfiguriert, sodass wir explizit routes erlauben, statt zu verweigern. Hierfür werden die routes benötigt.
## Nachtrag, ISGW-Termin 24.06.2021
Ergänze ich hier, weil das thematisch anschließt und einige offenen Fragen klärt.
- HTTPS ist konfiguriert wie von uns angefragt
- RNE-Server-Zertifikat für unsere CN
- Client-Cert-Validierung gegen RNE-CA-Cert 'CA CCS 1'
- Client-Cert-Daten werden base64-kodiert in den HTTP-Header X-Client-Cert eingefügt
- es gab die Frage ob der Header bei jedem Request, oder nur beim ersten Request einer HTTPS/1.1 Session nötig ist. wir haben jetzt um jeden Request gebeten, – da gibt es künftig Optimierungsmöglichkeiten
- Wie die Pen-Tester an Zertifikate kommen ist noch unklar → Kick-off-Termin
- Die interne Erreichbarkeit der externen Domain ist schwierig und erfordert den Web-Proxy http://wwwproxy.tech.rz.db.de:8080
- Zu Policy-Problemen/Fragen mit dem Proxy haben wir Alexander Perleth als Kontakt genannt bekommen.
- weiterer Test: der webproxy.comp.db.de sperrt Zugriffe aus unserem EKS-Containern, aber der Proxy wwwproxy.tech.rz.db.de funktioniert
- sehen wir da noch Handlungsbedarf?
- Der aktuelle Fehler 404 wird durch einen falschen Hostnamen bzw. ein fehlendes Umschreiben des Hostnamen verursacht.
- ISGW setzt auch in den internen Requests den HTTP-Header Host: bestellsystem-commoninterface-test.dbnetze.com
- Der CNP-Envoy bzw. AWS-ELB kennt den Hostnamen nicht und antwortet mit 404
- Korrektur dafür: den Hostnamen im CNP-Envoy einkonfigurieren --> wird von Sean eingetragen und mit Martin getestet
## Termin 15.06.2021
- Pen-Test für EVU-Testumgebung ist bestätigt
Kick-off-Termin (1h, voraussichtlich 28. Juni), Sean wird eingeladen
- EVU-Test
- ISGW ist eingerichtet, interner Ziel-DNS fehlt noch
- Deployment-Diagramm, `bestellsystem-ops`-Repo bei CNP und `bestellsystem-deployment`-repo bei Bestellsystem werden verlinkt
- IFP-SQS-Tests
- aktuell fehlen KMS-Zugriffsrechte → Merge Request in bestellsystem-ops
- Klärung FIFO-/Standard-Queues in SQS und Umgebungen
- Stand Service Mesh?
- wird aktuell mit IFP implementiert,
- für das Bestellsystem erst in Q4 realistisch
- Roadmap Pipelines auf CNP – Das Bestellsystem plant im PI21 (~Q3) nach CNP umzuziehen
- Die DNS-Einträge blockieren uns aktuell, weil automatische Tests per HTTPS so nicht funktionieren
- eigener Namespace für build → Setup so wie in bestellsystem-dev mit EC2 und fargate
- Martin und Sean besprechen das vor der PI-Planung
- Bestellsystem-Testkonzept
- Konzept im Bestellsystem-Confluence
- technische Doku im Bestellsystem-Entwicklungshandbuch
- nach dem EVU-Test werden wir das Web-Portal ins Internet bringen, dafür müssen wir einen Keycloak im Internet betreiben → Folgetermin
## Termin 01.06.2021
- Stand EVU-Test-Umgebung
-  Wir haben im bestehenden Namespace `bestellsystem-fargate` einen neuen Service `cnp-ifp-mock` – für den hätten wir gerne DNS-Einträge um den im Review zeigen zu können. 
SQS-Queues: evu-test-produktionsauftrag, evu-test-vertriebsauftrag.
S3-Bucket: evu-test-vertriebsauftrag. 
IAM-Role: bestellsystem-evu-test-sqs-access (mit read/write-Zugriff auf Queues und Bucket)
56
complete
: wird eingerichtet. → bitte testen und ggf. Rückmeldung an  die Resourcennamen liegne im Teams Bestellsystem Channel
- fehlende Zugriffsrechte → ist bei CNP in Arbeit
57
complete
Lösung bis Montag 7.6 notwendig (notfalls ohne WebSSO) → kubeconfig wurde an  übermittelt
- Monitoring funktioniert derzeit noch nicht für bestellsystem-evu-test
58
complete
in Arbeit, benötigt bis 9.6 für die System-Demo des PI 20 →  Nachdem vergangende Woche die Nodegroup Resourcen gefixed wurden funktioniert nun auch wieder das Dashboard. Einige Dashboards für das bestellsystem-evu-test cluster werden erst etwas anzeigen wenn dort Workloads deployed wurden.
- ISGW (und DNS) 
59
complete
 :Domäne bestellsystem-commoninterface-test.dbnetze.com reserviert?
60
complete
: ELB Probleme noch zu beheben. Ein ELB-Endpunkt für ISGW reicht aus.
66
incomplete
Antrag wurde gestellt, jedoch wurde der Endpunkt im Antrag falsch ausgefüllt.  meldet sich sobald mehr Informationen verfügbar sind.
61
complete
Zertifikat liegt vor. bei Bedarf bei Konstantin erfragen.
62
complete
: Anforderung bzgl. Client-Zertifikate senden
- PEN-Test vorbereiten
63
complete
Anmeldung erfolgt sobald Natalia da ist
- Wichtig: die Umgebung sollte zum 1.8 im Internet (nach dem PEN-Test) verfügbar sein.
- Filterung der Routen für ISGW (Monitoring-Endpunkte, interne APIs) - wird im Service verprobt
- AWS Aurora
64
complete
 eine Aurora-Instanz zum Verproben
- Pipelines
- Bestellsystem hatte Austausch mit CDaaS-Team bzgl. Gitlab Agent. Es gibt ein Helm-Chart, der auch auf EKS benutzt werden darf.
## Termin am 18.05.2021
- Monitoring: Bestellsystem-Dashboards zeigen aktuell NO DATA an: 
37
complete
prüft es und lässt es korrigieren (siehe 1.6.2021)
- Aktuelle Bestückung des Clusters bestellsystem-dev mit 3 EC-Nodes
- Reicht aktuell aus
- Zusammenspiel von Plattform (CNP), Pipelines (MoQ-AP) und Anwendung (Bestellsystem)
38
complete
: wird nach Natalias Rückkehr besprochen (siehe Themenspeicher, bzw. Termin am 8.6)
- Umstellung des K8s-Logins auf Web-SSO:
- es kann die selbe Nutzer-Liste wie für Dashboards genutzt werden
- Erstmal keine Unterscheidung in Rechten
- Service-Account für Gitlab-Runner
39
complete
: kann User selbst anlegen, Anleitung bei Sean besorgen und dokumentieren
- DNS-Publikation für Ingress-Controller
40
complete
: fragt nach dem aktuellen Status (siehe 1.6.2021)
## Termin am 11.05.2021
- Ankündigung: künftig gibt es zwei Domains für prod und non-prod-Betrieb (cnp.comp.db.de und cnp-test.comp.db.de).
Wenn es soweit ist wird das von Sean mit Martin koordiniert und im Bestellsystem-Deployment angepasst
- schneller Check der letzten Agenda-Punkte
- ISGW-Bestellung für EVU-Test, mit Größe S
41
complete
 :wird im nächsten Sprint gemacht (siehe 1.6.2021)
- Kurze Einordnung zur Roadmap Pipelines
- Vorschlag: CNP-Distribution für den GitLab-Runner
Wir haben jetzt einiges Trial-and-Error gebraucht um den GitLab-Runner für S3-Cache, für Fargate, und für non-privileged/non-root Pods zu konfigurieren. Für andere Projekte wäre es sicher hilfreich wenn es eine CNP-Default-Konfiguration gäbe. Zudem gibt es den Support-/Interne-Lizenzen-Graubereich dass wir gerade CDaaS-Setups und Container für CNP anpassen; auch da wäre ein CNP-Template hilfreich.
=> wird vermutlich an MoQ-AP abgegeben
- Ankündigung: Der K8s-Login (aktuell `bestellsystem-admin` mit Token) wird auf Web-SSO umgestellt, Sean und Martin sprechen sich dazu ab
## Termin am 04.05.2021
- Bestellsystem-Benutzer zu den Bestellsystem-relevanten Dashboards hinzufügen (aktuell hat nur Martin Zugriff)
32
complete
: schickt Sean eine Liste der Bestellsystem-Benutzer
33
complete
: Gruppe Bestellsystem ergänzen
- Dediziertes Cluster für EVU-Testumgebung bestellsystem-evu-test, 2x m5-large EC2
34
complete
: legt Umgebung an
- Service-Mesh Status: aktuell keine Neuigkeiten
- Externer DNS-Name bestellsystem-commoninterface-test.dbnetze.com
35
complete
: fragt bei Natalia nach
- Deployment-Sicht https://git.tech.rz.db.de/-/snippets/613
36
complete
: liefert Feedback
- PEN-Test kann (soll?) inzwischen DB-intern durchgeführt werden. Unklar ob damit Systel AppSec oder DB-Netz eigene Leute gemeint sind.
- OPA Policies haben neulich den Kaniko-Build verhindert.
- Künftig werden Policy-Änderungen vorab angekündigt
- Container-Image Build - eine saubere Lösung steht noch aus. Evtl. kann hier MoQ-AP etwas bereitstellen.
- Gitlab-Runner - vom wem wird dieser künftig bereitgestellt werden: MoQ-AP, CDaaS, CNP?
## Termin am 27.04.2021
- Neue Termin-Serie ab 4.5 9:15-9:45 alle 2 Wochen 
- Bedarf für eine MacOS Instanz (mit Safari für Frontend-Tests) in der Cloud
- Lässt sich die auf EC2 starten (https://aws.amazon.com/ec2/instance-types/mac/)?
- Hürden: erfordert dedicated hosts und ist nur in Irland (eu-west-1) verfügbar.
- => Region eu-west-1 ist K.O.-Kriterium, deshalb ist das Setup nicht möglich. (Wir werden also versuchen stattdessen einen BKU-Rechner zu bestellen).
- Externe (Sub-)Domäne fürs Bestellsystem steht endlich fest (siehe BSQ-384): Wer kann sie im Service Manager Service Manager anlegen?
21
complete
 : Auftrag über Natalia an TBF für den beschlossenen Namen 
- Vorbereitung: EVU-Testumgebung und Pen-Test: dediziertes Cluster oder Namespace?
- : schließen sich kurz
- Deployment-Sicht auf das Bestellsystem
22
complete
: Entwurf für 4.5.2021 → noch sehr vorläufig: https://git.tech.rz.db.de/-/snippets/613
- Mit CI-Pipelines auf EKS brauchen wir auch mehr EC2-Ressourcen...  grobe Abschätzung: 3 × m5.xlarge (jeweils 4 vCPUs, 16 Gb RAM)
-- für drei Anwendungs-Installationen (jeweils 1-2vCPUs und 4Gb RAM), 10 GitLab-Runner (jeweils 2-3vCPUs und 1-10Gb RAM), und 5-10 AT-Deployments (die review-Deployments könnten nach Fargate)
23
complete
: erweitert die Node Group 
-
Wir sehen gelegentliche Fehler beim Starten von Pods.
-
K8s-Events: 
-
Das führt dann zum GitLab-Fehler: 
Können wir das verbessern?
-
Speziell in Fargate gibt es auch Probleme mit Ressourcen-Quotas, das liegt vermutlich an Verhalten oder Konfiguration der GitLab-Runner, erscheint aber nur gelegentlich (und ist dadurch schwer zu demonstrieren oder zu beseitigen):
- Storage für Gitlab Cache: S3 bevorzugt
- erledigt: Bucket ist angelegt und wird vom GitLab-Runner benutzt 
- Nachfrage zu den ServiceAccount-Definitionen im bestellsystem-ops-Repo: sind die nur zur Info oder werden die irgendwann einmal eingespielt?
Wir haben nämlich zusätzliche Einstellungen (imagePullSecrets), die wir dann ggf. einpflegen müssen.
24
complete
: schaut sich das an. Prinzipiell kann das über MergeRequest beantragt werden.
## Termin am 13.04.2021
- Confluence für Mitschrift
13
complete
Konstantin: Freischaltungen für Natalia + Sean
- Serien-Terminverschiebung um eine Woche, ab 20.4
14
complete
Natalia lädt ein
- CNP-Umgebungen im Bestellsystem
- Aktuell läuft eine PoC-Umgebung auf CNP, die fertige Docker-Images installiert, über einen Gitlab-Runner
15
complete
: Bestellsystem wird um CNP-Monitoring erweitert (war schonmal drin)
- Sean: S3-Queues müssen neu angelegt werden, da das Namensschema sich geändert hat
16
complete
Sean geht auf Martin zu
- Aktuell wird im Bestellsystem eine Build-Pipeline auf CNP aufgebaut
- langfristigere Fragen:
- automatische DNS-Einträge für Ingress
- noch keine Terminaussage möglich
- API-Zugang
- frühestens in einem Monat
- Info zu Service Mesh
- siehe DNS-Einträge, Rollout am 27.4 geplant
- Secret-Ablage im Bestellsystem
- Gitlab-Runner legt sie im Kubernetes ab
- Zugriffe aus VPN per HTTPS auf Anwendungen immer noch langsam (3-4 Sec)? 
- scheinen sich gebessert zu haben
## Termine am 01.03.2021, 16.03 und 30.03
Mitschrift
- DNS-Einträge für neue Deployments/Ingresse (am 26.2. nochmal getestet; erfordert manuelle Schritte)
- Sollte automatisch funktionieren --> kommt erst mit Service Mesh
- Service Mesh: Recherche-Thema ganz am Anfang, wir wollen wissen was CNP anbietet bzw. plant​
- Roadmap und Dokumentation: Ende März erste Service Mesh Version geplant (app.mesh)
- Wie kann eine Lösung für REST-API Authentifizierung? Gibt es hierzu Infos?
- Sean prüft das und schickt einen Vorschlag
5
incomplete
(bis ca. 8.4)
- Hängt von ausstehenden AWS Diensten ab (Ingress Controller)
- In Q2 eher unrealistisch
-  PEN-Test
- Verschlüsselung/Authentifizierung
- Offener Punkt --> kann PEN Test verhindern!
- Natalia teilt Detaillsplanung wegen ISGW --> temp. Auch ohne PEN-Test möglich max. 2-3 Wochen --> vermutlich über CNP. Details klären.
- (PEN-Test pro Service oder System, Beauftragung durch CNP, Vorlaufzeit bis zu 6 Wochen, ca. Ende Q2)
- Kapa-Bel von IFP --> steht im März an
- OPA für Autorisierung
- Kann erst nach app.mesh kommen, frühestens im Juni für Projekte
- Routing für Diskriminierungsfreiheit
- Analog KommBau
- Interne Adresse gesperrt (über Whitelist)
- Keine Auswirkung auf Betriebsdienste
- Anhebung des Monitorings auf die nächste Stufe --> vom demo/PoC zum Regelbetrieb
- Heraufstufen der Umgebung
6
complete
zwischen 15. und 25. März möglich, wird seitens CNP gemacht
- Erstmal weiterhin ein Cluster-Admin-Account fürs Bestellsystem
- falls wir ein Deployment ohne Fargate haben, dann auch Anwendungs-Logdaten in deren Grafana 
-
Wird mit dem Heraufstufen der Umgebung voraussichtlich gelöst
-
Wann geht Logging mit Fargate?
-
Erfordert einen Log-Forwarder über Dateien und eigenen Sidecar-Deployment (promtail-agent)
-
Alternativ warten auf AWS-Feature --> wird von Bestellsystem derzeit bevorzugt
-
SQS-Zugriffsrechte (ist in Arbeit, Maximilian war krank)
7
complete
Ist gerade in Arbeit
-
hybrider EKS-Namespace mit EC2 (für GitLab-Jobs) und Fargate (für skalierbare Installationen)
-
Martin schickt die Anforderungen an eine neue EC2 Instanz, CNP macht es zusammen mit der Heraufstufung (ebenfalls 15-25.03)
-
Reifegrad MoQ-AP Integration --> gibt es noch offene Punkte (insb. Privileged Mode)
-
Es kann in derselben Bestellsystem-Umgebung bei CNP laufen
-
Natalia kann das Wissen sharen (Betriebsstellen-Service) --> Austausch zwischen Projekten muss über MoQ-AP laufen
-
Privileged mode noch seitens MoQ-AP benötigt --> ist kein dringendes Problem
-
Vault vs AWS Secret Manager
-
Vault wird von Bestellsystem nicht benötigt
-
Wichtig sind Kubernetes Secrets
-
AWS Secrets Manager als Vorgabe
-
Regel-Termin alle 2 Wochen
8
complete
Natalia lädt ein
bahn/project-audit/data/confluence-export/pages/171574432_Community of Practice CoP.md
+388
View File
@@ -0,0 +1,388 @@
# Community of Practice (CoP)
> Confluence Page ID: 171574432
> Version: 83
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Community of Practice (CoP)
> Labels: file-list
---
Community of Practice (CoP) ist eine Möglichkeit für Wissenstransfer und Erfahrungsaustausch für alle in unserem ART. Es soll uns ermöglichen Praktikern, Wissen und Fähigkeiten in dem Train auszutauschen, um bestehendes Wissen zu verteilen oder gemeinsam neues Wissen aufzubauen. 
Themen für CoP sind jeweils bis zum Freitag davor - bis 12 Uhr - einzutragen, ansonsten wird der Termin abgesagt. 
| | #  | Datum | Wer  | Timebox | Thema | Teilnehmer | Besprechungsnotizen
| |
| 16.12.2024 |
|
|
  |
|
| |
| 18.11.2024 |
|
|
  |
|
| |
| 04.11.2024 |
|
|
  |
|
| |
| 21.10.2024 |
|
|
  |
|
| |
| 07.10.2024 |
|
|
  |
|
| |
| 23.09.2024 |
|
|
  |
|
| |
| 26.08.2024 |
|
|
Entfällt, wg. keine Themen |
|
| |
| 12.08.2024 |
|
|
Entfällt wg. keine Themen |
|
| |
| 29.07.2024 |
|
|
  |
|
| |
| 15.07.2024 |
|
|
  |
|
| |
| 01.07.2024 |
|
|
  |
|
| |
| 10.06.2024 | Entfällt wegen I& A |
|
  |
|
| |
| 27.05.2024 |
|
|
  |
|
| |
| 13.05.2024 |
|
|
  |
|
| |
| 29.04.2024 |
|
|
  |
|
| |
| 15.04.2024 | Team Zero | 30 Min |
Wir möchten mit euch über Grafana-Boards, Metriken und Alerts sprechen. Idee ist, dass wir uns in dieser COP gegenseitig unsere Dashboards vorstellen und offen diskutieren was wir für sinnvoll / überflüssig / hilfreich erachten.   |
|
Grafana-Boards von Team Zero und APN und CIB und wurden vorgestellt. Themen waren:
-
- Realisierung der Abfragen 
- Erfahrungen mit Performanceproblemen
- Loki (label spielen eine große Rolle) vs. Prometheus -
Vor- und Nachteile
Kostenstelle ist auch eine Frage dabei, die dann bei CNP/AWS anfallen
IO und Netzwerktraffik kosten zusätzlich Geld
- Spike für fachliche Inszidens mit Countmetrik und Alerts
- Thema ist noch nicht abgeschlossen und es gibt Ideen/Vorschläge zu guter Handhabung
Für Fragen und weiteres Interesse gern Fragen direkt an die jeweiligen Teams.
| |
| 02.04.2024 | Ab jetzt wieder alle 2 Wochen CoP |
|
|
|
| | 27 | 18.03.2024 | Entfällt wegen I& A |
|
  |
|
| | 26 | 19.02.2024 |
|
|
  |
|
| | 25 | 22.01.2024 |
|
|
  |
|
| | 24 | 20.11.2023 | Diego Da-Costa-Souza / Jan Lubenow | 30 Min |
Parallelisierung von Cucumber-Basierten Tests am Beispiel der Systemtests des Bestellsystems.
- Was haben wir umgebaut?
- Welche Herausforderungen gab es?
- Wie gehen wir mit Tests um, die nicht parallel laufen dürfen? |
|
| | 23 | 23.10.2023 | Team Zero | 30 Min | Wir möchten mit euch über Code-Reviews sprechen/ mit euch diskutieren. Habt ihr in eurem Team eine definierte Vorgehensweise wie ausführlich ein Code-Review gemacht wird / ggf. eine Checkliste?  |
|
| | 22 | 07.08.2023 | Marcel Hufgard / Alexander Petioky | 45 Min | Camunda Cockpit für Nichtentwickler |
|
| | 21 | 26.06.2023 | Team Zero | 1 Stunde |
- Wer ergänzt der Entwicklerhanduch Wiki mit Antworten von CoP?
Secrets:
- Wie sind die Secrets strukturiert ?
- Secrets unter Pipeship Verzeichnis. Nur für AT oder andere Stellen auch ?
- Welche Schritte sind nötig Secrets für eine Anwendung zu definieren, der nur während der Pipeline lauft und nicht in ein eigene Container? (z.B. Lup)
Git + Pipeship:
- Umbenennung eine Applikation, was ist der beste/einfachste Weg?
Extra wegen Postman Umstellung:
- Wie ist der Stand mit Postman Ersatz, welche scheint der gewinner zu sein? (Insomnia oder andere)
DevOps Allgemein:
- Gibt es ein Wiki/FAQ für in CNP oft passierende Fehlern und zu ihre Behandlung? Wenn ja, wo ? (z.B.  Ingress Nummer Limit überschritten, DB Übergelaufen) |
|
| | 20 | 29.05.2023 | Team Zero | 30 Min | Fragen zum Thema DevOps |
|
| | 19 | 15.05.2023 | Kai Barkschat, Frank Thiele  | 1 Stunde | Gegenseitige Vorstellung  von APN und BS Piplines |
|
| | 18 | 03.04.2023 | Team Zero | 30-60 Minuten | Brainstorming zur Pipline Problematik.  |
  | Fragen bzw. Themen für FAQ:
- Ist es möglich die Pipeline Ausführung abzubrechen?
- Mit welchen Parameter kann die Pipeline gesteuert werden
- Ressourcen überprüfen & ggf. skalieren
→ das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-628
| | 17 | 06.02.2023 | Team Zero | 15-30 Minuten | Brainstorming Tracing: Wie wollen wir sinnvoll filtern? |
| Wir brauchen fürs Tracing a) ein sinnvolles Filtern (=Tail Sampling) als Defult zum Deployen und b) ein Verfahren und das Know How, wie man bei Bedarf das Tracing umkonfiguriert.
| | 16 | 23.01.2023 | Alle | 15-30 Minuten | Infosammlung PAN Client | Alle |
| | 15 | 09.01.2023 |
| ca. 5 Minuten | Vorteile der erweiterten Version (Developer Edition) von SonarQube  |   |
| | 14 | 09.01.2023 |
| ca. 30 Minuten | Nutzung von Camunda Cockpit für Prozesse von Steuerung-Vertrieb |
  |
| | 13 | 21.11. und 5.12.2022 | System Team | -- | Diese Termine möchten wir für den Wissenstransfer-Workshop übernehmen (den müssen wir wegen Konflikten jeweils auf Montag verschieben). |
  |
| | 12 | 7.11.2022 | System Team | 30-60min |
Themenvorschlag, bei Interesse:
Tracing mit OpenTelemetry Agent
Vorstellen des Setups und der verfügbaren Java-Code-Annotations. (Doku im Entwicklungshandbuch ist noch in Arbeit.) |   |
| | 11 | 29.08.2022 | Team Zero  |
| Fragen zum Talo(spring) für Logging
Gibt es einen Erweiterungspunkt in Talo-Java/Talo-Spring, was zum Ersetzen von geheimen Daten mit Sternen und zur Verkürzung von langen Strings genutzt werden kann ? 
Wie kann das mit Talo/log4j2 am einfachsten umgesetzt werden? |
|
| | 10. | 01.08.2022 | Team Zero / Bestellsystem Teams | ca. 30 Min. | Springboot-Webflux-WebClient Erfahrungen mit OpenAPI und Springboot-Client |
-  (Zero)
- Nach Interesse |
| | 9. | 11.07.2022 | Bestellsystem-Teams |
|
Git-Workflows
(Fortsetzung) | Erstes Ausprobieren mit Erfahrungsberichten? |
textwenig strukturierte Notizentrue im Zweifelsfall wird eine Pipeline brechen (entweder letzter MR-Build oder erster master-Build)
## Schwierigkeit: Updates von zwei Services
Funktioniert im Realbetrieb nie wirklich gleichzeitig, Kompatibilität zwischen zwei Versionen ist immer mehr oder weniger notwendig.
### Komponenten-Integrations-Test
z.Bsp. ifp-mock-Version in SV .gitlab-ci.yml => kein großes Problem
### Unit-Tests
keine Nachbarsysteme beteiligt,
aber mehr Pflege-Aufwand bei häufigeren Merges
## System-Tests
neue Features erfordern oft neue Branches im System-Test
normalerweise einfach, schwierig zum Sprint-Ende wenn viele Branches gemergt werden
es würde helfen in den System-Test-Reports mehr Metadaten, vor allem Service-Versionsnummern, zu haben.
allgemein: System-Tests sind instabil und "blinken"
Problem: viele Zeit-basierte Tests, mit schwankender Performance beim Nachrichten-Durchlauf (portal - SV - IFP und zurück) => unterschiedliche Test-Ergebnisse
ohne IFP-Mock-Wartezeit geht es bisher auch nicht (SV ist nicht so schnell)
### System-Tests mit development-Branch
Der development-Branch in qa/system-test wird benutzt, sollte nicht gelöscht werden
# automatisiertes Update nach EVU-Test
Reihenfolge der Stages?
=> IEU -> SIT -> EVU
Test-Zuverlässigkeit ist wichtig, je besser System-Test und System-Integration-Test desto sicherer ist das EVU-Test-Deployment
Offene Frage: wieviel Release-Management oder -Freigaben brauchen wir? Besonders in Richtung Kunden-Kommunikation (Sven-Ole).
]]>
| | 8. | 27.06.2022 | System Team | 1 |
Git-Workflows
Bei einem Git-Workflow geht es darum, wann man einen Branch anlegt, welchen existierenden Branch man als Grundlage nimmt und in welcher Reihenfolge und wann man Branches wieder integriert.
Wir stellen vor, welches Workflow in Git aktuell und künftig Vorgehen im Bestellsystem eingesetzt wird. |
|
Grundlage war das Bestellsystem-Konzept Git Workflow
textwenig strukturierte Notizentrue System Test
während der Entwicklung oft ein Diff zwischen Anwendungs-Code und System-Test-Code
]]>
| | 7. |
20.6.2022 | Team APN |
|
Umgang mit Software-Lizenzmanagement. Whitesource wertet das ja aus. Mich würde interessieren, wie die anderen Teams damit umgehen und ob es bereits Automatismen gibt (Die wir vielleicht übernehmen können). So eine Art Auto-Action, Pattern -basiert
-
Haben wir einen Lizenzexperten (Jurist?) als Ansprechpartner?
-
duale Lizenz -Kombinationen für Open Source,
-
organisatorische Vorgaben/Policies bzgl. Lizenzen
-
Erkennung von DBISL
-
In-House Lizenzen verwalten (aktuell bei uns: nur als OrgAdmin über tomag-Team -> sehr aufwendig, nicht praktikabel) |
|
Haben wir einen Lizenzexperten (Jurist?) als Ansprechpartner?
-> https://evi.intranet.deutschebahn.com/evi31/simpleSearchAction.do?filter=Cornelius%20Schumacher
Cornelius Schumacher
Open Source Steward der DB Systel GmbH
Teams Kanal für Lizenz – Fragen
organisatorische Vorgaben/Policies bzgl. Lizenzen
-> Open-Source-Lizenzkompass
https://git.tech.rz.db.de/foss/lizenzkompass/-/blob/master/index.adoc
https://git.tech.rz.db.de/foss/lizenzkompass/-/blob/master/lizenzen/liste.adoc
-> jedes Team kann selbst entscheiden, ob und wie in WhiteSource Policies verwendet werden
mit Policies kann geregelt werden, dass bei bestimmten Lizenzen Alerts entstehen
Erkennung von DBISL
-> aus Sicht von WhiteSource gibt es keine DBISL, entsprechende Libraries können als In-House markiert werden
In-House Lizenzen verwalten (aktuell bei uns: nur als OrgAdmin über tomag-Team -> sehr aufwendig, nicht praktikabel)
-> alle als In-House markierte Libraries entfallen aus der Lizenz-Betrachtung, die Zuordnung muss über tomag-Team laufen, kann leider nicht delegiert werden, man kann ganz gut mit Pattern arbeiten, um Muster zu erkennen
Mögliche Lösungsvorschläge für die Verwaltung von Lizenzen:
- Klären üb es möglich wäre den Feature Flag zu aktivieren und die Lizenz - Verwaltung über Produkt Admins zu organisieren.
- Klären, ob es möglich wäre, Anforderungen der Bahn beim Hersteller zu versenken.
| | 6 | 30.05.2022 | Team Zero |
|
Kundendaten-Adapter
Der Kundendaten-Adapter ist bereits durch viele Hände gegangen und nun beim Team Zero gelandet. Wir möchten gerne von denjenigen, die ihn bisher konzipiert und entwickelt haben, mehr KnowHow bekommen.
Wozu ist er gut und was tut er eigentlich ?
Gibt es besondere Fallstricke (Api oder ähnliches)?
Wie ist das Datenvolumen? Gibt es Anforderungen bzgl. Last- und Performance? |
|
| | 5. |
16.05.2022
23.05.2022 |
| 1 |
DevOps
Was sind unsere Ziele bezüglich DevOps? 
Wie stellen wir DevOps bei uns vor? | Vertreter aus allen Teams |
| | 4.  | 02.05.2022 |
| 1 |
DevOps 
Was sind unsere Ziele bezüglich DevOps?
Wie stellen wir DevOps bei uns vor? | Vertreter aus allen Teams |
| | 3. | 11.04.2022 | Team Zero | 1 |
Camunda:
Einführung in die umgesetzten Prozesse
Erläuterung: Marcel hat uns in der Einführungsveranstaltung die fachlichen Prozesse erläutert. In CoP vom 21.03. Haben uns die CIB-Entwickler an einem Prozess erläutert, wie das technisch realisiert ist und getestet wird. Jetzt wäre es gut, wenn Alexander noch die Lücke schließen würde: Welche fachlichen Prozesse sind wie in Camunda modelliert? |
(CIB)
|
| |
2.  | 21.03.2022 | Team Zero | 1 Stunde |
Camunda:
Welche Prozesse werden abgebildet?
Wie ist die Integration in die SV technisch umgesetzt?
Wie werden diese Prozesse getestet?
Falls vorhanden: Offene Punkte/Erfahrungen/Ausblick |
(Zero)
(CIB)
  (Zero)  |
| |
1. | 07.02.2022 | Team APN  | 1 Stunde  | Integration der CI-Pipeline:
- Welche Erfahrungen hab Ihr bezüglich der Pipeline gemacht?
- Welche Features werden genutzt, welche nicht?
- Welche Ergebnisse werden ausgewertet?
- aktueller Stand der Integration der Pipeline in den Entwicklungsprozess (je Team)
- Ansteuerung/Triggering via git (Vorgehensmodelle)
- Ausblick/Zukunftspläne |
 (Zero)
(Zero)
(System)
(APN)
 
(CIB)
(404)
(APN)
(APN)
(APN)
  (404)
(System)
(404) |
bahn/project-audit/data/confluence-export/pages/196749641_pathOS.md
+10
View File
@@ -0,0 +1,10 @@
# pathOS
> Confluence Page ID: 196749641
> Version: 6
> Pfad: /pathOS
> Labels:
---
## InhaltsverzeichnisÂ
bahn/project-audit/data/confluence-export/pages/206667947_QA Themen.md
+10
View File
@@ -0,0 +1,10 @@
# QA Themen
> Confluence Page ID: 206667947
> Version: 6
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen
> Labels:
---
bahn/project-audit/data/confluence-export/pages/206667964-Systemintegrationstests fuer BS - IFP-SST.md
+56
View File
@@ -0,0 +1,56 @@
# Systemintegrationstests für BS ↔ IFP-SST
> Confluence Page ID: 206667964
> Version: 11
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen/Systemintegrationstests für BS ↔ IFP-SST
> Labels: meeting-notes
---
Teilnehmer:  
Was soll genau mit SITs getestet werden? das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-1614
   Relevante  Aktionen zwischen BS und realen externen Partner zu testen. Pro Schnittstelle mind. ein Positiv und ein Negativfall testen.
   Die Tests werden möglichst einen kleinen Teil des Ablauf im BS testen. In diesem Fall SV<->IFP
Akzeptanzkriterien von  https://nvi.jaas.service.deutschebahn.com/browse/O2CCIB-1614 :
- Die Definition /Umfang von SIT ist für die IFP-SSTs geklärt
- Die bereits definierten Systemintegrationstestfälle wurden ggf. überarbeitet bzw. Aktualisiert
Die Tests müssen minimal die Kommunikation zwischen SV und IFP testen(Aufgrund Kosten der höheren Teststufen)
Stand der Testfälle aus TK: Die vorhandene Regressionstestfälle im Testkonzept sind sehr umfangreich für Systemintegrationstest.
Testfall: Ein konstruierbarer/nicht konstruierbarer Produktionsauftrag/Änderungsanmeldung(in TDM Format) wird von Steuerungsvertrieb an IFP geschickt.
Beispiel für den Negativfall:  Pflichtangaben fehlen. Anschließend wird die Anfrage abgelehnt. Vorerst kein negativer Testfall.
Anforderungen an Testfall:
- Der erste Testfall soll SQS testen und der zweite Testfall S3
- Die Nachrichten von SV(mit Trassenanmeldung API)  an IFP schicken
Bzgl. beteiligten Prozesse:
Überlegung: Die BEP und AC für SIT werden wir  nicht aufnehmen( Das kann gemockt werden)
Idee: Sub-Prozesse direkt im Test starten und dadurch die Nachricht an IFP über Camunda API versenden.
Ziel: Wir testen mit echtem Schnittstellen-Code auf SIT Umgebung. Ohne Code Änderung den Test durchführen. Z.B Prozess kopieren und den BEP-Aufruf weglassen.
Die Datenbank auf SIT wird nicht migriert.
Damit keine manuelle Aktion benötigt wird: 
- IFP erstellt statisch Angebote und SV Schickt Annahme für die von uns bekannten Aufträge
- Wir schicken eine Trassenanmeldung, die nicht konstruierbar ist.
Zusätzliche HealthChecks (Springboot, Kub Healthchecks)-> Überprüfen,  ob die Nachricht verschickt und Response zurück kommt.
Queue stellt sicher, dass die Nachrichten nicht verloren gehen. Daher verzichten wir von dieser doppelter Überprüfung.
Bessere Alternative: Queuegrosse überprüfen (Gelegenheitsverkehr) -> vorerst nicht geplant
Generieren von pathID für periodische Tests Durchführung (mit IFP abstimmen z.B für die Erstanmeldungen -> An Christian Meins )
TODOs:
- Der Testfall ist mit IFP zu klären(Jahan hält Absprache mit , um den Testfall mit IFP abzusimmen) 
- Alexander kümmert sich um die Prozesse für den Testfall
bahn/project-audit/data/confluence-export/pages/208930190_Sonstige Termine.md
+10
View File
@@ -0,0 +1,10 @@
# Sonstige Termine
> Confluence Page ID: 208930190
> Version: 1
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine
> Labels:
---
Dies ist ein Sammler für Termine, die nicht Teil einer Serie sind.
bahn/project-audit/data/confluence-export/pages/249539297_2023-04-03 Besprechungsnotizen Changelogs und Releaseprozess.md
+76
View File
@@ -0,0 +1,76 @@
# 2023-04-03 Besprechungsnotizen Changelogs & Releaseprozess
> Confluence Page ID: 249539297
> Version: 7
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2023-04-03 Besprechungsnotizen Changelogs & Releaseprozess
> Labels:
---
## Datum
## Teilnehmer
- Annette Halbhuber
- Bernd Klebl
- Bing Shi
- Christian Meins
- Christian Seltsam
- Daniel Brügmann
- Diego Da-Costa-Souza
- Dong-Won Han
- Emmanuel Kontcheu-Tagne
- Nicole Bechtold
- Thorsten Volland
## Diskussionspunkte
## Koordiniertes Release auf Kundentestumgebung
- nach Sprintende ausführliche Tests auf SIT
- Deployment im Anschluss zusammen und koordiniert mit IFP und neXt auf die E2E-Kundentestumgebung
- Teams-Kanal zur Koordination (Kundentestumgebung)
- Dokumentation der Releaseinhalte in Confluence
- Konsequenzen:
- SIT-Umgebung steht nicht durchgängig für Deployments zur Verfügung (Freeze zwischen Sprintende und Deployment auf E2E-Kundentestumgebung)
- Unterbrechung in der aktuellen Pipeline: SIT ist die Vorstufe zur EVU-Test
- Unterbrechung des Flows → kürzerer Zeitraum zwischen Sprintende + Deployment
- Starke Abhängigkeit zu IFP/neXt → Deployment unabhängig von IFP/neXt, aber vorab auf SIT getestet
- Schnittstellenänderungen konsequenter betrachten
- Maßnahmen:
- Vorgehen zwischen Iteration 2 und 3 (PI 28) einmal verproben
- Erstellung Releasedokumentation (nach Template ) 
- SIT ab Mittwoch EOB unverändert
- Wenn Tests grün, dann Deployment Donnerstagnachmittag auf E2E-Kundentestumgebung
- Erkenntnisse aus dem Vorgehen analysieren
- Offene Fragen:
- Zuständigkeit übergreifende Tests
- Wer macht das eigentliche Deployment auf Zielumgebung?
- Befüllung Releasedokumentation-Template für Bestellsystem?
## Diskussionspunkte für Folgetermine
## Wie ist der Release Scope des Bestellsystems (Gesamtsystem vs. Einzelanwendungen)?
- Feature-Releases/Reguläre Releases
- Hotfix-Releases
- Versionierung
## Wie ist der Release-Zyklus? Wann findet ein Release statt?
## Welche Release-Dokumentation wird benötigt?
- Scope des jeweiligen Releases (Versionen der Anwendungen)
- Changelog/Release-Notes
- Deployment-Infos (Reihenfolge aufgrund von Abhängigkeiten, zusätzliche Deployment-Tasks)
- Releasefreigabe (ggf. Anforderung von Betriebsteam)
## Werden Checklisten zur Release-Vorbereitung eingesetzt?
- siehe z.B. bei APN:
## Technische Fragen
- Scope von Changelogs (falls nicht oben geklärt)
- Arbeiten mit Release Candidates/Feature-Branch?
- Feature-Toggles?
bahn/project-audit/data/confluence-export/pages/253591653-2023-04-12 Releaseprozess fuer Kundentestumgebung.md
+35
View File
@@ -0,0 +1,35 @@
# 2023-04-12 Releaseprozess für Kundentestumgebung
> Confluence Page ID: 253591653
> Version: 2
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/Sonstige Termine/2023-04-12 Releaseprozess für Kundentestumgebung
> Labels:
---
## Datum
## Teilnehmer
## Diskussionspunkte
- Releasedokumentation:
-
neues Feld "Lösungsansatz" in Jira-Tickets für erläuternde Texte zu den einzelnen Tickets
- Vorschlag für erstes Deployment zur Vereinfachung: eine Release-Version für alle Anwendungen, später eine Version pro Anwendung
- Release Anwendung/Microservice vs. Bestellsystem-Release
- Release Anwendung/Microservice bei Fertigstellung der benötigten Features und Bugfixes inkl. anschließender QA
- Release Bestellsystem: aus der Sicht des Nutzers/EVU (Release = Bereitstellung/Deployment)
- Vorschlag zum vorübergehenden Vorgehen bei Release:
- Alle Apps mergen ihre Features wie bisher in den Master-Branch
- Ist der Master-Branch Feature-Complete für ein Release,
- wird in Git ein Release-Tag angelegt
- wird sichergestellt, dass SIT erfolgreich durchgeführt wurde
- sit_update/sit_trigger werden am Mittwoch vor einem BS-Release nicht automatisch ausgeführt
- bei Nachlieferung für Release müssen die Jobs manuell gestartet werden
- ggf. scheduled Trigger für Donnerstagmorgen?
- Ist die Staging-Pipeline im passenden Status (post SIT) für das Release, wird die Pipeline-Instanz in der Release-Dokumentation verlinkt
- vorhandener Eintrag in Release-Dokumentation wird überschrieben
- letzte eingetragene Pipeline enthält alle für das Release relevanten App-Versionen → Deployments nach EVU-E2E und EVU-Test werden auf dieser Pipeline-Instanz ausgelöst
- Neue Umgebung für E2E-Tests (ohne EVU-Zugriff) für die Releasevorbereitung ist in Planung
bahn/project-audit/data/confluence-export/pages/259257571-Einfuehrung von Xray im Testworkflow von ART O2C.md
+61
View File
@@ -0,0 +1,61 @@
# Einführung von Xray im Testworkflow von ART O2C
> Confluence Page ID: 259257571
> Version: 25
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen/QA Themen/Einführung von Xray im Testworkflow von ART O2C
> Labels:
---
Diese Seite wurde erstellt, um die Koordination der Xray-Einrichtung im neuen Bestellsystem nachvollziehbar zu machen.
Bitte um Updaten dieser Seite beim Fortschritt/Änderungen.  
- PI 27 - S4 - O2CCIB truedas I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2693
- PI 27 - S4 - O2CZERO das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-1588
- PI 28 - S4 - O2CZERO das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CZERO-1785
- PI 27 - S6 - O2C404 das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2C404-1911
- PI 27 - S6 - O2CCIB das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2876: Einleitun zu Xray: 
- PI 28 - S1 - O2CCIB das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CCIB-2942:
- Einrichten einer Jira-Testumgebung für alle Tester auf https://nvi-tst.jaas.service.deutschebahn.com/secure/Dashboard.jspa:
12
complete
Ticket zur Support-Anfrage an Jira-Team: https://arija.jaas.service.deutschebahn.com/servicedesk/customer/portal/9/SATS-563
Info: Laut Bing macht Team Zero die ersten Vorbereitungen für die GitLab Integration mit Xray. Die Tester sollen die Basis nutzen, um die
Integration weiter zu erweitern.
Tickets von System-Team für die Vorbereitung der GitLab Pipelines zweck Exportieren der Testergebnisse nach Jira in einem Testplan
- PI 28 - S2 - O2CSYS das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-663
- PI 28 - S5 - O2CSYS das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-672
Offene TODOs:
3
complete
Stauts der Einrichtung von Xray auf Jira-Testumgebung folgen (am 4.5.2023 wurde Xray auf Testumgebung in den Projekten O2C ART und O2C System freigeschaltet)
4
incomplete
Wunsch von Bing: Die Anforderungen in der Story das I.NVI IT Lifecycle Management Toold1143f0d-33c0-3f1c-b44b-7720150f306eO2CSYS-672 erweitern und konkretisieren und mit Jira-Board Zuständige ( Nicki, Ellena) Absprache halten, da der Import der Testergebnisse Einfluss auf Jira-Oberfläche haben wird (evtl. neue Test-Vorgänge werden automatisch erzeugt. Dies muss überprüft werden)
7
incomplete
Nach der Einrichtung von Xray auf Testumgebung die API ausprobieren und schauen, ob Importieren der Testergebnisse ohne Erstellung neuer Test-Vorgänge in Jira möglich ist?
10
incomplete
Xray Integration mit neuen Anforderungen für nächste PI vorbereiten. Laut Nicki hat System-Team aktuell wenig Kapazität für die Unterstüzung.
bahn/project-audit/data/confluence-export/pages/267687097-Kommunikationskanaele Termine Besprechungsnotizen pathOS.md
+11
View File
@@ -0,0 +1,11 @@
# Kommunikationskanäle, Termine, Besprechungsnotizen pathOS
> Confluence Page ID: 267687097
> Version: 8
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS
> Labels:
---
Dieser Abschnitt bietet eine Zusammenfassung aller regelmäßig stattfindenden Termine im ART pathOS – auf Team-, teamübergreifender und ART-Ebene – sowie eine Übersicht der etablierten Kommunikationskanäle in pathOS.
Weiterhin werden hier die Besprechungsnotizen zentraler, übergreifender Termine wie der Architekturrunde, der CI/CD-Runde und der DevOps-Runde dokumentiert. Notizen zu weiteren Terminen werden zentral im OneNote abgelegt.
bahn/project-audit/data/confluence-export/pages/267687106_Architektur Bestellsystem.md
+13
View File
@@ -0,0 +1,13 @@
# Architektur Bestellsystem
> Confluence Page ID: 267687106
> Version: 13
> Pfad: /pathOS/Architektur Bestellsystem
> Labels:
---
Architektur-Dokumentation
pathOS pflegt und aktualisiert seine Architekturbeschreibung im Runbook. Sie ist über den Link für jeden einsehbar. 
  Architektur-Runde
Im zweiwöchentlichen Rhythmus findet die Architektur-Runde von pathOS mit Teilnehmern aus jedem Team statt. Die Protokollierung findet sich hier.  Auch im Confluence dokumentiert werden alle betriebliche Themen, die die Architektur betreffen. Diese können unter der Kategorie Betrieb eingesehen werden. Â
bahn/project-audit/data/confluence-export/pages/267687109_Roadmap Bestellsystem.md
+10
View File
@@ -0,0 +1,10 @@
# Roadmap Bestellsystem
> Confluence Page ID: 267687109
> Version: 1
> Pfad: /pathOS/Roadmap Bestellsystem
> Labels:
---
Yellowi.A.
bahn/project-audit/data/confluence-export/pages/267687115_Start _ Vorstudie Bestellsystem.md
+10
View File
@@ -0,0 +1,10 @@
# Start / Vorstudie Bestellsystem
> Confluence Page ID: 267687115
> Version: 2
> Pfad: /pathOS/Start / Vorstudie Bestellsystem
> Labels:
---
bahn/project-audit/data/confluence-export/pages/27525683-4.4.5 Anbindung an Verwaltungsunterstuetzende Services KDV und eBRS.md
+426
View File
@@ -0,0 +1,426 @@
# 4.4.5 Anbindung an Verwaltungsunterstützende Services (KDV & eBRS)
> Confluence Page ID: 27525683
> Version: 135
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.5 Anbindung an Verwaltungsunterstützende Services (KDV & eBRS)
> Labels:
---
## Einleitung
DB Netz interne Mitarbeiter (DB Netz Vertriebsmitarbeiter, Kundenbetreuer, fachliche sowie technische Betriebsführung) sowie DB Netz externe Benutzer (Mitarbeiter der EVUs) sind die zwei unterschiedlichen Benutzergruppen, die sich im Bestellportal anmelden. Für die externen Benutzer wird die Funktionalität zur Authentifizierung und Autorisierung über das vorhandene Verfahren eBRS genutzt, interne Nutzer sollen sich dagegen mit ihrem BKU-Account am System anmelden können. Der Service Kundendatenverwaltung (KDV) liefert die Kundenstammdaten zu einer gegebenen Kundennummer.
Im CRM System gibt es neben der KaufmännischenSperre auch ein Stop-Kennzeichen für den Kunden. Wenn dieses gesetzt ist, wird dieser Kunde nicht über den Service KDV übertragen, d.h. er kann sich dann auch nicht am Bestellsystem anmelden. 
Hinweis: alle DB-internen EVUs (z.B. DB Cargo - EVU Sachbearbeiter) gelten als externe Benutzer.
Hinweis: Es wird keine Stellvertreter-Regelung wie in TPN unterstützt, d.h. dass es keine exklusiven Vorgänge gibt, für die man andere Benutzer (Stellvertreter) berechtigen muss. Stattdessen sollen Nutzer bei Bedarf die für sie irrelevanten Vorgänge ausblenden können.
## Registrierung und Verwaltung der Bestellportal-Benutzer
Alle externen Benutzer (DB Netz extern) müssen sich im Vorfeld für die Nutzung des Bestellportals registrieren. Dies geschieht über eine entsprechende Funktionalität im Kundenportal der DB Netz (ehemals myNet), das eine entsprechende Anbindung an eBRS besitzt. Über das Kundenportal können alle Nutzer kundenseitig durch Selbstadministration verwaltet werden. Die Verwaltung der Benutzer erfolgt durch EVU-PowerUser.
Die initiale Pflege der PowerUser pro Kunde, die dann selbst die Verwaltung und Berechtigungszuordnung der weiteren Nutzer dieses Kunden übernehmen, ist nicht Teil des Projekts und ist durch I.NMK sicherzustellen.
Für die Administration der DB Netz internen BKU-Benutzer zur Zugriffsberechtigung auf das Bestellportal ist das konzerninterne Benutzermanagementsystem iMan zu verwenden.
## Authentifizierung
Damit nur zugangsberechtigte Benutzer das Bestellportal verwenden können, erfolgt die Authentifizierung (Prüfung von Benutzername und Passwort) für beide Benutzergruppen (DB Netz intern und extern) über eine Login-Seite des Bestellportals. Das Bestellportal prüft die Authentifizierung im Hintergrund mithilfe von LDAP im entsprechenden Active Directory. Für DB Netz interne Benutzer wird das BKU-Active Directory abgefragt, für DB Netz externe User wird das konzernweite DS-Active Directory abgefragt. (Active Directory Domain Services AD DS). Wegen der Trust-Beziehung von DS-AD zu BKU-AD, kann die Anmeldung auch in einem Aufruf erfolgen.
Die Anmelde-Maske wird im Bestellportal umgesetzt. Die Anmeldung am Bestellportal muss im Rahmen einer 2 Faktor-Authentifizierung möglich sein. Diese Funktionalität muss im Rahmen des Bestellportals umgesetzt werden, da eBRS dies aktuell nicht unterstützt.
## Autorisierung
Die zugeordneten generischen Rollen eines Benutzers (z.B. DB Netz Vertriebsmitarbeiter oder EVU-Trassenbesteller) werden durch einen LDAP-Zugriff auf das jeweils entsprechende Active Directory abgefragt. Für DB Netz interne BKU-User erfolgt die Abfrage gegen das BKU-Active Directory, wohin gegen für DB Netz externe Benutzer die Abfrage gegen das DS-Active Directory erfolgt.
Für DB Netz externe Benutzer kommt nach Ermittlung der generischen Rolle zusätzlich die Notwendigkeit hinzu, über den Service BenutzerBerechtigungZuordnung (BBZ) und dessen Operation leseBenutzerKontoBerechtigungZuordnungen mit dem Rückgabewert "Zugeordnete Kundennummern", die berechtigten Kundennummern abzufragen, wobei einem externen Benutzer pro Rolle (z.B. "Trassenanmeldung") mehrere Kundennummern zugeordnet sein können. Der Service BBZ kann nur eine Ebene von Berechtigungen parametrisieren, in diesem Fall sind dies die Kundennummern. Derzeit wird davon ausgegangen, dass diese Berechtigungsgranularität ausreichend für die Rechtevergabe im Bestellportal ist. Falls sich im Laufe des Projekts weitere Anforderungen hinsichtlich Berechtigungen ergeben sollten, so muss entweder der Service BBZ angepasst werden oder im Bestellportal eine eigene Berechtigungsverwaltung implementiert werden.
DB Netz interne Benutzer sind für alle Kundennummern lese- und schreibberechtigt. (vgl.  - Akteure Bestellportal).
## Kundenstammdaten
Die Abfrage der Kundenstammdaten aus dem CRM-System erfolgt gestaffelt in zwei Operationen mit dem Service Kundendatenverwaltung (KDV). 
Die Operation leseKunde liefert zu einer Kundennummer den entsprechenden Kunden (Geschäftseinheit). Das Bestellsystem nutzt insbesondere folgende Felder: Name des Kunden, CompanyID, kaufmännischeSperre, Telefonnummer+E-Mail+Faxnummer des zentralen Ansprechpartners beim Kunden. Alle Berechtigungen liegen im Verfahren eBRS (siehe oben) ab.
Relevant für das Bestellsystem sind neben dem Kundenname und der Adressinformationen insbesondere die Sperrvermerke (Kunde ist kaufmännisch gesperrt oder inaktiv). Um die Kundenstammdaten zu ermitteln, wird die Operation leseKunde nach einer erfolgreichen Anmeldung aufgerufen, die durch Übergabe einer Kundennummer die entsprechenden Kundenstammdaten zurück gibt. 
Das Bestellsystem muss ermöglichen, dass auch für kaufmännisch gesperrte Kunden Aufträge an die DB Netz AG übermittelt werden können. Das Bestellportal muss dem Bearbeiter vor Übergabe einer Bestellung an die DB Netz AG eine konfigurierbare Warnmeldung anzeigen:
- Die Warnmeldung könnte wie folgt ausgegeben werden: "Diese Kundennummer ist kaufmännisch gesperrt. Bitte beachten Sie, dass Sie für die Dauer der Sperre kein Angebot erhalten und Trassenbestellungen nicht bearbeitet werden."
- Kundensperre "Inaktiver Kunde" für inaktiv gesetzte Kunden: es können keine Aufträge an DB Netz gesandt werden.  
| | Service / Komponente | Beschreibung | Kommentar
| |
BBZ
leseBenutzerKontoBerechtigungZuordnungen |
Liefert alle Zuordnungen für einen Benutzer eines Mandanten. | optional kann auch nach einer bestimmten Rolle gefiltert werden
| |
KDV
leseKunde
leseAlleKunden |
Liefert zu einer gegebenen Kundennummer detaillierte Kundendaten zurück
Liefert eine Liste aller Kunden  |
leseAlleKunden ist relevant, falls sämtliche Kundendaten im Bestellsystem gecacht werden müssen. Ansonsten können einzelne Kunden-Sätze mit leseKunde abgefragt werden.
Kundendaten
Mehrere Kundennummer /Geschäftspartner referenzieren auf eine Hauptnummer (z.B. DB Regio). Die TAF/TAP Company_ID muss noch entsprechend in den Stammdaten eingepflegt werden. 
Annahme: im neu zu startenden Projekt "Neues CRM System" werden diese Daten erfasst und über den Service KDV zur Verfügung gestellt.
## Kundennummer 
Die Kunden-Nr. ist Ausdruck dafür, welcher Regionalbereich (Kundenmanagement) für die Betreuung der Kunden zuständig ist. Die Zuordnung von Kunden zu Benutzern wird vom Service KundenDatenVerwaltung (KDV) übernommen. Die Kundenstammdaten liegen im CRM-Systems der DB Netz, der Service KDV ermöglicht den Zugriff auf die Kundenstammdaten für andere Systeme (siehe Schnittstellenbeschreibung).  
Die Buchstaben der Kunden-Nr. sind nicht durchgehend belegt. Die Verwendung der Buchstaben der Kunden-Nr. erfolgt nach dem Sitz des jeweiligen Regionalbereiches
-
- BXXXX: Berlin, RB Ost
- DXXXX: Duisburg, RB West
- FXXXX: Frankfurt, RB Mitte
- HXXXX: Hannover, RB Nord
- KXXXX: Karlsruhe, RB Südwest
- LXXXX: Leipzig, RB Südost
- MXXXX: München, RB Süd
- ZXXXX: Zentrale
- CXXXX: besondere Kundengruppe "SCHWEIZ"
- RXXXX: RV-Kunden
## Kundendatenverwaltung (KDV) und BenutzerBerechtigungsZuordnungen (BBZ)
  
## Datenmodell                                                                                                                                          
Das CRM System wird alle für TAF/TAP- TSI benötigten kundenspezifische Stammdaten zukünftig enthalten. Die Kundendaten werden in jeder TAF/TAP Nachricht im Element "AdministrativeContactInformation" übertragen.
Es gibt bereits EU-weit standardisierte Bezeichner für das jeweilige EVU/EIU, die sogenannte CompanyID :
- Jedes EVU bzw. EIU muss über eine eigene CompanyID verfügen. Sofern das noch nicht der Fall ist, muss das EVU / EIU diese beantragen
- Die jeweils erforderliche CompanyID wird als bekannt vorausgesetzt
(nicht in der untenstehenden Ausprägungsliste enthalten)
- Die gültigen Ausprägungen sind in der "RNE Reference Database" hinterlegt und können per Service oder per Dateidownload abgeglichen werden
Die CompanyID ist wie folgt strukturiert:
- CompanyID Kodierung: 4 digits (UIC id of the owner of the path, RU UIC code in the RU Path, IM UIC code in the IM Path)
- Die DB Netz hat die CompanyID 0080
| |
I....AdministrativeContactInformation |
  |
Administrative
ContactInformation |
Kontaktinformationen des Absenders |
Hinweis: Die EVU-Organisationseinheit ist als nationaler Parameter auf Messageebene definiert
| |
I....I....Name |
AdministrativeContactInformation |
Name |
EVU / EIU: Name des Kunden
EVU / EIU: Name des geschäftsführenden Koordinators |
Muss immer angegeben werden
| |
I....I....Address |
AdministrativeContactInformation |
Address |
Postadresse des Absenders |
wird nicht verwendet
| |
I....I....eMail |
AdministrativeContactInformation |
eMail |
EVU / EIU:  Email-Adresse des Kunden
EVU / EIU:  Email-Adresse des geschäftsführenden Koordinators |
Muss immer angegeben werden
| |
I....I....PhoneNumber |
AdministrativeContactInformation |
PhoneNumber |
EVU / EIU:  Telefonnummer des Kunden
EVU / EIU: Telefonnummer des geschäftsführenden Koordinators |
Muss immer angegeben werden
| |
I....I....FaxNumber |
AdministrativeContactInformation |
FaxNumber |
EVU / EIU:  Faxnummer des Kunden
EVU / EIU:  Faxnummer des geschäftsführenden Koordinators |
Muss immer angegeben werden
| |
I....I....FreeTextField |
AdministrativeContactInformation |
FreeTextField |
Frei definierbarer Text |
 
## Verortung der Kundennummer
| |
kundenummerBestellendesEvu (NSP) |
Kundennummer des bestellenden EVU (im ResponsibleApplicant steht die zugehörige CompanyID)
| |
kundennummerDurchfuerendesEvu (NSP) |
Kundennummer des durchführenden EVU (ResponsibleRU steht die zugehörige CompanyID)
Eine Änderung der Kundennummer in nachfolgenden Bezugsgeschäftsvorfällen ist nur durch "Abmeldung" bzw. "Stornierung" und anschließender erneuerter "Erstanmeldung" mit geänderter Kundennummer möglich. Die Kundennummer ist in einem Feld NSP "Kundennummer bestellendes EVU" bzw. "Kundennummer durchführendes EVU", das sich in der TAF/TAP Messagestruktur auf Ebene PathInformation->PlannedJourneyLocation befindet, pro Zuglaufpunkt anzugeben (siehe TAF/TAP TSI Kundendaten).
## Nichtfunktionale Aspekte BBZ
| |
Vertraulichkeit |
11
incomplete
 sehr hoch
12
incomplete
 hoch
13
complete
 mittel
14
incomplete
 niedrig
| |
Integrität |
15
incomplete
 sehr hoch
16
incomplete
 hoch
17
complete
 mittel
18
incomplete
 niedrig
 
 
| |
Verfügbarkeit
| |
Servicelevel* |
31
incomplete
 SL 1 Plus
32
incomplete
 SL 1
33
incomplete
 SL 1 Basic
34
incomplete
 SL 2
35
incomplete
 SL 3 Plus
36
complete
 SL 3
|
Aktueller Service Level der BBZ: SL3, eine Erhöhung des Service Levels ist anzustreben
  |
| |
Logging
| |
Anforderung an Logging* |
Nicht bekannt
  |
| |
Übertragungsverfahren
| |
Schnittstellenart* |
37
incomplete
 Datenablage in Datei, Pfad: manuelle Festlegung
38
complete
 Webservice: 
39
incomplete
 SMS-Nachricht, Nummer:
48
incomplete
 gemeinsame Datenbank:
41
incomplete
 Online-Transaktion:
42
incomplete
 Andere: Dateiversand via Email
| |
Transaktionssicherheit* |
 Keine Anforderungen.
 Folgende Anforderungen:
| |
Art der Datenübertragung |
 HTTP(S)
## Nichtfunktionale Aspekte KDV
| |
Vertraulichkeit |
97
incomplete
 sehr hoch
98
complete
 hoch
99
incomplete
 mittel
100
incomplete
 niedrig
| |
Integrität |
101
incomplete
 sehr hoch
102
incomplete
 hoch
103
complete
 mittel
104
incomplete
 niedrig
 
 
| |
Verfügbarkeit
| |
Servicelevel* |
105
incomplete
 SL 1 Plus
106
incomplete
 SL 1
107
incomplete
 SL 1 Basic
108
incomplete
 SL 2
109
incomplete
 SL 3 Plus
110
complete
 SL 3
|
Aktueller Servicelevel des KDV: SL3, von daher ist ein Caching der Daten über die KDV-Operation leseAlleKunden im Bestellsystem zu empfehlen.
- Antwortzeiten für leseKunde < 1 Sekunde (Datenvolumen Größenordnung < 50k)
- Antwortzeiten für leseAlleKunden < 5 Sekunden (ca. 3 MB Datenvolumen)
  |
| |
Logging
| |
Anforderung an Logging* |
 Ein Monitoring der kaufmännisch relevanten Vorgänge ist erforderlich
  |
| |
Übertragungsverfahren
| |
Schnittstellenart* |
111
incomplete
 Datenablage in Datei, Pfad: manuelle Festlegung
112
complete
 Webservice: 
113
incomplete
 SMS-Nachricht, Nummer:
114
incomplete
 gemeinsame Datenbank:
115
incomplete
 Online-Transaktion:
116
incomplete
 Andere: Dateiversand via Email
| |
Transaktionssicherheit* |
 Keine Anforderungen.
 Folgende Anforderungen:
| |
Art der Datenübertragung |
 HTTP(S)
bahn/project-audit/data/confluence-export/pages/27525686_6.7 SAPBINe und Netzmonitor Nemo.md
+38
View File
@@ -0,0 +1,38 @@
# 6.7 SAPBINe und Netzmonitor (Nemo)
> Confluence Page ID: 27525686
> Version: 25
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.7 SAPBINe und Netzmonitor (Nemo)
> Labels:
---
TPN stellt dem System Netzmonitor (Nemo) und SAPBine über zwei verschiedene Schnittstellen täglich ein aktuelles Datendelta aus der TPN-Datenbasis zur Verfügung. 
|
| |
Bereitstellendes System
| |
Name* |
TPN
| |
Anwendungs-ID (lt. BEAM) |
A-101 488
| |
Einführung mit Version |
TPN Release 8.9.5 / August 2018 Release - Netzmonitor
TPN Release 8.3.0 - SAPBine
| |
Organisatorische Verantwortung* |
Fachliche Betriebsführung TPN
| |
Neu oder Ersatz für/durch* |
Neue Schnittstelle
| |
Technische Betriebsführung |
Verfahrensbetriebsführung TPN
 
Die beiden nachfolgenden Schnittstellenkontextdiagramme zeigen die miteinander interagierenden Systeme TPN - SAPBI und TPN- NEMo sowie den Akteur. 
 
 
Die aktuelle Schnittstellenbeschreibung TPN - SAPBI und TPN- Netzmonitor befindet sich im Sharepoint.
bahn/project-audit/data/confluence-export/pages/27525688-2019-03-11 Fachliche Klaerung zum Thema Common Interface TAF-TAP.md
+118
View File
@@ -0,0 +1,118 @@
# 2019-03-11 Fachliche Klärung zum Thema Common Interface TAF/TAP
> Confluence Page ID: 27525688
> Version: 1
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-03-11 Fachliche Klärung zum Thema Common Interface TAF/TAP
> Labels:
---
 Besprechungsprotokoll vom 11.03.19
Abstimmung über die Technische TAF/TAP Schnittstelle für Fahrplan (/Vertrieb) und Betrieb
 
| | Teilnehmer:
| |
Wolfgang Kuzaj, NMF 11
Benjamin Schmücker, NMK 3(I)
Jens Miehlnickel, NMK 3(I)
Richard Berger, NVI 2 
Jürgen Sievers, NVI  2(A) 
Bettina Kranz, NVI 2(A)
Dr. Patrick Breun, NMF 11Andreas Haase, IPI
| |
Verteiler:
TeilnehmerInnen, sowieAndreas A Schumann, NPB 3(P)Ralph Grassel, NMK   
Holger Duis, NVI 2(A)   
Bernd Völlmeke, NPB 3(Z)
Lydia Weitershagen, NVI 2(A)  
Holm Zickermann, FIB VS
Martin Kiderle, NPB 3(P)   
Lars Ladouceur, NPB 3(P)   
Julian Holzner, NMF 11   
Henning Henke,NMF 2   
Sebastian Hassemer, NVI 31 
Erstellt von: Bettina Kranz
| | Ort/Zeit:
| |
Frankfurt, Weilburger Str. 22
11.03.19, 10.00 – 12:00Uhr
|
| | Nr. | Inhalte/Maßnahmen | Zuständig | Termin | Status
| | Agendapunkt: Fachliche Gründe, die für eine gemeinsame Schnittstelle sprechen
| |  1.           |  Die Teilnehmergruppen stellen jeweils aus ihrer Sicht die Vorteile eines Common Interface dar. |  Alle |
| I
| | Agendapunkt: Fachliche Gründe, die gegen eine gemeinsame Schnittstelle sprechen
| |  2.       
  |  Die Teilnehmergruppen stellen jeweils aus ihrer Sicht die Nachteile eines Common Interface dar. | Alle |
| I
 
| | Agendapunkt: Sicht der Enterprise Architektur
| |  3.       
    |  Die Sicht der Enterprise Architektur ist, dass alle Zielgruppen des Kunden konsistent mit den benötigten Geschäftsobjekten über alle Prozesse hinweg von der DB Netz beauskunftet werden sollen (360° Sicht auf den Kunden). | Sievers |
| I
| | Agendapunkt: Diskussion
| |  4.       
    | Es ist zu ermittelt, in welchem Umfang es der Wunsch der EVU ist, eine Schnittstelle zu haben, und ob die Kunden dieses Vorhaben der DB Netz unterstützen. Dabei sind insbesondere die entstehenden Kosten und Aufwände auf der Kundenseite sowie die Vor- und Nachteile für den Kunden zu ermitteln und zu bewerten.  | Kuzaj
  |
  | I
 
| |  5.       
    | Es istaktuell nicht geklärt, welcher Aufwand inklusive Kosten einem eventuellen, noch nicht ermittelten und erkennbaren Nutzen für die Bereiche Fahrplan und Betrieb gegenübergestellt werden kann. Diese Aufwands-/Nutzenbetrachtung mussaber Basis für die Entscheidung sein. | Kuzaj
  |
 
  | I
 
| |  6.       
    | Es besteht ein Problem der Dateninkonsistenz, welches nicht über eine gemeinsame Schnittstelle gelöst werden kann.  Die fachliche Inkonsistenz resultiert aus den Prozessen und muss aufgrund der Betriebslage auch so sein. Die Datensicht kann sich mehrfach im Prozessverlauf ändern. | Kuzaj
  |
  | I
| |  7.         | Aus Sicht der Fachbereiche müsste an Stelle einer gemeinsamen Schnittstelle eher an den Prozessen oder an der Transparenz in Richtung Kunde gearbeitet werden. | Fachbereiche
  |
| I
| |  8.        | Die Herstellung der internen Datenkonsistenz ist aktuell bereits im Scope von FIB. |
|
| I
| |  9.       
    | Es gibt keine Nachrichten/Meldungen auf Kundenseite, bei denen der Kunde nicht weiß, an wen er diese adressieren soll. Daher wird aktuell keine Notwendigkeit gesehen, nur eine fachliche Schnittstelle anzubieten.  Es ist im Gegenteil sogar wünschenswert, dass der Kunde entscheiden kann, an wen er die Nachricht senden möchte. | Fachbereiche
  |
  | I
| |  10.      
  |
Fachlich bleiben es zwei getrennte Kanäle, technisch kann zu einem späteren Zeitpunkt noch entschieden werden, ob diese zusammengeführt werden können um nach außen eine oder zwei Schnittstellen anbieten zu können.
Es muss noch entschieden werden, ob und unter welchen Anforderungen diese zusammengeführt werden soll. |  Alle
  |
 
 
  | B
 
| |  11.      
  | Die einzelnen Projekte werden nun zunächst jeweils ihre eigenen Schnittstellen nach den TAF/TAP Vorgaben und NfA spezifizieren und umsetzen. | Fachbereiche |   | A
| |  12.      
  | Aus Sicht der Enterprise Architektur soll das Ziel weiterverfolgt werden, eine gemeinsame technische Schnittstelle zu bauen, welche eine URL für den Kunden anbietet und zum Beispiel über einen Proxy die Nachrichtenverteilung steuert.
Der Vorschlag ist, zunächst mit zwei getrennten fachlichen Schnittstellen zu starten und ggf. später an einer gemeinsamen Schnittstelle zu arbeiten. | Sievers
  |
 
   | I
 
| | 13.        | Es muss nun evaluiert werden, wo die Entscheidungspunkte eine oder zwei technische Schnittstellen liegen. Hierbei muss sichergestellt sein, dass keine negativen Wechselwirkungen aus nicht koordinierbaren Lastspitzen der beiden Kanäle resultieren. | Sievers
  |
  |
A
| |  14.      
  | Falls in Punkt 11 die Umsetzung einer gemeinsamen Schnittstelle beschlossen wird, muss geklärt werden, welches Projekt die Kosten für die technische Schnittstelle trägt. | Sievers
  |
  | A
Anhang: Protokoll mit Workshop-Präsentation
250
bahn/project-audit/data/confluence-export/pages/27525692_6.2.1.1 Technische Schnittstellenspezifikation TPPuE.md
+14
View File
@@ -0,0 +1,14 @@
# 6.2.1.1 Technische Schnittstellenspezifikation TPPuE
> Confluence Page ID: 27525692
> Version: 26
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan/6.2.1 Business Service TrassenProduktPruefenUndErgaenzen (BEP) und Routensuche/6.2.1.1 Technische Schnittstellenspezifikation TPPuE
> Labels:
---
Der Service "Trassenprodukt prüfen und ergänzen" ist der fachlichen Domäne: „Kapazitäts-und Fahrplanmanagement“  zugeordnet und dort in der Komponente „Trassenmanagement“ verortet. 
## Die Technische Schnittstellenspezifikation TPPuE 
Link
https://wiki.intranet.deutschebahn.com/wiki/display/neXtlab/Operationen+des+BEP+SOAP+Service oder Technische Schnittstellenbeschreibung TPPuE
bahn/project-audit/data/confluence-export/pages/27525694_4.4.1 Anbindung Abrechnungssysteme an das Bestellsystem.md
+339
View File
@@ -0,0 +1,339 @@
# 4.4.1 Anbindung Abrechnungssysteme an das Bestellsystem
> Confluence Page ID: 27525694
> Version: 105
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.1 Anbindung Abrechnungssysteme an das Bestellsystem
> Labels:
---
## Einleitung 
Im Verkaufsprozess von Trassenprodukten muss sowohl eine Anbindung an das dem Vertrieb zugeordnete Preissystem, als auch an die kaufmännische Abrechnung erfolgen. Um dies zu ermöglichen werden die notwendigen Schnittstellen, welche im parallel laufenden Projekt AbrechnungsCookpit (AC) Trasse umgesetzt werden, angebunden. Das Projekt AC Trasse soll in 2021 produktiv gehen.
## Ausschnitt aus dem Systemkontext des Bestellsystems
Die Anbindung der kaufmännischen Systeme- Abrechnung an das Bestellsystem bildet eine umfangreiche Schnittstellensammlung. Im Folgenden zur Übersicht ein Ausschnitt aus dem Systemkontext des im EAM hinterlegten Architekturartefakts  
## Prozessuale und dynamische Sicht auf die Schnittstelle Bestellsystem und AbrechnungsCockpit
Im Folgenden eine vereinfachte Darstellung des gesamten Prozesses, der über das Bestellsystem abgewickelt wird. In dieser Darstellung ist dokumentiert, in welchem Prozessschritt welche Funktionalität der Abrechnungs- und Preissysteme aufgerufen werden sollen.
Verständnis des Prozessablaufs vor dem Hintergrund Abrechnung und zukünftige Anbindung von BP mit AC
|
| |
##  Service/Komponente  
|
##   Kurzbeschreibung
|
## Kommentar
| |
Service PreisVerwaltungTrasse
ermittleTrassenPreis
|
Es wird zu einer vom Fahrplan zurückgelieferten FahrplanKapazität (TAF/TAP TSI: PathDetailsMessage) eine verbindlicher Angebotspreis ermittelt.
Das zurückgegebene Objekt Preisauskunft liefert den Preis für eine Trasse und auch den Link zu einer generierte Leistungsbeschreibung (LB) im PDF Format welche im LB Portal abliegt.
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. | Die in der Schnittstelle definierte Zugtrasse muss durch das Bestellsystem über die Fahrplankapazität befüllt werden
| |
Service PreisVerwaltungTrasse
ermittleTrassenPreisInfo |
In diesem Kontext fragt das Bestellsystem unverbindliche Preisanfragen ab, um im Planungsprozess dem Kunden bei der Suche einer geeigneten Route als Information einen unverbindlichen Preis anzuzeigen.
Das zurückgegebene Objekt Preisauskunft liefert den Preis für die übergebene Trasse.
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. | Die in der Schnittstelle definierte Zugtrasse muss durch das Bestellsystem über die Fahrplankapazität befüllt werden
| |
Service AufbereitungAbrechnungsInformationenTrassen
abrechneVertragsAenderung |
Änderungen einer Bestellung nach Abschluss eines Trassenvertrags müssen im Abrechnungssystem nachgehalten werden. Dies geschieht über den Service abrechneVertragsAenderung.
Änderungen können vom Kunden oder von der DB Netz ausgelöst worden sein. In jedem Fall muss sichergestellt werden, dass dieser Service vom Bestellsystem aufgerufen wird.
Auch bei Gewährung von Rabatten (NeuverkehrsRabatte) wird dieser Service nach der Genehmigung im OrderDiscountOrderSystem aufgerufen.
Der Rabatt wird nachträglich auf den bereits zum Listenpreis abgeschlossenen Vertrag gewährt. Dieser Service erstellt erzeugt eine aktualisierte LB und liefert einen entsprechenden Link zurück.
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. |
Die in der Schnittstelle definierte Zugtrasse muss durch das Bestellsystem über die Fahrplankapazität befüllt werden
LB = Leistungsbeschreibung
| |
Service
KaufmaennischeAuftragsverwaltung
erstelleAngebotsAnfrage
erstelleVertragsAngebot
erstelleProduktVertrag |
Der Service  bildet die Schnittstelle zu SAP R/3 Netz. Der Service erwartet einen Beleg, der Belegpositionen enthält (ITOM).
Eine Belegposition kann eine AngebotsAnfrage, VertragsAngebot oder ProduktVertrag enthalten.
Die Belegposition benötigt eine Beschreibung (Text) und den dazugehörigen Preis.
Zurückgeliefert wird im Erfolgsfall wieder ein Beleg. Im Erfolgsfall werden BelegAnhänge generiert, die über den Service BelegAnhangArchiv ausgelesen werden können.
Bei den "Erstellen" Operationen ist die BelegID bei Übergabe an die Operation noch nicht gefüllt, erst bei Rückgabe des Belegs durch die ausgeführte Operation wird dieser zurückgesendet.
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen. |
Das im Beleg referenzierte eigentliche Trassenprodukt wird im Service nicht verwendet,
insofern kann hier ohne Change Request auch ein TAF/TAP Objekt mit übergeben werden (Any Tag).
| |
Service
KaufmaennischeAuftragsverwaltung
aendereAngebotsAnfrage
aendereVertragsAngebot
aendereProduktVertrag |
Der Service  bildet die Schnittstelle zu SAP R/3 Netz. Der Service erwartet einen Beleg, der Belegpositionen enthält (ITOM).
Eine Belegposition kann eine AngebotsAnfrage, VertragsAngebot oder ProduktVertrag enthalten. Die Belegposition benötigt eine Beschreibung (Text) und den dazugehörigen Preis.
Zurückgeliefert wird im Erfolgsfall wieder ein Beleg.
Im Erfolgsfall werden BelegAnhänge generiert, die über den Service BelegAnhangArchiv ausgelesen werden können.
Bei den "Aendere" Operationen muss die BelegID bei Übergabe an die Operation gefüllt werden, erst bei Rückgabe des Belegs durch die ausgeführte Operation wird dieser zurückgesendet.
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen.
|
Das im Beleg referenzierte eigentliche Trassenprodukt wird im Service nicht verwendet,
insofern kann hier ohne Change Request auch ein TAF/TAP Objekt mit übergeben werden (Any Tag).
| |
Service
KaufmaennischeAuftragsverwaltung
beendeBeleg |
Der Service  bildet die Schnittstelle zu SAP R/3 Netz. Der Service erwartet eine BelegID. Fachlich bedeutet dies, dass ein Beleg storniert wird.
Die Serviceoperation wird aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen.
|
| |
Service BelegAnhangArchiv
leseBelegAnhang
erstelleBelegAnhang |
Der Basic Service archiviert Dokumente der KundenAuftragsVerwaltung im Archiv (DoxIs/BCM). 
Der Link auf das Archiv wird im eigentlichen Beleg aus der kaufmännischen Auftragsverwaltung hinterlegt.
Das Speichern von BelegAnhängen muss vom Bestellsystem ausgehen.
Das Bestellsystem erstellt ein PDF jeder Anfrage, jeden Angebots und jeden Vertrags und speichert dieses über erstelleBelegAnhang.
Die Serviceoperationen werden aus der Komponente SteuerungVertriebsablauf des Bestellsystems heraus aufgerufen.
|
| | Schnittstelle DiscountOrderSystem |
Das Discount Order System ist eine Webapplikation, welche in das Abrechnungscockpit integriert ist und Anträge zur Neuverkehrsrabatten verwaltet.
Ein Kunde kann Neuverkehrsrabatte geltend machen. Eine Entsprechende Anfrage auf Genehmigung wird an das Discount Order System (DOS) übertragen.
Nach der Genehmigung muss es eine Rückmeldung an das Bestellsystem geben und die Änderungsbepreisung muss an den Service AufbereitungAbrechnungsInformationenTrassen
der Abrechnung übermittelt werden. | Schnittstelle ist seitens AbrechnungsCockpit noch nicht definiert.
| |
SteuerungVertriebsAblauf
(KundenauftragsVerwaltung) |
Die Komponente SteuerungVertriebsAblauf (ehemals KundenauftragsVerwaltung) steuert zukünftig den vertrieblichen Prozess für Trassen, Serviceeinrichtungen und Stationshalten.
Von hier werden die entsprechenden Produktspezifischen Services des Fahrplans, S&S etc aufgerufen und auch die kaufmännische Abwicklung angestoßen. |
| |
SAP R/3 Netz   |
Kaufmännisches Back-End System SAP R/3 Netz, das zur Abrechnung und revisionssicheren Archivierung verwendet wird.  
Abrechnung und revisionssichere Archivierung, SAP Hybris Billing in der Abbildung und hier SAP R3/Netz |
| | Link auf Rechnungsportal |
Sharepointanwendung zur Ablage der detaillierten Rechnung zu Trassenverträgen als PDF |
| | Link auf LB (Leistungsbeschreibung) |
Sharepointanwendung zur Ablage der detaillierten Preisaufstellung zu Trassenangeboten als PDF
Diskriminierungsfreie Veröffentlichung (Hinweis: Bei der Ablehnung bleibt die LB im Portal. Die Preisberechnung erfolgt zeitlich mit dem Angebotsversand.
Folglich können alle LBs auf dem LB-Portal Veröffentlicht werden. Im GelV- nach der Konstruktion wird LB freigegeben.
Im Netzfahrplan- Vorläufig VNP; Entgültig ENP - in beiden Fällen wird LB freigegeben.
Die im LB-Portal abgelegte Leistungsbeschreibung zum Trassenangebot darf erst sichtbar werden, wenn das Angebot an den Kunden versendet wird! |
| | Veröffentlichung der LB | ein Service wird bei der AC Trasse benötigt, um die Veröffentlichung von Leistungsbeschreibungen zu Netzfahrplanangeboten zu triggern   | noch nicht spezifiziert durch AC Trasse
| | AC Service Zuordnung in die Trassenproduktsegmenten -------------- |
Anhand der relevanten Anmeldekriterien im Bestellsystem wird eine Zuordnung in die Trassenproduktsegmenten
selbst in der AC Trasse (Trassenpreissystem) des dann geltenden Trassenpreissystems angezeigt  ()
- Anhand der relevanten Anmeldekriterien wird eine Zuordnung in die Trassenproduktsegmente des dann geltenden Trassenpreissystems angezeigt
- Das Preissystem unterscheidet grundsätzlich zwischen Güterverkehr und Personenverkehr
- Weitere Merkmale sind aktuell beispielsweise Zuggewicht, Zuglänge, (konstruierte) Durchschnittsgeschwindigkeit, Regionalität (Stichwort Metropolverkehre) und weitere Determinanten
- Die Produktdeterminaten können sich bis zur Produktivsetzung noch ändern > Grundsätzlich müssen die Produktzuordnungen
soweit wie möglich konfigurierbar und erweiterbar sein, um auf periodische Anpassungen der Produktgestaltung reagieren zu können
(die nächste Definition wird für das FplJ 2023 vorgenommen)  | noch nicht spezifiziert durch AC Trasse
| | Neue Anforderung wird noch durch AC Trasse spezifiziert |
Bei neuen Kunden oder bei Kunden mit Zahlungsausfällen bzw. drohender Insolvenz muss der Kunde Vorkasse leisten.
Aktuell gibt es keine Integration zwischen dem Vorkasse-Prozess und dem Abschluss eines Vertrags. Angedacht ist
bspw. das dem Kunden ein Angebot unterbreitet wird, aber der Vertrag erst dann abgeschlossen wird, wenn Vorkasse-Zahlungen eingegangen sind.  | (P0) Pe Null Projekt: To Do: AC Trasse
## Sicht auf die Schnittstellen im Verkaufsprozesses (inklusive Preisauskunft und Preisinformation)
Nachfolgend eine Zusammenfassung der Services und deren Operationen, die aus der Komponente SteuerungVertriebsablauf des neuen Bestellsystems heraus aufgerufen werden.
                                                              
## Nichtfunktionale Aspekte
| |
Vertraulichkeit |
11
incomplete
 sehr hoch
12
complete
 hoch
13
incomplete
 mittel
14
incomplete
 niedrig
| |
Integrität |
15
incomplete
 sehr hoch
16
complete
 hoch
17
incomplete
 mittel
18
incomplete
 niedrig
 
 
| |
Verfügbarkeit
| |
Servicelevel |
31
incomplete
 SL 1 Plus
32
incomplete
 SL 1
33
complete
 SL 1 Basic
34
incomplete
 SL 2
35
incomplete
 SL 3 Plus
36
incomplete
 SL 3
|
die Verfügbarkeit des AC-Services PreisVerwaltungTrasse mit SL3 ist nicht ausreichend
JP: Antwortzeiten werden unter 2 Sekunden sein, perspektivisch auch schneller. Durch das Auto-Scaling sollten AC überhaupt kein Problem mit den Peak-Lasten haben.
Bzgl. der Verfügbarkeit der Services hat der Fachbereich SL 3 angefordert.
  |
| |
Logging
| |
Anforderung an Logging |
 Ein Monitoring der kaufmännisch relevanten Vorgänge ist erforderlich
  |
| |
Übertragungsverfahren
| |
Schnittstellenart |
37
incomplete
 Datenablage in Datei, Pfad: manuelle Festlegung
38
complete
 Webservice: 
39
incomplete
 SMS-Nachricht, Nummer:
40
incomplete
 gemeinsame Datenbank:
41
incomplete
 Online-Transaktion:
42
incomplete
 Andere: Dateiversand via Email
| |
Transaktionssicherheit |
 Keine Anforderungen.
 Folgende Anforderungen:
| |
Art der Datenübertragung |
 HTTP(S)
                                   
## Datenmodell
Für die Preisberechnung/Abrechnung werden folgende Informationen aus dem Bestellsystem benötigen. Datenfelder AC-Bestellsystem TAF. Das vorhandene Datenmodell des AC Trasse beinhaltet ein ITOM nahes Modell vom Objekt ZugTrasse (siehe aktuelle Servicebeschreibungen). Ein Mapping des TAF/TAP Modells auf die ZugTrasse ist geplant.
Hinweis: Die Preise werden im TAF/TAP Objekt in den Attributen NetworkSpecificParameters hinterlegt, da diese keine TAF/TAP Standarddatenfelder darstellen.
## Attribute der Struktur „NetworkSpecificParameter“ auf Message-Ebene
(Extrahiert aus der Anlage 1 der EVU-SST)
 
| | Trassenpreis | Trassenpreis in Euro [€] |
|
1.  Das Feld enthält den Gesamtpreis der Trasse in Euro.
2.  Der Preis wird mit zwei Nachkommastellen geliefert.
3.  Wird nicht bei den Ausprägungen des Feldes <geschaeftsvorfallTyp> 19 (Zurückweisung), 35  (nicht konstruierbare Trasse) und bei RV-Kapazitätsangeboten und Ergebnissen der Produkte FZB und FPS geliefert.
| |
| PreisInformationen |
|
| |
  |
PreisInformationenZLP |
  |
 
| |
NV_IM |
Intermodal gewonnener Neuverkehr |
I....I....I....nvIm |
NetworkSpecificParameter
| |
NV_BIS |
Neuverkehr (ab ZLP) bis ZLP |
I....I....I....nvBis |
NetworkSpecificParameter
| |
NV_NUMMER |
Von DB Netz vergebene Nummer für bestätigten Neuverkehr |
Siehe |
https://ciodbn.noncd.rz.db.de/websites/MMO/Projekte/neXt_APluS/Value%20Stream/02%20Workshops/TAF%20TAP%20TSI/02%20Termine/Austausch%20M31%20Bestellportal/20181203%20NetworkSpecificParameter_%C3%9Cbersicht%20v06.xlsx
      Â
bahn/project-audit/data/confluence-export/pages/27525695-6.8 Verwaltungsunterstuetzende Services KDV und eBRS.md
+116
View File
@@ -0,0 +1,116 @@
# 6.8 Verwaltungsunterstützende Services (KDV & eBRS)
> Confluence Page ID: 27525695
> Version: 25
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.8 Verwaltungsunterstützende Services (KDV & eBRS)
> Labels:
---
6.8.1 Externe Benutzerverwaltung (eBRS)
eBRS steht als System für "externer Benutzer und Rollen Service" mit dem Funktionsumfang einer Benutzerverwaltung, die über ein PowerUser-Konzept von den EVU-Usern selbst bedient wird.
Die manuelle und verfahrensspezifische Pflege von Benutzern im Active Directory ist mühsam. Das Verfahren eBRS erleichtert dies durch automatische Prozesse. Auch der administrative Aufwand für DB Netz Mitarbeiter wird dadurch erleichtert, dass die Pflege der eigenen Mitarbeiter an die EVUs und EIUs selbst ausgelagert wird.
Pro EVU gibt es so genannte "PowerUser", die das Benutzermanagement für ihr eigenes EVU übernehmen. Neue Benutzer werden von ihren PowerUsern eingeladen, sich für eBRS bzw. myNet zu registrieren. Der PowerUser gibt hierfür lediglich eine E-Mailadresse ein.
Der Benutzer erhält dann einen Registrierungslink und kann sich registrieren. Hier wird er aufgefordert, folgende Informationen auszufüllen:
- Pflichtfelder
- Anrede (Herr/Frau)
- Vorname
- Nachname
- Passwort
- Optionale Felder
- Titel (Prof. / Dr.)
- Straße und Hausnummer
- PLZ
- Ort
- Land
- Telefonnummer
Weitere Felder (etwa Fax, Initialen) sind derzeit nicht in eBRS vorgesehen und werden zur Zeit daher nicht im AD gespeichert.
Folgende Namenskonvention wird für Benutzernamen im DS-AD verwendet: DS\[Erste Buchstabe des Vornamen].[Nachname][ggf. Nummer]
Zum Beispiel würde Johann-Wolfgang Goethe folgenden Benutzernamen bekommen: j.goethe
Zusätzlich sind folgende Regeln zu beachten:
- Die Sonderzeichen ä, ö, ü und ß werden in ae, ou, ue, ss konvertiert.
- Andere Sonderzeichen (wie è, à, …) werden bei der Eingabe blockiert.
- Nur folgende Zeichen sind bei der Eingabe des Vor- und Nachnamens auf der UI zulässig:
-
- a-z
- A-Z
- üÜöÖäÄ
- -
- ß (groß und klein)
- Leerzeichen
Bindestriche und Leerzeichen werden bei der Berechnung des Benutzernamens ignoriert (entfernt), sowohl bei Vor- als auch bei Nachnamen. Bei der Generierung der Benutzernamen werden nur Kleinbuchstaben verwendet.
 
Wenn ein Benutzerkonto mit dem gleichen Namen bereits besteht, dann wird hochgezählt. Das heißt zum Beispiel:
- Johann-Wolfgang Goethe bekommt den Benutzernamen j.goethe
- Johannes Goethe bekommt dann den Benutzernamen j.goethe1
Die maximale Anzahl von Buchstaben für Vornamenbuchstaben + . + Nachname beträgt 20 Zeichen. Denn aus Kompatibilitätsgründen erlaubt das AD maximal 20 Zeichen für den „SamAccountName“.
Sollte der Nachname zu lange sein, wird dieser automatisch gekürzt, zum Beispiel: Johannes Mustermannbeispielname wird zu j.mustermannbeispiel
Die Hochzählung funktioniert folgendermaßen:
Der erste Benutzer bekommt seinen Benutzernamen mit maximal 20 Zeichen zugeteilt. Der nächste, der den gleichen Benutzernamen bekommen würde, bekommt diesen Namen mit einer 1 im Anschluss. Der nächste bekommt eine 2 usw. Es werden keine redundanten Nullen verwendet, das heißt 1,2,3,4,5,6,7,8,9,10,11, 12… und nicht 01,02,03,04,05,06,07,08,09,10,…
Die Höchstmögliche Zahl beträgt 9999.
Sollte der Benutzername mit Zahl länger als 20 Zeichen sein, wird der Nachname um die entsprechende Zeichenzahl gekürzt.
Beispiele:
- j.mustermannbeispiel
- j.mustermannbeispie1
- j.mustermannbeispie#
- j.mustermannbeispi10
- j.mustermannbeispi##
- j.mustermannbeisp100
- j.mustermannbeisp###
- j.mustermannbeis1000
- j.mustermannbeis####
- j.mustermannbeis9999
Nachfolgendes Systemkontext-Diagramm beschreibt das eBRS-System aus architektonischer Sicht:
Die eBRS-Oberfläche (erreichbar über F5 und in der oberen Hälfte des Diagramms abgebildet) ist lediglich für die Pflege der Berechtigungen durch berechtigte Anwender (u.a. PowerUser) bestimmt. Die Anwendungen im Backend (z.B. Bestellsystem, Click&Ride) können direkt mit dem AD bzw. dem Service BBZ kommunizieren, um die Benutzerkonten bzw. die relevanten Rechte abzufragen.
Die externen Benutzerkonten liegen in der Active Directory Domäne ds.db.de. Hier besteht ein einseitiger Trust zur BKU-Domäne (DS vertraut BKU, aber BKU vertraut DS nicht).
Folgende Informationen sind für die Anbindung an das Active Directory wichtig:
- Host: ds.db.de
- Port: 389
- LDAP Root-Pfad: OU=MyNet,OU=Verfahren,DC=ds,DC=db,DC=de
- Darunter gibt es umgebungsspezifische OUs, worunter wiederum die Benutzer liegen. Die Struktur sieht folgendermaßen aus:
- MyNet (OU, siehe Root-Pfad oben)
- TU (OU)
- User (OU)
- Groups (OU)
- AU (OU)
- User (OU)
- Groups (OU)
- PU (OU)
- User (OU)
- Groups (OU)
- Zugriff: Da es sich um Active Directory handelt, braucht man für den lesenden Zugriff keine besonderen Rechte. Jeder Benutzer, der sich in dem AD authentifizieren kann, kann auch dort lesen.
- Sofern einem Benutzer eine bestimmte Rolle zugewiesen wird, wird er in der entsprechenden AD-Gruppe aufgenommen.
- Dabei ist die Zuordnung an Kundennummern nicht abgedeckt, da dies in der BBZ geregelt wird. Die AD-Gruppenzugehörigkeit kann aber insofern hilfreich sein, damit jeder, der überhaupt eine Rolle besitzt (z.B. Trassenbestellung), sich in einer Anwendung anmelden kann und die Startseite sieht. So ist die Erstanmeldung performanter und die Zuordnung zu Kundennummern kann später abgefragt werden.
- Folgende AD-Gruppen wurden definiert. Hier ist das "XX" entsprechend durch TU, AU oder PU zu ersetzen. Die Gruppen können in der o.g. OU-Struktur gefunden werden.
- gm-eBRS-XX-PowerUser
- gm-eBRS-XX-Trassenbestellung
- gm-eBRS-XX-Anlagenbestellung
- gm-eBRS-XX-BetriebDisposition
- gm-eBRS-XX-InfrastrukturBauplanung
- gm-eBRS-XX-Abrechnung
- gm-eBRS-XX-Vertrag
- gm-eBRS-XX-NebenleistungenKlein
- gm-eBRS-XX-NebenleistungenGross
- gm-eBRS-XX-Zusatzleistungen
- gm-eBRS-XX-Aufgabentraeger
- gm-eBRS-XX-AlleRollen (Parent-Gruppe: enthält alle o.g. Rollen)
- Zertifikate
- Für .NET Anwendungen sollten die Zertifikate automatisch gezogen werden. Für andere Anwendungen wurden folgende Kenntnisse aus dem Projekt Click&Ride (CnR) gesammelt:
- Die AD Server (Berlin/Frankfurt) haben PK-Zertifikate, welche mit einem der DB Root CA Zertifikaten (DB Root CA 1, ‎Sonntag, ‎21. ‎November ‎2027 17:21:47) signiert wurden.
- In der Regel werden DB Zertifikate mit einem der DB Trust Center Zertifikaten signiert.
- Das entsprechende DB Root CA Zertifikat war - zumindest in der aktuellen - SDE/SDC Installation (=Zertifikate in security/cacerts der Entwickler- JVM) nicht enthalten. In den Browsern etc. werden die z.B. aber schon verteilt.
- In CnR wurde nun ein eigener Truststore angelegt (hat aber vor Allem mit Spring/Docker/AWS zu tun) und das entsprechende DB Root CA Zertifikat dort zur Verifizierung der AD Zertifikate hinterlegt.
- Das DB Root CA bekommt man aus dem Browser oder per Open SSL
- Username und Passwort (Credentials, die gegen das AD verifiziert werden sollen) müssen nicht codiert werden; dies erfolgt mit SSL/TLS. Das jeweilige Kryptoverfahren handeln Client und Server immer vor Beginn der Übertragung aus.
Über den Service BBZ werden die Zuordnung von Benutzerdaten (Benutzername) zu Kundennummern und berechtigte Rolle (für Bestellsystem: "Trassenbestellung") bezogen. Dieser Service ist mittels SOAP anzusprechen. 
Detaillierte technische Informationen können der technischen Komponentenspezifikation entnommen werden. Diese ist unter folgendem Link im SharePoint abgelegt. 
## 6.8.2 Kundendatenverwaltung (KDV)
Das Arbeitsdokument befindet sich im Share Point Link.
| | KDV/ KuDav | SOAP, https | Kundendatenverwaltung. Enthält Informationen wie 'Sperrvermerk' auf Kundennummer-Ebene.
##
bahn/project-audit/data/confluence-export/pages/27525700_6.10 GFD-Z IST-Zustand und Analyse.md
+64
View File
@@ -0,0 +1,64 @@
# 6.10 GFD-Z IST-Zustand und Analyse
> Confluence Page ID: 27525700
> Version: 55
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.10 GFD-Z IST-Zustand und Analyse
> Labels:
---
Schnittstelle zwischen Trassenportal (TPN) und GFD-Z
TPN übergibt Trassenanmeldungen und andere Aufträge in Form von „TPN-Anforderungen“ an GFD-Z. GFD-Z bereitet die Aufträge für die Konstruktion auf und stellt für TPN Informationen über den Status der Verarbeitung („Anforderungsstatus“) zur Verfügung. Die aus dem Konstruktionssystem RUT-K an GFD-Z übergebenen Konstruktionsergebnisse werden von GFD-Z zusammengestellt und für die Veröffentlichung bereitgestellt sowie als Angebote („TPN-Antwort“) an TPN zurückgegeben. Die beiden Datenflussrichtungen sind technisch als Datenbankschnittstellen implementiert. 
## Annahme Bestellsystem:
Eine Anbindung des Bestellsystems an das bestehende System GFD-Z ist nicht geplant. Angebotsdaten werden direkt über die neue RUT-K Schnittstelle (SteuerungKonstruktionsablauf) an die neue Bestellsystem-Schnittstelle (SteuerungVertrieb) übertragen. Weitere Spezifikationen (erhaltene Operationen, verwendete Schnittstellenobjekte) werden in der Schnittstellenbeschreibung Bestellsystem - BaDiFa (RUK-K) neu beschrieben. 
Systemkontextdiagramm vom heutigen System GFD-Z: 
| |
Kurzbeschreibung der Schnittstelle GFD-Z  - TPN
TPN - GFD-Z |
GFD-Z stellt an der Schnittstelle folgende Daten zur Abholung durch TPN bereit:
- Informationen über den Bearbeitungsstatus einer TPN-Anforderung
- Angebote zu Fahrlagen, die aus einer TPN-Anforderung erzeugt oder verändert worden sind
- Daten zur Trassenanmeldung werden von TPN an GFD-Z übergeben
- GFD-Z quittiert den Empfang der Anforderung mit einer eindeutigen Anforderungsnummer
| |
Verwendete Schnittstellenobjekte |
-      TPN-Antwort
-      Anforderungsstatus
| |
Enthaltene Operationen |
-      Angebotsdaten an TPN übertragen
-      TPN-Abfrage (Status einer Anforderung vom GFD-Z abfragen)
-      Angebot abholen (durch TPN)
##
Schnittstelle zwischen GFD-Z – BIP
Als Nebenleistung kann ein EVU eine Trassengrafik bestellen, siehe https://fahrweg.dbnetze.com/fahrweg-de/kunden/leistungen/neben_und_zusatzleistungen/preise-1392066. Diese wird mit BIP erstellt.  Es handelt sich hier um den gleichen Bestellvorgang wie für gedruckte Buchfahrpläne, bei dem ein Produktionsauftrag direkt in Richtung der „Veröffentlichung“ geht. Im Zielbild würde BIP wegfallen und seine gesamte Funktionalität in der neuen Veröffentlichungsplattform aufgehen.
Die Bestellungen von Nebenleistungen sollten langfristig über das Bestellportal abgewickelt werden, das damit eine Schnittstelle zu einer weiteren Produktionsplattform hätte. Dies ist im Rahmen des MVPs jedoch nicht berücksichtigt.
## Schnittstelle zwischen GFD-Z und dem Abrechnungscockpit
Über GFD-Z wird die Verwaltung der Trassen und unter anderem die Datenversorgung der NSS und von EBuLa realisiert sowie die Angebote zur Weitergabe an den Kunden (EVU) vorbereitet. Da in diesen Angeboten auch Preisangaben vorhanden sind, muss GFD-Z diese über einen neuen Service des Abrechnungscockpits beziehen.
Über diese Schnittstelle werden von GFD-Z Trassenpreisanfragen an das Abrechnungscockpit gestellt und die jeweiligen Ergebnisse entgegengenommen. Weiterhin wird das Abrechnungscockpit über diese Schnittstelle bei Vertragsänderungen informiert und mit den Trassendaten des alten und neuen Vertragsstandes versorgt. 
## Annahme Bestellsystem:
Über die Schnittstelle Bestellsystem - AC werden zukünftig die Trassenpreisanfragen/Vertragsänderungen an AC gestellt und die Ergebnisse entgegengenommen. 
## Schnittstelle zwischen GFD-Z - NSS 
Die NSS Schnittstelle wird weiter über Fahrplan (Badifa) versorgt.
- Badifa berücksichtigt durch den Zugtrassenbereitstellungsservice die Versorgung unmittelbar umliegender DB Netz-interner Systeme mit Zugtrasseninformationen.
- Aktuell wird eine Vorstudie zur Integration der betrieblichen Fahrplanbearbeitung (BFB) in Badifa bzw. IKS (Integriertes Konstruktionssystem) durchgeführt
- Es existiert eine Analyse („Synopse“), die den Informationsgehalt von TAF/TAP Path Details Messages des Betriebs mit dem Informationsgehalt des aktuellen Betriebszugs der NSS verglichen hat.
- Es ist nicht erwünscht neben den geplanten Services einen weiteren provisorischen Service zu entwickeln, um bspw. ein Releasedatum zu retten. („kein zweites ISA“)
Zur Ablösung der NSS herrscht bilateraler Konsens zwischen Fahrplan und Betrieb. 
 Die Anforderungen der historischen Abnehmer (NSS) werden an Badifa übergeben ggf. den Zugtrassenbereitstellungsservice von Badifa um weitere Services erweitert sofern die TAF/ TAP TSI konformen Daten vom Bestellsystem oder aus dem Betrieb nicht ausreichend oder inkompatibel sind. 
## Experten Schätzung für die weitere GFD-Z Schnittstellen: 
GFD-Z – OSB: Entfällt zusammen mit OSB, wenn die Workflowsteuerung des unterjährigen Baufahrplans zur Fahrplankonstruktion wandert. Das hängt aber davon ab, ob die Prozessanpassungen und IT-Unterstützung aus M13 und M31 im unterjährigen Baufahrplan dazu führen, dass alle baubedingt geänderten Trassen auskonstruiert werden können, sodass QAP in GFD-Z entfallen kann. Wenn das nicht der Fall sein sollte, könnte die Schnittstelle evtl. noch etwas länger bis zur Ablösung OSB leben.
GFD-Z – PAULA: Wurde implementiert, aber nie produktiv genutzt, und diente nur zur Weitergabe von La-Daten aus PAULA nach EBuLa, ohne dass GFD-Z etwas damit getan hat. Falls irgendwann die La-Daten in die Buchfahrplan-Darstellung auf den Bordgeräten integriert werden soll, könnte sich das ändern. Vermutlich wird weder das neue Trassenkonstruktionssystem, noch die Trassen- bzw. Trassenfahrplan-Verwaltung, noch die zukünftige Veröffentlichungsplattform, eine Schnittstelle zu PAULA haben.
GFD-Z – BuMV: Eigentlich ist das keine Schnittstelle. GFD-Z erzeugt für gedruckte Buchfahrpläne RTF-Dateien. Die „Buchmacher“ (in den LN-Prozessen: „Fahrplandatenbereitsteller“) öffnen diese mit MS Word und verwenden einen Satz Makros zur Nachbearbeitung der Dokumente, wenn nötig. Diese Makros heißen „BuMV“ („BuchMacher-Verfahren“). 
## Annahmen aus der FIB 2 Veröffentlichungsplattform 
- Schnittstelle zwischen GFD-Z - Ebula: die Schnittstelle wird weiter über GFD-Z versorgt.
- GFD-Z - Ebula Editor: die Schnittstelle wird weiter über GFD-Z versorgt.
- GDF-Z - Leporello: die Schnittstelle wird weiter über GFD-Z versorgt.
bahn/project-audit/data/confluence-export/pages/27525710_7.1.3 Einzelkomponenten und Funktionen.md
+74
View File
@@ -0,0 +1,74 @@
# 7.1.3 Einzelkomponenten und Funktionen
> Confluence Page ID: 27525710
> Version: 21
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.3 Einzelkomponenten und Funktionen
> Labels:
---
In diesem Kapitel werden die Kernfunktionen des neuen Bestellprozesses betrachtet und die Umsetzungsalternativen vorgestellt. Eine Kauflösung bzw. Wiederverwendung wird vorgestellt, soweit diese bekannt ist. Dabei wird auf die Vorstellung von TPN verzichtet, da diese bereits in der IST-Analyse sowie als separate Wiederverwendungsoption diskutiert wurde.
## Kernfunkionen
## TAF-TAP-TSI-konforme Bestellschnittstelle
Neben einer Eigenentwicklung kommt hierfür das unter Kapitel  beschriebene Produkt - eine Referenzimplementierung der TAF TAP-TSI-Bestellschnittstelle in Betracht. 
Dieses Produkt könnte als Integrationskomponente zwischen den externen EVUs und der Komponente SteuerungVertriebsAblauf eingesetzt werden.
Eine Bewertung dieser Alternative ist in Architekturentscheidung RNE CI zu finden.
## Planung einer Zugfahrt (UI)
Hierbei handelt es sich um die Planungsfunktionalität in einer Bestelloberfläche. Die Wiederverwendung der entsprechenden Einfachbahn Produkte wird im Kapitel  beschrieben.
## Anmeldung einer Zugfahrt (UI)
Für die Anmeldung sowie Änderung oder Stornierung einer Zugfahrt kommen neben einer Neuentwicklung die bisherigen Systeme TPN und Click&Ride in Frage.
## Vorgangsverwaltung Trasse
Die Vorgangsverwaltung umfasst die Speicherung sowie den Abruf und die Darstellung der Anmelde-Vorgänge. Diese Funktionalität wird sowohl für die Bestellschnittstelle als auch auch für die Anmeldung-UI benötigt.
Hierfür ist eine Neuentwicklung vorgesehen, die das TAF-TAP-TSI-konforme Datenmodell und spezifische Zugriffsszenarien effizient unterstützen kann. So können zum Beispiel die Trassen-Anfragen und -Angebote als unveränderliche Dokumente abgelegt werden und eine einfache Darstellung der Vorgänge ermöglichen.
Eine Umsetzung als eigenständige Komponente (getrennt von der Prozesssteuerung) ermöglicht eine Trennung der trassenspezifischen Vorgänge vom produktübergreifenden Vertriebsprozess (siehe unten).
## Prozesssteuerung des Vertriebsablaufs
Die Steuerung des Vertriebsablaufs umfasst zum einen die Integration mit den Umsystemen aus dem Bereich Abrechnung und Fahrplankonstruktion. Zum anderen ist hier zukünftig die Integration mit den anderen Produkten (Anlagen bzw. Stationen) vorgesehen.
Hier kommt neben einer Neuentwicklung auch die Wiederverwendung der Prozesssteuerung (siehe Kapitel ) in Betracht. Allerdings läuft die bisherige Lösung auf der EIP und enthält Fahrplan- und Vertriebs-Komponenten. Eine Migration auf eine Camunda-basierte Lösung und eine Aufteilung in Vertriebs- und Fahrplan-Kompontenten ist in neXt gestartet. Eine Wiederverwendung kann geprüft werden, sobald die Migration abgeschlossen ist. Auf der anderen Seite ist eine integrierte Camunda-Funktionalität der einzusetzenden Entwicklungsplattform eine sinnvolle Alternative.
## Abrechnungsfunktionen
Für die Abrechnung werden im Rahmen der Trassenbestellungen folgende Funktionen benötigt:
- Preisauskunft
- Beleg-Verwaltung
- Beleg-Archivierung
- Änderungsabrechnung
- Rabatte
- Leistungsbeschreibungen
Diese Funktionen werden im Rahmen des Projekts Abrechnungscockpits neu- bzw. weiterentwickelt. Es handelt sich also um eine Wiederverwendung, wobei die zusätzlichen Anforderungen vom Bestellsystem berücksichtigt werden (siehe ).
## Fahrplan- und Infrastruktur-Funktionen
## Stammdaten
Es kann zwischen betrieblichen, fahrplanerischen und vertrieblichen Stammdaten unterschieden werden. Diese werden zur Zeit vom System GFD-I (siehe ) bereitgestellt. Als die künftige Quelle ist das System InfrastrukturManager anvisiert, welches durch das Projekt M15 aufzubauen ist.
## Konstruktion-Steuerung
Bisher erfolgt die Steuerung des Konstruktionsablaufs in TPN sowie die eigentliche Konstruktion in RUT-K (angebunden in TPN über GFD-Z). Künftig soll dieser Ablauf durch die im Projekt BaDiFa zu entwickelnde Systeme abgelöst werden.
Eine Alternative wäre die Wiederverwendung der bisherigen Kette: Konstruktion-Steuerung in TPN, GFD-Z, Konstruktion in RUT-K. Hier ist vor allem die Konvertierung zwischen den bisherigen Datenmodellen und Prozessen sowie deren Entsprechungen in der TAF/TAP Welt problematisch.
## Routensuche
Im Bestellportal soll die Routensuche die Planung einer Zugfahrt unterstützen, ähnlich zum Trassenfinder, bzw. die angebotene Trasse visualisieren, wie in der Click&Ride App. Dafür bietet  (im Gegensatz zum Trassenfinder) einen dedizierten Service. Dieser soll im Bestellportal genutzt und entsprechend der neuen Anforderungen erweitert werden.
## Zugnummer- bzw. OTN-Generator
Zukünftig sollen die OTN (Operational Train Number, entspricht in etwa der bisherigen Zugnummer) von einem vom Fahrplan angebotenen Service umgesetzt werden. Dieser wird im BaDiFa Projekt entwickelt, bzw. aus dem bisherigen Zugnummern-Generator von TPN weiterentwickelt.
## Bestelleingangsprüfung
Die fahrplanerische Prüfung der Trassenbestellungen erfolgt aktuell im vom  entwickelten Service TrassenProduktPruefenUndErgaenzen. Dieser kann wiederverwendet werden. Die vertrieblichen Prüfungen hingegen sollen direkt im Bestellportal umgesetzt werden, um eine saubere Trennung von Fahrplan und Vertrieb zu erreichen.
## Sonstige Funktionen
## Integration Kundenportal
Das Bestellportal-Frontend soll in ein Kundenportal der Netz integriert werden, um eine zentrale Anlaufstelle zu ermöglichen. Eine leichtgewichtige Integration (Verlinkung aus dem Portal) ist prinzipiell mit jeder verfügbaren Portal-Lösung, wie MyNet, NetzCockpit oder dem DB Kundenportal möglich.
## Benutzerverwaltung
Die Benutzerverwaltung deckt vor allem die Authentifizierung und Autorisierung der Benutzer ab. Das Letztere umfasst insbesondere die Rollen und die Kundennummer-Zuordnungen. Hierfür kann die bestehende eBRS Lösung aus MyNet/BBZ/LDAP wiederverwendet werden. Alternativ könnte, analog zu TPN, eine eigene Benutzerverwaltung umgesetzt werden.
## Kundenstammdaten
Die Kundenstammdaten werden aktuell vom Service KDV angeboten. Dieser soll wiederverwendet werden.
## Geschäftsanalytik (BI)
Für die Analyse der Geschäftsdaten sollen bestehende Systeme wiederverwendet werden: . Aufgrund der mit TAF-TAP-TSI geänderten Datenstrukturen und Prozesse wird dafür ein geeigneter Service angeboten.
bahn/project-audit/data/confluence-export/pages/27525716-4.3 Geschaeftsobjekte Bestellsystem.md
+40
View File
@@ -0,0 +1,40 @@
# 4.3 Geschäftsobjekte Bestellsystem
> Confluence Page ID: 27525716
> Version: 47
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.3 Geschäftsobjekte Bestellsystem
> Labels:
---
Das im Bestellsystem verwendete Objektmodell leitet sich aus dem fachlichen Objektmodell der DB Netz AG (FOM) ab (). Für die IT-technische Modellierung innerhalb des Bestellsystems orientiert sich das Projekt sehr nahe am TAF/TAP TSI Standard. Die neuen Fachklassen und Geschäftsobjekte sind im TAF/TAP TSI Modell (Anlage 3, 4 und 5 des TAF/TAP Fachkonzepts) beschrieben. Bei Schnittstellen im DB Netz-IT Kontext zu Komponenten außerhalb des Bestellsystems, findet eine bilaterale Abstimmung zwischen beiden Partnern statt, es wird insbesondere bei bestehenden Services eine am IT Objektmodell der DB Netz (ITOM) ausgerichtete Struktur verwendet werden, alternativ das intern genutzte TAF/TAP TSI nahe Modell.
Die folgende Abbildung zeigt die Beziehung von Objekten aus Sicht des Fahrplans zu Objekten aus Sicht des Vertriebs vorgenommen unter Berücksichtigung der TAF/TAP Nachrichten als Grundlage.
Im Rahmen der Vorstudie wurde das Objektmodell für die Schnittstellen mit den Verantwortlichen der externen Schnittstellen und der IT Architektur im CIO-Bereich der DB Netz AG abgestimmt und eine erste Kostenindikation erstellt. Eine finale Abstimmung des geänderten bzw. ergänzten Objektmodells auf Attributebene ist für den Start des Projektes Anfang 2020 geplant. 
## 4.3.1 Objektverwendungen und Identifier
Die unternehmensextern orientierte Schnittstelle TAF/TAP TSI Common Interface benutzt selbstverständlich TAF/TAP TSI im Sinne der Schnittstellenbeschreibung der DB Netz AG. Die zentralen Objekte der neuen TAF/TAP-TSI-Struktur sind die vier Objekte Train („Zug“), PathRequest („Fahrlage“), Path („Zugtrassenvariante“), sowie CaseReference (keine direkte ITOM-Entschprechung vorhanden) für spezielle Ausprägungen bzw. ergänzende Anmeldeinformationen. 
## Train-Objekt und PathRequestMessage
Das Train-Objekt bildet im Bestellsystem das grundlegende Objekt für die Kundensicht. Es kann ausschließlich vom Kunden erstellt werden. Der Train repräsentiert dabei den vom Kunden umrissenen, aus Kundensicht beschriebenen Geschäftsvorfall. Durch die TrainID wird das Objekt fachlich eindeutig identifizierbar. Das Train-Objekt ist in der Planungsphase beim Kunden das entscheidende Objekt, unter dem Entwurfsstände gefunden werden und so Planungsvorgänge wieder aufgenommen werden können. Ein Train kann in der Anmeldung in multiple PathRequests aufgesplittet werden. Jede maßgeblich Anpassung am Objekt PathRequest erfordert die Generierung eines neuen PathRequests. Maßgebliche Anpassung sind beispielsweise Unterscheidungen in den Anmeldungen für Werktage und Wochenenden. Eine präzise Definition, wann eine Differenzierung zu einem neuen PathRequest führt gibt es nicht. These ist, dass jede bestellte Attribut-Abweichung die Bildung eines neuen PathRequests erfordert. Bis zum Vertragsschluss, kann das Train-Objekt relativ beliebig durch den Anmelder angepasst werden. Mit Vertragsschluss führen wesentliche Änderungen am Objekt aber unbedingt zur Schaffung eines neuen TrainObjektes und ggf. zum Ende des Lebenszyklus des Ausgangsobjekts. So lässt sich beispielsweise nach Vertragsschluss der PlannedCalendar des Train-Objekts nicht mehr erweitern. Eine zeitliche Verlängerung kann nur durch Schaffung eines entsprechenden neuen Train-Objekts abgebildet werden.
## Path-Objekt und PathDetailsMessage
Das Path-Objekt wird im Gegensatz zum Train-Objekt durch den Infrastructure Manager (IM) gebildet und über eine eindeutige PathID fachlich identifizierbar gemacht. Das Path-Objekt beschreibt eine Zeit-Wege-Linie durch das Netz des erstellenden IM. Vereinfacht gesagt entsteht durch die Verknüpfung zwischen Train-Objekt und Path-Objekt ein Fahrplan. Ein Path-Objekt kann losgelöst von einem Train-Objekt existieren, etwa im Fall von Systemtrassen. Diese Zuordnung wird über eine PathDetailsMessage bekannt gegeben. Auf ein PathRequest hin, kann ein IM mit multiplen PathDetailsMessages eine 1:n Zuordnung herstellen. Bezogen auf den Train besteht also eine Mehrfachzuordnung auf PathRequest-Ebene und danach ebenfalls auf PathDetailsEbene. Durch Referenzierung auf die ensprechenden IDs ist aber jederzeit eine Nachvollziehbarkeit der Zuordnung gegeben.
## CaseReference
Das Objekt CaseReference ist derzeit noch in der fachlichen Klärung. Grundsätzlich können Verwendungen des Objekts "bilateral" zwischen IM und Responsible Applicant (RA) definiert werden, so dass Ersteller und Empfänger das Objekt verstehen können. Eine europaweite Abstimmung ist nicht erforderlich. Die Verwendung des Objekts wird mit der Schnittstellenbeschreibung bekannt gegeben.
Ideen zu Verwendung des CaseReference-Objekts sind:
- Zusammenfassung von Taktverkehren
- Zusammenfassung von Verkehrskonzepten (wahrscheinlich sehr ähnlich zu oben, ggf. mit anderen Ausprägungen)
- Beschreibung von Baumaßnahmen und Bündelung betroffener Path-Objekte mit Calendar-Objekten
- Grundsätzlich sachverhaltliche Bündelung einer Menge von Path-Objekten
CaseReference-Objekt Framework der RNE 
## Aufbau Identifier
Die Identifier in TAF/TAP sind alle grundsätzlich identisch aufgebaut. Der identifizierte Objekttyp selbst ist in den ersten beiden Stellen gekennzeichnet. Identifier in der Planungsphase bilden die Grundlage für die abgeleiteten tagesscharfen Objekte der Betriebsphase. Der Absender einer Nachricht an den Betrieb muss demnach bei Erstellung einer Nachricht darauf achten, auf das korrekte Tagesobjekt zu verweisen. 
Das Design von TAF/TAP TSI zeigt, dass die TrainID ein rein fachlich zu verstehender Identifier ist. Ungeachtet der Verwendung von TAF/TAP IDs, wird also auch das Handling technischer Identifier notwendig sein.
Â
bahn/project-audit/data/confluence-export/pages/27525725_2019-02-27 Abstimmung RuT-Kneu _-_ Bestellportal Zeitschiene.md
+74
View File
@@ -0,0 +1,74 @@
# 2019-02-27 Abstimmung RuT-Kneu <-> Bestellportal Zeitschiene
> Confluence Page ID: 27525725
> Version: 3
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-02-27 Abstimmung RuT-Kneu <-> Bestellportal Zeitschiene
> Labels: meeting-notes
---
##
## Teilnehmer
-
Sebastian Hassemer
-
Alicia Schäfer
- Daniel Görich
- Joachim Geidel
- Benjamin Schmücker
- Ana Cvitkovic
- Sebastian Leisner
-
Konstantin Pussep
## Was ist im Scope von RUT-K Neu bis 2023?
- RV-Kapazitäten
- Konstruktion GelV September 2023
- Konstruktion NetzV April 2023
- Datenmigration NetzV 2022 -> Netzfahrplan 2023
- Workflowsteuerung NetzV und GelV (im Scope RUT-K Neu; Workflowsteuerung Bau nicht RUT-K Neu)
- Inkl. BEP für automatisch vs. manuelle Konstruktion/Bestellportal fragt BEP, ob fahrbar oder nicht
Die BEP müsste fachlich gesehen in eine vertriebliche und eine fahrplantechnische Prüfung aufgeteilt werden, außerdem müsste die Bestelleingangsprüfung von der Prüfung auf Eignung für die automatische Konstruktion getrennt werden. Die vertriebliche Prüfung gehört eigentlich in die Domäne Vertrieb und nicht in die Domäne Fahrplan. Da eine Ablösung des aktuellen BEP-Services nicht im Scope der beiden M31-Teilprojekte ist, gehen wir zunächst davon aus, dass sie unverändert bleibt und in der Domäne Fahrplan angesiedelt wird.
- Veröffentlichung ansteuern
- Fristen kommen aus Vertrieb, Fahrplan teilt diese auf RBn auf
Es gibt für den Vertriebsprozess und die Steuerung der Konstruktionsprozesse unterschiedliche Fristen und daher auch unterschiedliche Fristenrechnungen. Korrekterweise müsste man von noch zwischen Fristen (Zeitdauern, um etwas zu tun) und Terminen (Stichtage wie letzter Termin für die Abgabe von Trassenanmeldungen zum Netzfahrplan) unterscheiden.
Fristenrechnung für Vertriebsprozesse gehört zur Domäne Vertrieb und damit in das Teilprojekt Bestellportal. Fristenrechnung für die Fahrplankonstruktion benötigt als Eingangsgrößen die Fristen bzw. Termine der Vertriebsprozesse, wenn es um eine aus einem Vertriebsprozess ausgelöste Konstruktion geht. Diese Fristenrechnung gehört zur „Steuerung Konstruktionsablauf“ und ins Teilprojekt RUT-K neu.
Trassenverwaltung
- Trassenverwaltung
- "Front-End um Bestellungen zu sehen" (KK-Client) inkl. Fahrlagenverwaltung
- Zugnummernvergabe (wird mitgenommen/kann sein, dass es weitergegeben wird)
- Heben auf neue Infrastruktur
 
## Change-Requests:
- Lärmschutz (Ana schickt CR)
 
## Nicht Scope RUT-K Neu
- Preis nicht Teil RUT-K Neu sonder im Rahmen des Bestellportals
- Abbildung TTR
- SAPBine Schnittstelle
 
## Einbindung BEP
- Überprüfung in Bestellportal (Fahrplan- und Vertriebs-BEP)
 
## Relevant für Meilensteine/Fertige Inkremente
- Schulungen für Konstrukteure müssen gewährleistet werden (erster Stand muss früher fertig sein)
- Dummy für Schnittstelle recht früh (gewünscht von Bestellportal)
- Aus feiner Fahrplan wird Kapazität ist Fahrplan Domäne (-> RUT macht aus Feinplanung Kapazitätszusage)
 
## Offen:
- Beratung bei abgelehnten Trassen kein LN-Prozess (Beratungsprozess). Im Scope oder nicht? -> Bestellportal über Marco
- Termin zur Abstimmung über Objektmodelle
 
## Fazit:
- Ohne äußeren Einfluss ist Scope bis Jfpl 2024 umzusetzen
- Aktuell Ziel
- Schätzung hat noch nicht stattgefunden
- Trotzdem Fallbacklösung vorbereiten im Rahmen des Risikomanagements, und in beiden Teilprojekten für den Fall, dass es Verzögerungen im jeweils anderen Teilprojekt gibt
bahn/project-audit/data/confluence-export/pages/27525729_6.2.1 Business Service TrassenProduktPruefenUndErgaenzen BEP und Routensuche.md
+42
View File
@@ -0,0 +1,42 @@
# 6.2.1 Business Service TrassenProduktPruefenUndErgaenzen (BEP) und Routensuche
> Confluence Page ID: 27525729
> Version: 36
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan/6.2.1 Business Service TrassenProduktPruefenUndErgaenzen (BEP) und Routensuche
> Labels:
---
## Einführung
Der Service "Trassenprodukt prüfen und ergänzen" ist der fachlichen Domäne: „Kapazitäts-und Fahrplanmanagement“  zugeordnet und dort in der Komponente „Trassenmanagement“ verortet. Welche Funktionalitäten von den Komponenten aktuell unterstützt werden ist nur rudimentär in der Dokumentation abgelegt und muss aktuell noch zu großen Teilen den User Stories entnommen werden. Es wird daran gearbeitet, die Dokumentation auszuweiten.
Um dem Kunden schnellstmöglich eine Rückmeldung zu geben, ob seine Angaben valide sind, wird jeder Vorgang (beispielsweise nach dem Speichern oder Senden) automatisch an den Business Service TrassenProduktPruefenUndErgaenzen (kurz: TPPuE) geschickt. Da es sich bei diesem Service um eine Art Bestelleingangsprüfung (kurz BEP) handelt, wird dieser Begriff sehr häufig verwendet und auch in diesem Dokument benutzt.
Auf den folgenden Seiten wird dieser Service näher beschrieben.
## Ziele und Inhalt des Service
Der Service führt umfangreiche Prüfungen auf einer Fahrlage durch um festzustellen, ob der Kundenwunsch formal korrekt ist und die Fahrlage technisch theoretisch konstruierbar ist.
Kurze Beschreibung der funktionalen Anforderungen der Service TrassenProduktPruefenUndErgaenzen liegt
 
## Serviceübersicht Routensuche 
| | Serviceprofil
| |
Tags |
Routensuche, Route, Kosten, Graph, schnellste Verbindung, Mehrwegsuche
| |
Verbindung zu Anwendungssystemen | Fahrzeiten- und Belegungszeitenrechner (FBZe) Service über FBZe-Connector
| |
Muster des Nachrichtenaustauschs
  (Message Exchange Pattern) |
synchrones Request/Response
| |
Fehlerbehandlung |
Siehe 2.6 Ausnahmebehandlung
- Es wird nicht die günstigste Route (Variante) gefunden (zurzeit wird eine leere Route dem Aufrufer zurückgeliefert)
- Die zu Grunde liegende Infrastruktur ist nicht korrekt
- Unabhängig von der Anzahl der geforderten Routen werden zu viele Routen ausgegeben
| | Servicebeschreibung | Servicebeschreibung Routensuche M13 NeXt Gesamtfahrplan befindet sich . 
Tabelle 1: Serviceübersicht RoutensucheÂ
bahn/project-audit/data/confluence-export/pages/27525735_6.2.2 Fahrzeitberechnung FBZE.md
+14
View File
@@ -0,0 +1,14 @@
# 6.2.2 Fahrzeitberechnung (FBZE)
> Confluence Page ID: 27525735
> Version: 7
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.2 M13 neXt Gesamtfahrplan/6.2.2 Fahrzeitberechnung (FBZE)
> Labels:
---
- Fahrzeitberechnung (FBZE) ist kein BusinessService, sondern wird derzeit nur als Bibliothek intern eingebunden. 
- Bibliothek FBZE ist nicht für das Produkt Fahrzeitrechnung geeignet, da dieser nur die Fahrzeiten für bereits existierende, mikroskopische Routen berechnen kann, selbst aber nicht in der Lage ist, ein Routing durchzuführen.
- Für den Zweck der Fahrzeitrechnung eignet sich der Kern der automatischen Einzelbelegung hinter C&R besser, wenn dieser ohne den gesetzten Verkehr initialisiert wird. In diesem Fall sucht der Algorithmus eine ideale Strecke und konstruiert diese inkl. Fahrzeiten aus. Für diese Trasse kann dann auch über den Service zur Preisermittlung ein Preis ermittelt werden
-
WSDL
bahn/project-audit/data/confluence-export/pages/27525737-7.1.2 Komplettloesung basierend auf Bestandssystemen.md
+37
View File
@@ -0,0 +1,37 @@
# 7.1.2 Komplettlösung basierend auf Bestandssystemen
> Confluence Page ID: 27525737
> Version: 10
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.2 Komplettlösung basierend auf Bestandssystemen
> Labels:
---
Bisher erfolgt die Trassen-Bestellung über  (Trassenfinder und Click-und-Ride App unterstützen nur einige Teilaspekte als Alternative zu TPN). Wie in der folgenden Abbildung vorgestellt, beinhaltet TPN sowohl vertriebliche als auch fahrplanerische Komponenten.
Durch die Trennung von Fahrplan und Vertrieb könnte die Wiederverwendung, also entweder im Fahrplan oder im Vertrieb, erfolgen. Nachfolgend wird eine Wiederverwendung im Vertrieb betrachtet.
Neben der technologischen Aktualisierung von TPN müssen folgende fachliche Anpassungen an TPN vorgenommen werden:
- Umsetzung wichtigster Anforderungen im bestehenden Internet Client (Angular Client) und TPN Backend
- Anpassungen der Datenmodelle der TPN-UI (z.B. homogene Fahrlagen in TAF/TAP TSI, keine Ergänzungsfahrpläne mehr, netzausgelöste Angebote)
- Erheblicher Ausbau der Planungs-Komponenten
- Ausbau der Konstruktionsfunktionalitäten
- Integration TAF/TAP-TSI in TPN
-
EVU XML und die neue TAF/TAP passen nicht zusammen. 120 Felder aus EVU XML gibt es nicht mehr in TAF/TAP (z.B. VZR und Lokstellungen sind anders).
- Die neue Verkehrstageregelung kann nicht ohne Weiteres zurück in eine TPN VZR transformiert werden
-
Mapping TPN- TAF/TAP- TSI -EVU 4.0 - Evu 2x. oder 3.x 
- Trennung Vertrieb vom Fahrplan
- Anbindung an die neue Konstruktionsschnittstelle
- Trennung Trasse Zug
- Trennung der Prozess-Schritte für Vertrieb und Fahrplan
## Bewertung
Folgende Argumente sprechen gegen die Wiederverwendung von TPN:
-
Bestellprozess für Trassenprodukte tief integriert mit Produktionssteuerung: Keine Bündelprodukte mit Nicht-Trassenprodukten möglich
-
Monolithisches System TPN erlaubt keine eigene Governance für die Weiterentwicklung von Prozessen und Systemen in den Domänen Vertrieb respektive Fahrplan
Aus diesem Grund findet keine Schätzung dieser Umsetzungsvariante statt.Â
bahn/project-audit/data/confluence-export/pages/27525741-7.1.1 Komplettloesung - Ergebnisse von APluS.md
+31
View File
@@ -0,0 +1,31 @@
# 7.1.1 Komplettlösung - Ergebnisse von APluS
> Confluence Page ID: 27525741
> Version: 18
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.1 Komplettlösung - Ergebnisse von APluS
> Labels:
---
Für die Auswahl und die Bewertung der BUY-Umsetzungsalternativen werden zunächst die Ergebnisse des Projekts APluS (siehe unten) betrachtet. 
## Projektauftrag EU-Ausschreibung Kaufsoftware für Planungs- und Steuerungssysteme (APluS)
Im Zeitraum von 09/2015 bis 08/2016 wurde das Projekt APluS zur „Vorbereitung einer EU-Ausschreibung zum Abschluss eines Rahmenvertrages mit den Leistungsfeldern Lizensierung, Wartung, Weiterentwicklung und optional den Betrieb einer Standard-IT-Plattform„ beauftragt (Quelle: BV aus VS 16/2015).
Fokus war hierbei: Ausrichtung der IT im Bereich Fahrplan und Betrieb auf einen europäischen Standard „um dem Ziel einer strategischen Weiterentwicklung der DB Netz AG zu einem europäischen Fahrplanersteller und damit Dienstleister von EIU näher zu kommen“ (Quelle: BV aus VS 16/2015) Perspektivische Weiterentwicklung des Standards zu einer releasefähigen, europäischen Plattform für Fahrplan- und Betriebs IT.
Der Projektauftrag APluS kann, aufgrund der geringen Abdeckung der Anforderungen am Markt (Ergebnis RFI), nicht erfüllt werden. Daher wurde im 2. Lenkungskreis der Auftrag zur Zerlegung des Scopes in separate Umsetzungspakete und die Erarbeitung von bedarfsgerechten Umsetzungsstrategien erteilt (Rightsizing APluS). Im Rahmen von „Rightsizing“ wurden Umsetzungspakete erarbeitet und vom APluS LK am 20.6.2016 beschlossen (vgl. Abbildung).
Bewertungskriterien K-Komplexität der Schnittstelle, R-Risiko, F-Funktionale Überlappung: Vorhanden
Das Umsetzungspaket 2 umfasst die Module der Trassenbestellung (und entspricht im Wesentlichen dem Umfang dieser Vorstudie):
- Bestellportal- Browserbasierte Kundenschnittstelle für EVUs zur Anmeldung von Trassen
- Bestellschnittstellen -TAF/TAP-TSI-konforme EVU-Schnittstelle und PCS-Schnittstelle
- Steuerung Vertriebsablauf - Komponenten zur Steuerung der Vertriebsaktivitäten: Anstoßen der Produktionsprozesse, Steuerung der Angebotskommunikation, Anbindung der kaufmännischen Systeme und des Archivsystems
 Der Scope des Projekts Bestellsystem ist eine Untermenge von Bestellportal /Bestellschnittstelle.
## Ergebnis APluS
Unter Punkt 2. Bestellportal/Bestellschnittstelle wurde eine Individualentwicklung empfohlen:
- Keine der am Markt verfügbaren Kaufsoftwarelösungen erfüllt die notwendigen Anforderungen der DB Netz
-
Die Eigenentwicklung- Individualentwicklung einer Lösung für das Bestellsystem und die entsprechenden Schnittstellen nach agilem Vorgehen (SAFe) wurde zwischen I.NM und I.NVI am 07.04.16 beschlossen (4.te Lenkungskreis).
bahn/project-audit/data/confluence-export/pages/27525745_7.1.4 Technologie- und Plattform-Auswahl.md
+102
View File
@@ -0,0 +1,102 @@
# 7.1.4 Technologie- und Plattform-Auswahl
> Confluence Page ID: 27525745
> Version: 18
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/7 Umsetzungsalternativen und Bewertung/7.1 make-, buy, re-use-Entscheidungen/7.1.4 Technologie- und Plattform-Auswahl
> Labels:
---
Die Eigenentwicklung der Bestellsystem-Services soll im Rahmen einer Microservice-Architektur erfolgen. Die geplanten Microservices sind in der folgenden Grafik dargestellt.
Die Technologie-Auswahl basiert auf den Empfehlungen des DB Systel Technologie-Radars und ist nachfolgend skizziert:
Die Auswahl einer geeigneten Plattform für die zu entwickelnden Systeme stellt in diesem Zusammenhang eine kritische Entscheidung dar. Hierfür werden die nachfolgenden Optionen betrachtet:
## Plattform-Alternativen
## AWS
Amazon Web Services (AWS) ist die Standard-Cloud-Plattform des DB Konzern (vgl. https://db-planet.deutschebahn.com/pages/value-it/apps/content/cloud-db). Das AWS-Angebot enthält zahlreiche Services aus den Bereichen Infrastructure-as-a-Service (IaaS) und Plattform-as-a-Service (PaaS). Diese können flexibel gebucht, kombiniert und konfiguriert werden.
So können praktisch alle benötigten Ressourcen, Technologien und Produkte als vorgefertigte bzw. konfigurierbare Dienste in AWS genutzt werden.
## Analyse
Aufgrund des sehr umfangreichen Angebots steigt die Komplexität und für einige Services, auch die Gefahr des Vendor-Lock-Ins bei der Nutzung der AWS-only Features, wie z.B. AWS Lambdas. Ein sicherer, Konzern-Richtlinien konformer, Betrieb ist nur mit viel AWS Know-How, Erfahrung und Aufwand zu bewerkstelligen.
Daher ist der reine Betrieb in AWS als aufwendig und riskant anzusehen. Diese Option wird somit nicht weiter in Betracht gezogen. Stattdessen ist der Betrieb in einer vorbereiteten DB-konformen AWS-Umgebung zu bevorzugen. Die dazugehörigen Angebote im DB Konzern werden nachfolgend vorgestellt.
## DB Modular Cloud
Mit der DB Modular Cloud wird ein Infrastructure-as-a-Service Angebot für den Self-Service Cloud-Betrieb angeboten. Dieser umfasst aktuell:
- Server-Varianten (Windows 2016, AWS Linux, AWS Linux 2, RedHat Enterprise Linux) in verschiedenen Leistungsklassen
- Datenbank-Varianten (PostgreSQL, MariaDB, Oracle SE Two, Microsoft SQL Server SE) in verschiedenen Leistungsklassen
- Supportlevel Bronze
- Support on Demand
## Analyse
DB Modular Cloud bietet lediglich den Service Level Bronze und ist aktuell nicht für den Produktivbetrieb vorgesehen.
## DB Container Services
DB Container Services (DBCS) ist die Containerumgebung der DB Systel. Ein besonderer Schwerpunkt liegt dabei auf der PaaS Platform OpenShift, Buildpipelines und DevOps. DB Container Services setzt auf RedHat OpenShift (RHEL7, Kubernetes, Docker) und beinhaltet die virtuelle Infrastruktur, die OpenShift Console/API und eine Vielzahl von gemanagten Middleware Produkten (Beispielsweise Apache, Tomcat, Jboss, .NET, Javascript, Node.js, Datenbanken, Messaging, etc.).
Der Funktionsumfang enthält:
- Einfaches Deployment durch Verwendung von Basistemplates (Apache, Tomcat, Jboss, PHP, etc.) im Self-Service, auf Wunsch werden diese automatisiert gepflegt
- Integrierte, standardisierte DevOps Mechanismen
- Bedarfsgerechte automatische Skalierung in Sekunden
- Eingebaute Hochverfügbarkeit über drei Availibility-Zones für jeden Container
- Integriertes zentrales Logfile-Management und Monitoring
Die Container Services werden in verschiedenen Varianten angeboten: Shared, Dedicated, Dedicated-Private. Die Unterschiede liegen in der Isolationsebene der OpenShift Installation und der zugehörigen Infrastruktur sowie in den Preismodellen (per-use vs. fix&per-use).
Als Service Level wird in der Variante Dedicated neben Bronze auch Gold angeboten.
## Analyse
CTO Container Strategie besagt: 
CTO-Beschluss
Neben der im DBCS-Team betriebenen PaaS-Lösung auf Basis von Kubernetes/OpenShift werden weitere PaaS-Lösungen für containerisierte Applikationen nur in Abstimmung mit Portfoliomanagement und der Architekturgilde aufgebaut.
Somit ist DBCS (bzw. Business Hub als Aufsatz) die Hauptoption für die Umsetzungsplattform. Allerdings werden einige Zusatzdienste (wie Datenbanken, WorkflowEngines) aktuell nicht von DBCS als Service angeboten.
## Business Hub
Der Business Hub dient als digitale Integrationsplattform des DB Konzerns (siehe https://db-planet.deutschebahn.com/pages/business-hub/apps/content/was-ist-der-business-hub-2):
## Eine Plattform für alle 
Durch den Business Hub werden sowohl geschäftsfeldübergreifende, bahninterne APIs, als auch APIs außerhalb des Bahnkonzerns miteinander verknüpft, um Ihre Geschäftsprozesse bestmöglich zu unterstützen. Die zentrale Plattformlösung stellt alle Werkzeuge, Bausteine und Services bereit, damit Sie Ihren Weg in digitale Transformation beschreiten können.
Auf Basis einer modularen Entwicklung im Baukastenprinzip können Konzernkunden die Plattform zur Erstellung verschiedener Services nutzen, sowie eigene Services am Markt für andere Konzernunternehmen und den externen Markt zur Verfügung stellen. Durch die Nutzung existierender Services profitieren Sie von bestehenden Lösungen anderer Konzerngesellschaften, die auf dem integrierten Marktplatz angeboten werden.
Der Business Hub ist der Marktplatz für die Nutzung und den Vertrieb von Daten und Services im Konzern.
Es werden unterschiedliche Varianten angeboten:
## Business Hub Service Factory
Die Business Hub Service Factory wird als betriebsfertiger Integrations- und Infrastrukturdienst in der DB Enterprise Cloud zur Verfügung gestellt.
Die in der Business Hub Service Factory enthaltenen Top-Features:
- Integration von internen und externen Services auf Basis unterschiedlicher Technologien (REST/SOAP/Streaming)
- BPM-Engine zur Orchestrierung mehrerer Services zu einem Service-Bundle
- Service-Monetarisierung auf Basis fachlicher Mengen oder Service Contents mit Übergabe der Abrechnungsdaten an die DB Konzernsysteme
- Identity- & Access-Management (Identity Broker), mit der Möglichkeit auch externe Identity Provider zu integrieren
- Deployment Pipeline mit Service Test Management für beliebig automatisierbare Testverfahren (z.B. Integration Tests, Compliance Tests)
- Datenbank- und Storage-Services
- Hochverfügbare Laufzeitumgebungen inkl. Monitoring
Der Service wird wahlweise als SL3-Bronze und SL1-Gold (geplant) angeboten. Die Preise orientieren sich an den darunterliegenden DB Container Services.
## Business Hub Connect
Zur Bereitstellung oder Integration von internen und externen digitalen Produkten und Services (APIs) innerhalb des Konzerns, stellt Business Hub Connect alle dazu benötigten Fähigkeiten in Form einer umfangreichen API-Konnektivitätslösung zur Verfügung.
Das API-Management unterstützt die Veröffentlichung und Monetarisierung von APIs - unabhängig davon, auf welcher Plattform die jeweilige API entwickelt wurde. Die API Management-Fähigkeiten von Business Hub Connect stellen hierfür umfangreiche Funktionen für das Veröffentlichen, Verwalten, Kontrollieren und Auffinden von APIs zur Verfügung.
Die Veröffentlichung der APIs im API-Portal als zentralem Marktplatz für Services ist Bestandteil von Business Hub Connect. 
Business Hub Connect ist zur Zeit noch in der Betaphase. Die Fähigkeiten sind noch im Aufbau und werden kontinuierlich weiterentwickelt. 
Die wichtigsten Features des API-Managements: 
- API Creation & Delivery Management.
- API Lifecycle Management.
- API Discovery.
- API Analytics.
- API Monetization.
- API Test Management.
- API Support & Community Management.
Der Service wird wahlweise als SL3-Bronze und SL1-Gold angeboten.
## Analyse
Prinzipiell bietet Business Hub zusätzliche Dienste zum Angebot der DB Container Services. Die meisten dieser Dienste (BPM-Engine, Identity Management, etc.) werden bereits mit dem Angebot der Service Factory abgedeckt.
Zielplattform-abhängige Lieferobjekte (z.B. Dokumentation, Testfälle, o.ä.) oder spezielle Anforderungen an Lieferobjekte (z.B. hinsichtlich Form, Inhalt, Erstellungsprozess), sind im Rahmen des Umsetzungsprojekts vorrangig durch die technischen Architekten zu ermitteln und auszuarbeiten.
bahn/project-audit/data/confluence-export/pages/27525760_4.4.2 Anbindung von Betriebsstellen_Fahrplanvertrieblicher Stammdaten.md
+49
View File
@@ -0,0 +1,49 @@
# 4.4.2 Anbindung von Betriebsstellen/Fahrplanvertrieblicher Stammdaten
> Confluence Page ID: 27525760
> Version: 87
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.2 Anbindung von Betriebsstellen/Fahrplanvertrieblicher Stammdaten
> Labels:
---
## Einführung
Das System zur Bereitstellung von fachlichen Stammdaten, wie etwa Betriebsstellen, Streckenklassen oder Produktmerkmale ist heute die GFD-I, deren Ablösung bis Mitte 2024 geplant ist. Der M15 Infrastrukturmanager wird hier das Nachfolgesystem sein, dass die Daten hält. Die Daten werden domänenspezifisch gepflegt. 
Das Bestellsystem hat unter anderem die Aufgabe, die DB Netz Stammdaten aus Betrieb, Fahrplan und Vertrieb den Schnittstellenkunden bereitzustellen. Hierfür wird es am M15 Infrastrukturmanager eine Schnittstelle geben müssen, die den gesamthaften Datenexport erlaubt und das Bestellsystem in die Lage versetzt, die Daten als xml unseren Kunden zur Verfügung zu stellen.
Für den Bestellprozess im Bestellportal werden zunächst vor allem die neuen, europaweit harmonisierten Primary Location Codes (PLC) zu verwenden sein. Diese werden in der Central Reference File Database (CRD) der RNE vorgehalten und sind jeweils durch die National Contact Points für die Einführung der TAF/TAP TSI verwaltet und gepflegt. Das Bestellportal wird für die Eingabe in der grafischen Benutzeroberfläche die Angabe dieser PLC auf Daten der CRD zurückgreifen. Die heutigen RIL100 Codes der DB Netz AG behalten parallel ihre Gültigkeit. Eine Zuordnung zwischen PLC und RIL100-Codes muss durch die Datenhaltung im M15 Infrastrukturmanager geleistet werden. Für die Abkürzungen der Örtlichkeiten und Betriebsstellen ist die Ril 100 respektive das AG 850 zuständig (Liegt bei I.NMN).  Das Bestellportal muss neben den DB Netz eigenen oder verwalteten Betriebsstellen auch die Eingabe von Betriebsstellen aus Fremdinfrastrukturen im In- und Ausland unterstützen, da diese im Rahmen der Train-Information abgebildet werden müssen. 
## Stammdaten aus dem Infrastrukturmanager M15 sind:
BetriebsstellenListe 
- Diese Auflistung enthält alle Betriebsstellen der DB Netz, die in ausgetauschten Nachrichten unter Beachtung der jeweils aktuell gültigen Schnittstellendokumentation enthalten sein dürfen. Die Betriebsstellen sind als PrimaryLocationCode (TAF/TAP Format) hinterlegt, bei Konstruktion auf fremder Infrastruktur ggf. auch nicht DB Netz eigene Betriebsstellen. Teilweise müssen Betriebsstellen auch als SubsidiaryCodes (TAF/TAP Format) vorliegen, dies ist bei Betriebsstellen der Fall, die z.B. eine Fahrplanbearbeitungsgrenze darstellen oder Bahnhofsteile einer großen Betriebsstelle (Mutterbahnhof) sind.
StreckenListe 
- Diese Auflistung enthält streckenweise (gleiche Zahl in Spalte "Strecke") in aufsteigender Kilometrierungsrichtung alle der Strecke zugeordneten Betriebsstellen (PrimaryLocationCodes, SubsidiaryCodes). Die versetzte Darstellung von Betriebsstellen bei zweigleisigen Strecken gesondert für die Hin- und Gegenrichtung entsprechend der Kilometrierungsrichtung sowie für das Richtungs- und Gegenrichtungsgleis ergibt sich aus der Wirkrichtung von Signalstandorten bzw. Halteplätzen. 
Für die Angabe in der Trassenbestellung bzw. im Angebot ist diese Unterscheidung nicht relevant, die Betriebsstelle selbst existiert unabhängig von der angegebenen Wirkrichtung in beiden Richtungen.
StreckenklassenListe 
- Diese Auflistung enthält alle aktuell bestellbaren Streckenklassen.
ZuggattungsListe 
- enthält alle aktuellen Zuggattungen.
ZugausruestungsListe 
- enthält Angaben für Attribute zur Beschreibung der technischen Ausrüstung des Zuges.
Verkehrstageschlüssel
- Evtl. für Anbindung als Schnelleingabefunktion; grundsätzlich werden in der fachlichen Kommunikation keine Verkehrstageschlüssel mehr verwendet
(Funktionsweise Bitleiste https://wiki.intranet.deutschebahn.com/wiki/display/neXtlab/Umrechnung+TPN+Verkehrszeitregelung+in+diskrete+Verkehrstageregelung)
TriebfahrzeugListe
- enthält die Baureihen und -varianten sowie deren Beschreibung für alle aktuellen Triebfahrzeuge.  Fachliche Betriebsführer und Ansprechpartner: Andreas Hahn. 
Tfz Leerfahrt
- Diese Tabelle enthält die Angaben zur Unterscheidung bei der Durchführung einer Zugfahrt bzw. eines Zugfahrtabschnittes als Tfzfahrt bzw. als Leerreisezug. (Tfzf und Leer_Rz)
Betriebstellendaten, DB Netz-eigen
- Verortung und Festlegung der Handoverpoints (zwischen zwei EIU vereinbarter Übergabepunkt hinsichtlich der Zuständigkeit für die Trassierung und Betriebsdurchführung) und Netzgrenze auf der Infrastruktur
- Das AbrechnungsCockpit-Trasse und RuT-K neu müssen erkennen können, ob Abschnitte zwischen Handoverpoint und Netzgrenze konstruktionsrelevant, abrechnungsrelevant und Veröffentlichungsrelevant relevant ist. Die entsprechenden Informationen müssen im Infrastrukturdatenmodell bei den Streckenabschnitten hinterlegt sein und bei der Infrastrukturdatenpflege (Infrastrukturmanger (IM)) erfasst werden. 
Verkehrsart Kunde Zusatz (enthält die Attribute der gewählten Produktart)
- Charterverkehr (nur für Züge mit maximal 30 Verkehrstagen bestellbar; nur im Gelegenheitsverkehr für Züge des SPV; Zuglaufpunkte mit bestelltem Verkehrshalt müssen mit einem erfassbaren Haltegrund bestellt werden)
- Nostalgieverkehr (nur für Züge mit maximal 30 Verkehrstagen bestellbar; nur im Gelegenheitsverkehr für Züge des SPV)
- Punkt-zu-Punkt-Verkehr (nur in Kombination mit einer Flexibilität = „ZF 30“ bestellbar; Bestellung ist dann sowohl zum Netzfahrplan als auch im Gelegenheitsverkehr für den SPV erlaubt – unter „Weitere Angaben“ dürfen keine Anschlußbeziehungen bestellt sein – max. 130 km/h Durchschnittsgeschwindigkeit)
Verkehrsart Kunde 
- Diese Tabelle enthält die Angaben zur Unterscheidung der Verkehre gemäß Trassenpreissystem 2017. Die Angaben sind Schienengüterverkehr (SGV), Schienenpersonennahverkehr (SPNV), Schienepersonenfernverkehr (SPFV).  
Betriebliche Priorisierung
- Diese Tabelle enthält die Angaben; sehr hohe Prio SPFV- Express, erhöhte Prio SGV-Schnell und sehr hohe Prio SGV-Express  zur Unterscheidung der Priorität in der betrieblichen Disposition der Zugtrassen.
Flexibilität
- enthält die Attribute der vom Kunden gewünschten Flexibilität für die Konstruktion.  Zur Steigerung der Flexibilität in der Trassenkonstruktion für den Netzfahrplan im Güterverkehr (also nicht im Gelegenheitsverkehr) kann der Kunde die Option „räumliche Flexibilität“ (RF 120) bestellen. Flexibilität gilt für den gesamten Zuglauf innerhalb des Konstruktionsbereiches der DB Netz. Räumliche Flexibilität darf nicht bestellt werden wenn der gesamte Zuglauf eine Tfz-Fahrt ist – in Zusammenhang mit der Bestellung von Pre-arranged Paths (PaPs) über PCS (gilt auch für „Nebenprodukte“ der PaPs wie Feeder/Outflow oder Tailormade-Trassen) – wenn die Trassenbestellung auf eine RV-Kapazität referenziertReferenziert eine Schienengüterverkehr-Anmeldung zum Netzfahrplan auf eine RV-Kapazität, muss der mit der bestellten räumlichen Flexibilität gewählte zeitliche Konstruktionsspielraum kleiner oder gleich der Bandbreite der referenzierten RV-Kapazität sein
bahn/project-audit/data/confluence-export/pages/27525769_4.4.3 Anbindung EVUs an DB Netz TSI konforme Bestellschnittstelle.md
+28
View File
@@ -0,0 +1,28 @@
# 4.4.3 Anbindung EVUs an DB Netz TSI konforme Bestellschnittstelle
> Confluence Page ID: 27525769
> Version: 14
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.3 Anbindung EVUs an DB Netz TSI konforme Bestellschnittstelle
> Labels:
---
Es wird eine technische Schnittstelle in Form eines WebService („CI_Planning_DBNetz“ genannt) zum Austausch von Nachrichten im Kontext von Vorgängen zur Trassenanmeldung zwischen dem EVU-System und dem Bestellsystem der DB Netz implementiert werden. Diese Schnittstelle ersetzt die bisherige EVU-Schnittstelle der DB Netz und wird den zukünftigen TAF/TAP-TSI konformen Nachrichtenaustausch zwischen den beteiligten Bahngesellschaften realisieren.
Die Implementierung der Schnittstelle (TAF/TAP TSI Common Interface) erfolgt gemäß der CI-Spec der RNE (RailNetEurope) und ist über den Link http://ccs.rne.eu/common-interface/ abrufbar.
Das TAF/TAP TSI Common Interface der DB Netz ("CI_Planning_DBNetz") kann nur die für das EVU und für den Trassenbestell- und Zuweisungsprozess erforderlichen TAF/TAP-TSI Nachrichten verarbeiten. Konkret sind dies die folgenden TAF/TAP TSI standarisierten Nachrichtentypen:
- PathRequestMessage
- PathConfirmedMessage
- PathDetailsRefusedMessage
- PathCanceledMessage
- ReceiptConfirmationMessage
- ErrorMessage
- ObjectInfoMessage
- UpdateLinkMessage
Umgekehrt erfordert eine peer-to-peer Kommunikation per WebService, dass jedes EVU, welches über CI_Planning_DBNetz mit dem Bestellsystem der DB Netz kommunizieren möchte, ebenfalls einen WebService bereitstellt. Dieser WebService muss sich ebenfalls nach der TAF/TAP-TSI Spezifikation richten. Er muss die notwendigen Aspekte der CI-Spec implementieren. Die DB Netz sieht eine Versendung der nachfolgenden Nachrichtentypen an die EVU vor.
- PathDetailsMessage
- PathNotAvailableMessage
- ReceiptConfirmationMessage
- ErrorMessage
- ObjectInfoMessage
- UpdateLinkMessage
## Systemkontext
bahn/project-audit/data/confluence-export/pages/27525778_4.4.4.2 M13 ClickundRide Integration und Anbindung.md
+30
View File
@@ -0,0 +1,30 @@
# 4.4.4.2 M13 Click&Ride Integration und Anbindung
> Confluence Page ID: 27525778
> Version: 36
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.2 M13 Click&Ride Integration und Anbindung
> Labels:
---
## Einführung
Grundsätzlich muss hier in der Begrifflichkeit zwischen dem Verfahren Click&Ride und dem gleichnamigen Produkt differenziert werden. 
## Das Verfahren Click&Ride
Die Integration des Verfahrens Click&Ride beschäftigt sich mit der technischen wie prozessualen Integration der Click&Ride App mit ihren Funktionalitäten in das neue Bestellsystem. Heute arbeitet Click&Ride mit einer eigenständigen Middleware, die aus Objekten im Click&Ride-Objektmodell (CROM) Objekte in ITOM erzeugt und diese an der neXt Schnittstelle zur technischen Prozessteuerung direkt in den Prozess zur automatischen Konstruktion einkippt. 
Mit Integration in das neue Bestellsystem wird Click&Ride künftig Aufträge, die aus der App erzeugt werden, an die Komponente SteuerungVertriebsAblauf übergeben. Dazu muss die Objektumwandlung von CROM zu ITOM auf CROM zu TAF/TAP-nah erfolgen. Das Messaging-Konzept aus TAF/TAP kann für die App-Version von Click&Ride vernachlässigt werden, da die Nachrichtenabfolge in Click&Ride fachlich ausreichend ist und keine Drittsysteme integriert werden müssen.
Durch die prozessuale Integration von Click&Ride in die Komponente SteuerungVertriebsAblauf wird künftig eine Statusüberwachung über das Bestellportal auch für Vorgänge möglich sein, die in der Click&Ride App ausgelöst wurden. Eine Annahme von Click&Ride-Angeboten, die über die Click&Ride-App angefragt wurden soll dabei im ersten Schritt aber nicht implementiert werden. Die Vertragsverwaltung von aus der Click&Ride-App bestellten Vorgängen wird aber nahtlos gemäß TAF/TAP TSI-Prozessen über das Bestellportal und die TAF/TAP-Schnittstelle möglich sein.
## Das Produkt Click&Ride
Das Produkt Click&Ride wird neben dem Auslösen von Anfragen über die Click&Ride-App, zukünftig auch aus dem Bestellportal heraus und über das Common Interface auslösbar sein. Hierzu wurde der Prozess "Kurzfristige Trassenberatung mit Buchungsoption" definiert und in der Schnittstellenbeschreibung für die neue TAF/TAP TSI Schnittstele dokumentiert. Der gesonderte Prozess ist erforderlich, um dem juristischen Charakter einer Click&Ride-Anfrage gerecht zu werden. Anfragen in Click&Ride gelten als eine Form der Trassenberatung, die im Einzelfall zur Buchung führen kann. Hierfür wird das Konstruktionsergebnis aus der Trassenberatung mit Click&Ride für 10 Minuten als belegte Trasse reserviert und ist für den Kunden, der die Trassenberatung angefordert hat mit Annahmeverzicht buchbar. Um dieses Produkt möglichst breitgefächert zur Nutzung zu bringen, wurde ein Prozess mit TAF/TAP-konformen Messages definiert, der dies bewusst auch Schnittstellenkunden ermöglicht.
## Die Kapazitätsabfrage (Nicht MVP)
Die Fähigkeiten hinter Click&Ride sollen außerdem in einem weiteren Feature einem Kundennutzen zugeführt werden: die Kapazitätsabfrage. Diese ermöglicht dem Kunden im Bestellportal, eine beliebige Anmeldung testweise in den Fahrplankonstruktionskern zu senden, ohne dass dies einen Anmeldungscharackter hat. Im Unterschied zur Fahrzeitberechnung erhält der Kunde auf seine Anfrage dann eine konkrete Trassenkonstruktion unter Berücksichtigung der bekannten Infrastrukturauslastung. Technisch ist eine Kapazitätsabfrage kaum von einer Click&Ride-Anfrage zu unterscheiden, es gibt aber erhebliche fachliche Unterschiede:
- Eine Kapa-Abfrage kann auch erfolgen, wenn eine automatische Veröffentlichung nicht erfolgen kann
- Eine Kapa-Anfrage ist nicht an die Beschränkung der Fristigkeit von Click&Ride gebunden, sondern kann auch mit mehreren Tagen oder Wochen Vorlauf erfolgen
- Eine Kapa-Abfrage kann ggf. auch dann erfolgen, wenn technische Sachverhalte eine automatische Konstruktion eigentlich nicht zulassen (z.B. aktuell: KV-Profil)
- Eine Kapa-Abfrage erzeugt keine persistente Trassierung bzw. Reservierung, sondern gibt ausschließlich Auskunft über eine individual nutzbare Kapazität für den angefragten Sachverhalt zum Zeitpunkt der Anfrage
Kunden bekommen so eine Einschätzung für die zu erwartende Netzauslastung zum gewünschten Fahrtzeitpunkt und können Ihren Kunden wiederum entsprechend angepasste Angebote unterbreiten. Die Kapazitätsauskunft gibt dabei keine Auskunft darüber, welche Kapazitäten durch wen belegt sind, sondern eine unverbindliche Positivauskunft darüber, wie eine Trassierung eines konkreten Zuges aussähe/aussehen könnte, wenn diese aktuell angefragt würde. Da eine Kapazitätsabfrage keinen Vertriebsprozess darstellt, ist angedacht diese zwischen Bestellportal und Click&Ride Belegungskern direkt, ohne Umweg über die Komponente SteuerungVertriebsAblauf, anzubinden. Die Informationsauskunft wird zunächst ausschließlich über das Bestellportal abrufbar sein.
Der Prozess für die kurzfristige Fahrplagenberatung mit Buchungsoption (KFB) ist im EVU SST Hauptdokument (Abbildung 12: Geschäftsvorfallfolgen – Kurzfristige Fahrlagenberatung mit Buchungsoption) einsehbar.
bahn/project-audit/data/confluence-export/pages/27525780-4.4.4 Anbindung an den Fahrplan und das Kapazitaetsmanagement.md
+19
View File
@@ -0,0 +1,19 @@
# 4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement
> Confluence Page ID: 27525780
> Version: 93
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement
> Labels:
---
## Einleitung 
Folgende Schnittstellen (Services/Komponeten) aus der fachlichen Domäne: „Kapazitäts-und Fahrplanmanagement“ werden an das neue System angebunden oder mit integriert. 
Die Schnittstellenbeschreibung bzw. Servicebeschreibungen sind Bestandteil der funktionalen Systemdokumentation und stellt allen Betroffenen die fachlichen Informationen zur Verfügung.
## Ausschnitt aus dem Systemkontext des Bestellsystems
In den folgenden Unterkapiteln sind zu den primären Soll-Schnittstellen noch weiterführende Informationen dokumentiert.
bahn/project-audit/data/confluence-export/pages/27525784_4.4.4.1 Neues Konstruktionssystem Projekt BaDiFa.md
+230
View File
@@ -0,0 +1,230 @@
# 4.4.4.1 Neues Konstruktionssystem (Projekt BaDiFa)
> Confluence Page ID: 27525784
> Version: 42
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.1 Neues Konstruktionssystem (Projekt BaDiFa)
> Labels:
---
## Einführung 
Durch die Trennung Fahrplan <> Vertrieb wird das Verhältnis zwischen Kundenauftrag und Konstruktionsauftrag stärker formalisiert () Heute ist beides in einer Datenbank in TPN integriert und wird nicht weiter differenziert.
Die Bestellsystem-Komponente SteuerungVertriebsAblauf verwaltet den Kundenauftrag und übergibt die Produktionsaufträge an die Fahrplan-Schnittstelle mit der dahinter stehenden Komponente SteuerungKonstruktionsAblauf. Dort werden fahrplanintern Arbeitsaufträge an die manuelle oder die automatische Fahrplankonstruktion geschnitten. Nach Fertigstellung der Konstruktion übergibt SteuerungKonstruktionsAblauf die Konstruktionsergebnisse über die Vertriebsschnittstelle zurück an SteuerungVertriebsAblauf. Der Produktionsauftrag ist damit abgeschlossen. 
SteuerungVertriebsAblauf bereitet nun die vom Kunden erwartete Nachricht für den Versand vor und gibt diese über das DB Netz Common Interface oder das Bestellportal an den Kunden. Ebenso werden Buchungsbestätigungen, Stornierungen und Änderungen über SteuerungVertriebsAblauf aus dem Vertrieb an den Fahrplan übergeben und dort verarbeitet. Der Abschluss der Verarbeitung wird in TAF/TAP TSI auch wieder zurück an den Kunden gespiegelt, so dass Kunde, Vertrieb und Fahrplan jeweils den aktuellen Status aller Vorgänge bestätigt vorliegen haben. Der Vertrieb hält dabei die Hoheit an den Daten zum Vertriebsvorgang, während dem Fahrplan die Datenhoheit über die Trassenverwaltung obliegt. Die veränderte systemische Abbildung zwischen Vertrieb und Fahrplan verändert dabei grundsätzlich nicht die Geschäftsprozesse zum Kapazitätsmanagement. 
Das neue Bestellsystem wird keine Schnittstelle zur Veröffentlichung enthalten, da die Veröffentlichung von Fahrplanunterlagen unmittelbar aus der Trassenverwaltung heraus auszulösen ist.
## Schnittstellenkontext 
## Schnittstellenspezifikation (Operationen)
| |
## Service/Komponente
|
##   Kurzbeschreibung
| Bild aus EAM |
## Kommentar
| |
FahrplanSchnittstelle
erteileFahrplanKonstruktionsAuftrag
bucheFahrplanKapazität
freigabeFahrplanKapazität
aendereFahrplanKonstruktionsAuftrag
zurückziehenFahrplanKonstruktionsAuftrag
verarbeiteFehlerNachricht
verarbeiteteAngebotsAnfrageStornierung
|
Fahrplan Schnittstelle - Angebotsdaten ( Angebotsanfragen) werden direkt über die neue RUT-K Schnittstelle (SteuerungKonstruktionsablauf) an die SteuerungVertrieb übertragen. Weitere Spezifikationen (Erhaltene Operationen, Verwendete Schnittstellenobjekte) werden in der Schnittstellenbeschreibung Bestellsystem- RUT-K neu beschrieben. |
|
| |
Vertriebsschnittstelle
verarbeiteVertragsAngebot
verarbeiteBuchungsbestaetigung
verarbeiteNetzausgeloestesVertragsAngebot
verarbeiteGebuchteTrasseNichtVerfuegbar
verarbeiteFehlerNachricht |
Vertriebsschnittstelle - VertragsAngebote, Buchungsbestätigungen und Netz-ausgelöste Vertragsänderungen werden von Seiten des Fahrplans über diese Schnittstelle an den Vertrieb (Bestellsystem) übergeben. |
|
ErrorMessage
AngebotsAnfrage
Buchungsbestätigung
NetzausgelösteAenderung
| |
OTN-Generator
pruefeOperationalTrainNumber
pruefeKundennummermitEigenemOTNKontingent
erzeugeOperationalTrainNumber
|
Prüfe ob ein Kunde ein Zugnummernkontingent besitzt, prüfe ob die vom Kunden angegebene Zugnummern zu seinem Kontingent gehört und frei ist.
|
|
OTN und parallel Betrieb Zugnummerngenerator (TPN)  Hinweis: Für eine gewisse Zeit wird es 2023 zu einem parallel Betrieb Zugnummerngenerator (Fahrplanjahr 2023) und OTN-Generator (Fahrplanjahr 2024) geben.
## Datenmodell Schnittstelle Bestellsystem- BaDiFa
Als Grundlage wird das Objektmodell TAF-TAP- TSI verwendet (Anlage 1 der EVU SST und das TAF/TAP TSI Konzept). Das fachliche Objektmodell des Vertriebs mit AngebotsAnfrage, VertragsAngebot und ProduktVertrag wird annähernd auf die TAF/TAP Objekte PathRequestMessage und PathDetailsMessage abgebildet. Steuernde Informationen für den Fahrplan werden in den übergreifenden Objekten modelliert. Das fachliche Objektmodell des Fahrplans mit den Objekten FahrplanKonstruktionsAuftrag und FahrplanKapazität wird ebenfalls annähernd auf die TAF/TAP Objekte PathRequestMessage und PathDetailsMessage abgebildet.
Die noch auszudetaillierenden Objekte und deren Befüllungsregeln werden zu Beginn des Implementierungsprojekts bestimmt und umgesetzt.
## Nichtfunktionale Aspekte
| |
Vertraulichkeit |
11
incomplete
 sehr hoch
12
complete
 hoch
13
incomplete
 mittel
14
incomplete
 niedrig
| |
Integrität |
15
incomplete
 sehr hoch
16
complete
 hoch
17
complete
 mittel
18
incomplete
 niedrig
 
| |
Verfügbarkeit
| |
Robustheit der Schnittstelle |
 Keine Anforderungen.
 Folgende Anforderungen: | Kommentar
| |
Servicelevel |
31
incomplete
 SL 1 Plus
32
incomplete
 SL 1
33
complete
 SL 1 Basic
34
incomplete
 SL 2
35
incomplete
 SL 3 Plus
36
incomplete
 SL 3
|
  |
| |
Logging
| |
Anforderung an Logging |
alle anmelderelevanten Vorgänge sind zu loggen 
  |
| |
Übertragungsverfahren
| |
Schnittstellenart |
37
incomplete
 Datenablage in Datei, Pfad: manuelle Festlegung
38
complete
 Webservice/Rest-API: 
39
incomplete
 SMS-Nachricht, Nummer:
40
incomplete
 gemeinsame Datenbank:
41
incomplete
 Online-Transaktion:
42
incomplete
 Andere: Dateiversand via Email
| |
Transaktionssicherheit |
 Keine Anforderungen.
 Folgende Anforderungen:
| |
Art der Datenübertragung |
HTTP
  Â
bahn/project-audit/data/confluence-export/pages/27525786_QG Planung Lieferkriterien.md
+1661
View File
File diff suppressed because it is too large Load Diff
bahn/project-audit/data/confluence-export/pages/27525791_6.3 Initiative Einfachbahn.md
+64
View File
@@ -0,0 +1,64 @@
# 6.3 Initiative Einfachbahn
> Confluence Page ID: 27525791
> Version: 28
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.3 Initiative Einfachbahn
> Labels:
---
6.3.1 Initiative Einfachbahn
Im Rahmen der Initiative Einfachbahn hat der Vertrieb der DB Netz AG verschiedene Angebote entwickelt, die durch prototyphafte Umsetzung schnell unseren Kunden und Partnern zur Verfügung gestellt werden konnten. Einige dieser Angebote/Produkte unterstützen auch mittelbar das Thema Zugfahrt bzw. Planung einer Zugfahrt. Hier gilt zu prüfen, inwieweit IT-Lösungen der Einfachbahn als integriertes Angebot im Bestellportal Mehrwert schaffen können. Dabei besteht keine Möglichkeit, Komponenten des Trassenfinder direkt zu übernehmen: Die fachlichen Komponenten des Trassenfinder werden nicht durch die Fachbereiche selbst bereitgestellt, sondern sind parallel durch Fachexperten der Einfachbahn kuratiert. Die IT ist außerdem ohne Abstimmung des CIO-Bereichs entstanden - eine bewusste Strategie, um schnell prototypische Lösungen entwickeln zu können. Das führt aber im Umkehrschluss dazu, dass die Lösungen nicht im produktiven Einsatz verwendet werden können. Die Konzepte der Einfachbahn-Angebote wären daher im Rahmen des Bestellportals unter Einbeziehung des CIO-Bereichs und Anbindung von Services der fachlichen Owner nachzubauen.
Die Produkte, die dafür zu betrachten sind, sind im Einzelnen:
- Trassenfinder
- Strecken.info
- GreTa
- MaTeo
## 6.3.1.1 Trassenfinder
## Funktionen
Der Trassenfinder ermöglicht die Routenplanung im Netz der DB. Der Nutzer kann unter Auswahl des Fahrplanjahrs, Angabe von Start, Ziel und Zugeigenschaften Routenvorschläge erhalten, die für die Anmeldung eines Zuges herangezogen werden können. Es besteht außerdem die Möglichkeit, durch Ausschluss einzelner Streckenabschnitte die Ergebnisse nutzerseitig zu beeinflussen. Neben Laufwegen in mehreren Varianten gibt der Trassenfinder außerdem Prognosen zum Trassenentgelt, zum Energieverbrauch und zur Fahrzeit ab.
Im nachfolgenden Dokument ist die Funktionalität des heute verfügbaren Trassenfinders detailliert beschrieben: ; Ein öffentlich zugänglicher Link zur Anwendung befindet sich im Internet unter folgender Adresse: www.Trassenfinder.de 
## Bewertung
Der Mehrwert für die Zugplanung ist unbestreitbar. Die angebotenen Informationen unterstützen den Kunden in jeder Zugplanung unmittelbar. Eine Integration der Kernfunktionen ist im Bestellportal daher bereits im Rahmen des Minimal Viable Product (MVP) zu sehen.
## Konzeptansatz
Die fachliche Abbildung mit Services der Fachabteilung ist in diesem Fall einfach konzipierbar, da im Rahmen des Projekts neXt Digitale Kapazitätssteigerung mit der Routensuche und dem Fahrt- und BelegungsZeitErmittlungsservice (FBZE) die wesentlichen Kernkomponenten für Routing und Fahrzeitberechnung bereits vorliegen. Die erforderliche Eingabe von Planungsinformationen ist in der Trassenplanung und -anmeldung sowieso teil des Bestellportals, so dass sich die Routensuchfunktionen nahtlos in den Nutzerprozess einbinden lassen.
Für die Prognose von Trassenentgelten werden Services des Abrechnungscockpit (AC Trasse) angebunden, die neben der reinen Entgeltprognose auch eine Produktzuordnung zurückliefern werden. Somit kann der Nutzer auch erkennen, wie sich das prognostizierte Trassenentgelt zusammensetzt und inwieweit die Zugplanung im beabsichtigten Produktsegment einordnungsfähig ist.
## 6.3.1.2 Strecken.info
## Funktionen
Die DB Netz AG ist bestrebt seine Zugangsberechtigte kontinuierlich über aktuelle Einschränkungen der Infrastruktur zu informieren. Dazu werden dazu die unterjährigen Baumaßnahmen der nächsten 70 Tage dem Kunden als pdf-Datei in Form der 12-Wochen-Vorschau (http://fahrweg.dbnetze.com/fahrweg-de/technik/baustelleninformation/bauschwerpunkte.html) zur Verfügung gestellt. Diese wird durch Strecken.Info durch eine interaktive Karte im Internet ergänzt, wobei die Granularität und der Inhalt der Informationen der 12-Wochen-Vorschau beibehalten wird. Strecken.Info bietet außerdem über einen Login eine Anbindung an den kostenpflichtigen Service LiveMaps.
## Bewertung
Eine Integration der Funktionen von Strecken.Info und ggf. LiveMaps ist stark erstrebenswert. Für die Planung von Zugfahrten im Gelegenheitsverkehr können die Informationen dem Kunden einen erheblichen Mehrwert bieten. Kunden im Netzfahrplan können die Informationen hingegen nicht nutzen. Aufgrund der Begrenzung der Anwendbarkeit und der erwarteten Komplexität der Einbindung der beiden Angebote Strecken.Info und LiveMaps, wird eine Integration im Rahmen des MVP nicht angestrebt.
## Konzeptansatz
 - keine Umsetzung im Rahmen des MVP -
## 6.3.1.3 GreTa
## Funktionen
GreTa ermöglicht dem Nutzer, unter Angaben von Traktion und Laufweg, die Anzeige von Regelgrenzlasten. Dabei bietet GreTa einen Lookup-Service, der die statischen Regelgrenzlasttabellen durchforstet und die Regelgrenzlast sowie die grundsätzliche Machbarkeit einer gesicherten Durchfahrt Streckenabschnittsweise ausgibt. Die begrenzende und jeweils nächste limitierende Grenzlast werden dabei farblich Hervorgehoben. GreTa bietet für angemeldete Nutzer außerdem die Möglichkeit der Beantragung einer Einzelgrenzlastberechnung.
## Bewertung
Eine Einbindung von GreTa in den Prozess der Planung einer Zugfahrt wäre im Wesentlichen für Güterverkehrskunden wünschenswert, wird aber nicht zwingend als MVP bewertet.
## Konzeptansatz
Die grundsätzliche Prüfung und Einhaltung von Grenzlasten erfolgt auch in der neXt Routensuche. Der dahinter stehende Service (Grenzlastbereitstellung) gibt zu allen Streckenabschnitten die gültige Grenzlast zurück. Das Mapping auf die Infrastruktur wird derzeit aufwändig in der neXt Routensuche vorgenommen. Eine Nutzung für das Bestellportal ist zwar grundsätzlich vorstellbar, erscheint aber sehr aufwändig. Parallel wurde durch das Projekt BaDiFa bei I.NMN 1 angestoßen, die Einrichtung eines echten Grenzlastberechnungsservice zu avisieren, da die heutige Praxis der Grenzlastermittlung in den Regionalbereichen hohe Ineffizienzen aufweist. 
Aufgrund der Kann-Bewertung der Integration von GreTa, wird die fachliche Anbindung hier zunächst nicht näher spezifiziert, da hier ggf. der Leistungsfähigste Service mit den besten Ergebnissen zu gegebener Zeit ausgewählt wird. Der Verzicht auf eine Integration stellt ebenfalls im Rahmen des MVP einen möglichen Ausgang dar, wenn beispielsweise auf die Produktivsetzung eines neuen Services gewartet werden sollte. Für Kunden besteht damit lediglich ein Komfortverlust, da die Grenzlastauskunft weiterhin in einem Bestellportal-externen Tool einzuholen wäre.
## 6.3.1.4 MaTeo
## Funktionen
MaTeo ist ein webbasiertes IT-Tool zur Beauftragung einer Machbarkeitsstudie außergewöhnliche Transporte (MaT). Die Machbarkeitsstudie ist Voraussetzung für die Bearbeitung von Trassenanmeldungen zu außergewöhnlichen Transporten. Im Rahmen der Machbarkeitsstudie wird eine BZA-Nr. vergeben, die in der Trassenanmeldung anzugeben ist. Andernfalls erfolgt solange keine Bearbeitung der Anmeldung, bis die BZA-Nr. vorliegt.
Die entsprechende Bestellannahme der MaT sowie die Interaktion zwischen den Kunden und der DB Netz AG wird durch MaTeo digital unterstützt. 
## Bewertung
Die Prozessunterstützung, die MaTeo Kunden im Segment außergewöhnliche Transporte bietet, sollte mittelfristig in das Bestellportal integriert werden. Da MaTeo auf eine abgrenzbare Menge Kunden wirkt und heute bereits eine digitale Prozessunterstützung bietet, wird auf eine Integration im Rahmen des MVP aber verzichtet.
## Konzeptansatz
- keine Umsetzung im Rahmen des MVP -
bahn/project-audit/data/confluence-export/pages/27525801-6.11 Rechner unterstuetzte Trassenkonstruktion RuT-K.md
+10
View File
@@ -0,0 +1,10 @@
# 6.11 Rechner unterstützte Trassenkonstruktion (RuT-K)
> Confluence Page ID: 27525801
> Version: 10
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.11 Rechner unterstützte Trassenkonstruktion (RuT-K)
> Labels:
---
Zum Zeitpunkt der Konzeptionsphase - Vorprojekt läuft ein paralleles Projekt BaDiFa zur Erstellung von RuT-Kneu. Die Beschreibung vom heutigen System RuT-K ist der Vorstudie BaDiFa zu entnehmen.
bahn/project-audit/data/confluence-export/pages/27525802_2019-04-17 Abstimmung RuT-Kneu _-_ Bestellportal Roadmap.md
+56
View File
@@ -0,0 +1,56 @@
# 2019-04-17 Abstimmung RuT-Kneu <-> Bestellportal Roadmap
> Confluence Page ID: 27525802
> Version: 3
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2019-04-17 Abstimmung RuT-Kneu <-> Bestellportal Roadmap
> Labels: meeting-notes
---
## Datum
## Kurze Zusammenfassung unseres Termins mit RuT-K zum aus unserer Sicht risikominimierenden Ansatz „Temporäre Wiederverwendung von Bestandssystemen“:
## Diskussionspunkte
| | Zeit | Eintrag | Wer | Notizen
| | 5min | Agenda Eintrag | Name |
BaDiFa sieht derzeit keinen Anlass, dass es grundsätzliche Schwierigkeiten geben könnte gemeinsam bis 2022 produktiv zu gehen. Der Tenor ist „Wir schaffen das…“.
| |   |   |   | RuT-K Neu glaubt nicht an ein Mapping der verschiedenen Datenmodelle (EVU, TAF/TAP) in einem vertretbaren Aufwand insbesondere wegen:
- Stamm-, Ergänzer
- Mehrere Angebote auf eine Anfrage
- Netzausgelöster Ergänzungsfahrplan
- 20 Stunden Züge
| |
|
|
| Man sieht zusätzlich in unserer Roadmap folgende Schwierigkeit: Zum Testen mit den EVUs wird man keine Fach-Ressourcen (Fahrplaner) bekommen können, es muss „alles“ automatisch funktionieren.
| |
|
|
|
Wir haben folgende Vereinbarung getroffen, der Plan A sollte in etwa so aussehen: wir legen unter der Annahme los, dass alle abhängigen neu gestarteten Projekte insoweit rechtzeitig liefern können, dass der Produktivtermin für das Bestellportal und nachgelagerte Systeme Ende 2022 gehalten werden kann. Die Integration mit dem neuen Konstruktionssystem muss in jedem Fall sehr frühzeitig und wirklich E2E - zumindest mit einfachen Anmeldungen – funktionieren, das sieht RuT-K genauso. Das bedeutet, eine erste für uns nutzbare Version von BaDiFa liegt Ende 2020 vor. Dazu muss es in FIB einen Eintrag im Risikomanagement geben.
Falls zum Zeitpunkt Ende 2020 BaDiFa nicht soweit sein sollte, wollen wir den Plan B ausrufen, bzw. aus Risikogesichtspunkten dem FIB Board zur Entscheidung vorschlagen: Implementierung TAF/TAP CI, Neue (TAF/TAP) Benutzeroberfläche für EVUs, Adapter TPN mit Mapping TAF/TAP->EVU, Headless TPN, Ertüchtigung TAF/TAP für das TPN Backend, Ertüchtigung TAF/TAP für RuT-K alt, Ertüchtigung TAF/TAP für GFD-Z.
Für Plan B benötigen wir eine Einschätzung der Dauer und Kosten einer Ertüchtigung der Bestandssysteme, falls das mehrere Jahre dauern würde wäre es wohl kein Notfallplan. Den Plan B definieren wir als eine der Umsetzungsalternativen unserer Vorstudie, und zwar als diejenige, die wir erstmal nicht als erste Empfehlung angeben werden, sondern eben erst zu dem gegebenem Zeitpunkt weiterverfolgen werden, falls obiges Szenario eintritt.
Information: RuT-K Neu plant als noch nicht näher abgestimmte eigene Roadmap die folgenden Haupt-Stränge: Fahrplaner UI und Konstruktionskern sowie Anbindung von Bestellportal und VÖ. Man will mit einfachen Use-Cases starten. Fahrplaner UI ist am Anfang nur readonly, Bearbeitung kommt dann später, …
## Handlungspunkte
13
incomplete
Sinnvollerweise sollte nach Ansicht RuT-K in unserer Roadmap auch nach Produkten unterschieden werden, also beispielsweise Fertigstellung GelV oder Netzfahrplan, Studien…
1
incomplete
14
incomplete
Â
bahn/project-audit/data/confluence-export/pages/27525810-4.4.4.3 Fahrplanerische Bestelleingangspruefungen BEP TrassenPruefenUndErgaen.md
+261
View File
@@ -0,0 +1,261 @@
# 4.4.4.3 Fahrplanerische Bestelleingangsprüfungen (BEP), TrassenPrüfenUndErgänzen (TTPUE), Routensuche und Fahrzeitberechnung (FBZE) - M13
> Confluence Page ID: 27525810
> Version: 53
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.3 Fahrplanerische Bestelleingangsprüfungen (BEP), TrassenPrüfenUndErgänzen (TTPUE), Routensuche und Fahrzeitberechnung (FBZE) - M13
> Labels:
---
## Anforderungen an die Bestelleingangsprüfung (BEP) und Routensuche
 Die Funktionsweise der Bestelleingangsprüfung (BEP) und der Routensuche wird in Kapitel 6.2.1 exakter erläutert. Im Folgenden wird lediglich eine kurze Beschreibung des Ablaufs gegeben sowie die zusätzlichen Anforderungen, die das Projekt Bestellsystem an die beiden Anwendungen hat, beschrieben.
Aktuell kann die BEP nur in Verbindung mit der Routensuche genutzt werden. Die Routensuche kann wiederum als eigener Webservice unabhängig von der BEP aufgerufen werden, allerdings unterstützt die Routensuche (wie auch die BEP) derzeit nur eine Infrastruktur, die des aktuell gültigen Fahrplanjahres. Die Fahrtzeitberechnung (FBZE) muss nicht direkt angesprochen werden. Es genügt, wenn diese nur durch die Routensuche angesprochen wird. Über die Routensuche bekommt das Bestellportal die FZBE Ergebnisse.
Ziel ist es, beide Anwendungen unabhängig voneinander aufzurufen sowie diese auf mehreren Infrastrukturversionen nutzen zu können.
## Arbeitsweise BEP / Routensuche (Route, RoutenVariante, Durchfahrt, Laufpunkt) 
Der Ablauf erfolgt in 4 Phasen:
1 Phase: Plausibilitätsprüfung und Formelle Prüfungen
Sind alle Pflichtfelder gefüllt?
2 Phase: Fachliche Prüfungen, die unabhängig von der Routensuche sind
Beispiel: Existiert die vorhandene Streckenklasse?
3 Phase: Routensuche
Ist eine Route zu den vorgegebenen Zuglaufpunkten vorhanden?
Berechnung der Fahrzeiten.
4 Phase: Keine Route gefunden? Ursachencheck.
Es werden verschiedene Relaxierungsparameter (siehe Anhang) geprüft. Das bedeutet, dass aktuell eine Prüfung erfolgt, welche untersucht, ob generell, unter Berücksichtigung der Via-Punkte oder bedingt durch die Zugcharakteristik keine Route gefunden wird. 
## Anpassungsbedarf durch ein neues (Trassen-)Bestellsystem
 Folgende Änderungen/Erweiterungen sind im Projekt neXt für die Anbindung des Bestellsystems notwendig:
- Die Streckennummern müssen angezeigt bzw. zurückgegeben werden.
- Das Servicelevel muss angepasst werden, Ziel SL1 Basic.
- Ggf. Nutzungskosten für die beiden Services im Betrieb (z.B. in der Anmeldephase Netzfahrplan mindestens 80000 Aufrufe).
- Die Routensuche muss Verfügbarkeitseinschränkungen zurückliefern können.
- Beide Anwendungen (BEP / Routensuche) müssen unabhängig voneinander aufrufbar sein.
- Die Routensuche soll verschiedene Kriterien berücksichtigen, wie z.B. die verkehrsgünstigste Route.
- Die BEP / Routensuche muss in einem TAF/TAP nahen Objektmodell kommunizieren können.
- Es sollten alle BEP Prüfungen bzw. Prüfungsschritte durchlaufen werden und eventuelle Probleme in der Rückmeldung bereits benannt werden, sodass Kunden dies nicht mehrmals prüfen lassen müssen, um mehrere Fehler zu finden. 
- Konfigurationsmöglichkeiten, welche Prüfungen durchlaufen werden sollen.
Das entsprechende Dokument zum Change Request ist unter CR_neXt_Bestellsystem zu finden.
## Anhang
##  Aktuelle Relaxierungsparameter
<v01:E-TraktionVerboten>false</v01:E-TraktionVerboten>
<v01:AusschlussVerkehrsart>false</v01:AusschlussVerkehrsart>
<v01:Zuggattungszusaetze>false</v01:Zuggattungszusaetze>
<v01:Steilstrecken>false</v01:Steilstrecken>
<v01:NotbremsUeberbrueckung>false</v01:NotbremsUeberbrueckung>
<v01:Bahnsteiglaengen>false</v01:Bahnsteiglaengen>
<v01:Halteplatzlaenge>false</v01:Halteplatzlaenge>
<v01:EingleisigeSperrung>false</v01:EingleisigeSperrung>
<v01:KombinierterVerkehr>false</v01:KombinierterVerkehr>
<v01:StreckenKlasse>false</v01:StreckenKlasse>
<v01:Zuglaenge>false</v01:Zuglaenge>
<v01:ETCS>false</v01:ETCS>
<v01:E-TraktionErforderlich>false</v01:E-TraktionErforderlich>
<v01:KesselwagenVerboten>false</v01:KesselwagenVerboten>
<v01:RichtungswechselhaekchenFehlt>false</v01:RichtungswechselhaekchenFehlt>
<v01:Streckenoeffnungszeiten>false</v01:Streckenoeffnungszeiten>
<v01:UeberlasteterSchienenwegVorgaben>false</v01:UeberlasteterSchienenwegVorgaben>
<v01:Totalsperrung>false</v01:Totalsperrung>
<v01:Grenzlast>true</v01:Grenzlast>
<v01:Zughakengrenzlast>false</v01:Zughakengrenzlast>
## Anforderungen des Projekts Bestellsystem an die Fahrtzeitberechnung (FBZE)
FBZE ist kein BusinessService, sondern wird derzeit nur als Bibliothek intern eingebunden. Die Bibliothek FBZE ist nicht für das Produkt Fahrzeitrechnung geeignet, da diese nur die Fahrzeiten für bereits existierende, mikroskopische Routen berechnen kann, selbst aber nicht in der Lage ist, ein Routing durchzuführen. Für den Zweck der Fahrzeitrechnung eignet sich der Kern der automatischen Einzelbelegung hinter C&R besser, wenn dieser ohne den gesetzten Verkehr initialisiert wird.
In diesem Fall sucht der Algorithmus eine ideale Strecke und konstruiert diese inkl. Fahrzeiten aus. (EINE VARIANTE in C&R). Über die Routensuche bekommt das Bestellportal die FZBE Ergebnisse. 
Anforderungen bei Fahrzeitberechnungen aus TAF/TAP- TSI
In einer Anmeldung für  eine Fahrzeitberechnung  ist immer eine Zugnummer anzugeben. Sie hat unter fachlich-rechtlichen Aspekten keine Bedeutung, dient aber neben den Identifikatoren Train-ID, PathRequest-ID und Path-ID als zusätzliches, den Geschäftsvorfall identifizierendes Ordnungsmerkmal. Sie unterstützt mit ihrer fachlichen Eindeutigkeit die praktische Arbeit mit den Geschäftsvorfällen für Fahrzeitberechnungen. Gesonderte Zugnummernzuweisungen für Fahrzeitberechnungen durch die DB Netz erfolgen nicht. Es können vorzugsweise Zugnummern des aktuellen Netzfahrplans, die vom EVU benutzt wurden, verwendet werden. Das bestellende EVU hat die Eindeutigkeit der Zugnummern für die Gesamtheit seiner Anmeldungen je Produkt Fahrzeitberechnung gewährleisten.
Schnittstellenkontext 
Die öffentliche Schnittstelle "Routensuche Web Service" bietet verschiedene Operationen für unterschiedliche Zwecke. Folgende Serviceoperationen werden durch den "Routensuche Web Service" bereitgestellt. SucheRoute - Das Ermitteln einer oder mehrerer Routen mit den Daten der Start- und Zielbetriebsstelle
  
## Datenmodell 
Routensuche ist grundsätzlich ein Webservice, der ITOM „spricht“ und über SOAP/http kommuniziert. Allerdings hat M13 die Antwortobjekte der Routensuche eigenhändig ITOM-nah modelliert, was dazu geführt hat, dass der CIO Bereich die Routensuche zum heutigen Stand nicht als Business Service betrachtet. Die Routensuche unterstützt keine Erkennung der korrekten Infrastruktur und keine Funktionen aus dem SPV. Diese fehlenden Funktionen werden sukzessive im Kontext Baufahrplan nachgeliefert. 
Problem: Datengrundlage bzw. Infrastrukturdaten in einer Version sind nicht vorhanden.
Datenmodell TAF/TAP-TSI
| |
marktProdukt |
Produkt, welches von DB Netz angeboten wird |
1.  In diesem Feld ist eines der über das Bestellsystem bestellbaren Produkte der DB Netz anzugeben. Produkte sind aktuell: Trasse, KFB (kurzfristige Fahrlagenberatung mit Buchungsoption), FZB (Fahrzeitberechnung), FPS (Fahrplanstudie/Betriebsprogrammstudie)
2.  Das Feld ist unter Berücksichtigung der für die Produkte möglichen Geschäftsvorfälle zu verwenden (siehe Kap. 2.1   "Geschäftsvorfälle und TAF-TSI/TAP-TSI- Nachrichtentypen") |
1 |
string |
TR = Trasse
FZB = Fahrzeitberechnung
FPS = Fahrplan- und Betriebsprogrammstudie
## Nichtfunktionale Aspekte
| |
Vertraulichkeit |
11
incomplete
 sehr hoch
12
incomplete
 hoch
13
incomplete
 mittel
14
incomplete
 niedrig
| |
Integrität |
15
incomplete
 sehr hoch
16
incomplete
 hoch
17
incomplete
 mittel
18
incomplete
 niedrig
| |
IT-Sicherheit |
n/a
| |
Nachvollziehbarkeit |
n/a
 
 
| |
Verfügbarkeit
| |
Robustheit der Schnittstelle |
 Keine Anforderungen.
 Folgende Anforderungen: | Kommentar
| |
Servicelevel* |
31
incomplete
 SL 1 Plus
32
incomplete
 SL 1
33
complete
 SL 1 Basic
34
incomplete
 SL 2
35
incomplete
 SL 3 Plus
36
incomplete
 SL 3
|
  |
| |
Logging
| |
Anforderung an Logging* |
 
  |
| |
Übertragungsverfahren
| |
Schnittstellenart* |
37
incomplete
 Datenablage in Datei, Pfad: manuelle Festlegung
38
complete
 Webservice: 
39
incomplete
 SMS-Nachricht, Nummer:
40
incomplete
 gemeinsame Datenbank:
41
incomplete
 Online-Transaktion:
42
incomplete
 Andere: Dateiversand via Email
| |
Transaktionssicherheit* |
 Keine Anforderungen.
 Folgende Anforderungen:
| |
Anforderung an Logging* |
n/a
| |
Art der Datenübertragung |
 ftp
 SMS
 HTTP
 ESB
 Andere: manuelle Übertragung
 
  Â
bahn/project-audit/data/confluence-export/pages/27525811_6.4 Abrechnungssysteme.md
+40
View File
@@ -0,0 +1,40 @@
# 6.4 Abrechnungssysteme
> Confluence Page ID: 27525811
> Version: 82
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.4 Abrechnungssysteme
> Labels:
---
## Ist Zustand
Das System Trassenpreissystem (TPS) ist abgängig und wird aktuell durch das Projekt AbrechnungsCockpit (AC) ersetzt. Die Preisberechnung wird bereits über das AC gekapselt und wird über entsprechende Adaptoren in TPN (Neuverkehrsrabatte) und GFD-Z (Angebotspreise) oder Click&Ride (Angebotspreise) an die Bestellsysteme übermittelt. |
| |   
Service/Komponente   |   
Kurzbeschreibung   |
Kommentar
  
| |
Trassenportal Netze (TPN) |
Über TPN werden Trassenanmeldungen und Trassenangebote zwischen der DB Netz und den Eisenbahnverkehrsunternehmen auf elektronischem Weg übermittelt. Die Kommunikation mit GFD−Z geschieht über eine elektronische Schnittstelle. Trassenanmeldungen mit einer Anfrage für Neuverkehrsrabatte (NVR) werden über den TPNAdapter weitergegeben. |
Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
| |
Service TPNAdapter |
Der Adapter dient der Anbindung des Altsystems TPN (Trassenportal Netze). Über diesen Adapter werden Anfragen für Neuverkehrsrabatte (NVR) an das Discount Order System (DOS) übertragen. Die Erstellung bzw. Aktualisierung von NVR Anträgen wird über den Adapter Service initiiert und die Belege werden revionssicher gespeichert. Darüber hinaus kann TPN über diesen Service Änderungsbepreisungen an die Abrechnung übermitteln. |
Die Schnittstellenbeschreibung kann über folgenden Link nachgelesen werden.
Die Anbindung des AC an TPN erfolgt indirekt über GFD-Z. Der Service AufbereitungsAbrechnungsInformationTrassen ist implementiert, wird jedoch noch nicht produktiv genutzt (Umsetzung erfolgt aufgrund Architekturweiche). Die Anbindung GFD-Z erfolgt für die Preisberechnung und Abrechnung über den Service GFD-ZAdapter.
| |
Discount Order System |
Das Discount Order System ist eine Webapplikation, welche in das Abrechnungscockpit integriert ist und Anträge zur Neuverkehrsrabatten verwaltet. |
Die Anbindung ist über GFD-Z vorgesehen, derzeit aber noch nicht implementiert. Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
| | GFD-ZAdapter | Der GFD-Z Adapter empfängt die Preisanfrage und transformiert den Request in ZugTrassenVarianten. | Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
| | GFD-Z: Preisanfrage für  Angebotserstellung | In diesem Kontext sendet GFD-Z Preisanfragen, um die Angebote zu vervollständigen. | Die Schnittstellenbeschreibung kann unter folgendem Link nachgelesen werden.
| | Click&Ride | AC- PreisVerwaltungTrasse.ermittleTrassenpreis |
Die Click&Ride – App nutzt die aktuelle Serviceoperation PreisverwaltungTrasse.ermittleTrassenpreis, als Datenmodell wird aktuell ITOM verwendet. Zukünftig wird für das Bestellsystem diese Schnittstelle verwenden. Die Änderung an dem AC Service werden zu einem Change Request führen.
Prozessschritt "Trassenpreis ermitteln pro Zugtrasse" (siehe Prozess-Schritt 71):
Ermitteln der einzelnen Trassenpreise durch Aufruf eines Webservices des Abrechnungscockpits.
Implementierter Service: com_dbnetz_neXt_PSS_g_V01._01.pub.angebotsAnfrageMain:ermittleTrassenpreise
https://wiki.intranet.deutschebahn.com/wiki/display/neXtlab/ProzessSteuerung.PhaseG
bahn/project-audit/data/confluence-export/pages/27525816_6.5 Bereitstellung von Stammdaten IST Zustand.md
+20
View File
@@ -0,0 +1,20 @@
# 6.5 Bereitstellung von Stammdaten IST Zustand
> Confluence Page ID: 27525816
> Version: 30
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.5 Bereitstellung von Stammdaten IST Zustand
> Labels:
---
GFD-I ist eine Anwendung zur Erfassung und Pflege von Daten zur Gleis- und Streckeninfrastruktur der DB Netz AG. In GFD-I werden im Ist-Zustand außerdem weitere Stammdaten von DaViT gepflegt (Geschäftspartner, Triebfahrzeug-Stammdaten und weitere sog. „Schlüsselwerte“).
| |
Rahmendatenzugriff |
GFD-I FahrplandatenhaltungInfrastruktur |
Abruf bestimmter Stammdaten (sog. Schlüsselwerte), z.B. Betriebsstellen, Fahrplanperioden, Geschäftspartner, Triebfahrzeugbaureihen und deren Eigenschaften.
Aktuell werden die Stammdaten über eine Excel Liste an TPN bzw. die EVU SST übermittelt. Folgende Stammdaten aus GFD- I werden für TPN bereitgestellt: Stammdaten_2017_08_TPN 
 Stammdaten 2019
bahn/project-audit/data/confluence-export/pages/27525834_4.4.4.4 Netzmonitor und SAPBIne.md
+193
View File
@@ -0,0 +1,193 @@
# 4.4.4.4 Netzmonitor und SAPBIne
> Confluence Page ID: 27525834
> Version: 42
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/4 Anforderungen an das neue Bestellsystem der DB Netz/4.4 Soll-Schnittstellen Bestellsystem (Consumer oder Provider)/4.4.4 Anbindung an den Fahrplan und das Kapazitätsmanagement/4.4.4.4 Netzmonitor und SAPBIne
> Labels:
---
## Einführung 
Im Rahmen des neuen Bestellsystems ist geplant, eine API anzubieten, die es ermöglicht, den Datenbestand für nachfolgende Business Intelligence Systeme (Drittsysteme) bereitzustellen. Diese API soll die bereitgestellten Daten jedoch nicht systemspezifisch aufbereiten, sondern die Daten in einer standardisierten Objektmodell-Struktur zur Verfügung stellen.
Hierzu wird es über einen Service AuftragsDatenBereitstellung (Pull) möglich sein, durch Angabe von Zeiträumen dedizierte Datensätze abzufragen. Das Datenformat wird das vom Bestellsystem verwendete Objektmodell beinhalten (TAF/TAP Objektmodell). Der Service soll mit SLA 3 betrieben werden.
Die abnehmenden Systeme können sich an diese Schnittstelle anbinden, um die Auftragsdaten des Bestellsystems zu beziehen. Die Aufbereitung und Auswertung dieser Daten für definierte Business Intelligence Auswertungen (Reports) ist nicht Bestandteil der angebotenen Schnittstelle vom Bestellsystem.
Im Folgenden ist ein Systemkontext des Services, über den beliebige BI Systeme angebunden werden können, abgebildet. Derzeit sind zwei Systeme vorgesehen.
Hinweis: Das Projekt Bestellsystem stellt die entsprechenden Daten zur Auswertung den jeweiligen Nutzern zur Verfügung. Anpassungen an den BI Systemen Netzmonitor und SAPBine sind nicht Teil des Projekts Bestellsystem.
## Netzmonitor 
- Das Bestellsystem stellt eine Schnittstelle im TAF/TAP Format zur Verfügung. Diese stellt die vertrieblichen Auftragsdaten in einem festgelegten Format (TAF/TAP-TSI-nah) bereit, von den fachlichen Inhalten angelehnt an die bisherige Schnittstelle. 
- Netzmonitor wird auch nach 2023 bestehen bleiben. 
- Ungeklärt ist im Rahmen der Konzeptionsphase des Bestellsystem, ob Netzmonitor die vom Bestellsystem geplante API nutzt und/ oder die Daten aus der Komponente Trassenverwaltung von BaDiFa beziehen wird.
- Arbeitsannahme vom Projekt Bestellsystem:
- Die Kosten zur Anpassung bei Netzmonitor werden nicht vom Projektbudget Bestellsystem finanziert.
## SAPBIne 
- Das Bestellsystem stellt eine Schnittstelle im TAF/TAP Format zur Verfügung. Diese stellt die vertrieblichen Auftragsdaten in einem festgelegten Format (TAF/TAP-TSI-nah) bereit, von den fachlichen Inhalten angelehnt an die bisherige Schnittstelle. 
- SAPBine wird nach 2023 bestehen bleiben. Derzeit nutzen 3000 User das System, ein Hauptnutzer ist z.B. Station&Service. SAPBine ist auch für den Vertrieb ein versorgendes System, es bedient die Schnittstelle IBL (Informationssystem Betriebsleistung). Die IT-Anwendung IBL ist in SAP BI integriert und dient der Ermittlung und Bereitstellung der Betriebsleistungsstatistik für die Abrechnung. 
- ab dem Zeitpunkt März 2023 müssen Reports über SAPBINe bereitgestellt werden 
- eine Anpassung muss bei SAPBINe erfolgen.
- Im Rahmen der Konzeptionsphase des Bestellsystems ist ungeklärt:
- Ob und welche Reports hinsichtlich Fahrplandaten über SAPBINe ab März 2023 bereitgestellt werden sollen.
- Ob SAPBINe die vom Bestellsystem geplante Schnittstelle nutzt und/ oder die Daten aus der Komponente Trassenverwaltung von BaDiFa beziehen wird.
- Wer die Kosten für die notwendigen Anpassungen von SAPBINe (und ggf. der Folgesysteme) finanziert, sofern vertriebliche Reports auf dem neuen Datenmodell von TAF/TAP-TSI erstellt werden müssen. 
- Arbeitsannahme vom Projekt Bestellsystem:
- Die Kosten zur Anpassung bei SAPBINe werden nicht vom Projektbudget Bestellsystem finanziert.
 
## Nichtfunktionale Aspekte
| |
Vertraulichkeit |
11
incomplete
 sehr hoch
12
incomplete
 hoch
13
incomplete
 mittel
14
incomplete
 niedrig
| |
Integrität |
15
incomplete
 sehr hoch
16
incomplete
 hoch
17
incomplete
 mittel
18
incomplete
 niedrig
| |
IT-Sicherheit |
n/a
| |
Nachvollziehbarkeit |
n/a
 
 
| |
Verfügbarkeit
| |
Robustheit der Schnittstelle |
 Keine Anforderungen.
 Folgende Anforderungen: | Kommentar
| |
Servicelevel* |
31
incomplete
 SL 1 Plus
32
incomplete
 SL 1
33
incomplete
 SL 1 Basic
34
incomplete
 SL 2
35
complete
 SL 3 Plus
36
incomplete
 SL 3
|
  |
| |
Logging
| |
Anforderung an Logging* |
 
  |
| |
Übertragungsverfahren
| |
Schnittstellenart* |
37
incomplete
 Datenablage in Datei, Pfad: manuelle Festlegung
38
complete
 Webservice: 
39
incomplete
 SMS-Nachricht, Nummer:
40
incomplete
 gemeinsame Datenbank:
41
incomplete
 Online-Transaktion:
42
incomplete
 Andere: Dateiversand via Email
| |
Transaktionssicherheit* |
 Keine Anforderungen.
 Folgende Anforderungen:
| |
Anforderung an Logging* |
n/a
| |
Art der Datenübertragung |
 ftp
 SMS
 HTTP
 ESB
 Andere: manuelle Übertragung
Â
bahn/project-audit/data/confluence-export/pages/27525836_6.9 RNE Common Interface.md
+124
View File
@@ -0,0 +1,124 @@
# 6.9 RNE Common Interface
> Confluence Page ID: 27525836
> Version: 29
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.9 RNE Common Interface
> Labels:
---
 Für den Austausch von TAF/TAP-TSI-konformen Nachrichten zur Unterstützung der europaweiten Interoperabilität muss das neue Bestellsystem bestimmte Schnittstellen anbieten, bzw. anbinden. Die Schnittstellen-Spezifikation wird nachfolgend beschrieben. Anschließend wird die RNE-Referenzimplementierung vorgestellt und bewertet. 
## Technische Spezifikation Common Interface (CI)
Die TAF-TSI-Verordnung (Siehe TAF-TSI-Verordnung, Commission Regulation 1305/2014) beschreibt im Abschnitt 4.2.12. Vernetzung und Kommunikation eine gemeinsame Architektur für den TSI-konformen Datenaustausch der beteiligten Eisenbahnunternehmen (EVUs und EIUs).
Die dort beschriebene Architektur adressiert die Aspekte:
- Vernetzung der Akteure mittels eines hybriden Peer-to-Peer Kommunikationsmodells und einer Nachrichten-Schnittstelle (ausführlich beschrieben in TAF TSI — Anhang D.2: Anlage F — Modell für TAF-TSI-Daten und -Meldungen)
- Sicherheit des Datenaustauschs (Verschlüsselung und Signatur für ausgetauschte Nachrichten)
- Zentralspeicher für Metadaten und Verwaltung der öffentlichen Schlüsseln (Publik-Key-Infrasktruktur und Zertifizierungsbehörde).
- (verbindliche) Gemeinsame Schnittstelle zur Unterstützung der Interoperabilität. Dadurch wird anderen Akteuren ein einheitlicher Zugang zu allen TSI-Daten gewährleistet. 
Vor allem die Gemeinsame Schnittstelle liegt im Fokus des Projekts Bestellsystem. Laut TAF-TSI-Verordnung gilt:
Eine gemeinsame Schnittstelle muss Folgendes verarbeiten können:
- Formatierung abgehender Meldungen anhand der Metadaten,
- Signatur und Verschlüsselung abgehender Meldungen,
- Adressierung abgehender Meldungen,
- Überprüfung der Authentizität eingehender Meldungen,
- Entschlüsselung eingehender Meldungen,
- Konformitätsprüfungen eingehender Meldungen anhand der Metadaten,
-
Behandlung des gemeinsamen Zugangs zu den verschiedenen Datenbanken.
Die technische Spezifikation der Schnittstelle erfolgt im TAF-TSI - ANNEX D.2: APPENDIX E - COMMON INTERFACE (zusätzlich zum Nachrichtenformat im Apendix F).
Es wird eine mehrstufige Architektur für die Verarbeitung der TSI-Nachrichten vorgeschlagen (Nummern verweisen auf Abschnitte der TAF-TSI Verordnung):
Die Architektur behandelt folgende Funktionalitäten:
- API Adaptors
- Translation and Validation
- Metadata System
- Security and Transport
- XML (Messages)
- Generic API
- Message Queueing
- Data Compression
- Admin UI
Es werden folgende nicht-funktionale Anforderungen adressiert:
- Capacity: up to 1000 partners
- Stress: 100 (nominal) – 200 (peak) msgs/sec, with delay of 500 (90 ) - 2000 (max) ms
- Availability: 99,9
- Internet resource utilization: 600 kb/s (~ 30 msgs/s)
- Computer resource utilization: <50  CPU load for 5 legacy applications
Die eigentliche Kommunikation zwischen den einzelnen TSI-Teilnehmern (also EVUs und EIUs) erfolgt über einen Web Service.
Der Web Service basiert auf SOAP (Simple Object Access Protocol) mit XML als Datenaustauschformat.
Weitere Informationen zum Common Interface beschreibt das TAP-TSI and TAF-TSI - Sector Handbook for the Communication between Railway Undertakings and Infrastructure Managers  (RU/IM Telematics Sector Handbook). Hier wird zum einen die übergreifende RU/IM Architektur skizziert:
Es kann entweder die von der RNE zu entwickelnde Referenzimplementierung eingesetzt werden oder eine Eigenentwicklung vorgenommen werden. Eine Eigenentwicklung empfiehlt sich für neu entwickelte TAF/TAP-TSI-konforme Systeme, während Alt-Systeme mittels Referenzimplementierung angebunden werden könnten (siehe auch die Bewertung der Referenzimplementierung weiter unten).
Analyse:
Die Kommunikation erfolgt im Push-Verfahren, d.h. dass jeder Netzwerkteilnehmer jeden potentiellen Netzwerkteilnehmer kennen muss, um ihm Nachrichten zustellen zu können. Im Falle der DB Netze müssen der CI Endpunkt von jedem EVU bekannt sein, um dessen Trassenanfragen beantworten zu können. 
Die TAF/TAP-TSI-Architektur verwaltet die Liste der registrierten Eisenbahnunternehmen (Company Codes), verzichtet aber auf eine gemeinsame Registry der zugehörigen CI Endpunkte. Stattdessen werden ausdrücklich bilaterale Abstimmungen über die Endpunkte zwischen den einzelnen Teilnehmern gefordert. Dies können ca. 1000 Partner pro Teilnehmer sein (vgl. nicht-funktionale Anforderungen oben und die mehr als 400 EVUs in Deutschland).
## RNE CCS - Common Components System
Die TAF-TSI-Common Components Group bietet (mit RNE als Auftragnehmer) eine Referenzimplementierung für das Common Interface an. Diese kann, muss aber nicht, von den einzelnen Eisenbahnunternehmen eingesetzt werden. Im letzteren Fall muss eine kompatible Implementierung seitens des Eisenbahnunternehmens eingesetzt werden.
Die Referenzimplementierung wird zusammen mit weiteren Komponenten als Common Components System bezeichnet. Das sind im Einzelnen:
- Common Reference Files Database (auch CRD für Central Repository Domain) für den Austausch der Stammdaten,
- Common Interface (CI) Implementierung inkl. Adapter für Bestandssysteme,
- Certification Authority (CA) für die Ausstellung und Verifikation der Zertifikate, wodurch TSI-Nachrichten verschlüsselt und verifiziert werden können.
Dabei werden die CRD und CA zentral von RNE betrieben, die konkrete von RNE erstellte CI-Implementierung wird wiederum sowohl von RNE selbst (z.B. im Falle von PCS bzw. dessen Nachfolger) als auch von EVUs und EIUs, die kein eigenes CI implementieren, genutzt. 
CI-Implementierungen kommunizieren mit (relevanten) anderen CI-Implementierungen sowie mit der CA (Zertifikat-Validierung) und ggf. mit dem CRD  zur länderübergreifenden Stammdaten-Synchronisation.
Die von der CA ausgestellten Zertifikate werden manuell beantragt und in der jeweiligen CI-Implementierung hinterlegt.
## CRD - Common Reference File Database
Folgende Daten werden vom CRD verwaltet und verteilt, entweder per manuellem Download oder über einen Webservice:
- Location Reference Files (stations, customer sidings, loading, places)
- Partner Reference files (company codes)
- TAF-TSI-Metadata (XML Schemas für Nachrichtenaustauch)
## Annahmen:
-
## Der Upload der nationalen (deutschen) Daten zum CRD ist nicht im Scope des Projekts Bestellsystem.
- Der Abgleich der XML Schemas erfolgt manuell, da diese in der Regel nur bei der Weiterentwicklung des TSI-Standards notwendig werden und somit ohnehin eine Anpassung des Bestellsystems erfordern.
- Ein automatisierter Abgleich der Referenz-Daten, vom CRD zum Bestellsystem, ist nur bedingt sinnvoll, da sich diese vermutlich selten ändern werden und zum anderen eine Qualitätssicherung gewünscht sein kann. Es wäre denkbar diese automatisiert abzuholen, um dann nach manueller Prüfung (ggf. auf Testumgebungen) in die Produktion einzuspielen, dies wird aber nicht Teil des MVPs des Bestellsystems sein.
## CA - Certification Authority
Die sichere Kommunikation zwischen den TSI-Teilnehmern wird mithilfe von digitalen Zertifikaten sichergestellt (X.509, vgl. https://docs.microsoft.com/en-us/previous-versions/tn-archive/bb123848(v=exchg.65)). Diese werden zentral von RNE CA vergeben, die wiederum von teilnehmenden IT-Systemen als "Trusted Authority" anerkannt werden müssen.
Die Zertifikate dienen der SSL/TLS Kommunikation zwischen den einzelnen CI's und CRD. Sie erlauben auch eine (optionale) Verschlüsselung und Signierung der Nachrichteninhalte.
Es sollen ausschließlich die von der RNE ausgestellten Zertifikate zum Einsatz kommen.
## Analyse:
Bei X.509-Zertifikaten und deren Einsatz in SSL/TLS sowie zur Verschlüsselung von Nachrichten handelt es sich um Industrie-Standards, die von der eingesetzten Software unterstützt werden müssen. Eine Verschlüsselung auf Transportebene gewährleistet eine sichere Übertragung, eine separate Verschlüsselung auf Nachrichtenebene über PKI Verfahren ist aufwendig, verlangsamt die Kommunikation und ist nicht empfehlenswert.
Aus technischer Sicht ist es unerheblich, ob Zertifikate nur von RNE oder auch von anderen Quellen CAs kommen, solange diese als Trusted Authority in der Software (z.B. Java Keystore) registriert werden.
## CI - Common Interface Implementation
Die von der RNE entwickelte und (mit Lizenz) verfügbare Referenzimplementierung ist im folgenden beschrieben.
Das Software-Paket kann von EVU bzw. EIU lokal installiert und konfiguriert werden. RNE CI agiert als Adapter (Local Instance) zwischen den Bestandssystemen (Legacy Systems) und anderen TSI-Teilnehmern (Remote CI). Die letzteren können die CI Referenzimplementierung oder eine eigene Implementierung des CI sein.
Das RNE CI enthält folgende Komponenten:
- CI Web Service für eingehende und ausgehende Nachrichten inkl. Verschlüsselung, Signieren, Kompression
- Verwaltung der Metadaten (Schemas und Referenzdaten) sowie der Zertifikate und zusätzliche privater Stammdaten
- Konnektoren für Bestandssysteme (FTP, Dateien, JMS, SMTP, WebServices)
- Routing-Regeln für die Weiterleitung zwischen den internen und externen Systemen
- Mapping der TAF-TSI-Daten auf interne Datenformate (z.B. UIC 407-1) sowie manuelle (graphische) Mappings auf andere XML Datenformate
Analyse:
Die RNE CI Implementierung liegt aktuell in Version 2.1 vor.
Das RNE CI unterstützt aktuell noch nicht den redundanten skalierbaren Betrieb mehrerer Instanzen mit Ausfallsicherheit, siehe auch das Dokument Common Interface Performance & Hardware Recommendation, Version 1.3, Kapitel 5.4. RNE Common Component Normal Deployment with Load Balancer and Failover:
This deployment option is not yet practically implemented and tested yet. 
Das RNE CI erlaubt den Betrieb und Konfiguration verschiedener CI-Instanzen pro Kommunikationspartner. Diese statische Zuordnung ist allerdings inflexibel verglichen mit der längst üblichen dynamischen Lastverteilung mittels Load Balancer.
Analyse:
Die fehlende Unterstützung der oben genannten nicht-funktionalen Anforderungen stellt ein erhebliches Risiko dar.
Der Technologiestack von RNE CI umfasst unter anderem Wildfly 14.0.1 und MySQL 5.7. Der letztere wird nur bis 2023 unterstützt (vgl. https://endoflife.software/applications/databases/mysql). Für Wildfly 14.0.1 endet der reguläre Support im Februar 2023 (vgl. https://access.redhat.com/support/policy/updates/jboss_notes).
Der Hauptanwendungsfall des RNE CI liegt auf der Integration der (unveränderten) Bestandssysteme in die TSI-Kommunikation. Dies erfolgt mithilfe der Konnektoren, Datenmappings und Routing-Regeln. Dies unterscheidet sich grundlegend vom Scope des Bestellsystems, das eine TAF/TAP-TSI-konforme Integration vom Vertrieb über den Fahrplan bis in den Betrieb ausgeht.
Der Einsatz des RNE CI stellt ein hohes Risiko bzgl. der Flexibilität und Time-To-Market dar, da eine Unterstützung der neuen Funktionen und Fehlerbehebung stets seitens RNE erfolgen muss. Ein kritisches Bespiel hier ist die Unterstützung, der noch nicht final verabschiedeten CaseReference-Objekte, die für nationale Erweiterungen des TSI-Standards von entscheidender Bedeutung sind.
Entscheidung:
Für erste Tests mit Kommunikationspartnern kann das RNE CI für das neue Bestellsystem initial verwendet werden, um eine TSI-konforme Implementierung der Bestellsystem-CI sicherzustellen. Eine eigene DB Netz Implementierung sollte jedoch durch das Projekt sichergestellt werden.
Begriffsdefinitionen:
- TSI - Technical Specification for Interoperability
- CRD -  Common Repository Domain: Europa-weite Metadaten, die im Central Reference Files Database des RNE verwaltet werden. Der letztere wird häufig ebenfalls als CRD bezeichnet.
- CA - Certification Authority: Service zur Ausgabe und Verifikation von digitalen Zertifikaten
- CI - Common Interface: Spezifikation einer gemeinsamen Schnittstelle für den Austausch von TSI Nachrichten
- RNE CI - Common Interface Reference Implementation: die von RNE entwickelte Integrationslösung für TAF/TAP TSI
- CCS - Common Components System: 
- LI - Local Instance: eine konkrete Installation des RNE CI
- UIC-Common Component: Synonym für RNE CI
bahn/project-audit/data/confluence-export/pages/27525850_6.6 Anlagenportal Netz APN-plus.md
+27
View File
@@ -0,0 +1,27 @@
# 6.6 Anlagenportal Netz (APN+)
> Confluence Page ID: 27525850
> Version: 11
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/6 IT Ist-Analyse/6.6 Anlagenportal Netz (APN+)
> Labels:
---
Die Nutzung des Anlagenportal-Netz ist ein kostenloser Service, den die DB Netz AG allen Zugangsberechtigten anbietet. Diese beinhalten Abstell- und Zugbildungsanlagen, Zusatzausstattungen, Ladestellen und Dispositionsgleise. Diese können sowohl für das kommende Netzfahrplanjahr als auch im aktuellen und zukünftigen Gelegenheitsverkehr angemeldet bzw. bestellt werden.
Anbei eine Übersicht über die Serviceeinrichtungen der DB Netz AG: Serviceeinrichtungen
Die Suche nach Serviceeinrichtungen bietet einen Überblick über das gesamte Angebot an Serviceeinrichtungen. Als Nutzer hat man Einblick, in welcher Betriebsstelle welche Serviceeinrichtungen vorhanden sind, welche Ausstattungsmerkmale sie aufweisen und was ihre Nutzung kostet.
Angebote
In der Angebotsphase werden alle Angebote aus Anmeldungen zum Netzfahrplan je Kundennummer aufgelistet. Alle Serviceeinrichtungen können in der Detailsicht gesamthaft oder einzeln angenommen oder abgelehnt werden.
Warenkorb
In der Anmeldephase zum Netzfahrplan kann man Serviceeinrichtungen in den Warenkorb schieben, um sie dann gesammelt zu überprüfen, bevor sie final anmeldet werden. In der Navigation kann man direkt über den persönlichen Bereich zum Warenkorb gelangen oder nach Spezifikation der Anmeldedetails. Über die Änderungsfunktion im Warenkorb gelangt man zurück in die Anmeldedetails, um sie dort zu bearbeiten.
## Überblick - Nutzungswünsche für Serviceeinrichtungen online anfragen
https://fahrweg.dbnetze.com/fahrweg-de/kunden/leistungen/anlagen/anlagenbestellung/anlagenportal_netz-1369304
Die Bestellung von Serviceeinrichtungen soll perspektivisch in das Bestellsystem übernommen werden, wird jedoch nicht Teil des MVPs sein.
bahn/project-audit/data/confluence-export/pages/27525865_9.2 Projekttools.md
+22
View File
@@ -0,0 +1,22 @@
# 9.2 Projekttools
> Confluence Page ID: 27525865
> Version: 10
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.2 Projekttools
> Labels:
---
In M31 werden folgende Tools verwendet:
 
- SharePoint zur zentralen Dokumentenablage und zur gemeinsamen Dokumentenbearbeitung. Darüber hinaus Projektkalender und kurzfristige Ankündigungen sowie Linksammlung.
- Jira als Sammlung des Product Backlogs mit Epics, Capabilities, Features/Enabler und Storys/Enabler. Darüber hinaus Erfassung von einzelnen Aufgaben, Bugs, Risiken und Impediments.
- Zentrales Mail-Funktionspostfach mit diversen E-Mail-Verteilern je Team M31; dient u. A. zur Verteilung von regelmäßigen Projekt-Statusmails an das Gesamtteam.
- DB Planet für das Projektmarketing. In Zukunft ist geplant, hier auch eine eigene Bestellportal-Anwendergruppe zwecks Informationsaustausch und Diskussion zu etablieren.
- TMT In Zukunft ist geplant für die Erfassung von Defects aus dem System- und Abnahmetest.
- Ontrack als vom Konzern vorgegebenes neues Projektmanagementtool.
- Wiki Confluence 
Eine Fortschrittsmessung erfolgt über Jira (Velocity, Story Points, Hit Rate etc.). Jira bietet dazu folgende Berichtsmöglichkeiten je Umsetzungsteam an, die z. T. in M31 auch genutzt werden: Burndown-Diagramm, Epic-Bericht, Epic-Burndown, Versionsbericht, Release-Burndown, Geschwindigkeits-Diagramm, Kontroll-Diagramm, Kumuliertes Flussdiagramm.
bahn/project-audit/data/confluence-export/pages/27525867_9.3 Mitarbeiter.md
+49
View File
@@ -0,0 +1,49 @@
# 9.3 Mitarbeiter
> Confluence Page ID: 27525867
> Version: 25
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.3 Mitarbeiter
> Labels:
---
Mit Vereinbarung des Projektauftrags stehen alle anbei genannten Rollen im definierten Umfang für die gesamte Projektlaufzeit dem Projekt zur Verfügung. Der VzP-Anteil ist mit der operativen Planung der jeweiligen OEn abgestimmt. Berücksichtigt sind hierbei nur Ressourcen, die aus Projektsicht mindestens mit 20% VzP benötigt werden. 
Bei Ressourcenwechsel ist eine adäquate Vertretung mit gleichem VzP-Anteil zu benennen, so dass alle Rollen im genannten Projektzeitraum durchgängig besetzt sind.
Die anbei aufgelisteten Ressourcen beziehen sich lediglich auf das Vorhaben zur Erstellung eines neuen Bestellsystems. Ggf. werden durch die Einrichtung eines neuen Release Trains "Vertrieb" nach der SAFe-Methodik, weitere Ressourcen notwendig. Diese sind in der nachfolgenden Abschätzung allerdings nicht enthalten, da zum Zeitpunkt der Abstimmung unklar ist, welchen Scope ein möglicher neuer Release Train abdecken soll.
| | Bereich | Rolle | (Initiale) Besetzung | OrgE | Auslastung (VzP) | Kommentar
| | Vertrieb | Product Manager | B. Schmücker | I.NMK 3 | 50% |
| | Vertrieb | Product Owner | B. Schmücker, N.N. | I.NMK 3 | 300% | 3 Umsetzungsteams
| | Vertrieb | Mentor/Experte | diverse (Kundenbetreuer, Fahrplan-Mitarbeiter in den Regionen, u.ä.) | diverse | 50% | 0,5 VZP = 5 Pers. zu je 1 Tag/Monat
| | Vertrieb | Change Manager | N.N. | I.NMK 3 | 50% |
| | Vertrieb | Fachliche BF | N.N. | I.NMK 3 | 20% |
| | CIO | Release Train Engineer | Holger Wiese | I.NVI 3 | 100% |
| | CIO | Scrum Master/PMO | A. Schäfer, (DBS/Extern) | I.NVI 31, extern | 200% | Jeder ScM übernimmt auch PMO-Aufgaben
| | CIO | Anwendungsmanager (Projektbegleitung durch I.NVI 4) | extern | I.NVI 4 | 50% |
| | CIO | Solution Architect | H. Duis | I.NVI 2 | 20% |
Darüber hinaus steht eine Entscheidung bzgl. der Budgetierung des Projekts UGA (Umsetzung gesetzlicher Anforderungen) im Rahmen des aktuellen Planungsprozesses von I.NMK 3 noch aus. Es wird davon ausgegangen, dass mit diesem Projekt das Budget für 3 VZP von I.NMK bereitgestellt werden kann:
- 0,5 VZP Product Manager
- 2 VZP Product Owner
- 0,5 VZP Change Manager
Weitere Ressourcen sind demzufolge im Rahmen der BV zu berücksichtigen und zu beantragen. 
Darüber hinaus werden folgende Ressourcen im Bedarfsfall hinzugezogen: 
- Testmanager Automatisierung (I.NVI 3, ca. 10%)
- Kostenstellenmanager (I.NVI 1, ca. 10%)
Weitere Experten werden bedarfsabhängig hinzugezogen. Dies umfasst beispielsweise die Themengebiete:
- Mitarbeiter aus den Regionalbereichen (insbesondere Kundenbetreuer)
- Recht- und Regulierung
- Fachbetriebsführung und Anwendungsmanagement weiterer Verfahren (TPN, APN,  etc.)
- Fach- und IT-Architektur.
Mit erfolgreichem Abschluss des Projekts und Überführung der Projektergebnisse in den produktiven Betrieb sind folgende Rollen entsprechend dem genannten VZP-Anteil in den jeweiligen Bereichen aufzubauen. Dieser Aufbau ist im Rahmen der Beschlussvorlage vor dem Projektbeginn berücksichtigt.
| | Bereich | Rolle | (Initiale) Besetzung | OrgE | VZP-Anteil | Kommentar
| | Vertrieb | Fachliche Betriebsführung | N.N. | I.NMK 3 | 100% | Productowner Bestellsystem
| | CIO | Anwendungsmanager | N.N. | I.NVI 4 | 20% |
bahn/project-audit/data/confluence-export/pages/27525869-9.4 Aufwands- und Kostenschaetzung fuer das neue Bestellsystem.md
+174
View File
@@ -0,0 +1,174 @@
# 9.4 Aufwands- und Kostenschätzung für das neue Bestellsystem
> Confluence Page ID: 27525869
> Version: 65
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/9 Weiteres Vorgehen und Kostenindikation/9.4 Aufwands- und Kostenschätzung für das neue Bestellsystem
> Labels:
---
## 9.4.1 Kostenindikation im Rahmen von Magic Estimation für das neue Bestellsystem 
Am 20. und 21. August 2019 wurde im Rahmen eines zweitägigen Workshops mit der agilen Schätzmethodik Magic Estimation eine Kostenindikation für die voraussichtlichen Projektumsetzungs- und anschließenden Betriebsführungskosten hergeleitet, die als Expertenschätzung zu bewerten ist. Als Baseline für die Schätzung wurde der zu diesem Zeitpunkt existierende Stand des Product Backlogs herangezogen, in dem sich zu dieser Zeit 75 Features befunden haben. Die Baseline der geschätzten Features lässt sich in einem entsprechenden Excel-Dokument nachvollziehen.
Das Team, welches die Schätzung durchgeführt hat, bestand insgesamt aus 6 Personen (davon 4 projektexterne Personen), die unterschiedliche Kompetenzen aufweisen. Vertreten waren die Kompetenzen von Entwicklern, technischen Architekten sowie ein UX-Experte. Begleitet wurde die Schätzung vom Product Owner und den im Vorprojekt mitwirkenden Business Analysten, die insbesondere durch die Klärung von Verständnisfragen und Festlegung von fachlichen Annahmen, Unklarheiten im Rahmen der Schätzworkshops direkt auflösen konnten.
Aufwände, die im Rahmen der Umsetzung eines Features enthalten sind und pro Feature ausgewiesen werden umfassen Tätigkeiten von
- Scrum Master
- Business Engineers
- Technischen Architekten
- Entwicklern 
- Tester
Der Aufwand und die Komplexität eines Features für die genannten Tätigkeiten wird anhand von T-Shirt-Größen eingeschätzt, die anschließend in Story Points umgerechnet werden:
| | T-Shirt-Größe | Story Points
| | XS | 10
| | S | 15
| | M- | 35
| | M | 60
| | M+ | 90
| | L | 115
| | XL | 300
Um eine Abschätzung zu erhalten, wie viel Personentage sich ungefähr hinter einem Story Point verbergen, wurden 4 Referenz-Features aus einem TPN-Projekt vom Expertenteam geschätzt. Da für diese Referenz-Features die tatsächlichen Umsetzungskosten bekannt sind, lässt sich hierdurch eine Umrechnung herleiten. Es ergibt sich ein Umrechnungsfaktor von 2,27 PT pro Story Point. Die vollständige Herleitung und Umrechnung lässt sich im Dokument FeatureListeBestellSystem_Schätzung sowie im Begleitdokument Bestellsystem - Magic Estimation Ergebnisse nachvollziehen.
Darüber hinaus wurde ein durchschnittlicher Tagessatz pro PT hergleitet, indem die aktuellen Ressourcen-Kosten eines Scrum Masters, Business Engineers, technischer Architekt, Entwickler und Tester, entsprechend der DB Systel Tagessätze gemittelt wurden. Es ergibt sich ein Kostensatz in Höhe von 952 EUR pro PT. Auch diese Herleitung kann in den zuvor genannten Dokumenten nachvollzogen werden.
Darüber hinaus wurden Aufwände ermittelt, die als Aufschlag in der Kostenindikation ausgewiesen werden. Diese umfassen
- Release-Kosten (Annahme: 4 Releases)
- LuP Test (Annahme: Durchführung pro Release)
- Pentest (Annahme: Durchführung pro Release)
- Umgebungskosten (während der Projektlaufzeit)
- technische Betriebsführung (von 11/ 2022 - 04/ 2023)
- SAFe Organisation (Aufwände für Ressourcen auf Release Train Ebene, 2 Systemarchitekten, 1 Projektleiter, 1 Testmanager, durchschnittlicher Tagessatz 1.213,50 EUR)
- Einheitsaufschlag DB Systel / Querschnittskosten (Annahme: 10% der Features, Onboarding und SAFe Organisation)
- Aufwände für On- und Offboarding von Mitarbeitern während der Projektlaufzeit (Annahme: 10% der Feature-Kosten)
- Umsetzungspuffer (Annahme: 15 % der Feature-Kosten)
- Risikoaufschlag (Annahme: 10% der Gesamtkosten)
In Summe ergeben sich durch diese Kostenindikation Gesamtkosten in Höhe von ca. 24.035.000 EUR*, die sich wie folgt aufgliedern:
| | Position | Betrag | Annahmen
| | Umsetzungskosten (Features) Bestellsystem | 12.020.485 EUR | Features enthalten die Aufwände für Umsetzung und Test, inkl. BE, TA, SM, Tester
| | Release-Kosten | 120.000 EUR | Pro Release, Annahme - Defekt und Analyseunterstützung durch Entwicklung
| | Lup Test, Pen-Test | 400.000 EUR |
LuP Test enthält Personalkosten zur Vorbereitung, durchführung und Betreuung pro Release;
Pentest erfolgt im Rahmen von Releases und enthält die Sicherheitsanalyse sowie externe Diensteistungen für die Durchführung
| | Umgebungskosten | 1.038.000 EUR | bis einschl. Ende 2023
| | Technische Betriebsführungskosten (von 11/ 2022 - 04/ 2023) | 125.000 EUR | 6 Monaten - Nur für Produktionsumgebung
| | Ressourcen für SAFe Organisation | 3.300.720 EUR | Safe Organisation 40 Monaten - 01.2020-04.2023 
| | Einheitsaufschlag DB Systel | 1.652.000 EUR |
| | Puffer (Onboarding/ Offboarding + Umsetzungspuffer) | 3.194.000 EUR |
| | Risikoaufschlag | 2.185.000 EUR |
| | Summe Kostenindikation Gesamtkosten  | 24.035.000 EUR* |
*) Keine Erhöhungen der Tagessätze in Folge der Projektlaufzeit berücksichtigt
## 9.4.2 Team-Zusammenstellung-Personalkosten
Entsprechend der vorangegangenen methodischen Kostenindikation unter 9.4.1 kann die nachfolgende Team-Zusammenstellung für die Projektumsetzungsphase empfohlen werden. Durch diese Team-Zusammenstellung konnte eine alternative, grobe Kostenindikation angenähert werden, die die oben genannte Indikation plausibilisieren konnte.  
Hieraus lässt sich im Zeitraum 01/ 2020 - 04/ 2023 eine Gesamtsumme von 25,1 Mio. EURO für Personalkosten herleiten. Die detaillierte Herleitung kann im Dokument Kalkulation_Ressourcen_Bestellsystem nachvollzogen werden.
Team 1 
| | Ressource | Einsatz ab | Einsatz bis | VzP
| | Business Analyst | 15.01.2020 | 30.04.2023 | 1
| | Technischer Architekt | 15.01.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Tester | 15.01.2020 | 30.04.2023 | 1
| | Scrum Master | 15.01.2020 | 30.04.2023 | 1
Team 2
| | Ressource | Einsatz ab | Einsatz bis | VzP
| | Business Analyst | 15.01.2020 | 30.04.2023 | 1
| | Technischer Architekt | 15.01.2020 | 30.04.2023 | 1
| | UI-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | UI-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | UI-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 15.01.2020 | 30.04.2023 | 1
| | Tester | 15.01.2020 | 30.04.2023 | 1
| | Scrum Master | 15.01.2020 | 30.04.2023 | 1
Team 3
| | Ressource | Einsatz ab | Einsatz bis | VzP
| | Business Analyst | 01.09.2020 | 30.04.2023 | 1
| | Technischer Architekt | 01.09.2020 | 30.04.2023 | 1
| | UI-Entwickler | 01.09.2020 | 30.04.2023 | 1
| | UI-Entwickler | 01.09.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 01.09.2020 | 30.04.2023 | 1
| | Backend-Entwickler | 01.09.2020 | 30.04.2023 | 1
| | Tester | 01.09.2020 | 30.04.2023 | 1
| | Scrum Master | 01.09.2020 | 30.04.2023 | 1
Querschnitt-Ressourcen
| | Ressource | Einsatz ab | Einsatz bis | VzP
| | UX-Designer | 15.01.2020 | 30.04.2023 | 1
| | Solution Architect | 15.01.2020 | 30.04.2023 | 1
| | Change Manager | 15.01.2021 | 30.04.2023 | 0,75
| | Anwendungsmanager
(Projektbegleitung durch I.NVI 4) | 15.01.2020 | 30.04.2023 | 0,5
##
9.4.3 Aktivierbarkeit
In Zusammenarbeit mit der Anlagenbuchhaltung (I.NPB) wurde im Rahmen der Konzeptionsphase festgestellt, dass die gesamte Projektumsetzungsphase (Januar 2020 - einschließlich März 2023) zur Erstellung eines Bestellsystems als aktivierbar eingestuft wird. Von den in diesem Zeitraum anfallenden Aufwänden sind keine Teile ausgenommen.
DB Netz interne Ressourcen sind aus diesem Grund in der Projektkalkulation zu berücksichtigen und als GWU-erhöhende Positionen im Rahmen der Beschlussvorlage einzubringen. Notwendig werdende Folgeaktivitäten sind im Rahmen des Umsetzungsprojekts durchzuführen, hierzu zählen u.a. AIB-Nr. beantragen, aktivierungsfähige Kostenstellen beantrage, Tool FAA einrichten und Mitarbeitern zur Verfügung stellen.
Die Bewertung wurde auf Basis einer Checkliste zur Bewertung von Aktivierbaren Eigenleistungen durchgeführt, die von der Anlagenbuchhaltung zur Verfügung und abschließend bewertet wurde. Diese ist zu Dokumentationszwecken auf dem Sharepoint abgelegt.
Es sind daher für folgende Ressourcen die zu berücksichtigenden Kosten zu berechnen. Diese belaufen sich im Zeitraum 01/ 2020 - 04/ 2023 auf insgesamt etwa 2.770.000 EUR, die detaillierte Herleitung kann im Dokument Kalkulation_Ressourcen_Bestellsystem nachvollzogen werden.
| | Ressouce | Organisationseinheit | Einsatz ab | Einsatz bis | VzP
| | Release Train Engineer | I.NVI | 01.01.2020 |
30.04.2023 |
1
| | Scrum Master | I.NVI | 01.01.2020 |
30.04.2023 |
1
| | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1
| | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1
| | Product Owner | I.NMK | 01.01.2020 | 30.04.2023 | 1
| | Product Manager | I.NMK | 01.01.2020 | 30.04.2023 | 0,5
| | Change Manager | I.NMK | 01.01.2020 | 30.04.2023 |
0,5
## 9.4.4 Ermittlung der Gesamtkosten für das Umsetzungsprojekt von 01/ 2020 - 04/ 2023
| | Position | Betrag
| | Umsetzungskosten im Zeitraum 01/ 2020 - 04/ 2023 | 18.695.000 EUR*
| | Einheitsaufschlag DB Systel (Annahme: 6%) | 1.122.000 EUR
| | Puffer (Annahme: 15 % der Umsetzungskosten) | 2.804.000 EUR
| | Release-Kosten (inkl. LuP + Pentest) | 520.000 EUR
| | Umgebungskosten | 1.038.000 EUR
| | Technische Betriebsführungskosten (von 11/ 2022 - 04/ 2023) | 125.000 EUR
| |
Zulieferung von Projekt M13 | 1.000.000 EUR
| |
Zulieferung von Projekt AC-Trasse | 260.000 EUR
| | Zulieferung von CST (KDV + BBZ) | 70.000 EUR
| | PGM (Annahme: 150 TEUR/ Jahr) | 500.000 EUR
| | Miete (Annahme: 150 TEUR/ Jahr) | 500.000 EUR
| | Schulung |
-*
| | Aktivierbare Eigenleistungen | 2.770.000 EUR*
| |
SUMME |
29.405.034 EUR*
*) Aus Projektsicht keine Anwenderschulungen notwendig. Keine Erhöhungen der Tagessätze in Folge der Projektlaufzeit berücksichtigt.
## 9.4.5. Kosten für den Betrieb ab 05/ 2023 
Eine detaillierte Herleitung der ab 05/ 2023 jährlich anfallenden Wartungs- und Betriebsführungskosten kann im Dokument Kalkulation_Sheet RUN-Kosten nachvollzogen werden. Nicht-Produktivumgebungen werden nach anteiliger Bedarfsabschätzung nicht durchgängig bereitgestellt. 
| | Position | ab 05/2023 | Betrag 2024 | Betrag 2025
| | Technische Betriebsführung Bestellsystem |
| 670.000,00 EUR | 670.000,00 EUR
| | Wartungskosten Bestellsystem |
| 3.406.241EUR | 2.806.669 EUR
| | Betreuungsaufwand I.NVI 4 |
| 2 VZP (240.000 EUR) |
Basiswert Wartungskosten Bestellportal
[Annahme: Steigerung um 3% pro Jahr - Verlagerung aus Basiswert]
bahn/project-audit/data/confluence-export/pages/27525871_12 Anhang.md
+114
View File
@@ -0,0 +1,114 @@
# 12 Anhang
> Confluence Page ID: 27525871
> Version: 40
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/12 Anhang
> Labels:
---
## 12.1 Referenzdokumente
Liste aller referenzierten Dokumente wie fachliche Anforderungen oder Schätzdokument, aus dem Kosten und Zeiten für Bewertung übernommen wurde. Quellenangabe der verwendeten Gesetze, Normen und Richtlinien
Alle referenzierten Dokumente sind mit der Vorstudie bereit zu stellen – bei umfangreichen Do­kumenten die relevanten Ausschnitte oder Verlinkungen.
Es gibt 3 wesentliche Quellen:
-      Die Vorstudie wird in Confluence (Kürzel „Wiki“) beschrieben: LINK WIKI
-      Weitere Dokumente liegen im Sharepoint (Kürzel „SP“): LINK SP
-      Die Modellierung erfolgt im Enterprise-Architekt - Kürzel „EAM“) unter „Projekte\Plan- Phase\Bestellsystem“. LINK EAM
 
| |
Nr. |
Inhalt |
Dateiname/Link
| |
1 |
Anforderungen Bestellsystem: |
Baseline_Anforderungen Export aus JIRA 
| |
2 |
Nichtfunktionale Anforderungen an das Bestellsystem: |
Nichtfunktionale Anforderungen Bestellsystem
| |
3 |
Schutzbedarfsfeststellung und Restrisikodeklaration- BS-Z: |
Link zu risk2value 
| |
4 |
Aufwand und Kostenschätzung für das neue Bestellsystem: 
  |
Kalkulation_Ressourcen_Bestellsystem 
FeatureListeBestellSystem_Schätzung
Bestellsystem - Magic Estimation Ergebnisse; 
Kalkulation_Sheet RUN-Kosten.
 
| |
5 |
Schnittstellen Bestellsystem:  |
Excel Datei "Schnittstellendokumentation Vorprojekt Bestellsystem" 
 
| |
6 |
EAM Bestellsystem:  
  |
Neues Bestellsystem Systemkontext.pdf, 
Neues Bestellsystem Architektur in EAM; 
 
| |
7 |
Architekturweiche:   |
Link 
| |
8 |
TAF/TAP TSI : |
Link
Schnittstellendokumentation zu TAF/TAP TSI  
Anlage 1 der EVU SST und das TAF/TAP TSI Konzept
Annex_8.4-TrainID-CaseReferenceFramework_
 
| |
 
9
 
 
  |
EAM Die IT Bebauung wird in einem EAM-Modell |
(EAM.eap) :
Domänenmodell, 
2-DB Netz IT Anwendungen Primärverortung.pdf 
IST Bebauungspläne -Kapazität und Fahrplanmanagement.pdf
Bebauungspläne -Kudeninteraktion - Vertrieb.pdf
| |
10 |
Übergreifendes Fachliches Objektmodell (FOM)
  |
Objektlandkarte - Übersicht.pdf 
 
| |
11 |
Prozessportal DB Netz: |
 Prozessportal der DB Netz AG
| |
12 |
IT IST Analyse:
TPN Architekturbeschreibung
TPN Schnittstellenbeschreibungen
Kaufmännische Systeme, Trassenpreissystem, Schmerzpunkte TPN-GFD-Z |
Link Sharepoint.
 
| |
13 |
Fachkonzept Value Stream FIB
  |
 Value Stream FIB_Fachkonzept.doc;
 
 
| |
14 |
Weitere Konzepte |
DB Systel Technologie-Radars 
Agiles Testkonzept.docx
 
 
Â
bahn/project-audit/data/confluence-export/pages/27525874-13 Abnahmeerklaerungen.md
+74
View File
@@ -0,0 +1,74 @@
# 13 Abnahmeerklärungen
> Confluence Page ID: 27525874
> Version: 3
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/13 Abnahmeerklärungen
> Labels:
---
| |
Besteller/Auftraggeber |
  |
  |
  |
  |
  |
 
| |
  |
  |
OE |
  |
Datum |
  |
Unterschrift (zwingend erforderlich)
| |
CIO |
  |
  |
  |
  |
  |
 
| |
  |
  |
OE |
  |
Datum |
  |
Unterschrift (zwingend erforderlich)
| |
Stakeholder gem. 2.1 |
  |
  |
  |
  |
  |
 
| |
  |
  |
OE |
  |
Datum |
  |
Unterschrift
| |
Stakeholder gem. 2.1 |
  |
  |
  |
  |
  |
 
| |
  |
  |
OE |
  |
Datum |
  |
Unterschrift
## Â
bahn/project-audit/data/confluence-export/pages/27525877_2018-12-06 Besprechungsnotizen.md
+70
View File
@@ -0,0 +1,70 @@
# 2018-12-06 Besprechungsnotizen
> Confluence Page ID: 27525877
> Version: 2
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2018-12-06 Besprechungsnotizen
> Labels: meeting-notes
---
## Datum
## Teilnehmer
-
   
-
Patrick Breun, Jürgen Sievers
## Ziele
-
- Methode im Vorgehen: IT Phasenmodell und Vorgehen im FIB (Feature-Readyness)
- Verantwortungen
- Einsatz Coach Hr. Buse
- Termine
- Optional: Multi-Kanal Architektur
- Gemeinsame Schnittstelle mit dem Betrieb
## Diskussionspunkte
## Methode im Vorgehen
Das Bestellportal läuft unter der Betreuung im FIB
Als Vorgehen soll die Methode des  Agiles Vorprojektes, mit Workshops und dem typischen Ablauf im IT-Phasenmodell, angewendet werden.
QG Idee ist noch nicht durchschritten. Dieses soll Anfang März durschritten werden.
## Verantwortungen
PO soll Benjamin Schmücker sein.
5
complete
Von Analtol Scholz erfolgt eine Zulieferung zu Ansprechpartnern zu den Geschäftsobjekten (darunter verstehe ich einen Ansprechpartner für die Themen Fahrlagen-/Trassenverwaltung und Auftragssteuerung) -> In dem Thema Geschäftsobjekte ist I.NMF1 in der Verantwortung; Todo: Patrick Breun à Stand: Anatol hat die Suche angestoßen, Rückmeldung noch offen
6
incomplete
Hierzu ist auch die I.NVI5 mit einzubinden um die Zuarbeit zu konkretisieren -> ToDo: Patrick Breun bitte auf Rüdiger Wenig zugehen à ehrlicherweise kann ich mit diesem ToDo gerade wenig anfangen. Was genau ist damit gemeint?
## Einsatz Coach Hr. Buse
An einer Beauftragung von Herrn Buse besteht kein Interesse und leider auch kein Budget. Das Vorhaben ist eng geplant und daher ist die Beauftragung eines Coaches schwierig in der Umsetzung.
## Gemeinsame Schnittstelle TAF/TAP/TSI
Zuerst als eine fachliche Schnittstelle betrachten und im laufe des Vorprojektes die konkrete Umsetzung und den Schnitt Vertrieb/Produktion betrachten.
7
incomplete
Termin zur EU Vorab-Kommunikation in den Terminplan aufnehmen. Detailtiefe der Vorab-Kommunikation muss bestimmt werden. Todo: Patrik Breun
Es ist auch der Ergebnistyp der Vorab-Kommunikation zu bestimmen.
Da der Termin aktuell grob mit Anfang/Mitte Q2/2019 abgegeben ist und damit noch vor QG Plan liegt ist dieses bitte als Abhängigkeit/Risiko gesondert im FIB zu betrachten und im Backlog des PO eintragen sein.
Die Vorab-Kommunikation muss über den I.NMK als Anforderung eingereicht werden.
## Multi-Kanal Architektur
Multikanal- Architektur bitte mit einplanen. Im Rahmen der Vorstudie sollen die zu bedienen den Kanäle genauer betrachtet werden.
## Sonstiges
Für die BusinessAnalyse und EnterpriseArchitektur stellt I.NVI 2 jeweils Mitarbeiter zu 40PT (= insgesamt 80 PT in 2019 für die Restarbeiten Idee und agiles Vorprojekt) bereit.
bahn/project-audit/data/confluence-export/pages/27525880_QualityGates.md
+10
View File
@@ -0,0 +1,10 @@
# QualityGates
> Confluence Page ID: 27525880
> Version: 4
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/QualityGates
> Labels:
---
bahn/project-audit/data/confluence-export/pages/27525893_2018-11-27 Besprechungsnotizen.md
+46
View File
@@ -0,0 +1,46 @@
# 2018-11-27 Besprechungsnotizen
> Confluence Page ID: 27525893
> Version: 2
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/14 Besprechungsnotizen Vorstudie/2018-11-27 Besprechungsnotizen
> Labels: meeting-notes
---
## Datum
## Teilnehmer
-
-
-
-
## Ziele
- Durchsprache der Inhalte QG Idee
- Einigung auf Tooling
- Nächste Schritte festlegen
## Handlungspunkte
1
complete
Confluence einrichten und Berechtigungen verteilen
8
complete
Kurzbeschreibung für GBR erstellen
9
complete
Ideenportaleintrag einrichten (Name Projekt und Verantwortlichkeiten)
Mit Erstellen der Inhalte für QG Idee wird ab sofort begonnen.
bahn/project-audit/data/confluence-export/pages/27525896_Besprechungsnotizen.md
+11
View File
@@ -0,0 +1,11 @@
# Besprechungsnotizen
> Confluence Page ID: 27525896
> Version: 4
> Pfad: /pathOS/Kommunikationskanäle, Termine, Besprechungsnotizen pathOS/Besprechungsnotizen
> Labels:
---
Alle Besprechungsnotizen
com.atlassian.confluence.plugins.confluence-business-blueprints:meeting-notes-blueprinte2019063-378a-47e1-8eeb-120824c6d610meeting-notesPlan your meetings and share notes and actions with your team.Meeting notesCreate meeting notemeeting-notes
bahn/project-audit/data/confluence-export/pages/27525916_00_Vorstudie Bestellsystem.md
+10
View File
@@ -0,0 +1,10 @@
# 00_Vorstudie Bestellsystem
> Confluence Page ID: 27525916
> Version: 5
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem
> Labels:
---
bahn/project-audit/data/confluence-export/pages/27525932_2 Rahmenbedingungen.md
+10
View File
@@ -0,0 +1,10 @@
# 2 Rahmenbedingungen
> Confluence Page ID: 27525932
> Version: 2
> Pfad: /pathOS/Start / Vorstudie Bestellsystem/00_Vorstudie Bestellsystem/2 Rahmenbedingungen
> Labels:
---

Some files were not shown because too many files have changed in this diff Show More