Defining Thresholds for Enterprise Architecture Debt

Sammanfattning: 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.