In this sprawling essay, Scott W. Ambler provides an intelligent, insightful, and very robust explanation of agile architecture. The post runs the gamut of introducing agile architecture, how it looks throughout the lifecycle, and who is responsible for implementing and maintaining it. The essay goes on to explain how to model it for your organization, and tips for being mindful of enterprise constraints. The suggestion is also made to “travel light” when it comes to documentation: Not sure of how documentation much to create? Err on the side of not having enough because you can always go back to the whiteboard if you need to, but the time you’ve wasted creating artifacts that you didn’t need or adding unnecessary detail to artifacts is gone for ever. Your goal should be to think through the critical issues faced by your project team (or organization or even industry depending on your scope), it shouldn’t be to create reams of documentation. The principle Maximize Shareholder ROI tells you to focus on high-value activities such as working through the hard problems as a team and coming to a common vision. Similarly, it tells you to avoid low-value activities such as writing detailed documentation or developing scores of pretty diagrams. Another section describes how to “prove your architecture” via prioritized requirements and testing of the architecture itself. You may learn that it doesn’t work, or that it works in a different way than what you had defined. Doing this early in the project lifecycle (rather than realizing it when your project is well past the scheduled completion date) is an important step, and mustn’t be overlooked.