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.

A common challenge in organizations is a perception of that different languages are spoken among IT and other departments. Co-workers come from different background, have different knowledge base and sometimes even different objectives which can make an alignment more challenging. Enterprise Architecture (EA) can align IT investments with business directions and potentially solve issues regarding business-IT misalignments and bring value to organizations. Technical Debt (TD) is a well-established concept in software development and means that a solution that is “quick and dirty” is applied in order to earn time in short term and be able to provide a function in a system more quickly. This primitive implementation will at a later stage need to be corrected and rewritten, and the longer it takes, the more advanced, complex and time-consuming the correction will be. As EA has grown, major scientific and academic contributions have been developed. What is still missing is insight and ability to include a debt concept, which not only address TD but also business aspects. By adapting the TD concept in the EA domain, a new metaphor, providing a holistic perspective, has been proposed; Enterprise Architecture Debt (EAD). Up to the present debts for measuring EAD has been identified, but current research projects has not yet identified when a certain measure is to be considered of high or low quality. There is a need to develop a process for deriving such thresholds and identifying them. To be able to communicate the severity of an EAD to stakeholders, thresholds for EAD measures plays an important role. These thresholds will in the long term play a role in providing a tool for computer scientist working in organizations exploiting EA, and also contribute to current research within the field of IT-management and EA. By adopting a systematic process for defining expert driven thresholds a first version of a process for defining EAD thresholds could be presented and tested with domain experts. Five common opinions were detected, regarding the process, among the experts. The process could potentially facilitate useful communication and it was considered positive that it highlighted the context of the EAD. Also, that clearer process description and real-world EA model examples was needed, and that the moment of selecting membership function was unnecessary came up. Further, drivers for EAD thresholds and areas where it is perceived as important to have thresholds for EADs was a focus during the study. Cost and time, responsibility and engagement and context are perceived to be important drivers for EAD thresholds. While the business-it alignment and master data are seen as important areas. Also, context can play an important role when determine important areas. / En vanlig utmaning inom organisationer är uppfattningen av att olika språka talas på IT-avdelningen och övriga avdelningar. Medarbetare kommer från olika bakgrund, har olika kunskapsbas och ibland till och med olika mål, vilket kan göra fastställandet av riktning mer utmanande. Enterprise Architecture (EA) kan säkerställa att IT investeringar och affärs direktiv går i samma riktning och kan därmed potentiellt lösa problem i anslutning till IT och övrig affärsverksamhet som uppstått på grund av detta och skapa värde till organisationen. Teknisk skuld är ett väletablerat koncept inom mjukvaruutveckling och syftar till att enlösning som är ”quick and dirty” tillämpas för att vinna tid på kort sikt och kunna tillämpa en funktionalitet i ett system snabbare. Denna primitiva implementation kommer vid senare tillfälle behöva korrigeras och skrivas om. Ju längre tid det tar desto mer avancerad, komplex och tidskrävande kommer ändringen att bli. I takt med att EA har vuxit har stora vetenskapliga och akademiska bidrag utvecklats. Vad som fortfarande saknas är insikt och förmåga att inkludera ett skuldkoncept som inte bara adresserar tekniks skuld utan även affärsaspekter. Genom att introducera konceptet teknisk skult i EA domänen har en ny metafor, som tillhandahåller ett helhetsperspektiv, föreslagits; Enterprise Architecture Debt (EA Debt). Fram tills idag har skulder för att mäta EA Debt blivit identifierade, men aktuella forskningsprojekt har ännu inte identifierat när en viss EA Debt är hög eller låg. Det finns ett behov av att utveckla en process för att härleda sådana gränsvärden och identifiera dem. För att kunna kommunicera all varlighetsgraden för en EA Debt till intressenter kan gränsvärden för EA Debt spela en viktig roll. Dessa gränsvärden kommer på lång sikt spela en roll när det kommer till att tillhandahålla verktyg för datavetare som arbetar i organisationer som tillämpar EA, och också bidra till aktuell forskning inom IT-förvaltning och EA. Genom att anta en systematisk process för att definiera expertdrivna gränsvärden har en första version av en process för att definiera EA Debt-gränsvärden kunnat presenteras och testas med domän-experter. Fem vanliga uppfattningar, gällande processen, kunde uppräckas bland experterna. Processens skulle också potentiellt kunna främja användbar kommunikation och det ansågs positivt att den belysta och tog hänsyn till kontext gällande EA Debt. Att tydligare processbeskrivning och verklighetstrogna EA-modeller som exempel behövdes samt att momentet där medlemsfunktion skulle väljas var onödigt kom också upp. Vidare så fokuserade studien på drivkrafter för att ta fram gränsvärden för EA Debt och områden där uppfattningen är att detta är viktigt. Kostnad och tid, ansvar och engagemang och kontext är uppfattade som viktiga drivkrafter när det kommer till gränsvärden för EA skuld, medan inriktningen för IT och övrig affärsverksamhet och basdata ses som viktiga områden. Även kontexten kan ha en viktig roll när det kommer till att avgöra vilka områden som är viktiga.