Agile Architecture

Agile methods are very kind to architects. In waterfall projects, it is common to falsely believe that the architect is a technical Nostradamus. The architect can't consult with their crystal ball, predicting all of the technical challenges that may threaten the project. However many managers of waterfall efforts don't plan for failed designs.

Big design up front assumes that the architect and designers are controllers of the cosmos. In reality, the very business in which we are employed for may morph and change causing the need for the software project to dissolve. The market might dry up, or a financial crisis strike which cowls the executives appetite for more financial risk. It isn't always possible to build a design which can survive game changing events such as these.

This doesn't mean we can take our eyes off of the bigger picture of the solution's overall delivery. With the vision of the effort in mind, the architect should communicate the desired behaviors of each major component of the solution. By understanding the behaviors, and the desired organization and structure of the codebase, the architect can lay the foundation from which development can begin. It is important to note that I don't believe an architecture must be finalized before coding can begin. But a rough sketch of this structure and behaviors must be complete to give a proper skeleton to the development team.

The architect is accountable for making the solution appear as if it was written by a single mind. This conceptual integrity helps the development team get their arms around the solution. It ends up reducing complexity, and increasing the understandability. Creating simple and easy to understand solutions are the key. A failed architect is one whom sees overly complex architects as direct reflections of their higher personal status. In fact, the inverse is true.