Capturing complexity: The 1st law of systems engineering
CSD&M is the French INCOSE conference that took place last week in Paris. By far the most exciting keynote was given by Prof. Olivier de Weck, who is in search of a universal law of complexity. In the following I will present the law of complexity that he has discovered. You can read about the topic here by the way, there is a lot to read at SE-Trends.
"Laws" in the natural sciences can be deceptively simple, such as E=mc² (equivalence of mass and energy) or ΔU = Q - W (1st law of thermodynamics).
What quantifiable property can be found in systems science? Complexity!
Olivier de Weck set himself the goal of finding a law for systems science as well. To this end, he first posed the question of which central, quantified property of systems should be used for this purpose. Here are the slides of the presentation.
Such a property should have two characteristics. Firstly, it should be useful, and secondly, it should be quantifiable. He quickly came across complexity that fulfilled both.
Measuring complexity
A useful metric for complexity, for example, is a Design Structure Matrixwhich can be used to quickly express complexity in the form of a percentage. Useful, but not nearly accurate enough.
Instead, he identified three components of complexity that can be used to calculate the overall complexity:
C1 - Inherent complexity, after all there are simple components (e.g. screw) and complex ones (e.g. integrated circuit).
C2 - Number and complexity of interfaces
C3 - Topological complexity, e.g. a distributed architecture is more complex than a centralized architecture with the same number of components.
These variables can now be used to formulate the first law of systems engineering:
Consequences
This law has concrete consequences. In particular, we need a certain level of complexity - otherwise no one would buy our products if they could not do more than the products that are already on the market. The following image shows this dynamic, with customers and competition as drivers of complexity.
In addition to functional and structural complexity, there is also organizational complexity, which, according to Conway's lawdepends on the complexity of the product to be developed.
Since our goal should be to minimize the effort required for development without jeopardizing success, several conclusions can be drawn from what has been said so far:
- We should set a budget for complexity - just as time, money and resources are budgeted, budgets should also be set for complexity
- Iso-complexity trade-offs - We have described three components of complexity, but which makes more sense: complex components with a simple architecture, or simple components with a complex structure? In part, this depends on the competencies of the implementing organization.
- Development effort can be optimized - With the help of these correlations, we can optimize development, not only in terms of costs, but also in terms of added value for the customer.
Not yet at the end
Much of what has been presented still needs to be scientifically substantiated and further investigated, but the results so far are extremely exciting, and not only that: they are of practical relevance. I will continue to look into this topic.
Image sources Michael Jastram (cover), Olivier de Weck (diagram)
