Background
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.
Planned Outcome
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.
Expectations
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.
Contact Persons
Further Information
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
Related Work
Lehmann, Barry-Detlef; Alexander, Peter; Lichter, Horst; Hacks, Simon
Towards the Identification of Process Anti-Patterns in Enterprise Architecture Models Proceedings Article
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.
@inproceedings{Lehmann2020,
title = {Towards the Identification of Process Anti-Patterns in Enterprise Architecture Models},
author = {Barry-Detlef Lehmann and Peter Alexander and Horst Lichter and Simon Hacks},
url = {http://ceur-ws.org/Vol-2767/06-QuASoQ-2020.pdf},
year = {2020},
date = {2020-12-11},
booktitle = {8th International Workshop on Quantitative Approaches to Software Quality in conjunction with the 27th Asia-Pacific Software Engineering Conference (APSEC 2020)},
volume = {2767},
pages = {47-54},
publisher = {CEUR-WS},
abstract = {IT processes constitute the backbone of an integrated enterprise architecture (EA). The model thereof sustains the development and management of the EA. Nevertheless, the quality of such models tends to degrade over time due to, e.g. improper modeling practices or ineffective evaluation. In this regard, the knowledge of relevant modeling anti-patterns can help identify, mitigate, and prevent the occurrence of sub-optimal or adverse constructs in the model. In the field of business process modeling (BPM), a plethora of BPM anti-patterns has been defined and compiled in various taxonomies. However, these BPM anti-patterns mostly focus on technical issues, which thus are applicable for evaluating workflows but not EA-level processes. We strongly argue that the concept of process anti-pattern in EA domain can facilitate EA analyses on process-related issues. To address this gap, this paper presents a catalogue of 18 EA process modeling anti-patterns, which we derived from the existing BPM anti-patterns. Our result should serve as food for thought and motivation for future research in this context.},
keywords = {},
pubstate = {published},
tppubtype = {inproceedings}
}
IT processes constitute the backbone of an integrated enterprise architecture (EA). The model thereof sustains the development and management of the EA. Nevertheless, the quality of such models tends to degrade over time due to, e.g. improper modeling practices or ineffective evaluation. In this regard, the knowledge of relevant modeling anti-patterns can help identify, mitigate, and prevent the occurrence of sub-optimal or adverse constructs in the model. In the field of business process modeling (BPM), a plethora of BPM anti-patterns has been defined and compiled in various taxonomies. However, these BPM anti-patterns mostly focus on technical issues, which thus are applicable for evaluating workflows but not EA-level processes. We strongly argue that the concept of process anti-pattern in EA domain can facilitate EA analyses on process-related issues. To address this gap, this paper presents a catalogue of 18 EA process modeling anti-patterns, which we derived from the existing BPM anti-patterns. Our result should serve as food for thought and motivation for future research in this context.
Salentin, Johannes; Hacks, Simon
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.
@incollection{Salentin.2020,
title = {Towards a Catalog of Enterprise Architecture Smells},
author = {Johannes Salentin and Simon Hacks},
editor = {Norbert Gronau and Moreen Heine and K Poustcchi and H Krasnova},
url = {https://dx.doi.org/10.30844/wi_2020_y1-salentin},
doi = {10.30844/wi_2020_y1-salentin},
isbn = {9783955453367},
year = {2020},
date = {2020-03-23},
booktitle = {WI2020 Community Tracks},
pages = {276--290},
publisher = {GITO Verlag},
abstract = {Code Smells are well known in the domain of Technical Debt (TD). They hint at common bad habits that impair the quality of the software system. By detecting those smells it is possible to suggest a better solution or, at least, make the developers aware of possible drawbacks. However, in terms of Enterprise Architecture (EA), which is a more holistic view of an enterprise including TD, there does not exist such a concept of EA Smells.
Such EA Smells can be a component of EA Debt, working like a metric to rate the quality of data and estimate parts of the EA Debt in an EA Repository. The main goal of this work is to start the development of a catalog to facilitate future design and development of EAs. This catalog should be expanded and serve as food for thought to create a corresponding tool for the detection of smells.},
keywords = {},
pubstate = {published},
tppubtype = {incollection}
}
Code Smells are well known in the domain of Technical Debt (TD). They hint at common bad habits that impair the quality of the software system. By detecting those smells it is possible to suggest a better solution or, at least, make the developers aware of possible drawbacks. However, in terms of Enterprise Architecture (EA), which is a more holistic view of an enterprise including TD, there does not exist such a concept of EA Smells.
Such EA Smells can be a component of EA Debt, working like a metric to rate the quality of data and estimate parts of the EA Debt in an EA Repository. The main goal of this work is to start the development of a catalog to facilitate future design and development of EAs. This catalog should be expanded and serve as food for thought to create a corresponding tool for the detection of smells.
