Cognitive biases are predictable, systematic errors in human reasoning. They influence decision-making in various areas, including architectural decision-making, where architects face many choices. For example, anchoring can cause architects to unconsciously prefer the first architectural solution that they came up with, without considering any solution alternatives. Prior research suggests that training individuals in debiasing techniques during a practical workshop can help reduce the impact of biases. The goal of this study was to design and evaluate a debiasing workshop with individuals at various stages of their professional careers. To test the workshop's effectiveness, we performed an experiment with 16 students and 20 practitioners, split into control and workshop group pairs. We recorded and analyzed their think-aloud discussions about improving the architectures of systems they collaborated on. The workshop improved the participants' argumentation when discussing architectural decisions and increased the use of debiasing techniques taught during the workshop. This led to the successful reduction of the researched biases' occurrences. In particular, anchoring and optimism bias occurrences decreased significantly. We also found that practitioners were more susceptible to cognitive biases than students, so the workshop had a more substantial impact on practitioners. We assume that the practitioners' attachment to their systems may be the cause of their susceptibility to biases. Finally, we identified factors that may reduce the effectiveness of the debiasing workshop. On that basis, we prepared a set of teaching suggestions for educators. Overall, we recommend using this workshop to educate both students and experienced practitioners about the typical harmful influences of cognitive bias on architectural decisions and how to avoid them.

What are the business causes behind tight deadlines? What drives the prioritization of features that pushes quality matters to the back burner? We conducted a survey with 71 experienced practitioners and did a thematic analysis of the openended answers to the question: "Could you give examples of how business may contribute to technical debt?" Business-related causes were organized into two categories: pure-business and business/IT gap, and they were related to ‘tight deadlines’ and ‘features over quality’, the most frequently cited management reasons for technical debt. We contribute a cause-effect model which relates the various business causes of tight deadlines and the behavior of prioritizing features over quality aspects.

Incorporating the business perspective into prioritizing technical debt is essential to contribute to decision making in industry. In this paper, we evolve and evaluate a business-driven approach for technical debt prioritization. The approach was evaluated during a five-months industrial case study with business and technical stakeholders' active participation. The results show that the approach contributed to aligning business criteria between the business and technical stakeholders. We also observed a downward trend in the amount of technical debt that affects high-value business assets. Moreover, we identified eight business factors that affect the decision making related to the prioritization of technical debt. The study results suggest that the proposed business-driven technical debt prioritization approach can help teams to focus their efforts on paying off the business' most relevant debt.

Technical debt happens when teams take shortcuts on software development to gain short-term benefits at the cost of making future changes more expensive. Previous results show that there is a misalignment between the prioritization done by technical professionals and the prioritization expected by business ones. This paper presents a business-driven approach to prioritize technical debt items. The research is organized into four phases: exploratory, to identify the research focus; concept verification, where the proposed approach was evaluated on a multi-case study; solution, where a design science research was conducted to develop Tracy, a framework for technical debt prioritization; and validation. Results so far show that the business-driven prioritization of technical debt items can improve the alignment and communication between the technical and business stakeholders.

Technical debt is a pervasive problem in software development. Software development teams have to prioritize debt items and determine whether they should address debt or develop new features at any point in time. This paper presents "Tracy", a framework for the prioritization of technical debt using a business-driven approach built on top of business processes. The current stage of the proposed framework is at the beginning of the third phase of Design Science Research, which is usually divided into the phases of exploration, engineering, and evaluation. The exploration and engineering phases involved the participation of 49 professionals from 12 different groups of three companies. The initial evaluation shows that the presented framework is coherent in its structure and that its results contribute to business-driven decision making on technical debt prioritization.

Technical debt (TD) is a metaphor to describe the trade-off between short-term workarounds and long-term goals in software development. Despite being widely used to explain technical issues in business terms, industry and academia still lack a proper way to manage technical debt while explicitly considering business priorities. In this paper, we report on a multiple-case study of how two big software development companies handle technical debt items, and we show how taking the business perspective into account can improve the decision making for the prioritization of technical debt. We also propose a first step toward an approach that uses business process management (BPM) to manage technical debt. We interviewed a set of IT business stakeholders, and we collected and analyzed different sets of technical debt items, comparing how these items would be prioritized using a purely technical versus a business-oriented approach. We found that the use of business process management to support technical debt management makes the technical debt prioritization decision process more aligned with business expectations. We also found evidence that the business process management approach can help technical debt management achieve business objectives.

In the Change Management process within IT Service Management, some activities need to evaluate the risk exposure associated with changes to be made to the infrastructure and services. The paper presents a method to evaluate risk exposure associated with a change. Further, we show how to use the risk exposure metric to automatically assign priorities to changes. The formal model developed for this purpose captures the business perspective by using financial metrics in the evaluation of risk. Thus the method is an example of Business-Driven IT Management. A case study, performed in conjunction with a large IT service provider, is reported and provides good results when compared to decisions made by human managers.

Change management is one of the most critical processes in IT management. Some of the reasons are the sheer number of changes and the difficulty of evaluating the impact of changes on the IT services being provided. Through carrying out a survey with IT managers and practitioners, we have found that, among the activities performed during change management, change scheduling (allocating changes to change windows) is the most problematic one. In this paper we solve the change scheduling problem by using a business-driven approach that evaluates the impact of a change schedule in terms of the financial loss imposed on the service provider. Toward this aim, we model the impact of SLA violations when the implementation of changes is done after their deadline. A change scheduling optimization problem is then formalized and its solution is applied to a typical scenario. The results show that optimizing the scheduling of changes can result in significant savings to an IT support organization.