Until it was suppressed because of controversy unacceptable to the ‘powers that be’ the SDS had an online forum ( known as the ‘mailing list’) for discussion of technical issues and exchange of views. I employed this forum to initiate a debate about a fundamental issue: the scope of SD modeling.

At that time the SDS website treated this issue in narrow terms: the solving of problems. This very much reflected the academic orientation of the SDS, and excluded SD’s arguably most-important mission: modeling complete systems for modern decision-support purposes in private and public sectors, and for civilian and military purposes. SDS disregard of this mission has been yet another aspect of the downside factors at work in this body.

For professional marketing purposes the SDS website was confusing and unhelpful. An important potential client had previously noticed that my (system-wide) modeling proposals apparently conflicted with the ‘official’ definition of SD’s scope. This person had been taught the official line.

I proposed a revision of the SDS website - to reflect the wider mission without dismissing problem-solving in its proper context.

The ensuing debate was vigorous and somewhat startling. It merited the pejorative description ‘wacky’. All sorts of strange opinions tumbled out of the woodwork. A senior academic accused me of modeling outside the SD paradigm: problem-solving in his view. Others also insisted that only problem-solving was acceptable. A few supported the system-wide approach in circumstances when nothing less would serve.

Academics usually do not have the time to model large, complete systems in detail, as I do. However, to extrapolate from this position, by claiming that system-wide modeling is actually improper, illustrates the depressing situation in the SDS; especially when compared with the cohesive econometrics community. Such people do disservice to the SD discipline, and help explain the lack of regard for it.

Michael J. Radzicki, 10 February 2008

You apparently like to develop large scale SD models of systems, not problems. This, of course, is in direct opposition to the SD paradigm. That said, this is not necessarily an "incorrect" approach, but I wonder if you're able to completely understand the dynamics of the models you build. Also, can your clients (i.e., the eventual users of your models) understand their dynamics?

### You have to be kidding. What I do is well within the (system-wide) paradigm of SD. Validation of my models with real data will answer the question of the extent to which model dynamics have been 'understood' (viz correctly modeled). Loop interactions and operation etc can also be studied.

Weldon, 5 May 2008

The following SDMAIL statement from Jack Harich (29 Apr 2008) provides an opportunity to comment on issues central to future prospects for SD growth:

'... the SD rule of don't model a system, model a problem. Or in science, solve the specific problem first, and then develop a more powerful generalization from that. The latter is the real payoff'.

Strong indications, that all is not well with the above 'rule', are provided by the following:

• The Ingalls case (Interfaces, K Cooper, 1980); one of the brightest jewels in the SD crown.

• Corporate models that are used for system-wide activity and resource control, planning, budgeting, and accountability etc.

If the 'rule' is correct, these system models are inappropriate and invalid, and outside the SD paradigm. However, it is much more likely that the 'rule' is deficient.

In some cases a genuine 'problem' can be identified of smaller content and scope than that of the system in which it resides. In many other cases the 'problem' is grounded in high interactive complexity of the system. This results in low effectiveness and efficiency. The 'problem' then is: what to do about that situation.

The 'problem' in the Ingalls case was that Ingalls was due to be closed down by its parent company, Litton, owing to Ingalls' induced insolvency. Ingalls' management had to prove in court that US Navy actions had caused that insolvency. The key point for the 'rule' in that case was that no modeling below the level of the full engineering system was relevant to Ingalls' stated objectives.

In the case of corporate models the 'problem' lies with the system itself; specifically with high levels of interactive and dynamic complexity, which are beyond the scope of 'manual' management (including general computerisation). Again, in order to address this 'problem' no modeling below the level of the full system is relevant for purposes of enhancing effectiveness and efficiency.

The 'rule' therefore needs to be substantially redefined along the lines below.

If a genuine 'problem' can be identified of smaller content and scope than that of the system in which it resides, modeling shall be confined to entities (below the number needed to model the system itself) that can adequately explain and resolve the 'problem'. In all other cases modeling of the system shall be regarded as appropriate and necessary.

The existing 'rule' is pernicious because it discourages modeling at system level in cases where that is appropriate. It also contributes to confusion on the part of potential clients for SD applications. The existing 'rule' is part of the baggage that needs to be jettisoned, if the SDS is to have any real prospect of growing the SD field.

Growth from the present point should not be viewed mainly in terms of more academic conferences, or even of graduating more SD Ph.Ds. It should be seen in terms of extending the coverage and influence of SD in the real world through quality SD applications. Modeling systems has an important role to play in achieving these objectives.

As a first step the SDS web site should be amended to reflect the above redefinition.

Postscript. In September 2009 I noticed that the SDS web site has been amended, in the right direction.