Agile Architecture according to Dan North

Updated on March 3rd 2012 with a PDF of Dan North’s mind map

On the first day of the QCon conference in San Francisco, I attended a full-day tutorial titled "Secrets of Agile Architecture" hosted by Dan North. I didn't really know what to expect, but I was hoping for some refreshingly new insights on the way I do my job currently.

Well, his talk was actually less innovative than I thought. But that's okay, because he gave one of the best and most refreshing talks on architecture I've seen in a while. He covered an enormous amount of material in that one day, so I won't even try to cover that in a blog post. But what I particularly liked is that a large part of that content was dealing with the organizational and human aspects of building an architecture.

One of the takeaways worth noting, and which is something I recognize quite well, is the fact that it's difficult to go into an organization and build enough trust to start breaking down the organization. Often you’ll find tens and tens of things to improve, accept the fact that you probably can only change three of them, and focus on that.

So what's the agile aspect? Well, just like Fowler explained in his Continuous Delivery tutorial, it is important to accept the fact that risks happen, so deal with it. If you can setup your architecture and development process in such a way that you can quickly (read: automated) build, test and deploy small changes, you don't have to worry too much about the likelihood of those risks. Moreover, deploying quickly gives you valuable feedback that you can use to further tune and tweak your architecture. As a bonus, it allows you to defer decisions to the last responsible moment instead of doing it upfront and running the risk you made a bad choice.

Dan didn't use any slides, but based his entire talk on a huge mind map that he unfolded gradually. He's going to share that mind map soon, and I'm sure going to put that on my office wall. It's a great reminder of all the aspects you should consider when designing an architecture for a specific company or problem domain. You can find a PDF of that mind map here.