ankn
a5f8fb49ab
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.
4.6 KiB
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 | â |