\section{Platform}
\label{sec:HMPAplatform}

Many people advocate generic developments, such as platforms, claiming a wide range of advantages.
Effective implementation of generic development has proven to be quite difficult.
Many attempts to achieve
these claims by generic developments have resulted in the opposite goals,
such as increased time to market, quality
and reliability problems et cetera.
We need a better rationale to do generic developments, in order to design an
effective platform creation process.

\FigureImposeWidth{GDdrivers}{Drivers of Generic Developments}{10cm}

Figure~\ref{fig:GDdrivers} shows drivers for
Generic Developments and the derived requirements
for the Generic Something Creation Process.
The first driver ({\it Customer value} is extrovert:
does the product have value for
the customer and is he willing to buy the product?
The second driver {\it Internal Benefits} is introvert,
it is the normal economic constraint for a company.

Today high tech companies are knowhow and skill constrained,
in a market which is extremely fast changing and
which is rather turbulent.
Cost considerations are degraded to an economic constraint, which is orders of magnitude less
important than being capable to have valuable and sellable products.

The derivation of the requirements shows clearly that these requirements are not a goal in itself.
For instance an shared
architecture framework is required to enable features
developed for one product to be used in other products
as well, which in turn should have value for a customer.
So the verification of this requirement is to propagate a new 
valuable feature from one product to the next, with small effort and lead time.

These drivers and requirements derivation is emphasized,
because many generic developments result in
large monolithic general purpose things, fulfilling:
\begin{myList}
\item availability accumulated feature set
\item designed for configurability
\item shared architectural framework
\item mature
\end{myList}
without bringing any customer value;
''You can not have this easy shortcut, because our architectural
framework does not support it,
changing the framework will cost us 100 man-years in 3 years elapsed time''

\FigureImposeWidth{HMPAplatform}{What is a Platform?}{.8\textwidth}

But what is a {\it platform}?
Many different types of platforms can be found.
Figure~\ref{fig:HMPAplatform} shows a classification of platforms along an axis of
increasing content and integration.
The ``lightest'' platform is a shared set of concepts, where every product implements it's own instantiation.
The most ``heavy'' platform is the implementation of a superset of all products,
where the creation of a product {\it only} involves a configuration step of selecting the right functionality
and performance.
The figure shows some intermediate possibilities, from light to more heavy respectively:
a collection of shared implementations of components, the same plus infrastructure, and
a complete pre-integrated framework.
{\it Light} platforms require lots of integration effort, are very flexible, have low coupling, 
and require a lot of complex configuration management effort.
{\it Heavy} platforms do not require much integration, are not flexible, create lots of coupling
between products, and require less complex configuration management at the expense of coupled release
cycles.

\FigureImposeWidth{HMPAplatformDeliverablesSimplified}{Platform Source Deliverables}{.8\textwidth}

\FigureImposeWidth{HMPAplatformDeliverables}{And now in More Detail...}{.8\textwidth}

The platform development results in deliverables.
To support integration and trouble shooting the delivery of source information is recommended.
Black box reuse tends to create surprises, due to invisible consequences.
However, delivering the source code itself, creates additional requirements. The source code is
only useful if the {\it development environment}, {\it specifications}, {\it configuration management},
{\it documentation tools}, {\it development process} and guidelines for the {\it infrastructure}
are also provided. Figure~\ref{fig:HMPAplatformDeliverablesSimplified} shows these deliverables, and
Figure~\ref{fig:HMPAplatformDeliverables} shows the same deliverables with more detailed content.
The message of this last figure is that much more is involved in platform development
than a set of source code files.

\FigureImposeWidth{HMPAreuseEfficiency}{Example of Platform Efficiency}{.8\textwidth}

The case, as shown in Section~\ref{sec:HMPAcase}, used a platform approach to share common functions.
In the table in Figure~\ref{fig:HMPAreuseEfficiency} the efficiency of this
platform approach is evaluated. The basis for this evaluation is the number of different
applications that has been realized and the required effort.
This table shows that 13 persons were needed per application in 1993, while
in 1996 only 3 persons per application were needed.
The re-use of lower level functions facilitated a more efficient application development process.
In practice the lead-time reduction of new applications was even more important.
A rich and flexible platform is also a rapid prototyping vehicle.
This last argument is far from trivial: many platforms are large and complex and do not facilitate
rapid prototyping at all!

\FigureImposeWidth{HMPAembedding}{Purchased SW Requires Embedding}{.8\textwidth}

A complicating factor is the use of COTS (Commercial Of The Shelf) software.
Software developed as part of a platform follows the architecture guidelines of the platform.
However, purchased software has been developed independent of the platform, using it's
own architecture guidelines.
Figure~\ref{fig:HMPAembedding} shows that purchased software requires some kind of
embedding to fit it into the desired architecture.

\FigureImposeWidth{HMPAembeddingCost}{Embedding Costs of Purchased SW}{.8\textwidth}

Figure~\ref{fig:HMPAembeddingCost} zooms in on the typical additional efforts to embed
purchased software in a platform.
Most embedding effort is required to ensure the desired system level behavior and qualities:
configuration, installation, start-up and shutdown et cetera.

\FigureImposeWidth{ARmergeProblems}{Example of Embedding Problems}{.8\textwidth}

The mismatch of existing platform software and purchased software results in lots of unwanted side-effects.
Figure~\ref{fig:ARmergeProblems} shows a number of these unwanted side-effects.
The side-effects cause the addition lots of code, in the form of wrappers, translators and so on, while this
additional code adds complexity, it does not add any end-user value.

