Structure LO14869

Don Dwiggins (dwig@MONTEREY.std.com)
Sun, 7 Sep 1997 15:27:34 -0700 (PDT)

Replying to LO14695 --

Richard Karash writes:
> I published an article on "How to Find Structure" in _The Systems
> Thinker_, published by Pegasus Communications. You can obtain reprints
> from them, or it's on the web at

> http://world.std.com/~rkarash/structure/

Your event-pattern-structure triad reminded me of another triad containing
structure, expounded by Luke Hohmann in his book "The Journey of the
Software Professional" (Prentice-Hall 1997); he identifies structure,
process, and outcome as the components of a problem-solving framework.
Your triad has the context of trying to "get on top of things", to gain an
understanding of what's going on out there. His has the context of trying
to create an outcome (a solution) that will satisfy a need (the problem).
In particular, he's interested in developing a framework to underpin his
approach to software engineering.

Here's a quick summary of the elements of his triad; I'm CC'ing this to
him, so he can correct any misstatements or shortcomings in my
description.

Process is concerned with the internal "toolkit" available to the problem
solver to attack a problem (cognitive models of the problem and solution
domains) and the external methods by which the problem solving activity is
structured ("do this to produce intermediate outcome A, then that to
produce B, then use A and B to produce the final outcome"). In a team
environment, it's also concerned with organizing and coordinating the
activities of the members.

Outcomes are the end results of processes; they can be physical or mental
artifacts. As described above, some outcomes may exist only as
intermediate products in the pursuit of other desired outcomes.

"Structure defines the form and content of outcomes and supports the
processes we use to create them. It is an axiom of this book that all
human activity takes place in the context of some structure" (from the
book). It's the structure that organizes the cognitive models, defines
the methods, and ensures that the process leads to the right outcome.

Again, this is a very sketchy summary, by way of introduction rather than
education. If you're interested, read the book or contact the author
(lhohmann@acm.org, http://members.aol.com/lhohmann/index.htm).

I'd be interested to hear how the participants in the "structure
discussion" on this list view Hohmann's framework.

Don Dwiggins "All models are false,
SEI Information Technology but some are useful"
dwig@earthlink.net -- George Box, "Statistics for Experiments"

-- 

dwig@MONTEREY.std.com (Don Dwiggins)

Learning-org -- An Internet Dialog on Learning Organizations For info: <rkarash@karash.com> -or- <http://world.std.com/~lo/>