System Architect vs Solution Architect in SAFe

0:00 Two roles, almost the same description

Hi, my name is Vicky from mozek.academy. In SAFe, two roles have almost the same description. The System Architect defines and communicates a shared technical and architectural vision for the solutions of an Agile Release Train. The Solution Architect does the same for a Solution Train. So what's the real difference, and how do the two roles work together? Let's find out.

0:22 The two definitions, side by side

Look closely, and you'll see that the main difference is the scope. The System Architect's vision covers the solutions of one train. The Solution Architect's vision covers one large solution, built by several trains and suppliers together, and it has to make sure that solution is fit for its intended purpose.

0:41 Where the roles came from: SAFe 4.5

It helps to know where the two roles come from. In SAFe 4.5, published in 2018, both were described together as one role, called System and Solution Architect and Engineering. Even then, the System Architect worked mainly in the context of one train, while the Solution Architect provided technical leadership for the whole solution. Today, SAFe 6.0 describes them as two separate roles, each with its own areas of responsibility.

1:07 Where each architect sits: ART and Solution Train

So where do they sit? Here's a simplified view of Large Solution SAFe. The System Architect is part of the leadership of one Agile Release Train, and a train can have several System Architects, each with their own focus. The Solution Architect works one level up, on the Solution Train, and in practice that's often a small team too. Above both sits the Enterprise Architect, who looks across the whole portfolio. SAFe sums up their scope in three phrases, a single system, across systems, and across value streams.

1:39 Who each architect works with

Each architect also has different partners. On the train, the System Architect works with Product Management, the Release Train Engineer and the Business Owners. On the Solution Train, the Solution Architect works with Solution Management and the Solution Train Engineer, and those three roles steer the Solution Train together. The Solution Architect also works directly with the suppliers, who build parts of the solution.

So both architects do the same kind of job, but at a different scale. Let's put them side by side, and see where their work is the same, and where it's different.

2:13 What the two roles share

Let's start with what they share. Both architects define and communicate an architecture vision, the System Architect for the train and the Solution Architect for the Solution Train. Both plan the enablers that build the architectural runway. Both define nonfunctional requirements, for one system or for the whole solution. Both agree on the capacity for enabling work, the System Architect with Product Management and the Solution Architect with Solution Management.

And both help to design the continuous delivery pipeline, and take part in release governance.

2:46 Where they differ

Now for the differences. The System Architect works close to the teams of one train. They create the technical roadmap with the teams, pair with team members, help with research spikes, and make sure the system can measure how users behave. The Solution Architect works across trains and suppliers. They apply Lean Systems Engineering, shape the Solution Intent and the Solution Context, use modeling and simulation, and keep the live solution compliant, release after release.

3:14 How they work together every PI

So how do they work together? The Solution Architect brings the end-to-end view, and helps each train's System Architects guide their part of the solution's design. And the System Architects bring back what their trains have learned, so the high-level architecture evolves with what the trains can really deliver. They come together at every PI boundary, and during the PI they meet in the Architect Sync.

3:36 Example: who decides at the bank?

Take a bank, for example. Its new mortgage platform has three decisions coming up. How the online application talks to the credit decision system affects several trains, so the Solution Architect takes that one. How the credit decision train structures its rules engine affects one system, so that's the System Architect's call, together with the train's teams. And how to test a single feature is decided by the team that builds it.

SAFe's principle of decentralized decision-making explains the logic. Decisions that are infrequent, long-lasting and bring economies of scale are best taken centrally, and frequent, time-critical decisions that need local knowledge are best delegated. Let's recap.

4:18 Recap

Both architects define and communicate a shared technical vision. The System Architect does that for one Agile Release Train, close to its teams. The Solution Architect does it for a Solution Train, across trains and suppliers. They share much of their work, from the runway to the nonfunctional requirements. And they work together at every PI, so the architecture keeps evolving. Thanks for watching. There's a third architect role in SAFe as well, the Enterprise Architect, who looks across the whole portfolio.

For more short explainers like this one, please subscribe, and visit mozek.academy.