REPLY Models, Problems and Systems (SD7039)

[SDMAIL Bill Harris]

Posted by  Bill Harris <bill_harris at facilitatedsystems.com>

"SDMAIL John Morecroft" <jmorecroft at london.edu> writes:
> > The contrast between the two examples was dramatic.  Two years for a
> > sector map of Digital Equipment Corporation, and eight hours for a
> > close-to-complete structural map of World Dynamics. The lesson is that
> > good model conceptualisation cannot be tightly scheduled.  Creativity
> > and convergence need time.  It is much better to wait for a satisfactory
> > modelling framework to come to mind than to rush into premature equation
> > formulation and simulation.  

John,

Thanks for this.  I've been pondering this question since the thread
started.  Coincidentally, I was thumbing through my Fink and
Christiansen Electronic Engineer's Handbook (Second Edition) recently
and found their chapter on Systems Engineering.  Section 5.12 is called
"Parsimony and Validation," and I think the parsimony idea may relate to
this issue.  While we wrestle explicitly with validation from time to
time (there's a chapter in Business Dynamics devoted to the subject), I
wonder if we condense the idea of parsimony into "Model the problem, not
the system."  Parsimony sounds at once more artful and more craft-like,
something emerging from experience at creating models that err on one
side or the other.

Starting as an electrical engineer, I have modeled circuits and systems
since university days.  Certainly by the time I was doing engineering
for a living, parsimony was wrapped up in figuring out the essential
pieces to include in a model to gave useful results without creating a
baroque model that obfuscated causality.  Sometimes decisions were
obvious; sometimes they were honed from the lessons of failed attempts
that landed in the ditch on either side of the parsimonious road.
"Model the problem, not the system" may serve as a useful reminder that
parsimony and purpose count, but it's perhaps too high up on a ladder of
abstraction to define parsimony for those midway between starting out
(when it may work well) and well experienced in the field (see "Before a
person studies Zen, mountains are mountains and waters are waters..."
on http://www.geocities.com/Tokyo/8669/rantsandzen.htm).

Despite our more than occasional desire on this list to make SD easy to
learn quickly (and I am a fan of Barry's goals of doing just that), your
contribution is reminding me that SD is perhaps better seen as a craft,
a skill that grows in somewhat varied ways amongst varied people and
that takes time and practice to ripen.  Neither engineers nor violinists
happen overnight, either.

Thoughts?

Bill
- -- 
Bill Harris  
Posted by  Bill Harris <bill_harris at facilitatedsystems.com>
posting date  Tue, 13 May 2008 09:02:29 -0700