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.

The development of Information Technology is, according to the Swedish Government, the most important area of development. The costs of IT in governmental agencies are somewhere in between 20 to 25 billion SEK, paid by taxpayers and one of the largest cost items in the Swedish governments resources. Despite this, every third Swedish governmental agency lacks an IT-strategy and is unable to meet needs for flexibility and control. The study aims to reveal barriers that prevent an active application lifecycle management (ALM) at Swedish governmental agencies and to answer the question: “How do Swedish authorities handle their proprietary applications from a lifecycle perspective; financially and technically?” The case study will be conducted at the Social Insurance Agency (SIA). The SIA distributed, in 2010, about 6 % of the Swedish GDP and is mainly funded by grants and loans from the Swedish National Debt Office. The survey will be studied from a management accounting and ALM perspective. Management accounting is the actions within organizations to achieve financial goals. ALM is the lifecycle of an application that consists of the phases; requirements specification, development, testing, deployment and maintenance. The study will also investigate the technical debt at the governmental agencies. Technical debt refers to the work which has to be completed before an application can be considered finished. The survey is a qualitative study based on interviews with an exploratory purpose. The results are generalised to reflect a greater part of the Swedish authorities and showed that Swedish governmental agencies have inadequate handling of their proprietary applications and that each application is financially linked to one or more projects simultaneously. The models made are to facilitate the understanding of the different stages of ALM in synergy with the management accounting. Theoretically, the Maintenance phase allocates approximately 90 % of the total costs, whereas in governmental agenises it stands for about 20 %. Theoretically 10 % of the total costs are allocated to the Development phase, whereas in governmental agencies the corresponding amount is 80 %. A consequence of this is increased technical debt. The technical debt at Swedish authorities is often funded with loans, which is not allowed according to the Swedish National Debt Office. The SIA exceed budgets without asking for increased funds and according to the Swedish Audit Office, so does also 1/3 of the Swedish governmental agencies, meaning that they must handle the financial complications internally by moving funds amongst different departments and projects, also spending money meant for development on maintenance. Future studies can be made as investigations on how management accounting and ALM can be implemented on a safe and effective manner in a governmental agency.

I det teknikväxande samhället bidrar mjukvaruutveckling till stora it-relaterade utgifter och investeringar. Industrier utvecklar stödjande programvara för sin produktion och mjukvaruföretag levererar digitala system för kunder som behöver uppfylla ett behov. Utvecklingsteamen jobbar under press för att leverera så bra programvara som möjligt och samtidigt hålla sig inom budgetramar som satts upp enligt avtal. För att nå sina mål kan utvecklare introducera teknisk skuld i systemen, dvs. att bristfälliga lösningar byggs före kvalitetslösningar. Teknisk skuld behöver inte vara ett problem för stunden men på sikt kan konsekvenserna av skulderna bli problematiska och kräva resurser att kunna hanteras. Tidigare forskning visar att drygt en fjärdedel av en utvecklares tid går åt för att hantera teknisk skuld. Vid åtgärdande av teknisk skuld brukar refaktorisering vara ett vanligt verktyg att ta till, vilket innebär att skriva om källkod utan att förändra det visuella beteendet för användaren. Syftet med följande uppsats är att undersöka olika branscher som utvecklar mjukvaraoch deras hantering av teknisk skuld genom att belysa vilka faktorer som avgör om och när refaktorisering skall ske, och hur argumentationerna för refaktorisering skiljer sig åt mellan branscherna. Uppsatsen baseras på kvalitativa intervjuer med aktörer från både industri- och mjukvaruföretag. Empirin från intervjuerna analyseras med hjälp av en ontologisk mappning kring typer av teknisk skuld, som sedan har applicerats i ramverket Technical Debt Quadrant. Resultatet visar att industribranschens avgörande faktorer för refaktorisering var konsekvensen av skuldens påverkan samt hur pass förändringsbenägen den skuldbelagda funktionaliteten var. Branschen ansåg att tidpunkten för att refaktoriseravar bäst lämpad i samband med vidareutveckling av en funktion som innehöll teknisk skuld. I konstrast visade resultatet för mjukvarubranschen att faktorerna för refaktorisering var konsekvensen av skuldens påverkan samt vilka ekonomiska förutsättningar som fanns för projektet. Tidpunkten för när refaktorsering var lämplig avgörs när företagen anser att avkastningen för investeringen att refaktorisera är som högst eller när inget annat val finns. Resultatet visar även att branscherna hade olika fokus för hur de argumenterar för refaktorisering. Industrin argumenterade mer med systemet i fokus, hur det kundeförändras med tiden och att det skulle bli lätthanterligt att underhålla med tiden. Mjukvarubranschen hade mer ekonomiska aspekter som argument, dvs. att de analyserade situationen och beslutade huruvida refaktoriseringen är lönsam eller inte. / In the technology-growing society, software development contributes to large itrelated expenditures and investments. Industrial companies develop supporting software for its production and software companies deliver digital systems for customers to satisfy a need. The development teams work under pressure to deliver as good software as possible and at the same time stay within budget frameworks according to agreements. To achieve their goals technical debt in systems can be introduced, which means that deficient solutions are built before quality solutions. Technical debt does not have to be a problem at first, but in the long run the consequences of the debts can become problematic and require resources to be managed. When fixing technical debt, refactorization is a common tool to resort to, which means to rewrite source code without changing the visual behaviour to the user. Previous research shows that just over a quarter of a developer's time is spent managing technical debt. The purpose of the thesis is to examine different industries that develop software and their management of technical debt by highlighting which factors determine if and when refactoring should take place, and how the arguing for refactorization differentiate between the industries. The thesis is based on qualitative interviews with actors from both industrial and software companies. The empirical data from the interviews are analysed with the help of an ontological mapping around types of technical debt, and later applied in the framework Technical Debt Quadrant. The results show that the industry companies' decisive factors for refactorization were the consequence of the debt's impact and how prone to change the indebtedness functionality was. The industry considered that the time to refactorize was best suited in connection with the further development of a function that contains technical debt. In contrast, for the software companies the results showed that the factors for refactorization were the consequences of the debt's impact and what financial prerequisites there were for the project. Appropriate timing for refactoring wasdetermined when the companies consider that the return on the investment to refactorize is at its highest or when there is no other choice. The results also show that the industries had different focus on how they argue for refactorization. The industry argued more with the system in focus, how it could change over time and that it should be easy to maintain while the software industry had more economic aspects as an argument, ie. that they analyzed the situation and made choices whether the refactorization is profitable or not.

The complex nature of technical debt and its implications has led to failures within IT-projects in aspects of exceeded budgets, failure to meet project objectives and to deliver a qualitative final product according to client specifications. The reasons IT-projects are struggling to succeed are many. Technical debt contributes in both a negative and positive aspect of project development and project management, and can, in certain cases, be held accountable for IT-project failures. Haeckel’s adaptive loop has been applied within the study, in two different aspects; technical debt and strategic debt, in relation to its planning, implementation and management. Bannerman’s multi-domain project success framework has been applied in accordance to Haeckel’s adaptive loop in the evaluation of the second loop, strategic debt. Respondents were chosen based on their previous knowledge and experience within the study area of interest, to participate in interviews. The collected data was analyzed through the perspective of Haeckel’s adaptive loop and followed with transliteration and extraction of themes and keywords. The objective of this study, is to present an analytical approach on how to manage technical debt within IT-projects, from both a technical and strategic point of view. Our proposed approach will contribute to a greater understanding of technical debt in terms of planning, strategy and implementation within IT-projects through collected data, based on real project situations and problems.

Software development can be a difficult and time consuming task. In addition, producing good code is even more difficult. Poor design and implementation choices in software code can result in an end product that is both difficult to understand and difficult to maintain. A collective name for implementation and design choices that is considered to have a negative impact or indicate something negative in software code is Code smells. In this study, we identify 34 unique code smells through a systematic literature study. The results are then ranked and validated with interviews with people who work or have worked with Javascript in a professional environment at some point during the past five years. The end result is a ranked list of 32 code smells that are applicable to Javascript. The result shows that the five highest ranked code smells are Variable name conflict in closures, Depth, Argument Type Mismatch, Duplicated code and Excessive global Variables.

Technical debt is used to describe the changing or to maintain a system due to expedient shortcuts done during its development. In the context of the software development industry, technical debt is regarded as a critical issue in terms of the negative consequences such as increased software development cost, low product quality, decreased maintainability, and slowed progress to the long-term success of developing software. Code Smells are well informed in the domain of Technical Debt. They indicate to the common bad practices that may impair the future quality of the software system. By identifying those Code Smells, it is possible to give an improved solution or make the developers aware of a possible deficiency. I explore the premise that technical debt within the enterprise should be viewed as a tool. Extensible and Appropriate tools can check the Code Smells automatically and improve the quality assessment accordingly. However, in the field of Enterprise Architecture(EA), common bad habits in EA can be called EA Smells. EA Smells itself can be a component of EA Debt. Enterprise Architecture Debt can be defined as such a metric that depicts the deviation of the currently present state of an enterprise from a hypothetical ideal state.In this thesis, we introduce SmellCull as an extensible tool for capturing, tracking and managing Enterprise Architecture debt in the EA field. SmellCull allows measuring different kinds of Enterprise Architecture debts for EA Model. SmellCull is extensible since different types of Model can be integrated as input into the tool environment and provides developers with a lightweight tool to capture EA debt and make it easier to understand them indicating corresponding parts in the implementation. The tool is used to create propagation paths for the EA debt. This allows for an up-to-date and accurate presentation of EA debt to be upheld, which enables developer conducted implementation-level micromanagement as well as higher-level debt management.Since the tool is sophisticated enough, automated detection supports the design process and ongoing change of EAS(Enterprise Architecture System). This includes the strategic development of EAS with the corresponding roadmaps, as well as design assurance and performance monitoring to assess the quality of data in EA repositories and the compliance with certain standards defined by EA Smells. Due to the limited scope of master thesis, the tool will identify a few number of EA debt. At the end, some future work suggestions in the context of identifying more salable Enterprise Architecture Debts with this tool are given. / Teknisk skuld dvs dålig eller kortsiktig programutveckling som belastning på IT-system måste förr eller senare återbetalas. I industrin betraktas teknisk skuld som en kritisk fråga när det gäller de negativa konsekvenserna som ökad mjukvaruutvecklingskostnad, låg produktkvalitet, minska underhåll och långsammare framsteg till den långsiktiga framgången med att utveckla programvara. Dålig kodkvalitet “code smell” är vanligt förekommande teknisk skuld. Det uppkommer i vanliga dåliga metoder “anti-patterns” som försämrar programvarans framtida kvalitet. För att kunna identifiera bristande kodkvalitet är det möjligt att skapa en förbättrad lösning eller göra utvecklare medvetna om de möjliga bristerna. Jag undersöker förutsättningarna att en sådan teknisk skuld i företag bör undersökas med en programvara. Utbyggbara och ändamålsenliga programvaror kan analysera källkod och hitta var kvaliteten behöver förbättras. Företagens tekniska skuld kan definieras som ett mått som visar avvikelsen från ett hypotetiskt idealtillstånd genom att jämföra det aktuella tillståndet med praktiska rekommendationer “best practice”. I detta examensarbete introducerar jag SmellCull som ett utbyggbart verktyg för att hitta, spåra och hantera bristfällig kodkvalitet inom företagsarkitektur (EA). SmellCull tillåter mätning av olika typer av tekiska skulder för EA modellen. SmellCull är utbyggbart genom att olika typer av datamodeller kan integreras som indata i miljön, och det ger utveck-lare ett lätt verktyg för att hantera teknisk skuld i programmeringsprojekt och hjälpa projektdeltagarna i programmeringsprojekt att förstå vad orsakar brister i kodkvalitet.  Eftersom verktyget är tillräckligt sofistikerat finns det automatiserad spårning, designprocess och kontinuerlig förbättring av EAS (Enterprise Architecture System). Detta inkluderar strategisk utveckling av EAS med motsvarande färdplan, samt konstruktionssäkerhet och prestandäovervakning för att bedöma kvaliteten på data i EA förvar och efterlevnaden av vissa standarder som definieras av EA code smell detection. På grund av den begränsade omfattningen av examensarbetet kommer verktyget att  identifiera några få EA skuld. I slutet, några framtida arbetsförslag i samband med identifiering mer säljbara företagsarkitekturskulder med detta verktyg ges.

Software architecture (SA) smells are design problems in the internal structure and behavior of an SA. These can be seen as a specific category under the umbrella concept of technical debt (TD). TD is a central concept in software development projects and having the means to detect and measure the smells is essential to understand impairments they may cause. However, TD is only limited to the technical aspects and does not describe smells found on an enterprise level. Enterprise architecture debt (EAD) expands the concepts of TD beyond the technical aspects such that it covers the debts that can be found in all layers of an Enterprise Architecture (EA). EA smells give a measurement for EAD by providing means for identifying and detecting the smell, hence enabling a method to quantify the level of debt. The goal of this thesis is to find EA smells derived from existing SA smells. In total, three new EA smells were presented based on existing SA smells. Each new smell was described by a short description that informally summarizes the smell. This was followed by an indication of the smell’s origin and reasoning about the effects on the quality. Then, an illustrative example of the smell was provided. Finally, a detection algorithm was also provided and implemented in a prototype detection program. This thesis serves as a basis for measurements of the quality of an EA and motivation for future research in this area. It is argued that the finding of EA smells can facilitate quality assessment in an EA. / Mjukvaruarkitektursrötor (MA-rötor) är designproblem i den interna strukturen och beteende i en mjukvaruarkitektur. Dessa kan ses som en specifik kategori under samlingsbegreppet teknisk skuld (TS). TS är ett centralt begrepp inom projekt i mjukvaruutveckling och att ha en metod att upptäcka och mäta dessa rötor är viktigt för att förstå försämringar dessa kan orsaka. TS är dock enbart avgränsat till de tekniska aspekterna och beskriver inte rötorna som kan finnas på en verksamhetsnivå. Verksamhetsarkitektursskulder (VAS) expanderar konceptet av TS utöver de tekniska aspekterna så att de även täcker skulderna som kan finnas på alla nivåer i en verksamhetsarkitektur (VA). VA-rötor ger ett mätvärde för VAS, genom att förse ett sätt att upptäcka rötorna och därmed möjliggöra ett sätt att kvantifiera graden av skuld. Målet i denna avhandling är att hitta VA-rötor som är härledda från befintliga MA-rötor. Totalt har tre nya VA-rötor presenterats baserat på befintliga MA-röter. Varje ny röta har beskrivits med en kort beskrivning som informellt summerar rötan. Detta följt av en indikation av rötans ursprung och resonemang om dess effekt på kvalitén. Ett illustrativt exempel har även presenterats. Slutligen, har en algoritm för att upptäcka rötan också presenterats och implementerats i ett prototypprogram för att upptäcka rötan. Denna avhandling används som en grund för mätvärden av kvalité i en VA och motivation för framtida studier i detta område. Det argumenteras för att identifieringen av VA-rötor kan förenkla kvalitetsbedömningen av en VA.

Bakgrund: Teknisk skuld är ett återkommande problem inom mjukvaruutveckling där det tycks vara omöjligt att undvika att samla på sig en teknisk skuld som över tid måste återbetalas innan den blir för komplex att handskas med. Detta har inneburit att man behöver hantera, åtgärda och återbetala den tekniska skulden med olika typer av tillvägagångssätt. Syfte: Syftet med denna studie var att intervjua tekniska ledare för att ta del av deras syn på vad teknisk skuld är och hur man hanterar den i det dagliga arbetet. För att kunna förstå termen teknisk skuld användes tidigare forskning och befintlig litteratur om ämnet. Metod: Undersökningsdesign i rapporten har följt en små-N-studie där nio respondenter har intervjuats från olika organisationer i Sverige. Intervjuerna genomfördes via digitala medel och samtliga intervjuer spelades in. Efter varje intervju transkriberades materialet med hjälp av Microsoft Word och renskrevs sedan av författarna i studien. Resultat: Resultatet visar att hanteringen av teknisk skuld skiljer sig beroende på vilken typ av bransch man är verksam inom. Det kan handla om hur man hanterar återbetalningen av teknisk skuld eller vilken typ av skuld som man samlar på sig. Slutsats: Fastän hanteringen och synen på teknisk skuld varierade mellan respondenterna så ansåg alla att det var väldigt viktigt att ta tag i och inget som man kunde ignorera. / Background: Technical debt is a recurring problem within software development where it seems impossible to avoid accumulating technical debt that over time must be repaid before the interest grows too large and complex to deal with. This has meant that you somehow need to handle, fix and repay the technical debt with many different approaches. Aim: The aim for this study was to interview tech leads about their view on what technical debt is and how it is managed in their daily work. To better understand the underlying concept of what a technical debt is and how it is managed we used prior research and existing literature about the subject. Method: The design method used in this report was of the type small-N-studies where nine respondents were interviewed from different organizations all located in Sweden. The interviews were transcribed using Microsoft Word and was then rewritten by the authors to be able to then analyze the material using a targeted content analysis with predetermined categories based on previous studies. Main result: The results show that the management of technical debt differs depending on the type of industry in which you operate. It can be about how to handle the repayment of technical debt or the type of debt that you accumulate. Conclusion: Although the management and view of technical debt varied between the respondents, everyone considered it very important to address and nothing that could be ignored. The technical debt was handled differently, but in the end the working methods were similar.

The rapid pace of digitalization has resulted in increased management of software development, and today a majority of startups are reliant on software. How to manage software development projects is a well-researched area and agile methods are widely adopted by companies in all industries and sizes. However, prior to working with agile methods or any other software development methodology, the founders and management of a startup have to make several technical decisions that could potentially affect the whole software development process and the company's success. Furthermore, studies show that only three programming languages are known by more than 50% of developers, suggesting that the potential effects of technical decisions stretch outside the software development process.  By performing a multiple-case study on startups with a mixed-methodology approach, the researcher has analyzed the literature, interviewed several founders and Chief Technology Officers, and quantitatively analyzed hundreds of thousand lines of code, to find how to organize to make better technical decisions in order to enhance growth and generate less technical debt. The results show that the effects of technical decisions stretch outside the software development process, having an apparent effect on a startup's ability to attract and retain talent. Furthermore, the results show that access to talent is an important but not deciding factor in technical decision-making. Additionally, it is found that in the initial stage of a startup, ease of development and speed are important factors in technical decisions as the main objective is to find product-market fit. When product-market fit has been found and the startup matures, the focus shifts and quality and durability are becoming prominent factors. It is found that scooping features only to implement the absolute core functionality is an effective approach to develop quickly and generate less technical debt while maintaining customer satisfaction. Lastly, it is found that programming language affects the number of issues generated per line of code and the time spent on building features. However, as found in the literature, there is no evidence of this being related to the type of programming language.  The findings have both practical and academic implications. In academics, this thesis lays the foundation for further studies and provides new insights into the field of startups in general, and technical decision-making in particular. For practitioners, this thesis provides a basis for discussion and execution of technical decisions in the early stages of a startup. / Den snabba digitaliseringen har resulterat i en ökad ledning av mjukvaruutveckling och idag är majoriteten av startups beroende av någon form av mjukvara. Hur man leder mjukvaruutvecklingsprojekt är ett välutforskat område och agila metoder är välanvända i företag i alla industrier och storlekar. Innan man arbetar med agila metoder eller någon annan mjukvarutvecklingsmetod så måste grundarna och ledningen ta flera tekniska beslut som potentiellt kan påverka hela mjukvaruutvecklingsprocessen och företagets framgång. Samtidigt finns det studier som visar att endast tre programmeringsspråk hanteras av mer än 50% av utvecklarna, vilket indikerar att de potentiella effekterna av tekniska beslut sträcker sig långt utanför mjukvaruutvecklingsprocessen.  Genom att utföra en flerfallsstudie på startups med både kvalitativa och kvantitativa moment, har forskaren analyserat literaturen, intervjuat flertalet grundare och tekniska chefer, och kvantitativt analyserat hundratusentals rader kod, för att undersöka hur startups kan organisera sig för att ta bättre tekniska beslut som förbättrar tillväxten samt genererar mindre teknisk skuld. Resultaten visar att effekten av tekniska beslut sträcker sig långt utanför mjukvaruutvecklingsprocessen genom att ha en direkt påverkan på startups möjlighet att attrahera och behålla talang. Tillgången till talang visar sig även vara en viktig faktor i teknisk beslutsfattande, däremot är den inte en avgörande faktor. Dessutom visar resultaten att i det initiala stadiet av en startup så är enkelhet och hastighet viktiga faktorer i tekniskt beslutsfattande eftersom fokus ligger på att hitta produkt-marknads-anpassning. När produkt-marknads-anpassning är funnen och startupen mognar, så skiftar dessa faktorerna över till kvalité och hållbarhet. Resultaten visar även att en effektiv metod för att utveckla snabbt och skapa mindre teknisk skuld är att skala ner förfrågningar till dess absolut grundfunktionalitet, samtidigt visade det sig att kundnöjdheten inte minskade. Slutligen visar resultaten att val av programmeringsspråk har en effekt på antalet issues genererade per rad kod och även tiden spenderad för att bygga features. Däremot, precis som i tidigare forskning, finns det inga bevis på att det är relaterat till typen av programmeringsspråk.  Resultaten har både praktiska och akademiska implikationer. I den akademiska världen så lägger detta arbetet en grund för framtida forskning och ger nya insikter i startupfältet generellt, och tekniskt beslutsfattande i startups i synnerhet. För utövare, lägger detta arbetet en bra bas för diskussion och verkställande av tekniska beslut i startups.

Digitaliseringen har inneburit en tilltagande komplexitet i organisationer, vilket föranlett skapandet av begreppet teknisk skuld. Likväl som organisationer försätter sig i ekonomiska skulder försätter sig organisationer i tekniska skulder. Tidigare forskning inom teknisk skuld visar på ett kunskapsgap gällande organisationsteoretiska aspekters eventuella påverkan på teknisk skuld. Baserat på detta så syftar studien till att undersöka antagandet gällande kontrasterande perspektiv på teknisk skuld mellan kommersiellt styrda och tekniskt styrda organisatoriska enheter. För att sedan utforska huruvida balansen av organisatoriska aspekter mellan enheter kan understödja en viss typ perspektiv och därmed inverka på organisationens faktiska ageranden, avvägningar och vägval i relation till teknisk skuld. Undersökningen grundas i en kvalitativ fallstudie där åtta intervjuer i fyra mjukvaruutvecklande organisationer genomförts. Studien visar på att perspektiven mellan enheter i denna undersökning skiljer sig åt en aning men att detta inte påverkar teknisk skuld i någon större utsträckning. Detta tack vare ömsesidig förståelse, god kommunikation, samsyn genom överordnade mål samt balans mellan makt och kultur. Kommersiella krafter tycks besitta något mer makt men undersökta bolag har samtidigt vägt upp detta genom en tydligt teknikfokuserad kultur. Vilket kan få organisationer att, om något, balansera en aning mer åt ett fokus på framtida hållbarhet och därmed gå miste om nutida affärsmöjligheter genom att undgå ett mer flexibelt och tillåtande förhållningssätt till teknisk skuld. / Digitization has meant an increasing complexity in organizations, which has led to the creation of the concept of technical debt. Just as organizations incur financial debts the organizations incur technical debts. Previous research in technical debt sheds light on a knowledge gap regarding organizational aspects, which influence technical debt. Based on this, the study aims to examine the assumption regarding contrasting views on technical debt between commercially controlled and technically controlled organizational units. To then explore whether the balance of organizational aspects between units can support a certain type of perspective and thereby influence the organization's actual actions, trade-offs and decision-making in relation to technical debt. The study was created through a qualitative case study where eight interviews were conducted in four software developing organizations. The study shows that the perspectives between units in this survey differ slightly, but that this does not affect technical debt to any great extent. This thanks to mutual understanding, good communication, consensus through overriding goals and a balance between power and culture. Commercial forces seem to possess somewhat more power, but surveyed companies have at the same time offset this through a clear product- and technology-focused culture. Which may cause organizations to, if anything, balance a little bit more on future sustainability and thus miss out on current business opportunities by avoiding a more flexible and permissive approach to technical debt.