Simple is Beautiful

One of the most important architectural qualities is simplicity. If an architecture is simple, it is easy to understand, change, or apply. Simplicity is not necessarily the opposite of complexity, because complexity is often an inherent property of problem space, while simplicity refers to the fact how to efficiently cover problems in the problem space by concepts in the solution space. However, simplicity might help mastering complexity. The secret to simplicity in software architecture as in all other systems is to define core architectural elements which are simple, but can be combined in various ways resulting in a broad spectrum of emergent behavior. The human brain is an example for this fact. While the core elements of a brain such as the neurons and synapses are surprisingly simple, their combination might result in incredible complex interactions, basically so complex that we don't really understand how the brain works. Same for peer-to-peer systems or ant populations.

The fundamental properties of of these examples are as follows:

• The entities and their interactions are simple
• If any of these entities and interactions are removed, full coverage of the problem space is not possible anymore
• The same design principles are applied orthogonally throughout the system. Such design principles cover functional as well as non-functional properties
• The system design provides atomic components on top of which higher abstractions (e.g., subsystems) are built, thus resulting in a hierarchical instead of a flat structure

If you think about the properties above, you'll see that a violation of one of them immediately results in a non-simple (i.e., complex or simplistic) system. For instance, you might have simple entities and relations, but when the system consists of a giantic flat structure, you might be lost. Trying to understand Windows Vista by looking at its assembly code, simply does not work. Simple systems offer what I call architectural beauty. Just by using a small set of easy-to-understand concepts, you can even cover complex problems in a domain.

What architects tend to forget is the fact that humans are not able to consider and understand more than 7 entities at the same time.

Thus, upcoming Ultra Large Scale systems will only succeed if they rely on a simple fundament consisting only of a few core concepts that can be combined to a broad spectrum of emergent behavior.

Simple does not mean simplistic. A system is simplistic when its core elements are not capable of covering the whole problem space.

How can we achieve simplicity? Simple software architectures often reveal a high pattern coverage, use abstraction concepts such as components or services, and use the same solutions for the same problem contexts. Evolving a simple system might happen in two ways, by evolving the core concepts or by applying the available abstraction mechanisms.

By the way, in case you wonder how to check whether an architecture is simple: one test for simplicity could be the following. An architecture is simple when is can be explained to other experts in a few minutes without using visualizations.

It is important to mention that in a software project it is not sufficient to deal with simplity in the software architecture. Simplicity should also be the leading principle for other aspects such as the process, the tools, the technologies, the programming languages, the models, the DSLs, and so forth. Also keep in mind that it is generally insufficient if each of these aspects is simple. You might use a simple but powerful language such as Lisp and will be completely doomed to fail when trying to build a multi-tier enterprise system using Lisp even if the architecture is simple. This implies, that the combination of simple aspects must be simple itself. Therefore, consider simplicity a holistic approach.

Mind the "Keep it simple, stupid" principle to make your professional life simpler but not simplistic :-)