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
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
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
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