A Rationale-based Model for Architecture Design Reasoning

1.2. Research motivations and research questions
such, the design could be violated and the cost of architectural design change could be
very high and even prohibitive. Kruchten et al. suggested that architecture knowledge
consists of the architecture design and its design rationale [86].
Despite the work by researchers such as [18, 24] and the standards organisations such as
[70, 164], the adoption of design rationale is sporadic. Design decisions still rely heavily on
the intuition and the experience of individual architects irrespective of the development
methodology being employed. The quality of an architecture design therefore largely
depends on the architecture decisions made by architects. Therefore the study of making
rational and objective design decisions is worthwhile.
1.2 Research motivations and research questions
Architecture design is one of the early steps and arguably one of the most important
steps in the software development life-cycle (SDLC). It provides a foundation to construct
a system. Architecture design decisions thus become early design commitments in the
SDLC. Activities of architecture design such as the procurement of platforms, determining
interface standards, outlining system design structure and determining development
standards are decided and executed at an early stage of the design process that can be
difficult to change or reverse later. Hence it is important to ensure that the decisions
behind the architecture design are correct. In this section, we describe the motivations
and the research questions addressed by this thesis.
1.2.1 Motivations
The software engineering community has long been aware of the issue relating to the loss
of design rationalisation knowledge. This phenomenon is evident in a lack of architecture
design justification process that uses design rationale and a lack of design rationale
documentation [11]. Researchers have put forward many suggestions to address this issue
[14, 129, 33, 124, 94]. Argumentation-based design rationale methods address the
issue of deliberation but they face challenges in their implementation (see Chapter 3).
Methods such as ATAM, CBAM, and Views and Beyond to aid architecture design have
also been suggested [8, 23]. However, the software development industry does not seem
to have adopted such practices and it is unclear what methods are used instead, if any.
We conjecture that the following factors contribute to the difficulties in design rationale
implementation. We subsequently provide evidence through a survey to prove some of
them:
4