No Complex Systems, Please

Is the objective of a systems engineer to make complex systems? Or is it to solve complex problems? Should we contemplate reducing the complexity of the system when solving complex use cases?

The answer is that we are here as engineers to solve complex problems, not to make complex systems. In my prior post 2.6 Bits of Information at a Time, I talked about cognitive limit for a person to process information. When solving difficult and complex problems, we shall engineer systems as simple as we can, not as complex as we can. I initially learned it from my professor Marcos Intaglietta (a.k.a Dr. I).

At that time I was in a bioengineering graduate class at UC San Diego. And we were asked to model and present to the class a biosystem of any choice as the final project. I picked a problem of solving a drug aerosol adsorption profile in the human nasal passage.

The model had to be complex because I was dealing with calculating the concentration of the drug over time and space, with convection of air flow rate, temperature changes, complex geometry, nostril hair pattern, adsorption rate, plus many other variables. So I started looking at all those dimensions and came up with a big set of partial differential equations. When I had a chance to talk to Dr. I about my approach, the first thing he said to me was, “Wait a minute, wait a minute, a set of PDEs? That is too complex, Feimo!” I was a bit discouraged, thinking as engineering graduate students, aren’t we supposed to come up with fancy PDEs like there is no tomorrow? So fancy that no one can easily solve those equations. Dr. I started drawing on the black board a one-dimensional picture of concentration and space to tell me think simple. I took that initial step and went to the library. After a while I found a closed-form solution. No computer was needed and I could solve the problem.

Today’s problems we are solving are pushing boundaries. Often, we need to have more fancy features, or squeeze the last drop of performance of some already impressive specifications. Therefore, the system necessarily becomes increasingly complex. However, if we let that bloating complexity grow unchecked, we will be over budget, both time and money, very quickly. In fact, empirical evidence has shown that the development cost of a product is proportional to the system complexity to the power of 1.5.

Therefore, we need to consider a limitation of budget when we perform system analysis. Here is one very simple model to quantify system complexity.¹

C = C₁ + C₂ × C₃.

C is the total system complexity. C₁ represents the sum of complexities of individual components of the system. C₂ is the sum of the pair-wise component interfaces. And C₃ is the most interesting: It is the system architecture! How? The architecture here is the system topology. C₃ is the graph energy and is calculated by the sum of the absolute eigenvalues of the adjacency matrix.

This representation of system complexity is a direct adaptation from organic chemistry for studying big organic molecules’ structure complexity.

Having numeric values of complexity enables us to quickly and objectively evaluate and compare system complexity. Keep in mind the development cost to the company as a function of system complexity is exponential! For competing designs, it will be straight forward to select a design that has lower total complexity.

Reference: 1. Sinha, K., Structural complexity and its implications for design of cyber-physical systems. Dissertation, MIT, 2014