\section{Introducing an Architect}

\FigureImposeWidth{MSarchitectingScope}{Architecting scope}{.8\textwidth}

One of the main causes of the late visibility of problems is the
limited context awareness of most component engineers. Most of
these engineers are simply not aware of potential problems!
This lack of awareness is reflected in the difficulty to plan design
meetings. Quite often the engineers don't see the benefit of such a meeting,
because they don't see any issues to be discussed.

Many organisations don't have explicit system architects.
Sometimes the { \it best in class} technical specialist
gets the architect title imposed.
In both cases the introduction of a broad system architect causes
a shock effect in the organisation.

Figure~\ref{fig:MSarchitectingScope} shows that the scope of architects
widely varies. The common denominator for all these architects is the
bridge function between context and technology (or problem and solution).
An architect needs sufficient know-how to understand the context as well
as the technology, in order to design a solution, which fits in the context
and is technical sound at the same time.

In general increasing the product scope of an architect coincides with
an increase in people scope at the same time.

\FigureImposeWidth{MSawarenessPath}{Architecture awareness evolution}
{.5\textwidth}

Figure~\ref{fig:MSawarenessPath} shows the phases an
organisation is going through in a typical project where an
architect is introduced.

As long as individual designers can work independently the collective mood
is great, while an architect is mostly perceived as a threat or a menace,
see also figure~\ref{fig:MSthreatOrMenace}. As soon as the integration starts
all invisible problems suddenly become visible, the beginning of a crisis,
which changes the mood to poor.

An architect who proves himself in this difficult stage, by hard work,
brainstorming, trouble shooting and problem solving earns a lot of credit.
This changes the appreciation of the architect dramatically, suddenly he
becomes an indispensable team member! After completion of the integration the
mood returns to good. In a next project, again during integration the mood
will degrade, even excellent architects will not prevent this. However this
crisis will be less severe.

An architect always starts to ask questions, to build up understanding and
overview. While sampling the problem and solution domain in this way,
he always discovers some weak spots. The identification of problems and
risks is often based on a judgement or an opinion.

\FigureImposeWidth{MSthreatOrMenace}
{The engineer's perception of the architect}{.6\textwidth}

The judgement or the opinion is based on a sample of all data, fitting
in the limited available time. Despite the incompleteness of the data
and despite a lack of domain and solution know-how the architect forms
an opinion anyway. The architect does the top level design, the nice
hand-waving work, without being too concerned with the nasty details.

Whenever you want to benefit from the architect's expertise, by asking for
a solution, the architect only worsens the problem, by showing even
more hidden problems.


