A Rationale-based Model for Architecture Design Reasoning

5.4. Discussion of findings
or considerations that influence architecture decision making, assess how they inter-relate
in the decision process, and generalise their use into architecture design patterns [3].
5.4.3 Designers’ attitude
Respondents frequently use design rationale to justify design choices. When we examine
the list of design rationales they use, it appears that those design rationale that positively
justify the design receive more attention than those negative rationales that explain why
the design may have issues. That leads us to suspect that there might be a tendency to
present good news rather than bad news during the design process. An analogous finding
[79] may give us some insights to this behaviour. In many industry scenarios that we have
encountered, some architects have a tendency to promote a design based on the benefits
of new technologies. However they often do not explain the potential negative impacts
of the new approach. Establishing if such a bias is commonly exhibited in architecture
would be useful, because awareness of this phenomenon would help architects to be more
objective in the assessment and selection of design choices.
5.4.4 Necessity for design rationale documentation
The survey found that there is a strong justification to document design rationale due to
the tendency of the architects’ forgetting their own design or the need for architects to
modify systems designed by other architects. However, not every system requires comprehensive
design rationale documentation because design rationale can be reconstructed for
non-complex systems. The extent to which design rationale are documented also depends
on the relative benefits it might deliver.
5.4.5 Design rationale to support impact analysis
Impact analysis requires the knowledge of dependency between design components [44].
The positive correlation between impact analysis tasks and the use and documentation
of design rationale indicates that the respondents realize the connection between the two
tasks at different stages of the development life-cycle. This finding indicates that there is a
need to capture and maintain design rationale as a first-class entity to facilitate traceability
during maintenance activities. The absence of design rationale may result in the violation
of constraints or assumptions in a design. That is why we argue that the availability of
design rationale can facilitate systematic reasoning to minimize the risks associated with
system enhancements. Collectively these results indicate that there is a necessity to use
76