Any software is a system. Actually, anything is a system. And maybe it is even unnecessary to make this remark. But it’s usually helpful to have a good model or analogy to point the similarities or certain characteristics of things.
The reason I wanted to reiterate this definition is that I think it can be helpful to notice it for people learning software development or concepts.
To consider (or to be convinced to see) software entities such as code and infrastructure as systems or equally subsystems relieved some of my worries when all these things were new to me.
When I was learning new concepts or reading others’ codes, I oftentimes felt confused because I couldn’t put whatever I was consuming in a context and I felt that I had to see and understand the whole thing.
But in reality, any broader perspective would fall into a bigger system anyway. So there is no possibility to grab “the” big picture, so it should be fine to see whatever you are into as a subsystem and accept it as it is. No need to worry.
Anyway… What is a system?
- if you can draw a box around something (2d or 3d)
- isolate it from the rest of the universe
- and model the interaction between itself and outside.
- you can define it as a system.
Notice that “you” draw the lines.
It means you defined what is included in the system.
The reason I am stressing this is that you could define a subpart of the system as the system (or a larger portion that contains the system)
As long as you define the input, output and the behaviour of what you picked.
- the system receives a signal
- the system processes the incoming signal.
- the system produces a response
You see a friend and say hello. And in return, your friend also says hello to you. I want to consider your friend as a system. You send input and the system produced an output.
There is only one extra thing I would like to add apart from input and output. Your friend’s mood has probably changed a little bit between they hear you and respond to you. Most of the time, more or less they should feel better because of the conversation with a friend. This extra thing I wanted to add is that the system produces the response depending on its characteristics (or its state) but each input potentially changes its state as well. So it actually becomes another system, probably something very very similar to the previous one but with a slight change.
- incoming signal + the system -> the (new) system + produced signal
- receiving input and processing it adds a new memory to the system
- this slightly or radically changes how the system works in the next signal processing.
At this point, I am probably diverting a little bit more than I should but wanted to add one more remark. Even though in a physical system it is an inevitable yet natural phenomenon to have this state shift, in software systems we tend to isolate the state and make the shift visible somewhere outside as much as we can in order to have a better software design.
As a summary, any field of view you picked while you are looking at a software system (either you are trying to understand or trying to design), you can isolate it as a “unit” having inputs, outputs, and state.
It can be a tiny piece or a huge block.
Finishing with a software example: When you think amazon.com as a system. The running code that is processing orders is a subsystem of it and the code calculating the shipping cost is another subsystem. And in that subsystem, you may find a subsystem telling you if the shipping cost is free or not depending on how much is the total cost of an order.
If you are new to software development concepts and if the examples you encounter seem too simple or too complex, try to see things as inputs, outputs, and states. Things may make a little bit more sense then.
Thank you for your time 🙂