There is none

I've written about this before (Everybody is an architect, except when they're not), but let me start by saying it again - there is no conflict between agile and architecture. Even the most agile of projects will have architectural concerns of some description and these things need to be thought about up front. Agile projects therefore need architecture.

Where is the conflict then? Well, the conflict is between the desired outputs of agile versus those of big up front design. One of the key goals of agile methods is to deliver customer value, frequently and in small chunks. It's about moving fast and embracing change. The goal of big design up front is to settle on an understanding of everything that needs to be delivered before putting a blueprint in place.

Separating architecture from big up front design

"Architecture" is about the stuff that's hard or costly to change. It's about the big or "significant" decisions. It's the sort of stuff that you can't easily refactor in an afternoon. For example, this includes core technology choices, the overall high-level structure (the big picture) and an understanding of how you're going to solve the complex/risky/significant problems. Big up front design typically covers these architectural aspects but it also tends to go much further, often unnecessarily so. The key to just enough up front design is to differentiate what's important from what's not. Defining a high-level structure to put a vision in place is important. Drawing countless numbers of detailed class diagrams before writing the code most likely isn't. Understanding how you're going to solve a tricky performance requirement is important, understanding the length of every database column most likely isn't.

The waters are muddied in the real world

There's a part 2 to this blog entry but before that I want to try something. The problem with the real world is that it's less than ideal, particularly with respect to software projects. Unless you're incredibly lucky, there will always be real world constraints that prevent you from taking a text-book approach to solving problems. In his QCon London 2011 presentation entitled Why Don’t We Learn!?, Russ Miles explains that this doesn't really matter. And I agree - you just have to find something that works for *you* rather than jumping headfirst into "the next big thing" because "it worked over there for them".

So here's my challenge to you. Let's imagine that you've been asked to lead a software project to replace an ageing Internet Banking system. The key facts are presented in the image below. To constraint it further, let's say that rebranding the existing system is out of the question and you've been committed to a delivery at the 4 months point. After all, things like this do happen in the real world.

This is a fictional situation but it highlights some of the real world challenges that many software projects face. How would you approach this project? What would you deliver? Feel free to leave a comment or copy the image if you want to post something longer on your own blog.