DevOps Zone is brought to you in partnership with:

Dennis is Principal Consultant at Aviva Solutions, speaker, author, coach, specialized in ALM, TDD, DDD, design patterns, architecture, Agile, TFS and Silverlight. He published coding guidelines for C#3.0 and C#4.0 and maintains multiple open-source .NET projects. You can tweet him at @ddoomen Dennis is a DZone MVB and is not an employee of DZone and has posted 40 posts at DZone. You can read more from them at their website. View Full User Profile

Agile Architecture according to Dan North

07.03.2011
| 3404 views |
  • submit to reddit
Last year at QCon, 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. I'll update this post when it’s available.
References
Published at DZone with permission of Dennis Doomen, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)