The complexity of the systems and methods of "struggle" with it

We all design and implement systems one way or another. Be it software systems, infrastructure or platform solutions. And as part of this work, we are constantly confronted with the concept of a "complex system." As part of this note, I want to share my vision of the complexity of the systems and the "struggle" with it.

Let's start with the definition of the system. I like the definition given in System Architecture . Strategy and Product Development for Complex Systems . Translation sounds like this:

A system is a set of components and their connections. The functionality of the entire system is greater than the sum of the functionalities of its individual components.

This is a very important definition. It suggests that the system should generate "utility." If the system does not give an increase in "utility", in comparison with the components, its components, then probably such a system is not very necessary.

The next question you can ask yourself is what a "complex system" is. One can argue a lot about this, but in my opinion, a complex system can be called difficult to evaluate with a mind that is difficult to work with, difficult to understand, difficult to keep in mind all the interactions that occur in this system.

And here for us, as engineers, it is important to have a mechanism, some way to measure this complexity. As a base for this mechanism, the guys from MIT suggest using the well-known “magic number seven plus minus two”. On this subject there is an original study , as well as articles on Habré and TED presentations . In a nutshell, the idea of ​​all these studies is that a person’s “working memory” can simultaneously hold and work with a limited number of different objects. Here the concept of "various" objects is very important, as the brain struggles with the complexity of grouping objects. For example, connections between objects of the same kind or type can be remembered in the head as one connection. Or, more clearly - no need to imagine a system from a pile of mixed balls of different colors. It is enough just to group them in the head, to say that there are, say, five red balls, seven yellow and three blue. This simplifies working with the system, reducing the number of objects from fifteen to three. Therefore, in the context of assessing the complexity, we are talking about different atomic objects that cannot be grouped.

Ultimately, there are different estimates of working memory capacity. Someone talks about four objects, someone - about five, someone - about seven. In my reasoning, I will adhere to the classical approach - "seven plus or minus two . "

Based on these estimates, we can say that if it becomes difficult to work with the system, to keep its components and connections in memory, then, apparently, it exceeds the very limit of the capacity of "seven plus or minus two". This in turn means that this very “magic number seven” can be used as a basic estimate of the complexity of the system. I think that the following, so far, intermediate definition, has the right to life:

A complex system is a system consisting of 7 + -2 atomic components and their connections in various ratios.

Classic ways of dealing with complexity

Now let's briefly recall the classic ways or tools to deal with complexity at the design stage. There are few of them: abstraction, decomposition, hierarchy and hierarchical decomposition.

• Abstraction - a method that allows you to select the main function of the system or subsystem and hide the contents
• Decomposition - a method of partitioning the system into smaller blocks or components
• Hierarchy - a way of splitting the system into levels, where levels have a certain place in the structure and are located one above the other
• Hierarchical decomposition - a way that combines hierarchy and decomposition

All these tools are ultimately designed to simplify the individual subsystems of our system so that when working with each individual unit, it would “pop into the head” entirely.

What is it all about in the end

What do all these things give us? Simply put, the idea is to convert an unstructured set of system components to a certain structural form using various methods. At the same time, bearing in mind the magic seven, we can say that each block in the decomposition should not contain more than seven plus / minus two elements. Otherwise, upon a detailed examination of such a block, it will be difficult to control.

On the other hand, if we have a system with a large number of blocks divided into hierarchical levels, then the number of such levels, preferably, should not exceed seven (plus / minus two). As an illustration, I want to bring a slide from Fundamentals of Systems Engineering . As can be seen from the slide, the complexity of the system grows with an increase in the number of levels of decomposition.

Thus, the correct system design process can be described by the following thesis:

Do not build complex systems. Build systems with the required level of complexity.

Literature

• System Architecture . Strategy and Product Development for Complex Systems
• Fundamentals of Systems Engineering
• When the working memory is overloaded in humans, the synchronization between the three parts of the brain is disturbed.