Defining Thresholds for Enterprise Architecture Debts Measurements

Background

Technical Debt (TD) is a well-established concept in software development and means that a solution that is “quick and dirty” is applied in order to earn time in short term and be able to provide a function in a system more quickly. This primitive implementation will at a later stage need to be corrected and rewritten, and the longer it takes, the more advanced, complex and time-consuming the correction will be. According to Seaman et al., TD can be described as a situation where software developers accept compromises in one dimension to meet an urgent demand in another dimension. This will later on result in an increased cost to restore the system’s health in the future.

To date, the context of technical debt is still limited to the technical aspects. During the years TD has become more important in order for companies to be able to make investments in IT-systems to maintain competitiveness, efficiency and durability. Also, to realize all the benefits and potential in those investments it is of high importance to align IT and other business activities. Enterprise Architecture (EA) has emerged to solve the issues regarding business-IT misalignments. EA is a method used to control and describe how complex and dynamic organizations processes, structures, applications, systems and technology interrelates. EA provides an unambiguous specification of the components included and their relations which makes it useful to serve as a communication bridge between the IT department and other business departments. A common challenge in organizations is a perception of that different languages are spoken among IT and other departments, and EA can provide a possible solution to this problem. An EA model does not only describe the current or future situation of the business but can also be a useful tool when evaluating the transition from current to future scenarios.

As EA has grown major scientific and academic contributions, that can be adapted in broad spectrum, been developed. These include among others EA frameworks, EA management and EA tools. What is still missing is insight and ability to include a debt concept, which not only address TD but also business aspects. By adapting the TD concept in the EA domain, a new metaphor, providing a holistic perspective, has been proposed; Enterprise Architecture Debt (EAD). Hacks et al. define EAD as follows: ”Enterprise Architecture Debt is a metric that depicts the deviation of the currently present state of an enterprise from a hypothetical ideal state”. Up to the present debts for measuring EAD has been identified, but current research projects has not yet identified when a certain measure is to be considered of high or low quality. There is a need to develop a process for deriving such thresholds and identifying them.

Problem

EAD as a concept and metaphor can lay a foundation for a common language between IT-departments and other business departments within an organization when it comes to communicating potential design issues. Commonly there is a gap concerning different objectives and background among business and IT representatives in an organization. This can inevitably make it difficult to align IT with the rest of the organization. EAD, as an extension of TD, can play an important role in addressing this issue. To be able to get the most out of an organization, drive innovation and align objectives a common language is of high importance and to be able to communicate the severity of an EAD. Here thresholds for EAD measures plays an important role. These thresholds for EAD will in the long term play a role in providing a tool for computer scientist working in organizations exploiting EA, and also contribute to current research within the field of IT-management and EA that can be helpful for computer scientists doing research within these fields.

Research Question

The purpose and aim with this study are to identify thresholds for EAD measures by identifying different kinds of thresholds and detect how these could be codified, and also to map the process for identifying such measures and ascertain which of these EAD measure thresholds that are relevant for EA practitioners.

• RQ1: What different kinds of EAD measure thresholds exist?
• RQ2: Which EAD measure thresholds are of relevance for practitioners?
• RQ3: How can these thresholds be codified in a structured manner?
• RQ4: How does a process look like, that can be followed, to identify EAD measure thresholds?

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

@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}

}

@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}

}