Agile Zone is brought to you in partnership with:

Simon lives in Jersey (Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon regularly speaks at international software development conferences and provides consulting/training to software teams at organisations across Europe, ranging from small startups through to global blue chip companies. He is the founder of "Coding the Architecture" (a website about pragmatic, hands-on software architecture) and the author of "Software Architecture for Developers" (an e-book that is being published incrementally through Leanpub). He still likes to write code too, primarily in .NET and Java. Simon is a DZone MVB and is not an employee of DZone and has posted 32 posts at DZone. You can read more from them at their website. View Full User Profile

The Conflict Between Agile and Architecture

05.27.2013
| 7811 views |
  • submit to reddit

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.

Conflict between agile and architecture

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.

Published at DZone with permission of Simon Brown, 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.)