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. According to Seaman et al., TD can be described as a situation where software developers accept compromises in one dimension to meet an urgent demand in another dimension. This will later on result in an increased cost to restore the system’s health in the future.
To date, the context of technical debt is still limited to the technical aspects. During the years TD has become more important in order for companies to be able to make investments in IT-systems to maintain competitiveness, efficiency and durability. Also, to realize all the benefits and potential in those investments it is of high importance to align IT and other business activities. Enterprise Architecture (EA) has emerged to solve the issues regarding business-IT misalignments. EA is a method used to control and describe how complex and dynamic organizations processes, structures, applications, systems and technology interrelates. EA provides an unambiguous specification of the components included and their relations which makes it useful to serve as a communication bridge between the IT department and other business departments. A common challenge in organizations is a perception of that different languages are spoken among IT and other departments, and EA can provide a possible solution to this problem. An EA model does not only describe the current or future situation of the business but can also be a useful tool when evaluating the transition from current to future scenarios.
As EA has grown major scientific and academic contributions, that can be adapted in broad spectrum, been developed. These include among others EA frameworks, EA management and EA tools. 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). Hacks et al. define EAD as follows: ”Enterprise Architecture Debt is a metric that depicts the deviation of the currently present state of an enterprise from a hypothetical ideal state”. 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.
EAD as a concept and metaphor can lay a foundation for a common language between IT-departments and other business departments within an organization when it comes to communicating potential design issues. Commonly there is a gap concerning different objectives and background among business and IT representatives in an organization. This can inevitably make it difficult to align IT with the rest of the organization. EAD, as an extension of TD, can play an important role in addressing this issue. To be able to get the most out of an organization, drive innovation and align objectives a common language is of high importance and to be able to communicate the severity of an EAD. Here thresholds for EAD measures plays an important role. These thresholds for EAD 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 that can be helpful for computer scientists doing research within these fields.
The purpose and aim with this study are to identify thresholds for EAD measures by identifying different kinds of thresholds and detect how these could be codified, and also to map the process for identifying such measures and ascertain which of these EAD measure thresholds that are relevant for EA practitioners.
- RQ1: What different kinds of EAD measure thresholds exist?
- RQ2: Which EAD measure thresholds are of relevance for practitioners?
- RQ3: How can these thresholds be codified in a structured manner?
- RQ4: How does a process look like, that can be followed, to identify EAD measure thresholds?
EA Smells catalog: https://ba-ea-smells.pages.rwth-aachen.de/ea-smells/
EA Smells prototype: https://git.rwth-aachen.de/ba-ea-smells/program
In: 8th International Workshop on Quantitative Approaches to Software Quality in conjunction with the 27th Asia-Pacific Software Engineering Conference (APSEC 2020), pp. 47-54, CEUR-WS, 2020.
Towards a Catalog of Enterprise Architecture Smells Book Section
In: Gronau, Norbert; Heine, Moreen; Poustcchi, K; Krasnova, H (Ed.): WI2020 Community Tracks, pp. 276–290, GITO Verlag, 2020, ISBN: 9783955453367.