Agile Architecture

In many agile teams the role of architecture is derided and on occasion actively avoided.

I think this view point comes from mistakenly equating architecture with planning.

As agile teams we don't won't to get bogged down in planning and we don't require a large upfront design to get started in delivering value.

And thats fine because this isn't the role of architecture.

Architecture isn't about exactly how we might implement a possible new feature six months down the line, it should be about how we make sure our code base is built to accept change and adapt so that if that feature does come further down the line we haven't painted ourselves into a corner.

Agile teams will often describe their architecture as emergent, I think this can be dangerous if you expect a robust architecture to just come riding into view when you've paid it no thought, instead I believe we should be aiming for an emergent codebase that can go anywhere we want to take it.

Two Big Questions

I don't believe its anti-agile to take a small amount of time just thinking through the structure of the code were about to write, this thinking should be aiming to answer two questions,

How will we test this?

How would we change this?

Agile architecture should be about being able to scale, we need to be able to adapt to new requirements quickly and we need to be able to verify our code still works.

This means the two most important properties our code can have is testability and adaptability, being able to fall back on these two things means you will never be fearful of a new requirement. 

Failing to think about these two things means the architecture that emerges will be brittle and ultimately will fall apart.

Look After the Small Things

Although having this scaleability in our code base is a long term aim fortunately we can ensure we get there by taking care of the small things in the here and now.

SOLID is all about taking care of testability and adaptability, ensuring you write your code being guided by these principles whilst taking a small amount of time to think through how you want to structure things will allow for the emergence that were seeking.

Always Ready to Go

Once we have the emergent code base that will allow us to grow another important aspect of our architecture needs to be the ability to deliver at a moments notice.

For this to be a reality we need to embrace automation, in building, in testing, and deploying, the architecture of our build processes is just as important as the architecture of our code.

If we prefer working software over documentation then we need to ensure that as little energy as possible is expended in getting that working software though the door.

Shaping the Future

Software provides solutions to problems, the genesis for wanting to reduce the role of architecture within an agile team comes from our propensity to solve problems that don't exist yet or becoming too obsessed with minor details.

The role of architecture should be to create a framework to allow creativity, to enable solutions to be found and implemented when the need arises.

Good architecture stops us creating a straight jacket that suffocates us from being able to move forward.

Without this flexibility it is impossible to be agile, without a bias towards automation it is impossible to be agile.

The concept of MVP should be applied as much to architecture as it is to the product the architecture needs to deliver.

We need to define the simplest architecture that can possibly work and continue to work in the future when we change exactly what working means.