\section{Process View}
\label{sec:HMPAprocess}

The business process for an organization that creates and builds systems consisting of hardware and
software is decomposed in four main processes as shown in figure~\ref{fig:RSPprocessDecomposition}.

\FigureImposeWidth{RSPprocessDecomposition}{Simplified decomposition
of the business in 4 main processes}{.6\textwidth}

The decomposition in 4 main processes leaves out all connecting supporting and
other processes. The function of the 4 main processes is:
\begin{description}
\item[Customer Oriented Process] This process performs in repetitive mode all direct interaction with the customer.
This primary process is the cash-flow generating part of the enterprise.
All other processes only spend money.
\item[Product Creation Process] This Process feeds the Customer Oriented Process with new products.
This process ensures the continuity of the enterprise by creating products which enables the primary process
to generate cash-flow tomorrow as well.
\item[People and Technology Management Process] Here the main assets of the company are managed: the know how
 and skills residing in people.
\item[Strategy Process] This process is future oriented, not constrained by short term goals, it is
defining the future direction of the company by means of roadmaps. These roadmaps give direction
to the Product Creation Process and the People and Technology Management Process. For the medium term these
roadmaps are transformed in budgets and plans, which are committal for all stakeholders.
\end{description}

\FigureImposeWidth{SWRprocessDecompositionFamily}{Modified Process Decomposition}{.6\textwidth}

The simplified process description given in figure~\ref{fig:RSPprocessDecomposition}
assumes that product creation processes for
multiple products are more or less independent.
When generic developments are factored out for
strategic reasons an additional process is required to visualize this.
Figure~\ref{fig:SWRprocessDecompositionFamily} shows
the modified process decomposition (still simplified of course)
including this additional process "Generic Something Creation Process".

\FigureImposeWidth{SWRprocessDecompositionFamilyByValue}
{Financial Viewpoint on Process Decomposition}{.6\textwidth}

Figure~\ref{fig:SWRprocessDecompositionFamilyByValue}
shows these processes from the financial point of view.
From financial point of view the purpose of this additional
process is the generation of strategic assets. These assets
are used by the product generation process to enable tomorrow's cash-flow.

\FigureImposeWidth{SWRprocessDecompositionFamilyPlusFlow}{Feedback flow: loss of customer understanding!}{.6\textwidth}

The consequence of this additional process is an
lengthening of the value chain and consequently a longer feedback
chain as well. This is shown in figure~\ref{fig:SWRprocessDecompositionFamilyPlusFlow}.
The increased length of the feedback
chain is a significant threat for generic developments.
In products where integration plays a major role (which are nearly all products)
the generic developments are
pre-integrated into a platform or base product,
which is released to be used by the product developments.

\FigureImposeWidth{GDpropagationDelay}{The introduction of a new feature
as part of a platform causes an additional latency in the introduction to the market.}{8cm}

The benefit of this approach is separation of concerns and decoupling of products and
platforms in smaller manageable
units. Both benefits are also the main weakness of such a model,
as a consequence the feedback loop is
stretched to a dangerous length.
At the same time the time from feature/technology to market increases,
see figure~\ref{fig:GDpropagationDelay}.

The list of pitfalls in Figure~\ref{fig:GDpitfalls} has been compiled on the basis of many
disastrous or halfway successful efforts of platform developments.

\FigureImposeWidth{GDpitfalls}{Sources of failure in platform developments}{.8\textwidth}

Many different models for the development of generic things are in use.
An important differentiating characteristic
is the driving force, which often directly relates to the de facto organization structure.
The main flavors of driving forces are shown in figure~\ref{fig:GDmodels}.

\FigureImposeWidth{GDmodels}{Models for SW reuse}{.7\textwidth}

\subsection{Lead Customer}

The lead customer as driving force guarantees a direct feedback path from an actual customer.
Due to the importance
of feedback this is a very significant advantage.
The main disadvantages of this approach are that the outcome of
such a development often needs a lot of work to make it reusable as a generic product.
The focus is on the functionality
and performance, while many of the quality aspects are secondary in the beginning.
Also the requirements of this
lead customer can be rather customer specific, with a low value for other customer.

\subsection{Carrier Product}

The combination of a generic development with one of the product developments
also shortens the feedback
cycle, although it is not as direct as with the lead customer.
Combination with a normal product development will result in a better
balance between performance and functionality focus and quality aspects.
Disadvantage can be that the operational team
takes full ownership for the product (which is good!),
while giving the generic development second priority, which
from family point of view is unwanted.

In larger product families the different charters of the product teams creates a political tension.
Especially in immature 
or power oriented cultures this can lead to horrible counterproductive political games.

Lead customer driven product development,
where the product is at the same time the carrier for the platform
combines the benefits of the lead customer and the carrier product approach.
In my experience this is the most
effective approach of generic developments.
A prerequisite for success is an open and result driven culture to preempt
any political game mentioned before.

\subsection{Platform}

In maturing product families the generic developments are often decoupled
from the product developments.
In products where integration plays a major role (which are nearly all products)
the generic developments are
pre-integrated into a platform or base product,
which is released to be used by the product developments.


