# 26. Teams inkl. TrassenOrder

Version: 1 | Last modified: 2026-05-07T16:51:18.183+02:00
Source: confluence page ID 586388763

---

Team-Landschaft pathOS + TrassenOrder
Stand: 2026-04-30 | Kontext: Reorganisations-Planung

TrassenOrder (TraPo) ist ein Testballon, um zu pruefen ob eine andere Herangehensweise (entkoppelt, UX-first, klein) schneller, besser und sicherer funktioniert als der pathOS-Ansatz (Microservice-Monolith, 167 Repos, 35+ Personen).

Aktuelle Team-Landschaft

Team | Personen | Fokus | Services | Deployment | Besonderheit | 

Team 404 | ~10 | Portal UI + Middleware | 2 (68K LoC) | pathOS Release-Zug | 33% Bug-Rate, kundenseitig | 

Team CIB | ~13 | Prozesse, Camunda, Backend | ~15 (122K LoC) | pathOS Release-Zug | SV-Monolith, Abrechnung | 

Team Zero | ~9 | TAF/TAP Schnittstellen | ~9 (38K LoC) | pathOS Release-Zug | Beste Qualitaet, OPs-Rotation | 

OPs Squad | 2 fest + rot. | Betrieb, Infrastruktur | Infra-Repos | pathOS Release-Zug | Seit PI 39 (ex-STeam) | 

DevOps | ~7 | CI/CD, Tooling, Pipelines | Pipelines, Helm | pathOS Release-Zug | Jan Lubenow = 39% SPOF | 

TrassenOrder (TraPo) | ~5 (klein) | GelV-Portal (UX-first) | 1 (neu) | Unabhaengig! | Testballon, Discovery-Phase | 

TrassenOrder vs. pathOS — Vergleich der Ansaetze

Dimension | pathOS (aktuell) | TrassenOrder (Testballon) | 

Architektur | Microservice-Monolith (synchrone Releases, 167 Repos) | Externes System, eigene Schnittstellen, unabhaengig deploybar | 

Teamgroesse | ~35+ Personen, 5 Teams | ~5 Personen, 1 Team | 

Zielgruppe | Alle EVUs (Experten + Anfaenger) | Kleine EVUs, Ein-Mann-Betriebe ("WhatsApp-Nutzer") | 

UX-Ansatz | 240+ Formularfelder, Experten-Tool | 3 Angaben fuer eine Bestellung, radikal vereinfacht | 

Deployment | Release-Zug (alle Services zusammen) | Unabhaengig, eigener Rhythmus | 

Abhaengigkeiten | Hoch (Kafka, Camunda, 15+ Services) | Minimal (nur API-Schnittstellen zu Primaerquellen) | 

Geschwindigkeit | PI-getaktet (10 Wochen) | Kontinuierlich, Feature-basiert | 

Scope | Netzfahrplan + GelV + ujBau + Abrechnung | Nur GelV (Gelegenheitsverkehr) | 

Phase | Produktiv seit Dez 2025 | Discovery seit Jan 2026, Livegang Q4 2026 | 

Was testet der Testballon?
Hypothesen

Schneller: Kann ein kleines, entkoppeltes Team schneller liefern als ein grosses im Release-Zug?

Besser: Fuehrt UX-first + radikale Vereinfachung zu besserer Nutzerzufriedenheit?

Sicherer: Reduziert Entkopplung das Risiko (kein Dominoeffekt bei Fehlern)?

Wenn der Testballon erfolgreich ist: Das Modell koennte auf weitere Bereiche uebertragen werden (Netzfahrplan, ujBau). Langfristig koennte TrassenOrder das pathOS-Portal abloesen.

Schnittstellen zwischen pathOS und TrassenOrder

Schnittstelle | Richtung | Zweck | 

Trassenanmeldung API | TraPo → pathOS | Bestellung absetzen | 

Stammdaten API | TraPo ← Primaerquelle | Direkt, NICHT ueber pathOS | 

Angebots-Rueckmeldung | pathOS → TraPo | Ergebnis der Konstruktion | 

Trassenfinder | TraPo ← BVU | Routing, Validierung (Fernziel) | 

Architekturentscheidung: TrassenOrder greift auf Primaerquellen direkt zu — nicht ueber eine pathOS-Zwischenschicht. Das vermeidet Abhaengigkeiten vom pathOS Release-Zug.

Implikationen fuer Team-Reorganisation

Szenario | Auswirkung auf pathOS-Teams | 

TraPo erfolgreich → GelV wandert zu TraPo | pathOS kann sich auf Netzfahrplan + ujBau + Abrechnung konzentrieren. Vereinfacht den fachlichen Schnitt erheblich. Click&Ride (ADR-72) wird obsolet. | 

TraPo erfolgreich → Modell wird uebertragen | Weitere kleine Teams fuer spezifische Domaenen. pathOS wird zum API-Backend-Layer. Portal-Team (404) wird langfristig obsolet. | 

TraPo scheitert → GelV bleibt bei pathOS | Keine Aenderung. Click&Ride Anbindung (ADR-72) wird weiter von CIB gebaut. | 

Offene Fragen

Wann ist der Testballon "erfolgreich"? Welche Metriken? (Time-to-Market, Nutzerzufriedenheit, Bug-Rate?)

Wie wird die Schnittstelle zwischen TraPo und pathOS-Backend definiert und versioniert?

Wer pflegt die Schnittstelle langfristig? (API-Vertrag)

Kann das TraPo-Modell auf Netzfahrplan skaliert werden? (Komplexitaet ist dort 10x hoeher)

Was passiert mit Team 404 wenn TrassenOrder das Portal langfristig abloest?

Team-Kennzahlen (Vergleich)

Metrik | pathOS gesamt | TrassenOrder | Faktor | 

Personen | ~35 | ~5 | 7x | 

Services | ~40 aktiv | 1 | 40x | 

Lines of Code | ~260K | ~0 (Discovery) | — | 

Jira-Projekte | 6 (O2C*, TTTI) | 1 (TRAPO) | 6x | 

Release-Frequenz | ~2x/Monat (KTU) | Kontinuierlich (Ziel) | — | 

Bug-Rate | 20-33% | 0% (noch kein Code) | — | 

Deployment-Abhaengigkeiten | Hoch (17+ Umgebungen) | Keine | — |