\section{Architectural Refactoring}

Combining existing software packages is mostly difficult due to ``architectural mismatches''.
Different design approaches with respect to exception handling, resource management,
control hierarchy, configuration management et cetera, which prohibit straightforward merging.
The solution is adding lots of code, in the form of wrappers, translators and so on, while this
additional code adds complexity, it does not add any end-user value.

Performance and resource usage are most often far from optimal after a merger.

Amazingly many people start worrying about duplication of functionality when merging, while
this is the least of a problem in practice. This concern is the cause of reuse initiatives,
which address the wrong (non-existing) problem: duplication, while the serious architectural
problems are not addressed.

\FigureImposeWidth{ARmergeProblems}{Merge problems}{8cm}

The proposed solution to this set of problems is {\bf architectural refactoring}.
Architectural refactoring is an incremental approach, putting a lot of emphasis on feedback.
Two major criteria to get feedback on are:
\begin{myList}
\item How well does the current architecture support today's product needs?
\item How well will the architecture evolve to follow the market dynamics?
\end{myList}
In every increment to the market both concerns should be addresses, which translates in
clear business goals (product, functions, value proposition) {\bf and} clear refactoring goals
fitting in a limited investment.
The refactoring goals should be based on a longer term architecture vision,
see~\ref{fig:ARsolution}.

\FigureImposeWidth{ARsolution}{Solution: Architectural Refactoring}{8cm}

Examples of Refactoring goals can be seen in figure~\ref{fig:ARrefactoringGoals}.
These refactoring goals should be sufficiently ``SMART'' to be used as feedback criterium.

{\it Note: many refactoring projects spend lots of effort, while critical review afterwards
does not show any improvement. Often loss of goal or focus is the basis for such a disaster.}

\FigureImposeWidth{ARrefactoringGoals}{Example of Refactoring Goals}{8cm}

Architectural refactoring looks at all architectural aspects, from functions and structure to
selection of mechanisms and technologies.
Code refactoring, well known from extreme programming~\cite{book:ExtremeProgramming},
plays a role at a much more microscopic level.
See figure~\ref{fig:ARcodeVersusArchitecturalRefactoring} which shows both
ways of refactoring side by side.
Some code refactoring requires an update of the architecture. At the other hand architectural
changes quite often have a significant software impact.

\FigureImposeWidth{ARcodeVersusArchitecturalRefactoring}{Architectural and Code refactoring}{\textwidth}

\subsection{Prerequisites for effective architectural refactoring}

{\bf Frequent feedback}

Understanding of the problem as well as the solution is key to being effective.
Learning via feedback is a quick way of building up this understanding.
Waterfall methods all suffer from late feedback, see figure~\ref{fig:LWAfeedbackSmall}
for a visualization of the influence of feedback frequency on project elapsed time.

\FigureImposeWidth{LWAfeedbackSmall}{Frequent feedback results in faster results and a
shorter path to the result}{\textwidth}

{\bf Awareness of dynamics}

The world is highly dynamic, the markets and applications change rapidly, while the famous
law of Moore shows the incredible speed of technological developments.
Unfortunately most people believe in stability and are biased towards stabilizing architectures.
Architectures and their implementations are sandwiched between the fast moving
market at one side and technology improvements at the other side. Since both sides
change quite rapidly, the architecture and its implementation will have to change in response,
see figure~\ref{fig:LWAplatformStability}.

\FigureImposeWidth{LWAplatformStability}{Myth: Platforms are Stable}{8cm}

The evolution of a platform is illustrated in figure~\ref{fig:LWAplatformEvolution}
by showing the change in the Easyvision~\cite{www:MedicalImagingCaseStudy}
platform in the period 1991-1996. It is clearly visible that every generation doubles the
amount of code, while at the same time half of the existing code base is touched by changes.

\FigureImposeWidth{LWAplatformEvolution}{Platform Evolution (Easyvision 1991-1996)}{\textwidth}

{\bf Long Term Vision}

In order to set refactoring goals it is useful to have a long term vision on the architecture.
Such a long term vision may be quite ambitious. The ambition of the vision will be balanced
by the pragmatics of short term business goals and limited investments in improvement.

Figure~\ref{fig:ARlongTermVisionExample} shows an example of a long term vision,
where a framework is foreseen, which decouples 6 design and implementation concerns:
\begin{myList}
\item applications
\item services
\item personalization
\item configuration
\item computing infrastructure
\item domain infrastructure
\end{myList}
The actual implementation will not have such a level of decoupling for a long time,
the penalty in effort, resource usage and many other aspects will be prohibitive for
a long time. Nevertheless the decoupling will become crucial if the variety of products
is really very large and dynamic.
 
\FigureImposeWidth{ARlongTermVisionExample}{Example Long Term Vision}{10cm}
