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.
