\section{Architecture}
\label{sec:HMPAarchitecture}

\FigureImposeWidth{HMPAwhatIsArchitecture}{What is Architecture?}{.8\textwidth}

What is {\it Architecture}? Every individual appears to use their own definition
of architecture. Figure~\ref{fig:HMPAwhatIsArchitecture} shows many different
aspects that are frequently mentioned as being part of the architecture.

\FigureImposeWidth{LWAwhatIsArchitecture}{What is Architecture?}{.6\textwidth}

We will use a broad definition of {\it Architecture}.
Architecture is the combination of the  know how of the solution (technology)
and understanding of the problem (customer/application).
The architect must play an independent
role in considering all stakeholders interests and searching for an effective solution.
The fundamental architecting activities are depicted in figure~\ref{fig:LWAwhatIsArchitecture}.

\FigureImposeWidth{LWAarchitectureHow}{''Guiding How'' by providing rules for:}{.9\textwidth}

Creating the solution is a collective effort of many designers and engineers.
The architect is mostly guiding the implementation, the actual work is done by the designers and engineers.
Guiding the implementation is done by providing guidelines and high level designs for many
different viewpoints. Figure~\ref{fig:LWAarchitectureHow} shows some of the frequently occurring viewpoints
for guiding the implementation. Note that many people think that the major task of the architect is to define
{\bf the} decomposition and to define and manage the interfaces of this decomposition. 
Figure~\ref{fig:LWAarchitectureHow} shows that architecting involves many more aspects
and especially the integrating concepts are crucial to get working products.

Architecting involves amongst others {\it analyzing}, {\it assessing}, {\it balancing}, {\it making trade-offs} and
{\it taking decisions}. This is based on architecture information and {\bf facts}, following the needs
and addressing the {\bf expectations} of the stakeholders. A lot of the architecting is performed
by the architect, which is frequently using {\bf intuition}.
As part of the architecting {\it vision}, {\it overview}, {\it insight} and {\it understanding} are created and
used.

\FigureImposeWidth{LWAarchitecting}{The Art of Architecting}{.7\textwidth}

The strength of a good architect is to do this job in the real world situation,
where the {\bf facts}, {\bf expectations} and intuition sometimes turn out top be false or changed!
Figure~\ref{fig:LWAarchitecting} visualizes this art of architecting.

\FigureImposeWidth{LWAdecompositionAndIntegration}
{Architecting is much more than Decomposition}{.7\textwidth}

Many people expect the architect to decompose, as mentioned in the explanation of ''guiding how'', while
integration is severely underestimated, see figure~\ref{fig:LWAdecompositionAndIntegration}.
In most development projects the integration is a traumatic experience.
It is a challenge for the architect to make a design which enables a smooth integration.

\FigureImposeWidth{VCarchitectureDescription}{The architecture description is by definition
a flattened and poor representation of an actual architecture.}{.6\textwidth}

IEEE 1471 makes another interesting step: it discusses the architecture {\it description}
not the {\it architecture} itself. The {\it architecture} is used here
for the way the system is experienced and perceived by the
stakeholders\footnote{Long philosophical discussions can be held about the
definition of {\bf the} architecture. These discussions tend to be more entertaining than
effective. Many definitions and discussions about the definition can be found, for instance
in~\cite{www:PuttingSystemsToWork},~\cite{www:BredemeyerSoftwareArchitectureDefinitions},
or~\cite{www:SEIsoftwareArchitectureDefinitions}}.

This separation of {\it architecture} and {\it architecture description} provides
an interesting insight. The {\it architecture} is infinite, rich and intangible,
denoted by a cloud in figure~\ref{fig:VCarchitectureDescription}. The
{\it architecture description}, on the other hand, is the projection, and the extraction of this
rich {\it architecture} into a flattened, poor, but tangible description.
Such a description is highly useful to communicate, discuss, decide, verify, et cetera.
We should, however, always keep in mind that the description is only a poor
approximation of the {\it architecture} itself. 
