\section{What is an Architect?}

\FigureImposeWidth{MATsystemArchitectGrowth}{Typical Development of a System Architect}{.7\textwidth}

System architects need a wide range of knowledge, skills and experience to be effective.
Figure~\ref{fig:MATsystemArchitectGrowth} shows a typical development of a system architect.

The system architect is rooted in technology. A thorough understanding of a single technological
subject is an essential underpinning.
The next step is a broadening of the technical scope.

When the awakening system architect has reached a technological breadth, it will become obvious
that most problems have a root cause outside of technology. Two main parallel streams are opened:
\begin{itemize}
\item The business side: the market, customers, value, competition, logistics, service aspects
\item The process side: who is doing what and why
\end{itemize}

During this phase the system architect will broaden in these two dimensions.
The system architect will view these dimensions from a technological perspective.
Again when a sufficient level of understanding is attained an awareness starts to grow that people
behave much less rationally than technical designs. The growing awareness of the psychological and the sociological
aspects is the next phase of growth.

Most developers of complex high tech products are specialists.
They need an in-depth understanding of the applicable technology to effectively guide the product development.
The decomposition of the development work is most often optimized to create a work breakdown
enabling these specialists to do their work with  as much autonomy as possible.

Most generalists are constrained in the depth of their knowledge by normal human limitations,
such as the amount of available time and the finite capacity of the human mind. The figure also shows that a generalist
has somewhere his roots in in detailed technical knowledge.
This root is important for the generalist himself, since it provides him with
an anchor and a frame of reference.
It is vital in the communication with other specialists, because it gives the generalist credibility.

Both generalists and specialists are needed. Specialists
are needed for their in depth knowledge, while the generalists are needed for their general integrating ability.
Normally there are much more specialists required than generalists.
There are more functions in the Product Creation Process which benefit from a generalist profile.
For instance the function of project-leader or tester both require a broad area of know how.

\FigureImposeWidth{MATfromSpecialistToSystemArchitect}
{Growth in technical breadth, intermediate functions from
specialist to system architect}{.6\textwidth}

Architects require a generalist profile, since one of their primary functions is to generate the top-level specification
and design of the system. The step from a specialist to a generalist is of course not a binary transition.
Figure~\ref{fig:MATfromSpecialistToSystemArchitect} shows a more gradual spectrum from specialist to system architect.
The arrows show that intermediate functions exist in larger product developments, which are natural
stepping stones for the awakening architect.

Examples of aspect architects are:
\begin{itemize}
\item subsystem architects
\item SW, mechanics or electronics architects
\end{itemize}
For instance a software architect needs a significant in-depth knowledge of software engineering and technologies,
in order to design the software architecture of the entire system. On the other hand a subsystem architect requires
multi-disciplinary knowledge, however the limited scope reduces the required breadth to a hopefully realistic level.

\FigureImposeWidth{MSarchitectingScope}{Different Architecting Scopes}{.7\textwidth}

Many products are becoming so complex that a single architect is not capable of covering the entire breadth of the
required detailed knowledge areas.
In those cases a team of architects is required, that is complementing each other in knowledge
and skills.
It is recommended that those architects have complementary roots as well; as this will improve the credibility
of the team of architects.

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.


