In my RSS aggregator, I've been seeing a lot of talk on the role of an architect in the IT industry. Periodically there is a flurry of commentary out on the web generally revolving around the question "What is an architect?" Alan, a technology evangelist over on the MSDN blogs, references a recent article in the Architectural Journal discussing the role of architects in software development. Additionally, Tom Hollander provides his thoughts on the role, duties, and primary competencies of architects in the larger development project. In some sense, the need for discourse on the nature and value of architects on a dev team indicates that folks are still having trouble quantifying the value of a solution, enterprise, infrastructure, etc. architect in their organization. This is of particular relevance and concern to me...because the "a" word is in my job title.

And as I read through these recent writings and some of the links therein, I recalled that at many of the larger client's I've consulted for, architects demonstrated their value by producing large discourses and treatises on the value of the "this or that pattern", laying out the complete system vision in a document that perhaps three other humans read and never understood. How'd you like to have a job that meant writing the technical equivalent of Ulysses over and over again to scathing reviews? Well then, become and architect! But what about us agilistas? How do I demonstrate value on a daily basis if working software trumps documents? The reality for most solution or enterprise architects would seem to conflict directly with the Agile Manifesto no? Kind of...in Tom's well presented list of duties he's called out three important functions of the agile architect:

1. Break new ground before leading your team down a dark alley;
2. Manage the requirements and technical implementations; and
3. Just-in-time architecture

Doing number one ensures you stay relevant and keep your coding chops sharp, and number two falls into the larger category of what I'd call "herding cats"...while change and shifting priorities/requirements are welcomed in agile projects, it falls to the Scrum Master and the architect to isolate the developers from such things. Number 3 is the biggie...the agile architect does just enough to keep the working solution moving along. Sometimes #3 is difficult in the GIS realm because spatial data or third party technologies often introduce special problems not encountered in traditional ground up software builds...How would you like it if somebody tossed DCOM into your nice .NET solution architecture at the last minute? Or just mentioned off hand the 4 TB of imagery that needed to be served over the WAN to 200 users concurrently? #3 also means resisting the desire the really trick out a solution just for the sake of doing it. If your client will only ever use SQL Server for ever and ever, that nifty provider model for the back-end connection is superfluous and shouldn't be there. The Scrum team succeeds and fails as a unit so the architect demonstrates value only when the entire project succeeds. It's binary...not measured in pages, words, diagrams, or pounds. Agile architects need to be aware of some principles to guide their work, they of course need to be technically competent and skilled in the use of the tools of the trade, and I would add that the architect needs to be able to speak to the team in technical terms, and the stakeholders in non technical plain speak. The agile architect site has a great summary of how an idea agile architect might work. Be sure to check out the Tao and Lao-Tzu link at the bottom...nifty! So how many pages of value have I provided today? Zero. But I've had two whiteboard sessions, done a box and arrow diagram to remove a blocking issue, put out two requirements fires at the client site, assisted in reorganizing the product backlog, wrote an SOW for a proposal, taken my team to lunch, did a phone touchpoint with a potential new account, and retained my sanity for one more day. That's gotta' be $3 at least right?