A Rationale-based Model for Architecture Design Reasoning

2.2. Architecture frameworks and design rationale
• Applications Viewpoint - the software design of the system. It represents the highlevel
design of the system. Some frameworks have further classifications such as a
software configuration model and a model representing process execution.
• Technology Viewpoint - the technologies which support the system. This represents
the hardware and software platforms and their organisations in the architecture.
Although some of the frameworks specify the processes and the methodologies that
are used in the construction of these viewpoints, for instance, DoDAF have suggested to
use design tradeoffs [31] and TOGAF specifies the capture of design rationale [71, 164]
in their models, there is still very little considerations on the decision making process
which underpins and justifies the architecture. In an earlier study to compare architecture
frameworks [160], it was found that these architecture frameworks do not mandate rationale
capture nor do they specify how rationale should be represented or used. Without
a proper guideline, architecture design rationale is probably not captured in these large
enterprise systems. There are three implications:
• Lack of Justifications - A lack of design rationale documentation in large enterprise
systems development implies that stakeholders would have to assume that the
architecture design decisions that are made are comprehensive and correct.
• Knowledge Loss - The knowledge that is required to support maintenance in the
long-term may be lost because the rationale behind the architecture design are gone
when original designers are no longer available.
• Quality Depends on Designer Experience - Without a systematic design rationalisation
process, architecture design and its quality would have a high dependency
on the level of experience of the designer.
Although the IEEE 1471-2000 standard [70] and some of the architecture frameworks
discuss the importance of design rationale, none of them provide much guidance in the
use, the capture or the representation of design rationale. This does not necessarily mean
that the architecture design are inferior, but the lack of an objective decision-making
framework would place a higher reliance on the experience and the quality of the decision
makers whereas a well-defined decision making approach can provide a systematic way to
ensure architecture design qualities.
22