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.
tical methods for supporting the continuous evaluation and improvement of EA models are needed.
The model of enterprise architecture (EA) greatlywsuapy-s of approaching them. ports sustainable management of complex IT landscapesC. onsidering that current EA smells were derived from It provides insights into the current implementationscoanded smells, we argue that exploring known code refacfuture orientations of the EA developed, thereby prtoovridi n-g solutions can result in meaningful insights into ing a reasoning basis for important decisions. Nevertthhee-refactoring solutions for EA smells. Therefore, based less, the maintenance of the EA model is often pusheodn the code smells used in EA smell studies, we first down the priority list due to, e.g., lack of resourcesesaorrched for relevant code refactoring solutions in major supporting methods. Flaws and deficiencies in the EAcode smell and refactoring catalogs. The code refactormay remain ignored and create barriers to EA evolutiniognsolutions collected were then used to answer the known as EA debt1[]. To prevent such tendencies, pracf-ollowing research questions (RQ):
Using EA models to guide the improvement of EA qualfrom the existing code refactoring solutions? ities has been proposed by some studieSsa. lentin and Hackscoined the concept of EA smell to address commoRnQ 1.1 How to derive insights about EA refactoring bad habits in EA practices and derived EA sme2l]lbsy[ from analyzing code refactoring solutions?
modelling anti-patterns for EA anal3y]sebsy[transfersolution? transferring known code smells into the context oRfQEA1..2 What attributes can describe an EA refactoring ring known workflow anti-patterns into the contexRtQof2 How can EA practitioners and researchers benefit EA. Both of these studies suggest, among others, some solutions to refactor the problems they identify. However, existing descriptions of these solutions lack the basisTohfe remainder of this paper is structured as follows: evidence and practical details that are necessary forSetchteiiorn2 gives an overview of studies related to refacapplication. This study therefore focuses on explortionrging solutions. Secti3odnescribes our methodology from knowing about EA refactoring solutions? nEvelop-O (H. Lichter) CEUR
CEUR for deriving and documenting refactoring solutions for
ing solutions mapped to the corresponding EA smells.
using EA refactoring solution for mitigating EA smells. Section6 discusses our finding, its implications, and the threats to its validity. Sec7tmioontivates future research directions and concludes this paper.
ness, application, and/or technology architecture. This scope was recently expanded by the exploration into EA The concept of refactoring has been developed to psruopc-ess anti-pattern, which resulted in 18 EA smells for port software design and evolution, specifically to repcr-ocess-related issue3s].[ As the interest in EA smell tify design flaws and improve software quality throughresearch is growing, more EA smells will continue to be restructuring plans while preserving the observablideebnet-ified through new explorations into other aspects havior. The term ’refactoring’ can be used in difereonftEA, such as management. ways, namely ’refactoring’ (noun) to mention the restructuring applied to a software4][, ’to refactor’ (verb) to mention the activity of restructuring a softw4]a,roer[ 3. Methodology ’refactoring solution’ to mention a possible technique for restructuring a software (e.g5.][). For the sake of clarityT,his study uses the design science research (DSR) methodthese ways of usage are applied in this paper. ology according to the guidelines proposePdebferys
After being extensively used in programming domains,et al[.21] andHevner et al[.22]. A DSR aims to devise such as the procedural programming (e.6g].),[object- an artifact that addresses a ”heretofore unsolved and imoriented programming (e.g5.][), and functional programp-ortant business problem” by drawing on the existing ming (e.g. [7]), the concept of refactoring has been kenxo-wledge, and the resulting artifact must be rigorously plored in a wider spectrum of software engineering. Ienvaluated in terms of its ”utility, quality, and eficacy” and the domain of software modelling, the concept of modeefelctively communicated to relevant audiences. With refactoring was introduced to enable restructuringreplsapencst to the DSR guidelines above, this study follows on the high-level description of softwa8r]e. T[he aim of the six main steps of DSR as listed below. model refactoring can be twofold: to allow for an e1a. rPlireorblem 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 semanticthe solution proposed and syntactic quality measures of the model. Whichever aim is set, model refactoring should preserve both2t.hSeolution objective definition Infer the objectives behavior of the modelled software and the semantic ofof 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 pa3r.-Design and development. Create the artifact ticular architectural aspect. Modelling language4s.suDcehmonstration. 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 refacto5r.inEgvaluation. Observe and measure how well the artisolutions9[] [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 comprehens6i.veCommunication. Communicate the problem and architecture restructur1i2n]g[1[3] [14]. Furthermore, its importance, the artifact, its utility and novelty, the rigor of its design, and its efectiveness to researchers the so-called large refactorings have been proposed to deal with refactoring in complex projects, specificallyand other relevant audiences when changing significant parts of a system, which oftenThe following subsections describe the process and methtakes longer than a da1y5][. Still, there are growinogds employed in this study with respect to the steps possibilities to explore new refactoring solutions forabnoevwe. 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 represeDnetsspite current results in EA smell research (as presented negative examples and bad habits that, when ignoirnedse,ction2), the identification of EA smells is never an may harm the performance of EA activities or even etnhde in itself. The identified EA smells should, e.g., inorganization as a whol2e]. [The concept was proposed form the decisions for imposing suitable EA improvement together with a catalog of 45 EA smells, which descrmiebaessures with regards to the current circumstances and (among others) the problem contexts, applicable deitnetce-rests. To reason such decisions, enterprise architects tion methods, and possible mitigation solutions. Banseeedd to first understand the applicability of each soluon the scope of occurrence, an EA smell can be of the btuisoin- alternative through evidence and practical details,
Source
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 InteracComponent → Component, Grouping [19,16, 17, 20] tion, Business Process, Junction, Work
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
Information Flow → Flow, Triggering [20] tion → Realization, Composition, AggreInteraction → Interaction, Application [16, 18] gation
Service, Event, Function, Process which are still lacking in the hitherto solution sugge3s.tiAonllsow the EA community to obtain an up-to-date for EA smell mitigation. Furthermore, current knowol-verview of results in EA refactoring research and edge about the refactoring of architectural smells focucsoenstribute to the its development on rather technical aspects (i.e. software architecture), which are hardly applicable for evaluating and e3v.o3l.v-Design and development ing an EA. Therefore, we argue that EA research should pursue the identification of possible EA refactoringSsion-ce the first EA smells were derived from code smells lutions to guide enterprise architects in finding possi[b2l],ewe assume that refactoring solutions for code smells and feasible solutions for the EA smell problems at hmaanyd.hold some clue to the refactoring solutions for EA smells. This assumption leads to the design of our method3.2. Solution objective definition ology, which includes three main steps: Concept analysis, concept mapping, and concept transformation.
Considering the problem described above, this study aims to devise the concept of EA refactoring solution by dCroanwc-ept Analysis. Our first step is to collect relevant ing on the existing knowledge about refactoring.coTdoe refactoring solutions for the code smells used by guide the solution design and development, this steuxdisyting studies on EA smell2s].[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 architecsolutions to a certain EA smell by identifying possible
tural smells and vice versa25,”],[ 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 rmealey-also occur in EA context. Furthermore, the practice vant EA refactoring solutions in a consistent maonfnterransferring existing concepts into a diferent domain by identifying relevant attributes and providing ahsatsanb-een performed to generate first ideas within a new dard documentation template problem domain and inspire further research (2e].g,. [ [3]). Attribute Gives the refactoring solution a meaningful designator Links the refactoring solution to the targeted EA smells Names the code refactoring solution from which this refactoring solution is derived Gives a brief overview of this refactoring solution Describes the main goal of this refactoring solution Describes the reasons of applying this refactoring solution Describes the conditions prior to applying this refactoring solution Describes the influence of this refactoring solution to EA qualities Describes the practical steps to apply this refactoring solution Describes the situations when this refactoring solution can be useful
Shows a graphical representation of the refactoring solution to reduce misinterpretations
Concept Mapping. The second step in our method-of UML and ArchiMate is proposed Gbyericke, which ology is to establish a mapping between the conceptaslisno considers ArchiMate concepts under the motivation code and EA modelling, which should serve as a basis lfaoyrer 2[0]. Table1 summarizes all these mappings which conceptually transforming the code refactoring soluwteiounsse as a basis to conduct the concept transformation. collected into EA refactoring solutions.
Although the code and the EA lie on two opposite siCdoenscept Transformation. To finally derive EA refacin the spectrum of abstraction, the languages usedtofroirng solutions, the code refactoring solutions collected modelling them share a good deal of similar construcatrseinprocessed as follows: that both support the description of architectural aspects.
Previous studies have proposed some mappings betwee•n We analyzed the descriptions and examples of code the notations of UML and ArchiMate, which are the morsetfactoring solutions to identify instances of UML conused languages for code and EA modelling, respectivelcye.pts and relationships. Based on the mapping of UML Some of these mappings are described in the ArchiMateand ArchiMate notations shown in t1a,btlhee idenspecification [17]—as some notations thereof are indeedtified UML constructs are translated into ArchiMate derived from UML1[9]—, while the rest have been exclu- constructs. Since each UML notation does not necessively suggested by the studies. Since most code refactosra-rily 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 guidecan be translated into Interface in ArchiMate), the the transformation of code refactoring solutions intotrEaAnslation has to be inferred rationally from our unrefactoring 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 proposedWbyiering et al[.18]. Their study focuses on identifying matchi•ngIn some cases, the translation may not directly result in concepts and relationships by comparing the notationans ArchiMate construct that conveys a valid solution in in the two languages by the properties thereof. Anothtehre context of EA. Such ArchiMate construct is either attempt was made in a study Gbyill, which focuses on modified for a reasonable EA refactoring solution or ifnding concepts in other modelling languages besideexcluded from consideration.
ArchiMate which are applicable for EA model1l6in].g [ The resulting contribution includes a mapping of somBeecause of the manual concept transformation in this concepts in UML to ArchiMate. FurthermLoarnek,horst process, the outcome is highly influenced by the skill, also advocate the use of ArchiMate in conjunction kwniotwhledge, and experience of the researchers. Also, since other modelling languages (including UML) to creattheeamapping used gives more than one matching Archimore holistic EA descriptio1n9][. To support this in prac-Mate notations for every UML notation, the resulting tice, this contribution highlights not only the similatrriatniesslation may vary depending on the researcher’s own understanding and interpretation of the two modelling but also important diferences in ArchiMate and UML, e.g. the absence of separate conceptssefrovrice andinterface languages (UML and ArchiMate). as well as the reverse interpretation of the ArchiMate relationshisperving in UML. Lastly, another mapping
Ambiguous Viewpoint→ 5 Viewpoints Jumble→ Architecture Partitioning Architecture by Implicatio→n Goal Question Architecture Lazy Component→ GhostbustingorInline Service Big Bang→ Process Manager Message Chain→ Process ManagerorExtract & Move Data Bloated Service→ Merge input Object Business Process Foreve→r Process Manager Missing Abstraction→ Add Abstraction Chatty Service→ Front End Gate Multifaceted Abstractio→n Split Phase Combinatorial Explosio→n 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 Functio→n 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 FrameworokrEA Planning Documentation→ Rename Component Strict Layers Violatio→n Move Service to Diferent Layer Duplication→ Extract Shared Functionality Temporary Solution→ Extract Temporary Solution Feature Envy→ Move ComponentorFront 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 Abstractio→n Grouping Warm Bodies→ Small Project Incomplete Node or Collaborati→onIntroduce Local Exten- Weakened Modularity→ Split Modularity sion Wrong Cuts→ Reorganization
Inconsistent Versioning→ Semantic Versioning 3.4. Demonstration
3.5. Evaluation In this DSR step, the use of the artifact is demonstrTahteedevaluation step in DSR aims to review the efectiveto solve one or more instances of the prob2l1e]m.T[he ness of the artifact proposed in supporting a solution to fundamental questions to be answered are, ”What uttihlietyproblem2[1]. In this paper, this step is embodied in does the new artifact provide?” and ”What demonstraadteiscussion, in which we explain how the main RQs of that utility?2”2][ In the context of this study, the EtAhis study have been answered based on our findings and refactoring solutions proposed should provide solutthioeinr demonstration. Since the discussion presented in alternatives for mitigating EA smells and the practthiicsaplaper is focused only on the qualitative performance details needed to understand their feasibility as woefllEAasrefactoring solution within our example scenario, relevance according to the current conditions. Therwefeorreec, ommend future research to extend the evaluation to demonstrate the applicability of our result for soblyviinncgluding more (real-world) examples and quantifiable the problems described in secti3o.1n, we illustrate somemeasures (e.g. using EA model quality framework [28]). small scenarios of mitigating EA smells using the EA refactoring solutions proposed. For this purpose, we3u.s6e. Communication a small ArchiMate model which contains some EA smells.
Then, we identify candidates of EA refactoring solutFiionnaslly, the communication step focuses on presenting and select one that we deem the most appropriate forththeeartifact proposed, its utility, and its efectiveness to EA smell given. It is worth noting that the systematirceasepa-rchers and other relevant audien21c]esT.o[commuproach to prioritizing EA refactoring solution candindiactaetse our results in an intuitive and consistent manner, is still a subject to future work; hence, the selectiwoendoofcument the EA refactoring solutions in a standard EA refactoring solution demonstrated in this paper rteelmiepslate (see tab2le)which we adapted from some existon the authors’ perspectives. Finally, we elaborateintghteemplates of refactoring solution us4e]d[i2n6][[27]. architectural changes suggested by the EA refactoFurrintghermore, the EA refactoring solutions are categorized solution selected, show the resulting ArchiMate mboadseeld on the domains of the corresponding EA smells after applying these architectural changes, and disc(ui.ses. business, technology, and application domai2n] s) [ the impact on the ArchiMate model’s overall qualitayn.d made publicly available on a web page [29]. Connected EA smell Derived from Intent Motivation Prerequisites Impact Mechanics Discussion
Process manager Encapsulate Business Objects This refactoring increases the user orientation of serviceRoute data access through dedicated data interfaces with the goal to enable user involvement inservices that encapsulate the needed busibusiness processes. A process manager that realizes theness objects. service calls is created. Previous caller of the process call the process manager now with process control data that parameterizes the wanted process.
Business Process Forever, Big Bang, Nothing New, No Shared Persistency Legacy Process Manager Encapsulate Variable Create a process manager component which orchestratesNarrow down the data visibility by routing the components involved in the process. data access through dedicated data services.
This refactoring is meant to create a better user involveR-educe the likeability that teams unwillingly ment. It also adds more flexibility and extensibility to thedepend on each other because the visibility architecture. of the data is too broad.
A long, very strict process chain with many diferent Multiple business services that access the stakeholders involved. same database.
This refactoring makes the application service interfacesThe structure created by the refactoring remore user oriented which enables the user involvementduces data visibility to only those of the in business processes. owned business objects, thereby preventing any unwanted interdependence between teams and services. 1. Generate a new service P called the Process Manager1. Create a new data service that will contain 2. Add a service call from P to all the process componentsthe dedicated data services of the Process manager 2. For each business service, create a dedi3. All calls to the individual process components callcsated data service that routes the access to now the Process Manager with process control data Cthe database. Test each data service. that parameterize the wanted original Process. Test each3. 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 This is not only a refactoring but also an architecturTehe data visibility is very narrow when using pattern itself. It can be used to generate more onlinethis refactoring which reduces unwanted deinvolvement 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.
refactoring solution candidates for some EA smells, such As a result, this study yields a catalog of 37 EA refactaosrtinhge Move Component and Front End Gate which are solutions for all 45 EA smells proposed2]i n(s[ee table3). suggested as solution candidates for mitigating the FeaIn the catalog, some EA refactoring solutions aretsuurge-Envy EA smell. Such result is obtained because we gested for multiple EA smells, such as the Process Maind-entified diferent studies which suggest diferent code ager EA refactoring solution which is suggested forrtefhaectoring solutions for the same code smell. While we Big Bang, Business Process Forever, Message Chain, are aware that the selection of an appropriate EA refactorNo Legacy, and Nothing New EA smells. Such resulting solution should consider the specific circumstances is obtained because some code refactoring solutiosnusr–rounding the EA smell problem, such specific circumfrom which we derived EA refactoring solutions–hsatvaences are beyond the scope of this study. Therefore, we also been suggested for mitigating various code smseullgsg.est future studies in this context to investigate the While we are aware that specific adaptations may be npeoc-ssibility to systematically prioritize all EA refactoring essary to make one kind of solution works for diferesnotlutions recommended for a certain EA smell. In such problems, the catalog currently provides only a genaerprailoritization approach, various quality requirements description of how to apply each EA refactoring solumtaioynb.e considered, such as scalability and extensibility. Describing such adaptations is a subject to future work.
modules that are accessible through external interfaces.
Afterwards, a process manager must be implemented (in this case, the customer information service) which reIn order to illustrate the application of the proposceedivEeAs requests for customer information processing and refactoring solutions, we performed an experiment tofualpfil-ls these by delegating tasks to the available services. ply EA refactoring solutions on a small ArchiMate modTelhe second EA smell (i.e.shared persistency) is de(see fig. 1), which we adapted from2][. This ArchiMate tected when multiple services access the same data collecmodel contains two EA smells: Firsmt,eassage chain due tion or schema, thereby reducing team and service indeto the sequential calls over 5 application services topfeunldfillence [30]. For this, our catalog proposesetnhceapthe same application process (i.e. customer registra-sulate business objects refactoring solution (adapted tion). Second, ashared persistency because of the directfrom ’encapsulate variable’4i]n),[as presented in tab4l.e relations between 3 application services and a dataTbhaisserefactoring 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 applicaleast 5 services sequentially interact to fulfill a protcioensss,ervice. This structure reduces data visibility to only which may harm availability and evolvabi3l0it].yT[o those of the owned business objects, thereby preventing solve this, our catalog (see t3a)bplreoposes two possi- unwanted interdependence between teams and services. ble EA refactoring solutions, i.e.ptrhoceess manager (inspired from ’process manager’ i3n1][) andextract 6. Discussion and move data object (adapted from ’extract and move class’ in 4[]). To select from several possible refactorIinngthis section, we describe the extent to which the main solutions, the architect must first evaluate whetheRrQtshe(see section1) of this study have been answered main idea and practical details thereof suit the cotnhtreoxutgh our finding and its demonstration; elaborate the of the subjected EA smell. In the presented ArchiMiamtpelications of the EA refactoring solutions identified model, we assume that the exemplifiemdessage chain for researchs and practitioners; and identify the potential does not stem from data but process architecture istshurees.ats to the internal and external validity of our result. Therefore, thperocess manager is chosen, as presented in table4.
The chosen refactoring solution suggests to res6t.r1u.c-Explanation of the Result ture the collaboration scheme between the chaineWdsiterh-regards to answering the RQ1 and its sub-questions, vices into an orchestration scheme—in which one sertvhicies study identifies the first catalog of EA refactoring soacts as a ’process manager’ that coordinates independluentitons for all the EA smells propose2d].inW[e achieved services to fulfill the requested business process. Ththisis result by performing a conceptual transformation scheme eases the maintenance and extension of the sounp-relevant code refactoring solutions, which relies on a ported business process, thereby remediating the avmaailp-ping between code and EA modelling concepts. To ability and evolvability issues posed bymtehsseage chain. document the resulting EA refactoring solutions, we use In our ArchiMate model, this refactoring solution ais taepm-plate of attributes which we adapted from some plied by first encapsulating all involved operations acreoxsissting templates in code refactoring domain. Finally, the chained application services into independent actwiveitdyemonstrated the use of several refactoring solutions in some small scenarios of EA smell. While the soluttiohne mapping used in this study. Last but not least, the prochoices demonstrated may not be suitable to all casceessisnof transforming code refactoring solutions into EA reality, we believe that the presented catalog provdidoemsaain relies on subjective analysis, which potentially useful platform for EA researchers and practitionerresutlots in biased considerations upon deriving the EA develop new or better refactoring solutions to comrmefoanctoring 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 cataResearchers log is a step in the right direction towards solutions for common design issues in EA.
Recent study in EA has proposed the concept of EA debt [1] which represents the divergent EA evolution fEroxmternal validity. As the resulting EA refactoring sothe EA standards and principles. One possible sourceluotfions are yet to be evaluated in industrial context, their EA debt is the implementation of sub-optimal solutdioesncriptions may still rather hypothetical and theoretical, design. The role of EA smells is to indicate the signtshoefreby posing challenges to their adoption. Furtherexisting sub-optimal solutions within the IT landscmaopree,, as there could be multiple solution alternatives for so that further investigation can be triggered i2n].timevee[ry EA smell, further research is still needed to identify
With regards to answering the RQ2, the implicatiopnoossfible factors and conditions which influence the suitour result can be seen from both practical and reseaabriclhity of a certain EA refactoring solution. Finally, the perspectives. For EA practitioners, the proposed aEdAoption of EA refactoring solutions greatly depends on refactoring solutions may help to find possible methotdhse progress in EA smell research. At the time of writing, or techniques for solving the EA smells identified. Altshoe, existing EA smells are yet to be evaluated and their such a solution catalog can help to establish commondetsecrr-iptions enriched with practical examples. minologies within an organization, thereby supporting various stakeholders to discuss possible solutions.
For the EA research community, our result gives m7o.- Conclusion & Future Work tivation and food for thought for further investigations into the concept of EA refactoring. Future attempOtusrtmoain goal is to support EA practitioners in analyzextend the catalog by transforming refactoring soluintgiopnosssible improvements with regards to the current circumstances and interests. We strongly argue that apfrom other domains (e.g. process smell, infrastructure
proaches to EA improvement must extend from EA modsmell, etc) may also adopt the conceptual transformation
elling capabilities. Therefore, this study investigates the methodology used in this study. To allow public contributions in the development of EA refactoring solutcioonncs,ept of refactoring in the context of EA modelling.
Our methodology focuses on defining EA refactoring sothe catalog has been published in a website together with a guideline on contributing [29]. lutions for the EA smells proposed2i]nby[ analyzing the 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 loignhatweb page [29]. of some limitations. In this section, we present an aIsn- spite of this progress, there is still work to be done, sessment of possible threats to the internal and exteesrpneaclially in improving the catalog, or where further validity of our result. Internal validity focuses ownotrhkeis necessary. Some potential future works in this reliability of the result within the given environcmoenntte,xt are as follows: Firstly, further EA refactoring whereas external validity focuses on the ability to gseonluert-ions can be derived for EA smells from diferent alize the result [32]. domains, such as the EA process smell3s].[ For such purpose, we suggest to adapt the methodology from the Internal Validity. The design of our methodology mayone used in this study, e.g. by integrating a mapping of ArchiMate to another modelling language of interest pose certain threats to the internal validity of our result.
as proposed in 1[6]. 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 of the EA refactoring solution catalog. Secondlyc,atnhe be developed for, e.g., recommending suitable EA refactoring solutions (e3.g3.])[or supporting the implemapping between UML and ArchiMate notations used
mentation thereof. in the transformation was summarized from some selected sources, thereby threatening the completeness of