System Design

Problem Scaling


'System Design' is a tool like a microscope or telescope; the sequence of tasks in this guide can be likened to the process of bringing the object of attention more sharply into focus. That object is the Virtual System that includes the connection from the Issue-related Human Activity to its impact on ecosystem goods and services and their contribution to the `well-being needs' of stakeholders. Seen in the light of this analogy, the 'Problem Scaling' task is simple: it is to consider whether the designed system, in the form of the conceptual model, is too simple or too complicated. You do this so that you can scale - i.e. adjust the number of model components and the data requirements - for relevance (to the Issue), for resources (of skills and time available to you), and in terms of scientific understanding.

Adjust the complexity of the Virtual System

"An idealization is a deliberate simplification of something complicated with the objective of making it more tractable. ... Aristotelian idealization amounts to 'stripping away', in our imagination, all properties from a concrete object that we believe are not relevant to the problem at hand. ... Galilean idealizations are ones that involve deliberate distortions. Physicists build models consisting of point masses moving on frictionless planes, economists assume that agents are omniscient, biologists study isolated populations, and so on."

The quote is from: Frigg, R. and Hartmann, S. (2006) 'Models in Science', URL:

'Occam's razor': it is vain to with more what can be done with fewer, suggests starting with a simple model, and adding extra components only when it proves impossible to get realistic results from the simple model. In the face of a complicated physical and human-social world, Occam's razor is helpful. When applied to models of systems, however, it may slice away something that appears minor but which actually plays a critical part in a feedback loop. Linear models, such as those simulating cause-effect chains, can be made simple; but most systems have feedback loops that you may want to simulate, as demonstrated in the diagram below.

Illustrating Problem Scaling. On top is a simple chain from phytoplankton to a fishery in a coastal lagoon; the more complex version underneath includes several feedback loops as well as boundary fluxes.

diagram showing simple, and more complex, conceptual models of the Lagoon of Venice phytoplankton-clam fishery system

'Problem Scaling' can lead to removal of some existing parts of the conceptual model, and the addition of new parts. In ideal circumstances, such adjustment could take some time. In practice, your application will be restricted by the resources of people, skills, time and information available to you, and by the Reference Group's' time-constraints. So the Virtual System needs to be reconsidered in relation to those constraints, and a decision reached, in consultation with Reference Group, as to what can be done. If your modelers are experienced and already have portfolios of model components, then it will be possible to build, quickly, an adequately complex model. If that is not possible, do as much as you can! Our experience in Spicosa suggests that even simple models, simulating only parts of the system, can be useful, and that the business of resolving the Issue and creating a conceptual model can help by clarifying understanding of ecological, social and economic constraints on the management solutions, even if no numerical model is built.

Begin to specify formats for Output

An importnat part of a SAF application is is the reporting of scientific results to stakeholders and environment managers or policy makers. In addition to on-going discussions with the Reference Group, there will be a need to present information to the wider community of stakeholders etc. during the 'System Output' step. Therefore, begin to specify the format for presentations and visualizations (for policy-makers, stakeholders, and public) recommended for use in 'System Output'. This might include thinking about a media strategy, and includes discussing requirements with the Reference Group.

In addition, it may be deemed desirable to produce a scientific output, in the form of a paper in a peer-reviewed journal. This will strengthen the perceived legitimacy of the scientific results, will disseminate what has been learnt out into the wider scientific community, and may be vital for the career prospects of the scientists involved. What is needed now is a scoping exercise, to identify a suitable journal and its submission requirements.

The 'Designed System Report'

The 'Designed System Report' differs from the proposed scientific or popular output: it is an evolving technical document describing the work that has been done. It may already have been compiled during the 'System Definition' task, and can now be updated. If not, it is important to prepare it now, while what has been done remains fresh in the memory of scientific team. It will be updated again in subsequent SAF steps, and will provide a detailed account from which information can be drawn during the 'System Output' step tasks, and for scientific publication.

A final note

When this task is finished, you will be ready to move on to the SAF's next step of 'System Formulation'. In that step, what we have here called the social-ecological system (to emphasise its unity) becomes the ESEsystem, in order to denote that models for ecological, social and economic components may be made separately, by experts in the different disciplines, before linking during the 'System Appraisal' step.

It may help to recall the way the 'Systems Approach Framework' looks at systems:

  1. The real Social-Ecological system: we argue that the social (and economic) component is as real as the ecological part, even if some of it exists in 'world 3' rather than 'world 1'; the real system possesses the generic system properties described by General Systems Theory;
  2. The Virtual System: a way of conceptualizing a part of the real social-ecological system, omitting components not relevant to the Issue under study; this is a vieodology, whibe the objec of the Virtual System in a qualitat/LI>
  3. Simulation model(s), whic rts of the Virtual System: it is these parts that are later brought together as an ESEsystem model that can simulate the outcomes to the different scenarios that are included in the Issue package; those parts of the Virtual System that are not modeled in this way, should be subject to other kinds of analysis to explore their behaviour under these scenarios.


Move on to the Forumulation Step