\section{The Time Dimension}
\label{sec:HMPAtimeDimension}

\FigureImposeWidth{HMPAreleaseModel}{Who is First: Platform or Product?}{.8\textwidth}

Many philosophies are practiced to synchronize platforms and products.
The main choice is the primary vehicle for change:
\begin{myList}
\item innovate in products and consolidate in a platform
\item innovate in the platform and propagate to products
\end{myList}
These two variants are visualized in Figure~\ref{fig:HMPAreleaseModel}.

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.
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}{Feedback (3)}{.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.

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

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{HMPAlifecycles}{Life-cycle Differences}{.8\textwidth}

The business context, the application, the product and it's components have all their
own specific life-cycles. In Figure~\ref{fig:HMPAlifecycles} several different
life-cycles are shown. The application and business context in the customer world
are shown at the top of the figure, and at the bottom the technology life-cycles are shown.
Note that the time-axis is exponential; the life-cycles range from one month to more than ten years!
Note also the tension between commodity software and hardware life-cycles and software release life-cycles:
How to cope with fast changing commodities?
And how to cope with long living products, such as MR scanners, that use commodity technologies?

\FigureImposeWidth{MICAFreferenceModel}{Reference model for health care automation}{.8\textwidth}

Figure~\ref{fig:MICAFreferenceModel} shows a reference model for image handling functions.
This reference model is classifying application areas on the basis of those characteristics 
that have a great impact on design decisions, such as the degree of distribution,
the degree and the cause of variation and life-cycle.
Such a reference model is one of the means to cope with widely different life-cycles.

{\it Imaging and treatment} functions are provided of modality systems with the focus on the patient.
Safety plays an important role, in view of all kinds of hazards such as radiation,
RF power, mechanical movements et cetera. The variation between systems is mostly determined by:
\begin{myList}
\item the acquisition technology and its underlying physics principles.
\item the anatomy to be imaged
\item the pathology to be imaged
\end{myList}
The complexity of these systems is mostly in the combination of many technologies at state-of-the-art
level.

{\it Image handling} functions (where the medical imaging workstation belongs) are distributed over the hospital,
with work-spots where needed. The safety related hazards are much more indirect (identification, left-right
exchange). The variation is more or less the same as the modality systems: acquisition physics,
anatomy and pathology.

The {\it information handling} systems are entirely distributed, information needs to be accessible from everywhere.
A wide variation in functionality is caused by ``social-geographic'' factors:
\begin{myList}
\item psycho-social factors
\item political factors
\item cultural factors
\item language factors
\end{myList}
These factors influence what information must be stored (liability), or must not be stored (privacy),
how information is to be presented and exchanged, who may access that information, et cetera.

The {\it archiving} of images and information in a robust and reliable way is a highly specialized activity.
The storage of information in such a way that it survives fires, floods, and earthquakes is
not trivial\footnote{Today terrorist attacks need to be included in this list full of disasters, and
secure needs to be added to the required qualities.}. Specialized service providers offer
this kind of storage, where the service is location-independent thanks to the high-bandwidth networks.

All of these application functions build on top of readily available IT components: the {\it base technology}.
These IT components are innovated rapidly, resulting in short component life-cycles.
Economic pressure from other domains stimulate the rapid innovation of these technologies.
The amount of domain-specific technology that has to be developed is decreasing, and is replaced by
base technology.




