In the previous installment I talked about the architect and the architectural decisions, I also said (ok, wrote) that architects do more than that. Well, here are a few of the duties I think  architects should have (sometimes not exclusively)

project CTO - Tom Berray has an excellent paper describing 4 models for the role of a CTO. 3 of them can be applied to software architects (within their projects)

• "Big Thinker" - This is somewhat akin to the role discussed in the previous post.
  
• "External Facing Technologiest" - I usually saw this in larger projects, but it is also applicable for smaller ones. There are many occasions where the technical capabilities of the project have to be presented and/or negotiated with external stakeholders. Architects are in a good position to perform this as they should have good understanding of both the business and the technology. Additionally making architectural decisions already requires the architect to understand the different stakeholders' needs

The third model is called "Technology Visionary and Operations Manager" - Making sure that technology works to deliver business goals - but how is that done?

In their book on organizational patterns, Jim Coplien and Neil Harrison, talk about the "Quattro Pro for Windows" (QPW) development team. According to the case study, Borland had a team of 4 architects who worked together to produce what the authors call prototypes*. 6 month later these architects were joined by additional developers to produce the product. During the development the architects kept meeting on a daily basis to coordinate their efforts (sort of like a daily stand-up in a scrum of scrums).

The situation in the QPW is probably close to the ideal architect involvement in a project - coding architects that work closely with the team, while driving technical and architectural decisions. The availability of multiple architect (but few to prevent the "design by committee" effect) also enhances the overall quality of the solution.

Another aspect of the architect work is to act as a coach/tutor. It isn't enough for the architect to "know best". We already know that architect must also be able to reason about their recommendations/decisions, but that's just part of the story. Helping other team members get better in what they do means that they'd be able to do their job better, they'd be able to come up with their own ideas (and get more fresh ideas into the discussions) and produce better software. Since the architect is ultimately responsible  for the quality of the solution, making others perform better should be a top priority for the architect. Being considered as a source of knowledge will help an architect perform his/her role, even when they don't have an architect title

---

Actually, What they did were POCs or spikes  (see "Architecture Evaluation in code" for an explanation of the differences)