\section{Education}

\FigureImposeWidth{FARcurriculumSA}{Proposed Curriculum for System Architects}{.9\textwidth}

A curriculum proposal for architects is shown in Figure~\ref{fig:FARcurriculumSA}.
At the top of the figure the growth path of a system architect is shown.
Below the courses or course subjects are shown which fit in the architect career path.
Note that this is not a unified list for all architects. Instead it is a palette of
courses, where the architect must select the courses which best fit his current needs.
In color coding is indicated if courses are available internal or external.

\FigureImposeWidth{AMOoverview}{The outline of a CAFCR based architecting method}{.8\textwidth}

Figure~\ref{fig:AMOoverview} shows the overall outline of an architecting method,
as it is being used in the MOSAD or {\it Architectural Reasoning} course.
The right hand side shows the visualization of the steps of the method.
The {\it framework} is a decomposition into five views, the ``CAFCR'' model,
{\it Customer Objectives}, {\it Application}, {\it Functional}, {\it Conceptual},
and {\it Realization} views.

Per view in the decomposition a collection of {\it submethods} is given.
The collections of submethods are open-ended. The collection is filled by borrowing relevant
methods from many disciplines.

A decomposition in itself is not useful without the complementing integration.
{\it Qualities} are used as {\it integrating} elements. The decomposition into qualities is orthogonal to the
``CAFCR'' model.

The decomposition into CAFCR views and into qualities both tend to be rather {\it abstract}, {\it high level}
or {\it generic}. Therefore, a complementary approach is added to {\it explore specific details}:
story telling. Story telling is the starting point for specific case analysis and design
studies.

\FigureImposeWidth{RATWpyramid}{Connecting System Design to Detailed Design}{.5\textwidth}

These approaches are combined into a thread of {\it reasoning}: valuable insights in the different views
in relation to each other. The basic working methods of the architect and the decompositions should help
the architect to maintain the overview and to prevent drowning in the tremendous amount of data
and relationships. The stories and detailed case and design studies should help to keep the
insights factual.

The translation of system requirements into detailed mono-disciplinary design decisions spans many orders of magnitude.
The few statements of performance, cost and size in the system requirements specification ultimately
result in millions of details in the technical product description:
million(s) of lines of code, connections, and parts.
The technical product description is the accumulation of {\it mono-disciplinary} formalizations.
Figure~\ref{fig:RATWpyramid} shows this dynamic range as a pyramid with the system at the top and the
millions of technical details at the bottom.

\FigureImposeWidth{RATWdisconnect}{Organizational Problem: Disconnect}{.6\textwidth}

The combination of Figures~\ref{fig:AMOoverview} and~\ref{fig:RATWpyramid} brings us to
a very common organizational problem: the disconnect between customer oriented reasoning (breadth, CAFCR)
and technical expertise (depth, the mono-disciplinary area in the pyramid).
Figure~\ref{fig:RATWdisconnect} shows this disconnect.

\FigureImposeWidth{RATWbreadthAndDepth}{Architect: Connecting Problem and Technical Solution}{.6\textwidth}

Our definition of the work of an architect places this role
as a bridge between these two worlds, as shown in Figure~\ref{fig:RATWbreadthAndDepth}.
In essence the architect must combine and balance breadth and depth iterations.

\FigureImposeWidth{RATWmentalDynamicRange}{Major Bottleneck: Mental Dynamic Range}{.4\textwidth}

We should realize that this architect role is quite a stretching proposition.
The architect is stretched in customer, application and business direction and
at the same time the same architect is expected to be able to discuss technological details
at nuts and bolts level. By necessity the architect will function most of the time
at higher abstraction levels, time does and brain capacity don't allow the architect to spend all time
at detailed design level.
Figure~\ref{fig:RATWmentalDynamicRange} shows that different people fill different
spots in the abstraction hierarchies. For communication purposes and to get a healthy system
design the roles must have sufficient overlap. This means that all players need to be stretched
regularly beyond their natural realm of comfort.

The MOSAD course provides means to address:
\begin{myList}
\item the breadth of systems architecting
\item the depth of technological design
\item the connection of breadth and depth
\end{myList}
If we look back at the first editions of the MOSAD course, then we see that participants
have the tendency to either go for breadth or for depth. But exploring both breadth and depth,
and even more challenging connecting breadth and depth appears to be very difficult.

