Refactoring for Software Architecture Smells: Potential Research Directions

Smells and refactoring have received considerable focus from the academia as well as from the industry in the past two decades. Various tools, processes, techniques, and practices have been proposed to identify smells arising at the granularity of code and (to some extent) of design. However, architecture smells and corresponding refactorings haven’t received as much focus and adoption from the software engineering community. This article provides a motivation for architecture refactoring and discusses a few potential research directions for architecture refactoring.


Industrial software systems are typically complex and long-lived. Consider Windows operating system for example. It has grown to more than 50 million LOC over the last 25 years. Evolution at such a scale of time and size poses a threat to the structural quality of the software. Hence, periodic architecture refactoring is required to maintain the structural quality of an evolving software system. In addition, such refactorings are mandatory for the success of the software product as they facilitate an easier integration of new significant features. For instance, a major refactoring effort was carried out for Windows while evolving from Vista to Windows 7 version. The performed refactoring was targeted to address various layering violations and to improve dependency structure [Miryung 2014].

The Java library is another example of such a large-scale refactoring. Since the release of its first version in 1995, Java library has evolved considerably in size and complexity. The above figure shows complex dependency structures within Java libraries. The red lines show the dependencies that are undesirable or bad. [Figure courtesy – Oracle]

It is extremely difficult to refactor such a codebase because it serves a huge user base. A small tweak in such a codebase could end up breaking thousands of programs worldwide. Any major change in such a codebase has to cope up with challenges such as ensuring backward compatibility.

Java 9 – with its project Jigsaw – is introducing module feature in the language [Reinhold 2014]. With that, the JDK and JRE are also being refactored to have a modular structure (see figure below). [Figure courtesy – Oracle]

Screenshot 2016-02-17 21.14.30

Potential research directions

From a detailed analysis of existing literature on architecture smells and refactoring, we identify the following areas for further research on this topic.

  • Catalog of architectural smells: Various authors have made attempts to catalog architectural smells and corresponding refactorings ([Babar et al. 2013], [Lippert and Roock 2006], and [Garcia et al. 2009]). However, a comprehensive catalog of architectural smells with detailed explanation, examples with context, their technical and economic impacts on the software product, and refactoring suggestions is still missing.
  • Tool support: Currently, architecture refactoring is performed ad hoc without adequate tool support [Terra et al. 2012]. An ecosystem of tools for detecting architectural smells and providing refactoring recommendations is severely lacking.
  • Empirical studies: Though there are a few case studies reported on architecture smells or refactoring (such as [Kumar et al. 2011]), there is a lack of empirical studies on architectural smells or refactoring. Such an empirical study on large software systems may reveal many interesting insights about the characteristics of architecture smells and their impact.

Michael Stal [Stal 2007] made the following observation in 2007:

“From my viewpoint, we have just started to understand and apply refactorings in a more holistic context. As the old saying goes, we have just seen the tip of the iceberg. Architecture Refactorings will guide architects to identify potential problems in a software architecture and also provide them with refactorings to solve those issues.”

In the last decade, much progress has been made on architecture smells and refactoring but there is still a long way to go.


  • [Miryung 2014] Kim, Miryung, Thomas Zimmermann, and Nachiappan Nagappan. “An Empirical Study of Refactoring Challenges and Benefits at Microsoft.” IEEE Transactions on Software Engineering 7 (2014): 1-1.
  • [Garcia et al. 2009] Joshua Garcia, Daniel Popescu, George Edwards, and Nenad Medvidovic. 2009. Toward a Catalogue of Architectural Bad Smells. In Proceedings of the 5th International Conference on the Quality of Software Architectures: Architectures for Adaptive Software Systems (QoSA ’09), Raffaela Mirandola, Ian Gorton, and Christine Hofmeister (Eds.). Springer-Verlag, Berlin, Heidelberg, 146-162. DOI=10.1007/978-3-642-02351-4_10
  • [Kumar et al. 2011] Kumar, M. Raveendra, and R. Hari Kumar. “Architectural refactoring of a mission critical integration application: a case study.” In Proceedings of the 4th India Software Engineering Conference, pp. 77-83. ACM, 2011
  • [Terra et al. 2012] Ricardo Terra, Marco Tulio Valente, Krzysztof Czarnecki, and Roberto S. Bigonha. 2012. Recommending Refactorings to Reverse Software Architecture Erosion. In Proceedings of the 2012 16th European Conference on Software Maintenance and Reengineering (CSMR ’12). IEEE Computer Society, Washington, DC, USA, 335-340. DOI=10.1109/CSMR.2012.40
  • [Reinhold 2014] “The Modular Java Platform and Project Jigsaw”, Mark Reinhold, JavaOne, San Francisco, 2014
  • [Stal 2007] Stal, Michael. “Software architecture refactoring.” In Tutorial, in The International Conference on Object Oriented Programming, Systems, Languages and Applications (OOPSLA). 2007. Also blog post: (last accessed 09-May-2015)
  • [Babar et al. 2013] Muhammad Ali Babar, Alan W. Brown, and Ivan Mistrik. 2013. Agile Software Architecture: Aligning Agile Processes and Software Architectures (1st ed.). Morgan Kaufmann Publishers Inc., San Francisco, CA, USA.
  • [Lippert and Roock 2006] Martin Lippert and Stephen Roock, Refactoring in Large Software Projects: Performing Complex Restructurings Successfully. John Wiley & Sons. 2006.