The Shiny New Agile Architect

Architect never does Big Modeling Up Front (BMUF).

He generally does not use heavy CASE tools for modeling big designs and decisions. Usually, all the modeling is "just enough" modeling and is done on white boards. The simple model grows and is enhanced with every iteration. He follows the concept of Agile Modeling and for him "the code is the model." If there is a need to generate a model for documentation purposes, then the model is generated from the code using a suitable reverse engineering tool.

The models, documents, content, and style of communication are kept as simple and as brief as possible. The idea is to focus on content, not representation or "polishing," which add little business value.

An Agile Architect looks for large scale refactorings .

He is always on the lookout for issues that could become serious technical impediments and damage the architectural concerns of the project. As the system grows, he makes sure that the architecture keeps pace. He is constantly on the lookout for big changes that have bigger payoffs. As an example, if the application is not utilizing enough CPU, and this leads to lower performance, then he might try to introduce multi-threading so that idle resources are adequately utilized to deliver better performance. He starts with the simplest working solution first and then constantly refactors the solution to meet the changing quality and functionality requirements.

The Agile architect also helps in partitioning the system. Instead of a divide and conquer approach, he recommends conquer and divide. Initially, a small system is implemented with the help of a small team. Eventually, with the experience of the Architect, the team divides the system along its natural fracture lines, keeping the big picture in mind, and adds team members for each partition.

An Agile Architect is a super glue.

He acts as a super glue between the team, various vendors, and stakeholders by communicating incremental architecture, design decisions, any technical impediments, etc. He is an intermediary between the business and technical worlds. He has the ability to see business issues through a technical lens and technical issues in a business context. He is able to explain the value proposition of current technologies in terms of business value which would be realized for the stakeholders. For example, when there is a choice of one technology over another, he would be able to explain the business value realized in terms of people utilization, faster turnaround, money saved, etc. He thinks in terms of "why" as well as "how" when working on a project to answer both business and technical concerns. Most traditional architects would focus on how to implement the solution without giving a thought about why the solution the best option. The agile architect tries to work with business and find out why a particular solution is needed, could there be a simpler way of solving the issue at hand than what the business is proposing?

Last, but not least, an Agile Architect embraces change.

He embraces change for both architecture and the role. True architectural agility is the ability to undergo change quickly and easily without degrading the architecture, and with as small as possible an impact elsewhere. To ensure this he starts with a good design and keeps evolving it throughout the project. He always abstracts out common elements and encapsulates those which may change behind stable interfaces thus minimizing the impact of change.

True role agility is playing multiple roles. He works as a programmer, system tester, mentor, mediator, team member, glue, and potentially a manager, potentially all in a days work.