\section{Do the things right; Lessons from Practice}
\label{sec:LWAlessonsFromPractice}

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.

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

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.

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 to be false or changed!
Figure~\ref{fig:LWAarchitecting} visualizes this art of architecting.

\FigureImposeWidth{LWAarchitecting}{The Art of Architecting}{.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{LWAdecompositionAndIntegration}
{Architecting is much more than Decomposition}{.7\textwidth}

A common pitfall is that managers as well as engineers expect a platform to be stable; once the
platform is created only a limited maintenance is needed.
Figure~\ref{fig:LWAplatformStability} explains why this is a myth.
A platform is build using technology that itself is changing very fast (Moore's law again).
At the other hand a platform served a dynamic fast changing market, see section~\ref{sec:LWAdynamicMarket}.
In other words it is a miracle if a platform is stable, when both the supplying as well as the consuming side
are not stable at all.

\FigureImposeWidth{LWAplatformStability}{Myth: Platforms are Stable}{.5\textwidth}

The more academical oriented methods propose a ''first time right approach''. This
sounds plausible, why waste time on wrong implementations first? The practical problem with this
type of approach is that it does only work in very specific circumstances:
\begin{myList}
\item well defined problem
\item few people (few background, few misunderstandings)
\item appropriate skill set (the so-called ''100\%'' instead of ''80/20'' oriented people)
\end{myList}
The first clause for our type of products is nearly always false,
remember the dynamic market. The second clause is in practical cases not met (100+ manyear projects),
although it might be validly pointed out that the size of the projects is the cause of many problems.
The third clause is very difficult to meet, I do know only a handful of people fitting this category,
none of them making out type of products (for instance professors).

\FigureImposeWidth{LWAfirstTimeRight}{The first time right?}{.7\textwidth}

Figure~\ref{fig:LWAfirstTimeRight} shows the relationship between team size and the chance
of successfully following the {\it first time right} approach.

\FigureImposeWidth{LWAfeedbackSmall}{Example with diffrent feedback cycles (3, 2, and 1 months)
showing the time to market decrease with shorter feedback cycles}{.7\textwidth}

Understanding of the problem as well as the solution is key to being effective.
Learning via feedback is a quick way of building up this understanding.
Waterfall methods all suffer from late feedback, see figure~\ref{fig:LWAfeedbackSmall}
for a visualization of the influence of feedback frequency on project elapsed time.

The evolution of a platform is illustrated in figure~\ref{fig:LWAplatformEvolution}
by showing the change in the Easyvision~\cite{www:MedicalImagingCaseStudy}
platform in the period 1991-1996. It is clearly visible that every generation doubles the
amount of code, while at the same time half of the existing code base is touched by changes.

\FigureImposeWidth{LWAplatformEvolution}{Platform Evolution (Easyvision 1991-1996)}
{.7\textwidth}

