Understand Things As Interacting Systems
Tags: Systems Thinking, Interaction, Software Development, Promise Theory, Wardley Maps

So what are systems ?

In each of the previous example, we found common properties that make system useful tools. Let’s walk through each of them.

Systems are useful learning tools

We already saw that at the begining: building the model is what makes you understand it, question your assumptions, share your thoughts. Your models will be false — they are models! You learn with iterations, making them less false is possible.

Systems are entities…

A system is a model about entities, so you need at least things that last sufficiently long that you want to talk about them. It can be anything, from people to items to ideas and more.

Abstract entities

These things need to be in some sort of interaction, or at least relation. Again, here interaction and relation are very loosely defined, “the cars on the road” is totally fine, as much as “people who saw that series” or “these lines of codes”.

For example, the children from the previous school:

Sometime a little bit to concreate entities (if you are parents, you know)

So, you have things and links between them:

Abstractly interacting entities

This is your world, the thing you need to better understand, or just talk about with your friends.

Noisigly interacting entities

Defining systems — boundaries and names

And then, to transform that into interacting systems, you need to do (be careful, it will be very quick, don’t lose the track of my hands): draw lines around groups of things that belong together.

And tadaaaa, you have interacting systems — an ecosystem:

Tada! Colorful systems ! Choosing where to draw lines and why is the interesting part.

And give a name to each group. As you can see, you don’t even have to be good for the naming part, but at least you will be able to easily communicate to others (and yourself) what things you are talking about.

Again, “belong together” is up to you. It’s the part that makes the system definition helpful to reach your goal, to learn about the entities at hand. Thinking about the boundaries is what makes you understand your systems.

For example, if you want to build a long-lasting application, you could group code by the service it provides to other parts of the application. Or by how stable it must be because of third party integration. Or by sensitivity of managed data if you are on the security side of applications.

So each time you have interacting things, and you talk about a subpart of them, you are actually — even without knowing it — defining systems. Yep, you were doing it all that time.

Some examples of interacting systems:

“I love that book so much”.

System. With at least the people mostly sharing the ideas of narrators, and the ones who don’t.

“Did you correct the bug in that part of the application that looks if the user is connected?”.

System. And you should give a memrable name for that part of the application. And draw a big line around it, it seems important to be able to talk about its behaviour.

Or for the previous school example:

Creating systems is easy. Being ok with someone else (or you in 5min) about where to put the lines and what names should be used is the hard part

Internal language

As you defined a part “in” a system and a part “out” of it, you will see that the rules are not the same for things in and out.

A system develops an internal language. You know, your famous “business domain”, or even just your work expert vocabulary — the words that the outer world describes as “jargon” or “gibberish” most of the time. This internal language makes intra-system communications full of conventions, assumptions, non-obvious self-consistency. In exchange, your intra-system communications can be more precise and efficient.

Making explicit the boundaries of your system make it clear where you are allowed to use that internal language, and where you need to give more context, or even adapt to a common, less efficient but more broadly understood language.

Teachers talk to each other with pedagogical terms but they use common words to talk to parents. Alice’ Band has its private jokes and references which differ from Gus Band, but both agreed on a common, colorful language when they play together. And so on.

… interacting with other systems

These explicit boundaries also make apparent how all systems interact with each other.

Most of the time, you will be surprised by how much entangled systems are in reality, and how naive your circles were — that’s good ! You are learning about the topic at hand, and what you are starting to see are interfaces and communication protocols.

Interfaces

Interfaces are gates in the boundary of a system. They are places that other systems use to interact with your system — identified points of contact.

The fewer gates there are, the easier it is for a system to evolve and change without impacting other systems. It’s something very well-known in code, where we have entire books explaining that modules should hide their internal state. But actually, they just need to expose few interfaces, hiding internal state is just a consequence of that.

Protocols

Interfaces per se are not useful. They take flesh once you know how to use them to talk to the system, and what you get in return. We, experts, call that chating. Sorry, a protocol.

Promises and error modes

Once you have an identified bounded system that can be contacted at interface points thanks to protocols… You will like to actually interact with the system, and you will expect some kind of behaviour from it: the system make promises to the outer world about what it will do. Promises can be kept — it’s the nominal case in a working ecosystem — , or not — and that’s an error.

Protocols and interfaces help to encode these promises in a way that is useful for the other systems which want to interact with the firt one. They describe:

where you need to ask something,

what kinds of interactions will be processed,

what kinds of returns can be expected,

and what errors can happen along the way.

And so you have an ecosystem interacting by protocol through interfaces.

Promises on behavior is shared with protocols using interfaces

Nothing surprising in a digital world actually built upon these principles.

But you can use it on more down to earth systems, to better understand how the parts interact and what are the protocoles. Again, drawing the lines and putting the tags is what will make you discover the studied world, and confronting your lines with others will make you understand it: you will most likely disagree on where are the interfaces and what are the correct protocols.

See, in the following example, what happens if Charlie is in Deborah’s class, contrary to the three others?

Systems, protocol and interfaces don’t need to formally defined to share understanding of the world

Systems are fractal

Systems can be composed of subsystems. Or be part of macro-systems. You adapt the granularity to the problem at hand and zoom as needed.

Our school is its own system in the world, with its own interfaces to other systems like the local administrations, its ministry, parents, etc. You could zoom out to study the town as a system and better understand what the place of the school is, or you can zoom in Alice’s Band inner complicated relationships.

Zoom in and out of system to study different levels of interaction.

Systems are rooted in a world

One last thing: interacting systems are rooted in a world. So you have a virtual horizon to your ecosystem beside which nothing useful happens for that model of the world.

Systems are rooted in a world.

That doesn’t mean it doesn’t exist, just that you don’t want to consider it in your model. And actually, if something from beyond that horizon is important… It’s part of your ecosystem, and you need to understand its interaction. It isn’t a contradiction with the previous fractal part either: when you chose a level, you also choose to exclude what is considered irrelevant for your eco-system at that level. Again, this is part of being a mostly wrong model and not the reallity.

This horizon is extremely useful because it allows defining three modes of interaction for systems:

The nominal case, when an interaction went as expected for both parts.

The error mode, when something *expected* went wrong.

The failure mode, when something *unexpected* (i.e. beyond our horizon) happened.

In our school example, we could have:

nominal case: children are in school during break, they play marble and have some fun.

error mode: children are in school during break, they play marble, start a fight and their parents get called.

failure: in the morning, it’s snowing a lot. Children can’t go to school, all adults panic.

Or perhaps that last case should be an expected error mode? It’s a snowy region, and the city is used to that. There is a special public service that will take care of the children whom parents can’t get a day off —but most can, because remote is expected in that situation.

Well, you see: thinking in systems is useful. Now you know that you decide what the expected errors are, and what is an unexpected failure. It’s the same in your code. You want to know what your world hypothesis are and what events need to be considered to be fatal for your application.

For example, in Java, most people consider the memory management as beeing out of their world. In case of a memory allocation failure (the famous “OutOfMemoryError”), you just have to terminate your application, because you switched to an inconsistant state, out of your understanding of your model. But in some rare cases, it’s totally legit to draw lines around a part of the code and to expect that that part may throw that error (for example when loading a Big Thing in memory), with a recovery scheme (when Thing is Too Big).

In economics, they call the things happening beyond your model horizan externalities. Earth ecosystem is such an externality, and we are just now noticing that perhaps we don’t like the failure mode going with that one, so we are starting to internalise it, i.e. integrate it in our humanity models.