Once upon a time, ... everything was simpler. And then we started making things and it became a lot more complex. How far?

Written on June 11, 2020.
Tags: systems, engineering, readings, complex

Table of contents

What’s is that about?

Where to start? I recently finished reading Engineering systems - Meeting Human Needs in a Complex Technological World by de Weck et al. This book does an excellent job at showing the evolution of engineering, how we have reached this notion of engineering systems and what characterize them.

Mixing the idea with a few other readings on the topics and trying to present my version of this. This might lack a bit of rigor but… hey, it’s a blog post after all: I’m just sharing some thoughts, make your own and share.

Simple systems

Long time ago, people use to build their own things and life was pretty simple back then. Pick cooking - cooking as in cooking for the purpose of feeding oneself, not as in to get your third Michelin star - as an illustration of a simple process: you mix sugar, flour, eggs, baking soda and butter, and cook it and you’ll get a cake. Might not be the best cake ever, but it’s going to be a cake. There is a pretty clear way to test for success, a recipe to get there, and the recipe is robust. If you step a way from it your are going to get a different cake but chances are it’s going to work just fine. Growing potatoes in your backyard falls in this category too.

Over time, specialization kicked in and craftmanship appeared as a way to produce ‘outcomes’ repeatedly - with better quality and production cost. Things were designed for use.

Complicated systems

For complicated systems, there is no single criteria to determine success has been reached but a collection of them. There is a recipe to get there but it is not robust. Steps need to be followed carefully or success will not be reached.

Process is an example of the mechanism used to drive that type of systems. They can be automated but stepping away from the recipe can lead to failure and specific attention need to be paid to guardrails. V-shape development process is another example that demonstrated some value for these systems. This is design for use at scale.

Complex systems

Complex systems are not simple and not complicated. They have no clear definition of success and there is no recipe. These are the systems where the dominant properties are defined by the interaction between their components.

The concept of emergence is central in complex systems: the entire system is more than the sum of its part. As with the ‘network effect’: in closed systems where the value each participant derive from belonging to it is proportional to the number of them. The total value sees a quadratic growth in the number of participants. Depending on the property we are looking at this can both be an advantage or an inconvenient that need to be controlled.

A car is example of complex system and its performance, reliability, and many other ‘ities’ are going to depend not just on a single part but on the interactions these have together.

In term of engineering, they pose significant challenges but it is still possible to build full scale prototypes that can be used to validate the properties and allowing to design for one goal: usually, the initial qualities. This is design for first time quality.

System of systems

Systems of systems come next in the complex-ification of things. They have no clear boundaries and are made of changing interactions of systems (which themselves can be complex). Their open or changing context makes their properties changes too and building a prototype is either impossible or useless. It would either not capture all the context or that is possible at a point in time would no longer be relevant very rapidly. A company like Tesla can make a prototype of their cars but this is not going to fully capture the interaction with their network of charging stations and the collective learning of the fleet of car being driven in the wild.

From an engineering standpoint, in this context, the design needs to focus on building for continuous quality and accommodate for multiple, possibly conflicting and definitively changing goals. Systems have to be designed for change as they are inevitable even during their lifetimes and after they are out in the wild. For software, Building Evolutionary Architectures: Support Constant Change by Neal Ford et al. is a great read on the subject of building for change.


The interaction is between engineering and complexity is a fascinating topic which is far from having been tamed.

In next post, I will summarize the characteristics of these systems and explore how they can be “navigated” from an engineering perspective. Hopefully, I will not need 4 years to write it.

June 11, 2020

Creative Commons License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. Powered by Hakyll.