We are all familiar with the idea of “systems”. Broadly speaking they are collections of things that work together to do stuff (I said broadly). As a concept they are extremely powerful, so learning some “systems thinking” can be tremendously valuable. In the long run, what separates you from your competition is not a question of skills. It comes down to who has the better systems.
Systems Thinking – Car Example
To illustrate systems thinking let’s look at the example of a car. Systems are made up of a bunch of different parts (we will call these parts entities), and these parts are connected to each other through relationships. Relationships can be functional (this entity tells this entity to move) or formal (this thing is welded to this other thing). Entities can be arranged in a hierarchy, which helps in understanding how the system fits together.
We can see each of the entities is represented by a blue box, with its function shown in the internal white box. Relationships are indicated by the blue lines.
We really care about the high-level function that the system delivers, namely transport driver. We put together all the lower-level entities via their relationships and we basically hope that this desired function emerges from the system. Often it doesn’t (more on this later).
We don’t particularly care about the form of the system. Setting aside matters of taste, the form of your system is only relevant to you because it determines how much your system will cost, both in terms of purchasing and operation.
The benefit of a system comes from its function and the cost of the system comes from its form. How much value you derive from it comes from the ratio benefit / cost. Simple.
Emergence
Emergence is pretty cool. It is the core concept that all of this systems stuff really pivots on. You will want to deploy your system into some relevant environment (called a context), in order for it to be useful. The line that we draw between the system and its context is called the system boundary (how original).
If we have a done a good job we should see our desired function emerge magically from our collection of entities. But of course it is not that simple. There are few other things that can “emerge” too.
- Emergence of function. This is what we want!
- Emergence of performance. We do existing things, but better.
- Emergence of “ilities”. Our system delivers reliability, visibility, traceability, etc.
- Emergencies. Uh-oh.
Predicting Emergence
I said earlier that if we have done a good job then we should see the emergence we are hoping for. But what does that actually mean? How do we “do a good job”?
Broadly speaking, to predict the emergence of a system we have four weapons in our arsenal. Here they are, in order of most to least effective:
Experimentation. Build your system up iteratively, and piece-by-piece, testing through experimentation. If you don’t get the desired function you are after then make a change and note the differences.
Modelling. If you cannot experiment for real, then you can try to experiment in silico by simulating your system on a computer. Ultimately your system will still need to be tested for real, but this method can give you cheaper and faster iteration loops than the purely experimental approach. For a good example of how simulations can speed up development of real devices check out micron cubed simulations.
Precedence. If you cannot experiment or simulate then you can look for precedence. Has anyone built a system like yours in the past? If so, then perhaps there is a good chance that yours might work. If they have made exactly your system before then do not reinvent the wheel. Just buy theirs (unless you have a very strong reason not to).
Systems Thinking. If all else fails, then you are left to rely on your own reasoning (dear god, no!). That is where systems thinking comes in, which you are now, obviously, an expert in.
Failures
Systems will succeed when all of their entities and relationships function correctly. It is that simple (well, perhaps it isn’t – see below). But there are a couple of interesting ways in which your system might fail:
Weak link failures. As the name suggests this is where a single entity or relationship fails. This can develop into a pretty nasty situation where the failure of that single point or connection permeates through your system, knocking out all of the other system entities. This is called cascade failure.
Cascade failures are a staple of low-budget disaster films.
[enter junior analyst, disheveled and panicked]
“They fried server 28. The entire defence network is down!”
junior analyst in every disaster film you have ever seen
Honestly, I think these people deserve to have their entire defence network collapse. It is the only way they will learn. If you want to see an example of a network that defends itself from these sorts of stupid Hollywood affronts on logic then look no further than the internet.
The emerging magic of the internet stems from the simple protocols that run on each and every router on the network. If a single router (entity) is knocked out then the system automatically heals itself by redirecting traffic. No cascade failures for us, thank you very much.
The other type of failure you can experience is a system failure. This is sometimes what people call cascade failures, but they shouldn’t. In a system failure all of your entities and relationships work perfectly, but you do not get the emergent function that you were aiming for. You often see this sort of thing with misguided government initiatives to combat traffic congestion. Some extra lanes get added to roads to make them less busy. This makes driving look more attractive, so more people drive. You end up with more cars on the roads but no decrease in commute time. Brilliant.