A Rationale-based Model for Architecture Design Reasoning

2.1. Industry practice of design rationale
be more than one answer and most likely the answers are non-trivial. However, there is
something fundamental that underlies such project issues - the soundness of the design
decisions.
Software engineering practices mostly focus on the design of concrete and visible artefacts
and either omit or treat the decision making documentation as separate [43]. Design
rationale is commonly ignored and undocumented. Most of the time they are not mandated
as part of the software deliverable. Even though architecture design is thought to
be a very important stage in the development process, the architecture design rationale
are usually not rigorously tested in the design review process. The treatment of those
factors which influence the design decisions are usually implicit and ad hoc. For instance,
architecture decisions would make assumptions on factors such as delivery schedule, level
of expertise in the development team and platform stability, but these assumptions are
mostly implicit. Designers could be biased toward personal preferences and agenda that
would affect the objectivity of the design decisions.
Given that design decisions are predominantly an implicit process, it is possible and
quite common that a series of incorrect decisions can escape quality checks set out by
development methodologies and standards, resulting in project failures. Thus we posit
that improving the decision making process can help minimise mistakes and failures. Along
with many other researchers [11, 12, 124], we argue that making quality decisions is an
essential part of software development. High quality design requires that each decision is
rational and that all relevant factors which influence the decision are well considered. As
such, the system design process will improve if a methodology to enhance design decision
making is available.
In a successful project, planning and architecture design are two of the crucial steps
[154]. These two factors are interrelated in that the project plans set the constraints for
the architecture design, and the architecture design dictates the resources required in a
project. For instance, design decisions made during the architecture design dictate the
resources required to develop the system. Even though the role of architecture design is
very important in a project, its decisions are often not sufficiently justified. Less than
optimal decisions could be made and risk could arise when decisions are not justified
systematically. The author has numerous encounters of such incidents and some real-life
examples are illustrated below:
• Design for the Future - arguing for reusability or flexibility, the architects make
architecture design overly complex and costly without delivering additional benefits.
The reusable or flexible features are actually never required or necessary [15].
13