The Solution Train

Most organizations don't need the Large Solution level. Essential SAFe (one ART) handles the majority of scaling scenarios. You need a Solution Train when:

• The product requires multiple ARTs (200+ people) to build and maintain
• There are significant dependencies between ARTs that can't be eliminated through architecture
• The system includes hardware, firmware, or external suppliers that must integrate with software
• Regulatory requirements demand coordinated compliance across multiple trains

Examples of systems that often need Solution Trains:

• Autonomous vehicle platforms (perception + planning + control + infrastructure)
• Large financial platforms (trading + risk + compliance + data)
• Telecommunications systems (network + billing + customer experience)
• Military/aerospace systems (hardware + firmware + software + integration)

The key indicator: If your ARTs are constantly blocked on each other and dependency management consumes significant RTE time, you may need the coordination structure that a Solution Train provides.

The Solution Train sits above ARTs and provides coordination across them. Its structure mirrors the ART, but at a higher level:

Solution Train Engineer (STE) — The RTE equivalent for the Solution Train. Facilitates Solution-level events, manages cross-ART risks, and ensures the trains stay aligned. This is an extremely demanding role requiring deep technical understanding and exceptional facilitation skills.

Solution Management — The Product Management equivalent. Defines the solution vision and roadmap. Breaks large initiatives into capabilities that map to ARTs. Works with Product Management on each ART to ensure alignment.

Solution Architect/Engineer — Defines the overarching architecture across all ARTs. Ensures technical coherence, manages interfaces between subsystems, and maintains solution-level architectural runway. Must balance ART autonomy with system-level consistency.

Solution Backlog — Contains capabilities (large solution behaviors that span ARTs) and solution-level enablers. Capabilities are decomposed into features that individual ARTs implement.

The Solution Train doesn't replace ART-level structures—it adds a coordination layer on top. Each ART still has its own RTE, Product Management, and System Architect. The Solution Train roles coordinate across these ART roles.

The Solution Train has its own cadence of events that wrap around ART events:

Pre-PI Planning (1 day, before ART PI Planning) — Solution-level stakeholders align on the vision and top capabilities for the next PI. Solution Management presents priorities. Solution Architect presents technical direction. Cross-ART dependencies are identified. The output feeds into each ART's PI Planning event.

ART PI Planning (2 days, as normal) — Each ART runs its standard PI Planning, but now informed by the Pre-PI Planning output. ARTs know the solution-level priorities and inter-ART dependencies.

Post-PI Planning (1 day, after all ARTs plan) — Representatives from all ARTs come together to align plans, resolve remaining dependencies, and create the solution-level PI objectives. The Solution Train does a confidence vote on the integrated plan.

Solution Demo (end of PI) — Like the System Demo but at the solution level. All ARTs demonstrate their integrated contribution to the overall solution. This proves the system works end-to-end across all trains.

Solution Train Sync (weekly) — STEs and RTEs meet to manage inter-ART coordination, surface impediments, and track solution-level progress.

The cadence adds overhead (Pre-PI, Post-PI), but this overhead is the price of coordinating 200+ people on a shared product. Without it, you get integration chaos at the end of each PI.