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.
Some of my favorite systems-thinking type ideas:
A black box in YOUR system has outputs.
. Some of those outputs might be byproducts.
. Some of those byproducts might be unwanted — by you, or by Somebody.
. That Somebody might have a PROBLEM with the generation of those byproducts; even if YOU don’t have a problem over the existence of those byproducts, the Somebody might MAKE a problem for YOU over them.
. Now THEIR problem is YOUR problem.
. To deal with the problem… you can eliminate the byproducts, eliminate the problem, or eliminate the Somebody.
. The situation looks very different if you are the Somebody, vs. if you are the system owner.
Sometimes the WORST things about a system (as judged by you) are unwanted (as judged by the system owner), or uncared-about (as judged by the system owner), side-effects or byproducts of the BEST things about that system (as judged by you).
And the title of a classic essay says it all: “On the folly of rewarding A, while hoping for B”.
Good programmers and IT people tend to automatically think in systems thinking terms: inputs, outputs, encapsulated processes, etc., as Bob so well described in this article.
Good for us, bad for most others!
We may be boring, or we may be entertaining, but our natural communication style can cause our message to be lost on users, and definitely lost on other organization decision makers. And, we don’t get the resources the organization needs, in a timely manner, despite our best efforts.
To me, the greatest value of this series of articles is that it tells us what levers to pull and what levers not to touch when we are communicating “in the room where it happens.”