In our previous article, we proposed four checks to determine whether something can be called a ‘system’ or not, from a systems engineering (SE) point of view. We strongly recommend that you read that article first. In this article, we provide examples of applying these checks on various items to illustrate how the checks are passed or failed, thus helping us decide if we may refer to them as systems or not.
We wish to re-emphasize that our objective is to determine whether something is a system or not, purely from a systems engineering point of view. We do not propose these to be universal checks of a system. There could also be many characteristics and attributes of a system, even from a systems engineering perspective – i.e., things that you can see/observe in a system that you cannot see/observe in something that is not a system. However, we do not consider these to be critical checks to determine whether they are systems or not. For example, a system would have a boundary, exhibit emergent behaviour, and operate in the context of an environment. But these are not checks to determine if something is a system or not.
Recap of the Four Checks
In our previous article, we had proposed these four checks:
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 stated purpose - i.e., someone must have explicitly expressed one or more benefits they wish to derive from it
Checks-1&2 will help us determine if something falls within the domain of SE or not. We proceed with the next two checks only if checks-1&2 are passed. The things that fail checks-1&2 could very well be termed as systems in another domain or from some other perspective. We do not challenge that at all. We are just saying that they do not belong to SE. We will leave it to the experts of those domains and disciplines to decide whether to call it a system or not, according to their criteria.
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.
Once we determine that something falls within the domain of SE, checks-3&4 help us clarify if we can call something to be a system. In reality, what we identify to be a ‘system’ (after passing the four checks), may actually be called by different names – e.g. sub-system, super-system, system-of-systems, etc. We only wish to propose some commonality within SE such that when you or someone else refers to something as a system, it will be done carefully (and not loosely as just a manner of speech), and that others will clearly and unambiguously understand it to be a system as well.
Let us now discuss a few examples where we will apply the four checks.
1) Grassland Ecosystem
This is a natural system, and therefore, it is something that has not been made by humans. It is certainly a very complex ‘system’ in its own way. But from an SE perspective, it is not something that humans have engineered. Hence, it fails check-1, and we do not explore any further checks.
2) Modes of Transportation
Consider the need to travel between two points – either within a city or otherwise. One could use a mix of two or more modes of transportation for this purpose - autorickshaw, bus, metro, train, etc. Each of these modes pass checks-1&2. But when we look at them collectively, you can call it a ‘transportation system’ only if it was engineered holistically to serve the purpose of providing a means of transportation between those two points. If not, we are only utilizing existing options to achieve a purpose. We are not intentionally decomposing the transportation system to manage its development. In fact, we are aggregating what is already existing. Hence, checks-3&4 are failed.
(This example could lead us into a discussion on systems and system-of-systems. We will not engage in that discussion here, but in a future article.)
3) Engine of a Car
An engine is an essential part of a car. It clearly passes checks-1&2. But then, for someone who is engineering the car, the engine could be a bought-out item. They need not know anything about what elements are inside or how they are interacting. All they are interested in is to successfully integrate the engine so that the car is able to perform what it needs to. For that car-level engineer, the engine is not a system. However, for the engineer who is designing and developing the engine, it passes checks-3&4, and hence it is a system!
4) Software or Software-System?
All of us use various software tools for various daily technical activities. They immediately pass checks-1&2. Now, let's take one such tool - say, Microsoft Word. For all users of Microsoft Word, it is a ‘software’ and not a ‘software-system’, since we may not (and need not) be aware of the software code, its structure, and other elements that enable Microsoft Word to do what it does. For users of Microsoft Word, it fails checks-3&4 since they do not attempt to decompose the software tool. However, for the developers of Microsoft Word, they would have decomposed the overall software into various elements, and multiple programmers would have been involved in the coding, testing, and release of the software. They had to decompose it, in order to manage the development and release of it in an orderly and timely manner. For them, Microsoft Word passes checks-3&4, and they can call it a ‘software-system’.
5) Printed Circuit Board (PCB)
A PCB will typically contain a number of electronic components that are connected to each other, and any PCB will be created to serve some purpose expressed by someone – otherwise, there would be no need to create a PCB. Hence, checks-1&2 are passed! For an engineer who is developing a system in which this PCB is a component, checks-3&4 are failed since they will consider the PCB as a monolith. Now, the entire PCB could be designed by an electronics engineer utilising just their own knowledge and expertise. There is no need to decompose it further, and no benefit will be achieved even if it were decomposed. Hence, the PCB fails checks-3&4 for the electronics engineer as well!
The above examples are drawn from different contexts, and you may be able to extend the four checks to many other things. What we achieve by passing something through these four checks and determining whether it is a system or not, gives us clarity in two ways from a SE perspective:
When someone refers to something as a system, it gives us an insight into how they are approaching and treating it.
When something is a system, then we can be sure that adopting an SE approach will be of benefit. An SE approach cannot be treated to be universal - it can only benefit in the development of ‘systems’ (that pass the four checks).
To summarize - in the development of a car for example, when someone refers to a “car engine system”, then we could assume that the person is developing the engine by decomposing it in order to manage its design and development. But if another person is using the car engine as a single entity without having to decompose it, then it would be appropriate for them to refer to it as a “car engine” and not a “car engine system”.
We hope this is helpful, because we first need to be clear about the ‘system’ in SE! By commenting below or by sending us an email (SystemsEngineering360@gmail.com), please let us know if these checks are helpful. Also, if there are things that you would consider to be a system (from an SE perspective only), but fail one or more of the fours checks, we are curious to know more about it!
- KS & DH
To know more about us, read our blog launch article
Comments