For me personally properties such as the following ones are important so that I consider a software architecture as beautiful and elegant:
Simplicity: A software architecture should be as simple as possible but obviously not simplistic. If an architecture reveals unnecessary complexity, it is almost impossible to capture the strategies and tactical design behind the architecture. This is strongly coupled with readability. To check whether a software architecture is simple, ask the chief architect to call a person who has never seen the architecture before. The architect should then in no more than 5 minutes explain the architecture to the said person. If the person can grasp the fundamental architectural idea within that time, then the architecture should be simple. Another related issue in this context is expressiveness. An architecture that is expressive implements a (domain) model consistently. Hence, it is very easy to find the key domain entities and use cases in the architecture. I am emphasizing the domain model, because some (ugly) software architectures tend to mix implementation issues with domain entities which makes them not expressive at all. Separation of concerns is one of the means to achieve expressiveness.
Orthogonality or conceptual integrity means that within a particular software architecture the same solution is applied to address the same problem (context). This is where patterns come in: using the same patterns for the same problem contexts is important. Likewise, it is essential not to unnecessarily reinvent the wheel again and again. This is also sometimes mentioned as the concept of least surprise. Of course, orthogonality is not constrained to patterns. For instance, a software architecure lacks orthogonality if you find different kinds of error handling strategies or memory management strategies all over the system. Note, that orthogonality is closely related to simplicity and expressiveness.
Correctness: Even, an expressive and orthogonal system might be plain wrong. If you like to get a spreadsheet application from a development team, you won't be very happy as a user if you receive a text processor instead. Correctness is not limited to functional aspects. A system that does the right thing but takes an incredible amount of time for each activity is also considered incorrect from a user perspective. Correctness might be improved by re-use. Re-using well-proven components or designs instead of inventing your own stuff is obviously helpful.
Symmetry is an important topic as well. There are two kinds of symmetry, structural and functional symmetry. Structural symmetry is tightly coupled with conceptual integrity (see above). Functional integrity means for eaxmple: when there is an open-method there should also be a close-method. Breaking of symmetry in this context may lead to incorrect systems. Kevlin Henney used functional symmetry to illustrate why he considered the GoF's factory pattern as incomplete. In the factory pattern there is a create-method that helps to hide all the complexitites of object creation from an object user.The factory pattern states that it is applicable in all situations where object creation is rather complex. Kevlin argued that when object creation is complex, then object deletion is also complex in most circumstances so that there should also be a delete method in the factory pattern.
Of course, this list is far from being complete. I just introduced some points to give you the idea.
There are also some signs when an architecture doesn't reveal architectural beauty. For example, violation of layering or dependency cycles in the design are always signs of severe problems or design erosion which brings me to another point:
Often, architects and developers come up with very beautiful architectural design in the beginning. After some change requests or extensions to the system which are often applied with time pressure, the software architecture erodes and with it the architectural beauty. This means, architectural beauty is not carved in stone but might disappear after a while, if you are not cautious.
All of these properties of software architecture that I consider as preconditions for architectural beauty are also qualities. They help to achieve a specific purpose. Thus, architectural beauty is not independent of architectural quality. Both are only two sides of the same coin.
5 comments:
Great post, loved it.
I particularly like your "simplicity" definition, yet I have a doubt: ok, if an architecture is simple enough I should be able to explain its fundamental idea(s) to another (competent) person in - say - five minutes.
But don't you think this would depend also on the perspective I look at the architecture from?
I mean, I could look at a project as a whole system, or as interacting subsystems and so on, yet never going deep into implementation details, but only focusing on the architectural issues.
I could hide or deal with more or fewer subsystems' architectural details and interaction issues.
The more complex the project is, the higher the level of my architectural description. Consider a generical OS architecture...someone could describe it in some minutes, but he/she is no way close to show its actual complexity.
Wouldn't this lead to a fake sense of actually understanding the underlying architecture, or at least its complexity? Or am I just missing the point?
Savino,
you mentioned some excellent points. I am speaking about the strategic architecture with all the core entities. If I would dig deeper, I also had to deal with tactical issues and subsystems in detail. However, I consider architecture viewpoints with a tree-like organization in this context. The root defines the strategic architecture and on the deeper nodes the architecture uncovers more details such as subsystem architectures. Each node in the architecture should be simple to explain.
However the tree shouldn't be too broad for that purpose. There is the old psychological issue that a human mind cannot understand more than 7 parts at the same time. Thus, if one hierarchy level consists of more than 7 lower levels, you won't understand the architecture easily.
In summary, I don't propose a naive approach (which would be simplistic), but only an approach where structural organization allows understanding of each abstraction level.
Does that make sense?
Of course it makes sense Michael. :) Thanks a lot for your reply.
Like you mentioned many of these are adhered and kept in mind, in the early phases of a project, and most are aware of them. But maintaining it over time is something I am particularly interested in... And part of it requires starting the project by correctly understanding the problem domain. Once that is done, the usual iterate+refactor+iterate should lead you along a long way...
The strategic architecture is a interesting point of view...
Actually, there is the old psychological issue ..
Post a Comment