In this blog we’re going to be talking about the architectural runway in a scaled agile program.

Now the architectural runway looks like a squiggly line that sits in the safe big picture.

Scaled Agile Framework Big Picture. Source: https://www.scaledagileframework.com/

The architecture spans across the entire organization, teams,  program and portfolio.

Emergent Design

As you may know, in agile, we are looking to discover, to an extent, the design and the architecture, as we continue our iterations and our sprints. We look at small units of work and we let the designs emerge from self-organizing teams.

This concept is referred to as Emergent Design because it emerges as part of doing the work.

The problem is if we have a large number of teams that are working on a vision, it’s important to have some level of coordination and communication, because there’s so many ways to skin a cat.

And so what you will find is that even given the same problem, different teams will come up with different solutions to solve the same problem.

And what that inevitably leads to is a hodgepodge of solutions.

You’ve got lack of consistency across the teams.

You’ve got different architectural standards and guidelines that people are working to.

And in fact they could be contradictory.

They could conflict with one another and even negate one another.

This could lead to a very bad experience for the end user.

And also can result in a number of different challenges.

Now, this is where, when we have a Scaled Agile program, we might need to look at having a more intentional aspect to our architecture and our design.

This is what is referred to as intentional architecture.

Intentional Architecture

This is your purposeful planned guidelines that you provide to the Agile Release Train and this spans across all of the teams.

And this is something that all of the teams subscribe to so that they have this coherence across all of the different elements of the solution that they’re being provided.

What is an Architectural Runway?

The Architectural Runway actually provides guidance to the Agile Release Train to do just the right thing at the right time.

So that they’re able to ensure that there is a coherence and an appropriate architecture.

We want to be able to reduce excessive regret costs and rework.

We want to provide that consistent approach across the Agile Release Train, the teams, the systems and the silos, and we want the architectural design and the approach to maintain and enable agility.

Emergent Design -> Intentional Architecture: A balancing act

So the Architectural Runway requires both Emergent Design and your Intentional Architecture as well.

The problem we have now is to find a balance across these two things.

If we do too much international architecture. You end up with an inflexible architecture because you’re doing too much up-front.

You’re basically ‘Waterfalling it’ : it’s not responsive and you’re not learning as you go along.

You have too much rework because you’re making decisions too early. When you have incomplete knowledge, it’s effectively pushing you more towards a Waterfall design.

You also have an impact on innovation as well, because you’re not able to adjust and change as you learn through iterations as you proceed.

So that’s what happens if we have too much intentional architecture.

On the other hand, if you have too much emergent design. Then you end up with another problem.

You could have an inconsistent approach because the teams are working at odds with one another.

You could have a lot of regret cost because when you find out that one team’s building something in one way, another team’s building it in another way you need to do a lot of rework. 

This can result in a lot of redundancy and replication, which leads to inefficiency both in terms of the solution, but also in terms of the solution maintainability as well.

So the question is how do we get the right balance?

3 Key Factors to getting the right balance

So there are three factors that I would like to bring to your attention that are really helpful for you to determine which elements should find their way on the emergent design side, and which elements of the architecture should find their way on intentional architecture.

Let’s take a look at the three key factors that are really important as far as getting that right balance.

Factor 1: Lead Time

So, the first thing is you need to understand is what is the lead time.

Let’s say you’ve got a requirement and it has a significant lead time for you to be able to deliver that.

So it could be something as simple as, you have got on-premise servers you need to put up, or you’ve got resourcing requirements where your requirement needs specialist resources that you need to bring in from outside.

This can impact the lead time.

This is going to make an impact on whether your architectural element falls on the Emergent Design side or the Intentional Architecture side.

Meaning are we able to determine this as we progress (Emergent Design) or does the Lead Time mean that we need to be more intentional and look at this earlier on? 

Factor 2: Ability to Change

Some things are a lot harder to change than others. 

For example, if you had a system and you wanted to change the technology that you were using, of course you could change it.

But if you were to change it midway then that’s going to cost you a lot more and would require a lot more rework. So perhaps it’s something that you want to try, investigate and decide upon before you get started, or at least as early as you possibly can.

Factor 3: Need for Consistency

And the third factor is how important is architectural consistency for that particular requirement?

There are some types of requirements where consistency is not necessarily paramount, e.g. many teams may select how to deliver functionality specific to a system or team in an approach that they feel is optimal.

After all they are the experts and are likely to be best qualified to make such decisions. 

On the other hand, there are other requirements which necessarily need a higher degree of intentionality, consistency and alignment across teams. For example the User Experience, or common elements e.g. Security Protocols. 

These types of requirements will need more upfront thought (Intentional Architecture).

These three elements can help you to decide whether your architectural element falls in the emergent design or the intentional architecture side.

A non-software related example

Now I’m going to move away from the software example to a construction example.

Let’s just imagine that we’re going downtown and we’re making a large building.

So there are elements there and we’re going to take a look at some of these requirements.

So the carpeting is something that you can do, it doesn’t have a long lead time.

If you want to change your mind before you order it, you could do that.

And there’s not necessarily a need for consistency across the whole building, but you may require that.

So this is something that we can safely do in the sprint before we need to lay the carpeting, as it’s something that we don’t need to look too far in advance. So that would go on the emergent design, same with the lighting.

Now let’s have a look at the foundations.

If we look at the foundations, obviously we would want to know the size and the scale of the building.

Once we lay the foundations, if we need to change the foundations, it’s much harder to do, of course we can underpin and make adjustments.

But it’s expensive and it’s difficult to do.

So, this is something that you would want to have leading more on towards your intentional side of that.

Something you would want to design, explain and have a blueprint for in advance.

Now you’ve got exotic imported marble.

If we have a building, it may have quite a long lead time because you need to source this, it’s imported from an external place.

So again, that would be more Intentional. 

So again, as you can see, it’s very context dependent and really depends upon your project and your program.

But this is the way in which you would think about these things.

Let’s have a look at the Building Regulations.

Now clearly the building regulations is something that we need consistency across all of the teams so we need to be working to a set of guidelines.

So we want them to be clearly articulated.

So we don’t fall foul of the building regulations.

Summary

The question of the balance between Emergent Design and Intentional Architecture is a complex one, but one that can be simplified by thinking of the 3 most relevant factors to determining whether a requirement should be architected upfront or designed ‘just-in-time’.

By simply looking at the 3 factors discussed (Lead Time, Ability to Change, Need for Consistency), it becomes easier to determine which elements need an upfront architectural blueprint vs those which can be left to ’emerge’ in a more Agile way. 

The key, then, is to only do those things early and upfront which require it in your context.

How well you do that, will determine, to a great degree, your agility.