{"id":115458,"date":"2026-11-11T18:41:40","date_gmt":"2026-11-11T17:41:40","guid":{"rendered":"https:\/\/industry-science.com\/?post_type=article&p=115458"},"modified":"2026-11-11T18:42:22","modified_gmt":"2026-11-11T17:42:22","slug":"towards-a-catalog-of-enterprise-architecture-smells","status":"publish","type":"article","link":"https:\/\/industry-science.com\/en\/articles\/towards-a-catalog-of-enterprise-architecture-smells\/","title":{"rendered":"Towards a Catalog of Enterprise Architecture Smells"},"content":{"rendered":"\n

Abstract.<\/strong> <\/p>\n\n\n\n

Code Smells are well known in the domain of Technical Debt (TD). \u00a0They hint at common bad habits that impair the quality of the software system. \u00a0By detecting those smells it is possible to suggest a better solution or, at least, \u00a0make the developers aware of possible drawbacks. However, in terms of \u00a0Enterprise Architecture (EA), which is a more holistic view of an enterprise \u00a0including 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 \u00a0the quality of data and estimate parts of the EA Debt in an EA Repository. The \u00a0main goal of this work is to start the development of a catalog to facilitate future \u00a0design and development of EAs. This catalog should be expanded and serve as \u00a0food for thought to create a corresponding tool for the detection of smells.<\/p>\n\n\n\n

Introduction<\/strong><\/p>\n\n\n\n

In the software development industry, Technical Debt is regarded as a critical issue in \u00a0terms of the negative consequences such as increased software development cost, low \u00a0product quality, decreased maintainability, and slowed progress to the long-term \u00a0success of developing software [1, 2]. Technical Debt describes the delayed technical \u00a0development activities for getting short-term payoffs such as a timely release of a \u00a0specific software [3]. Seaman et al. [4] described Technical Debt as a situation in which software developers accept compromises in one dimension to meet an urgent demand \u00a0in another dimension and eventually resulted in higher costs to restore the health of the \u00a0system in future.<\/p>\n\n\n\n

Furthermore, Technical Debt is explained as the effect of immature software  artifacts, which requires extra effort on software maintenance in the future [5]. While  the Technical Debt metaphor has further extended to include e.g. database design debt,  which describes the immature database design decisions [6], the context of Technical  Debt is still limited to the technological aspects.<\/p>\n\n\n\n

Therefore, we have proposed to combine the concepts of EA (Enterprise \u00a0Architecture), which provides a holistic view on an organization, and the concept of \u00a0Technical Debt [7]. However, our definition still lacks a means to identify possible \u00a0debts. To close this gap, we suggest transferring the concept of Code Smells to the domain EA Debts. Transferring a concept from the software architecture domain to the  EA domain seems obvious, as they share some terminology, concerns, and notations  [8]. Nonetheless, they focus on different domains (business vs. system) and,  consequently, have fundamentally different stakeholders with different perspectives  and viewpoints [8]. Accordingly, we will elaborate on aspects both domains have in  common, especially structural aspects.<\/p>\n\n\n\n

The main goal of EA Smells and their automated detection is to increase the quality \u00a0of EAs and the awareness for common bad habits. Therefore, EA Smells should reflect \u00a0quality flaws in the EA itself. However, if the EA model is used as an input to determine \u00a0the EA Smell, the smell might only appear in the model and not in reality, based on the \u00a0on the degree of how the model reflects the reality. Further, EA Smells can be \u00a0considered in a prescriptive or descriptive manner. For prescriptive purposes different scenarios of evolution can be compared to each other [9]. In a descriptive manner, the \u00a0actual status of the EA can be assessed and its development over time can be tracked. \u00a0With a catalog of EA Smells, developers can rely on it during the design process or \u00a0even afterwards while doing performance monitoring to assess the quality of data in \u00a0EA repositories. Sophisticated tools for automated detection can then provide a \u00a0convenient risk detection with built-in solution suggestions.<\/p>\n\n\n\n

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. This represents a  valuable usage of the EA Debt concept, even though EA Smells are just a subset of the  overall EA Debt, which will influence the popularity of those ideas in a positive way,  resulting in encouragement. 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<\/p>\n\n\n\n

In order to define EA Smells and develop a first program for automated detection,  there are some steps, which must be considered. Our research questions will guide the  process of finding suitable answers to the open problems and structure the course of  action:<\/p>\n\n\n\n

What corresponding EA Smells can be defined based on the existing Code Smells  and anti-patterns?<\/em><\/p>\n\n\n\n

Then EA Smells can be defined in a catalog based on their counterparts in Code  Smells and a procedure is elaborated to detect some smells automatically in  representative EA repositories.<\/p>\n\n\n\n

The rest of this work is structured as follows: First, we sketch the applied research  design. Next, we present the basic concepts that we will use to create a catalog of EA  Smells, namely Code Smells and EA Debt. Afterwards, we introduce our EA Smells  catalog by presenting the overall representation and giving some exemplary EA Smells  we discovered. Those EA Smells serve as input for our prototype that allows identifying  EA Smells in ArchiMate models. Before we conclude our work, we give an overview  regarding related work.<\/p>\n

Your downloads<\/h2>