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 provide the framework for an extensible tool that allows measuring different kinds of debts.
The outcome of the thesis should be a prototype that fulfills different requirements: First, an architecture should be sketched that is robust to future extensions. Second, the architecture is implemented, considering existing implementations of EAD detection. Third, at least to kind of assessments should be considered: automatic assessment and support for interview based assessments. Fourth, the tool should be integrate-able into other tool environments for data exchange (e.g. by offering a REST-API).
You should be able to program in Java. It would be good if you were already familiar with several software engineering techniques like software testing, design patterns, measurement, 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
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.