Towards a Catalog of Enterprise Architecture Smells

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.

Introduction

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 [1, 2]. Technical Debt describes the delayed technical  development activities for getting short-term payoffs such as a timely release of a  specific 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  in another dimension and eventually resulted in higher costs to restore the health of the  system in future.

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.

Therefore, we have proposed to combine the concepts of EA (Enterprise  Architecture), which provides a holistic view on an organization, and the concept of  Technical Debt [7]. However, our definition still lacks a means to identify possible  debts. 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.

The main goal of EA Smells and their automated detection is to increase the quality  of EAs and the awareness for common bad habits. Therefore, EA Smells should 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 [9]. In a descriptive manner, the  actual status of the EA can be assessed and its development over time can be tracked.  With a catalog of EA Smells, 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 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

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:

What corresponding EA Smells can be defined based on the existing Code Smells  and anti-patterns?

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.

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.