Characteristics of a Software Architect

The construction analogy tells us that there is no single role for an architect - he may be any combination of client, project overseer, inspector, trouble-shooter and builder as well as some combination of visionary, designer, problem solver and mentor. Neither is an architect defined by a single body of knowledge or expertise - a competent housing architect would not be qualified to tackle a bridge or a skyscraper.

The role may vary from senior strategic adviser to programmer, but an architect will always deliver some key views and contributions. An architect who can design a web-based business solution, but knows when client-server is better, might also recognise when the requirement demands a larger-scale TP or real-time solution, but might not presume to design either.

If anything the software architect is defined by a set of viewpoints and attitudes:

The architect must make sure that the solution will manage change and control complexity. To do this he may have to stand in lieu of future users, developers and maintainers, extrapolating the requirements beyond the views of current stakeholders, which may be constrained by parochial or short-term considerations. This is the equivalent of Stewart Brand's "building for change".
The architect must deliver a solution which meets the users' needs. However, he does not have to meet every constraint, passing fancy or prescribed solution, especially when these are incompatible or generated by panic, religion or fashion (e.g. "We want a web-based solution"). The ability to say "No", or at least "What do you really need?" is even more important than "Yes, we can do it".
The architect sees the "big picture", and views a system and its context as a set of interacting components. The ability to take this view is probably what distinguishes the architect(s) on a project, from those whose mental model focuses on functionality, hardware, project or financial considerations. However, the architects must also be able to understand and discuss the system using those other mental models, and may have to act as an interpreter between them.
The architect is frequently an evangelist for new or different technologies, processes or solutions. However, he or she also has a key responsibility to help manage change, which may mean reining in enthusiasm where the risks and costs would outweigh the benefits.
The architect may be a key source of ideas, but must expect those to be adapted and changed as they are adopted by the rest of the team. Conversely the architect may have to adapt ideas originating elsewhere, but without losing the team's ownership of the solution.
The architect recognises that success in IT is about people, and understands both the processes of development and the factors which drive the various players. He or she has been "out there", so that requests or suggestions are realistic, not academic. A key role may be to help interpret between the people (developers etc.) actually doing the work, and senior managers who see projects in terms of money and "resources".
The architect will typically have general, not specific business knowledge. One of the key contributions may be to look at problems in a different way by applying analogies from different fields or projects. A true architect must not be parochial, and this means gaining experience in different roles and fields, probably with different employers. Having and using experience is more about attitude than years.
The architect has the ability to synthesise solutions, understanding new problems in the context of old ones.

To formalise Software Architecture, we have to define a basic set of knowledge and skills. However, this is likely to be quite "light": basic terminology, modelling skills, pattern literacy and so on. Different architects may need very different detail technical skills. We must also find some way to recognise the important attitudes and softer skills which really define an architect.