\section{What is architecting?}

Architecting in product creation spans from {\it understanding} the {\bf why},
via {\it describing} the {\bf what} to {\it guiding} the {\bf how},
as shown in figure~\ref{fig:LWAwhatIsArchitecture}. Or in even more
popular terms: {\it do the right things} and {\it do the things right}

\FigureImposeWidth{LWAwhatIsArchitecture}{Architecting visualized}
{.6\textwidth}

Architecting is a job which is done by all members of the product creation
team, however the architect is responsible for the consistency and balance
of {\bf why}, {\bf what} and {\bf how}

A useful top level decomposition of an architecture is provided by the
so-called ''CAFCR'' model, as shown in figure~\ref{fig:MSintegratingCAFCR}.
The {\it customer objectives} view and the {\it application} view provide
the {\bf why} from the customer. The {\it functional} view describes the
{\bf what} of the product, which includes
(despite the name) also the {\it non functional} requirements.
The {\bf how} of the product is described in the {\it conceptual} and
{\it realization} view, where the conceptual view is changing less in time
than the fast changing realization (Moore's law!).

\FigureImposeWidth{MSintegratingCAFCR}{Five viewpoints for an architecture.
The task of the architect is to integrate all these viewpoints, in order
to get a {\it valuable}, {\it usable} and {\it feasible} product.}
{.8\textwidth}

The job of the architect is to integrate these views in a consistent and
balanced way. Architects do this job by {\it frequent viewpoint hopping},
looking at the problem from many different viewpoints, sampling the problem
and solution space in order to build up an understanding of the business.
Top down (objective driven, based on intention and context understanding) in
combination with bottom up (constraint aware, identifying opportunities,
know how based).

\FigureImposeWidth{MSeasyVisionCAFCR}{The customer issues which are
relevant for the case illustrated in this article}{.8\textwidth}

Figure~\ref{fig:MSeasyVisionCAFCR} shows these 5 views with some relevant
issues with respect to the illustrated memory usage. The customer objectives
are expressed in a number of keydrivers, constrained by a street price of
50k\$.

The application and functional view are here shown together,
expressed by a typical case with 3 connected X-ray system, where an
examination has a typical size of 20 images, which are auto-printed on 
3 film sheets.

The conceptual view contains a decomposition, amongst others in
import, database and print servers. It also contains concepts to
constrain the memory usage, such as anti-fragmentation and dynamic link
libraries.

The realization view contains the actual measured memory usage as well as
the budgeted usage.

\FigureImposeWidth{LWAarchitectureHow}{Guiding {\bf how} by providing
five {\it how}-viewpoints}{.9\textwidth}

The {\bf how} of the product is created by many specialists. The {\bf how}
is guided by the architecture. At least 5 views are required for guidance:
\settoheight{\myListItemsep}{.}
\begin{myList}
\item functional decomposition
\item construction decomposition
\item allocation of functions to construction elements
\item infrastructure
\item integrating concepts
\end{myList}
Figure~\ref{fig:LWAarchitectureHow} visualizes these 5 {\bf how} views.

\FigureTextwidth{MSfunctionSubsystemCharacteristic}{Question generator}
\FigureTextwidth{MSquestionGeneratorEasyVision}{Question generator}

Figure~\ref{fig:MSfunctionSubsystemCharacteristic} and
\ref{fig:MSquestionGeneratorEasyVision} shows a question generators,
which can be used to uncover potential problems. This question generator
is based on a discrete 3-dimensional space, where every point in this space
can be used to formulate a question. The axis of this space are:
\begin{myList}
\item functions
\item (HW) components
\item characteristics
\end{myList}
The question in any point in space looks like:

\noindent
''How about {\it characteristic c} in {\it HW component h} when performing
{\it function f}?''

Nearly all questions formulated in this way will get an answer {\it unknown},
which in most cases means {\it here is a potential problem}.

Note that a good architect uses a more refined question generator, which
uses a priori know-how to select the really relevant questions. The a priori
know-how includes:
\begin{myList}
\item importance, value of functions and performance
\item how critical, sensitive technical solutions are
\item people and organisation bias, strengths and weaknesses
\end{myList}

