Principles of System Architecture
A map must first be legible. This means that the map must not over-compress the information of the system. It must also exist in a form that can be understood by those who will implement a system, whether that is in a diagram, a document, a software representation, or some other form. Like the map of a territory, a good architecture must be usable as a form of navigation for those who wish to build or maintain the system.
Albert Korzybski wrote about the ideas of maps and territories in mathematical semantics in his early 20th century paper. There have since been many versions of ideas like this. Similarly, this principle a loose interpretation of the idea that a system could be represented as a Category in Category Theory. In Category Theory, a functor is the morphism of one category to another, and thus leads to the idea that a well-structured architecture should behave like a category and be “functorizable”.
A system architecture is a representation of the system that exists or will one day exist in real life. For that system architecture to be good, it must demand the mental resources of a user of that architecture. This means that it must sufficiently compress excessive details while avoiding over-compressing information that requires attention or is of greater importance to the system.
When a system architecture achieves the proper balance of friction and seamlessness in the right places, then the user of the architecture can trust that architecture to sufficiently direct them, and the user’s mental burden can be offloaded. The user trusts that they do not need to create extra friction for themselves when things need to be double checked, the architecture will provide the appropriate amount of friction for them.
As stated before, entropy is the tendency of a system to progress from order towards randomness. To fight this tendency towards disorder, a good system architecture should aim to reduce the energy required to sustain the system. Energy here means all types of energy, including physical energy, human effort, or systemic energy. Any form of “entropy fighting” is considered energy output, and a good system minimizes the amount of energy input required.
An example of this would be two different systems, one that uses market forces to achieve its outcome versus one that uses government regulation. All else being equal, the one that uses market forces is a better architecture, because it uses the existing energy flow of the market to fuel its system rather than requiring the input of energy that is required by regulation.
Reducing side effects makes it easier to fight the tendency of a system towards entropy. One can think of side effects as “leaks” that may be harmless but have some probability of being harmful, especially at scale. Examples of side effects could be heat and sound in hardware systems, whereas in software it will mean any change to state caused by the function that is not the output of the function.
While this principle exists in different forms in many areas, my version is mainly derived from the core concepts in functional programming. Like in mathematical functions, functional programming is designed around functions that are idempotent and produce no side effects, making them flexible modules that are easier to work with conceptually.
↑ 5 References
When looking to design a system architecture, one will inevitably be faced with some problem that needs to be solved. This principle highlights the need to not stop at attempting to solve the symptom of the problem, but to also go “upstream” up the causal chain and discover the root cause of the problem within the system.