A Rationale-based Model for Architecture Design Reasoning

8.2. The architecture rationalisation method
a decision.
This approach allows architects and designers to justify a decision based on the explicit
representation of motivational reasons and design rationale. It provides a structure to
support an objective decision making process. However, the assessment could still be
biased if the architect is subjective and opinionated towards one solution. The qualitative
reasoning mandated by ARM would encourage an architect to consider the options and
their relative benefits. Additionally, the recording of such reasoning could be used for
architecture verification. As such, it will reduce the chance of undesired biases.
8.2.2 Quantitative rationale
There are a number of methods to support quantitative analysis for decision making.
Notable examples are CBAM [4] and AHP [2]. These methods commonly use priority, costs
and benefits for assessing different options to make a decision. This may be justifiable for
some of the key architecture decisions where a group of stakeholders are gathered together
in the assessment process. It would be quite a costly process to always make decisions
with a group of stakeholders. For most typical architecture decisions, however, only one
architect or a small group of architects would be responsible after consultation with the
stakeholders concerned.
In ARM, decision making requires the evaluation of the costs, benefits and risks of
design options, and such evaluations are the quantitative rationale QNR for comparing
and selecting design options. For instance, when two options are considered in a decision,
their relative costs, benefits and risks can be compared in an explicit way to justify a
decision. In a survey, we have asked practising software architects if they think these
design rationale are useful. Their responses suggested that such design rationale are
indeed very useful in justifying the design options (see Section 5.3.4). Furthermore, A
quantitative approach could be more effective in characterising the decision, costing the
design and improving the design process [42].
Expected costs and benefits
If there are different ways to design a system to achieve a set of goals, we can assume
that an experienced and logical designer would attempt to select a viable design. To
achieve this, an architect would first eliminate those options that would not work. Then
the architect would find a design which maximises the benefits of the outcomes whilst
minimises its cost. If more than one option is available, this exercise can be quite complex
138