Review of research paper titled [Decision making and cognitive biases in designing software architectures](https://wwwmatthes.in.tum.de/file/2obyskxdzbng/Sebis-Public-Website/-/Decision-making-and-cognitive-biases-in-designing-software-architectures/Bh18a.pdf) (PDF) Authors: Akash Manjunath, Manoj Bhat, Klym Shumaiev, Andreas Biesdorf and Florian Matthes. *[See my blog article on this](https://serverlessfirst.com/debiasing-software-architecture-decisions/).* ## Summary - Context: - Software architects and developers make decisions which affect the overall success of the product they're building, from engineering quality to speed of delivery. They need to consider various factors such as long-term sustainability, skillset of their team, complexity and time constraints. - Problem: - But, afflicted by the human condition, architects are biased when making decisions. They use past experiences, familiarity with technologies, trends and other heuristics to come up with a plan of action. Because of these heuristics, the resulting (biased) decisions may lead to sub-optimal solutions. In many cases they aren't consciously aware of how they made the decision they did. If you asked them, they might struggle to explain their process. - Solution: - When making decisions, consider the phases in your decision-making process using the [[OODA loop]] model. Within each phase, there are several biases at play (33 specifically, within this study). By becoming aware of them (now and/or just-in-time as you are in the middle of making a decision) and learning some debiasing techniques specific to each bias, you can help improve the rationality of your decisions. - The full list of biases and when they apply are listed below: "List of 33 Cognitive Biases used in this study, grouped by OODA decision-making phase" - Caveats: - The bad news is that while awareness of the biases helps with debiasing, it alone is not sufficient to eliminate bias altogether. ### List of 33 Cognitive Biases used in this study, grouped by OODA decision-making phase - [[Observe (Decision-making phase)]]: - Information Gathering: - [[Completeness Bias]] - [[Confirmation Bias]] - [[Information Bias]] - [[Levels-of-processing effect (Bias)]] - [[Reference Bias]] - [[Search Bias]] - Information Presentation: - [[Framing Bias]] - [[Similarity Bias]] - [[Orient (Decision-making phase)]]: - Information Filtering: - [[Base rate fallacy (Bias)]] - Semblance: - [[Similarity Bias]] - Previous Knowledge/Experience - [[Availability Heuristic (Bias)]] - [[Functional Fixedness (Bias)]] - [[Google Effect (Bias)]] - [[Law of the instrument (Bias)]] - [[Mere exposure effect (Bias)]] - Trends: - [[Bandwagon Effect (Bias)]] - [[Decide (Decision-making phase)]]: - Complexity: - [[Attenuation Bias]] - [[Hard-easy Effect (Bias)]] - [[Planning Fallacy (Bias)]] - [[Time-saving bias]] - [[Parkinson’s Law of triviality (Bias)]] - [[Well travelled road effect (Bias)]] - Nature of invention / Trends - [[Bandwagon Effect (Bias)]] - [[IKEA Effect (Bias)]] - Previous Knowledge / Experience - [[Habit (Bias)]] - [[Law of the instrument (Bias)]] - [[Mere exposure effect (Bias)]] - [[Negativity (Bias)]] - Strategy - [[Test (Bias)]] - [[Hyperbolic Discounting (Bias)]] - [[Inconsistency (Bias)]] - [[Act (Decision-making phase)]]: - [[Misinformation effect (Bias)]] - [[Post-purchase rationalization (Bias)]] ## Highlights - **Abstract**: **The architecture of any software can be thought of as a blueprint of its structure. This blueprint is an artifact generated based on a series of decisions taken by software architects and determines the overall quality of the resulting software.** The first part of this paper focuses on identifying and formalizing the decision-making models in the context of designing software. Three models are investigated in detail: the rational economic model, the bounded rational model, and the recognition-primed decision model. The steps of decision making are mapped to the OODA Loop (Observe, Orient, Decide and Act) decision cycle as a generic framework for decision making. The second part of this paper focuses on documenting cognitive biases in the context of architectural decision making. ==**Architects, being human, are invariably subject to the influence of cognitive biases due to the cognitive limitations of the human mind, resulting in a systematic deviation from the ideal decision- making process. This leads to the design of sub-par solutions because of missing rationality behind the decisions.**== A two-level classification is made to modularize the extensive list of biases that influence the architectural decision-making process. As an important outcome of this research, detailed information about each bias is documented as part of a cognitive bias catalog. __Index Terms__—Decision-making process; OODA loop; Architectural design decision; Cognitive bias. - What are the decision-making models used in the context of designing software? 3 models: - Rational Economic Model - Bounded Rational Model - Recognition-Primed Decision Model - The generic framework for decision making known as the [[OODA loop]] (Observe, Orient, Decide and Act) is mapped to by each of the above 3 models. - Section 1 (Introduction): - Software architecture is a set of architectural design decisions (ADDs) - **Software architects and developers make these ADDs and ==in many cases they may not be aware of how they made those decisions==** - Architectural decision making is a continuous process which is often implicit, complex, and knowledge intensive. It is a key factor for the sustainability of software systems. In recent years, evidence has been provided to show that architects either follow rationalistic or naturalistic decision-making process. - In parallel, it has also been shown that architects are biased during their decision making - ==**Architects regularly use past experiences, familiarity with technologies, trends, and other heuristics or “cognitive shortcuts” to make decisions. The resulting decisions are biased due to the use of heuristics and may lead to “sub-optimal” or “satisficing” solutions**== - During the decision-making process, architects like all humans are constrained by their ==**cognitive limitations which are affected by factors including information overload, complex data, and time constraints**==. The cognitive limitations manifest in the form of cognitive biases resulting in suboptimal solutions. Much effort has been made over the years by experts in identifying different types of cognitive biases. not all those biases are important in the context of designing software. We have identified and documented thirty-three biases that in our opinion influence architects more commonly. - Furthermore, in this paper, we make the implicit decision-making process explicit by using semi-formal models that consists of a series of steps specifying the course of actions taken to reach a decision. The decision-making steps are mapped to the Observe, Orient, Decide, and Act **(OODA) loop, which is a four-phase decision cycle used by strategists in many other domains including business, litigation, and military strategy**. Three decision-making models (DMMs) along with their relationships to the [[OODA loop]] are presented in Section II which correlates them in a systematic manner. - The contribution of this paper is twofold. First, we establish a relationship between the DMMs and the OODA loop. Second, we map the cognitive biases to the OODA loop phases. This is to present the combination of three concepts (DMMs, OODA loop, and cognitive biases) in a way that can be easily comprehended by architects. By consolidating and making the aforementioned information available to architects, they will be able to: - The contribution of this paper is twofold. First, we establish a relationship between the DMMs and the OODA loop. Second, we map the cognitive biases to the OODA loop phases. This is to present the combination of three concepts (DMMs, OODA loop, and cognitive biases) in a way that can be easily comprehended by architects. By consolidating and making the aforementioned information available to architects, they will be able to (a) relate their decision-making processes to a generic process such as the OODA loop and (b) evade the common cognitive limitation pitfalls by being aware of the typical biases documented in the catalog. **In essence, the cognitive bias catalog helps architects in debiasing through self-awareness and encourages them to reason about their ADDs. Our claim indeed goes with the assumption that if a person is aware of the situation where things could go wrong (anti-patterns), he or she would put an extra effort to avoid it.** - Section 2 (OODA LOOP AND DECISION-MAKING MODELS): - The concept of [[OODA loop]] [7] developed by [[@John Boyd]] is a generic decision-making process model. It describes how to gain competitive advantage in any situation. ==**Within the OODA Loop, an actor makes __observations __about the surrounding environment, __orients __his/her thinking process by perceiving the important information based on the context, __decides __on a course of action, and finally __acts __on it**==. As shown in Figure 1, this process is iterative with loops providing feedback to the observe phase for constant reorientation and adaption.  - ==**Designing software architectures involve making strategic decisions keeping in mind various factors such as long-term sustainability, technical capabilities of the teams, complexity, and time constraints**==. In the next subsection, we present how DMMs can be used in conjunction with the [[OODA loop]] when making ADDs. These ADDs, for instance, could include the selection of architectural styles, design patterns, implementa- tion technologies, and software components. - There exist two main approaches to decision-making, namely __normative __and __behavioral __[9]. The DMMs belonging to the normative stream are based on sound logical reasoning. They are mostly applicable in an ideal-world scenario wherein a perfect requirements document with no future changes is available, alongside with other resources such as time, budget, and team dynamics are also available. The examples for normative approaches include the __Rational Economic model __(REM), the Brunswick’s Lens model (BLM), and the Cynefin framework. The BLM is statistical in nature and requires an optimal decision to begin the process and to compare it against the actual decision. On the other hand, even though the Cynefin framework is useful for executives and policy- makers, it is hard to break it down into simple steps so as to map it with the OODA loop. However, due to the clarity of the decision-making steps in the REM, it is investigated further. - __Rational Economic Model (REM)__:  As shown in Figure 2, in the REM, an architect meticulously defines the concerns in the __observe __phase and creates a list of __all __possible alternatives that can be used to address the concerns in the __orient __phase. In the __decide __phase, a ranking algorithm is used to choose an “optimal” alternative which is then implemented in the __act __phase. The implementation is then tested and constant feedback is sent to the observe phase for future decision making. While the REM works well in ideal situations, it is difficult for architects to use it since they work under various real-life constraints such as time, complexity, and permanently changing budget constraints. - The DMMs representing the behavioral approach are subject to cognitive biases and better reflect real-world scenarios. Both BRM and RPDM are models thats follow the behavioral approach. - __Recognition-Primed Decision Model (RPDM)__: -  - The RPDM is derived from the naturalistic decision-making framework that relies on mental mind maps. **It is generally used by inexperienced architects or in scenarios where ADDs are to be made under time pressure and other constraints which affect the decision-making quality**. As shown in Figure 3, architects gather information in the __observe __phase to define concerns until they feel it is complete. In the __orient __phase, the situation is verified for familiarity and to check if any expectations are violated so as to determine if more information is needed. In the __decide __phase, a mental simulation of each alternative is made to verify if it works. The alternative that fits the situation is selected and is implemented in the __act __phase. Here, the aim of an architect is to find a “good-enough” alternative that meets an acceptability threshold. - __Bounded Rational Model (BRM):__ -  - On the other hand, we also observe architects making an effort in creating a subset of alternatives to __orient __themselves with the design concerns captured in the __observe __phase. Then, using heuristics such as “previous experience” and “team capabilities”, architects choose a “satisficing” alternative in the __decide __phase. This corresponds to the BRM introduced by Herbert Simon [11]. The steps in this process model are shown in Figure 4. The BRM is similar to the REM but differs from it as an architect collects only a manageable subset of alternatives, ranks the alternatives using heuristics, and chooses a satisficing alternative without using any optimization algorithm, which may or may not be the optimal one - Section 3 (Cognitive Biases): - Biases are classified into hierarchy groups, firstly by OODA phase and then by a sub-category.  - Observe: - Within the observe phase, since architects focus on how to gather information and how to present them in the subsequent phase, biases can be classified into two main subcategories, namely, __information gathering biases __and __information pre- sentation biases__. - Orient: - The orient phase consists of biases which influence how people interpret the information and orient themselves to the situation at hand. During this process, architects orient them- selves by filtering available information and are influenced by the similarity of the situation, their previous experiences, and current trends. - Decide: - Since the actual decision-making happens in the decide phase, this phase is associated with largest number of biases. The decisions are made based on the __complexity __of the problem, nature of how the solution will be invented (__trends__), __previous experience__, and __decision-making strategies__. - Act: - Corresponding to the act phase, since only two related biases, namely, misinformation effect and post-purchase rationalization were identified, we did not sub-classify these biases. - Section 4 (Using the Research Artifacts) - First, architects should gain an understanding of the OODA loop and how it is related to their decision-making process. Next, they should explore the three different DMMs and understand the relationships between the OODA loop and the DMMs. Following this, architects can move on to the cognitive bias catalog. To get an initial idea, it is recommended to familiarize with the bias listing and the classifications. **During the actual decision-making, once architects identify the phase of the OODA loop they are in, they can read in-depth about biases related to the corresponding phase so as to reduce or eliminate the impact of the biases.** - Section 5 (Conclusion and Future Work) - The usage of the catalog brings the [[Availability Heuristic (Bias)]] into play by ensuring greater availability of biases in the minds of architects. They can then tend to seek evidence of these biases in real-life decision-making scenarios through the [[Confirmation Bias]]. ==**Even though awareness of biases establishes the first point for debiasing, awareness alone is __not __sufficient. The best one can expect is a discussion on cognitive biases and as described in the bias catalog some (limited) actions that architects could take to avoid those biases.**== - Further research is required to provide substantial tool support to help architects debias during their decision making. ## References - [Cognitive Biases Catalog web app](https://tum-master-thesis.herokuapp.com) accompanying this research - contains definitions of the 33 biases used in this thesis - [List of Cognitive Biases - Wikipedia](en.wikipedia.org/wiki/List_of_cognitive_biases) - A. Tang, “Software designers, are you biased?” in __Proc. 6th Int. Workshop on SHARK__. ACM, 2011, pp. 1–8. - A. Zalewski, K. Borowa, and A. Ratkowski, “On cognitive biases in architecture decision making,” in __ECSA__. Springer, 2017, pp. 123–137. - W. Stacy and J. MacMillan, “Cognitive bias in software engineering,” __Communications of the ACM__, vol. 38, no. 6, pp. 57–63, 1995. - G. Hammond, __The mind of war: [[@John Boyd]] and American security__. Smithsonian Institution, 2012. - My [[published]] [[Daily emailing practice]] on this: https://serverlessfirst.com/debiasing-software-architecture-decisions/ --- tags: [[Software Architecture]], [[Software engineering MOC]], [[Cognitive Bias]], [[Decision-making]], [[Strategy]], [[Bias]], [[Architectural Decision-making]], #ArticleReview