Orchestrator/bahn/project-audit/analysis/iteration-03-team-workflow.md

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