The model of enterprise architecture (EA) greatly supports sustainable management of complex IT landscapes. It provides insights into the current implementations and future orientations of the EA developed, thereby providing a reasoning basis for important decisions. Nevertheless, the maintenance of the EA model is often pushed down the priority list due to, e.g., lack of resources or supporting methods. Flaws and deficiencies in the EA may remain ignored and create barriers to EA evolution known as EA debt [1]. To prevent such tendencies, practical methods for supporting the continuous evaluation and improvement of EA models are needed.
Using EA models to guide the improvement of EA qualities has been proposed by some studies. Salentin and Hacks coined the concept of EA smell to address common bad habits in EA practices and derived EA smells [2] by transferring known code smells into the context of EA. Lehmann et al. made a similar attempt to derive process modelling anti-patterns for EA analyses [3] by transferring known workflow anti-patterns into the context of EA. Both of these studies suggest, among others, some solutions to refactor the problems they identify. However, existing descriptions of these solutions lack the basis of evidence and practical details that are necessary for their application. This study therefore focuses on exploring current knowledge about refactoring solutions to find further evidence about EA refactoring solutions and new ways of approaching them.
Considering that current EA smells were derived from code smells, we argue that exploring known code refactoring solutions can result in meaningful insights into the refactoring solutions for EA smells. Therefore, based on the code smells used in EA smell studies, we first searched for relevant code refactoring solutions in major code smell and refactoring catalogs. The code refactoring solutions collected were then used to answer the following research questions (RQ):
RQ 1 What EA refactoring solutions can be derived from the existing code refactoring solutions? RQ 2 How can EA practitioners and researchers benefit from knowing about EA refactoring solutions?
The remainder of this paper is structured as follows: Section 2 gives an overview of studies related to refactoring solutions. Section 3 describes our methodology for deriving and documenting refactoring solutions for EA smells. Section 4 presents the resulting EA refactoring solutions mapped to the corresponding EA smells. Section 5 demonstrates some small practical examples of using EA refactoring solution for mitigating EA smells. Section 6 discusses our finding, its implications, and the threats to its validity. Section 7 motivates future research directions and concludes this paper.
The concept of refactoring has been developed to support software design and evolution, specifically to rectify design flaws and improve software quality through restructuring plans while preserving the observable behavior. The term 'refactoring' can be used in different ways, namely 'refactoring' (noun) to mention the restructuring applied to a software [4], 'to refactor' (verb) to mention the activity of restructuring a software [4], or 'refactoring solution' to mention a possible technique for restructuring a software (e.g. [5]). For the sake of clarity, these ways of usage are applied in this paper.
After being extensively used in programming domains, such as the procedural programming (e.g. [6]), objectoriented programming (e.g. [5]), and functional programming (e.g. [7]), the concept of refactoring has been explored in a wider spectrum of software engineering. In the domain of software modelling, the concept of model refactoring was introduced to enable restructuring plans on the high-level description of software [8]. The aim of model refactoring can be twofold: to allow for an earlier (i.e. at the design stage) and easier (i.e. reduced complexity) refactoring of software; or to improve semantic and syntactic quality measures of the model. Whichever aim is set, model refactoring should preserve both the behavior of the modelled software and the semantic of the model.
Studies of model refactoring have varied in their focus, whether it be on a specific modelling language or particular architectural aspect. Modelling languages such as the object constraint language (OCL), unified modelling language (UML), and web ontology language have been studied and supported with designated refactoring solutions [9] [10] [11]. Architectural aspects such as process aspect, data aspect, and style aspect have also been analyzed in this context to support a comprehensive architecture restructuring [12] [13] [14]. Furthermore, the so-called large refactorings have been proposed to deal with refactoring in complex projects, specifically when changing significant parts of a system, which often takes longer than a day [15]. Still, there are growing possibilities to explore new refactoring solutions for new design anomalies, especially with the growing interest in bad smell research-which focuses on detecting concrete indication of the need for refactoring [4].
The concept of bad smell has been adopted in the domain of EA and referred to as EA smell, which represents negative examples and bad habits that, when ignored, may harm the performance of EA activities or even the organization as a whole [2]. The concept was proposed together with a catalog of 45 EA smells, which describes (among others) the problem contexts, applicable detection methods, and possible mitigation solutions. Based on the scope of occurrence, an EA smell can be of the busi-ness, application, and/or technology architecture. This scope was recently expanded by the exploration into EA process anti-pattern, which resulted in 18 EA smells for process-related issues [3]. As the interest in EA smell research is growing, more EA smells will continue to be identified through new explorations into other aspects of EA, such as management.
This study uses the design science research (DSR) methodology according to the guidelines proposed by Peffers et al. [21] and Hevner et al. [22]. A DSR aims to devise an artifact that addresses a "heretofore unsolved and important business problem" by drawing on the existing knowledge, and the resulting artifact must be rigorously evaluated in terms of its "utility, quality, and efficacy" and effectively communicated to relevant audiences. With respect to the DSR guidelines above, this study follows the six main steps of DSR as listed below. Communicate the problem and its importance, the artifact, its utility and novelty, the rigor of its design, and its effectiveness to researchers and other relevant audiences
The following subsections describe the process and methods employed in this study with respect to the steps above.
Despite current results in EA smell research (as presented in section 2), the identification of EA smells is never an end in itself. The identified EA smells should, e.g., inform the decisions for imposing suitable EA improvement measures with regards to the current circumstances and interests. To reason such decisions, enterprise architects need to first understand the applicability of each solution alternative through evidence and practical details, UML → ArchiMate Source Activity → Interaction, Function, Process [16,17,18] Actor → Actor, Role [19,16,17,20] Artifact → Artifact, Contract, Deliverable, Gap, Product, Representation [19,16,17,20] Association → Association, Aggregation, Composition [17,20,18] Class → Actor, Collaboration, Component, Data Object, Meaning, Motivational Concepts, Object, Plateau, Representation, Role, Stakeholder, Value [19,16,20,18] Collaboration → Collaboration, Function, Interface, Location [19,16,17,20,18] Component → Component, Grouping [19,16,17,20]
Path → Communication Path, Network [17,20,18] Dependency → Assignment, Derived, Influence, Serving/Used by [17,20] Device, Event, Execution Environment → Device, Event, System Software [19,16,17,20] Generalization → Specialization [19,20,18] Information Flow → Flow, Triggering
[20] Interaction → Interaction, Application Service, Event, Function, Process [16,18]
Interface → Interface, Service [19,16,17,20,18] Method → Application/Infrastructure Function, Infrastructure Service [16] Note/Comment → Meaning, Representation [18] Node → Node, Communication Path, Device, Infrastructure Interface, Location, Network, System Software [19,16,17,20] Object → Object, Contract, Data Object, Meaning, Product, Representation, Value [16] Opaque Behavior → Application Interaction, Business Event, Business Interaction, Business Process, Junction, Work Package [20] Swimlane → Actor, Business Service, Role [16] Usage → Access, Serving/Used By [20] Use Case → Business Function, Business Interaction, Requirement, Service [19,16,17,20] Realization, Composition, Aggregation → Realization, Composition, Aggregation [19,17,20,18] Table 1 A mapping from UML to ArchiMate which are still lacking in the hitherto solution suggestions for EA smell mitigation. Furthermore, current knowledge about the refactoring of architectural smells focuses on rather technical aspects (i.e. software architecture), which are hardly applicable for evaluating and evolving an EA. Therefore, we argue that EA research should pursue the identification of possible EA refactoring solutions to guide enterprise architects in finding possible and feasible solutions for the EA smell problems at hand.
Considering the problem described above, this study aims to devise the concept of EA refactoring solution by drawing on the existing knowledge about refactoring. To guide the solution design and development, this study sets the following solution objectives:
1. Support enterprise architects in finding appropriate solutions to a certain EA smell by identifying possible EA refactoring solutions and providing clear descriptions about their context and implementation 2. Support enterprise architects in communicating relevant EA refactoring solutions in a consistent manner by identifying relevant attributes and providing a standard documentation template 3. Allow the EA community to obtain an up-to-date overview of results in EA refactoring research and contribute to the its development
Since the first EA smells were derived from code smells [2], we assume that refactoring solutions for code smells may hold some clue to the refactoring solutions for EA smells. This assumption leads to the design of our methodology, which includes three main steps: Concept analysis, concept mapping, and concept transformation.
Concept Analysis. Our first step is to collect relevant code refactoring solutions for the code smells used by existing studies on EA smells [2]. Our analysis covered some existing code smells or anti-patterns catalogs (i.e., [4], [23], and [24]). While we are aware that "the presence of code smells does not imply the presence of architectural smells and vice versa, " [25], we argue that some problematic design patterns addressed by code smells or anti-patterns (e.g. cyclic dependency or duplication) may also occur in EA context. Furthermore, the practice of transferring existing concepts into a different domain has been performed to generate first ideas within a new problem domain and inspire further research (e.g. [2], [3]). Describes the situations when this refactoring solution can be useful Graphical example Shows a graphical representation of the refactoring solution to reduce misinterpretations
Attributes of EA refactoring solutions (adapted from [4], [26], and [27]).
Concept Mapping. The second step in our methodology is to establish a mapping between the concepts in code and EA modelling, which should serve as a basis for conceptually transforming the code refactoring solutions collected into EA refactoring solutions.
Although the code and the EA lie on two opposite sides in the spectrum of abstraction, the languages used for modelling them share a good deal of similar constructs in that both support the description of architectural aspects. Previous studies have proposed some mappings between the notations of UML and ArchiMate, which are the most used languages for code and EA modelling, respectively. Some of these mappings are described in the ArchiMate specification [17]-as some notations thereof are indeed derived from UML [19]-, while the rest have been exclusively suggested by the studies. Since most code refactoring solutions have been described and exemplified using UML, we strongly argue that such mappings can guide the transformation of code refactoring solutions into EA refactoring solutions.
We believe that the first mapping between the concepts in UML and ArchiMate was proposed by Wiering et al. [18]. Their study focuses on identifying matching concepts and relationships by comparing the notations in the two languages by the properties thereof. Another attempt was made in a study by Gill, which focuses on finding concepts in other modelling languages beside ArchiMate which are applicable for EA modelling [16]. The resulting contribution includes a mapping of some concepts in UML to ArchiMate. Furthermore, Lankhorst also advocate the use of ArchiMate in conjunction with other modelling languages (including UML) to create a more holistic EA description [19]. To support this in practice, this contribution highlights not only the similarities but also important differences in ArchiMate and UML, e.g. 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 of UML and ArchiMate is proposed by Gericke, which also considers ArchiMate concepts under the motivation layer [20]. • In some cases, the translation may not directly result in an ArchiMate construct that conveys a valid solution in the context of EA. Such ArchiMate construct is either modified for a reasonable EA refactoring solution or excluded from consideration.
Because of the manual concept transformation in this process, the outcome is highly influenced by the skill, knowledge, and experience of the researchers. Also, since the mapping used gives more than one matching Archi-Mate notations for every UML notation, the resulting translation may vary depending on the researcher's own understanding and interpretation of the two modelling languages (UML and ArchiMate).
In this DSR step, the use of the artifact is demonstrated to solve one or more instances of the problem [21]. The fundamental questions to be answered are, "What utility does the new artifact provide?" and "What demonstrates that utility?" [22] In the context of this study, the EA refactoring solutions proposed should provide solution alternatives for mitigating EA smells and the practical details needed to understand their feasibility as well as relevance according to the current conditions. Therefore, to demonstrate the applicability of our result for solving the problems described in section 3.1, we illustrate some small scenarios of mitigating EA smells using the EA refactoring solutions proposed. For this purpose, we use a small ArchiMate model which contains some EA smells. Then, we identify candidates of EA refactoring solutions and select one that we deem the most appropriate for the EA smell given. It is worth noting that the systematic approach to prioritizing EA refactoring solution candidates is still a subject to future work; hence, the selection of EA refactoring solution demonstrated in this paper relies on the authors' perspectives. Finally, we elaborate the architectural changes suggested by the EA refactoring solution selected, show the resulting ArchiMate model after applying these architectural changes, and discuss the impact on the ArchiMate model's overall quality.
The evaluation step in DSR aims to review the effectiveness of the artifact proposed in supporting a solution to the problem [21]. In this paper, this step is embodied in a discussion, in which we explain how the main RQs of this study have been answered based on our findings and their demonstration. Since the discussion presented in this paper is focused only on the qualitative performance of EA refactoring solution within our example scenario, we recommend future research to extend the evaluation by including more (real-world) examples and quantifiable measures (e.g. using EA model quality framework [28]).
Finally, the communication step focuses on presenting the artifact proposed, its utility, and its effectiveness to researchers and other relevant audiences. [21] To communicate our results in an intuitive and consistent manner, we document the EA refactoring solutions in a standard template (see table 2) which we adapted from some existing templates of refactoring solution used in [4] [26] [27]. Furthermore, the EA refactoring solutions are categorized based on the domains of the corresponding EA smells (i.e. business, technology, and application domains) [2] and made publicly available on a web page [29].
This refactoring increases the user orientation of service interfaces with the goal to enable user involvement in business processes. A process manager that realizes the service calls is created. Previous caller of the process call the process manager now with process control data that parameterizes the wanted process.
Route data access through dedicated data services that encapsulate the needed business objects.
This is not only a refactoring but also an architecture pattern itself. It can be used to generate more online involvement for everyone that should be involved. In a peer-to-peer system it is usually not desired to have many centralized services, so the process manager needs to be evaluated carefully.
The data visibility is very narrow when using this refactoring which reduces unwanted dependencies between teams.
Documentation of the Process Manager and Encapsulate Business Objects EA refactoring solutions
As a result, this study yields a catalog of 37 EA refactoring solutions for all 45 EA smells proposed in [2] (see table 3).
In the catalog, some EA refactoring solutions are suggested for multiple EA smells, such as the Process Manager EA refactoring solution which is suggested for the Big Bang, Business Process Forever, Message Chain, No Legacy, and Nothing New EA smells. Such result is obtained because some code refactoring solutionsfrom which we derived EA refactoring solutions-have also been suggested for mitigating various code smells. While we are aware that specific adaptations may be necessary to make one kind of solution works for different problems, the catalog currently provides only a general description of how to apply each EA refactoring solution.
Describing such adaptations is a subject to future work.
Furthermore, the catalog also suggests multiple EA refactoring solution candidates for some EA smells, such as the Move Component and Front End Gate which are suggested as solution candidates for mitigating the Feature Envy EA smell. Such result is obtained because we identified different studies which suggest different code refactoring solutions for the same code smell. While we are aware that the selection of an appropriate EA refactoring solution should consider the specific circumstances surrounding the EA smell problem, such specific circumstances are beyond the scope of this study. Therefore, we suggest future studies in this context to investigate the possibility to systematically prioritize all EA refactoring solutions recommended for a certain EA smell. In such a prioritization approach, various quality requirements may be considered, such as scalability and extensibility.
In order to illustrate the application of the proposed EA refactoring solutions, we performed an experiment to apply EA refactoring solutions on a small ArchiMate model (see fig. 1), which we adapted from [2]. This ArchiMate model contains two EA smells: First, a message chain due to the sequential calls over 5 application services to fulfill the same application process (i.e. customer registration). Second, a shared persistency because of the direct relations between 3 application services and a database management system (i.e. DBMS). The first EA smell (i.e. message chain) occurs when at least 5 services sequentially interact to fulfill a process, which may harm availability and evolvability [30]. To solve this, our catalog (see table 3) proposes two possible 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 class' in [4]). To select from several possible refactoring solutions, the architect must first evaluate whether the main idea and practical details thereof suit the context of the subjected EA smell. In the presented ArchiMate model, we assume that the exemplified message chain does not stem from data but process architecture issues. Therefore, the process manager is chosen, as presented in table 4.
The chosen refactoring solution suggests to restructure the collaboration scheme between the chained services into an orchestration scheme-in which one service acts as a 'process manager' that coordinates independent services to fulfill the requested business process. This scheme eases the maintenance and extension of the supported business process, thereby remediating the availability and evolvability issues posed by the message chain. In our ArchiMate model, this refactoring solution is applied by first encapsulating all involved operations across the chained application services into independent activity modules that are accessible through external interfaces. Afterwards, a process manager must be implemented (in this case, the customer information service) which receives requests for customer information processing and fulfills these by delegating tasks to the available services.
The second EA smell (i.e. shared persistency) is detected when multiple services access the same data collection or schema, thereby reducing team and service independence [30]. For this, our catalog proposes the encapsulate business objects refactoring solution (adapted from 'encapsulate variable' in [4]), as presented in table 4. This refactoring solution suggests to route accesses to the DBMS through dedicated data services; each of which encapsulates all business objects required by one application service. This structure reduces data visibility to only those of the owned business objects, thereby preventing unwanted interdependence between teams and services.
In this section, we describe the extent to which the main RQs (see section 1) of this study have been answered through our finding and its demonstration; elaborate the implications of the EA refactoring solutions identified for researchs and practitioners; and identify the potential threats to the internal and external validity of our result.
With regards to answering the RQ1 and its sub-questions, this study identifies the first catalog of EA refactoring solutions for all the EA smells proposed in [2]. We achieved this result by performing a conceptual transformation on relevant code refactoring solutions, which relies on a mapping between code and EA modelling concepts. To document the resulting EA refactoring solutions, we use a template of attributes which we adapted from some existing templates in code refactoring domain. Finally, we demonstrated the use of several refactoring solutions in some small scenarios of EA smell. While the solution choices demonstrated may not be suitable to all cases in reality, we believe that the presented catalog provides a useful platform for EA researchers and practitioners to develop new or better refactoring solutions to common problems in EA.
Recent study in EA has proposed the concept of EA debt [1] which represents the divergent EA evolution from the EA standards and principles. One possible source of EA debt is the implementation of sub-optimal solution design. The role of EA smells is to indicate the signs of existing sub-optimal solutions within the IT landscape, so that further investigation can be triggered in time [2].
With regards to answering the RQ2, the implication of our result can be seen from both practical and research perspectives. For EA practitioners, the proposed EA refactoring solutions may help to find possible methods or techniques for solving the EA smells identified. Also, such a solution catalog can help to establish common terminologies within an organization, thereby supporting various stakeholders to discuss possible solutions.
For the EA research community, our result gives motivation and food for thought for further investigations into the concept of EA refactoring. Future attempts to extend the catalog by transforming refactoring solutions from other domains (e.g. process smell, infrastructure smell, etc) may also adopt the conceptual transformation methodology used in this study. To allow public contributions in the development of EA refactoring solutions, the catalog has been published in a website together with a guideline on contributing [29].
The results of this study have to be seen in the light of some limitations. In this section, we present an assessment of possible threats to the internal and external validity of our result. Internal validity focuses on the reliability of the result within the given environment, whereas external validity focuses on the ability to generalize the result [32].
Internal Validity. The design of our methodology may pose certain threats to the internal validity of our result. Firstly, the code refactoring solutions analyzed were collected from a selection of relevant books on code smell and refactoring, thereby threatening the completeness of the EA refactoring solution catalog. Secondly, the mapping between UML and ArchiMate notations used in the transformation was summarized from some selected sources, thereby threatening the completeness of the mapping used in this study. Last but not least, the process of transforming code refactoring solutions into EA domain relies on subjective analysis, which potentially results in biased considerations upon deriving the EA refactoring solutions. To reduce the bias, the resulting EA refactoring solutions were reviewed and decided among the authors of this paper. Despite these weaknesses, we believe that the resulting EA refactoring solution catalog is a step in the right direction towards solutions for common design issues in EA.
As the resulting EA refactoring solutions are yet to be evaluated in industrial context, their descriptions may still rather hypothetical and theoretical, thereby posing challenges to their adoption. Furthermore, as there could be multiple solution alternatives for every EA smell, further research is still needed to identify possible factors and conditions which influence the suitability of a certain EA refactoring solution. Finally, the adoption of EA refactoring solutions greatly depends on the progress in EA smell research. At the time of writing, the existing EA smells are yet to be evaluated and their descriptions enriched with practical examples.
Our main goal is to support EA practitioners in analyzing possible improvements with regards to the current circumstances and interests. We strongly argue that approaches to EA improvement must extend from EA modelling capabilities. Therefore, this study investigates the concept of refactoring in the context of EA modelling. Our methodology focuses on defining EA refactoring solutions for the EA smells proposed in [2] by analyzing the known associations between code refactoring solutions and code smells. The resulting contribution is a catalog of EA refactoring solutions which is publicly available on a web page [29].
In spite of this progress, there is still work to be done, especially in improving the catalog, or where further work is necessary. Some potential future works in this context are as follows: Firstly, further EA refactoring solutions can be derived for EA smells from different 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 of ArchiMate to another modelling language of interest as proposed in [16]. Secondly, empirical studies can be performed to further review and improve the hitherto knowledge in this area. Last but not least, tool supports can be developed for, e.g., recommending suitable EA refactoring solutions (e.g. [33]) or supporting the implementation thereof.