\section{Experience}

The effectiveness of an architect depends on experience.
In all years of being an engineer, designer and architect, a lot of different
needs in different contexts with different solutions with different complicating
challenges pass by.
If all these events are processed by the (potential) architect, then
a frame of reference is created that is very valuable for future architecting work.

\FigureImposeWidth{DTAtrapezoidPatterns}{Example: Trapezoid Pattern}{.8\textwidth}

In this section we will illustrate the experience factor by means of a few
architecture patterns that repeatedly popped up in completely different domains.
For this purpose we look at the {\it Trapezoid Pattern}, 
as shown in Figure~\ref{fig:DTAtrapezoidPatterns}.
One of the very common technical problems is the actuation by software of some
physical entity, for instance for positioning, moving or displaying.
In these cases the software often has to create set-points for one parameter,
where this parameter is constant at different levels for some time and switches linearly
from one level to another level. For instance, a sample table is at a given position
(constant), moves with a constant velocity to the next position, and then stays at the next position
for some time (constant).
This same behavior is also present in the actuation of gradient fields in MRI scanners,
and in the grey level mapping in imaging displays (although the last example uses grey levels
as running parameters instead of time).

\FigureImposeWidth{DTAtrapezoidChain}{From SW input to physical Effect}{.7\textwidth}

In the system a chain of transformations takes place to get from a high level software representation
towards an actual physical behavior by physical objects.
Figure~\ref{fig:DTAtrapezoidChain} shows such a chain of three steps:
{\it computation}, {\it conversion}, and {\it actuation}.
Note that this chain is often more complex in real systems with
more software steps (controller algorithms, corrections),
more electronic steps (controllers, amplifiers),
and more mechanical steps (motors, transmission).
The high level software representation that is the starting point
is unconstrained (high precision in time as well as in value).
The most common representation is break-point based:
the coordinates, where the running parameter changes the linear behavior, are specified.

The conversion and actuation steps have their own particular transfer functions.
These steps may introduce additional delays, noise, variations et cetera.
The virtual model in the high level software does not take this into account
or makes (calibrated) assumptions.

\FigureImposeWidth{DTAtrapezoidDiscretization}{Discretization effects}{.5\textwidth}

The {\it computation} step transforms the unconstrained representation into
a constrained sampled list of values.
This transformation is a discretization in two directions: time and value,
see Figure~\ref{fig:DTAtrapezoidDiscretization}.
This discretization may introduce system level problems:
\begin{description}
\item[Staircase effects] the linear shape is approximated by many staircase-like steps. The question is
how this software output is transformed into the actual physical actuation and if artifacts will be
observable in the physical performance.
\item[Not all values can be reached]. Normally the digital to analog conversion is a bottleneck in the
values that can be reached. This conversion can be very much limited in low cost solutions (8-bits, 256 values)
to limited (16-bit, 65536 values). The time-values are also limited, varying from sub-microsecond for more expensive
solutions to milliseconds for simple low-cost controls.
The consequence of this limitation is that the physical reality may differ in a systematic way from the
virtual model in the high level software.
For example the high level software may have determined that at moment $t=3.14159$ the system should be at position
$x=2.718281$, while actually the system is controlled to stop at $t=3.1$, $x=2.7$.
\item[Impact on frequency domain] The staircase approximation of linear behavior introduces many higher frequencies
in the frequency domain.
Many of the higher frequency artifacts are filtered out in the analog and physical part of the chain.
However, due to aliasing-like problems the system performance might degrade in unexpected ways.
\item[Broken invariants (surface)] The high level software model in many systems is based on invariants.
For instance, if we control velocity linear, then we expect that we now the position as the integral of velocity.
Discretization, at lower software level, will violate the higher level assumption.
If the model assumes we move with $v=3.14159 m/s$, while we actually move with $v=3.1 m/s$, then
the position will deviate significant.
Interestingly, the low level software can compensate for this error by modulating
the value: 58\% of the time $v=3.1 m/s$ and 42\% of the time $v=3.2 m/s$.
These solutions work, but introduce again their own next level of problems and artifacts.
In this example the frequency of the modulation may introduce unexpected physical behavior,
such as vibrations.
\end{description}
A priori use of the need for discretization can also turn into a benefit. Especially
the consequent use of integer representations (with some pragmatic normalization, such as $255=5 Volt$)
reduces processor load, memory use and may increase system performance.

Discretization problems, the artifacts introduced by discretization, the measures against artifacts
are also universally applicable. However, the exact consequence and the right countermeasure
are domain dependent.

\FigureImposeWidth{MITORfalseContouring}{Example of Discretization Problem}{.4\textwidth}

As example of discretization problems Figure~\ref{fig:MITORfalseContouring} shows
a typical image quality problem that popped up during the integration phase of a Medical Imaging Workstation.
The pixel value $x$, corresponding to the amount of X-ray dose
received in the detector, has to be transformed into a grey value $f(x)$ 
that is used to display the image on the screen.
Due to discretization of the pixel values to 8 bits {\it false contours} become visible.
For the human eye an artefact is visible between pixels that are mapped on a single grey value
and neighboring pixels that are mapped on the next higher grey value.
It is the levelling effect caused by the discretization that becomes visible as false contour.
This artefact is invisible if the natural noise is still present.
Concatenation of multiple processing steps can strongly increase this type of artifacts.

\FigureImposeWidth{DTAtrapezoidContinuity}{Example of Generic Smoothing Consideration}{.6\textwidth}

An example of a pattern that builds further on this transformation chain is
shown in Figure~\ref{fig:DTAtrapezoidContinuity}.
Physical systems in general start to show artifacts with discontinuous inputs.
The linear approximation used in the trapezoid pattern has a discontinuity
in the derivative. For example, if we control velocity, then the acceleration
jumps at the break-point. A solution for this discontinuity is to {\it smooth} the input
function, for instance by a low-pass filter. Note that most analog and mechanical
systems are already natural low-pass filters. Despite the low-pass characteristic
of the later part of the chain artifacts might still be induced by the discontinuity.
These remaining artifacts can be further removed by using an explicit low-pass filter
in the high level software model.
Again this is an example of a pattern that is universally applied in multiple domains.

\FigureImposeWidth{DTAexperience}{Architects Collect a Rich Set of Patterns}{.7\textwidth}

The example showed a small subset of patterns that an architect experiences.
This subset as its has been discussed here is highly technical.
However, in real life technical patterns and organizational patterns are
experienced concurrently. For example in the trapezoid example also a number of
organizational patterns pop up, related to mono-disciplinary experts and multi-disciplinary
design, and system integration.

In Figure~\ref{fig:DTAexperience} the career of an architect is shown with
the repeated encounters of patterns in different products and in different environments.
We estimate that an experiences architect encounters (and files and uses) thousands
of patterns. All these patterns form a frame of reference for the architect as an individual.
This frame of reference helps the architect to assess new architectures very quickly.
Potential problem areas are identified and design issues are weighted very fast,
thanks to this frame of reference.

