Fairness-First Design Thinking for Software Architecture Iffat Fatima
Markus Funke
Patricia Lago
Vrije Universiteit Amsterdam Amsterdam, The Netherlands [email protected]
Vrije Universiteit Amsterdam Amsterdam, The Netherlands [email protected]
Vrije Universiteit Amsterdam Amsterdam, The Netherlands [email protected]
arXiv:2604.18055v1 [cs.SE] 20 Apr 2026
Abstract Fairness issues often remain hidden in digital systems, making them difficult to detect and even more difficult to address. In this study, we introduce a fairness-first Design Thinking (DT) approach to support addressing fairness concerns in software architecture (SA) design. We implemented our approach in a graduate-level course where students executed all steps of our DT approach as part of an assignment. We analyzed the assignment data to reflect on the implications for applying the DT approach in SA and teaching the DT approach in SA education. As a result of this study, we provide (i) a DT approach for SA, (ii) implications of the DT approach on handling fairness in both problem and solution spaces, and (iii) implications for education. Our reflections highlight that fairness theory and context identification are essential for a holistic, fairnessfirst design. We propose the use of composite views to address cross-cutting concerns such as fairness. In the future, we will update the course material to provide end-to-end fairness traceability in SA, helping students to understand how fairness concerns can be translated into actionable design decisions.
Keywords Fairness, fair digital design, fairness perspective, design thinking, software architecture, software design
1
Introduction
Digitalization has reshaped the way that fairness issues manifest in a digital society. The root causes of these issues are often hidden by the complexity and opacity of digital systems [1]. As a result, we see an increase in the prominence of fairness concerns in different sectors, where technology not only overlooks existing issues but can also reinforce them [26]. Such an amplification of unfairness can lead to negative systemic impacts in society at large. For example, in healthcare, diagnostic systems have been shown to exhibit racial bias, leading to disparities in health outcomes that lead to long-term allocation of unequal health benefits [37]. In the financial sector, credit scoring algorithms have been shown to embed historical biases that disproportionately affect people in marginalized communities [26]. In the criminal justice sector, predictive algorithms have been criticized for perpetuating overpolicing in communities of color or with a migration background [29]. In the employment sector, recruiting algorithms trained on historical recruitment data have been found to reinforce gender imbalance and
This work is licensed under a Creative Commons Attribution-NonCommercialNoDerivatives 4.0 International License. , © 2026 Copyright held by the owner/author(s).
racial inequalities in the workforce [30]. Content recommendation systems optimized for engagement have been criticized for leading to situations in which vulnerable users are exposed to content that contradicts their intent and negatively affects their well-being [21]. Furthermore, the unchecked development and use of AI systems raise broader ethical questions related to privacy, transparency, environmental sustainability, and many more. These examples are only a glimpse of the broader challenges of fairness in digitalized sectors. Although legal frameworks such as the AI Act and GDPR provide accountability mechanisms for digital systems, it is equally crucial to embed fairness as a foundational principle in software design [15] [3]. Proactive alignment of digital systems with the fairness needs of society would ensure that fairness is not treated merely as a regulatory requirement but as a fairness-first commitment integrated into the software design process. Research shows that fairness-first design thinking (DT) is necessary to reduce the fairness debt in digital systems, which may have long-range effects [15]. Once the software is implemented and operationalized, the changes required to solve the fairness issues go beyond the technical aspects of the software to the social, governance, and legal domains [15], adding further complications. The issues mentioned above create the need for processes to support a fairness-first DT to address fairness issues during software design. As a first step in this direction, we introduce a DT approach for fairness-first DT in software architecture (SA). We applied our DT approach in an educational setting where graduate-level students used it to explore fairness issues and formulate solutions as part of a course assignment. The study presents the DT approach, the results of its application, and our reflections on SA and education.
2
Background
This section provides some background on fairness, DT, and the role of fairness in the design of digital systems.
2.1
Fairness in the Theory of Philosophy
Fairness is a fundamental concept in philosophy, social justice, and ethics that has evolved throughout history. The early mentions of fairness emerge from the distributive justice concepts of Aristotle, where all individuals are treated proportionally according to their merit or need, rather than strictly equally [4]. Later theoretical developments expanded the theory of fairness into multiple dimensions. Rawls [42] formalized distributive justice as a principle to allocate resources fairly across society, while procedural justice theorists such as Leventhal [35] emphasized fairness in the processes used for decision making and resource allocation. Bies and Moag [6] introduced interactional fairness, focusing on the quality of interpersonal treatment. Greenberg [22] later extended this to informational fairness, highlighting the role of transparency
,,
I. Fatima, M. Funke, P. Lago
and explanation in fairness judgments. Retributive fairness, on the other hand, concerns the fairness of punishments and corrective actions [8]. Together, these frameworks offer a comprehensive lens for evaluating fairness in outcomes, processes, communication, and interpersonal dynamics, especially relevant to the design of sociotechnical systems. These theories suggest that fairness means treating people without favoritism or prejudice, but it can also involve differentiating treatment based on important factors such as need, effort, or merit to ensure outcomes that are just and balanced. Hence, context is extremely important in the application of fairness principles.
2.2
Design Thinking: Origins and Ethics Dimension
The concept of DT first appeared in 1969 by Herbert Simon [48]. DT is a methodology to create solutions with a human-centered approach [40]. Its interdisciplinary character makes it suitable for answering complex ‘wicked problems’ such as ethics and fairness [32]. Ethics is a core component of human-centered design because it involves engaging with people, especially the intended users or beneficiaries [49]. Hence, their moral values and experiences must be taken into account during the design process. DT emphasizes understanding stakeholder concerns, their context, redefining problems, and creating innovative solutions that fulfill stakeholder needs. It has five stages [23]: (i) emphathize, i.e., to understand the needs of people in the context of the design challenge, (ii) define, i.e., capturing the design problem, (iii) ideate, i.e., to synthesize ideas that help solve the problem, (iv) prototype i.e., an artifact that showing a solution, and (v) test, i.e., to ensure the prototype serves the intended purpose of solving the problem.
2.3
Fairness in Digital Systems
In digital systems, fairness is mostly studied for algorithmic decisionmaking. Researchers have developed fairness metrics to formally assess and compare fairness in digital systems. Common metrics include (i) group fairness metrics, which assess whether different demographic groups are treated equally, and (ii) individual fairness metrics, which assess whether similar individuals receive similar outcomes [16]. These fairness metrics are sometimes conflicting and may not be suitable for all contexts [31]. As digital systems become more integrated into decision making, the choice and interpretation of fairness metrics become increasingly critical [12].
2.4
Fairness from a Software Architecture Lens
In this section, we give an overview of concepts from SA theory and literature that help build the foundations of our study. Software architecture is defined as a set of design decisions [28]. These decisions are often represented as architectural diagrams (or design views), where each view represents a certain architectural aspect. In SA, viewpoints serve as a structured template or modeling conventions to represent stakeholder concerns and associated guidelines for a particular kind of architectural representation. A design view is a concrete realization of the viewpoint as a model or diagram that illustrates a certain architectural aspect through the lens established by the viewpoint [43]. These design views help capture architecturally significant quality concerns.
Similar to sustainability [34], fairness can be seen as an architectural quality concern [51] which is (i) multidimensional [14] encompassing both social and technical aspects and (ii) cross-cutting [43] affecting multiple architectural elements and design views. To explore these multidimensional and cross-cutting concerns, such as fairness, the Sustainability Assessment Framework Toolkit (SAF) [33] offers a set of thinking tools. For instance, Decision Maps (DMaps) are a graphical representation of the system features and their associated quality concerns across different dimensions (economic, environmental, social, and technical). DMaps help illustrate the effects (positive or negative) of quality concerns on each other and their direct, enabling, or systemic impacts over time. The Sustainability Quality Model (SQModel) helps define quality concerns and their sub-characteristics, per dimension. It also helps to define their measurement metrics, which can be used to define Key Performance Indicators (KPIs). These KPIs can help formalize the measurement process, making it actionable by linking high-level goals to concrete measurements and actionable tactics. As fairness is often represented as a collection of quality concerns (e.g., transparency, accessibility, bias, etc.), its cross-cutting nature can be represented by using an architecture perspective [43] which is designed to facilitate representing cross-cutting quality concerns.
3
Design Thinking Approach
DT refers to a human-centered problem-solving approach that emphasizes understanding stakeholder concerns, their context, redefining problems, and creating innovative solutions that fulfill stakeholder needs. Our DT approach aims to facilitate the identification of fairness issues and to find actionable and measurable solutions to integrate fairness in SA design. Hence, we divide our DT approach into a problem space and a solution space. Figure 1 shows an overview of our DT approach. Problem Space. Exploring the problem space involves identifying the problem of fairness and reasoning about fairness in terms of associated quality concerns. The steps are as follows. Step 1 – It involves the identification of a real-world use case on fairness issues in a digital system, its stakeholders, and the context. Step 2 – It involves the exploration of the problem space using a DMap and the SQModel from the SAF Toolkit [33]. The DMap helps translate the system into relevant features, quality concerns, their effects on each other, their impacts over time, and sustainability dimensions. These effects help identify trade-offs between different quality concerns. Next, the SQ Model elaborates on the identified quality concerns by defining them in the context of the use case and as per sustainability dimensions. The final SQ Model provides an overview of fairness as a sustainability quality concern, represented by a collection of quality attributes (QAs). Solution Space. Exploring the solution space involves representing fairness using a fairness perspective, applied through a design view. The next steps are as follows. Step 3 – It involves the creation of a fairness perspective. To capture a set of elements satisfying a particular fairness concern, the fairness perspective is adapted from the Sustainability Perspective by Funke and Lago [19], which is rooted in the general concept of architectural perspectives [43]. Our fairness perspective consists of the following elements: (i) Desired quality which defines fairness
Fairness-First Design Thinking for Software Architecture
,,
Figure 1: Overview of the DT Approach as a quality of the system under consideration, (ii) Quality concerns which are scoped to the fairness definition, (iii) Architectural tactics which, if implemented, would lead to achievement of the desired quality, (iv) Fairness Indicator which is a KPI that can be used to measure and monitor the level of fairness in the system, and (v) Problems and Pitfalls which are the issues which may hinder the achievement of the fairness. Step 3.1 – Architectural tactics from the fairness perspective are documented using the template from the Awesome and Dark Tactics (AADT) archive1 . Step 3.2 – KPIs from the fairness perspective are documented using the KPI template [17]. Quality concerns from the fairness perspective and metrics identified as part of the SQ model help to build a KPI that meets the fairness goal for the desired quality in the fairness perspective. Step 4 – Finally, a fairness-based design solution is illustrated by using a design view, i.e., an architecture diagram. Our DT steps align with the five stages of DT [23]. Steps 1 and 2 help elicit human-centered fairness concerns (empathize), Step 3 refines them into a sustainability perspective (define), Step 3.1 explores architectural tactics and options (ideate), Step 3.2 proposes measurable criteria to monitor (and test) the interventions represented by Step 4 as design views that operationalize fairness (prototype). Due to the limited duration of the course, the design is not tested via the implementation of the prototype.
4
Study Design and Execution
The study was carried out as part of a graduate-level Fair Digital Design that spanned a period of seven weeks, where the student attended a lecture and a working session per week. A total of 26 students took the course. The students worked in pairs on the Design for Fairness (D4F) assignment. The DT approach was executed as part of this assignment. Each group explored a fairness issue in the 1 https://s2group.cs.vu.nl/AwesomeAndDarkTactics
domain of cloud/edge data management. The students were free to choose a fairness issue of their choice. As a final output, they were expected to present the solution as a fairness perspective and design views. Our study focused on the design and reflections of the DT approach, applied as part of the D4F assignment. During this course, we introduced our DT approach and operationalized learning through a structured assignment. One lecture was dedicated to teaching the DT approach and the relevant techniques to be used in the assignment. During the working sessions, a facilitator guided students on the techniques taught in the lecture and how to use them for the assignment. The students also received feedback on their progress during these sessions. The graded assignments with corrections were used as a source for data extraction and analysis. We applied the following inclusion criteria to ensure the quality of the data under analysis: (i) Data used for this study is extracted from assignments with a grade ≥ 60%. (ii) Data used for this study is referenced using the peer-reviewed literature. We selected all 13 assignments as they met the inclusion criteria. Data extraction was performed for each step of the DT approach. We provide an online replication package [18] containing templates for each DT step and the extracted data, including only assignments with students’ consent (i.e., all except A12). Step I - Use case: We used open coding [50] for data extraction. This resulted in 11 elements of the use case description (see Table 1). The data from the use cases was extracted into these categories. Further, we categorized fairness issues based on the type of fairness issue described in the use case problem descriptions. This categorization was based on the fairness definitions from philosophy theory, described in the following.
,,
I. Fatima, M. Funke, P. Lago
Distributive Fairness – Resources, benefits, and burdens should be allocated among individuals or groups based on fair and just criteria such as equity, equality, or need. These allocations should be made to ensure fairness in outcomes, focusing on transparent, consistent, and just distribution principles that stakeholders recognize as legitimate [11]. Procedural Fairness – Decision-making processes should be built and applied consistently, transparently, and without bias. It must be ensured that all affected parties have a voice, that rules are followed, and explanations are provided to ensure fairness in the process [35]. Interactional Fairness – Individuals should be treated with dignity, respect, and honesty during interactions, with clear, truthful, and timely communication that reflects consideration of their concerns [6].
These definitions were matched with the descriptions of use cases and the fairness problems. The categorization was carried out independently by two co-authors and later compared to resolve differences and finalized after mutual consensus. Table 1: Use Case Template Element
Description
Domain
Describes the general area where the system operates (e.g., healthcare, education, etc.) Stakeholder(s) of the system who interact with it or are affected by it An identifiable name of the system A brief overview of the system’s domain, prominent features in the context of the use case, and its intended purpose Specific tasks performed by the system/actors Challenges that the actors face due to the system operating in a certain way Challenges that the system faces to operate in a certain way The technical component where fairness is at risk The impact of the design choices on the actors in terms of fairness The impact of the design choices on the system in terms of fairness The solution to address fairness issues in the system at the architectural level
Actor(s) System name System description
Use case focus Problem in the context of the actor Problem in the context of the system Technical subject of fairness issue Impact of the design issue on the actor Impact of the design issue on the system Proposed solution
Step 2 - Decision Map and Sustainability Quality Model: We employed a priori coding [7] for data extraction, as this step required the use of templates from the SAF Toolkit, which has predefined elements that we used as categories for data extraction. Once the data was coded, we performed further categorization using open coding to gather insights about possible patterns. Each SQ model contained a subset of quality concerns from the Decision Map, defined according to the mapped sustainability dimension. To identify QA trade-offs and synergies, we used this common subset of QAs and observed the effects in the DMaps as positive, negative, or neutral over time as immediate, enabling, or systemic impacts. The SQ Models helped define QAs in a certain sustainability dimension. We extracted data from the SQ Models and grouped it by dimensions. In each dimension, we categorized the QAs into different QA
categories. For the technical dimension, we use the ISO/IEC 25010 standard2 . For other dimensions, we performed deductive coding to identify categories, as no standard is currently in place. Step 3 – Fairness Perspective: We employed a priori coding [7] for data extraction. This choice was made because this step required the use of templates from different frameworks(such as the Sustainability Perspective, AADT Template, and KPI Template), all of which have predefined data categories for data extraction. The fairness perspective defines fairness as a desired quality. We analyzed these definitions in combination with tactics and KPIs to observe similarities and differences, specifically for similar domains. We also compared the implications of the definitions with the types of fairness assigned to the use cases. This was to observe any changes in perception of fairness as we transition from the problem to the solution space. We extracted all tactics from the fairness perspectives and mapped them across fairness types based on tactic intent. This served as a guide to indicate the type of fairness the tactic supports, i.e., distributive, procedural, or interactional. The KPIs from the fairness perspective were elaborated using the KPI framework, which outlines the goal, the critical success factor, the KPI with its goals and actions (if the target is not achieved), the metrics, and their corresponding measures. We analyzed the data in these categories to see similarities, patterns, and insights to enable fairness in different contexts and for different fairness goals. Step 4 – Design View: We used directed content analysis [25] by starting with the codes from the work of Migliorini et al. [36] followed by developing additional categories inductively from the data to capture concepts not addressed in the previous framework. We also looked at the elements of the views and analyzed them in light of the problem context, the provided solution, and the fairness types. Using these sources of information, we determined which elements support a specific type of fairness need. We also identified new elements from the view data and provided some recommendations in the reflections. The choice of inductive coding for steps 1 and 4 (part) was because the students were given creative liberty to elicit these steps, hence, information was documented in different formats. The choice of inductive coding was motivated by the aim of finding practical and novel ways to represent fairness issues and their solutions.
5
Results
Our results show that the students focused on use cases specifically in the domains of healthcare (A02, A06, A10, and A12), education (A08 and A11), disaster management (A01), agriculture (A04), entertainment (A05), finance (A09), and hospitality (A13). Two use cases are domain-independent and target cloud software in general (A03 and A07). Table 2 shows an example use case represented using the use case template created during the data extraction process. The details of the other use cases are available in our replication package [18]. In the following, we present each finding from our results with a concise statement summarizing the primary data pattern, followed by a detailed explanation, and a concluding takeaway. Distributive fairness issues dominate in problem descriptions; procedural and interactional issues are less frequent. 2 https://www.iso25000.com/index.php/en/iso-25000-standards/iso-25010
Fairness-First Design Thinking for Software Architecture
Table 2: Example: Step 1 – Usecase (A08) Element Domain Actor(s) System name System description
Use case focus Problem(s) in the context of the actor
Problem(s) in context of the system Technical subject of fairness issue Impact of the design issue on the Actor Impact of the design issue on system Proposed solution
Description Education High school student in a remote location in a country in the Global South Online education platform The educational platform is hosted on a global cloud infrastructure with an edge network, offering online classes for high-school students. It offers digital resources, on-demand and real-time online classes, and an assessment component, offering self-paced and real-time proctored tests. Uninterrupted real-time online classes Uninterrupted virtual tests Network fluctuations cause delays, video lag, and disconnections, disrupting student exams, not because of their ability, but because of poor connectivity. Network issues lead to session interruptions, significantly impacting students’ learning experience and progress. Poor connectivity impacts real-time data transfer in the education platform Data management over unreliable networks
,,
The lack of a sustainability-aware scheduling mechanism is a procedural issue, whereas for the developers, this is an interactional fairness issue, as it hinders them from making informed decisions based on transparency. In summary, in our data, the issues of distributive fairness focus on unequal access to resources based on geographical differences or varying data storage policy decisions. The issues of procedural fairness focus on the lack of control or transparency about the process through which the software operates and handles data, sometimes leading to disparities and unfair outcomes. The issues of interactional fairness focus on the lack of explainability of the decision-making process, the lack of transparent/poor communication with users, harming user trust, and the usability experience. Takeaway – Distributive fairness issues appeared more frequently, possibly because they are based on outcomes and manifest outside the system, making them more noticeable to the students. To support the identification of different types of issues in future editions of the course, we aim to provide an overview of fairness types and their possible manifestations in digital systems.
Student’s learning experience and progress. Not provided The architecture will address network issues and aim at counter-balancing the disadvantage caused by socioeconomic circumstances, with features designed to ensure fair access.
The classification of fairness issues in terms of fairness types shows a mix of disjoint and overlapping cases (see Figure 2). In particular, we observe that most issues are described as distributive fairness issues (in A01, A02, A03, A04, A06, A08, A09, A10, A12, A13), six as procedural (in A05, A07, A09, A11, A12), and three ( in A03, A09, A11) as interactional (see Table 3 for issue descriptions). Only one issue (in A12, a healthcare diagnostic system) is classified as both distributive and procedural because the design of the diagnostic algorithm and the choice of training data are procedural issues in the context of the system, while the impact of bias leading to unequal treatment is a distributive fairness issue in the context of the user. Similarly, two issues (in A09 and A11) are classified as both procedural and interactional. In A09 (credit scoring system), there is a lack of transparency in the process used for credit scoring. This, coupled with the lack of explainability, makes it both a procedural and an interactional issue. In A11 (education record verification system), there is no procedure in place to access and get information about unavailable diplomas, making it a procedural issue, whereas the lack of information to the user is a communication issue, making it interactional in nature. Only one issue (in A03, an AI job scheduler) is classified across all fairness types. The inability to allocate the burden of scheduling jobs with energy-efficient resources is a distributive fairness issue.
Figure 2: Overlapping use cases per fairness type Technical quality concerns can cause immediate impacts that ripple into systemic social and economic effects over time. DMaps show information on QA trade-offs and synergies that are rooted as direct impacts, but over time lead to enabling and systemic impacts. For example, in the use case A08 (Domain: Education), the implementation of the adaptive resource allocation feature (see associated Figure 3) negatively affects maintainability, as it increases technical complexity and effort. However, when observed over time, this feature contributes positively to adaptability, creating a positive effect on robustness (T)3 as a direct effect. This robustness further enables reliability (T) and fosters trust (S), over time. Establishing trust (S), in turn, can have a systemic effect in promoting educational equity (S). In the use case A074 (Domain: Cloud Software – AWS), data sovereignty (T) is positively reinforced as an immediate impact of GDPR compliance. This, in turn, has a positive enabling effect on regulatory compliance (S), which leads to a positive systemic impact on third-party compliance (Ec). This illustrates how a technical 3 (T): Technical, (En): Environmental, (Ec): Economic, (S): Social 4 See Replication Package [18] for DMap
,,
I. Fatima, M. Funke, P. Lago
Table 3: Fairness Issues mapped on Fairness Types ID Issue Description D P I A01 Marginalized communities have limited access to disaster ● response tools, leading to unequal protection. A02 AI predictions seem less accurate for patients from minority ● groups due to imbalanced data. A03 ML engineers have no control/information over ● ● ● sustainability-aware job scheduling, indicating a lack of voice and transparency. A04 Lack of real-time availability of decision-making informa- ● tion in rural areas A05 Users cannot transfer data between music providers ● A06 Patients from rural areas have trouble connecting to the ● system, hindering remote patient health monitoring. A07 Privacy and legal protections under GDPR are difficult to ● apply equally across regions. A08 AI-driven education systems are less accessible to under- ● resourced learners, widening the learning gap. A09 Credit reductions are made by opaque algorithms without ● ● user input or an appeal channel. A10 Inefficient cloud resource allocation causes long patient ● waiting times in healthcare. A11 Diploma access processes are unclear, reducing perceptions ● ● of fairness. A12 Biased diagnostic algorithms result in unequal patient treat- ● ● ment. A13 AI support distribution is uneven between urban and rural ● areas. Fairness Types; D: Distributive, P: Procedural, I: Interactional
intervention can produce long-term effects in the social and economic dimensions of sustainability, contributing to fairness over time through systemic influence. Since the positive systemic impact lies within the economic dimension, it creates a strategic incentive for businesses to adopt fair data management policies. Takeaway – Technical interventions can drive long-term social and economic fairness, providing strategic incentives for businesses to adopt fair practices. A fairness-first DT approach may enable integrating interventions for social quality concerns early at design time.
The classification of data from the SQ Model shows that out of 148 QAs, 46.6% (69) QAs were classified as technical, 6.8% (10) as environmental, 12.8% (19) as economic, and 33.8% (50) as social. The SQ Model also contains metrics that can be used to quantify some QAs. Although our study is specific to fairness, some of the provided metrics are agnostic of the general goal of measurement and, therefore, can be reused for quality monitoring in other contexts. The information from the SQ Models is later used in defining the fairness perspective. Both QA definitions, their mapping on dimensions, and metrics can be found in the replication package [18]. Fairness definitions vary within similar domains and in granularity levels. We observed certain conflicts in how fairness is defined in different fairness perspectives. For example, A07 emphasizes strong privacy protection in order to adhere to the principles of data sovereignty and compliance with GDPR. In contrast, A08 stresses the sharing
Figure 3: Example: Step 2 – DMap (A08)
of resources for equitable access to educational resources, which may cross continental boundaries and cause data sovereignty and privacy issues. We also see differences in the definition of desired quality within a domain. An analysis of healthcare use cases (A02, A06, A10, A12) shows that fairness concerns in this context are multifaceted and often intersect across the categories of distributive and procedural fairness. A02, initially categorized as distributive, emphasizes fairness in data-driven decision making, particularly through transparency, explainability, and equitable treatment across demographics. This reinforces its alignment with interactional fairness while also addressing distributive concerns through accessibility. A06, with its comprehensive focus on representation management, data quality, connectivity, and compliance across locations, bridges distributive fairness (equal access and representation) and procedural fairness (mechanisms ensuring fairness in data handling and system operations). A10, concerned with equitable access to data resources, performance metrics, and adherence to international standards, reflects both distributive fairness (resource access) and procedural fairness (standardized measurement and compliance frameworks). Collectively, these cases underscore that fairness must be understood both as a system outcome and as the mechanisms by which such outcomes are produced. Our results show that fairness definitions vary in granularity from a very high level (fair and sustainable data management in A01) to very specific (secure music data porting in A05). Although quality concerns are identified as economic in ten SQ Models, we still see a scarcity of a fairness perspective that includes economic aspects, except for A01 and A10. These two fairness perspectives include regulatory compliance and cost efficiency. Takeaway – The definition of fairness is driven by context and stakeholder needs. What counts as fair in one system under certain constraints may not be considered fair for another. These trade-offs in digital systems should be understood both in terms of system outcomes and processes that produce them.
Fairness-First Design Thinking for Software Architecture
,,
Architectural tactics serve as procedural fairness-based interventions. Our results show that all tactics fall under procedural fairness because the intrinsic nature of tactics being procedural interventions. Four tactics fall under both procedural and interactional categories, depending on whether the solution is system-facing or user-facing. For example, regulatory environments (e.g., EU AI Act, GDPR) increasingly demand justification and transparency. For architects to know how explainability serves different fairness roles would help in meeting such requirements strategically through procedural fairness-based interventions. Although some fairness problems were framed as distributive (such as A01 and A10), the fairness intent in the architectural tactics used to solve them now includes some procedural elements. Interactional fairness was the least addressed by architectural tactics. Table 4 shows all tactics categorized according to the three types of fairness. Takeaway – Overall, we positively noted that although not all fairness types were part of the problem space, as the solution space evolved, we saw a diversity of fairness types being addressed through the fairnessfirst DT approach by the use of tactics.
Table 4: Architectural Tactics Mapped to Fairness Types Architectural Tactic (Use case ID) Smart Data Tiering (A01) Adaptive Resource Allocation (A01, A08, A13) Green Computing Strategies (A01) Explainable AI (A01, A02, A09) Regulated Storage Access (A01) Realtime Bias Detection (A02, A12) Adaptive Learning Mechanisms (A02) Carbon footprint aware scheduling (A03) Data center selection using adaptive desirability functions (A03) Runtime process migration to suitable data centers (A03) Monitor environment of individual jobs (A03) Local Data Processing via Edge Computing (A04) IoT Sensor Network for Real-Time Data Collection (A04) Distributed Edge Devices (A04) Blockchain for Transparency (A04) Standardized data portability between platforms (A05) Adaptive Edge Processing Prioritization (A06) Data Access Control for GDPR (A07) Prioritized Traffic Management (A08) Edge Caching (A08) Provenance-Driven Transparency (A09) Tiered Storage (A10) Energy-aware Scheduling (A10) Compress infrequently accessed data (A10) Continuous monitoring & mitigation of AI bias (A12) Cloud-based retraining with diverse datasets (A12)
D P I ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
Fairness Types; D: Distributive, P: Procedural, I: Interactional
KPIs help turn fairness goals into measurable outcomes. Architectural tactics contribute to making fairness actionable in SA design, however, it is important to monitor the impact of these interventions over time. Our DT framework assists in creating KPIs for fairness monitoring.
Analysis of KPI data shows that some measurements are performed by collecting data from the digital system, hence classified as internal. For others, measurements are performed by collecting data from users, therefore, categorized external. Some KPIs use a mix of internal and external measures and are therefore classified as hybrid. Six KPIs were classified as internal (A03, A12, A01, A06, A10, and A13), while others were classified as hybrid (A02, A07, A11, A05, A09, A04 and A08). Among the KPIs, we observe two distinct approaches to setting targets (i) single value targets and (ii) conjunctive targets. In the first approach, various underlying metrics are aggregated into a single numerical value using a mathematical function. This simplifies monitoring and decision-making at the macro level, offering a unified view of performance. However, such aggregation can obscure the contribution of individual metrics, making it difficult to understand why a particular KPI value was achieved. In contrast, the conjunctive approach treats each metric separately with its own threshold. Instead of single-valued functions, these KPIs use logical functions. A KPI is considered successful only if all KPI metrics meet their respective thresholds. This approach improves transparency and provides detailed information, allowing targeted interventions through KPI actions. However, this approach can compromise the benefits of simplification and abstraction that single-value KPIs provide, potentially making high-level comparisons and reporting more complex. Takeaway – The choice between single-value vs. conjunctive KPIs involves a trade-off between clarity for strategic decision-making and granularity for operational insight. The ultimate choice lies in the monitoring goal.
We observed that some KPI targets were based on architectural tactics from a fairness perspective. This shows that architectural interventions can facilitate the achievement of fairness goals, can be monitored over time, and are well-handled early in the software development lifecycle. For example, in A01, actions to improve the fairness index included tactics such as implementing smart caching mechanisms to optimize data retrieval speed and resource allocation adjustments to dynamically balance workloads. Other tactics as actions include adaptive resource allocation and processing on the edge, and load balancing. The KPI for A08 measures the continuity of the session, with the target of maintaining continuity above 95%. This requires defining a performance requirement for sustained access under varying loads. Meeting this requires the use of adaptive resource allocation, which guides architectural tactics such as autoscaling and real-time monitoring. This chain from KPI to the design tactic illustrates how high-level goals can be operationalized within the system architecture and monitored over time. Takeaway – KPIs act as a bridge between fairness ideals and system design, translating fairness into measurable metrics without losing its ethical purpose.
Contextual design view elements help embed fairness in SA. Our results show that some design views follow notations from standards like ArchiMate5 and UML6 , while others use a mix of notations from different architecture viewpoints (such as deployment, 5 https://www.opengroup.org/archimate-forum/archimate-overview 6 https://www.omg.org/uml/
,,
I. Fatima, M. Funke, P. Lago
functional, operational, etc.) and some custom notations specific to the context of the use case. The level of granularity is high for most views (A01, A02, A03, A04, A05, A06, A07), while medium for others (A09, A10, A11, A12, A13). Only one view had a low granularity level and was depicted as an activity diagram using an operational viewpoint for job scheduling. The views focus on representing the interaction of stakeholders with the features and the representation of the fairness issue through two types of interactions, (i) human–technology and (ii) technology–technology. The former included human actors (A05, A09, A13), user (A01), and stakeholders (A07, A08, A12). The latter included components of different systems communicating through interfaces (A01-A13). One design view was textual (A01), while the other 12 were graphical. The views provide an overview of the static and dynamic behavior of the architecture. The views provide an overview of the features and components, their interactions with each other, external systems, and stakeholders. We also observe some elements in the design views that are not standard but rather improvised to represent the context (see Figure 4). For example, the elements of the geographical area (A08, A06) capture distributive fairness by reflecting the environmental and regional factors that influence the equitable allocation of resources. The elements of connection quality and network traffic prioritization (A08) further support distributive fairness by modeling the varying capabilities of the infrastructure and ensuring the priority of the data flow where necessary. The constraint elements for privacy and other regulations (A02, A07) emphasize procedural fairness by embedding compliance mechanisms that ensure that decisions respect established rules and stakeholder rights. The stakeholder influence relationship (A07) highlights interactional fairness, representing the impact of organizational actors and their power dynamics within the system. Finally, representation management and adaptive monitoring (A06) integrate procedural fairness through continuous system assessment and dynamic resource adjustment based on KPI thresholds.
Figure 4: Step 4 – Design View
fulfills it. A08 (see Figure 4) uses boxes (connection stability, geographical location) and lines (prioritized data transmission) to represent contextual information that is key to ensuring fairness. It combines the underlying problem and the proposed solution in a single, self-contained view. The view shows how different edge nodes transmit data with network prioritization for rural regions with poor connectivity. The adaptive system component includes a dynamic computational resource manager, a network traffic scheduler, and adaptive resource allocation to maintain Quality of Service. The visibility of external interactions in specific situations, such as unstable connectivity, strengthens the soundness of the architecture design representation. Takeaway – Representing KPI targets and adaptive actions in design views helps fairness requirements become operational and traceable in SA. This helps strengthen the link between fairness goals and concrete interventions needed to achieve them.
Takeaway – Contextual elements help document the context and rationale behind design decisions within the design views, hence providing a mechanism for architecture knowledge preservation.
Explicit representation of targets and actions in design views makes fairness-driven architecture adaptations traceable. In A02, the activity diagram integrates KPIs directly into the decisionmaking and scheduling logic, and metrics guide the dynamic selection/reassignment of data centers. This integration makes fairness logic, including the prioritization of user preferences and equitable job distribution, explicit within the operational flow and provides a traceable link between QAs and adaptive system behavior. A06 presents a similar contextual connection for connectivity status, proposing a representation monitor to enable adaptive resource allocation. The design view incorporates the KPI for representation management and its thresholds, making explicit when actions should be triggered to maintain fairness once a threshold is breached. This explicit integration of monitoring, thresholds, and adaptive response within the view provides clear traceability from the fairness requirement to the architectural element that
6
Reflections
We present our reflections on the insights about fairness in the context of SA and our fairness-first DT approach for education.
6.1
On Fairness in Software Architecture
Our analysis revealed a consistent pattern where issues framed primarily as distributive fairness problems (in the problem space) were often addressed with procedural fairness–based solutions (in the solution space). For example, several use cases showed that concerns about distributive fairness (e.g., resource allocation) were resolved through procedural interventions across different use cases, including adaptive learning mechanisms (in A02), process transparency (in A04), and through monitoring components (in A08). The DMaps helped us observe possible trade-offs between QAs as we explored the problem space. In addition, they helped to visualize the possible enabling and systemic impacts of technical features over time. Such exploration of the problem space, specifically for multidimensional concerns such as fairness, is essential as it allows
Fairness-First Design Thinking for Software Architecture
for proactive management of overtime cross-dimensional impacts within the design phase instead of addressing them later. We observed that explainability as a quality concern served a dual role. When designed for system-facing use, it enabled auditing and compliance (procedural fairness), while user-facing implementations supported trust and comprehension (interactional fairness). Hence, it is important to define a QA with its different interpretations based on the intent as per the dimension(s) it supports, which is facilitated by the SQ Model in our DT approach. By applying fairness perspectives on design views, we established a clear chain to (i) trace architectural elements to the QA(s) they affect, (ii) the KPIs that measure fairness using these QA metrics, and (iii) the tactics that make these KPIs actionable and help enable the desired level of fairness. Building on this traceability chain, we suggest extending sustainability perspectives (i.e., architectural perspectives) with the element of KPIs. Incorporating KPIs within a perspective enables systematic monitoring of the desired qualities. The KPI definition in the problem space becomes especially helpful for new and unexplored concerns like fairness or sustainability, in general. KPIs at this stage facilitate the collection of relevant data, which in turn enables informed design decision-making and the reconsideration of earlier choices. Over time, as sufficient data is collected, such KPIs can evolve beyond the architecture problem space and inform, e.g., architecture guidelines or patterns with clear targets for future solutions. In the solution space, many design view elements span multiple types of fairness, reflecting the cross-cutting nature of fairness concerns in SA. For example, stakeholders appear in all three types but play different roles, such as resource recipients (distributive), participants in decision processes (procedural), and participants in social interactions (interactional). It is important to consider these fairness types in hindsight when creating design views, while being careful with the intent of each choice. Complex concerns such as fairness require a composite view, as they do not fit neatly into one architecture viewpoint due to their multidimensional nature. Addressing a quality concern for fairness may require the representation of multiple elements (such as data, behavioral, stakeholders, deployment, and others) in a single view. This requires combining viewpoints or their elements, which can be achieved by using composite viewpoints. Composite viewpoints integrate components from various viewpoints, allowing architects to concentrate on concern-specific elements that extend across multiple viewpoints [43]. Hofmeister et al. [24] emphasize that viewpoints should be flexible enough to facilitate composition or extension to address new or evolving concerns, which in our case is fairness. The ISO/IEC/IEEE 42010:2011 standard [27] also allows for creation of ‘custom viewpoints’ to address concerns that are not adequately supported by existing ones. Composite viewpoints can enable one to tackle multiple fairness types in concise views. Considering the multidimensional and cross-cutting nature of fairness as a quality concern, we recommend the use of composite views. Sections 2 and 7 show that context is key to understanding and solving fairness issues, and it is also a key element in the DT process. Therefore, design views for fairness concerns must explicitly incorporate contextual elements. The design views in this study used elements such as geographic location, connectivity status, regulatory constraints, and stakeholder influences. Such contextual
,,
elements are essential to capture the environmental and social conditions that impact fairness-based decisions in the system. Including such contextual information allows architects to visualize the influence of external factors and stakeholder relationships on fairness outcomes. Furthermore, it preserves the rationale for making a decision within the design view. The presented DT approach provides a thinking framework to expand on fairness issues; facilitates understanding them in the context of system features and related concerns; and helps define a fairness perspective to apply fairness-supporting interventions during the design of SA. This helps ensure that fairness is treated as a priority concern and not retrofitted later into the system.
6.2
On Fairness-First Design Thinking in Education
To understand and analyze the problem context, students need an understanding of the theory of fairness. Our results show that even when the initial problem focused on a single type of fairness, using the DT approach, aspects relevant to other fairness types appeared while exploring the solution space. Planning these aspects early can improve the effectiveness of solutions. Our experience showed that the students found it difficult to concisely define the use cases. Our results provide a use case template that facilitates the description of the problem in the context of the stakeholder and in the context of the system. A system designed to produce fair outcomes may still violate some fairness principles that affect the stakeholder(s). In contrast, economic, technical, or legal restrictions can hinder the implementation of a fairness-based design. Addressing both aspects of the issue (if applicable) is important to fully understand the fairness issue and its context. We aim to encourage students to use composite views and viewpoints for the representation of a design solution. We plan to integrate the learning from this research into the course and assignment design.
7
Related Work
This section discusses related work and outlines the research gaps bridged by our DT approach. Design Thinking in Software Engineering Education. The literature highlights the use of DT in teaching mobile application development [13, 20]. DT has also been used for project-based learning, requirement elicitation, software design, and development in a software engineering course [38] and to teach the design of safety-critical software with physical hardware components [10]. These studies collectively demonstrate that DT is a flexible framework, adapted to diverse educational contexts and problem spaces. However, the literature does not explicitly address the application of DT to SA, which is a fundamental phase for the construction of any software [5]. Fairness Considerations in Software Architecture. Shelly et al. [46] question the assumption that technology is inherently neutral, suggesting that design choices can introduce unfairness into systems. This highlights the relevance of identifying fairness concerns during the early stages of design before they become embedded in the software solution.
,,
I. Fatima, M. Funke, P. Lago
Fairness presents socio-technical challenges, requiring a perspective with professionals from both social and technical domains. To this aim, Ryan et al. [44] carried out a study with experts in machine learning and human-computer interaction, revealing that fairness is perceived in various and sometimes contradictory ways. Their work highlights data quality and context definition at design time as key challenges in achieving fairness, emphasizing that the fairness evaluation measurement process must be user-centric. In our study, we present a use case template to capture this context, together with an SQ Model that captures contextual definitions of quality concerns and the metrics to help measure them. Although context is important, the abstraction of the social context while designing sociotechnical systems can also lead to fairness issues. For example, Selbst et al. [45] present four context-centered pitfalls in the design of such systems, some of which we avoid through our DT framework. These include the use of decision maps that help identify ripple effects and leverage the SQ model to avoid the formalism trap by defining quality concerns based on context per dimension (social, economic, environmental, and technical). Elements of software design can also be leveraged as a tool to define fairness concerns early in the life cycle of software development [14]. To support this, card-based games help identify ethical [2] and fairness [52] issues in software design. Although these approaches help identify fairness issues, they do not directly guide the architectural design process. Our DT framework supplements these approaches by embedding fairness considerations through an exploratory SA-focused DT approach. Architectural choices can be used to mitigate bias, for example, by adopting fairness-aware tactics [47] or by introducing design patterns that enable fair algorithmic strategies [51]. To operationalize fairness at design time, our framework incorporates architectural tactics that translate abstract fairness concerns into concrete design choices. Complementing it, we use KPIs, which can help monitor the impact of fairness-supporting tactics. As important as including fairness at design time, it is equally important to measure it in terms of its impacts over time to understand how well the chosen fairness strategies work and change them based on the knowledge acquired over time [9], which is supported by our DT approach.
8
Threats to Validity
In this section, we present possible threats to the validity and related mitigations. Threats are categorized according to the checklist by Peterson et al. [39] for qualitative studies. Construct Validity. In this study, we only considered three foundational fairness types relevant to the use cases and the scope of the study. We do not use the concepts of retributive or informational fairness. The former deals with penalizing people for unethical behavior, e.g., on the moderation of social networks. The latter deals with issues such as information bias. Both fall outside the scope of SA (in data collection or algorithm implementation). Although our focus was on fairness, we used sustainability-specific frameworks in problem and solution spaces. The literature shows that both are multidimensional concepts, where fairness is sometimes studied under the umbrella of sustainability [41]. We only used these frameworks to create a structured step-by-step process.
The content used to initialize the frameworks was independent of the frameworks. Internal Validity. In thematic analysis, data coding and identification patterns are subject to bias. To mitigate this threat, the categorization is performed by multiple authors, and the changes are merged after a discussion process. As the study results are based on assignment data, it might raise questions about data quality. We mitigated this threat by setting an inclusion criterion for data selection. External Validity. Due to a small sample size, the conclusions cannot be generalized for a specific domain or fairness type. However, the study provides a foundation for further research using this approach in larger and more refined data sets, e.g., in the industrial domain. Although the DT approach is used for fairness, it can be extended to similar multidimensional quality concerns, such as sustainability, fairness, and trustworthiness, etc. Reliability. For transparency, we provide data from all three phases in our replication package. All thematic analysis steps, such as coding schemes, categorization, and identification of patterns, were cross-checked by all authors. In case of disagreements, a consensus was reached after discussion.
9
Conclusion and Future Work
In this study, we presented a fairness-first DT approach for SA design, executed in an educational context. Our results show that (i) context is key to solving fairness issues, (ii) multiple fairness types must be considered during problem elaboration, (iii) composite views with contextual elements can aid in preservation of contextual details and decision making logic, (vi) fairness perspective helps define scope of fairness, provides a roadmap for monitoring it via KPIs, and makes it actionable through tactics, (v) design views provide a visualization of end-to-end traceability between fairness quality concerns, architectural elements and operational context. As an outcome of this study, we also provide reusable templates and an education guide enabling adoption of our DT approach, made open source via our replication package. Our results and education guide are valuable for educators seeking to integrate socio-technical concerns into SA education. Future work involves integrating the learnings of this study into the course design, collecting student feedback, and understanding the needs and processes of the industry to find entry points to incorporate fairness-first DT.
Acknowledgments We are grateful to the students of the Fair Digital Design for consenting to the analysis of their assignment data for this research. This publication is part of the project SustainableCloud (OCENW.M20.243) of the research programme Open Competition by the Dutch Research Council (NWO). We acknowledge the use of the AI tool Writeful tool for grammatical improvements in the text of this paper.
References [1] Kyra Milan Abrams. 2025. Digital Redlining: Past and Present Motivations. In Advances in Information and Communication. Springer Nature Switzerland, Cham, 32–43. [2] Razieh Alidoosti, Patricia Lago, Eltjo Poort, and Maryam Razavian. 2023. Designing Ethics-Aware DecidArch Game to Promote Value Diversity in Software
Fairness-First Design Thinking for Software Architecture
Architecture Design Decision Making. In Universal Access in Human-Computer Interaction. Springer Nature Switzerland, Cham, 3–26. [3] Razieh Alidoosti, Patricia Lago, Eltjo Poort, Maryam Razavian, and Antony Tang. 2022. Incorporating Ethical Values into Software Architecture Design Practices. In 2022 IEEE 19th International Conference on Software Architecture Companion (ICSA-C). doi:10.1109/ICSA-C54293.2022.00031 [4] Aristotle. 2014. The Nicomachean Ethics. Penguin Classics. [5] Len Bass, Paul Clements, and Rick Kazman. 2012. Software Architecture in Practice (3rd ed.). Addison-Wesley. [6] Robert J. Bies and Joseph S. Moag. 1986. Interactional Justice: Communication Criteria of Fairness. In Annual Meeting of the Academy of Management. JAI Press. [7] Andrea J. Bingham. 2022. From Data Management to Actionable Findings: A Five-Phase Process of Qualitative Data Analysis. Sage Open 12, 2 (2022). [8] Kevin M. Carlsmith, John M. Darley, and Paul H. Robinson. 2002. Why Do We Punish? Deterrence and Just Deserts as Motives for Punishment. Journal of Personality and Social Psychology 83, 2 (2002). [9] Alessandro Castelnovo, Luca Malandri, Federico Mercorio, Mario Mezzanzanica, and Alberto Cosentini. 2021. Towards Fairness Through Time. In Machine Learning and Principles and Practice of Knowledge Discovery in Databases, Vol. 1524. Springer, Cham. doi:10.1007/978-3-030-93736-2_46 [10] Jane Cleland-Huang and Mona Rahimi. 2017. A case study: Injecting safetycritical thinking into graduate software engineering projects. In Proceedings of the 39th International Conference on Software Engineering: Software Engineering and Education Track. IEEE Press. doi:10.1109/ICSE-SEET.2017.4 [11] Jason A. Colquitt. 2001. On the dimensionality of organizational justice: A construct validation of a measure. Journal of Applied Psychology 86, 3 (2001). doi:10.1037/0021-9010.86.3.386 [12] Sam Corbett-Davies, Johann D. Gaebler, Hamed Nilforoshan, Ravi Shroff, and Sharad Goel. 2023. The measure and mismeasure of fairness. 24, 1, Article 312 (2023), 117 pages. [13] Natasha M. Costa Valentim, Williamson Silva, and Tayana Conte. 2017. The Students’ Perspectives on Applying Design Thinking for the Design of Mobile Applications. In 2017 IEEE/ACM 39th International Conference on Software Engineering: Software Engineering Education and Training Track (ICSE-SEET). doi:10.1109/ICSE-SEET.2017.10 [14] Ronnie de Souza Santos, Felipe Fronchetti, Savio Freire, and Rodrigo Spinola. 2025. Software Fairness Debt. arXiv:2405.02490 [cs.SE] https://arxiv.org/abs/2405.02490 [15] Ronnie de Souza Santos, Cleyton Magalhaes, and Rodrigo Spínola. 2025. Bias Smells: Exploring the Roots of Discrimination and Societal Inequities in Software Systems. SSRN Electronic Journal (2025). doi:10.2139/ssrn.5227890 [16] Cynthia Dwork, Moritz Hardt, Toniann Pitassi, Omer Reingold, and Richard Zemel. 2012. Fairness Through Awareness. In Proceedings of the 3rd Innovations in Theoretical Computer Science Conference (ITCS). ACM. doi:10.1145/2090236. 2090255 [17] Iffat Fatima, Markus Funke, and Patricia Lago. 2024. Providing Guidance to Software Practitioners: A Framework for Creating KPIs. IEEE Software (2024). doi:10.1109/MS.2024.3456446 [18] Iffat Fatima, Markus Funke, and Patricia Lago. 2025. Replication Package: FairnessFirst Design Thinking for Software Architecture (Version 1). doi:10.5281/zenodo. 17977756 [19] Markus Funke and Patricia Lago. 2025. Towards an Architectural Perspective for Sustainability: Bundle the Needs from Industry. In Quality of Information and Communications Technology. Springer Nature Switzerland. In press https: //arxiv.org/abs/2508.20774. [20] Kiev Gama, Fernando Castor, Pedro Alessio, Andre Neves, Cristiano Araújo, Rafael Formiga, Francisco Soares-Neto, and Higor Oliveira. 2018. Combining Challenge-Based Learning and Design Thinking to Teach Mobile App Development. In 2018 IEEE Frontiers in Education Conference (FIE). doi:10.1109/FIE.2018. 8658447 [21] Jennifer Golbeck. 2025. Recommender System-Induced Eating Disorder Relapse: Harmful Content and the Challenges of Responsible Recommendation. ACM Trans. Intell. Syst. Technol. 16, 1 (2025). doi:10.1145/3675404 [22] Jerald Greenberg. 1993. The Social Side of Fairness: Interpersonal and Informational Classes of Organizational Justice. Justice in the Workplace 1 (1993). [23] Hasso Plattner Institute of Design at Stanford. 2009. An Introduction to Design Thinking Process Guide. Technical Report. Stanford University, Stanford, CA, USA. [24] Christine Hofmeister, Robert L. Nord, and Dilip Soni. 2007. Applied Software Architecture. Addison-Wesley Professional. [25] Hsiu-Fang Hsieh and Sarah E. Shannon. 2005. Three Approaches to Qualitative Content Analysis. Qualitative Health Research 15, 9 (2005). doi:10.1177/ 1049732305276687 [26] Christophe Hurlin, Christophe Pérignon, and Sébastien Saurin. 2024. The Fairness of Credit Scoring Models. Management Science (2024). doi:10.1287/mnsc.2022. 03888 [27] International Organization for Standardization. 2011. ISO/IEC/IEEE 42010:2011 Systems and software engineering — Architecture description. Available at: https://www.iso.org/standard/50508.html.
,,
[28] A. Jansen and J. Bosch. 2005. Software Architecture as a Set of Architectural Design Decisions. In 5th Working IEEE/IFIP Conference on Software Architecture (WICSA’05). doi:10.1109/WICSA.2005.61 [29] Brian Jefferson. 2020. Digitize and Punish: Racial Criminalization in the Digital Age. University of Minnesota Press. [30] Aislinn Kelly-Lyth. 2021. Challenging Biased Hiring Algorithms. Oxford Journal of Legal Studies 41, 4 (2021). doi:10.1093/ojls/gqab006 [31] Jon Kleinberg, Sendhil Mullainathan, and Manish Raghavan. 2016. Inherent Trade-Offs in the Fair Determination of Risk Scores. Proceedings of Innovations in Theoretical Computer Science (ITCS) (2016). [32] Joyce H. L. Koh, Ching Sing Chai, Boon Wong, and Huang-Yao Hong. 2015. Design Thinking and Education. In Design Thinking for Education. Springer, Singapore. doi:10.1007/978-981-287-444-3_1 [33] Patricia Lago, Nelly Condori-Fernandez, Iffat Fatima, Markus Funke, and Ivano Malavolta. 2024. The sustainability assessment framework toolkit: a decade of modeling experience: The sustainability assessment framework toolkit: a decade of modeling experience. Softw. Syst. Model. 24, 2 (2024). doi:10.1007/s10270-02401230-9 [34] Patricia Lago, Sedef Akinli Koçak, Ivica Crnkovic, and Birgit Penzenstadler. 2015. Framing sustainability as a property of software quality. Commun. ACM 58, 10 (2015). doi:10.1145/2714560 [35] Gerald S. Leventhal. 1980. What Should Be Done with Equity Theory? Social Exchange: Advances in Theory and Research (1980). [36] Sofia Migliorini, Roberto Verdecchia, Ivano Malavolta, Patricia Lago, and Enrico Vicario. 2024. Architectural Views: The State of Practice in Open-Source Software Projects. In European Conference on Software Architecture. Springer, 396–415. [37] Ziad Obermeyer, Brian Powers, Christine Vogeli, and Sendhil Mullainathan. 2019. Dissecting racial bias in an algorithm used to manage the health of populations. Science 366, 6464 (2019). doi:10.1126/science.aax2342 [38] Maria Palacin-Silva, Jayden Khakurel, Ari Happonen, Timo Hynninen, and Jari Porras. 2017. Infusing Design Thinking into a Software Engineering Capstone Course. In 2017 IEEE 30th Conference on Software Engineering Education and Training (CSEE&T). doi:10.1109/CSEET.2017.41 [39] Kai Petersen and Cigdem Gencel. 2013. Worldviews, Research Methods, and their Relationship to Validity in Empirical Software Engineering Research. In 2013 Joint Conference of the 23rd International Workshop on Software Measurement and the 8th International Conference on Software Process and Product Measurement. 81–89. doi:10.1109/IWSM-Mensura.2013.22 [40] Hasso Plattner, Christoph Meinel, and Larry Leifer. 2010. Design Thinking: Understand – Improve – Apply. Springer. [41] Christophe Ponsard, Bérengère Nihoul, and Mounir Touzani. 2024. Modelling and Classification of Fairness Patterns for Designing Sustainable Information Systems. arXiv:2411.17894 [cs.SE] https://arxiv.org/abs/2411.17894 [42] John Rawls. 1971. A Theory of Justice. Harvard University Press. [43] Nick Rozanski and Eoin Woods. 2012. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives (2nd ed.). Addison-Wesley. [44] Seamus Ryan, Camille Nadal, and Gavin Doherty. 2023. Integrating Fairness in the Software Design Process: An Interview Study With HCI and ML Experts. IEEE Access 11 (2023). doi:10.1109/ACCESS.2023.3260639 [45] Andrew D. Selbst, Danah Boyd, Sorelle A. Friedler, Suresh Venkatasubramanian, and Janet Vertesi. 2019. Fairness and Abstraction in Sociotechnical Systems. In Proceedings of the Conference on Fairness, Accountability, and Transparency. Association for Computing Machinery. doi:10.1145/3287560.3287598 [46] Cameron Shelley. 2012. Fairness in Technological Design. Science and Engineering Ethics 18, 4 (2012). doi:10.1007/s11948-011-9259-1 [47] Yi Sheng, Junhuan Yang, Yawen Wu, Kevin Mao, Yiyu Shi, Jingtong Hu, Weiwen Jiang, and Lei Yang. 2022. The larger the fairer? small neural networks can achieve fairness for edge devices. In Proceedings of the 59th ACM/IEEE Design Automation Conference. Association for Computing Machinery. doi:10.1145/3489517.3530427 [48] Herbert A. Simon. 1969. The Sciences of the Artificial. MIT Press. [49] Marc Steen. 2013. Co-Design as a Process of Joint Inquiry and Imagination. Design Issues 29, 2 (2013). doi:10.1162/DESI_a_00207 [50] Anselm Strauss and Juliet Corbin. 1990. Basics of Qualitative Research: Grounded Theory Procedures and Techniques. Sage Publications. [51] Urjaswala Vora. 2025. Architecting for Fairness. In 2025 IEEE 22nd International Conference on Software Architecture Companion (ICSA-C). doi:10.1109/ICSAC65153.2025.00052 [52] Jiehuang Zhang, Ying Shu, and Han Yu. 2023. Fairness in Design: A Framework for Facilitating Ethical Artificial Intelligence Designs. International Journal of Crowd Science 7, 1 (2023). doi:10.26599/IJCS.2022.9100033