Agile Architecture – Neither BDUF nor Chaos

I’m often asked how architecture works on agile software projects. It’s a big question, but the core answer, I think, is this: Neither a big, detailed architecture up front nor no architecture at all is a good approach. The former leads to waste. The up-front architecture tends to support features that turn out never to be necessary and that unnecessary complexity tends to make the features that are implemented more expensive than they need to be. I worked in one organization where the requirement to fully implement the company-standard architecture added several hundred thousand dollars to the initial release of any new product with questionable business value in return. The latter approach, no architecture at all, is prone to produce a system that is unmaintainable, leading to waste later as features cost increasingly more to implement and maintain as the system grows.

Here’s my two rule heuristic for agile architecture:

1. Have a minimally sufficient technical vision. Know where you’d like to go architecturally at a high level. What technologies do you expect to use? What architectural patterns are appropriate (e.g. SOA)? You may not implement most of the target architecture until features require it, but it will keep the team working in the same direction. Revisit this target architecture regularly as the backlog changes to ensure that it stays relevant.
2. Make decisions that keep your options open. Always try to build just enough to support the current features, while keeping it easy to move towards the target architecture (or any other architecture that future features may require). Avoid making commitments to a particular architecture before you have to.

For example, suppose your target architecture includes SOA. Until your features require your business layer to be consumed as a service by more than one client, you might defer actually building the service interface. Instead, build a good OO interface and use it directly from your client, designing it such that a service facade will be easy to add when needed. Your current features will be usable faster, allowing for early ROI and for learning that might change the requirements around the service interface. Fortunately, since you haven’t built a service interface yet, you won’t have to throw anything away to incorporate that learning into the product.

You can employ a similar approach around persistence, caching, reporting, configuration, and security, among others.

Where have you struggled with agile architecture? What creative architectural solutions have you come up with that allowed you to implement just enough architecture while leaving your options open?