What is a System?

When someone says the word ‘system’, what comes to mind?

If asked to provide the most basic of definitions I would say;

“Something is a system when multiple elements interface together to achieve an outcome.”

Three key points here.

Multiple Elements

First, multiple elements. If it there is just one isolated thing, say a light bulb or a tire, then chances are that isn’t a system. Or at least not a very interesting one. A system requires more than one element to be considered a system by it’s very nature. If thinking about a smart light bulb, powered by a grid, that connects to a WiFi network, that is controlled by Alexa via voice command, then that is a system. Similarly, if the tire is mounted to a wheel, which is bolted to the wheel hub, which mounts to the axle of a car, and so on; then you’ve found yourself a system.

This also hints at a point about different perspectives which I will touch on later.

Interfaces

Next point, interfaces. As you might have noticed in the previous examples it took the singular elements interfacing with something else in order to create some kind of system. Interfaces are arguably the most important part of any system. Elements on their own may be perfectly designed, but if they cannot function with their intended interfaces, then they are practically worthless. A tire without a wheel or an automobile is just a tire. The same could be said for a smart light bulb without power or a WiFi network, it’s just a light bulb.

Achieve an Outcome

Last point, achieve an outcome. This implies that there is a goal in mind; there is something the thing, the product, the system, is trying to achieve. Understanding what users needs or wants, and translating that into what the system will do is not easy, but essential to being successful.

This terminology is often translated into the oh-so lovely word “Requirements”. Engineers have different levels of familiarity with this word, but here I want to stay high level and just consider “an outcome”. Asking ourselves and the team, “what do we (and the users) want this thing to do?”, “How can we replicate and test what we are trying to create?”. Starting there and writing down what is known will start to create alignment and a path to design against.

Requirements can be captured in many forms; in your head, on paper, in a spreadsheet, a database, etc. Requirements management in itself is an entire discussion, but I would encourage at minimum to begin to write these things down so you can come back to them in 6 months when you have a product to test and break.

Levels

Earlier I mentioned perspective, and you may be imaging systems at many different levels; a microprocessor, a spaceship, Netflix, or a watch, all of which are systems in their own right. Systems occur at many different levels and forms, and require different perspectives in order to be designed, analyzed, and constructed.

Thinking of a system in different levels allows us to construct a framework for design and analysis. What is meant by “levels”?

“A system level consist of elements that directly interface with one another.”

There is that key word again, interfacing. I won’t bore you with picking apart this definition, but rather jump in to an example.

System Level

Suppose your team is responsible for designing a wireless mouse, a product most of us use daily. Your company sees the market of smart homes and integrated devices growing, and perhaps what is special about this mouse is it connects to a WiFi network, not directly to a PC. The intent of being able to control more than just one device, potentially different kinds of devices, from the mouse.

Back to our definition, “multiple devices interfacing to achieve an outcome”. Our outcome here is to provide the user with some control over multiple devices from a mouse. So in this perspective our system consist of the mouse, the network, and the devices; all of it interfacing together is the system. You cannot achieve the expected outcome if one part were to be exempt.

You can however exempt an element and change the definition of what the system consist of. For example, perhaps instead of leveraging a WiFi network for connectivity your team decides to use Bluetooth to directly communicate to devices. That is okay, but that is a new and different system in its own right.

An interesting point here for our system of interest is that the ‘user’ is a part of the system. They themselves are required in order for the system to achieve it’s intended function. Some systems may require a variety of users in order to function, while others may not require any users at all.

Product Level

Lets jump on level down and focus in on the mouse specifically. The mouse is your product, this what your team is responsible for developing, hence the product level.

Now the product level allows the team to consider elements that may be needed for design other than just the mouse itself. Lets consider your mouse will have its own internal battery that needs to be charged for use. At the Product level you can start to capture this amongst others like packaging and instructions. In the context of the System level these elements and interfaces are not nearly as obvious as they are when looking at the Product level.

I will mention it isn’t necessary to have a product level, some may prefer to jump right to the sub-system level which is absolutely acceptable. Providing this level specifically provides perspective around what the team is responsible for. I find this level to be most useful when designing a widget that has to fit within, or support, some existing interfaces. In our example that would be the WiFi networks expected to be in most homes. If looking at the perspective of an entire automobile then the product level probably isn’t the most useful, but if we are responsible for designing the new user control system that is installed into the dash of the new automobile model, then perhaps it is.

Sub-System Level

Down one more level and you would be at the sub-system level. Now we are starting to look at, “what is inside of the device?”. The mouse likely consist of several buttons we have become familiar with, a scrolling wheel, On/Off switch, a battery, a PCBA, and so on. It is up to your team to decide what the device or product will consist of internally, but this is the level that is captured at.

In the above levels you were able to identify various interfaces; buttons, WiFi, charging cable, and here is a good place to identify where this external interfaces come into the system. The components, the internals, at the sub-system level should be driven by constraints, requirements, and needs from the system and product levels.

In addition, a healthy exercise is understanding the “flow”, from when an interface comes into the produce to creating an output. Understanding this logical order of operations allows the team to identify what they might be missing within the product, or where different elements perform the same function.

System of Systems Level

This most challenging and confusing level is the System of Systems (SoS) level. This is very product dependent, but at times very helpful. Continuing with our example lets imagine the business needs to be able to send software updates to this mouse automatically. To add, the business intends for these products to be used globally in different markets. Now we are looking at more of a Systems of Systems architecture.

At this level we can begin to see the complexities, security risks, and new challenges of connecting the mouse back to company owned software service. There are different schools of thought when it comes to how to architect a SoS’s, each of which have their own set of trade offs. I won’t cover this in detail here, but you can see how considerations around security, interoperability, emergent behavior, and evolution of the system become more complex and important.

This level of analysis is only required for some products, but in the event, it’s an important perspective to keep in mind. It requires a thorough amount of thought and consideration when architect a system that is highly connected, yet independent, and secure.

Summary

Answering “what is a system?” can be simple yet challenging depending on the perspective and the scope of a specific product. Perspective is key here as it very much depends on what you and your team are responsible, this frame of reference helps define your system, and what may be just a sub-system for a much larger network of connected systems. Leveling the different elements in your scope will help create clarity of what is The System, The Product, Sub-Systems, and so on.

Remember the key points;

• multiple elements

• interfacing together

• to achieve an outcome