I’ve had this entry in draft mode for a while, and seeing as I am likely to have limited access to the Internet next week, it’s probably best that I get it out there. After all, I believe that all constructive feedback (both positive or negative) is useful.

The traditional software architect role is an interesting one. Developers, who choose not to go down the management line for one reason or another, typically take up this role. Defining what an “architect” does in a traditional software environment seems to be pretty well known. Trawling some job advertisements you see role descriptions like, “translate business requirements into a framework”, “high level analysis and design”, and “technological evangelization”. My observations of a real ‘architect’ at work is that they generally do spike-like work, develop a little (but usually not so little) framework here or there, or suggest implementation patterns in the form of a tutorial or cookbook.

As a mad keen developer, who is into Test Driven Development (TDD), constant refactoring, and evasion of Big Design Up Front (BDUF), I question where does this role fit into newer software development processes? I respect these people, because they have been around for much longer than I have. They probably have a wider repository of patterns to drawn upon and the wisdom of learning from many different projects. I question this, because I think the typical responsibilities fail in an environment that I like to work it.

Architects in their traditional sense, typically fail because they work leagues ahead of the development team. Sometimes they run with BDUF, but other times, they do spike work that sets a pattern for a simple use case, but fails to address the needs of many other ones. Since they rarely look back at the things they have done, architects rarely get any feedback, and one of the most useful of eating your own dog food. It sometimes gets to the point where the architect starts dictating architecture with diagrams instead of actual code, failing to see the difficulties of how untestable or how inflexible it might be when actually implemented!

Here is my revised list of descriptions on the software architect role in a modern software development team:

• The architect should be an embedded member of the development team – Like it is important to have a customer representative and a tester during an iteration, the architect must be someone a team member can go to for direction relating to a technical feature when unsure. Although it is okay for architects to work on technical spikes in advance, they should also be looking at the implemented result under all real circumstances.
• Identifying, extracting and naming patterns out of the system – Refactoring code is excellent at a microscopic developer level as you can draw out a better, more maintainable piece of code. Refactoring during an iteration by developers working on stories tend to have too much of a narrow focus to influence a large entrenched system. Excellent test coverage and well-written tests also give the architect an ability to execute on this, without having to leave the code in the state that it is.
• System-wide Odor Purification – Bad smells reside in code all over the place for one reason or another. Identifying bad smells throughout a system, highlighting them, developing a strategy for getting rid of them, or better yet, actually removing them is important. Once again, developers do this on a microscopic level but similar smells may co-exist in several parts of the system.
• Mediating technical discussion – Although BDUF is never useful, it is sometimes to useful for a team to talk about different problem solving strategies (a general approach) to take. Reality will always step in and cause something to deviate from a ‘plan’, and the architect should support brainstorming activities and should be able to step in and prevent discussions that become ineffective, and do turn into BDUF.