I recently got an email from an old colleague who asked me a question: What exactly is a software architect?
Before I realized it, I had taken up half a dozen paragraphs in my response so I thought I'd reproduce it here (granting my colleague complete anonymity, of course) and plaster it for the world to judge.
This is a question that I've asked myself several times throughout my career, and I have learned a great deal from some of the world's most brilliant architects that are generous enough to publish their work (either in books or orally). I continue to learn new techniques and refine them in my own work, but the application of techniques are really only a by product of the trade. For example, before you can apply proven techniques for generating new leads, or closing deals, you have to first be a salesman.
So what is a software architect?
Naturally, the response is my opinion- some may agree while others vehemently disagree and that's OK :-)
As to your question regarding key functions/requirements of a software architect. The answer varies, as there is much confusion as to what an architect is, much less what makes a good software architect. This is true both for companies as well as for IT professionals. For many, becoming a software architect takes years of mastering the fundamentals before one is ready to take on the role, while for others, they are simply born with it, so to speak.
The gross misunderstanding of this role can sometimes lead to companies hiring for an architect title, but not looking for much more than a senior level developer/engineer. The confusion results from the inflation in terms (a term first coined by Juval Lowy) that plague software engineering. For example, a software developer or software engineer is the white collar equivalent of what in any other industry would be a trained, highly skilled professional for a given trade, i.e. a [trade name] technician. Technicians are highly skilled and very proficient in their given trade, but they are not engineers because engineering is a completely different skill and requires a different thought process. Mechanical and electronic engineers, for example, all require degrees and licenses to even use the word "engineer" in their title. Software developers/engineers are exempt from this due to the sad state of licensing (or lack thereof) in software engineering and the white collar perception of software human resources due to the fact that many, but not all software developers/engineers, are college graduates. The result is that there is a tremendous skill gap in the industry and really only a small percentage of developers/engineers are actually qualified to do the work they are doing. This is a big reason that so many software projects fail.
Software architects, on the other hand, are really somewhat on par with their actual engineer contemporaries in other disciplines. While neither software developers or software architects require a license (or even mandatory certification), true software architects have a proven track record of leading, managing, designing and architecting fairly complex medium-sized to large enterprise projects. Architects understand the technology, platforms and systems on which they build software very deeply, and are often in a position to make significant financial decisions about the application of these tools. Architects don't necessarily have to be the best programmers (developers) on the team because they do not write code 100% of the time, but they are certainly at an expert level and close to mastery in the given language, or technology and may in fact contribute to production code. Most of their time, however will be spent designing and modeling and then prototyping the resulting design and architecture so that they can convince the stakeholders and developers/engineers that their approach holds water. You will notice I said convince. Architects typically do not have direct reports (except for junior architects or apprentices, if you will) and as such yield very little unilateral power. Instead, the architect must be a team player because she must convince both peers and others that the approach laid out is sound (I never said perfect), and this is the epitome of intellectual or referential leadership.
In addition, software architects take cost, schedule and quality into account in addressing "the pillars of software architecture": Performance, Security, Reliability, Availability, Scalability, Maintainability and, in today's world where services are fast becoming the norm- interoperability. Architects solve for these all the time, often even unconsciously.
So, as you can see from the voluminous response, there is no easy answer but here are some links to some additional information which might be helpful.
Finally, below is a link to a fantastic podcast where Juval Lowy, one of the leading .NET architects in the world talks about what makes a good architect:
http://teamagile.com/interviews/Roy_Talks_With_Juval_Lowy_180105.zip
A final word of caution. The need for an architect in some organizations can become a highly philosophically contested issue. In moderate shops, where a combination of common sense traditional and modern software engineering techniques are applied, architects are invaluable. On the other hand, many Agile-influenced methodologies, for example, will go as far as to all but eliminate the role of the architect on projects due the communal nature of agile teams. In mature teams, this isn't so much of a problem because in such teams, tenured, highly skilled software practitioners take on this role collectively- naturally- as a team, and often, an informal "lead" architect will emerge (the cream rises to the top, so to speak). A program manager or chief architect might be assigned to this team who really is just a first among equals with additional administrative duties. On the other hand, in teams made up of junior, intermediate and relatively novice "senior" (it happens all the time, trust me) developers, the lack of a strong architect can have detrimental effects from a productivity perspective that has ripple effects throughout the entire lifecycle of the project. Agile's response to this problem is a relentless focus on quality, which is great move forward, but only solves some of the problems related to software engineering. In my opinion, a truly exceptional team is one made up of a combination of skill levels that employ many (so called Agile) modern software engineering techniques and work together with an architect to collaboratively build the best solution possible.