For any evaluation of architecture, the natural question is raised whether the architecture is good and the common criteria to assess this quality is not common for all reviewers. You can have some:

- It seems that the coding standard are not followed well –> Wrong assessment due to quality of design is not related to coding standard.

- The performance of system is great –> The performance result is not the main factor of evaluating system performance, of course the bad quality can cause the impact to system performance.

- The architecture is designed very complicated and it is created by a “guru” guy –> the complicated is the signal of bad design, we have no design for prediction purpose and the fame of some one is not the main factor to decide the quality of design.

- The architecture applies many well-known pattern in practices –> You know that the patterns are applied correctly depends on the context of business scenario. No one pattern is right for all cases.

Well, after reading my arguments, you will ask me what are the criteria to assess the quality of architecture. I just can say “The architecture is designed with high quality if they are followed object oriented design principles”. Pattern is described is GoF books or any ones must be follow the design principles/practices. Any violate can cause the quality of design becomes bad. Here are the design principles that are described detail on Object Mentor

1. The Open/Closed Principle: Software entities (classes, modules, etc) should be open for extension, but closed for modification.
2. The Liskov Substitution Principle: Derived classes must be usable through the base class interface without the need for the user to know the difference.
3. The Dependency Inversion Principle: Details should depend upon abstractions. Abstractions should not depend upon details.
4. The Interface Segregation Principle: Many client specific interfaces are better than one general purpose interface/
5. The Reuse/Release Equivalency Principle: The granule of reuse is the same as the granule of release. Only components that are released through a tracking system can be effectively reused.
6. The Common Closure Principle: Classes that change together, belong together.
7. The Common Reuse Principle: CClasses that aren’t reused together should not be grouped together.
8. The Acyclic Dependencies Principle: The dependency structure for released components must be a directed acyclic graph. There can be no cycles.
9. The Stable Dependencies Principle: Dependencies between released categories must run in the direction of stability. The dependee must be more stable than the depender.
10. The Stable Abstractions Principle: The more stable a class category is, the more it must consist of abstract classes. A completely stable category should consist of nothing but abstract classes.