Change is inevitable. In fact, this is the only constant. It applies to the evolution of species, human culture, technology and the weather. Apparently it is especially applicable to everything associated with software development. Agile evangelists want us to embrace change. I think what they mean is we need to plan for change and allow changes in every part of the system that is under development. This means that schedules should not extend too far into the future and that technical decisions should never be fixed or final, before the project ends. In effect this promotes a very constant change management, where changes are continuous but small in stead of big and interrupting.
Most big projects I have seen follow quite a different pattern. Early in the process change is promoted, even advertised: Your credit management has low accountability? Let's remodel your financial management system! You have too many separate programs in your system? Let's throw them all out and rebuild the whole thing! Your website is not user friendly? Let's redesign the whole thing with this new cool framework! Of course a lot of analysis goes into finding out which changes can be applied to the system, but once every possibility for change and improvement has been found, documented, considered and (re)designed, changes are no longer allowed. A contract is signed and for the customer, who has been bombarded with questions and proposals for change, the long silence begins. In this period, the system is being developed, according to the design that has been consolidated with the contract. Changes that the business might want will be very costly. And then, when the customer has forgotten all about this project and can surely not remember what exactly the problem was that was being solved: BANG! The business is hit with the full impact of the New SolutionTM.
I think this approach has harmed the software development business. Software development is seen as a painstaking process of implementing changes, where it should be about finding solutions to business problems. Business is being scared away by the high cost of analysing their "information problems", let alone the cost of implementing all those changes. This is where the agile business proposition is at it's full force: Agile software development promises the most valuable thing first and short time to market. I would like to add a slogan: The smallest change with the highest business value. In stead of looking for all possible changes and trying to achieve them all at once, we should start out to find the smallest technical change that we can make that will give the customer the highest gain. That will be the first thing we'll develop. This means we need to have a clear picture of the technological landscape that the customer is in. What programs are they running? What do their processes look like? What does their infrastructure look like? But as soon as small improvements can be made, development should start and delivery should be at hand.
This defines the role of an architect in agile software development: Always on the lookout for improvements in the context of the customer. As everything in an agile process, this is in parallel with the other processes: design, development, testing. The architect does not try to write a conclusive report on the requirements and needs of the customer, he tries to feed those into the agile process as they are discovered. His focus and priority here are (as always) business value and early delivery.
I think this is an important part of the Agile business proposition. In stead of building a new system where everything is improved, we'll start out with the existing situation, applying small changes to arrive at the desired situation. This will also provide the customer with means to steer the process when he feels that it is taking the wrong direction. The ultimate goal as the customer percieves it at the start of the process will be the same, but since the process is agile, the customer can decide at any point to change direction or that the current situation is satisfactory. In a way, the customer can sit back and relax: we won't try to change everything at once and the architect will be responsible for finding out what improvements should be made and when. This is a good counterweight against the higher involvement we demand from the customer with regards to requirements and testing.
In conclusion: There is a role for architects in Agile software development. The architect is concerned with integrating the system in the technological landscape of the customer. It's main focus is on determining which changes have the smallest impact and the largest business vale for the customer. This underlines one of the most important parts of the Agile business proposition.