|
Some time ago, I was asked to give my
definition of the role of a software
architect in a small team, and state what
the required qualities to satisfy this function
are, in my opinion. This article presents the
answer I gave at that time. I hope it will help
you to better understand the role and duties of
an architect.
Architect or ArchitectS ?
The term "Software Architect" is somewhat
vague. The definitions we can give depend on the
context. This article concentrates on architects
working with a small to medium team, on multiple
projects, but not so many. In these conditions,
the software architect also acts as a
technical expert on one or multiple
platforms.
During the DotNetGuru Symposium 2003, Sami
Jaber presented two kinds of architects:
- functional architects, who optimize
business processes, and have a very good
knowledge about analysis methods;
- technical architects, who design
long-term, reliable
and adaptive technical architectures, and constitute a technical
gateway between the project manager and the
developers.
We can come across other kinds of architects. You
can refer to the resources presented at the
bottom of this page to learn more. We will focus
here on technical architects, and not on
functional architects.
Here is the role of a technical architect,
according to Sami:
- Anticipate on technological evolutions
- Build durable architectures
- Independence with regard to
API/framework providers
- Promote genericity and abstraction
- Bridge between developers, project
managers, and business experts
- Technological evangelization, sharp sense
of communication
- Ensure the technical directions and
choices
- Often mixed culture (.NET/J2EE/opensource)
- First a role instead of a job
Tasks and required skills
I won’t give here a definition of the word
architect in the sense I use it. I will
instead introduce some aspects of the role of a
technical software architect, as well as the
required qualities to perform such a function.
As previously stated, I here address mostly the
context of small and medium-sized businesses or
small development departments. In these cases,
the role is often close to the role of a
technical expert.
We could summarize the functions of an
architect within a few words. Those could
include: proposal work, advisory work, design,
realization, validation, presentations, reports,
management, transmitting as clearly as possible
the results of a continuous technological survey,
guarantee the technical quality of developments…
But there is much more than that. The work
carried out by an architect is satisfying only
if he has understood that his mission goes
beyond simple expertise and knowledge
application.
 An
architect is often an ex-developer who has
accumulated such experience as to reach a good
level in expertise. This experience must cover
ideally a variety of platforms and products, and
knowledge about the lifecycle of an application,
or even of an information system.
The role of an architect is unique compared
to the job of developers or project managers,
because it requires long-term involvement,
transverse to projects and teams. This gets even
truer for long-lasting collaborations, compared
to classic consulting missions.
It is a key role in a team. The architect must
work hand in hand with the whole of the team to
federate the energies of all the team members.
It is obvious that the benefits of having an
architect highly rely on his involvement and
integration with the project teams. It is thanks
to permanent interchanges with the developers
and the project managers that the architect will
be able to communicate his knowledge, but also
make the best out of the work of the team and
the individuals. The architect must also be
listening to the needs. Due to all this, there
are big relational requirements in this function.
Communication skills are required.
Diplomacy and pedagogy skills are also required
to be able to explain architectures, debate
about them and have them adopted.
An architect must be able to step back and
take a higher-level look, which is often
difficult for developers and projects managers
because they are often too focused on a specific
project and so on immediate needs. This means
raising from the application level to the
information system level. This also means that the
architect has
to perform a continuous technological survey;
one that goes further than the context a
specific project.
 The
architect has to submit proposals on the
directions for developments, with a long-term
vision of the information system’s architecture
and of application integration problems,
while keeping in mind the priorities. It is thus
better to favor a pragmatic approach, by
opposition to an idealistic one. Theory must
remain guidance for the long term and not an
obstacle for developments, which are often
constrained in terms of delays.
However, even if I maintain that an architect
has to step back from his work and the teams’ work,
I hardly conceive an architect who would remain
far from the implementation shop (the code, the
project). Indeed, an architect can have to write
lines of code (at least to create prototypes or
mock-ups), but also has to get his hands dirty
with code to validate the quality of what is
produced or resolve a particularly technically
difficult situation. Often are the pretty UML
diagrams or the architecture papers to be left
aside to look under the hood how things work (or
don’t) in an application. This mainly means that
an architect must be able to quickly read and
analyze code.
An architect doesn’t take part to a project
only at its beginning, but during the whole
project’s lifecycle to ensure a right implementation
of the design and architecture. He also has to
keep listening to new requirements to adapt
solutions if needed. Therefore, the involvement
of an architect can span the lifetime of an
application to give new directions, and ensure
that the evolutions don’t weaken the whole
construction.
Often, architects will initiate in-house
frameworks, which represent a big part of the
capitalization work of a company. In this case,
the architect becomes responsible for the
framework’s directions and works on the
evolution to come.
A framework also facilitates the adoption of a
technological platform such as .NET or J2EE.
This is another task where an architect can help
if he is expert in a given environment.
Let’s repeat that architect is more a
role than a job. Having experience is not all,
it also requires qualities and before all a
state of mind.
Architect or developer?
To finish on a lighter note, a question that
gets often asked is: "how to differenciate a
software architect from a developer?"
Michael Platt wrote: "Architects are a lot
slower in getting a solution, especially if the
problem is simple!". Probably we could add that
"Architects are much likely to come up with
complex and costly solutions, especially if the
problem is simple!".
Addendum
When I first published this article, a couple
of persons came up with interesting links:
Who is Fabrice Marguerie?
Fabrice Marguerie is a .NET architect and a
Microsoft MVP. Fabrice works as a consultant on
design and implementation missions. He writes a weblog in English:
http://weblogs.asp.net/fmarguerie and
administrates the web site:
http://sharptoolbox.com
|
