Der Solution Train

Die meisten Organisationen benötigen die Ebene der großen Lösung nicht. Essential SAFe (ein ART) bewältigt die Mehrheit der Skalierungsszenarien. Sie benötigen einen Solution Train, wenn:

• Das Produkt mehrere ARTs (200+ Personen) zum Entwickeln und Warten erfordert
• Es erhebliche Abhängigkeiten zwischen ARTs gibt, die nicht durch Architektur eliminiert werden können
• Das System Hardware, Firmware oder externe Lieferanten umfasst, die mit Software integriert werden müssen
• Regulatorische Anforderungen eine koordinierte Compliance über mehrere Trains hinweg erfordern

Beispiele für Systeme, die oft Solution Trains benötigen:

• Autonome Fahrzeugplattformen (Wahrnehmung + Planung + Steuerung + Infrastruktur)
• Große Finanzplattformen (Handel + Risiko + Compliance + Daten)
• Telekommunikationssysteme (Netzwerk + Abrechnung + Kundenerlebnis)
• Militär-/Luftfahrtsysteme (Hardware + Firmware + Software + Integration)

Der Schlüsselindikator: Wenn Ihre ARTs ständig voneinander blockiert werden und das Abhängigkeitsmanagement erhebliche RTE-Zeit verbraucht, benötigen Sie möglicherweise die Koordinationsstruktur, die ein Solution Train bietet.

Der Solution Train sitzt über den ARTs und bietet Koordination zwischen ihnen. Seine Struktur spiegelt den ART wider, aber auf einer höheren Ebene:

Solution Train Engineer (STE) — Das RTE-Äquivalent für den Solution Train. Moderiert Ereignisse auf Lösungsebene, managt ART-übergreifende Risiken und stellt sicher, dass die Trains ausgerichtet bleiben. Dies ist eine äußerst anspruchsvolle Rolle, die tiefes technisches Verständnis und außergewöhnliche Moderationsfähigkeiten erfordert.

Solution Management — Das Product-Management-Äquivalent. Definiert die Lösungsvision und Roadmap. Zerlegt große Initiativen in Capabilities, die auf ARTs abgebildet werden. Arbeitet mit dem Product Management auf jedem ART zusammen, um Ausrichtung sicherzustellen.

Solution Architect/Engineer — Definiert die übergreifende Architektur über alle ARTs hinweg. Stellt technische Kohärenz sicher, managt Schnittstellen zwischen Subsystemen und pflegt die architektonische Runway auf Lösungsebene. Muss ART-Autonomie mit systemweiter Konsistenz ausbalancieren.

Solution Backlog — Enthält Capabilities (große Lösungsverhalten, die ARTs überspannen) und Enabler auf Lösungsebene. Capabilities werden in Features zerlegt, die einzelne ARTs implementieren.

Der Solution Train ersetzt nicht die Strukturen auf ART-Ebene – er fügt eine Koordinationsebene darüber hinzu. Jeder ART hat weiterhin seinen eigenen RTE, Product Management und System Architect. Die Solution-Train-Rollen koordinieren über diese ART-Rollen hinweg.

Der Solution Train hat seine eigene Kadenz von Ereignissen, die sich um ART-Ereignisse herum gruppieren:

Pre-PI-Planung (1 Tag, vor der ART-PI-Planung) — Stakeholder auf Lösungsebene richten sich auf die Vision und die wichtigsten Capabilities für das nächste PI aus. Solution Management präsentiert Prioritäten. Solution Architect präsentiert die technische Richtung. ART-übergreifende Abhängigkeiten werden identifiziert. Das Ergebnis fließt in das PI-Planning-Ereignis jedes ART ein.

ART-PI-Planung (2 Tage, wie üblich) — Jeder ART führt seine Standard-PI-Planung durch, aber jetzt informiert durch das Ergebnis der Pre-PI-Planung. ARTs kennen die Prioritäten auf Lösungsebene und die ART-übergreifenden Abhängigkeiten.

Post-PI-Planung (1 Tag, nach der Planung aller ARTs) — Vertreter aller ARTs kommen zusammen, um Pläne auszurichten, verbleibende Abhängigkeiten zu lösen und die PI-Ziele auf Lösungsebene zu erstellen. Der Solution Train führt eine Vertrauensabstimmung über den integrierten Plan durch.

Solution Demo (Ende des PI) — Wie die System Demo, aber auf Lösungsebene. Alle ARTs demonstrieren ihren integrierten Beitrag zur Gesamtlösung. Dies beweist, dass das System End-to-End über alle Trains hinweg funktioniert.

Solution Train Sync (wöchentlich) — STEs und RTEs treffen sich, um die ART-übergreifende Koordination zu managen, Hindernisse aufzudecken und den Fortschritt auf Lösungsebene zu verfolgen.

Die Kadenz fügt Overhead hinzu (Pre-PI, Post-PI), aber dieser Overhead ist der Preis für die Koordination von 200+ Personen an einem gemeinsamen Produkt. Ohne ihn entsteht am Ende jedes PI Integrationschaos.