In 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. Technical debt describes the delayed technical development activities for getting short-term payoffs such as a timely release of a specific software. Seaman et al. described technical debt as a situation in which software developers accept compromises in one dimension to meet an urgent demand in another dimension and eventually resulted in higher costs to restore the health of the system in future. So far, the context of technical debt is still limited to the technological aspects.
Over the years, technical debt becomes increasingly important when organizations invest huge amounts of money in IT to stay competitive, effective, and efficient. However, it is vital to align IT and business in order to realize the full benefits and potentials of those IT investments. From there, the concept of Enterprise Architecture (EA) has evolved as a method to facilitate the alignment of IT systems and business strategies within dynamic and complex organizations. Consequently, the huge interest in EA resulted in vast scientific contributions that address a broad thematic spectrum, including EA frameworks, EA management, and EA tools. However, there is a lack of insight into the application of the debt concept to include not only the technological aspects addressed by technical debt, but also the business aspects. Adapting the concept of technical debt in the EA domain, hitherto we have proposed a new metaphor “Enterprise Architecture debt (EAD)” to provide a holistic view. So far, first steps to measure EAD where taken by identifying first debts and proposing a prototype, which allows to measures some of them. This thesis aims to develop further measurements for EAD. Those can arise from mapping existing measurements for bad behavior in the different domains of EA (business, data, application, infrastructure layer) to EAD. Another possibility is to conduct interviews with experts and practitioners in the field and conclude based on their input further measurements.
The outcome of the thesis should be a set of measurements for EAD. The concrete sources will be determined in a personal discussion with the supervisor, as there are several possible sources. Further, we expect a prototype that allows assessing the EAD (semi-)automatic. This prototype should be integrated in our existing environment.
Developing knowledge might be of advantage (e.g., Java, C#, …). It would be good if you were already familiar with the concept of EA, design patterns, and REST-APIs.
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 Incollection
In: Gronau, Norbert; Heine, Moreen; Poustcchi, K; Krasnova, H (Ed.): WI2020 Community Tracks, pp. 276–290, GITO Verlag, 2020, ISBN: 9783955453367.