Some disciplines are “invented” or, more accurately, “evolve” as ways of solving specific, difficult problems. Principles and techniques are developed to cope with the knotty aspects of such problems. This was the path that led to systems engineering. First discussed by Bell Labs, systems engineering arose across several decades primarily in the aerospace and defense industry as a response to the problems of developing complicated and complex systems such as sophisticated airplanes, ships, and rockets.
Instead of treating these highly technical and intricate projects as a collection of independently developed parts cobbled together into a whole, systems engineering stressed the concept of developing the system together in ways that promoted the performance of the whole. It was in these contexts that the concepts and methods of systems engineering first began to take shape and be refined into the processes that we recognize today as systems engineering practice.
Although there have been some notable attempts to draw the concepts of systems engineering together into the community of systems disciplines (see particularly The Systems Engineering Body of Knowledge (SEBoK) Part 2: Foundations of Systems Engineering, and Sillito, 2012, Integrating Systems Science, Systems Thinking, and Systems Engineering: Understanding the Differences and Exploiting the Synergies, INCOSE IS 2012, there still exists a division and even a resistance to seeing systems engineering as a “sister” discipline among siblings sharing concepts and frameworks for thinking about problems.
Reproductive thinking
That divide and the reasons behind it produce two significant problems. The first has to do with the way in which engineers steeped in the experience of applying their tools and methods to very similar problems go about conceptualizing solutions. They tend to solve problems as they have experienced solutions to similar problems. In the world of problem-solving this results in what is called “reproductive thinking.”
In his book Cracking Creativity: The Secrets of Creative Genius, Michael Michalko explains:
Typically, we think reproductively, on the basis of similar problems encountered in the past. When confronted with problems, we fixate on something in our past that has worked before. We ask, “What have I been taught in my life, education, or work that will solve this problem?” Then we analytically select the most promising approach based on past experiences, excluding all other approaches, and work in a clearly defined direction toward the solution of the problem. Because of the apparent soundness of the steps based on past experiences, we become arrogantly certain of the correctness of our conclusion.
When we see our discipline as having a relatively narrow, limited problem set, this kind of thinking has a large impact on the quality of solutions by restricting the solution set artificially. Often our professional preparation contributes to this by “training” us in a set of narrow applications rather than taking us to the more abstract, conceptual level. This is the problem discussed by Stanley McChrystal in his book Team of Teams. Noting the difficulty of team members from particular specialties in transitioning to solve problems typically seen as out of their specialty, McChrystal wrote:
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. Education is resilient, training is robust.
An artificial opportunity horizon
The second problem results from the imposition of an artificial limitation on the opportunity horizon for the discipline. Ordinarily the question of where a discipline might be applied turns on the nature of the tools and methods of the discipline. By looking at the range of problems that might be solved using the concepts of the discipline the practitioner can begin to define the set of problems that represent an opportunity to engage the discipline.
Systems engineering developed in the aerospace and defense trade space. Its initial development was as a set of methods, tools, and processes intended to leverage the production of hardware (mostly military). As the discipline grew, software engineering began to both impact and draw from it. There was some cross pollination and some sectarianism around the approaches. But almost everyone thought in the context of application.
How does that limit us? Look, for example, at INCOSE’s foray into the world of healthcare. Where did systems engineering head?
The move to healthcare was largely into medical devices. Why? Because the hardware/software design paradigm for developing avionics control systems could be easily seen as applying to the development of operating room control systems. The applications (contexts) were similar. Very few people asked whether systems engineering could leverage the organizational design of healthcare delivery systems so that the Veteran’s Administration could deliver medical care more efficiently. So the discipline seeking to expand did so based on the similarity of applications and not on the similarity of needs amenable to solution using the discipline’s concepts.
So the failure to think at the conceptual level can hurt in two ways. It denigrates the quality of solutions by fostering “reproductive” thinking. Further, it restricts the opportunity horizon by limiting the practitioner’s vision to applications that are substantially similar to familiar problems. It causes us to timidly go where many of us have gone before.
