Systems maps


Format for a systems map

Purpose

A systems map is essentially a snapshot. It shows components of the system and environment at a point in time. Unless some components are grouped into sub-systems and/or there are significant overlaps, a map conveys no more information than a list of components. But it carries much more impact, and is easier to grasp.

The main uses of systems maps are to help you to decide how you are going to structure a situation and to communicate to others just what system you have chosen to study. In particular, systems maps are used to:

Elements:

(Note linking lines, arrows etc. are not permitted elements.)

Conventions

  1. The blob lines in the figure above represent boundaries of system components.
  2. Words (e.g. aaa, bbb, ccc, ddd, etc.) are used to name each system or component.
  3. Blobs (5 and 6) outside the main system boundary (1) represent components of the environment.
  4. Blobs (2, 3 and 4) inside the system boundary represent components of the system. Components (e.g. 3) can be shown as grouped into sub-systems (2). Undifferentiated components may themselves be sub-systems.
  5. Blobs may overlap only if some components (which need not be depicted) are seen as common to both in the early stages of identifying a system of interest.
  6. A title defining the system of interest is essential.

Guidelines

  1. It should be clear which is ‘the’ system boundary. The system boundary can be emphasized by colour, or by a thicker line. A dashed line can be used to emphasize that the boundary is subjective and tentative.
  2. Irregular blobs are normally preferable to regular boxes. Boxes imply that (sub-)systems are clearly defined, which is seldom the case, and have the practical disadvantage that the eye finds it hard to distinguish between a series of parallel lines.
  3. Use overlaps sparingly. They reduce the impact and clarity of the map when trying to establish a system of interest. Overlap only when the sharing of components is important from your particular viewpoint or when you are still uncertain as to where a component should lie. This applies equally to components within and spanning the boundary. Multiple overlaps should be avoided at all costs as this goes against the aim of clearly identifying a system of interest.
  4. Aim for consistency between components. For example, avoid representing system properties as elements.
  5. Although the size of blob used is not determined by size, importance, or other characteristics of the component that it represents, it makes sense to show important sub-systems at a reasonable size and less important ones somewhat smaller, as this is the way relative size is likely to be interpreted by a reader.
  6. Similarly, although there are no firm rules on positioning of components (other than nesting and overlapping) it makes sense to put important components in a fairly central position and to place related components close together. This will facilitate subsequent additions of sub-system boundaries.
  7. It is a good idea to leave some space within your map. Not only does this allow components to stand out clearly, but it leaves room for any components you may wish to add later.
  8. Partitioning within a blob (6) is to be avoided unless fff and ggg contain all possible members of hhh and this fact is important. Normally blobs within blobs are preferable to partitions.