Context: In an era where every industry is impacted by software, it is vital to keep software costs under control for organizations to be competitive. A key factor contributing to software costs is software maintenance where a significant proportion is utilized to deal with different types of technical debt. Technical debt is a metaphor used to describe the cost of taking shortcuts or sub-optimal design and implementation that compromises the software quality. Similar to financial debt, technical debt needs to be paid off in the future. Objective: To be in control of technical debt related costs, organizations need to identify technical debt types and quantify them to introduce solutions and prioritize repayment strategies. However, the invisible nature of technical debt makes its identification challenging in practice. Our aim is to find pragmatic ways to identify technical debt in practice, that can be supported by evidence. Once technical debt types that are significant have been identified, we aim to propose suggestions to mitigate them. Method: We used design science as a methodological framework to iteratively improve the technical debt identification methods. We utilized bug reports, which are artifacts produced by software engineers during the development and operation of the software system  as the data source for technical debt identification. Software defects reported through bug reports are considered as one of the key external quality attributes of a software system  which supports us in our evidence based approach. Throughout the design science iterations, we used the following research methods: case study and sample study. Results: We produced three design artifacts that support technical debt identification. The first artifact is a systematic process to identify architectural technical debt from bug reports. The second is an automated bug analysis and a visualization tool to support our research as well as to support practitioners to identify components with hot spots in relation to the number of defects. The third is a method for identifying documentation debt from bug reports. Conclusion: Based on the findings from this thesis, we demonstrated that bug reports can be utilized as a data source to identify technical debt in practice by identifying two types of technical debt; architectural technical debt and documentation debt. Compared to the identification of documentation debt, architectural technical debt identification still remains challenging due to the abstract nature of the architecture and its boundaries. Therefore, our future work will focus on evaluating the impact of reducing the sources of documentation debt on the frequency of bug reports and overall project cost.

Arkitektoniska beslut har ofta långvariga effekter på system. När beslut leder till ökad komplexitet, underhållbarhet och hämmad utvecklingshastighet, uppstår arkitektonisk teknisk skuld. Arkitektonisk teknisk skuld kan betraktas som mer relevant än någonsin i en tid där vi inte bara är mer beroende av våra informationssystem än någonsin, de är också mer komplexa än någonsin. Systemen fortsätter öka i skala och ny teknologi, såsom AI, tillkommer och blir snabbt en del av gemene mans vardagliga arbete. Arkitektoniska beslut fattas inte bara vid ett tidigt skede med dagens agila utvecklingsmetoder, utan kontinuerligt under iterationer. Detta kan leda till genvägar och därmed suboptimala arkitektoniska beslut, vilket i sin tur kan ge upphov till arkitektonisk teknisk skuld över tid. Denna masteruppsats om arkitektonisk teknisk skuld i en molnbaserad miljö är en fallstudie som undersöker organisationer verksamma inom CRM-systemet Salesforce, mer specifikt systemutveckling inom ramen för detta. Studien undersöker organisationernas uppfattning och hantering av fenomenet, men även hur deras attityder och risktagande ser ut vid arkitektoniska beslut. Studien presenterar tidigare forskning om teknisk skuld, den finansiella metaforen av Ward Cunningham, arkitektonisk teknisk skuld, en kategori av teknisk skuld, och använder två teoretiska ramverk: en deskriptiv modell för att tolka arkitektonisk teknisk skuld och en analytisk modell som kategoriserar teknisk skuld enligt Fowlers kvadranter, med en arkitektonisk tappning. Resultatet består av en empirisk insamling där dokumentation från Salesforce presenteras och åtta respondenter med olika roller har intervjuats. Studien visar att det råder skillnader i hur organisationer hanterar arkitektonisk teknisk skuld beroende på uppdragsgivarens roll och förståelse, att det finns utmaningar med att få hantering av arkitektonisk teknisk skuld prioriterad, samt att det råder både vårdslösa och eftertänksamma attityder. / Architectural decisions often have long lasting effects on information systems, when these decisions lead to increased complexity, maintainability, and inhibited development speed, architectural technical debt arises. Architectural technical debt can be considered more relevant than ever in an age where we are not only more dependent on our information systems than ever, they are also more complex than ever. The systems continue to increase in scale and new technology, such as AI, is added and quickly becomes part of the everyday work of the average person. Architectural decisions are made not only once at an early stage with today’s agile development methods, but continuously during iterations. This can lead to shortcuts and thus suboptimal architectural decisions, which in turn can create architectural technical debt over time. This master’s thesis on architectural technical debt in a cloud-based environment is a case study that examines organizations operating within the CRM system Salesforce, more specifically system development within this framework. The study examines the organizations' perception and management of the phenomenon, but also what their attitudes and risk-taking look like in architectural decisions. The study presents previous research on technical debt, the financial metaphor of Ward Cunningham, and architectural technical debt, a category of technical debt, and uses two theoretical frameworks: a descriptive model to interpret architectural technical debt and an analytical model that categorize technical debt according to Fowler’s quadrants, with an architectural angle. The result consists of an empirical collection where documentation from Salesforce is presented and eight respondents with different roles have been interviewed. The study shows that there are differences in how organizations handle architectural technical debt depending on the client's role and understanding, that there are challenges with getting handling of architectural technical debt prioritized, and that there are both reckless and prudent attitudes.