\section{Market Driven}
\label{sec:HMPAmarket}

A useful top level decomposition of an architecture is provided by the
so-called ``CAFCR'' model, as shown in figure~\ref{fig:CAFCRannotated}.
The {\it customer objectives} view and the {\it application} view provide
the {\bf why} from the customer. The {\it functional} view describes the
{\bf what} of the product, which includes
(despite the name) also the {\it non functional} requirements.
The {\bf how} of the product is described in the {\it conceptual} and
{\it realization} view, where the conceptual view is changing less in time
than the fast changing realization (Moore's law!).

\FigureImposeWidth{CAFCRannotated}{The ``CAFCR'' model}{.8\textwidth}

The job of the architect is to integrate these views in a consistent and
balanced way. Architects do this job by {\it frequent viewpoint hopping},
looking at the problem from many different viewpoints, sampling the problem
and solution space in order to build up an understanding of the business.
Top down (objective driven, based on intention and context understanding) in
combination with bottom up (constraint aware, identifying opportunities,
know how based), see figure~\ref{fig:AMOintegratingCAFCR}.

In other words the views must be used concurrently, not top down like the waterfall model.
However at the end a consistent story must be available, where the justification
and the needs are expressed in the customer side, while the technical solution
side enables and support the customer side.

\FigureImposeWidth{AMOintegratingCAFCR}{Five viewpoints for an architecture.
The task of the architect is to integrate all these viewpoints, in order
to get a {\it valuable}, {\it usable} and {\it feasible} product.}
{.8\textwidth}

The model will be used to provide a next level of reference models and methods.
Although the 5 views are presented here as sharp disjunct views, many
subsequent models and methods don't fit entirely in one single view.
This in itself not a problem, the model is a means to build up understanding,
it is not a goal in itself.

\FigureImposeWidth{HMPAprojectsCase}{Example of Scoping of a Platform.}{.6\textwidth}

One of the key success factors of platform development is {\it scoping}.
The opposing forces are the efficiency drive by higher management teams, increasing the scope,
and the need for customer specifics by project teams, minimizing the platform scope.
Scope overstretching is one of the major platform pitfalls: in best case
the result is that the organization is very efficient, but customers are dissatisfied.
Worst case the entire organization drowns in the overwhelming complexity.
Blindly following (potential) customers is another pitfall: best case we end up with a satisfied
customer and a good starting point for next products.
The real challenge is to build up sufficient understanding to find the sweet spot for the platform
scope: efficient by leveraging synergy, but sufficiently agile to be responsive to customers.

Figure~\ref{fig:HMPAprojectsCase} shows an example of platform scoping.
In this case the synergy of the producer is in technologies, such as Closed Circuit TV (CCTV),
audio, broadcasting, access control, and networking.
These technologies are used in widely differing application domains:
airports, railway stations, intelligent buildings and motorway management systems.
These heterogeneous domains can share a platform, as long as the functionality is restricted to the
shared technologies.
The analysis to find the right level of synergy is based on the key driver
method~\cite{www:Requirements}.
The essence of the objectives of the customers can be captured in terms of
customer key drivers. The key drivers provide direction
to capture requirements and to focus the development.
The key drivers in the customer objectives view will be linked 
with requirements and design choices in the other views.
The key driver submethod gains its value from relating a few sharp articulated key drivers to a much
longer list of requirements. By capturing these relations a much better understanding of customer
and product requirements is achieved.

\FigureImposeWidth{COVmotorwayManagementKeyDrivers}
{Example of the four key drivers in a motorway management system}{.9\textwidth}

Figure~\ref{fig:COVmotorwayManagementKeyDrivers} shows an example of key drivers
for a motorway management system, an analysis performed at Philips Projects in 1999.
The same method has been applied on the other domains.

\FigureImposeWidth{MITORthread50}{Example Thread of Reasoning from the Medical Imaging Workstation}
{.8\textwidth}

The key drivers and design decisions can be visualized as a {\it thread of reasoning}~\cite{www:Thesis}
during the development of products and platform.
This thread of reasoning captures the essential relations between customers needs and technological
decisions, with emphasis on tensions and trade-offs.
Figure~\ref{fig:MITORthread50} shows an example of such a thread of reasoning for the Medical
Imaging Workstation.
