I think that the new role of an architect on an agile project is to be the clearing house for decisions on design and architecture of the project. This implies that the architect understands the current state of the software, and the rationale for the decisions that affected the current architecture. The architect works closely with the project manager (or is the project manager) and the Customer to identify the direction that the project is taking. In short, the architect is the past, present, and future of the architecture.
The architect's job is especially important at the beginning of the project. You simply have to decide what category of software is to be built, and what platform to build it on. It is extremely difficult to "refactor" a product from being a PhotoShop plug-in to a Siebel application, and certainly not worth the effort. Making the right decision usually requires much more knowledge than just the list of features. You have to understand the deployment environment, the performance, availability, scalability, expected load, and so many other factors that are not addressed by an agile process.
The architect's toughest job on an agile project is balancing Do The Simplest Thing That Could Possibly Work with minimizing predictable re-work to accomplish the next iteration. Encapsulation and layering are an architect's best friend. For example, suppose the customer wants to be able to change some parameters of the program without re-compiling. The standard answer is to use a properties file. But there are cases when a properties file is insufficient, or you need too many of them to be workable. This case might arise when deploying to a cluster, over a WAN, or the if application server doesn't expose the class path. In this case you may need to use something like LDAP or a non-standard, distributed parameter server (i.e., through a URL). The real issue is that the system needs to have an encapsulated way to load and access parameters.
Similarly, the architect should apply his/her skills to selecting refactoring alternatives that balance complexity with flexibility. The best solution supports the required, known functionality using accepted patterns, but doesn't preclude other designs for other functionality that may later need to be implemented. Notice that I said "preclude", not "support". I'm not suggesting that the solution needs to support future functionality, merely that it should not make it impossible or more difficult to implement.
I don't think that the architect's job is every really done. Even if the architecture never changed from its initial design, there would still be a need to shepherd it through the project, explain it, and maintain consistency with the detailed design. In an agile process, the architecture is most likely to change. For example, you may start with a Tomcat architecture (deployed on one machine), and later incorporate remote objects (e.g., EJB). (An unfortunate side-effect of using EJB's is that the RMI proxy object is distinguishable from the local Java object it replaced because "RemoteException" is thrown from every method.) The remote objects can be encapsulated by using the Proxy and Factory Method patterns, but some issues might arise due to serialization and pass-by-value (lack of side effects in the client JVM).
In my experience as an architect, I didn't just deal with architectural issues. I also mentored the team on best practices and discovered, identified and disseminated patterns and project standards. I helped the project manager (or I was the project manager) with risk management, estimation, mile stones, requirements gathering and analysis, iteration planning, and process improvement.
I think the role of architect on an agile project is alive and well. In many ways it is more challenging because there is less up-front work, fewer constraints, and a more dynamic environment.
I have been a Java architect since 1996, when I helped Fidelity Investments with their first thin-client, Java application. I architected HAHT Commerce's suite of e-commerce products using component-based techniques so that they could be de deployed in any combination, but developed individually. I have helped SciQuest work through architectural issues related to making one of their enterprise products application-server independent.
Toby Sarver
Principle Technologist
New Object Solutions
newobjects@nc.rr.com
3213 Watkins Glen Ct
Raleigh, NC 27613
919-848-6323