STEM newsletter

Managing complexity with STEM 6.2

30 April 2002

STEM 6.2

STEM version 6.2 was released on 30 April 2003, featuring time-series views in the Editor, persistent formatting of graphs and tables in the Results Program, and a powerful new template-replication feature with the potential to massively streamline the service and cost structures of large models.

Examining assumptions with time-series views

STEM has always used parameterised time-series inputs, such as Exponential Growth or Interpolated Series, as a way to enable rapid model development from concise and manageable assumptions. However, this approach lacks the immediacy of the more familiar spreadsheet interface, and the ability to scroll across and review the actual numbers for each year, and especially the value in the last year (or period) of the model run.

Time-series views are an optional extension to the standard data-dialog interface which present the numeric values calculated from the underlying parameters in a spreadsheet-like tabular display. Key parameters are highlighted and can be edited directly (just as in the conventional dialogs for these parameters). Calculated values appear in grey, and can also be modified directly. In the example below, the 50% Base of an Exponential Growth is displayed in black in the column for Y0 (which is the Base Period for the series), while the remaining values are shown in grey.

Time-series view for Service Demand

Managing complexity with template replication

The natural evolution of many business models, whether in STEM or any other platform, tends to involve the manual replication of core fragments of model structure, perhaps for different customer segmentations or service types, or for different geographical classifications, by cost or by configuration.

Manual replication is time-consuming and tedious: copied elements must be renamed and tailored to suit the needs of each individual copy. Moreover, there is no direct way to verify the consistency of the copied elements as part of an auditing process. This second point becomes critical when, almost inevitably, some change is required within the original core fragment. The only alternative to making the same changes in parallel is to revert to the original model and repeat the copying – but both processes are tedious and susceptible to human error, especially after several iterations.

Manually copied model structure

Such a manual approach to a complex model is counter-intuitive. If you were to describe the structure of such a model to a colleague, you would not describe the original fragment, and then repeat all the detail for each copy. Rather, you would describe the original, and then explain that the structure is replicated for several named variants, specifying in detail only how the respective variants differ.

STEM’s template replication concept allows you to translate this principle of concision into software. Firstly, elements which must be reproduced for multiple geographical areas are identified as a template, together with the key differentiating parameters. Secondly, the names of separate geographical areas are specified, together with the corresponding key values for each area. STEM then automatically generates an expanded model with template replication for the named areas, and implicit aggregation for common model features, e.g. backbone network traffic, in a process that is logical, concise, extensible and easy to maintain and audit.

Achieving continuity with results workspaces and views

The Results program can save a workspace which enables the working environment to be persistent from one session to the next. The workspace file specifies the full set of loaded models and the results configuration, together with the layout and formatting of all current graphs and tables, which are then restored at the start of the next session.

In addition, you can fix a number of separately arranged and formatted graphs and tables as a series of results Views, stored within the workspace. The ability to call up this pre-arranged sequence facilitates the process of verifying a certain set of results as a model is being developed, and is also very convenient for presentational purposes.

Leaner models without Functions

The original STEM methodology for the supply side of a network was built around the concept of logical Functions representing the different roles played by different physical pieces of equipment, with one or more Resources within each Function capturing the physical parameters and costs relating to a specific item. This is the fundamental basis for modelling technology migration, through the automatic take-up of capacity of one Resource as another in the same Function is either replaced or removed.

However, in many models, technology migration is limited to a few Functions, if any. The remaining Resources cannot generally be placed in one Function, as this would imply that capacity is transferable, i.e. that capacity from one Resource could be replaced with capacity from another. So the original methodology demanded separate Functions for the remaining Resources in a model, slowing the model-building process and cluttering Views with ‘dummy’ Functions.

Now this hierarchy is optional, and Resources can be created at will without the need for a ‘parent’ Function. Instead, suitably compatible Resources can be grouped together as required when the Function model is required.

The removal of the rigid Function hierarchy enables a more streamlined user interface for Resource Requirements. The original Resource Requirement dialog for a Function has been replaced by an interface which caters for an individual Resource as its standard form, with a separate time-series table for comparing Mapping inputs when several Resources are grouped together in a Function.

These re-designed dialogs also provide an interface for defining time-series formulae for Mapping inputs, and for linking all the assumptions defining a Requirement for a Service/Transformation × Resource pair to another.

© Implied Logic Limited