Being clear about the word ‘system’ in ‘systems engineering’ (SE) is fundamental to the discipline of SE. However, the word ‘system’ is so commonly used (or misused), that it fails to convey any unique, unambiguous meaning. In this article, we propose what could be called a ‘system’, such that it will be foundational to the understanding of SE. Please note that we are not attempting to understand ‘system’ in any universal manner - we are focused only on systems that are engineered. Sometimes, to know a concept better, it might help to figure out what it is not. “What is NOT a system”, is a question you can ask yourself. Are you able to answer it to your own satisfaction? Read on. This article might be of help to you!
Systems are Ubiquitous
We probably heard the word ‘system’ for the first time in a science class while in primary or middle school – solar system, systems in the body (nervous system, muscular system, immune system, …), and so on. Over time, we would have come across many other terms that included the word system (ecosystem, transportation system, global positioning system, weather / storm system, number system, …).
Somewhere along the way since those science classes at school, we would have started to use or hear the word ‘system’ in isolation. But then, the context will be needed to know what is being referred to. When someone says “The system is not working”, they could be referring to the government, banking, education, or healthcare, depending on the context of the conversation. When someone said “I bought a system at home” in the early 1990s, it would often refer to a Hi-Fi audio system. Since the advent of computers, the word ‘system’ most commonly refers to a ‘computer system’. This trend continues in the IT/Computer industry - the evidence is in the titles, designations, and job descriptions that refer to systems and systems engineers. This brings up another question: “Who is a Systems Engineer?”, which we will discuss in a separate article.
All these are valid uses of the word system. But our interest is to understand ‘system’ in the context of engineering at large, and SE in particular. There are many formal definitions of a system - will they not help? Let’s find out.
By Definition, a System is…
Let us take a look at two key definitions of a system.
The first is by Ludwig von Bertalanffy in 1968: “A set of elements in interaction”. This sounds crisp and concise, but fails to help us truly distinguish between something that is a system and something that is not. Take any quantity of matter - any matter. There will be millions of molecules interacting with each other. Within each molecule, there will be atoms interacting with each other. And within each atom there will be neutrons, protons and electrons - all interacting with each other. Hence, by definition, any chunk of matter is a system! This definition is so generic, that it is very difficult to say that something is not a system!
The second definition is from the ISO/IEC/IEEE 15288 standard (Systems and software engineering – System lifecycle processes): “A combination of interacting elements organized to achieve one or more stated purposes”. This definition is more relatable in the context of SE. Engineering is fundamentally the use of nature to achieve some purpose to serve humans, and SE can be viewed as a discipline whose interest is to develop such systems that serve a stated purpose. While this second definition is more specific than the first definition from an SE perspective it still does not help us identify a system with more objectivity.
If we were to look at more definitions of ‘system’ we would encounter many variations, and one definition would offer some insight that another one does not. But something that is likely to be common to almost all definitions is the mention of elements (or parts or constituents) that are combined to form the system. As we saw in the example of matter, it will be possible to view anything as having been combined from molecules. So, we need to be clear about what those elements are, and the purpose behind breaking the system into elements. This is perhaps the most critical aspect from an SE point of view.
‘System’ in the Context of Engineering
In the engineering industry, particularly in aerospace (that KS and DH are most familiar with), it is common to attribute the term system not to the system at large (aircraft or automobile for example), but rather to some of the elements that make up the system, e.g. electrical system, hydraulic system, mechanical system, etc. This is much like how the organ systems in the human body are referred to as systems, e.g. nervous system, while the body is not referred to as a system! Such terminology has ingrained and taken roots in some industries from pre-SE days.
So, when SE begins to percolate within engineering organizations, things become a little tricky. “What should I call a system?” is a confusion that emerges in the minds of many. Add to this, the ways in which others use the word - especially those who seem to know about SE, and it can only make things worse. We know a senior person in a systems development organization who would use the word ‘system’ more as a pronoun to refer to anything and everything. This is an extreme example of misuse of the word ‘system’. At the same time, there will be those who would use the word ‘system’ judiciously and thoughtfully to convey something specific - they are at the other extreme of perfection. Then there will be those who may lie anywhere between these two extremes.
The confusions that exist in the minds of people about the word ‘system’ often get exacerbated when SE comes into the picture. Many continue to look at SE with a bias that arises from their own existing understanding of what is a system and what is not! Can this be resolved?
System Check
As we attempt to clearly identify what is a system and what is not, we must accept that this could be subjective. What is a system to one, need not be so to another! But what’s more important, is that even the person who does not consider something to be a system should be able to acknowledge that it is a system to someone else. Hence, when someone says “it is a system to me’, another person should be able to say “Yes - it is a system to you, but not to me”. Is there a way to clearly qualify something to be a system or not such that everyone would agree? That’s what we are trying to do here.
Based on the discussions thus far, we propose a few checks to see if something is a system or not. Please note, that our intent here is to establish clarity for the purposes of SE practice only. This may not be considered as criteria for an universal check of any system.
Check-1: It must be intentionally made by humans - i.e., it cannot be accidentally made, and it must not exist in nature
Check-2: It must serve a purpose - i.e., someone must be able to derive some benefit from it
Check-3: It must be possible to decompose it into interacting elements - i.e., every element must interact with at least one other element.
Check-4: There must be a purpose for decomposing it into elements - i.e., it is not done just for the sake of decomposing.
Let us explore these checks a little more.
Check-1 is fairly clear and objective, but Check-2 is subjective. It may not be possible to find a universal worthwhile purpose, and that is where we go back to the definition by ISO/IEC/IEEE 15288 which mentions that the purposes must be stated. We presume that before the purpose is stated, it is first agreed upon by all those who are involved (also called 'stakeholders’). Hence, the purpose is defined based on the benefits to particular individuals or groups of individuals. The system is being developed to provide such benefits only.
If something fails both Check-1 and Check-2, then it falls outside the purview of SE. It might still be considered to be a system from another (non-SE) point of view, but we will leave it to the experts of that point of view.
Check-3 is fairly straightforward, but Check-4 is crucial. From an SE perspective, there must be a reason to decompose a system. If it does not serve any purpose, it need not be decomposed. We break a system only if it will be difficult to ‘engineer’ it (or design & develop it) as one whole. We break in order to manage the engineering of the system effectively, efficiently and successfully. We may want to manage complexity, effort, expertise, schedule, cost, resources, skills, or any such factor. But we must do this carefully in a structured manner, and we must be able to successfully synthesize what we have broken down such that the system as a whole achieves its stated purpose(s).
Check-4 implies that we should not decompose if we don’t have to. At the same time, it also implies that one person may need to decompose a system, but another person need not decompose it if they are able to handle the system as a whole!
We will end this discussion here. In our next article, we will present a few examples where we will apply the four system checks to see if something is a system or not! Until then, give these checks a try. Think about something you consider to be a system, and see if it passes all four system checks listed above. Keep in mind that the objective of identifying something to be a system is to enable SE. Think about something else that you do not consider to be a system. If it still passes the four checks, then perhaps it is a system to someone else! Can you think of something that is made by humans and serves a purpose, but cannot be considered to be a system? Think about it, and let us know – either as comments below or by sending us an email (to SystemsEngineering360@gmail.com).
Most often, a discussion on what is a system will lead to a discussion on system hierarchy, and about how one person’s system could be another person’s element, or vice-versa. Hierarchy is definitely relevant, but not as fundamental as determining if something is a system or not. Once something is determined to be a system, you can then choose to apply any label to it (system, sub-system, super-system, system-of-systems, etc.) and organize it in any hierarchical manner. We will discuss hierarchy in a separate article.
- KS & DH
To know more about us, read our blog launch article
Record of Changes
Original date of publishing: 11-Apr-2022
Date of Revision-1: 23-Apr-2022
The illustration was changed from the one below, to better clarify our position.
Text in blue font (as in this sentence) has been inserted.
The paragraph just below the inserted text has been modified, from the original text shown below. The text in red font has now been deleted or modified:
Check-3 is fairly straightforward, but Check-4 is crucial and can be subjective too. From an SE perspective, there must be a reason to decompose a system. If it does not serve any purpose, it need not be decomposed. We break a system only if it will be difficult to build it (or design & develop it) as one whole - i.e., if the system is complex. By breaking we are reducing complexity within each element to a manageable level. But we must do this carefully in a structured manner, and we must be able to successfully synthesize what we have broken down such that the system as a whole achieves its stated purpose(s).
Commentaires