Who Needs an Architect Anyway? Part III: The Other Responsibilities

In the previous installment, I talked about the architect and the architectural decisions, I also said (okay, "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 four models for the role of a CTO. Three 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 Organizational Patterns of Agile Software Development, 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 four architects who worked together to produce what the authors call "prototypes"*. Six months 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.

Posted by Arnon Rotem-Gal-Oz at 04:21 PM  Permalink