One of the things that I mention every time I do training or mentoring around technical architecture is that you don't just wake up one day and become a TA. From my experience, it's much more of an evolutionary path where you gradually take on more and more TA responsibilities.

Last night I ran a training session where we looked at what an architect might do during a typical RUP style project. With the full list of responsibilities defined, it was interesting to see that everybody in the room was already doing some of them. As I said, it's an evolutionary path to becoming a TA.

However, more interesting was that the same people said that some of their projects don't have a "technical architect". After the initial shock, this got me thinking. Do you really need an architect on a software project? Is it more important to have the responsibilities covered off by the team as a whole rather than having a single person looking after them? Is having a single point of contact and responsibility essential? Provided the role is performed (e.g. there is a defined architecture, quality assurance is being performed, etc) there are pros and cons either way.

What do you think?

Read more...