Agile Architecture according to Dan North
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. I'll update this post when it’s available.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)