SAFe System Architect Explained

0:00 What does a System Architect look after?

Hi, my name is Vicky from mozek.academy. Every feature an Agile team builds stands on technical choices, such as which platforms to use, how the parts of a system talk to each other, and how everything gets tested and released. When nobody looks after those choices, a system slowly becomes harder to change. On an Agile Release Train, the role that looks after them is the System Architect. Let's explore what a System Architect does and who they work with.

We'll also see how the role balances planning ahead with learning along the way.

0:31 Why systems must keep adapting

The computer scientist Manny Lehman studied how software changes over the years, and he wrote that a system must be continually adapted, or it becomes progressively less satisfactory. SAFe opens its article on the System Architect with that idea, because keeping a system adaptable is a large part of the job.

0:50 What is a System Architect in SAFe?

So what is a System Architect? In SAFe, the System Architect defines and communicates a shared technical and architectural vision for the solutions that an Agile Release Train develops. The System Architect aligns the Agile Teams on the train to a common technical direction, and makes sure that this technical vision fits the product vision of Product Management. And a train can have more than one System Architect, each focusing on one part of the design, such as security, cloud services, data or the user interface.

1:23 Emergent design vs intentional architecture

Why does a train need this role at all? Agile teams practice emergent design, which means they extend the design only as far as the next increment needs. But at scale, emergent design alone runs into problems, such as missing standards that raise costs, one-off solutions that are hard to change, and quality that depends on tribal knowledge. So SAFe balances emergent design with intentional architecture, a set of planned and purposeful guidelines that let the independent work of many teams fit together into one solution.

1:55 Where the System Architect fits on the ART

So where does the System Architect fit? Here's a simplified view of an Agile Release Train. The System Architect is part of the ART leadership, together with Product Management, the Release Train Engineer and the Business Owners. Product Management decides what the train builds to achieve the vision, and the System Architect designs the overall architecture it's built on. Outside the train, the System Architect works with Enterprise and Solution Architects, so the train stays in line with the organization's wider technology strategy and with other solutions.

2:30 Five areas of responsibility

So what does a System Architect actually do? SAFe describes five areas of responsibility. The first is aligning the architecture with business priorities, and the second is defining and communicating the architecture vision. The third is evolving the system design together with the teams. The fourth is fostering built-in quality and looking after the nonfunctional requirements. And the fifth is supporting DevOps and the continuous delivery pipeline.

2:57 Enablers and the architectural runway

Let's start with business priorities. The System Architect identifies the enablers that build the architectural runway. The architectural runway is the existing code, components and technical infrastructure that teams need to build the next features without much redesign or delay. New features use up the runway as they're built, so it needs continual investment. That's why the System Architect works with Product Management to make sure that enough of the teams' capacity goes to this enabling work, before every PI and during PI Planning.

3:30 Nonfunctional requirements (NFRs)

The System Architect also takes part in defining the solution, for example in roadmap workshops, architecture reviews and feature refinement, and points out what's technically possible and what isn't. And the System Architect defines the system's nonfunctional requirements. Nonfunctional requirements are system qualities, such as security, performance and reliability, and they often act as constraints across all the backlogs.

So the architecture has to support them.

3:58 Example: a bank's credit decision train

Take a bank, for example. Its credit decision train builds the system that checks whether a customer can afford a mortgage. The next features in its backlog will check a customer's income from their bank account data, with the customer's consent. Before the teams can build those features, the train needs a secure connection to that account data, so the System Architect adds it to the backlog as an enabler. The System Architect also sets a nonfunctional requirement for the new check, that a decision comes back within a time the business has agreed on.

4:30 Sharing the architecture vision at PI Planning

The second area is the architecture vision. The System Architect updates it before every PI Planning event and presents it to the whole train, as part of the briefings at the start. During the PI, the System Architect stays close to the teams and helps them solve the design issues they run into. That's normal, because the plan changes as the teams learn more in every iteration. The System Architect also designs for change, for example with set-based design, which keeps several design options open until the best one becomes clear.

5:04 Evolving the design with the teams

The third area is evolving the design with the teams. The System Architect helps teams run quick experiments and research spikes to test their design ideas early, because a wrong guess becomes expensive to fix later. They pair with team members, mentor them and take part in peer reviews. That's how the System Architect keeps the gap small between the architectural vision and what the teams can really build with their skills, capacity and tools.

5:30 Built-in quality and design for testability

The fourth area is built-in quality. The System Architect promotes designs that help teams find problems early, or avoid them altogether, such as loosely coupled architectures, clear design and coding standards, and regular refactoring. An article in SAFe's community series adds a related idea. It argues that System Architects should help the teams design for testability, because a system that can't easily be tested can't easily be changed.

So choices such as technologies, design patterns, logging and configuration should all make testing easier.

6:05 Example: credit rules designed for testing

Back at the bank, the credit rules used to live deep inside the database, so the only way to test them was with a full copy of the system, which was slow. So the System Architect agrees with the teams to move the rules into their own component, where each rule can be tested on its own, with test data instead of real customer accounts. Testing becomes faster, and the teams can change a rule with confidence.

6:28 DevOps and the continuous delivery pipeline

And the fifth area is DevOps and the continuous delivery pipeline. The System Architect helps the teams plan how to set up and manage releases, including the right environments and tools, and often cloud infrastructure that makes the system easier to scale. They take part in release governance, assessing how technology affects specific releases. And they make sure the system can measure what matters, so the teams can learn how users really behave.

6:55 Just enough architecture

One word of warning, because the balance is hard. If architects specify too much, the teams lose their autonomy. And if they specify too little, the patterns become inconsistent and technical debt grows. Architects also need to stay close to the teams without becoming a bottleneck. That's why SAFe sees every architect as a Lean-Agile leader, someone who mentors the teams and helps them grow their skills.

7:19 Recap

Let's recap. The System Architect defines and communicates a shared technical vision for an Agile Release Train. They work in the ART leadership, next to Product Management, the Release Train Engineer and the Business Owners. They build the architectural runway with enablers, and they look after the nonfunctional requirements. They evolve the design together with the teams. And they help the train deliver, with built-in quality and a continuous delivery pipeline.

Thanks for watching. The System Architect is one of three architect roles in SAFe, next to the Solution Architect and the Enterprise Architect. For more short explainers like this one, please subscribe, and visit mozek.academy.