Open Discussion Thread: "Places to Intervene in a System," by Donella H. Meadows

Sorry, this turned from a comment to a monograph quite quickly...

Coming from a Systems Engineering background, I thought the recent article was quite a thought-provoking one. It was a nice expansion on several concepts out of Systems Engineering and a two other issues that have intrigued me since my graduate school days.

The two most important tenets in Systems Engineering or more exactly, Control Theory, a sub-speciality that deals with the efforts to control systems, are Observability and Controllability. Observability is the mathematical measurement of the ability of the changes in one of the inputs of a system to be seen in the measured output of the system. For example, the changes in the pressure of your foot on the accelerator in your car is directly observable in the most obvious output of the car, its velocity. You vary the input, you can watch the output vary as well. That is observability, in layman's terms.

Controllability is the mathematical measurement of the ability of an input signal to be used to control the output signal. The accelerator in your car is a good example of this as well. The velocity of the car is directly related, actually linearly related, to the pressure applied to the pedal. You vary the pressure, and you can directly affect the speed of the car (in most situations, but we'll talk about the other situations subsequently). That the accelerator input has both observability and controllability is by design, a car being a man-made system, designed to be controlled by that input.

Now let's consider the instance where the car is hydroplaning, or even hitting a patch of black ice on the highway. Your manipulation of the input signal, the pressure on the accelerator, will be evident in the additional spinning of your tires, but you will have lost the ability to control the direction and motion of the car. In that situation, a perfectly controllable and observable system can migrate into the realm of the merely observable. The input loses its relationship to the output, as measured by the velocity of the car, sometimes with drastic consequences. But this leads me to the first of my ponderings, scope.

Scope is what I have learned to call it now in the world of software development. In my engineering days, it was the drawing of the system boundaries. Where we draw the system boundaries can drastically affect the way we interpret the system and the thus the way that we strive to control that system. Simply put, a system boundary is a bubble, drawn around the system you are studying or modeling. Everything within the boundary is fair game for your study, everything outside is not considered. This sounds simplistic, but it is what every good model developer has to do, and it is in fact one of the most complicated tasks in the design process. As an example, software engineering has only recently begun to consider the human part of the human-computer system with quite an effect on the approaches and techniques used in that domain.

In my early research, we had another example of the paradigm shift that can occur when you change your system boundaries. In the past, manufacturers looked at their loading docks at their plants as the input/output points of their system. Inputs (raw material and sub-assemblies) came in through those doors and outputs (finished goods) flowed outward. In the process, labor was consumed, and waste was generated. With the advent of environmental laws, the waste stream gained some consideration as an additional regulated cost. Some future-looking individuals started looking at the bigger picture though (literally), and a different kind of interpretation of the system arose.

By changing your system boundaries to be a large bubble surrounding the plant, one can start to look at the flux of materials in and out of the bubble. Waste streams become another output and a broader output that now included air pollution, ground seepage, and run-off. But this also brought up a seemingly new insight, that since nuclear fusion is not occuring in most manufacturing plants, all of the output is generated out of the inputs coming into the system. The waste materials leaving the system were materials that had entered the system as an input somehwere, and inputs cost money. Thus, the waste streams were really money flowing out the doors.

Viewing your waste stream in that fashion makes it something whose reduction or reuse can now be viewed as a cost savings, putting environmental concerns onto the balance sheet, where reduction of waste makes both corporate and environmental sense. So changing your perspective and redrawing your boundaries can not only change the solution, but the perception of the problem.

This expansion of boundaries can lead to the second of the issues that are interesting. The larger your system, the more complicated it usually becomes. Complication comes either through the addition of more inputs and outputs to consider or through the addition of more sub-systems each with their own feedback loops and controllers. The determination of observability and controllability become more complicated if not utterly impossible (due to the effects of chaos and the like).

Imagine that instead of looking at your car and your accelerator, you were now looking at a highway full of cars, and hundreds of accelerators pushed by hundreds of controllers (read, drivers). The system at the highway scale has increased exponentially in terms of inputs, outputs, and internal complexity. We can limit the outputs to something equally grand in scale, in terms of highway congestion and travel times; the outputs that concern every metropolitan traffic management system. But the inputs and the complexity of the system still remain untractable.

The issue we face is that humans tend to think that big problems need big solutions. Rephrased, we answer complexity with complexity. Software systems tend to reiniforce this, as we can manage many more of those inputs and we can throw the computational tasks inherent in modeling the complexities of the internal workings of the system into the code. Thus, the fidelity of our models increase, which begs us to consider controllers that use that fidelity.

Oftentimes though, we tend to jumble our scales. We build a complex controller with hundreds of inputs, which models the best case scenarios. The problem is the behavior of the system is generated by the chaos of the interactions between multitudes of smaller systems , each with their own smaller controller. So we take the inputs at this granular level and we attempt to build a controller at the meta level, creating an even more complex system. And more complexity leads to more fragility. And thus the traffic system hums along, until it hits the metaphorical black ice.

These controllers in the business world are composed of the "business rule" and the "workflow". The controllers of the systems in this world tend to form as ad hoc systems that proceed to documented processes, and that eventually end up as requirements sitting on the desk of an architect or a developer. The fragility of the inherent system is masked behind the 300 pages of nicely formatted requirements. We see a grand system, and we design a grand controller. A large, fragile thing that perfectly fits the conditions at hand.

OO processes start to reverse this view. We start to look at granular storage and granular control(encapsulation) and we look to build the complex system out of simple blocks, reusing them where we can (inheritance). I believe the web service paradigm on top of the OO paradigm will get us closer to building the distributed controllers that our distributed systems require.

To bring this ramble around to a close, I think this article gets us going in the right direction. Finding the right leverage points, those confluences of observability and controllability at the proper scale of the system's components to provide a robust controllable system is an incredibly critical step in any system design or analysis.

"Give me a place to stand and with a lever I will move the whole world" -Archimedes

Meadows revised the work after it appeared in Whole Earth. That longer version is available from the Sustainability Institute at: www.sustainabilityinstitute.org/pubs/Leverage_Points.pdf