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?

Related posts:

1. Free Agile Product Management Seminar – Nov 11, Denver
2. Surviving Rewrites

It seems like fully half the projects I come across are rewrites in one form or another. It ought to be common knowledge by now that rewrite projects have a very bad track record, but perhaps the bad results are connected to the inordinate attractiveness of “doing it right this time.” The chance to replace the ugly production system with a new, pure, buzzword-compliant ode to software architecture is one of the more compelling siren songs for developers. Too bad about those rocks.

Given that rewrites aren’t going away, here are the things I recommend software organizations consider to maximize their chances of avoiding the rocks (and maybe even be wildly successful!).

1. The problem isn’t as well known as you think it is. Run away from specs that say, “The new system shall do everything the old system does plus new functions X, Y, and Z.” No one knows exactly what the system does. It got to where it is today through the accretion of features, hacks, and workarounds. You’re almost guaranteed to break someone’s unofficial report when you rebuild the system “right.”
2. BDUF still doesn’t work, even if the previous version of the system already exists. Sure, you’ve architected the perfect service-oriented, social-media, domain-specific new system. Unfortunately, it’s wrong. In the end, the new system is going to look nothing like you envision. You can’t see the future any more than the previous team could. (In fact, they were probably replacing some other system and “doing it right this time.”)
3. The customer almost always wants the existing system plus something new. By now, the existing system is probably what David Anderson calls table stakes. Since the existing system exists, you’re already in the game. Don’t start by building the table stakes again. The new features are probably spoilers or differentiators. Those have real incremental business value. If the existing system works, build the new features first. Figure out a way to integrate them with the existing system as necessary. Then grow the new system to choke out the existing one. (Martin Fowler call this pattern Strangler Application.) Eventually, you’ll have your whole new system, but it’ll bring new value from day one instead of spending months or years catching up with the existing system. It’s harder to architect a system incrementally than from scratch, but architects like challenges, right?
4. Involve the business. Don’t let them send you to the existing system as a specification. Starting with the new features makes this a pretty easy sell. Someone’s excited enough about those new features to work with your team. Keep a blend of new and replacement features through the whole project and they’ll stay engaged.
5. Release early and often. Business value can only be realized if people are using the software. Moreover, the quality of the feedback you receive will be better if your software is being used by real users with real data. This is standard agile stuff and shouldn’t come as a surprise to anyone, but rewrite projects seem to have a logic of their own.

For more rewrite project advice, check out Chad Fowler’s excellent 2006 series on the topic.

What other tips would you give teams considering a rewrite project? Share them in the comments.

Related posts:

1. One Word Can Change Your Daily Scrum