Zane Scott, Vitech Vice President of Professional Services
Those of us engaged in instruction, be it live or web-based, are often asked to provide “practical examples” of the principles and techniques we discuss. There is an intense desire to focus on application and avoid theory or concepts. The examples requested are deemed “practical” to the extent that they resemble the requester’s practice area. Rail system designers seek examples of rail systems. Missile designers want missile systems as examples. This seems practical and focused at first blush, but it disguises an underlying learning/teaching problem.
The problem is rooted in a struggle to establish a body of knowledge and the corresponding theoretical foundations of a systems engineering discipline. The history of the practice of systems engineering makes this struggle all the more difficult. Systems engineering arose in response to the need in the military/aerospace (mil/aero) sector for dealing with increasingly more complex problems and solutions in a rigorous and disciplined way. As the problem set began to demand solutions that crossed disciplinary boundaries, the need for an organized, comprehensive approach to designing and managing these solutions increased dramatically. Nowhere was this more apparent than in the arms and space races of the Cold War era.
A practice focused on commonalities
It was in this mil/aero arena that systems engineering was born. Missile defense programs like SAGE and the space explorations of NASA demanded complex, multi-faceted solutions. The days of deterministic systems as an answer to design problems disappeared almost completely. Problems and solutions in this limited space gave rise to a practice focused on their commonalities. This set a context for the new practice of systems engineering based on the transferability of its processes and approaches within those common characteristics.
But, when we learn a discipline from the perspective of narrow, specific applications, we seriously limit the possibilities for using our knowledge. We tend to see the possibilities for applying systems engineering in terms of the similarities between solutions in particular areas. That spawns the question of validating systems engineering with “practical” examples. In essence, we seek to validate its applicability by showing that the solutions produced are those that we seek in answer to the specific problem set we are encountering. Thus, for a rail system designer, systems engineering is validated by producing an example of a rail system designed using systems engineering methods and approaches. But this is an inherently limiting way to approach the subject.
The difference between “education” and “training”
As retired Army General Stanley McChrystal frames the problem in his book Team of Teams, it relates closely to the difference between education and training.
We would never call the rigors of medical school “easy,” but it is more feasible to spend seven years learning about the complex cause-and-effect relationships in the human body than to attempt to record and memorize every possible event that can befall bodies. This is the difference between “education” and “training.” Medical school is education, first aid is training. Education requires fundamental understanding, which can be used to grasp and respond to a nearly infinite variety of threats; training involves singular actions, which are useful only against anticipated challenges. McChrystal, Stanley; Collins, Tantum; Silverman, David; Fussell, Chris. Team of Teams: New Rules of Engagement for a Complex World (p. 153). Penguin Publishing Group.
The limited mindset that results from the origin of systems engineering as a way to produce mil/aero solutions mitigates against educating engineers in the principles of systems engineering in favor of training them in specific applications. Because of this limitation, we propagate a number of problems:
- The student is encouraged to see the practice in a limited way that obscures the full range of solutions. This is known as reproductive thinking, where problems are solved by replicating previous solutions – hopefully successful ones – with only minor alterations to tailor them to the new problem. There is nothing inherently wrong with reproductive thinking as a tool, but using it exclusively is limiting.
- There is no impetus to expand the scope of the systems engineering practice beyond those spaces where the similar solutions will work. Systems engineering remains the limited practice of cyber-physical systems and similar product-centric solutions. It is, for example, difficult to see it as a means of crafting human organizational architectures to address social problems like health care delivery. This serves to constrain the opportunity horizon for the practice.
- The criticism of systems engineering as lacking the body of knowledge and conceptual framework of a legitimate discipline is validated and even magnified by confining the emphasis to specific practice areas rather than encouraging thinking at the conceptual level.
The need for expanding our thinking
Opening up the thinking about systems engineering to conceptual considerations is critical to expanding the possibilities for problem solving and the commercial opportunities that accompany them. If we educate engineers in the principles that drive the problem-solving processes, they can see the transferability of those processes to areas based on the similarities of the problem sets and not just the applicability of specific solutions. As McCrystal points out, training focuses on the application of techniques to defined situations. Education, on the other hand, drives the mastery of principles that can then be applied to problems that call for their application. The difference is being able to recognize the relationship of solutions (training) versus the recognition of similarities in problem sets.
As long as we emphasize training in techniques over education in principles, we are tacitly promoting the strictures that confine us. It is good to be “practical” but not to the point of limiting our mindset. The insistence on narrowing the scope of our discussions ultimately does not serve us well.
