At first look, that can seem well-worn. Since software exists the theorists praise us the merits of the modularity. The real voyage of discovery consists, not in seeking new landscapes, but in having new eyes. What misses cruelly nowadays it is a demonstration of the practice. We only have to consult the literature on the subject to be convinced. For example, lately I was reading version 2.0 of the  Application Architecture Guide published by the Pattern & Practices group at Microsoft. They explain in detail the need for partitioning into layers to produce quality architecture. However, nothing is written about best practices to correctly design the visible interface of a layer. In the same way, anywhere, they explain the practice to reduce the coupling between the modules; practices which ensures to be able to test in an autonomous way (in a test bed) each layer without having to assemble the whole system. Yes, the modular architecture seems a well-worn subject but, but still today, the training in regard with modular design is defective and this one remains a challenge for a great number of organizations.

Here are three things which I like about the Application Architecture Guide :

1. It seeks to show all the options: The architects build models. They create structures to reduce complexity and to simplify the problem to be solved. This guide does not present only the heuristics necessary to achieve this work but also the most common examples of predefined models (applications archetypes).
2. It seeks to explain the design process: The guide explains in what the business needs and the deployment constraints are stakes paramount which must be analyzed early in the process of design.
3. It confirms that the layer is the unit of modularity of the application architect: The programmers took nearly fifty years to recognize that the unit of modularity par excellence is the object (the class). From the omnipresent place of the layer in this guide, it clearly demonstrate that the layer is the module to be privileged by the architects to create a simple structure to partitions the concerns of the application.

Here are three things which I would like to improve?

1. Add a better separation of the concerns: The Architecture Frame seems to me a hold-all. There would be place for a better classification. It is the same for the architectural styles; the guide try to compare apples and oranges. For example, I do not believe that layered architecture and N-Tier deployment are comparable architectural styles. The first one concentrates on the logical internal structure while the second is concerned with considerations of deployment.
2. Improve the design process: The greatest leverage in architecting is at the interfaces. Partitioning the concerns of the application requires layers with a unique role and a well defined contract. It is important to put the emphasis on the need to express not only the specifications but the dynamic behavior of the interfaces between the layers. It seems to me that it is paramount to add this in the design process.
3. Explain clearly what composes an interface: The interface of a layer is a list of the allowed operations with an explicit description of the expected dynamic behaviors. For example, one should find for each operation the pre and post conditions as well as the invariants. Once we have explained what an interface is, we should start discussing implementation practices such as the “Abstract Interface” and the “Concrete Façade” (Common Design Type). However, it seems important to me NOT to present “Dependency Inversion” and the “Message based Interface” as implementation practices. They are rather practices for procedures invocation.