=Paper=
{{Paper
|id=Vol-3062/paper09
|storemode=property
|title=Towards a Catalog of Refactoring Solutions for Enterprise Architecture Smells
|pdfUrl=https://ceur-ws.org/Vol-3062/Paper09_QuASoQ.pdf
|volume=Vol-3062
|authors=Lukas Liss,Henrik Kämmerling,Peter Alexander,Horst Lichter
|dblpUrl=https://dblp.org/rec/conf/apsec/LissKAL21
}}
==Towards a Catalog of Refactoring Solutions for Enterprise Architecture Smells==
https://ceur-ws.org/Vol-3062/Paper09_QuASoQ.pdf
Towards a Catalog of Refactoring Solutions for Enterprise
Architecture Smells
Lukas Liss1 , Henrik Kämmerling1 , Peter Alexander1 and Horst Lichter1
1
RWTH Aachen University, Research Group Software Construction, Ahornstrasse 55, Aachen, Germany
Abstract
The model of enterprise architecture (EA) is often a primary means of steering the business-IT development. It helps to
ensure EA qualities in many ways, including identification of weaknesses in an EA or the signs thereof. Such weaknesses
have been addressed through the study of EA smell, which focuses on common bad habits in EA practices. Although EA
smell problems have been described in various contexts, current solutions lack the basis of evidence and practical details that
are necessary for their adoption. Therefore, this study seeks to gain new insights into the solution domain of EA smells by
exploring current knowledge about refactoring solutions. We present our findings in a catalog of EA refactoring solutions
intended to serve as food for thought for future research directions.
Keywords
enterprise architecture, enterprise architecture smell, refactoring solution
1. Introduction current knowledge about refactoring solutions to find
further evidence about EA refactoring solutions and new
The model of enterprise architecture (EA) greatly sup- ways of approaching them.
ports sustainable management of complex IT landscapes. Considering that current EA smells were derived from
It provides insights into the current implementations and code smells, we argue that exploring known code refac-
future orientations of the EA developed, thereby provid- toring solutions can result in meaningful insights into
ing a reasoning basis for important decisions. Neverthe- the refactoring solutions for EA smells. Therefore, based
less, the maintenance of the EA model is often pushed on the code smells used in EA smell studies, we first
down the priority list due to, e.g., lack of resources or searched for relevant code refactoring solutions in major
supporting methods. Flaws and deficiencies in the EA code smell and refactoring catalogs. The code refactor-
may remain ignored and create barriers to EA evolution ing solutions collected were then used to answer the
known as EA debt [1]. To prevent such tendencies, prac- following research questions (RQ):
tical methods for supporting the continuous evaluation
and improvement of EA models are needed. RQ 1 What EA refactoring solutions can be derived
Using EA models to guide the improvement of EA qual- from the existing code refactoring solutions?
ities has been proposed by some studies. Salentin and
Hacks coined the concept of EA smell to address common RQ 1.1 How to derive insights about EA refactoring
bad habits in EA practices and derived EA smells [2] by from analyzing code refactoring solutions?
transferring known code smells into the context of EA. RQ 1.2 What attributes can describe an EA refactoring
Lehmann et al. made a similar attempt to derive process solution?
modelling anti-patterns for EA analyses [3] by transfer-
ring known workflow anti-patterns into the context of RQ 2 How can EA practitioners and researchers benefit
EA. Both of these studies suggest, among others, some so- from knowing about EA refactoring solutions?
lutions to refactor the problems they identify. However,
existing descriptions of these solutions lack the basis of The remainder of this paper is structured as follows:
evidence and practical details that are necessary for their Section 2 gives an overview of studies related to refac-
application. This study therefore focuses on exploring toring solutions. Section 3 describes our methodology
for deriving and documenting refactoring solutions for
QuASoQ 2021: 9th International Workshop on Quantitative EA smells. Section 4 presents the resulting EA refactor-
Approaches to Software Quality, December 06, 2021, Taipei, Taiwan
Envelope-Open lukas.liss@rwth-aachen.de (L. Liss);
ing solutions mapped to the corresponding EA smells.
henrik.kaemmerling@rwth-aachen.de (H. Kämmerling); Section 5 demonstrates some small practical examples of
alexander@swc.rwth-aachen.de (P. Alexander); using EA refactoring solution for mitigating EA smells.
lichter@swc.rwth-aachen.de (H. Lichter) Section 6 discusses our finding, its implications, and the
Orcid 0000-0001-6534-278X (P. Alexander); 0000-0002-3440-1238 threats to its validity. Section 7 motivates future research
(H. Lichter)
© 2021 Copyright for this paper by its authors. Use permitted under Creative directions and concludes this paper.
Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
60
2. Related Work ness, application, and/or technology architecture. This
scope was recently expanded by the exploration into EA
The concept of refactoring has been developed to sup- process anti-pattern, which resulted in 18 EA smells for
port software design and evolution, specifically to rec- process-related issues [3]. As the interest in EA smell
tify design flaws and improve software quality through research is growing, more EA smells will continue to be
restructuring plans while preserving the observable be- identified through new explorations into other aspects
havior. The term ’refactoring’ can be used in different of EA, such as management.
ways, namely ’refactoring’ (noun) to mention the restruc-
turing applied to a software [4], ’to refactor’ (verb) to
mention the activity of restructuring a software [4], or 3. Methodology
’refactoring solution’ to mention a possible technique for
restructuring a software (e.g. [5]). For the sake of clarity, This study uses the design science research (DSR) method-
these ways of usage are applied in this paper. ology according to the guidelines proposed by Peffers
After being extensively used in programming domains, et al. [21] and Hevner et al. [22]. A DSR aims to devise
such as the procedural programming (e.g. [6]), object- an artifact that addresses a ”heretofore unsolved and im-
oriented programming (e.g. [5]), and functional program- portant business problem” by drawing on the existing
ming (e.g. [7]), the concept of refactoring has been ex- knowledge, and the resulting artifact must be rigorously
plored in a wider spectrum of software engineering. In evaluated in terms of its ”utility, quality, and efficacy” and
the domain of software modelling, the concept of model effectively communicated to relevant audiences. With
refactoring was introduced to enable restructuring plans respect to the DSR guidelines above, this study follows
on the high-level description of software [8]. The aim of the six main steps of DSR as listed below.
model refactoring can be twofold: to allow for an earlier 1. Problem identification and motivation. Define
(i.e. at the design stage) and easier (i.e. reduced com- the specific research problem and justify the value of
plexity) refactoring of software; or to improve semantic the solution proposed
and syntactic quality measures of the model. Whichever
aim is set, model refactoring should preserve both the 2. Solution objective definition Infer the objectives
behavior of the modelled software and the semantic of of the solution proposed from the problem definition
the model. and knowledge of what is possible and feasible
Studies of model refactoring have varied in their focus,
whether it be on a specific modelling language or par- 3. Design and development. Create the artifact
ticular architectural aspect. Modelling languages such 4. Demonstration. Demonstrate the use of the artifact
as the object constraint language (OCL), unified mod- to solve one or more instances of the problem
elling language (UML), and web ontology language have
been studied and supported with designated refactoring 5. Evaluation. Observe and measure how well the arti-
solutions [9] [10] [11]. Architectural aspects such as fact supports a solution to the problem
process aspect, data aspect, and style aspect have also
been analyzed in this context to support a comprehensive 6. Communication. Communicate the problem and
architecture restructuring [12] [13] [14]. Furthermore, its importance, the artifact, its utility and novelty, the
the so-called large refactorings have been proposed to rigor of its design, and its effectiveness to researchers
deal with refactoring in complex projects, specifically and other relevant audiences
when changing significant parts of a system, which often The following subsections describe the process and meth-
takes longer than a day [15]. Still, there are growing ods employed in this study with respect to the steps
possibilities to explore new refactoring solutions for new above.
design anomalies, especially with the growing interest in
bad smell research—which focuses on detecting concrete
indication of the need for refactoring [4]. 3.1. Problem identification and
The concept of bad smell has been adopted in the do- motivation
main of EA and referred to as EA smell, which represents Despite current results in EA smell research (as presented
negative examples and bad habits that, when ignored, in section 2), the identification of EA smells is never an
may harm the performance of EA activities or even the end in itself. The identified EA smells should, e.g., in-
organization as a whole [2]. The concept was proposed form the decisions for imposing suitable EA improvement
together with a catalog of 45 EA smells, which describes measures with regards to the current circumstances and
(among others) the problem contexts, applicable detec- interests. To reason such decisions, enterprise architects
tion methods, and possible mitigation solutions. Based need to first understand the applicability of each solu-
on the scope of occurrence, an EA smell can be of the busi- tion alternative through evidence and practical details,
61
UML → ArchiMate Source UML → ArchiMate Source
Activity → Interaction, Function, Pro- [16, 17, 18] Interface → Interface, Service [19, 16, 17, 20,
cess 18]
Actor → Actor, Role [19, 16, 17, 20] Method → Application/Infrastructure [16]
Artifact → Artifact, Contract, Deliver- [19, 16, 17, 20] Function, Infrastructure Service
able, Gap, Product, Representation Note/Comment → Meaning, Represen- [18]
Association → Association, Aggregation, [17, 20, 18] tation
Composition Node → Node, Communication Path, De- [19, 16, 17, 20]
Class → Actor, Collaboration, Compo- [19, 16, 20, 18] vice, Infrastructure Interface, Location,
nent, Data Object, Meaning, Motiva- Network, System Software
tional Concepts, Object, Plateau, Repre- Object → Object, Contract, Data Object, [16]
sentation, Role, Stakeholder, Value Meaning, Product, Representation, Value
Collaboration → Collaboration, Func- [19, 16, 17, 20, Opaque Behavior → Application Inter- [20]
tion, Interface, Location 18] action, Business Event, Business Interac-
Component → Component, Grouping [19, 16, 17, 20] tion, Business Process, Junction, Work
Communication Path → [17, 20, 18] Package
Communication Path, Network Swimlane → Actor, Business Service, [16]
Dependency → Assignment, Derived, In- [17, 20] Role
fluence, Serving/Used by Usage → Access, Serving/Used By [20]
Device, Event, Execution Environ- [19, 16, 17, 20] Use Case → Business Function, Business [19, 16, 17, 20]
ment → Device, Event, System Software Interaction, Requirement, Service
Generalization → Specialization [19, 20, 18] Realization, Composition, Aggrega- [19, 17, 20, 18]
Information Flow → Flow, Triggering [20] tion → Realization, Composition, Aggre-
Interaction → Interaction, Application [16, 18] gation
Service, Event, Function, Process
Table 1
A mapping from UML to ArchiMate
which are still lacking in the hitherto solution suggestions 3. Allow the EA community to obtain an up-to-date
for EA smell mitigation. Furthermore, current knowl- overview of results in EA refactoring research and
edge about the refactoring of architectural smells focuses contribute to the its development
on rather technical aspects (i.e. software architecture),
which are hardly applicable for evaluating and evolv- 3.3. Design and development
ing an EA. Therefore, we argue that EA research should
pursue the identification of possible EA refactoring so- Since the first EA smells were derived from code smells
lutions to guide enterprise architects in finding possible [2], we assume that refactoring solutions for code smells
and feasible solutions for the EA smell problems at hand. may hold some clue to the refactoring solutions for EA
smells. This assumption leads to the design of our method-
ology, which includes three main steps: Concept analysis,
3.2. Solution objective definition
concept mapping, and concept transformation.
Considering the problem described above, this study aims
to devise the concept of EA refactoring solution by draw- Concept Analysis. Our first step is to collect relevant
ing on the existing knowledge about refactoring. To code refactoring solutions for the code smells used by
guide the solution design and development, this study existing studies on EA smells [2]. Our analysis covered
sets the following solution objectives: some existing code smells or anti-patterns catalogs (i.e.,
[4], [23], and [24]). While we are aware that ”the presence
1. Support enterprise architects in finding appropriate
of code smells does not imply the presence of architec-
solutions to a certain EA smell by identifying possible
tural smells and vice versa,” [25], we argue that some
EA refactoring solutions and providing clear descrip-
problematic design patterns addressed by code smells
tions about their context and implementation
or anti-patterns (e.g. cyclic dependency or duplication)
2. Support enterprise architects in communicating rele- may also occur in EA context. Furthermore, the practice
vant EA refactoring solutions in a consistent manner of transferring existing concepts into a different domain
by identifying relevant attributes and providing a stan- has been performed to generate first ideas within a new
dard documentation template problem domain and inspire further research (e.g. [2],
[3]).
62
Attribute Meaning
Name Gives the refactoring solution a meaningful designator
Connected EA Smells Links the refactoring solution to the targeted EA smells
Derived from Names the code refactoring solution from which this refactoring solution is derived
Summary Gives a brief overview of this refactoring solution
Intent Describes the main goal of this refactoring solution
Motivation Describes the reasons of applying this refactoring solution
Prerequisites Describes the conditions prior to applying this refactoring solution
Impact Describes the influence of this refactoring solution to EA qualities
Mechanics Describes the practical steps to apply this refactoring solution
Discussion Describes the situations when this refactoring solution can be useful
Graphical example Shows a graphical representation of the refactoring solution to reduce misinterpretations
Table 2
Attributes of EA refactoring solutions (adapted from [4], [26], and [27]).
Concept Mapping. The second step in our method- of UML and ArchiMate is proposed by Gericke, which
ology is to establish a mapping between the concepts in also considers ArchiMate concepts under the motivation
code and EA modelling, which should serve as a basis for layer [20]. Table 1 summarizes all these mappings which
conceptually transforming the code refactoring solutions we use as a basis to conduct the concept transformation.
collected into EA refactoring solutions.
Although the code and the EA lie on two opposite sides Concept Transformation. To finally derive EA refac-
in the spectrum of abstraction, the languages used for toring solutions, the code refactoring solutions collected
modelling them share a good deal of similar constructs in are processed as follows:
that both support the description of architectural aspects.
Previous studies have proposed some mappings between • We analyzed the descriptions and examples of code
the notations of UML and ArchiMate, which are the most refactoring solutions to identify instances of UML con-
used languages for code and EA modelling, respectively. cepts and relationships. Based on the mapping of UML
Some of these mappings are described in the ArchiMate and ArchiMate notations shown in table 1, the iden-
specification [17]—as some notations thereof are indeed tified UML constructs are translated into ArchiMate
derived from UML [19]—, while the rest have been exclu- constructs. Since each UML notation does not neces-
sively suggested by the studies. Since most code refactor- sarily map exclusively with one ArchiMate notation
ing solutions have been described and exemplified using (e.g. both Collaboration and Interface in UML
UML, we strongly argue that such mappings can guide can be translated into Interface in ArchiMate), the
the transformation of code refactoring solutions into EA translation has to be inferred rationally from our un-
refactoring solutions. derstanding of what solution is possible and feasible
We believe that the first mapping between the con- for the EA smell addressed.
cepts in UML and ArchiMate was proposed by Wiering
et al. [18]. Their study focuses on identifying matching • In some cases, the translation may not directly result in
concepts and relationships by comparing the notations an ArchiMate construct that conveys a valid solution in
in the two languages by the properties thereof. Another the context of EA. Such ArchiMate construct is either
attempt was made in a study by Gill, which focuses on modified for a reasonable EA refactoring solution or
finding concepts in other modelling languages beside excluded from consideration.
ArchiMate which are applicable for EA modelling [16].
Because of the manual concept transformation in this
The resulting contribution includes a mapping of some
process, the outcome is highly influenced by the skill,
concepts in UML to ArchiMate. Furthermore, Lankhorst
knowledge, and experience of the researchers. Also, since
also advocate the use of ArchiMate in conjunction with
the mapping used gives more than one matching Archi-
other modelling languages (including UML) to create a
Mate notations for every UML notation, the resulting
more holistic EA description [19]. To support this in prac-
translation may vary depending on the researcher’s own
tice, this contribution highlights not only the similarities
understanding and interpretation of the two modelling
but also important differences in ArchiMate and UML, e.g.
languages (UML and ArchiMate).
the absence of separate concepts for service and interface
as well as the reverse interpretation of the ArchiMate
relationship serving in UML. Lastly, another mapping
63
EA smell → EA refactoring solutions EA smell → EA refactoring solutions
Ambiguous Viewpoint → 5 Viewpoints Jumble → Architecture Partitioning
Architecture by Implication → Goal Question Architecture Lazy Component → Ghostbusting or Inline Service
Big Bang → Process Manager Message Chain → Process Manager or Extract & Move Data
Bloated Service → Merge input Object
Business Process Forever → Process Manager Missing Abstraction → Add Abstraction
Chatty Service → Front End Gate Multifaceted Abstraction → Split Phase
Combinatorial Explosion → Extract Shared Functionality Nanoservices → Front End Gate
Connector Envy → Extract Component No Legacy → Process Manager
Cyclic Dependency → Cyclic Dependency Removement Nothing New → Process Manager
Data-Driven Migration → Functionality First, Data Last Overgeneralization → Extract Shared Functionality
Data Service → Encapsulate Data Service Sand Pile → Grouping
Dead Component → Remove Dead Component Scattered Parasitic Function → Merge Components
Deficient Encapsulation → Break Up Component Shared Persistency → Encapsulate Business Objects
Deficient Names → Rename Component Shotgun Surgery → Grouping
Dense Structure → Complexity Reduction Stovepipe System → Architecture Framework or EA Planning
Documentation → Rename Component Strict Layers Violation → Move Service to Different Layer
Duplication → Extract Shared Functionality Temporary Solution → Extract Temporary Solution
Feature Envy → Move Component or Front End Gate The God Object → God Object Decomposition
Golden Hammer → Boundaries The Shiny Nickel → Plan Ahead
Hub-like Modularization → Break Up Component Vendor Lock-In → Isolation Layer
Incomplete Abstraction → Grouping Warm Bodies → Small Project
Incomplete Node or Collaboration → Introduce Local Exten- Weakened Modularity → Split Modularity
sion Wrong Cuts → Reorganization
Inconsistent Versioning → Semantic Versioning
Table 3
Catalog of EA Refactoring Solutions
3.4. Demonstration 3.5. Evaluation
In this DSR step, the use of the artifact is demonstrated The evaluation step in DSR aims to review the effective-
to solve one or more instances of the problem [21]. The ness of the artifact proposed in supporting a solution to
fundamental questions to be answered are, ”What utility the problem [21]. In this paper, this step is embodied in
does the new artifact provide?” and ”What demonstrates a discussion, in which we explain how the main RQs of
that utility?” [22] In the context of this study, the EA this study have been answered based on our findings and
refactoring solutions proposed should provide solution their demonstration. Since the discussion presented in
alternatives for mitigating EA smells and the practical this paper is focused only on the qualitative performance
details needed to understand their feasibility as well as of EA refactoring solution within our example scenario,
relevance according to the current conditions. Therefore, we recommend future research to extend the evaluation
to demonstrate the applicability of our result for solving by including more (real-world) examples and quantifiable
the problems described in section 3.1, we illustrate some measures (e.g. using EA model quality framework [28]).
small scenarios of mitigating EA smells using the EA
refactoring solutions proposed. For this purpose, we use 3.6. Communication
a small ArchiMate model which contains some EA smells.
Then, we identify candidates of EA refactoring solutions Finally, the communication step focuses on presenting
and select one that we deem the most appropriate for the the artifact proposed, its utility, and its effectiveness to
EA smell given. It is worth noting that the systematic ap- researchers and other relevant audiences. [21] To commu-
proach to prioritizing EA refactoring solution candidates nicate our results in an intuitive and consistent manner,
is still a subject to future work; hence, the selection of we document the EA refactoring solutions in a standard
EA refactoring solution demonstrated in this paper relies template (see table 2) which we adapted from some exist-
on the authors’ perspectives. Finally, we elaborate the ing templates of refactoring solution used in [4] [26] [27].
architectural changes suggested by the EA refactoring Furthermore, the EA refactoring solutions are categorized
solution selected, show the resulting ArchiMate model based on the domains of the corresponding EA smells
after applying these architectural changes, and discuss (i.e. business, technology, and application domains) [2]
the impact on the ArchiMate model’s overall quality. and made publicly available on a web page [29].
64
Name Process manager Encapsulate Business Objects
Description This refactoring increases the user orientation of service Route data access through dedicated data
interfaces with the goal to enable user involvement in services that encapsulate the needed busi-
business processes. A process manager that realizes the ness objects.
service calls is created. Previous caller of the process call
the process manager now with process control data that
parameterizes the wanted process.
Connected EA Business Process Forever, Big Bang, Nothing New, No Shared Persistency
smell Legacy
Derived from Process Manager Encapsulate Variable
Intent Create a process manager component which orchestrates Narrow down the data visibility by routing
the components involved in the process. data access through dedicated data services.
Motivation This refactoring is meant to create a better user involve- Reduce the likeability that teams unwillingly
ment. It also adds more flexibility and extensibility to the depend on each other because the visibility
architecture. of the data is too broad.
Prerequisites A long, very strict process chain with many different Multiple business services that access the
stakeholders involved. same database.
Impact This refactoring makes the application service interfaces The structure created by the refactoring re-
more user oriented which enables the user involvement duces data visibility to only those of the
in business processes. owned business objects, thereby prevent-
ing any unwanted interdependence between
teams and services.
Mechanics 1. Generate a new service P called the Process Manager 1. Create a new data service that will contain
2. Add a service call from P to all the process components the dedicated data services
of the Process manager 2. For each business service, create a dedi-
3. All calls to the individual process components calls cated data service that routes the access to
now the Process Manager with process control data C the database. Test each data service.
that parameterize the wanted original Process. Test each 3. Move the database into the grouping data
call individually. service.
4. Remove the service calls between the services that
belong now to the Process Manager P
Discussion This is not only a refactoring but also an architecture The data visibility is very narrow when using
pattern itself. It can be used to generate more online this refactoring which reduces unwanted de-
involvement for everyone that should be involved. In pendencies between teams.
a peer-to-peer system it is usually not desired to have
many centralized services, so the process manager needs
to be evaluated carefully.
Table 4
Documentation of the Process Manager and Encapsulate Business Objects EA refactoring solutions
4. Result Furthermore, the catalog also suggests multiple EA
refactoring solution candidates for some EA smells, such
As a result, this study yields a catalog of 37 EA refactoring as the Move Component and Front End Gate which are
solutions for all 45 EA smells proposed in [2] (see table 3). suggested as solution candidates for mitigating the Fea-
In the catalog, some EA refactoring solutions are sug- ture Envy EA smell. Such result is obtained because we
gested for multiple EA smells, such as the Process Man- identified different studies which suggest different code
ager EA refactoring solution which is suggested for the refactoring solutions for the same code smell. While we
Big Bang, Business Process Forever, Message Chain, are aware that the selection of an appropriate EA refactor-
No Legacy, and Nothing New EA smells. Such result ing solution should consider the specific circumstances
is obtained because some code refactoring solutions– surrounding the EA smell problem, such specific circum-
from which we derived EA refactoring solutions–have stances are beyond the scope of this study. Therefore, we
also been suggested for mitigating various code smells. suggest future studies in this context to investigate the
While we are aware that specific adaptations may be nec- possibility to systematically prioritize all EA refactoring
essary to make one kind of solution works for different solutions recommended for a certain EA smell. In such
problems, the catalog currently provides only a general a prioritization approach, various quality requirements
description of how to apply each EA refactoring solution. may be considered, such as scalability and extensibility.
Describing such adaptations is a subject to future work.
65
Figure 1: EA refactoring demonstration, showing before (left) and after (right) refactoring EA smells in an ArchiMate model
5. Demonstrating EA Refactoring modules that are accessible through external interfaces.
Afterwards, a process manager must be implemented (in
Solutions this case, the customer information service) which re-
In order to illustrate the application of the proposed EA ceives requests for customer information processing and
refactoring solutions, we performed an experiment to ap- fulfills these by delegating tasks to the available services.
ply EA refactoring solutions on a small ArchiMate model The second EA smell (i.e. shared persistency) is de-
(see fig. 1), which we adapted from [2]. This ArchiMate tected when multiple services access the same data collec-
model contains two EA smells: First, a message chain due tion or schema, thereby reducing team and service inde-
to the sequential calls over 5 application services to fulfill pendence [30]. For this, our catalog proposes the encap-
the same application process (i.e. customer registra- sulate business objects refactoring solution (adapted
tion). Second, a shared persistency because of the direct from ’encapsulate variable’ in [4]), as presented in table 4.
relations between 3 application services and a database This refactoring solution suggests to route accesses to the
management system (i.e. DBMS). DBMS through dedicated data services; each of which
The first EA smell (i.e. message chain) occurs when at encapsulates all business objects required by one applica-
least 5 services sequentially interact to fulfill a process, tion service. This structure reduces data visibility to only
which may harm availability and evolvability [30]. To those of the owned business objects, thereby preventing
solve this, our catalog (see table 3) proposes two possi- unwanted interdependence between teams and services.
ble EA refactoring solutions, i.e. the process manager
(inspired from ’process manager’ in [31]) and extract
and move data object (adapted from ’extract and move
6. Discussion
class’ in [4]). To select from several possible refactoring In this section, we describe the extent to which the main
solutions, the architect must first evaluate whether the RQs (see section 1) of this study have been answered
main idea and practical details thereof suit the context through our finding and its demonstration; elaborate the
of the subjected EA smell. In the presented ArchiMate implications of the EA refactoring solutions identified
model, we assume that the exemplified message chain for researchs and practitioners; and identify the potential
does not stem from data but process architecture issues. threats to the internal and external validity of our result.
Therefore, the process manager is chosen, as presented
in table 4.
The chosen refactoring solution suggests to restruc- 6.1. Explanation of the Result
ture the collaboration scheme between the chained ser- With regards to answering the RQ1 and its sub-questions,
vices into an orchestration scheme—in which one service this study identifies the first catalog of EA refactoring so-
acts as a ’process manager’ that coordinates independent lutions for all the EA smells proposed in [2]. We achieved
services to fulfill the requested business process. This this result by performing a conceptual transformation
scheme eases the maintenance and extension of the sup- on relevant code refactoring solutions, which relies on a
ported business process, thereby remediating the avail- mapping between code and EA modelling concepts. To
ability and evolvability issues posed by the message chain. document the resulting EA refactoring solutions, we use
In our ArchiMate model, this refactoring solution is ap- a template of attributes which we adapted from some
plied by first encapsulating all involved operations across existing templates in code refactoring domain. Finally,
the chained application services into independent activity we demonstrated the use of several refactoring solutions
66
in some small scenarios of EA smell. While the solution the mapping used in this study. Last but not least, the pro-
choices demonstrated may not be suitable to all cases in cess of transforming code refactoring solutions into EA
reality, we believe that the presented catalog provides a domain relies on subjective analysis, which potentially
useful platform for EA researchers and practitioners to results in biased considerations upon deriving the EA
develop new or better refactoring solutions to common refactoring solutions. To reduce the bias, the resulting EA
problems in EA. refactoring solutions were reviewed and decided among
the authors of this paper. Despite these weaknesses, we
6.2. Implication for Practitioners & believe that the resulting EA refactoring solution cata-
log is a step in the right direction towards solutions for
Researchers common design issues in EA.
Recent study in EA has proposed the concept of EA debt
[1] which represents the divergent EA evolution from External validity. As the resulting EA refactoring so-
the EA standards and principles. One possible source of lutions are yet to be evaluated in industrial context, their
EA debt is the implementation of sub-optimal solution descriptions may still rather hypothetical and theoretical,
design. The role of EA smells is to indicate the signs of thereby posing challenges to their adoption. Further-
existing sub-optimal solutions within the IT landscape, more, as there could be multiple solution alternatives for
so that further investigation can be triggered in time [2]. every EA smell, further research is still needed to identify
With regards to answering the RQ2, the implication of possible factors and conditions which influence the suit-
our result can be seen from both practical and research ability of a certain EA refactoring solution. Finally, the
perspectives. For EA practitioners, the proposed EA adoption of EA refactoring solutions greatly depends on
refactoring solutions may help to find possible methods the progress in EA smell research. At the time of writing,
or techniques for solving the EA smells identified. Also, the existing EA smells are yet to be evaluated and their
such a solution catalog can help to establish common ter- descriptions enriched with practical examples.
minologies within an organization, thereby supporting
various stakeholders to discuss possible solutions.
For the EA research community, our result gives mo- 7. Conclusion & Future Work
tivation and food for thought for further investigations
Our main goal is to support EA practitioners in analyz-
into the concept of EA refactoring. Future attempts to
ing possible improvements with regards to the current
extend the catalog by transforming refactoring solutions
circumstances and interests. We strongly argue that ap-
from other domains (e.g. process smell, infrastructure
proaches to EA improvement must extend from EA mod-
smell, etc) may also adopt the conceptual transformation
elling capabilities. Therefore, this study investigates the
methodology used in this study. To allow public contri-
concept of refactoring in the context of EA modelling.
butions in the development of EA refactoring solutions,
Our methodology focuses on defining EA refactoring so-
the catalog has been published in a website together with
lutions for the EA smells proposed in [2] by analyzing the
a guideline on contributing [29].
known associations between code refactoring solutions
and code smells. The resulting contribution is a catalog
6.3. Threats to Validity of EA refactoring solutions which is publicly available
The results of this study have to be seen in the light on a web page [29].
of some limitations. In this section, we present an as- In spite of this progress, there is still work to be done,
sessment of possible threats to the internal and external especially in improving the catalog, or where further
validity of our result. Internal validity focuses on the work is necessary. Some potential future works in this
reliability of the result within the given environment, context are as follows: Firstly, further EA refactoring
whereas external validity focuses on the ability to gener- solutions can be derived for EA smells from different
alize the result [32]. domains, such as the EA process smells [3]. For such
purpose, we suggest to adapt the methodology from the
one used in this study, e.g. by integrating a mapping
Internal Validity. The design of our methodology may
of ArchiMate to another modelling language of interest
pose certain threats to the internal validity of our result.
as proposed in [16]. Secondly, empirical studies can be
Firstly, the code refactoring solutions analyzed were col-
performed to further review and improve the hitherto
lected from a selection of relevant books on code smell
knowledge in this area. Last but not least, tool supports
and refactoring, thereby threatening the completeness
can be developed for, e.g., recommending suitable EA
of the EA refactoring solution catalog. Secondly, the
refactoring solutions (e.g. [33]) or supporting the imple-
mapping between UML and ArchiMate notations used
mentation thereof.
in the transformation was summarized from some se-
lected sources, thereby threatening the completeness of
67
References [9] J. Reimann, C. Wilke, B. Demuth, M. Muck, U. Aß-
mann, Tool supported OCL refactoring cata-
[1] S. Hacks, H. Höfert, J. Salentin, Y. C. Yeong, logue, in: M. Balaban, J. Cabot, M. Gogolla,
H. Lichter, Towards the definition of enterprise C. Wilke (Eds.), Proceedings of the 12th Work-
architecture debts, in: 23rd IEEE International En- shop on OCL and Textual Modelling, Innsbruck,
terprise Distributed Object Computing Workshop, Austria, September 30, 2012, ACM, 2012, pp.
EDOC Workshops 2019, Paris, France, October 28- 7–12. URL: https://doi.org/10.1145/2428516.2428518.
31, 2019, 2019, pp. 9–16. doi:10.1109/EDOCW.2019. doi:10.1145/2428516.2428518 .
00016 . [10] M. Misbhauddin, M. Alshayeb, Uml model refac-
[2] J. Salentin, S. Hacks, Towards a catalog of enter- toring: A systematic literature review, Empiri-
prise architecture smells, in: N. Gronau, M. Heine, cal Software Engineering 20 (2015) 206–251. URL:
H. Krasnova, K. Poustcchi (Eds.), Entwicklun- https://doi.org/10.1007/s10664-013-9283-7. doi:10.
gen, Chancen und Herausforderungen der Digi- 1007/s10664- 013- 9283- 7 .
talisierung: Proceedings der 15. Internationalen [11] M. R. Hacene, S. Fennouh, R. Nkambou, P. Valtchev,
Tagung Wirtschaftsinformatik, WI 2020, Potsdam, Refactoring of ontologies: Improving the design
Germany, March 9-11, 2020. Community Tracks, of ontological models with concept analysis, in:
GITO Verlag, 2020, pp. 276–290. doi:10.30844/wi\ 22nd IEEE International Conference on Tools with
_2020\_y1- salentin . Artificial Intelligence, ICTAI 2010, Arras, France,
[3] B. Lehmann, P. Alexander, H. Lichter, S. Hacks, To- 27-29 October 2010 - Volume 2, IEEE Computer
wards the identification of process anti-patterns Society, 2010, pp. 167–172. URL: https://doi.org/10.
in enterprise architecture models, in: H. Lichter, 1109/ICTAI.2010.97. doi:10.1109/ICTAI.2010.97 .
S. Aydin, T. Sunetnanta, T. Anwar (Eds.), Proceed- [12] D. Silingas, E. Mileviciene, BPMN 2.0 Handbook,
ings of the 8th International Workshop on Quanti- Future Strategies Inc., Lighthouse Point, FL, USA,
tative Approaches to Software Quality, co-located 2012, pp. 125–134. URL: http://www.futstrat.com/.
with 27th Asia-Pacific Software Engineering Con- [13] S. W. Ambler, P. J. Sadalage, Refactoring Databases:
ference (APSEC 2020), Singapore (virtual), Decem- Evolutionary Database Design, Addison-Wesley
ber 1, 2020., CEUR-WS.org, 2020, pp. 47–54. URL: Professional, 2006.
http://ceur-ws.org/Vol-2767. [14] J. Bruel, M. Mazzara, B. Meyer (Eds.), Software En-
[4] M. Fowler, Refactoring - Improving the Design gineering Aspects of Continuous Development and
of Existing Code, Addison Wesley object tech- New Paradigms of Software Production and Deploy-
nology series, Addison-Wesley, 1999. URL: http: ment - Second International Workshop, DEVOPS
//martinfowler.com/books/refactoring.html. 2019, Château de Villebrumier, France, May 6-8,
[5] A. S. Nyamawe, H. Liu, Z. Niu, W. Wang, N. Niu, 2019, Revised Selected Papers, volume 12055 of Lec-
Recommending refactoring solutions based on ture Notes in Computer Science, Springer, 2020. URL:
traceability and code metrics, IEEE Access 6 https://doi.org/10.1007/978-3-030-39306-9. doi:10.
(2018) 49460–49475. URL: https://doi.org/10.1109/ 1007/978- 3- 030- 39306- 9 .
ACCESS.2018.2868990. doi:10.1109/ACCESS.2018. [15] M. Lippert, S. Roock, Refactoring in large software
2868990 . projects: performing complex restructurings suc-
[6] W. G. Griswold, Program Restructuring as an Aid cessfully, John Wiley & Sons, 2006.
to Software Maintenance, Ph.D. thesis, Department [16] A. Q. Gill, Agile enterprise architecture modelling:
of Computer Science and Engineering, University Evaluating the applicability and integration of six
of Washington, USA, 1992. UMI Order No. GAX92- modelling standards, Inf. Softw. Technol. 67 (2015)
03258. 196–206. URL: https://doi.org/10.1016/j.infsof.2015.
[7] S. J. Thompson, Refactoring functional programs, 07.002. doi:10.1016/j.infsof.2015.07.002 .
in: V. Vene, T. Uustalu (Eds.), Advanced Func- [17] The Open Group, Archimate 3.1 specification, 2019.
tional Programming, 5th International School, AFP URL: https://pubs.opengroup.org/architecture/
2004, Tartu, Estonia, August 14-21, 2004, Revised archimate3-doc/.
Lectures, volume 3622 of Lecture Notes in Com- [18] M. J. Wiering, M. M. Bonsangue, R. van Buuren,
puter Science, Springer, 2004, pp. 331–357. URL: L. Groenewegen, H. Jonkers, M. M. Lankhorst, In-
https://doi.org/10.1007/11546382_9. doi:10.1007/ vestigating the mapping of an enterprise descrip-
11546382\_9 . tion language into UML 2.0, Electronic Notes in The-
[8] A. Folli, T. Mens, Refactoring of UML models using oretical Computer Science 101 (2004) 155–179. URL:
AGG, Electron. Commun. Eur. Assoc. Softw. Sci. https://doi.org/10.1016/j.entcs.2004.02.020. doi:10.
Technol. 8 (2007). URL: https://doi.org/10.14279/tuj. 1016/j.entcs.2004.02.020 .
eceasst.8.112. doi:10.14279/tuj.eceasst.8.112 . [19] M. M. Lankhorst (Ed.), Enterprise Architecture
68
at Work - Modelling, Communication and Anal- Enterprise architecture refactorings, 20.10.2021.
ysis, Fourth Edition, Springer, 2017. URL: https: URL: https://swc-public.pages.rwth-aachen.de/
//doi.org/10.1007/978-3-662-53933-0. doi:10.1007/ ea-refactoring-solutions/web-catalog/.
978- 3- 662- 53933- 0 . [30] J. Salentin, S. Hacks, Enterprise architecture smells,
[20] T. Gericke, ArchiMate to UML Mapping, Tech- 2020. URL: https://ba-ea-smells.pages.rwth-aachen.
nical Report, Adocus AB, Stockholm, Sweden, de/ea-smells/.
2018. URL: http://www.adocus.com/media/21703/ [31] J. Král, M. Zemlicka, The most important service-
archimate-to-uml-mapping-whitepaper.pdf. oriented antipatterns, in: Proceedings of the Second
[21] K. Peffers, T. Tuunanen, M. A. Rothenberger, International Conference on Software Engineering
S. Chatterjee, A design science research methodol- Advances (ICSEA 2007), August 25-31, 2007, Cap Es-
ogy for information systems research, J. Manag. Inf. terel, French Riviera, France, IEEE Computer Soci-
Syst. 24 (2008) 45–77. URL: http://www.jmis-web. ety, 2007, p. 29. URL: https://doi.org/10.1109/ICSEA.
org/articles/765. 2007.74. doi:10.1109/ICSEA.2007.74 .
[22] A. R. Hevner, S. T. March, J. Park, S. Ram, De- [32] C. Wohlin, P. Runeson, M. Höst, M. C. Ohls-
sign science in information systems research, son, B. Regnell, Experimentation in Soft-
MIS Q. 28 (2004) 75–105. URL: http://misq.org/ ware Engineering - An Introduction, vol-
design-science-in-information-systems-research. ume 6 of The Kluwer International Series in
html. Software Engineering, Kluwer, 2000. URL:
[23] S. Kebir, I. Borne, D. Meslati, Automatic refac- https://doi.org/10.1007/978-1-4615-4625-2.
toring of component-based software by detect- doi:10.1007/978- 1- 4615- 4625- 2 .
ing and eliminating bad smells - A search-based [33] H. Zhang, S. Jarzabek, A bayesian network ap-
approach, in: L. A. Maciaszek, J. Filipe (Eds.), proach to rational architectural design, Int. J.
ENASE 2016 - Proceedings of the 11th International Softw. Eng. Knowl. Eng. 15 (2005) 695–718. URL:
Conference on Evaluation of Novel Approaches https://doi.org/10.1142/S0218194005002488. doi:10.
to Software Engineering, Rome, Italy 27-28 April, 1142/S0218194005002488 .
2016, SciTePress, 2016, pp. 210–215. URL: https:
//doi.org/10.5220/0005891602100215. doi:10.5220/
0005891602100215 .
[24] W. H. Brown, R. C. Malveau, H. W. S. McCormick,
T. J. Mowbray, AntiPatterns: Refactoring Software,
Architectures, and Projects in Crisis, 1st ed., John
Wiley & Sons, Inc., USA, 1998.
[25] F. A. Fontana, V. Lenarduzzi, R. Roveda, D. Taibi,
Are architectural smells independent from code
smells? an empirical study, Journal of Systems
and Software 154 (2019) 139–156. URL: https://doi.
org/10.1016/j.jss.2019.04.066. doi:10.1016/j.jss.
2019.04.066 .
[26] G. Suryanarayana, G. Samarthyam, T. Sharma,
Refactoring for Software Design Smells: Managing
Technical Debt, 1st ed., Morgan Kaufmann Publish-
ers Inc., San Francisco, CA, USA, 2014.
[27] J. Kerievsky, Refactoring to patterns, in: C. Zan-
nier, H. Erdogmus, L. Lindstrom (Eds.), Extreme
Programming and Agile Methods - XP/Agile Uni-
verse 2004, 4th Conference on Extreme Program-
ming and Agile Methods, Calgary, Canada, August
15-18, 2004, Proceedings, volume 3134 of Lecture
Notes in Computer Science, Springer, 2004, p. 232.
URL: https://doi.org/10.1007/978-3-540-27777-4_54.
doi:10.1007/978- 3- 540- 27777- 4\_54 .
[28] S. Hacks, F. Timm, Towards a quality framework
for enterprise architecture models, EMISA Forum
38 (2018) 31–32.
[29] L. Liss, H. Kämmerling, P. Alexander, H. Lichter,
69