Interview: Michael Stal on Architecture Refactoring

Posted by Niclas Nilsson on Mar 25, 2008

Sections

Architecture & Design,

Enterprise Architecture

Topics

Architecture ,

Enterprise Architecture ,

Design

Tags

Patterns ,

Refactoring

In this interview, Michael Stal describes what architecture refactoring is about and how it relates to both code refactoring and patterns. He describes some architectural refactorings by giving real work examples from his work as Siemens, and he elaborates on some situations where you may want to avoid doing this kind of refactorings.

From the interview:

One of the most typical examples is, if you are a software architect in a project and as I said before normally you are trying to be very elaborate, you are trying to be very sophisticated only to the changes in a very systematic way, but that’s not the way it works of course in practice. So basically what happens after a time that sometimes in space and time you get situations where your architecture gets messy. For instance you get dependency cycles and these dependency cycles are one of the most obvious problems or all of the sudden you subsystem A depends on a subsystem which depends on a subsystem C which also depends of you original subsystem A, which makes the system less testable because if you have to test A, you also need to touch B, C and so on. If you want change something in A you have a dependency on B, so you have also to change something in B and all of these problems are really obvious. One of the architecture refactorings which really is applicable to this kind of situation is how to break dependency cycles. For instance, one solution could be just inverting one of the dependencies, so instead of having a dependency from A to B, try to come up with a dependency from B to A instead, in order to break this kind of dependency cycle.

Michael also describes when he went out looking for literature and other writing in this area and found virtually nothing written about it, and what he hopes to do about it.

Watch the "Michael Stal on Architecture Refactoring" interview.

1. Back to top

   Architecture isn't in the code?

   by Jeremy Wales

   I must confess, I don't understand his distinction between architecture refactoring and code refactoring. Does he just mean you need to keep your diagrams up-to-date as you refactor the code? Otherwise, his examples of architecture refactoring would appear, to me at least, to be classic examples of code refactoring: Got dependency cycles? You would probably refactor to a pattern that loosens the coupling; Got two hierarchies and then realize that in your domain there's only really one? Sounds like refactoring toward deeper insight.
   
   

   Have I missed something? I may well have as my XP leanings get me riled at any hint of separating architecture from code :-)

   Reply

2. Back to top

   Architecture Refactor

   by Pete Haidinyak

   I use Structure101 (www.headwaysoftware.com) and know in 'realtime' (intellij plugin) when I have caused an unwanted dependency in the application I am writing. It's a cool tool to help keep your architecture 'pure'.

   Reply

3. Back to top

   notes about Architecturing Refactoring

   by William Martinez

   Just to clarify some of the ideas.
   
   
   
   Refactoring is changing of code in order to improve design without changing functionality.
   
   
   
   To me, architecture and design are higher level coding. Code (micro-design) has to be the same solution, just more detailed, than the actual design (Tactical level) which is at the same time a more detailed description of the solution from the architecture design.
   
   
   
   Thus, a dependency is reflected in all three levels. There is no way a dependency may be in one level and not in another one. You may not have the best view to catch it, though. Maybe you have no detail in a higher level to see that dependency (a dependency is inside one class or between classes inside a functional unit), or looking at code you cannot detect a global dependency (usually three+ way dependency).
   
   
   
   A refactoring in any part may affect any of the other levels, so all should be maintained up-to-date. A refactoring made from strategic level will impact coding, 90% of the time. I code is actually well written, changing a communication way from WS to REST for instance, will require changing probably one class and all should work the same. If it is all tightly coupled, then changing that may require rewriting half the application.
   
   
   
   There are several more issues about this. It is interesting, so I may post something more related to this in my blog .
   
   
   
   
   
   William Martinez Pomares

   Reply

4. Back to top

   DSM Methodology might help

   by Han van Roosmalen

   Since a few years some tools based on Dependency Structure Matrix methodology exist. I use Lattix quite extensively. This tool lets you see the current state of the architecture as you have modelled it conceptually against the realised architecture. Before you want to refactor you can manually insert scenario's and see how those will work out and what will be affected.
   
   Lattix support an ever increasing number of platforms, like Java (incl Spring and Hibernate), .Net, SQL Server, Oracle, Delphi Pascal, C/C++. Buildtime it checks for dependency violations, so there is a great way to measure deviations to the intended architecture.
   
   The method proves to be very helpful to architects, and other less technical people. It opens discussions based on what you see in the matrix in stead of gut feeling.

   Reply

• Older >