What is Systems Design? Part 2
Let’s revisit the definition from before: Systems design is concerned with the combination, integration, and interaction between and within parts, processes, people, or perspectives and necessitates trade-offs between these elements to meet a demand unmet by a basic product.
In part 1, we started unpacking this definition by describing the multiple meanings behind the word system as a partial source of the confusion. A lot of people use, misuse, and abuse the word system to describe their own process, product, or part. We don’t have enough words to describe the particular nuances and so we all default and use the same word “system” regardless of the application domain, field, or scope. (Go back and see the example list in Part 1)
To start exploring why this phenomenon is observed, let’s start with a simple spectrum, I’ll call the systems design spectrum, as shown in the following figure:
A Simple Systems Design Spectrum
Often the words product and system are used interchangeably as simple synonyms of each other, but I view them as relative locations on a design spectrum. It’s not always clear where one ends and the other begins. Thus, the difference may be only with respect to a particular dimension like scale, complexity, cost, or number of end-users (among many other possible criteria). Furthermore, many design methods and techniques can be used across this entire spectrum. Ideation methods, prototyping techniques, test and evaluation processes, and verification and validation assessment should occur regardless of the term you use for your device or process or product or system.
Still, there are certain methods and techniques that may become less useful as one moves far to the left or far to the right because of the innate attributes of the thing being designed. So, in the next figure below, we expand the systems design spectrum and add some additional labels:
A More Complete Systems Design Spectrum
To the left of “Product”, the term “Subsystem” is added. Of course, one can break a subsystem down and move further left with the terms “parts” and “components,” but the term subsystem will suffice for the current discussion. After all, a subsystem itself can be an independent product or system. Think of the radio or GPS in your automobile. Those could both be stand-alone products but they’re viewed as subsystems purchased by the automobile manufacturing company and installed into your car. To the original radio supplier and the design engineers of the radio, their entire focus was just the radio system. They might have even called it a system internally. In contrast, to the car manufacturer, the radio is just one part of thousands of parts in their car system. The takeaway is that one person’s system is another person’s product or subsystem when viewed from a higher level.
This continues all the way up to the right-hand side of the above figure, where people seek to communicate that their system is comprised of many systems and can even designate it as a “system of systems.” (You will occasionally find a reference to “a system of systems of systems” but that seems a bit excessive in my opinion.)
One typical characteristic of a system of systems (SoS) is that it usually continues to function (at least marginally) if one of the many system constituents is removed. For example, consider the transportation system. If a train (a system by itself) is all of sudden removed or doesn’t work, we can still get around with automobiles. Likewise, if one GPS satellite is offline, the air traffic control system doesn’t crumple to a full stop. Instead, the air transportation system of systems can use radar and other redundant onboard options (e.g. ADS-B) to know where an aircraft is and communicate their positions to other aircraft. (Additional features of an SoS will be explored in a later article).
In contrast to a SoS, this phenomenon doesn’t always hold for a system or product further to the left on the spectrum. That is, in a car, if the engine (a system or even subsystem) is dysfunctional, the entire car is close to useless, although one can argue the car still performs different functions such as for shelter, an uncomfortable bed, a source of fuel, etc.)
It’s now time to introduce the last figure of this article:
Example of increasing scope and levels for systems design
In the above figure, and starting at the top right, chemists and atomic physicists will clearly consider protons and neutrons as key parts or components of a silicon atom system. In fact, they may even view an atom as a system of systems with various subatomic particles: electrons, neutrons, and protons, each composed of a few quarks. In fact, the system of an atom might be even more complex as new subatomic particles seem to be discovered every year.
Moving up one level, an engineer designing PN junctions for a transistor cares about the unique properties of silicon as a bulk material and as a semi-conductor (i.e. not quite a conductor and not quite an insulator), but that same engineer won’t concern themselves too much about what’s going on in the atom’s nucleus. For them, that’s in the unnecessary details.
But an electrical engineer will take those transistors and combine them in a particular way to make certain logical processes that can do operations using voltage levels. Their system doesn’t care about silicon, but their system does concern itself with the interaction between multiple transistors.
What’s more, a set of transistors might be combined into a NAND gate (after moving one level up as shown in the bottom left). Likewise, hundreds and thousands of AND, NAND, OR, and NOR gates are integrated to ultimately make a system called an ALU (or Arithmetic and Logical Unit). This “system” might be a small portion of a small chip on your micro-processor (e.g. an Arduino), but even this system needs to be combined with many other things before it’s a useful product for humans to interact with, such as input and output devices and other peripherals.
The resultant computer system, say your smartphone, on which you might be reading this exact sentence, is only a system in a larger system of systems of computers, servers, data centers, and communication towers with broadcast antennae, each which could be a system by themselves. These computer systems might be embedded or connected in cars, boats, aircraft, and thousands of other products, both large and small, sometimes collectively called the Internet of Things (IoT).
Is this system the highest level and the last one to discuss? Not exactly. Communication systems and the IoT are only a portion of the socio-politico-technical system of our society. Collectively we have to pay for these services, agree on environmental, economic, and social impacts, both good and bad, and trade across national borders while reaching consensus on resource allocation and usage, including both water and energy. Since energy and the water cycle are partly driven and originate from the influence and effects of the sun, it’s even wise for systems scientists and engineers to view the earth with the sun as one system, especially if they are climate scientists. (Can even the moon be a part of this system? Absolutely. Designers of tidal energy harvesting systems are keenly aware of the moon as a key subsystem and a necessary part of their SoS.)
If it’s not obvious yet, I hope you walk away with at least one understood principle: One person’s component may be another person’s system. And therein lies a portion of the problem. When we can call anything and everything along the design spectrum a system (as presented in the first figure) we can quickly become lazy in communicating what we are referring to with our audience. Furthermore, they will have their own assumptions, scope, and perspective that we will have to understand if we are to make sense of the different things found at different points in the spectrum using the exact same language.
Systems design is product design, and product design is systems design, but only when we’ve reached a mutual understanding about scope, decomposition/composition, and perspectives.
In the next part, we’ll discuss those perspectives and explore additional criteria that vary across the above system design spectrum.
