Speaking of thinking about thinking, it’s time to talk about systems thinking – a topic spotlighted in Peter Senge’s groundbreaking The Fifth Discipline (1990).

Systems thinking is about breaking any whole into not only its component parts, sub-parts, and sub-sub-parts ad infinitum, but also their sub-parts’ interrelationships. It’s a big subject – so big there’s no point trying to provide links to useful sources.

Most likely, you’re already familiar with many of systems-thinking’s tools and techniques. They’re essential for just about any IT-related endeavor.

But there’s a difference between, to take one example among many, using a swim-lane diagram to design a business process and using one to think through who should be responsible for what, to decide if that’s really such a good idea.

What follows are a few tools, techniques, and principles I’ve found useful over the years to help me think things through.

Law of 7 ± 2: This really should be the law of 7, + 2 if absolutely necessary. What it means is that whatever technique or tool you’re using to figure out a system, no representation should ever have more than seven elements in it – nine if you just have to. If you need more, make one or more of the elements more inclusive – a category of elements. Think through its complexity in a separate, cross-referenced diagram that also follows the law of 7, + 2 if absolutely necessary.

Why seven? Humans can easily grasp a collection of seven or fewer items. More than that and we have to inspect. We can verify the correctness of a diagram that obeys the law. With more elements we’re left hoping we didn’t miss anything.

Black box: If you’re trying to understand a business function – a process or practice – black-box thinking is essential. Black box descriptions describe what something does, not how it does it. They cover five subjects (thereby obeying the Law of 7, + 2 if absolutely necessary):

• Outputs – what the function is for. They’re its products and byproducts.
• Inputs – the raw materials the function converts to outputs. Any input not needed by at least one output isn’t an input at all. It’s a distraction, unless it suggests a missing output.
• Resources – the tools the function uses to turn inputs into outputs.
• Constraints – restrictions on what the process does or how it does it.
• Controls – mechanisms for adjusting process operation, such as turning a process on or off, changing its speed, or setting a configurable output characteristic.

Relationships: Six ways each system element can influence other system elements:

• Component – an element could be part of another element.
• Container – conversely, other elements could be part of the element.
• Output / Input – one element’s outputs could serve as another element’s inputs, and vice versa.
• Resource – one element could produce resources used by other elements.
• Constraint – one element could place constraints on other elements.
• Controls – one element could affect the operation or characteristics of other elements.

Feedback: A special type of relationship that describes how a process’s output encourages (positive feedback) or discourages (negative feedback) its own operation or characteristics. Diagrammatically, black-box diagrams represent feedback as arrows connecting process outputs to their controls.

As a matter of nomenclature, “positive” and “negative” are unfortunate word choices. They suggest feedback is either complimentary or critical.

From a systems perspective, positive feedback drives a process to produce more of whatever it is that it does; negative feedback causes it to produce less. Positive feedback accelerates a process, negative feedback keeps a process in control.

Output / Input Loops: Not all loops are feedback loops. Some make one or more of a function’s outputs one of its own inputs. The well-known OODA loop (for Observe / Orient / Decide / Act) is an example. Some outputs of its Act sub-function are inputs to its Observe sub-function, and in fact each sub-function’s outputs include inputs to the next sub-function.

Decoupling: Eliminating or reducing the strength of system interrelationships is, as a general rule, a good idea. It makes the system more resilient by reducing the ripple effects of any changes being considered.

Bob’s last word: We’ve barely scratched the surface of systems thinking. It’s a highly consequential subject because without it, it’s all too easy to fall into the trap of focusing on a particular element, optimizing it without taking the change’s ripple effects into account.

Bob’s sales pitch: The next “CIO Survival Guide” is ready on CIO.com for your viewing pleasure. It’s titled “The Hard Truth of IT Metrics,” and I think you’ll find it useful. And as always, if you have any feedback for me (see above), please share your thoughts about it.