BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Architectural Refactoring: A Task-Centric View on Software Evolution

Architectural Refactoring: A Task-Centric View on Software Evolution

This article first appeared in IEEE Software magazine. IEEE Software offers solid, peer-reviewed information about today's strategic technology issues. To meet the challenges of running reliable, flexible enterprises, IT managers and technical leads rely on IT Pro for state-of-the-art solutions.

 

Software-Intensive Systems often must be reengineered—for example, owing to unpredictable business changes and technology innovations. Many reengineering activities affect these systems’ software architecture. One popular reengineering practice is code refactoring. Given the success of code refactoring, it’s surprising that architectural refactoring (AR) hasn’t taken off yet. To help remedy that situation, I show here how AR can serve as an evolution technique that revisits architectural decisions and identies related design, implementation, and documentation tasks.

Introducing Architectural Refactorings

A refactoring aims to improve a certain quality while preserving others. For example, code refactoring restructures code to make it more maintainable without changing its observable behavior. Code refactorings work on machine-readable entities such as packages, classes, and methods so that they can leverage data structures from compiler constructions such as abstract syntax trees. 1 ARs deal with architecture documentation and the architecture’s manifestation in the code and run-time artifacts. So, a single architectural syntax tree doesn’t exist. ARs pertain to

  • components and connectors (modeled, sketched, or represented implicitly in code),
  • design decision logs (in structured or unstructured text), and
  • planning artifacts such as work items in project management tools.

ARs address architectural smells, which are suspicions or indications that something in the architecture is no longer adequate under the current requirements and constraints, which might differ from the original ones. An AR, then, is a coordinated set of deliberate architectural activities that remove a particular architectural smell and improve at least one quality attribute without changing the system’s scope and functionality. An AR might negatively in uence other quality attributes, owing to conficting requirements and tradeoffs.

In my view, an AR revisits certain architectural decisions 2 and selects alternate solutions to a given set of design problems. A decision’s execution leads to related engineering tasks, which fall into these categories:

  • Tasks to realize structural changes in a design. Such changes have a larger scope than code refactorings and deal with components, subsystems, and systems of systems (and their interfaces).
  • Implementation and configuration tasks in development and operations (depending on the AR’s viewpoint).
  • Documentation and communication tasks, such as modeling activities, technical-writing assignments, or design workshop preparation and facilitation.

Tabel 1. A structured representation of an architectural refactoring (AR).

My decision- and task-centric view on ARs complements and extends that of Michael Stal, who published the first catalog of ARs in 2007. 3 To document his ARs, Stal uses a simple pattern format with three sections: context, problem, and general solution idea. His ARs include “Break Dependency Cycles” and “Splitting Subsystems,” addressing the architectural smells “dependency cycles” and “inadequate partitioning of functionality.” 4

An Example and a TaskCentric Template

The chief technicians at Doodle.com explained in their blog why they switched from using MySQL to Mongo DB after several years of pro- ductive use of their collaborative on- line calendar- scheduling service. In this case, the architectural smell was that migrating large production databases after an SQL schema change 5 (such as adding a column to a table) took too long. The affected quality attributes were the productivity in development and operations as well as the performance and scalability of the database and the data access layer. The cause of the smell’s symptoms was that relational database management systems weren’t designed for that usage scenario: they could handle it, but not optimally.

The solution was to revisit the ar- chitectural decisions regarding the database paradigm, query APIs, and database provider. The technicians decided to use the document-oriented paradigm, one flavor of schemaless NoSQL, and MongoDB as the document database provider. This change improved migration management at the expense of administration and coding effort—new solutions for data access, transactions, and backup management were required.

The Doodle example qualifies as an AR because it revisits certain architectural decisions to improve a quality attribute but doesn’t involve code refactoring. The structured AR representation in Table 1 makes it easy to comprehend and apply this AR to a similar project. This example also proposes an AR documentation template; each row in Table 1 is one template entry. Figure 1 shows the resulting template structure.

When using the template shown in Table 1 to document your own ARs, the AR name should be expressive, such as a metaphor. Unlike pattern names, which are typically nouns, AR names should be verbs, like code-refactoring names. The context section can include information about the abstraction level in a software engineering method or viewpoint in an enterprise architecture management framework. Because the AR describes a design change, two solution sketches can be provided: the design before applying the AR, and the design after applying the AR. Architectural elements form a link to the structural design, which might be modeled explicitly, sketched informally, or represented implicitly in code. The task description might refer to work items in agile planning tools or to software engineering activities. Some execution tasks can be automated (just like the execution of many code refactorings), but not all,because ARs operate on a higher abstraction level and larger scale than code refactorings.

FIGURE 1. The anatomy of an architectural refactoring. The left side presents an architectural smell as observed in a particular context (such as viewpoint or abstraction level), pertaining to certain quality attribute (QA) concerns. The right side sketches the refactored architecture and identifies related design, implementation, and documentation tasks. The architectural decisions to be revisited serve as the glue connecting these two parts.

Architectural- Refactoring Catalogs

Let’s now go broad and look at additional ARs. Table 2 lists basic ARs in two dimensions: architectural viewpoints and types of change. These ARs can be represented as instances of the task-centric template in Figure 1. For example, the tasks for “Introduce Cache” include deciding on a lookup key and cache invalidation strategy, cache distribution, and so on.

In the future, domain- and style-specific AR catalogs might appear, perhaps for financial- services software, game development, or cloud computing. For example, here are three candidate ARs for a prospective catalog for enterprise application modernization:

  • Move session state management (for example, from the client or mid-tier server to a database to improve horizontal scaling and to better leverage cloud elasticity).
  • Replace scalar parameters with a data transfer object in a service interface contract (to reduce the number of remote calls).
  • Streamline a Web client (to reduce the client workload and processing capabilities).

Both basic and specific ARs provide an opportunity for cross-community collaboration between

  • Architecture and development. AR execution might involve one or more code refactorings, which must be stitched together.
  • Architecture and project management. AR descriptions organized according to the AR template can serve as planning tasks; the need for AR is an expression of technical debt.
  • Architecture and operations (ArchOps). ARs in the deployment viewpoint can serve as a means for communication.

Tabel 2: Viewpoints, types of ARs, and the associated ARs. 

It remains to be seen how to efficiently share and execute ARs. Are templates and catalogs good enough knowledge carriers, or are modeling and collaboration tools more appropriate? Web-based delivery of knowledge has a natural appeal, as Wikipedia demonstrates. Code refactoring started with a book and formal groundwork. Refactoring tools (such as those in Eclipse) were developed much later, after content and theory were established and experience was gained. Any AR tool support would need to tie in with modeling tools supporting UML or architecture description languages, but such support has yet to emerge.

Acknowledgments

Types of change Elaboration ARs Adjustment ARs Simplification ARs Functional Split Component Responsibility Expose Internal Feature as Component Responsibility Concurrency, Information Shift Responsibility to New Component Split Layer (Move Components to New Layer) Distribute Processing (Introduce Concurrency) Shift Responsibility to Existing Component I thank Christian Bisig and Mirko Stocker of the University of Applied Sciences of Eastern Switzerland, Rapperswil, for reviewing earlier versions of this article. I also thank the attendees of my OOP 2014 and GI FG SWA 2014 presentations on architectural refactoring for the cloud for their helpful feedback.

References

  1. M. Fowler, “Definition of Refactoring,” blog, 1 Sept. 2004.
  2. O. Zimmermann, “Architectural Decisions as Reusable Design Assets,” IEEE Software, vol. 28, no. 1, 2011, pp. 64–69.
  3. M. Stal, “Software Architecture Refactoring,” 2007.
  4. M. Stal, “Refactoring Software Architecture,” Agile Software Architecture, 1st ed., M. Babar, A. Brown, and I. Mistrik, eds., Morgan Kaufmann, 2013.
  5. P. Sevinç, “Doodle’s Technology Landscape,” blog, 14 Apr. 2011.

About the Author

Olaf Zimmermann is a professor and institute partner in the Institute for Software at the University of Applied Sciences of Eastern Switzerland in Rapperswil. Contact him at ozimmerm@hsr.ch.

 

 

This article first appeared in IEEE Software magazine. IEEE Software offers solid, peer-reviewed information about today's strategic technology issues. To meet the challenges of running reliable, flexible enterprises, IT managers and technical leads rely on IT Pro for state-of-the-art solutions.

Rate this Article

Adoption
Style

BT