Today we're going to be talking about the role of the system architect in SAFe.

The system architect sits at the program tier on the SAFe big picture, and as a trio of key program roles as he or she is going to need to work closely with the release train engineer and the product manager.

The release train engineer is a person that supports and facilitates and enhances all the cross-team communication to enable the agile release train to deliver on its commitments.

And the product manager is a person that defines what, when and why the agile release train does what it’s supposed to be doing.

Let's just take a step back and have a look at the challenges of the system architect. Now imagine you have several teams working to deliver on a single vision. There's almost an infinite number of ways to solve any problem.

If you've got 12 teams working on a problem, the chances of them coming up with an approach that's compatible and works harmoniously across all the teams is very unlikely.

All the teams need to agree on an approach and a common understanding of how they wish to do things, how they wish to architect or design the solution.

They need to support the teams so that they can agree on the technologies that they're going to use.

How the solution and the components interact at a high level, they need to understand in the system constraints that they have.

They also need to understand any functional requirements that they may have.

For example, they may have certain security needs.

The data may need to be encrypted, or they may have certain number of concurrent users that need to be supported.

We also need, in addition to having clarity on the overall approach at a high level.

We also need a greater level of detail just before it is needed.

This is what we call the last responsible moment. So let's take an example.

Imagine we're creating a building. We obviously want to know whether it's a home or an office, whether it's a five-story building or a twenty-story building.

And we need to put this upfront, prior to putting in the foundations, because we can't iterate over the foundations easily.

It's not easy to update the foundations from a five story building to a 20 story building.

There's just too much work and too much what we might refer to as regret cost now, to be sure that we make sure we can eliminate and reduce this unnecessary work.

We need to be clear on what we need to understand and design upfront. And so this is something that we need to put into what's known as the architectural runway.

Where things we can't iterate over, are in the architectural runway, whereas things that we're happy to iterate and increment over, we can elaborate on those on those just in time at the last responsible moment.

For example, we will need to know the size and scale of the building, but we don't need to know about the fittings in the bathroom or the kitchen upfront electrical sockets are going to go, what kind of marble we're going to be using the foil, et cetera, et cetera.

So these details, we can work out at the last moment using our analogy.

The system architects are responsible for maintaining the architectural runway. There are two elements to that.

We need to have a high-level overview of what we need, the kinds of technologies, interactions, the key architectural requirements as I've already discussed.

The other thing is we need to prove the agile teams with enough detail just in time so that the teams can deliver on the requirements and complete any detailed designs that they need for the user stories and time.

There are two gotchas that I want to talk to you about that typically occur.

The first one is what I call the vertical drift.

This is when you've got architects and they actually go in to deep.

They are not just staying at a high level of architecture. They are actually dropping down too early.

And they actually try and end up doing what I would consider to be almost a detailed design.

Now that's too much information. So that is one of the challenges that you need to be careful of.

The other gotcha. That I want to talk to you about is what I call horizontal drift.

Now that's quite different.

That's where you've got the system architect is working at the PI level, but the detailed designers are not just looking at the work that's needed for the current sprint.

They're looking far ahead as well, that distinction between the high-level architecture architectural runway and the detailed design is lost, and the designers may be trying to design things too far ahead as well.

We need to be careful about, so we need to be careful of the vertical drift where the system architects going too deep and the horizontal drift where you've got people working at the team level, trying to go into too much detail across multiple sprints in advance.

Hope you found that useful.

That's all we've got for the system architect role in this blog and I look forward to seeing you next time.

Thanks very much.