Layers

When we develop most software systems, I think we subconsciously try to implement them using some variant of the layered structure because it's usually the most straightforward way to think about the problem. And I think we all know that by having many layers, it could introduce inefficiencies in some cases. But I don't think we can anticipate the other liabilities that the article describes until we get stuck during coding. For example, the liability of Cascades of Changing Behavior is something I missed several times in the past, mainly because it's difficult to predict what the implementation of the lower layer will entail. Its not until you're actually coding that you realize you need to make changes in every layer to accommodate errors that need to be propagated to the top (sometimes you do this because the service team wants to view lower layer error information at the GUI level). The "you don't know until you're actually doing it" argument can also be applied to the Unnecessary Work and Difficulty in Establishing Granularity Levels liabilities. I think applying a layers architecture is a good way to start designing, assuming that you can't think of a better architecture up-front. But once these liabilities begin to creep up, one may want to consider refactoring the code to conform to an alternative architecture. Or maybe it can be switched over to a Relaxed Structure like TCP/IP if it's an infrastructure system. As the paper says, "The main reason for this is that infrastructure systems are modified less often than application systems, and their performance is usually more important than their maintainability." One of TCP/IP's biggest philosophical complaints about layering is that it constrains data manipulation functions because optimizations of each layer have to occur separately (http://tools.ietf.org/html/rfc3439#page-7).

On a last note, this paper introduces us with some other architectural patterns such as the Blackboard Pattern, the Refactor Pattern, and the Microkernal Pattern. If you would like to take a closer look at these, check out this link http://www.vico.org/pages/PatronsDisseny.html