I recently had the pleasure of attending an expo where undergraduate research was presented. One particular project testing formal propositions regarding systems vs systems of systems (SoS) caught my eye. We generally think we understand the basic concepts as we work with somewhat loose definitions. As we move to formal logical propositions, impacts, issues, and inconsistencies become far more evident.
This caused me to reflect upon some of the common “definitions” of SoS and the greater implications:
- Two or more systems that are separately defined but operate together to perform a common goal. (Peter Checkland, 1999)
- A system‐of‐interest whose system elements are themselves systems; typically these entail large scale inter‐disciplinary problems with multiple, heterogeneous, distributed systems. (INCOSE, 2012)
Typically, we choose to highlight two critical aspects when discussing SoS. First is a statement of composition. A SoS is composed of systems where the systems themselves have identity and produce results. The assembly of these systems into a greater SoS delivers new capability and value. Second is a statement of control. The systems within a SoS are independently specified and often independently managed and evolved. As such, SoS are often discussed in terms of interactions and cooperation as opposed to traditional specification and control.
If we stop to reflect upon classical systems engineering, what does this mean for a system where humans are within the systems boundary? If I consider the operator part of my system, does that automatically make my system a SoS? Not necessarily because perhaps the operator is the only system element that itself is a system. What about systems engineering an enterprise? In this case, an enterprise would have to be a SoS as the enterprise is composed of a mix of humans, infrastructure, policy, culture, and more.
So what does this mean? This gives us new insights, approaches, tools, and techniques for dealing with systems containing human elements. We cannot simply satisfy ourselves with static interfaces. We must focus on the far more complex concept of interactions. We must recognize that our system is constantly in evolution. No two humans operating within the system boundary are the same even if they are performing the same role. Any one human is changing over time in terms of knowledge, attitude, and capability. These concepts of interactions and independent evolution of system elements are aspects that classically cause us difficulties, and many engineers would like nothing more than to exclude “those messy humans” from their system boundary.
Perhaps the answer is not to exclude humans from the system boundary. Perhaps the answer is to recognize them for the independent systems that they are. Perhaps we should take a lesson from this research, apply a little bit of logic, and leverage the lessons of systems of systems engineering to help us better address the human elements in any system.
(HT to Carolyn Elliott and her advisor Alejandro Salado, Virginia Tech for the propositions. This work caught far more than my eye. It was recognized as the best undergraduate research project.)
