\section{Discussion}

Many similarities exist between the building architect and the (electronics) product architect.
The maturity of both disciplines is quite different. Architecting buildings is a very mature
discipline, with millenia of experience. At the other hand electronics and software are very young
disciplines, where the construction technology is changing rapidly. The (electronics) product
architecting is a very immature discipline.

\FigureImposeWidth{WDCarchitectingDynamics}{Architecting dynamics}{10cm}

The maturity influences the way of working of the architect. The building architect does most, if
not all, work at the beginning of a project. Figure~\ref{fig:WDCarchitectingDynamics} shows the
relative effort as function of time, showing that the building architect stops after delivering the
design. The building architect is not involved in building, preparing the use, or the actual use
of the building. The building architect is sometimes involved in the acceptance of the building,
the phase transition between building and using.

The product architect must be involved in the later stages of the project, to solve unforeseen
requirements and implementation hurdles. Due to the immaturity of the involved disciplines both
unforeseen requirements and implementation hurdles are a fact of life. If the architect
is not available in that phase the integrity of the architecture is in severe danger.

The strict phasing of the building world is in my opinion too strong. Many building architects don't
get practical feedback from builders and users. Also many unforeseen requirements and
implementation hurdles are also a fact of life in buildings. As example of an
unforeseen requirement we can look at the
{\it concentration} wish of the users, researchers, which had a significant impact on the
architecture. Examples of implementation hurdles are the climate control and the light controls.
