Just like we apply the test-driven discipline to our code, we can apply it to our architecture. When you begin working on a new system you have to make some decisions up-front, but if you follow agile practices you would agree it’s impossible to foresee every requirement at this point. Requirements change so your code will change, and your system architecture can change if you prepare it for it.

When working with agile practices there’s a very high emphasis on iterations: uncovering requirements and making better decisions as the project matures. You need to pay special attention to your client needs, and think of the technical challenges involved. Get a glimpse of the big picture, and start working towards it.

In the beginning you can set a foundation that’s good enough to iterate through the first features quickly, backing your system with tests and writing clean, modular code to sustain your pace. As the system grows, you can begin extracting services and evolving your architecture into what it needs to be. By adapting to new features and increased demands, you can keep working at a fast, steady pace, upgrading the parts that needs to be changed.