I got asked recently about the role of architecture in agile development. Basically, the question boils down to some variation of “Is there a place for architecture in agile development?” This is a common and mostly misunderstood question. It seems like it gets asked on every project. It’s based on a faulty assumption: that architecture is something that is stand alone, that can be bolted on to a project.

To talk about agile architecture, you first need to understand what architecture is. Once you know what architecture is, and what it isn’t, the question changes to “How can you do good architecture in agile development?”

Architecture

I went to a training class where architecture kept getting defined as “All the decisions that you wish you had gotten right at the start of a project.” That’s probably the best working definition of software architecture that I’ve heard. Although, in a more helpful way, I would say that it is the way that you frame the problem to help arrive at the solution.

Whether you choose a service oriented architecture, client server, etc. It affects how you look at the problem domain, it limits the techniques that are available to the ones that work well within that framework. That’s architecture in a nutshell “How you frame the problem domain.”

Agile Architecture

What makes agile architecture different from any other architecture?  Nothing really.  Architecture is architecture, it’s still the way that you frame the problem domain. The way that you choose to look at a the problem affects the solutions to that problem that come easily, and which solutions are made more difficult.

When doing an agile project, there are some things that you need to have happen more fluidly, like managing change.  In addition to that, you also tend to have an extremely compressed time frame for doing architecture on agile projects.

Making good architecture in a hurry

Anyone can come up with the perfect architecture given infinite time. Since no project has infinite time and agile projects have even less, no architecture will be perfect. Although, that doesn’t mean that the perfect architecture is no architecture. The idea is to aim for pretty good and extensible.

If it’s pretty good, then it’s a decent fit for most of the problem domain.  There may be some outliers where it won’t work real well, but that’s OK.  The goal is consistency across the project, not making it identical. If it’s consistent, then when people move to different areas to work on new stories, they have a framework that they’ve worked with already.  Common things are already thought out and it’s just implementing the new ones.

The other main goal is extensibility.  Things change and in agile project things change even more quickly.  If you have an architecture that involves making changed in multiple places to get something done, it won’t be as flexible as one that you have to make a change in one place.

There are a couple of ideas to keep in mind that help me when coming up with the architecture for agile projects:

The Symmetric Property of the Single Responsibility Principle

The symmetric property says that if a = b then b = a.  The same holds true for the single responsibility principle. If the class has only one responsibility, then there is only one class that has that responsibility. This is a slightly different way of saying don’t repeat yourself.

Actually, it’s applying the DRY principle to code and business logic instead of data. In it’s purest form, it means having a single point of change for any piece of business logic. It means, don’t put 1/2 the functionality in code and 1/2 in a config file.  Put it in either one place or the other.  If you need to make something configuration driven, then commit to it.  If you want to have a code driven approach then commit to that.  When you do it half one way and half the other it makes it tough to extend and even tougher to maintain.

 See the big picture while focusing on the details

The single hardest thing to do when coming up with an architecture for and agile project is to keep the big picture in mind. You have this constant barrage of small stories coming in, with relatively simple development efforts to finish each one. They are the notes, the music defines the architecture.

I wish that there was an easy way to see the big picture, but there isn’t.  In then end, it comes down to experience.  Being able to produce a well designed project under the intense time pressure of an agile process is a skill that can only be learned by doing.