Home > technical > Nasty, Non-linear, Inter-variable Couplings

Nasty, Non-linear, Inter-variable Couplings

To illustrate the difference between analytical thinking and systems thinking (which some people think are identical), Jamshid Gharajedaghi presents these two figures in his wonderful book: “Systems Thinking: Managing Chaos and Complexity“.

Equations

Anyone who has been through high school has been exposed to equations of the type on the left. To discover the impact of one variable, say x1, on the system output, y, you simply vary its value while keeping the values of the other (so-called) independent variables fixed. But what about equations of the type on the right? Every time you attempt to vary the value of one variable to discover its effect on system behavior, you unwittingly “disturb” the values of each of the other variables… which in turn disturbs the variable you’re trying to directly control… which in turn disturbs the set of variables yet again… ad infinitum. It’s called the law of unintended consequences.

Nice and tidy equations of the type on the left are applicable to, and only to, problem modeling in the natural sciences in which the players are time, energy, and mindless chunks of matter. Intractable sets of equations of the type on the right, unsolvable messes in which every variable is correlated which every other variable, are applicable to socio-technical systems where the most influential players have minds of their own. System thinkers focus on the coupling and dynamic interactions between the variables in the system to understand emergent behaviors. Analytical thinkers assume away (either consciously or unconsciously) the nasty, non-linear, inter-variable couplings and thus form an erroneous understanding of the underlying causes of system behavior. Welcome to the guild of business management.

  1. Rainee
    September 14, 2014 at 1:02 am

    Please forgive my frivolity but your title reminded of my ex-husband 🙂

  2. September 17, 2014 at 12:02 pm

    As a mathematician these two pictures do not convey what you think they do. The one on the left can have interdependencies between the variables. The function F’s INTERNAL algorithm is not defined. That’s where the interdependencies take place. The one of the right, showing the interdependencies must be “notional” since those interdependencies can only be defined inside the function.

    If you’ve programmed in LISP (used in our world for pattern processing) then you’ll have encountered Church’s Lambda Calculus, which defines the rules for the dependencies of the arguments of a function. Only with this definition can you determine the complexity of the function.

    I borrowed this book from the library. It an odd collection of rehashed ’70’s ideas. So take care in its content – saying this as a Systems Engineering. Not much actionable there on the systems complexity side other than “nice words” easily found in many other places.

    Would consider it “populist” in our domain of complex systems management.

    So if you’re interested in organization theory as a complex system, this might be useful. But if you interest is in managing complex projects, not much there to put to work. Much better “complex systems management” books out there. Starting with “Systems Engineering: Coping with Complexity,” Stevens, Brook, Jackson, and Arnold, Prentice Hall. And the best practice book in our System-of-Systems work “The Art of Systems Architecting,” 2nd Edition, Maier and Rechtin. Rechtin was the father of SoS and complex systems design.

    • September 17, 2014 at 1:40 pm

      Thanks for chiming in Glen. Everything on this blog is notional, arguable, hate-able 🙂

      I have both the solo Rechtin book “Systems Architecting” and the Maier/Rechtin follow “The Art Of Systems Architecting”. Both are terrific and filled with great heuristic guidance.

      Systems thinkers like Ackoff/Senge/Meadows/Forrester/Checkland focus more on the “socio” side of complex socio-technical systems whereas system engineers and SE orgs (IEEE, INCOSE, etc) tend to stay on the mechanistic, “technical” side of the equation. When I was younger I was interested more in the latter, but as I’ve aged my interest has wandered over to the former.

      • September 17, 2014 at 2:05 pm

        Thanks for the quick response. Sitting and typing all day on an agile PMO process for DARPA ;>)

        I have a visceral response – not to or from you – to those social systems complexity advocates that transfer the populist view to the practices of program management. That was my response to the library book.

        I’m old as well, but still a technocrat in heart and practice, too long in the military I guess. “Just do your job” is our common admonition ;>)

      • September 17, 2014 at 3:02 pm

        🙂

  1. No trackbacks yet.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.