light My Insights: Ackoff was (and is through his legacy) an inspiring thought leader and promoter of System Thinking. This 15 minutes talk leave no doubt of that and is as a great motivation of why systems thinking perspective is key to approach problems and the design of systems. In a nutshell, and paraphrasing Ackoff: “a system is not the sum of the behaviors of its parts, but the product of its interactions”. Given this, if we are purely focusing on the parts in isolation, this will never yield to the maximizing the properties (and efficiency) of the overall system. This is why I strongly believe that when building software products we can’t purely focus on the “technical system” to be built (or worse, single parts of it). We must understand the customer, but also make sure we consider (empower) the people who will actually be building the product (technical system). Only then we will be able to maximize our impact (and effectiveness). This may not be trivial, but failing to do so will lead to all sorts of challenges that will block the improvement of the overall socio-technical system, or even degrade it.

(Subscribe here or follow me on Twitter to get notified about new TLA_insights)

Analysis & Summary

The insights and notes of this record are inspired and driven by a short talk from Russell Ackoff on the core ideas Systems Thinking [System-Thinking-Ackoff] (video below). Ackhoff is a well known figure in the systems thinking world and this talk is a great 15 minutes 101 on this topic.


He starts by sharing that many “project failures” come from the fact that such projects don’t follow a systems thinking approach. They tend to be “anti-system applications”, mostly approaching the problems from “partial/local/reductionistic” perspectives.

He then goes on defining what is a system: “a whole that consists of parts, each of which can affect its behavior or its properties”. He gives the human body as an example of a system made of many different interacting parts, each of which can affect the human body behaviors or properties. Each part has inter-dependencies on other parts of the system, and as such the system cannot be divided into its sub-parts without loosing its properties. To emphasize this, he shares another rather interesting example: a car (as a whole) can move, however that property is lost if you break the car into parts (e.g: engine alone cannot move). This is why “a system is not the sum of the behaviors of its parts, but the product of its interactions”.

The next point mentioned relates with “systems of improvement”. He makes a blunt (but so painfully real) claim here, namely: “if we have a system that is directed at improving by approaching its parts separately, you can be absolutely sure that the performance of the system as a whole will not improve!”. He showcases this with another brilliant example: bring the 200 best cars in the world; take each best car part from the whole group of cars; and then put all the best parts (from all cars) together. What do you get? For sure not the best car! Why? Because the parts don’t fit with each other. This happens because the form/design of the parts depend on the system context they are being designed for.

Notes: This is so intuitive, however we still live in a world where “reductionism” (i.e.: break everything into parts and optimize parts in isolation) is the most prevalent approach. This is true on how we build Software (our teams, architecture, etc.); but also on how we work and collaborate as societies. The COVID-19 pandemic is a great example of this: each country takes its own local approach and forgets that this virus is not going to stop at the borders (“boundaries”). Such challenges require joint efforts (of the parts, i.e.: countries) and solving the problem from an holistic manner (in the overall system, i.e.: world). Similar challenges are coming with global warming…

On the next point Ackhoff shares some great insights on the challenges and approach for the “architect of systems”. On his words this is a person that should be able to understand the system as a whole and how its parts interact to create the whole. An architect cannot properly design without that perspective (at least understand the “surrounding scope system”, where the design should fit and relates with). He shares the example of a house Architect. She starts with the overall design of the house (that is the system she is looking at), and only then the rooms that fit the design of the house. In this process she may discover ways to improve the quality of the rooms, and that may improve the overall quality of the house. However, she (should) never focuses on improving the quality of the rooms if that does not simultaneously improve the overall quality of the house. In a nutshell: parts of the whole should improve the quality of the whole. If this is not happening, you should take a step back (and again look at the whole - “synthesis” exercise).

Notes: this is why I strongly believe we should stop designing our products and technical software systems in isolation (as in the old classical “business” and “IT” silos). Even a step further, I argue that we must consider the whole sociotechnical system involved into understanding and building our software products. Failing to take that perspective means that we will also fail to understand how we can improve the overall system, e.g.: have a clear understanding of the customer, the teams that will be building and owning the systems and make sure the technical systems are aligned with that. This is what I call Sociotechnical Architecture and Systems [Sociotechnical-Silva] .

He finishes the talk with several amazing remarks, namely:

  • getting rid of deficiencies on parts does not improve the quality of the system as a whole. Improvements should be focused on “what you want”, not on what you don’t want. We will not improve the house by stopping a fire… we improve it by adding quality to its parts that make the house better.
  • “continuous improvement” is as nearly as important as “discontinuous improvement”. Creativity is a discontinuity, it breaks the continuous improvement flow, which leads to leaps of improvement that are not possible in “normal paths”.
  • qualities of systems should focus on effectiveness not efficiency. Efficiency is knowledge, however effectiveness is wisdom! He shares an amazing example: Toyota found greatly efficient ways to mass produce cars; however, if we look at our transportation systems this is not effective - having each person driving alone on a car.

References

InsighTweet