\section{Environment}

The business process for an organization which creates and builds systems consisting of hardware and
software can be decomposed in 4 main processes as shown in figure~\ref{fig:PDBprocessDecomposition}.
This process decomposition model is more extensively discussed in\cite{www:ProcessDecompositionOfBusiness}.

\FigureTextwidth{PDBprocessDecomposition}
{Simplified decomposition of the Business}

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[Policy and Planning 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{DTAlineOrganization}{Line Organization Stovepipe}{.6\textwidth}

The challenge for companies is to organize themselves in a way that support these 4 different types of
processes. Rather common is that the {\t People and Technology Management Process}
is mapped on the line organization, see Figure~\ref{fig:DTAlineOrganization}.
This figure also shows a common problem of hierarchical organization structures:
the organizational entities become (over)specialized stovepipes.

\FigureImposeWidth{DTAbusinessOrganization}{Business Organization Stovepipe}{.6\textwidth}

The {\it Product Creation Process} maps often on a business oriented project organization,
as shown in Figure~\ref{fig:DTAbusinessOrganization}.
The stovepipe problem is here also present, although the stovepipes are
now in the product/market direction.

\FigureImposeWidth{DTAmatrixOrganization}{Different Concerns}{.8\textwidth}

The combination of both organization models results in a matrix organization,
where the two types of organizations have different concerns.
The line organization is competence and skill oriented, looking for synergy and re-use opportunities.
The line organization typically has a long term focus, but an introvert perspective.
The business organization is customer oriented and result driven.
The business organization typically has a short term focus, but an extrovert perspective.

\FigureImposeWidth{SAPprocessSimplified}{Positioning System Architecting}{.8\textwidth}

Figure~\ref{fig:SAPprocessSimplified} positions the {\it System Architecture Process}
in the simplified process decomposition.
The System Architecture Process bridges the Policy and Planning Process and the Product Creation Process.
The roadmaps made in the policy and planning process are the shared understanding of direction of the company:
\begin{myList}
\item It positions the products in the market and within the product portfolio.
\item It shows the relations between products, such as re-use of technology.
\item It positions the product in the technology life-cycle.
\item It relates products and technology to the (long lead) development of people and process
\end{myList}

The System Architecture Process is the process that:
\begin{myList}
\item Gathers input for the Policy and Planning Process
\item Brings in technical overview and common sense in the Policy and Planning Process and
the Product Creation Process
\item Transfers the intention of the Policy and Planning Process into the Product Creation Process
\item Performs the system level Requirement analysis, Specification, Design and Verification
\item Maintains the consistency, integrity and  balance.
\end{myList}

\FigureImposeWidth{DTAenvironmentFactors}{What Can We Do to Improve the Environment?}{.6\textwidth}

Until now we have sketched the organizational and process environment in which the system architect operates.
A complex environment that is full of human factors, such as conflicting interests
and complementing (or opposing?) characters.
The natural growth direction in this environment is specialization.
In some organizations the security or standardization efforts hurt the architecting effectiveness.
For example, we have seen organizations where customer key drivers, cost of ownership models,
and market roadmaps are marketing confidential. The gap as described in Figure~\ref{fig:RATWdisconnect}
is here imposed by the organization.

Figure~\ref{fig:DTAenvironmentFactors} shows what we can do to improve the environment
from system architecting perspective.
\begin{description}
\item[Systems engineering as discipline]
Conventional disciplines are technology oriented, for instance: mechanical, electrical, and software engineering.
However, systems engineering has grown into a discipline itself.
Most organizations have a severe lack of systems engineers and systems architects.
Organizational ownership for systems engineering as a discipline counter-balances the natural
tendency towards specialization.
\item[Job rotation] is one of the means to broaden employees.
The cultivation of a systems attitude requires such a broadening,
it is a prerequisite to become systems engineer
\item[Stimulate architect exposure] to help them overcome their introvert nature and
to help them bridge the gap between managers and architects.
\item[stretch all engineers] The broadening mentioned before should not be limited to
(potential) system architects. The extremely challenging job of a system architect becomes
somewhat more feasible if the engineers are at least system-aware.
\item[cultivate customer and market oriented culture]
Especially in large organizations the distance from local organizational concerns to customers and market
can become large.
System architects suffer tremendously from introvert organizations, because
the architect has to connect the customer and market needs to technological decisions.
\item[share and invest in future exploration and vision]
Good architects base their work on a vision.
Some investment is needed to create a vision and to keep the vision up-to-date.
A vision becomes much more powerful if it is shared throughout the organization.
\end{description}
