Layered Architectures

I like the description of the layered architecture provided in this chapter, and especially the parallels drawn with networking protocol stacks. Amongst the benefits provided by this type of architecture, I feel that the most important one is the ability to shield higher layers from the changes in lower layers provided that only the lowest levels, typically the hardware are subject to change. This type of architecture is more suitable for a stable networking system. As Steven says, this design pattern provides a way to decompose large systems that provide collaborating objects, and for consolidating segmented interfaces.
Reusing of functionality is also one of the benefits which I feel is important and representative of this architecture. However, the choice of implementing this architectural pattern is entirely upto the design team. This can be easily explained to them and it is also easy to demonstrate how each layer fits into the overall picture. In theory all of this seems very good, but it would require some efforts on part of the organization to get it right the first time. To quote Eric Evans, "If an unsophisticated team with a simple project decides to try a model-driven design with layered architecture, it will face a difficult learning curve". In a related paper, a study of the usage of layered architectures in the industry was conducted and they concluded that any number of layering diagrams were possible for a particular software architecture. The authors argue that none of the architectures under study made use of multiple layering criteria in their design. Overall, I think the status and meaning of the word "layered architecture" has undergone a lot of changes since the days of the OSI - 7 layer model and is evolving rapidly today.