According to Psychology Today, “Addiction is a condition in which a person engages in use of a substance or in a behavior for which the rewarding effects provide a compelling incentive to repeatedly pursue the behavior despite detrimental consequences.” Addictions operate to block our view of reality as we focus on the habit pattern of the addiction. As the addiction grows, we come to the point of denying various aspects of reality, instead structuring our world to fit the addictive behavior. The addiction takes over our behavior.
But, how does this dire pattern of addiction possibly apply to systems engineering? As systems engineers, we have a tendency to embrace particular paradigms and their related tools and methods and gradually grow that familiarity into something that resembles an addiction. We become blind to the real challenges facing us and instead adopt the contextual viewpoint of the addiction—adapting our view of reality to fit our “solutions.”
This has been particularly true around the reductionist paradigm regarding the construction and optimization of systems. To paraphrase a popular aphorism, “An airplane is not a large collection of aviation parts flying in close formation—and yet we act as if that were the case.”
This statement begins with the truth contained in the INCOSE definition of a system—“A system is a construct or collection of different elements that together produce results not obtainable by the elements alone,” and then observes that we fall victim to the reductionist paradigm in the very face of that truth.
We are so addicted to that paradigm that we adopt behaviors that deny the truth of the nature of systems. In the name of building system models to advance our understanding, we are satisfied to accept disjoint sets of documents that break the relationships that make a system a system. We work with domain-specific tools that fragment our understanding of the whole and, at the same time, entertain the idea that aggregating their output will yield a system model. We restrict our representations in ways that exclude others not a part of our professional segment. While we would on the surface deny that optimizing a separate part of a greater system will optimize the whole, we act as if it does. All this is done with the assurance of our reductionist addiction beguiling us into the false belief that these breakdowns are valid.
But we can and should do better than that. We need to recognize our addiction and break through it into the reality of systems thinking. What we need is the proven process of a 12-step program.
These are the twelve steps for breaking our addiction to document-centered, domain-fractured systems engineering:
1. Admit we are powerless to change the nature of the problems we were asked to solve—that pressure from complexity and time was making our lives unmanageable.
We have to recognize that, try as we might, we cannot escape the grip of complexity, and that the only way to manage it is through a true systems view. Complex problems and solutions cannot be made into merely complicated ones, and we have to recognize this reality.
2. Come to believe that a systems view of our problems and their contexts can restore us to sanity.
Once we see that complexity can be modeled and managed using systems thinking that contemplates the whole, we can begin to gain an assurance that we can solve complex systems that demand complex solutions without our addictive crutch of breaking everything apart.
3. Make a decision to turn our will and our practice over to the discipline of the systems view and the practice of model-based systems engineering.
Breaking any addiction requires real commitment. We have to be willing to give up our reductionist thinking, methods and tools.
4. Make a searching and fearless inventory of our current tools and practices.
We have to see our tools and methods in the light of real systems thinking. Are our methods promoting the knowledge of the interfaces between the elements and their relationships? When we make changes, are those automatically tracked into the model everywhere they have an impact? Tools are useful to the extent that they unburden the user in tracking the problem and its solution. We cannot excuse them by seeing them as having a limited scope incapable of producing a systems view.
5. Admit to ourselves and to our teams the exact nature of our problems and our failure to understand the systems approach.
This one can be tough. The reductionist addiction permeates our world. From Descartes’ 17th century description of non-human animals as automata made of a set of parts and explainable as their sum, to current scientific education, the elixir of reductionism pulls at our thinking. Without a candid recognition of its existence and role in our mental models, we can’t hope to eliminate it from a view of our problems and their solutions.
6. Become ready to use model-based systems engineering to remove all these defects of tools and practice.
Change is difficult. Psychologists tell us that we will change only when we see the change process as less painful than the prospect of remaining where we are. Once we see the connection between reductionist thinking and the pain of dealing with complexity without the ability to manage it effectively, we should have the motivation needed for change.
7. Humbly restructure our tools and methods to remove our shortcomings.
Knowledge without action is valueless. We not only have to recognize the problem, but we have to do something constructive about it. That means changing our tools, methods and behaviors to reflect our systems perspective.
8. Make a list of all the mistakes we were making in our methods and become willing to change them all.
This inventory helps us to recognize all the ways our addiction was dragging us down and to be sure that we make all the necessary adjustments.
9. Make direct changes to such mistakes in our methods wherever possible.
Again, realization without action does not help us. The old saw that one definition of insanity is doing the same thing over and over while expecting different results reminds us that it is not enough to see the change or even to desire it—we have to act on our desire if we hope to throw off our addiction.
10. Continue to take inventory and assess our practice, and when we are wrong, promptly admit it.
We have to be vigilant not to slip back into bad practices. The specter of our reductionist thinking is all around us. The ideas of dividing systems to understand them through their parts and seeing cause and effect as strictly linear are all around us. Once we change our thinking, our methods and our tools, we must guard against any relapse.
11. Seek through study to improve our conscious understanding of model-based systems understanding, dedicating our efforts to continuously improving our practice.
Systems engineering, especially through the use of system models, is couched in an understanding of the principles of systems thinking, complexity, innovation and disciplined problem solving. We need to further our knowledge in these areas as insurance against falling into the trap of the unthinking application of our tools and methods.
12. Having had an awakening as the result of these steps, we try to carry this message to the systems engineering community, and to practice these principles in all our work.
We can do no greater service to our community of practice, our profession and our colleagues than to spread this word—by advocacy and example. We are truly evangelists. But we shouldn’t carry this message as if it comes from on high. We should spread it collegially. The Ceylonese pastor D.T. Niles observed that real evangelism is “just one beggar telling another beggar where to find bread.” Our message will travel further with more effect if it is passed with humility and accompanied by action.
I’m Zane. I’m a recovering reductionist. If you want to know where I find bread (tools and methods), I’d be happy to share. I can be reached at zscott@vitechcorp.com .
