Systems thinking

Nowadays, people are dealing with IT systems every day. Some of us work on building systems and other are system users. In this article I will focus on the first group, because despite my Engineering Manager role I still see myself as Software Engineer :). Software engineers encounter many, many complex problems every week. At least, that is what we are telling ourselves. When developing IT system Software Engineers work with System Analysts, business stakeholders and Product Managers.

Despite being deeply involved in system design we (Software Engineers) rarely give enough attention to understanding the system we’re working on. In this article I will give you a brief introduction to system thinking. We’ll see how we can apply tiny bit of knowledge of systems into Software Engineer job.

What is system thinking?

Wikipedia stays as follows:

Systems thinking is a way of making sense of the complexity of the world by looking at it in terms of wholes and relationships rather than by splitting it down into its parts.[1] It has been used as a way of exploring and developing effective action in complex contexts.[2]

Systems thinking is a holistic approach to analysing complex systems, by taking into account all system parts and interactions between them. System thinking is widely used in the medical field, climate change research and many others areas with complex problems. System thinking is a method to approach problems that pushes us to ask more questions about the problem we trying to solve. It is more of a way of approaching to problems rather than using specific set of tools.

System thinking? Holistic view? Why bother?

Software Engineers build systems every they. We solve business problems and help our companies to maintain theirs competitive advantage. Building proper system requires understanding what do we need to build. Nowadays not every company hires System Analysts. To be honest, there are companies that do not need full-time job System Analysts. In those cases both Software Engineers and Product Managers are expected to do some analysis. However, analysis it’s not enough to build system that’s working as expected. Classical approach to analysis focuses on decomposing the problem, understanding all problem aspects in detail. Don’t get me wrong. These approach is the foundation of our contemporary technical civilisation and our progress as humanity! Without proper analysis we wouldn’t have the internet to run blog on!

I think that system thinking is valuable completion to system analysis. What system thinking allows us to do is to synthesise analysed informations into working system. Because Software Engineer is deeply involved in system design, I believe that system thinking will allow usa to build better systems.

That being said, let’s see what a system is.

What is a system?

In the famous book Thinking in Systems Donella Meadows brings up following definition of a system:

A system is an interconnected set of elements that is coherently organised in a way that achieves something.

As we can see, no system is distinguished here. The same definition applies to IT system, communication system, nervous system or basketball team. They all consist of three kinds of things:

• elements or parts,
• interconnections,
• purpose (achieving something).

How can we summarise informations mentioned above?

1. System is a whole that contains at least two elements.
2. Each of the elements can affect properties or behaviour of the whole system.
3. Between two elements of the system there is direct or indirect path that represents interconnection.
4. How any element effects the whole depends on what other elements are doing.

We can group elements of the system into subsystem, no matter how we group them, each subsystem will effect other subsystems and the properties or behaviour of the whole. None of the subsystems have independent effect on the whole system. So basically, group of elements has the same properties and behaviours as single element.

Systems are more than just the sum of its parts. Systems can evolve, change their behaviour or interconnections over time. System is a living thing and cannot be divided into independent parts and still be called the same system.

Elements of the system

Base unit of any system is stock. Stocks are measurable, countable element of the system. A stock does not have to be physical. Stocks change over time due to actions of flows. Flows can be divided into inflow (filling) and outflow (draining). The system regulate itself through feedback loops. Feedback loops can be divided into two groups: reinforced feedback and balancing feedback.

To put it simply. Our model of a system includes:

• Stocks – elements we affect
• Filling and draining stock in/out of the system
• Way to reinforce or balance system (feedbacks)

Using systems thinking by Software Engineer

Is everything a system? How can I distinguish system from a bunch of random stuff? What should I do?

In my opinion using systems thinking by Software Engineer starts with asking proper questions. First, we can identify the business problem and what features we will be working on. Second, ask questions about the nature of the system. Armed with those answers we can build proper solutions.

How to identify the system?

System elements can be easily identified: team players are elements of the system, neurons are the elements of the system. On the other hand, interconnections and system function is not as easy to identify as system elements. When analyzing system try to answer following questions:

1. Can I identify parts of the system?
2. Do the parts affect each other?
3. Do the parts working together produce different effect than each part of its own?

If you can answer: Yes to all three questions than you’re dealing with system.

Nature of the system

Try to discover nature of the system. Ask business stakeholders for questions that will allow you to create following graph:

1. What are the inputs and outputs of the system?
2. How do elements of the system affect each other?
   1. If A causes B, is it possible that B causes A?
3. Are there any external feedbacks that affect our system and perhaps our business goals?
4. Are there any internal feedbacks from within the org.?
   1. Do we use functionalities from other teams? How changes in their domain will affect us?
   2. Do other teams contribute to the same system stocks as we do?
5. Is there a possibility that our system will affect other system within org. and reduce their KPIs?

With answers to these questions we can build view of our system and understand impact of it. And more importantly: we know why we are we designing system.

Our time and cognitive abilities are finite, so we may miss something, or system will simply evolve. It is okay to reevaluate our assumptions and design when we’ll get more knowledge about business or problem itself. Progress over perfection.

More holistic view can even reevaluate business idea in the first place. Maybe building this system will have negative impact on the company and closing project early on will be the best decision. If you will ask proper questions and provide conclusions on the business needs, you will be viewed as someone deeply caring for the company.

Conclusion

Analysing complex systems is quite complex 🙂 and we’ve just scratch the surface.

We are surrounded by systems that influence each other. Our job as a Software Engineers is to understand relationships between systems within our organization. Engineer who better understands business and systems will be more valuable to organization than the one who does not. It won’t take too much to apply basics of system thinking. Asking proper questions is crucial. Any place to do it is great: refinement, meeting with business stakeholders or simply write an email. I hope that some of you will do. If you will put effort in building knowledge on company’s business and systems it probably will be noticed by your manager. It’s a win-win situation and I highly encourage you to do so. Of course, remember about nonviolent communication when asking questions and your voice will be heard in the room.

I highly encourage you to research system thinking on your own. There are many aspects we didn’t cover.

In further articles we will dive deeper into system analysis and design. We will discuss system archetypes, system ambushes and how to apply system thinking to designing software systems.

Stay tuned and please leave the feedback in the comment section down below.

Resources

1. Thinking in Systems, Donella H. Meadows. https://www.amazon.com/Thinking-Systems-Donella-H-Meadows/dp/1603580557
2. Wikipedia, System Thinking https://en.wikipedia.org/wiki/Systems_thinking
3. Wikipedia, Nonviolent Communication https://en.wikipedia.org/wiki/Nonviolent_Communication