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