Spaghetti

["William H. Cutler" <72734.3452@]

June 3, 1996

To the SD Community,

The antidote to spaghetti-itis is hierarchy.

Question: Is this network-hierarchy representation described below necessary and
sufficient to represent any system, or is there a fundamentally different
representation which is needed for certain classes of systems?

I think of a system model in terms of blocks connected by lines. The blocks
represent the entities which make up the system, and the lines represent their
interactions.

At the top level there are two blocks: the system and its environment. There
are many lines connecting the two blocks which represent everything that passes
back and forth between the system and the environment.

Zooming in on the system block, I see the first level of detail of its internal
structure. It is composed of several blocks connected by lines to form a
network. Some of the blocks also have lines to the boundary of the larger
(top-level) block, which represent detail on the interface to the environment.

Zooming in again on one of the blocks to see its internal detail, the picture
looks just the same in general character. The lines between the blocks I now
see represent the internal interfaces of the next higher level block, and the
lines to the boundary represent the detail of the next higher level blocks
interfaces with its neighbors or environment. The other blocks at this level
also have internal structure of the same type.

This network-hierarchy structure can be continued down to as deep a level of
detail as necessary, until the effective atoms of the system are reached and no
further decomposition is necessary or useful.

The skill in modeling is to make the picture at any level comprehensible by
having a half-dozen to a dozen blocks to represent the detail of the block at
the next higher level. Any more than that and it is too complicated to
understand. Any less and the richness of behavior may be lost. The trick in
doing it is to find the natural lines of cleavage of the system so that detail
is packaged inside the blocks, and the interfaces between blocks are fairly
simple. This is called partitioning. The objective is to do the partitioning
at each level so that (1) the dynamics at theat level are comprehensible, and
(2) the decomposition to the lowest levels (greatest detail) produces elements
which assemble to produce the correct representation of the system as it comes
back up the hierarchy.

If the model needs more detail to make it valid, dont add it as spaghetti at
the top level. Partition the top level into functional chunks which are
relatively simply related, and have the detail inside.

The blocks can represent various classes of entities. Just be sure to be
consistent with whatever class of entitiy is chosen.

One class of entity represented by the blocks is the actual physical agents
which make up the system. The physical entities exist in states characterized
by the applicable state variables. The physical entities produce products,
which may be the value of certain state variables passed to the other blocks, or
an actual physical product. An example would be a car. The blocks might
represent the body structure, the suspension, the wheels, the drive train, etc.
One kind of product passed among the blocks would be mechanical loads. The
drive train block would be decomposed into engine, transmission, drive shaft,
differential, axels (for an old-style rear wheel drive car). The engine in turn
would be decomposed into major components like block, heads, crank, con rods and
pistons, valve gear, carburetor, etc. The carburetor could be decomposed into
individual parts, and thats about as far as we need to go.

Another class of entity would be the functions of the system. In the case of
the car, the functions might include locomotion, directional control, internal
comfort, etc. The products of the functions would be variables such as speed,
which is an output of the locomotion function, and affects ability to control
direction (how sharp a turn without skidding) and internal comfort (wind noise).
The function of locomotion decomposes into functions like create rotational
power, transform rotational power to needed torque and speed, transfer torque to
point of application, transform torque into unidirectional force. Each of those
functions could be further decomposed.

Note that there is a many to many mapping between the two representations. For
example the wheels contribute to locomotion (applying a unidirectional force in
the desired direction of motion through friction with the road), directional
control (creating a transverse force for cornering), and comfort control
(cushioning bumps). Likewise locomotion depends on the contribution of several
of the physical entities.

A useful tool here is Quality Functional Deployment, also known as House of
Quality. This is one of the Japanese management tools that have recently been
introduced into global industrial planning. It is a graphical tool in the form
of a rectangular matrix. The rows of the matrix are labeled with the needs
which the system is to satisfy. The columns of the matrix are labeled with the
actions taken to satisfy the needs. The squares in the matrix are filled in
according to how a particular action contributes to a particular need. In the
examples above, the needs would be the functions and the actions would be the
physical elements of the system.

Another useful tool is the N-squared chart, so-called because it maps the
interconnections among N items on an N by N matrix. Presume there is a
systemcomposed of N entities of a uniform type. Create a square checkerboard of
N by N squares. Place each of the N entities in the squares on the diagonal,
starting at upper left. The interconnections among each pair of entities are
entered in the off-diagonal squares. For example, the influence of item i on
item j is entered in the square on row i, column j. The reverse influence, from
item j to item i, is entered in row j, column i. This is a very powerful tool
for keeping track of the interconnections. It never gets spaghetti-like, no
matter how big and complex the system. However, it looses the visual impact of
a conventional flow chart, i. e., it is not easy to see the paths through the
system. On the other hand it shows attributes of the system which are sometimes
hidden on a flow chart. Nested causal loops and unidirectional causal sequences
show up very well. If a particular entity is a crucial node, it will show up as
many entries in the row and column which intersect on that entity. Also it
shows how to partition the system into chunks which are tightly connected
internally but loosly connected to each other. Software tools are available for
constructing system maps, which switch back and forth between flow-chart and
N-squared representations.

Regards,
Bill Cutler
4114 Park Blvd.
Palo Alto, CA 94306
415-493-8715
72734.3452@compuserve.com

["Jaime Finguerut"]

Dear Paul and colleagues:

Paul Kucera wrote in reply of Bill Cutler:
> The power of Systems Thinking lies in using the stock flow language to

I am a newcomer to system dynamics, so please excuse me the question
that follows:
What is stock flow language ?
TIA

[Hosts note: Others are welcome to respond, of course, but some terminology
basics are:

Stock-Flow the representation of system levels (states or accumulations) as
boxes with the pipes containing valves used to show the things
that change the levels.
___________
| |
----X----->| Level |-----X----->
inflow |___________| outflow

(This only works in a fixed pitch font).
Needless to say the pictures can be made to look more elegant.

BPR - Business Process Reengineering
IDEF - a set of structured analysis diagramming protocols that show how
to represent a system as a series of related and hierarchically
stacked diagrams.
]

Jaime Finguerut (Mr.,chem.eng.)
jaime@azul.ctc.com.br

[PKucera@aol.com]

Bill Cutler wrote: "The antidote to spaghetti-itis is hierarchy."

I am not convinced that hieracrchies and decompositions of the ilk described
are necessarily helpful in generating the insights SD practitioners typically
seek. Folks (most often BPR types) apply reductionist decomposition and lose
sight of the ESSENCE of the system under examination. Anyone whos done an
IDEF decomp knows what I mean.

The power of Systems Thinking lies in using the stock flow language to
distill a richer understanding of this essence. The building blocks are
elegantly simple, but they enforce a disciplined way of thinking that helps
to uncover essence. Good SD models are almost often built top down as was
suggested, but using the stock flow language can often be more helpful in
getting to meangingful structure than can applying some exogenous structural
framework like the one described.

Paul Kucera
High Performance Systems, Inc.
PKucera@aol.com