Hi Folks

I had a discussion recently with a group of software architects about whether Architecture had a place in Agile development. This is an important (and at times hotly debated) topic so I'm going to expand on the discussion here.

It is often said that agile methodologies have no place for architecture. Indeed, some agile methodologies (like XP) expressly forbid thinking about it. In an XP project you focus only on what needs to be done right now and must not think about the future. I fundamentally disagree with this position. To me, this lack of future thinking is one of the reasons XP never really caught on in mainstream development. It was fine for small projects but for anything larger or longer lived, it failed. Don't get me wrong though - XP still has much to teach us; in fact some of the XP practices are absolutely required for successful agile development. But its failure to address architecture is a serious failure.

Why is that? On the surface agile and a defined architecture look incompatible. How can you respond to change if you are locked into a defined architecture? My answer is that you can't respond to change unless you do have a defined architecture. It just has to be the right type of architecture.

If you just write code and don't think about how it all hangs together you can get things done very quickly. But any time you want to change that code you need to re-factor. Sure, unit tests will give you the confidence to do that re-factoring but those design shortcuts you took to get things done earlier will come back to bite you. You code will rapidly become unstructured, messy and hard to change. You will end up spending longer and longer re-factoring existing code and less and less time getting things done. In short, you will build up technical debt that needs to be paid back.

There needs to be a focus, right from the beginning, on making your code extensible, testable, changeable and all the other -ble's that are important. You code needs to be able to adapt to any requirement (or user story) that comes along. Just like your team, your code needs to be agile. Looking at this in a Lean way, your code needs to be written in a way that doesn't close off options too early (from the Decide as Late as Possible principle of Lean). This implies a lot of things - that your code is well structured, that it is loosely coupled, highly coherent, easily testable, well encapsulated. In short, that it is well architected.

To be truly agile, your team needs to have single-minded focus on architecture. Not the sexy things that architecture groups tend to focus on these days. Not architecting complex frameworks or elaborate n-tier scenarios but on the architectural basics - Design Patterns, Simplicity, Separation of Concerns, Testability, Flexible Deployment, Coherence, Coupling. All the basic, un-sexy parts of architecture that your team absolutely has to get right. Modules should do only what they need to do and should communicate with other modules through well-defined, stable interfaces. Interfaces should be versioned to preserve backwards compatibility. In that way, new modules can be added to add new functionality without needing to do major re-plumbing on existing code. Your code must be testable and have a comprehensive suite of regression tests to give you the confidence to make changes where required. Your product should be developed to allow flexible deployment - one box, client/server, n-tier, cloud - it shouldn't change anything but your installer.

Your architecture will make or break your agile project. A well architected product can adapt and change easily to changing requirements. It can be agile. A poorly architected product will accumulate technical debt and bog your team down in constant major re-factoring. Poor architecture will give you code that is complex, slow to change and unmaintainable. Good architecture will set your code free and allow it to become as agile as you are.

Cheers

Dave