One of the most important—and often overlooked—aspects of good systems engineering is first principles thinking. In an excellent article on first principles thinking in his Farnam Street blog, Shane Parrish discusses first principles thinking in the context of Julia Child’s French cooking. Arguing that what made her extraordinary television show “The French Chef” so popular was not her ability to follow a recipe, but rather her understanding of the nuances of her ingredients, Parrish underscored her deep knowledge as the secret to her success.
Calling that understanding “first principles thinking,” Parrish pointed out, “Following a recipe might get you the results you want, but it doesn’t teach you anything about how cooking works at the foundational level. Or what to do when something goes wrong. Or how to come up with your own recipes when you open the fridge on a Wednesday night and realize you forgot to go grocery shopping. Or how to adapt recipes for your own dietary needs.”
This thinking (and the failure to put it to work) is not limited to the world of cooking. Practitioners in many disciplines seek closely defined processes (recipes) to provide an assurance, if not an outright guarantee, of success. For example, content marketing experts would probably remind me that I could increase my readership for this blog by titling it something like “3 Steps to Successful Systems Engineering” precisely because of the market pull toward a recipe approach. Just look at the success of books and articles in the vein of “The 10 Irrefutable Laws of . . . (you fill in the subject).”
Systems engineering is replete with calls for “standard” processes—lists of defined steps to success—steps that lead unfailingly to the desired result. But true success rests more on the fundamental understanding of first principles than on the use of “cookbook” recipes.
While there is much to be said for following a proven path to success, that is not always the best way to meet our systems engineering challenges. The world is complex, and it presents us with complex, entangled challenges and problems. Following a recipe designed to cook last night’s dinner doesn’t help us meet today’s needs. It is first principles thinking that can turn us from cooks to chefs in the face of our real-world challenges and the need for solutions.
What is “first principles thinking” and how can it help?
In his Metaphysics, Aristotle called first principles “the first basis from which a thing is known.” They are the foundational principles that undergird the understanding of a discipline. From them the rest of what we know of the discipline can be extracted. But what does Aristotle and Greek philosophy have to do with practical systems engineering?
To put it succinctly we offer a nod to another philosopher, the early 20th century Austrian-born Cambridge professor, Ludwig Wittgenstein, who said, “To understand is to know what to do.”
In other words, if we want to be able to know what to do in a myriad of complex situations, we must understand what it is we are about—we must understand the first principles of the discipline. Perhaps the best way to make that clear is through examples of what is sacrificed by neglecting first principles in systems engineering.
EXAMPLES OF MODEL-BASED SYSTEMS ENGINEERING’S NEGLECTED “FIRST PRINCIPLES”
Principle: In order to understand a system, we must have a “systems view” that allows us to see the system entities in full relationship to each other.
Systems are arrangements of their “parts or elements that together exhibit behavior or meaning that the individual constituents do not.” (INCOSE) In his book, The Systems View of Life, Fritjof Capra warns, “These properties (behavior or meaning) are destroyed when the system is dissected, either physically or theoretically, into isolated elements.”
Ignoring this warning is the most common way this principle is neglected. Partly due to our cultural position as children of the Western Enlightenment, we are given to deconstructionist approaches to understanding all but the simplest things that we encounter. When in doubt, we “analyze.” That very word comes from roots in classical Greek that mean to “tear apart.” The idea is that we can then aggregate our understanding of the deconstructed parts into an understanding of the whole.
But, as Capra reminds us, when we “dissect” a system, we destroy its properties. When we dissect our models (or parcel the elements and relationship into separate “models”), we destroy the very view of the reality that we seek. Without a system view we can’t hope to get an understanding of the system whole. We do this dissection in a variety of ways. We might do it by using different “models” of limited aspects of the system in different tools (e.g., requirements tools, architecture tools etc.). We might also do it by treating a number of views—drawings, tables, documents—as if they are, in the aggregate, a “model” of the system. But any approach that separates the entities or classes from each other, breaks the relationships and denies us the critical system view and the understanding that goes with it.
Principle: Our models must give us a system view in order to help us understand and predict the behavior of the system they depict.
Models are limited representations of an underlying reality that we use to understand that reality. A true system model is used to help us understand the system it depicts. If, as is the case in systems engineering, the model is tasked to help us understand the behavior produced by the system under scrutiny in order to determine whether that behavior can meet the needs that the system is tasked to satisfy, the model must give us a view of the system sufficient to make that prediction. Any limitation of the model that impairs that capability impairs its usefulness to the systems engineer.
Since understanding the behavior that is produced by a system requires a view of the entities of the system in full relationship to each other, any model that fails to give us the required system view of all the entities in full relationship to each other fails as a system model upon which systems engineering can be “based.” This principle is overlooked when systems engineers seek to “base” their engineering on a model or collection of models that don’t offer that view of the system.
Principle: Systems engineering is, by definition, interventional and can apply to any system that can be created or modified.
This principle is overlooked most often by systems engineers who see only applications that can be seen by analogy to applications with which they are familiar. For example, engineers with experience in the creation and reproduction of tangible “products”—be it hardware or software—are prone to deny the applicability of systems engineering to unfamiliar problem spaces like the design of social processes.
This problem is promoted and encouraged by the educational path of engineering. The intense and thorough grounding in an engineering discipline has the beneficial effect of transmitting a deep understanding of the discipline but, at the same time, can be limiting by shaping the thinking of the engineer in the context of the problems, processes and solutions that attend that discipline. The world is then viewed largely through that lens, and problems outside its field of view come into focus only by direct analogy to the disciplinary experience. This reduces the ability of the engineer to transcend the discipline and its closely related problem spaces to apply systems engineering to problems and systems outside its scope.
As we can see from even these few examples, when we neglect an understanding of first principles, we limit the range and power of our model-based systems engineering. Admittedly, we are fighting an uphill battle—an Enlightenment heritage and our educational experiences mitigate against a synthetic, non-reductionist approach—but the first principles of model-based systems engineering are not limiting at all. On the contrary, they point us to a transcendent set of possibilities.
Systems engineering has the tools and methods for solving a wide variety of problems—not just the traditional physical and technological challenges, but the social, economic and biological problems as well. Transcending the traditional spaces to unleash the real power and potential of model-based systems engineering requires us to dig underneath the recipes and processes of the standard practices to unearth and understand the first principles at their foundation.
To learn more about how systems engineering can help you and your enterprise navigate a complex world, check out this page on Process and the Enterprise.
