[Crossposted from DDJ]

Following the series of posts that discussed whether architects should code (see Part I, Part II and Part III), I thought I'd expand on how I see the software architect's role.

To be a good architect, a person needs to have experience taking a project from inception to production and maintenance, they should have project management experience, and have spent time working directly with customers. On top of that, know-how and experience is needed in design and technology. Having a diverse experience is what enables the architect to have a wide view on a project, understand the need for pragmatism, better understand stakeholders concerns as well understand the implications of design and technology decisions (on scheduling and budgeting, for instance). Having a wide experience also puts architects in a unique position where they can really help make projects meet their goals.

Software Architecture deals with the system's quality attributes. This makes the architect the ultimate person responsible for making sure the solution meets these quality goals (and I don't mean quality as in low bug count, rather the soundness of the solution and it ability to address the various stakeholders concerns).

To make this quality claim a reality I tend to take a holistic view in regard to the architect's role, which, simply put, means that the architect needs to do whatever it is needed to make the project go forward and succeed. Taking this direction toward quality is only possible if the architect has the wide range of experiences mentioned above.

How does that translate to real life? Here are few examples for "non-architect tasks" from my experience:

• On one project the system engineering team was working in the wrong direction in regard to analyzing requirements (this cost us six months of delay). I helped introduce the concept of Use Cases and created the project's initial use case model. (You can read the insights I have from my experience in my paper Use Case Methodology for large systems (pdf) )

• On another occasion one of the project managers was trying to evaluate how a certain technology will help advance the project. I helped her construct the WBS of the activities needed to complete the needed functionality (assuming the technology is in place) and the helped her create the estimates.
  
  
• On another project we had performance bottlenecks related to the technology used (ESRI, displaying vector maps with high refresh rates for displayed objects). I got together with another architect to pin-point the problem, diagnose it, and came up with a solutions (mapping ESRI temp files to a RAM-disk).

• I worked on a project where time was running out and a milestone was looming fast. I helped introduce the project to some SCRUM-like techniques (why only "SCRUM-like"? Remember that Rome was not built in one day either) and by working closely with the PM helped the team reach the milestone successfully (indeed not all the feature were completed--but the ones that did work were the features important to the end-user which made the milestone a success).

And the list goes on and on. And yes, coding can also be a part of this list (though for me it usually only translates to writing short proof of concepts--and for others it may mean coding some of the tasks with the team).

To sum up, a good architect is not just a lead developer on steroids. An architect should have a much wider range of capabilities and experience. Architects are "enablers". They should use their capabilities to help advance the solution and ensure its overall quality.