We are happy to see the first article in the domain of EA Debt being published. It results from two
Technical Debt is explained as the effect of immature software artifacts, which requires extra effort on software maintenance in the future. While the Technical Debt metaphor has further extended to include e.g. database design debt, which describes the immature database design decisions, the context of Technical Debt is still limited to the technological aspects. Therefore, we have proposed to combine the concepts of EA, which provides a holistic view on an organization, and the concept of Technical Debt as EA Debts. However, our definition still lacks a means to identify possible debts.
To close this gap, we suggested transferring the concept of Code Smells to the domain of EA Debts. The main goal of EA Smells and their automated detection is to increase the qualityof EAs and the awareness for common bad habits. Therefore, EA Smells reflect quality flaws in the EA itself. However, if the EA model is used as an input to determine the EA Smell, the smell might only appear in the model and not in reality, based on the on the degree of how the model reflects the reality.
Further, EA Smells can be considered in a prescriptive or descriptive manner. For prescriptive purposes different scenarios of evolution can be compared to each other. In a descriptive manner, the actual status of the EA can be assessed and its development over time can be tracked.
We developed a catalog of EA Smells, on that developers can rely on it during the design process or even afterwards while doing performance monitoring to assess the quality of data in EA repositories. Sophisticated tools for automated detection can then provide a convenient risk detection with built-in solution suggestions.
EA Smells are an indicator or symptom of EA Debt, working like a metric to rate the quality of data and estimate parts of the EA Debt in an EA Repository. This represents a valuable usage of the EA Debt concept, even though EA Smells are just a subset of the overall EA Debt. For example, such an EA Smell could be a bloated service that has one large interface with many parameters or requires much data and performs mostly heterogeneous operations with low cohesion.
Above figure illustrates three examples of EA Smells in an EA model. Firstly, a Cyclic dependency in which three services build on each other. Secondly, a Dead Component, which has no relations to the rest of the model. Lastly, a Strict Layers Violation where elements of the business layer are directly linked to an element of the technology layer.
Determining Enterprise Architecture Smells from Software Architecture Smells Proceedings Article
In: 2021 IEEE 23rd Conference on Business Informatics (CBI), pp. 134-142, IEEE, 2021.
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.